That doesn't bode well for the rest of us if someone this accomplished can't land a Haskell job. This makes me wonder if it's been worth learning functional programming. I've put hours and hours of my free time into F#. I'm not sure that it was a wise move. That said I love F#.
Pro gamers and TV critics are rolling their eyes. =D
I feel like in this day and age, you can be successful at anything if you put in enough hours. Key is probably in being active and critical instead of being mindless.
The counter argument could be that this defines free time as measured by its opportunity cost against something else, and not as just what you enjoy. I tell people all the time that what I'm doing isn't procrastination, it's sacrifice.
All he's done is write a blog post yesterday saying "does anyone want to give me a Haskell job? I have no substantial experience in Haskell". Bit early to say he can't land a Haskell job.
I think getting to grips with Haskell and the like is worth it even if you are not going to end up using it day to day.
In the pst I have been running a program where I was introducing devs to Haskell (immutable data, purism and quickcheck lostly) and then watching how their code evolved in their classical language projects. Over all it always was a great benefit.
Still, I think our industry is seriously behind in the adoption curve of pure force languages. It is mindblowing really that important software is still mainly written in Java C and the likes…
Haskell makes you think about code composition.
My Java skills (and object composition) has changed drastically after reading about Haskell.
[java8+, of course]
> That doesn't bode well for the rest of us if someone this accomplished can't land a Haskell job.
As an opposite experience, we're currently hiring someone with no experience to do haskell and purescript. The key here is that there are few haskell companies, but also few haskellers: companies have trouble finding haskellers just like haskellers have trouble finding companies. While most of the work in a traditional tech company receives lots of CVs, we typically experience the opposite, where it's hard to find many people to apply.
Finding "F# jobs" is a lot easier in my experience, due to easy interop with C#. Many places using .Net or C# are willing to let you use F# in places if you can convince them it makes sense.
As to the question of it being "worth it". I learnt more about becoming a better programmer by learning Haskell than probably any other single thing I've done. And while I've never written Haskell professionally and haven't used Haskell in probably a decade, I use many of the concepts and principles I discovered via Haskell almost every day.
Only if other people at the company can maintain F#, though - interoperability is importnnt, yes, but experienced managers will want to plan for the time after you are gone.
In theory no, as F# runs perfectly fine on Linux. In practice all real world uses of F# in paying jobs I've seen has been Windows. The big advantage however is that there are probably at least an order of magnitude more F# jobs than Ocaml jobs.
F# runs on .Net Core, which in turn runs near perfectly on Linux (incl Alpine). The runtime is about 50MB these days, so coupled with alpine or a minimal ubuntu server, you can squeeze a lot out of .net. F# is slightly slower than C# in some ways but in most cases you won't notice it and it brings a lot more to the table. I honestly wish most C# devs would start using F# for everything by default except the GUI layer, which C# makes more sense. If you are doing purely api/backend stuff, F# can be sharp knife you are looking for on linux.
We hire F# dev. You can work on whatever OS suits you need as long as you can maintain it. If most of my colleagues are windows users, more and more are switching to tux. (mandatory, I use arch btw). Thank you dotnet core.
There's a big difference between Haskell and F#. I like F# because I can get messy and impure if I want to. I've only written a little Haskell but it seems very much the opposite - its has to be perfect or else it doesn't even compile.
Businesses generally aren't looking for perfect code. They want code that does the job well enough, that others can maintain, and they want it done fast. Haskell doesn't seem great for that, the people who can actually crank it out fast/well enough seem quite few in number. In most cases, as a business, you don't want to have an IQ minimum of 140 for people to be able to maintain and extend your code (exception for safety critical software of course).
F# has the potential to be suitable for more businesses, the skill floor is lower, and when the going gets tough you can just take on the technical debut and f**ing hack it - and someone else will be able to understand the hacks.
>Businesses generally aren't looking for perfect code.
Mostly you don't want that, but there are a few industries where its jackpot. For instance building some state control engine for rockets etc. Also Haskell does not force you to write perfect code, but forces you to write code that is considering all the possible outcomes, so even if you handwave some stuff it will be pretty clear to everyone reading you handwaved some stuff.
> For instance building some state control engine for rockets etc.
Just out of curiosity: are there companies actually writing mission-critical code in a Haskell? My impression is that those normally tend to get written in C++ and the like.
Is it because they might be overqualified, so any company that happens to do haskell (which I can imagine aren't many) are intimidated?
I mean how many people here, currently working in language X, would want to hire someone that is better than they are? I mean rationally it makes sense - bette for the company, learning opportunities, etc, but emotionally it would seriously piss me off if someone came swooping in and basically made me obsolete and look stupid. (I'm not saying the author of the article would do so, I'm just speaking in general and thinking up hypothetical scenarios)
That attitude among Haskell devs is one of the problems. The conviction that it is a fundamentally better way of programming and that anybody who chooses anything else for anything is a worse programmer certainly hampers its success.
But the main reason, at least in my 20+ year career in my industry, is that it simply doesn't have a track record of success. Haskell isn't remotely new. It was mainstream in academia when I was at university and since then I've seen multiple attempts at adopting it in a large scale commercial setting. I've seen a couple of successes, on small, well defined projects that were relatively "academic" in nature (i.e. the challenges were in the comp-sci type aspects rather than the engineering, and the interactions with other systems were minimal). I've seen more failures, projects with lofty goals that went nowhere. F# has been more successful, and I've seen some significant infrastructure built with it, but it's certainly not proven itself superior to the alternatives (in an industry where successful solutions always get mimicked).
Basically, it's 2022. People have tried it and it hasn't worked out.
> That attitude among Haskell devs is one of the problems. The conviction that it is a fundamentally better way of programming and that anybody who chooses anything else for anything is a worse programmer certainly hampers its success.
This is not true in my experience; and I have been professionally writing Haskell for over a decade. It is well understood that Haskell is excellent for reasoning about program correctness, but rather poor for reasoning about program performance/efficiency, especially memory usage. What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?). There are many domains for which correctness and productivity are important, but performance/efficiency less so. Haskell is still much more performant than many dynamic languages are.
OCaml is a nice middle ground, lots of functional goodness and type safety with a much more predictable runtime.
> What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?)
They haven't been very "successful" yet in the sense of mass adoption (even as far as smart contracts go, EVM-based dapps have multiples more users), but I think this is because of design choices in how the blockchain works moreso than using Haskell for implementation, which limit the usability right now.
Ethereum and EVM compatible chains are at least 4 years ahead in terms of smart contract activity. Cardano just enabled smart contracts in September of last year, and there's been very little success in terms of usability so far; network scaling upgrades are slated to roll out over the next few years, and the dapps that have deployed don't really work without them. For context, Sundaeswap, a long-awaited DEX just deployed roughly 1 week ago, but people trying to make swaps may have to wait days for their swap to execute, which isn't very ergonomic.
The increased activity from people trying to make transactions with Sundaeswap has resulted in sluggishness all-around on the chain as well, because Cardano doesn't have the concept of gas bidding for priority
I was replying to a comment that explicitly described Haskell programmers as "better" than other programmers and implied they make them "look stupid". I'd certainly expect anyone with some maturity and common sense to have a more nuanced view, but this attitude is expressed commonly enough that I think it does have an impact on perceptions.
I have similar opinions on Scala, lots of theory that it makes things better, but the only measurable difference is that its a nightmare to hire for, more expensive and we often have to invest time training people ... who then leave to become contractors.
I'm not anti functional or Scala, but I'm yet to see any reports etc that actually indicate there is a pay off.
There are two flavors of Scala and only one of them is about cats/scalaz. I feel intellectually inferior to people who use the latter in production. But I don't think anymore it's a reasonable aspiration to become one of them. And maven builds Scala projects equally well (with half a screen of XML) and without any SBT complexity.
I have not seen Bay Area companies where previous Scala experience counts for more than inviting me to an interview. In my current team I know multiple developers who'd like to have more Scala and Java developers who don't know Scala or even Kotlin.
I don't even view Scala as a functional language, as functions (methods) are not first class. Lambdas are encoded as objects with a single method. It's much more expressive than Java and so better at expressing many functional programming ideas, but it's not a functional-first language, it's an evolution of Java.
The underlying issue is that it's a complex language with many experimental and interacting features, which can and do cause a lot of distraction. This is not the fault of functional programming. Have a go at OCaml or F#, which are nice practical sweet spots.
The JVM has had specialized bytecode for SAM types for a long time now, you cannot really get more "first-class" than that. And really it's just an implementation detail than doesn't make the language more or less functional.
Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml. The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.
> it's just an implementation detail than doesn't make the language more or less functional.
It affects the language very much, awkward currying and tupling, needing to wrap methods in objects. Subtyping also has many complex consequences. There is limited type inference and tail call optimisation versus functional-first languages.
> Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml.
It offers higher-kinded types, but F# has units of measure, OCaml has polymorphic variants.
Each has advanced features not offered by the other.
> The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.
It was not designed as a functional programming language first and foremost, that is my point.
> It affects the language very much, awkward currying and tupling, needing to wrap methods in objects.
That is a lot less true since Scala 3.
> Subtyping also has many complex consequences.
Sure. But it also means I can use any library from the Java ecosystem, and that's a huge reason behind the big number of Scala jobs compared to other FP languages.
> There is limited type inference and tail call optimisation versus functional-first languages.
Limited type inference is typically what I (and my team) want, for the sake of self-documentation. Scala's type inference is plenty enough, and the few corner cases that were annoying in Scala 2 should be fixed in Scala 3.
Tail-call optimization is done the compiler. The lack of tail-call elimination is bothering the few maintainers of functional libraries that need to implement CPS and trampolines, but not really something the average developer will have to worry about. And it should come to the JVM with Loom, eventually.
> F# has units of measure
Scala offers more generic ways to do the same thing. Would F# need such a feature at the language-level if it had typeclasses?
> OCaml has polymorphic variants
I believe most people don't want structural typing in their GADTs.
> It was not designed as a functional programming language first and foremost, that is my point.
I don't think Martin Odersky would agree. It's not an either/or situation. Scala was designed to be a full-fledged functional language, and OO hybrid, compatible with (and leveraging) the Java OO model, and offering a strong type system that goes beyond what you find in most FP languages.
Personally, even though I haven't really thought it through deeply, I feel like Scala would be better if everything were curried.
> Subtyping also has many complex consequences
But also substantial benefits!
> There is limited type inference
I wish Scala would improve in this regard. Maybe paradoxically, inference works better with code tuned for subtyping and variance.
> tail call optimisation
This will be fundamentally solved by Project Loom. At least on the JVM (there's also Scala on JS and on LLVM).
> F# has units of measure
I dearly miss those. Type Providers even more so.
> OCaml has polymorphic variants
Could be nice in Scala. Or maybe not, can't tell now. And there's always the risk of too many features, which makes a language worse, not better.
> It was not designed as a functional programming language first and foremost
This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary, not fundamental. In other words, Scala erases the distinction, it's fully OOP and fully FP. Scala has higher order functions, ADTs, pattern matching, a module system, like SML/OCaml. But it uses keywords `class` and calls it's instances "object" like Java. And it's interoperable with Java. But theoretically there's no fundamental distinction.
More languages are becoming more and more like Scala, btw.
> This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary,
Possibly misleading yes, it is certainly a subjective point. I guess it reflects the struggle I had doing FP in Scala versus alternatives. I don't think I'm alone either, the Haskell community contains a lot of Scala refugees. Note that I have not looked at Scala 3.
I think Scala is the language most actual functional programming on this planet takes place these days. Be it just FP or pure FP.
I especially like pure FP in Scala. One can do that with Cats Effect (from the TypeLevel family of languages) or ZIO. They're both awesome, so check them out and pick what you'll like best.
You don't even need to reach out to Scala 3 (still not as mature in its tooling support), you can have a great time with the latest Scala 2 (2.13).
> versus alternatives
I think of Scala as a opinionated take on ML and a module system that is tailored to JVM (and is seamlessly interoperable with Java) that just happens to have syntax heavy on braces/parentheses. Otherwise, what's not to like? :)
I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery.
I get that it is probably more intellectually stimulating for many engineers than the project they are working on, but it also reflects in over engineering of distributed systems for simple problems. I do wonder if there is really any net gains for a company to go the functional route.
I would love to see some research on this as people have been championing it for decades now, and seems suspiciously absent!
> scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery
This feels to me like a low effort and vague criticism.
Essentially, this is a complaint about an arbitrary group of developers that they're playing around with tech (whatever that tech might be) instead of delivering...
Obviously, in this case you can't say that specific thing about Python/JS/PHP/whatever developers, because "monads and type theory" just don't apply in these languages. (I know Python has MyPy, but let's put that aside for the simplicity of the argument.)
But for some non-scala/functional engineers, somebody could complain that they're wasting time playing with GUI frameworks, testing frameworks, async libraries, whatever...
The truth is, people can clown around with any technology, just as people can deliver with Scala/FP or something else.
> I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery.
Then how do you explain that a very significant number of "top" tech companies have teams who manage to deliver products written in Scala or other FP languages?
Teams have managed to deliver products in also sorts of languages, Cobol for example.
Did the choice of language benefit the delivery, maintenance and TCO is my question.
If I choose Haskell/Scala over Java (FYI as a programmer I'm not a fan of Java) what benefit will it actually bring the business, and does it out weight the negatives, over what time frame and how much risk?
There are technical tradeoffs everywhere. But you cannot make a caricature of FP developers, supposedly not willing to spend energy on delivering products.
Lots of tech companies have proved that you don't need to follow Google and constrain your workforce to a small list of vetted languages. Most teams who chose Haskell, OCaml, Scala, Rust... are productive and able to deliver products.
> There are technical tradeoffs everywhere. But you cannot make a caricature of FP developers, supposedly not willing to spend energy on delivering products.
That is my personal experience, a tiny data point, again where are the studies that give some actual useful guidance?
I wrote a great project using Racket, everyone should use Racket, its cool, lets blog it ... gains momentum, its new its exciting it promises change ... people start to have different experiance, bad decisions are made ... new bandwagon, lets all rush to that yay. Having been around for long enough to see this cycle, I think it's right to ask for some well thought evidence, or gathering of trade offs to help decision making.
But my point is does moving to FP, which is the direction of change, actually bring any benefits to the actual outcome?
My question is simple as that, yet as engineers we get lost in the detail of the doing and some hand wavy suggestion that it makes things better, yet where is the actual evidence for this?
Be pro FP or not, or any other programming paradigm, lets say logic based (prolog etc), where is there any measures on how it benefits outcome.
I appreciate this isn't something that can be easily measured, but that is arguably a key problem with the state of the industry, that its emotion, intuition and bandwagon driven.
F# is an awesome language that I hold very dear, but it is a castrated form of OCaml. It has only a few features that OCaml doesn't have. For example Type Providers or Unit of Measurement. These are nice and useful features, they're not gimmicks, but they're not fundamental.
On the other hand, Scala isn't a hollowed out Haskell. Haskell, admittedly, is a more powerful language and has features Scala doesn't, like a linear type system. And it's just different, non-strict, whereas Scala is strict.
But Scala is also very powerful in other fundamental areas, where Haskell is weak. Scala has a superior module system, it's biggest strength IMO. Haskell's modularity story is that great AFAIK.
I remember perusing a book on ML (the language) and having aha moments such as "so this is where the '_' naming convention comes from" and "this is where pattern matching was borrowed from". Monads (aka zio/cats) are not built-in, the "lazy" keyword is a far cry from strictly lazy evaluation. I say "Scala to Ocaml" on the JVM is equivalent to "F# to Ocaml" in the .NET world (there must be some category theory joke in this topology).
> I don't even view Scala as a functional language, as functions (methods) are not first class. Lambdas are encoded as objects with a single method. It's much more expressive than Java and so better at expressing many functional programming ideas, but it's not a functional-first language, it's an evolution of Java.
It' technically true that Scala's fundamental building block is object, not function.
But that is in my eyes more of an implementation detail. Scala is a language that blurs the distinction between FP and OOP to the point of meaninglessness. You can do FP and still organize your code into classes/objects/traits (aka modules). You can choose to do side effects. Or you can waive them and do pure FP (like in Haskell) with TypeLevel or ZIO.
> it's an evolution of Java
I would say that it's kanda the other way around. Scala is a beacon that almost all languages are converging towards, not just Java.
> complex language with many experimental and interacting features
It doesn't have that many features. Some people even call Scala simple for this reason. But the features that is has are _very_ powerful. Some maybe even too powerful for my taste (implicit conversions anyone?). And they're orthogonal so they can be composed together.
Sadly, such composition can be brittle and non-beginner friendly, especially when it fails -- things like weird type errors or weird unexpected behavior at runtime, or compiletime for that matter, etc.
So Scala will give you a lot of rope to hang yourself onto, if you'll be blindly taking it.
But it doesn't have to be that way. You (or a senior developer) have to know what you're doing. Then you can reap significant benefits.
It's good news that Scala 3 significantly improves on this front -- it emphasizes programmer's intent instead of Scala's internal mechanics.
Sure, in some languages, this risk isn't even on the table (Go, etc). But having power also comes with benefits, not only the potential problems I've described above.
Haskell's slogan was "avoid (success at all cost)", so it's hardly surprising that it's been considered niche since its inception.
It's seen adoption among at least a couple of large companies: Standard Chartered, and Facebook uses it to make a DSL for spam filtering. The key point for at least those adopters is that it has a fast turnaround time for quickly changing code and still having it be correct.
Is this objective data? No, certainly not, but it's probably better than pure speculation.
I personally speculate that it has a lot to do with what type of problem you're solving. If you're solving difficult/intricate problems language matters a great deal, but if you're just doing CRUD the language choice probably matters much less. Or if, as above, you're working in a domain where being correct the first time matters a lot.
I honestly think this is/was an idiotic move; especially since the alternative reading 'avoid "success-at-all-cost"' is not thaaat much better, like (from the second link):
"An example is I/O. For literally years Haskell had no I/O to speak of; more precisely, I/O was unreasonably difficult. For practical utility that was pretty inconvenient. But we stuck to purity…"
I mean, would you want to rest your business on such an attitude? (Which is a great attitude, also gave monads, explained in the link, and advanced the language while keeping it pure). I am not saying a language/environment has to be business friendly, but if you want businesses to use it, it better be.
> I mean, would you want to rest your business on such an attitude?
Haskell started as a research language by academics, for academics. Business concerns have not been a large concern in its language evolution. That's fine IMO, it's good to have a place where CS researchers can experiment relatively freely without having Big Corporate Stakeholders demanding absolute backwards compatibility for all time (see Python 2->3 for an example of that).
The best parts of Haskell have slowly been copied by other languages (for example: typeclasses became traits in Rust, list comprehensions are in Python, goroutines look a LOT like Haskell threads, etc), while the experiments that didn't work out as much (lazy I/O for example) just don't get copied.
"It's no good for business" just misses the point of a research language completely IMO. That said, some people want to make it more business-oriented and have been making strides towards that goal. Haskell does not really have a BDFL, so anyone can (try to) move the ecosystem in any direction they wish.
> I mean, would you want to rest your business on such an attitude?
From a business pov, the idea would be to assess whether you're happy with what can be done in userland rather than expect syntactic or semantic changes. I can't think of a company that started doing haskell waiting for future features to be added in the language.
Do you know of any person that made a decision based on the slogan contents? It was an obvious joke. I've seen people claiming to avoid a language that posts a joke on the front page (honestly, appeasing to those people were a sure way to add those costs the slogan is about), but never because of the message.
Anyway, removing the parenthesis makes it clear that the operations are associative. Otherwise the phrase would be wrong, and Haskell developers really dislike that kind of wrong.
I think you took the wrong message from my message.
I was saying that the Haskell people were unapologetic (and obviously tongue-in-cheek)... and that one perhaps shouldn't expect massive commercial success when the people in charge obviously weren't going for that.
Haskell has been a huge success in how it has inspired the industry. I believe there is more where that came from. I think Haskell Generics could be really powerful if it was made way more usable and intuitive.
I don't think this is a good philosophy to follow. Javascript for example was a terrible language. It's better now because they modified it and most people use typescript... but it was shit starting out and it's initially popularity had nothing to do with how well it worked.
I will say that haskell does solve many of the problems we face in software engineering today including coding ourselves into a corner. The problem is the paradigm is extremely hard and that's what hampers its success.
> Basically, it's 2022. People have tried it and it hasn't worked out.
It worked well enough for us when we tried it.
I guess the issue is that people and companies really have bad expectations on what "works out" means, and how different languages may need different kinds of environment/investment. If you expect to run a haskell shop the same way you run a java shop, you'll run into trouble as soon as your original team leaves. Likewise, if you run your java shop as you would run a haskell shop, expect trouble.
F# was built to be successful rather than pure. The Early History of F# writeup[1] talks about Don Syme wanting to get strongly typed functional programming "delivered in such a way that it could be adopted by large numbers of programmers", and SML.NET which was being developed at the time was not looking like it would do that. He then worked with someone to port Haskell to .NET and got it running, but with input from Simon Peyton-Jones decided on a different direction. Then went towards OCaml and whether it could run on either JVM or .NET and had this exchange:
> "OCaml already shares a platform with C (at least with the native−code compiler), so all the C libraries are already available... Yet it can still be a lot of effort to link with a C library.[...] There's hard work to be done to realise this vision, but in principle a clean interop story sure beats the endless rehashing of other people's code in language X as a library in language Y. Myself and others involved in the Project 7 are working on one approach to achieve this interop, i.e. compiling languages directly to .NET MS−IL, in the style of MLj, often adding extensions to the language in order to improve the interop. We are also working on improving the .NET infrastructure, proposing support for features such as parametric polymorphism in MS−IL..."
That is, Don Syme was not focused on the most pure ideological code first, he wanted something a large number of programmers could use, and adapting the language and tooling for that goal. F# became a thing supported by Microsoft, by Visual Studio, interops with C# libraries, and C# being able to use libraries written in F#, with very low friction as they share the same runtime, garbage collector, basic type library, exception system, etc. Quoting from the PDF again:
> "As an aside, I think it would be an interesting question to say "OK, let's take it for granted that the end purpose of our language is to produce components whose interface is expressed in terms of the Java or .NET type systems, but which retains as many of the features and conceptual simplicity of OCaml and ML as possible." I'm not sure exactly what you'd end up with, but whatever it was it could be the language to take over from C\# and/or Java (if that's what you're interested in...) But without really taking Java/.NET component building seriously right from the start I feel you're always just going to end up with a bit of a hack − an interesting, usable hack perhaps, but not a really good language"
F# is a bit awkward, not perfectly pure, has to cope with .NET nulls and C# being the big force for the direction of.NET and so on. 20 years later, well who knows but in the StackOverflow survey of 2018 F# is 9th "most loved language" and OCaml is 25th.
> I mean how many people here, currently working in language X, would want to hire someone that is better than they are?
I have always tried to hire better than I am (and ever will be); not to say i'm very good, but a lot of people are very bad. I hired, multiple times in my (30+ year) career people who are much better than I am at pure tech stuff like creating great code. I would love for someone to make me obsolete (I don't think looking stupid is a thing), then I can focus on other stuff. In my first company I was the founder and CTO; I replaced myself with a much better CTO who was so much better that I suddenly had literally nothing to do. So I went on to create + run our research (r&d) group which was a lot more fun than being CTO. Far too many people stay in positions they don't like for pure ego; I don't care what they call me as long as I like the work and I get paid enough, in that order.
I guess when you have a job and this happening it would be less good. Although I would see it as a sign to go do something else.
That is why choices like that should be left to project managers. As someone who is coding less and managing more these days, I have none of that ego left. If I could hire someone twice as good as me I would do so in a heart beat[1] and then go home and celebrate my great luck.
Just search your favorite job board, you'll see that Scala is far more popular than anything else in this space. Elixir is pretty niche, you can clearly see that on https://whoishiring.io (that is scraping HN among other sources).
I think this is not a useful or productive mindset. I mean the idea of "I spend hundreds of hours learning $TECH in order to get a job in it".
If you learn it because it is interesting to you and you enjoy the process of learning and using the language/tech, then that's all good. How to "monetize" your hobby is a separate question that should not factor in whether you should or should not cultivate it. There are probably many ways to monetize it. Landing a job is just one way.
> cats or zio are basically ports of Haskel into Scala
Not really. And ZIO takes special pride in that not being the case.
That's not to say that the authors didn't know (about) Haskell and its libraries. But these are distinctly Scala takes on the topic. Especially ZIO, heavily relying subtyping and vairance, is very far from Haskell while still being pure FP.
ZIO's "FP" library called "ZIO Prelude" totally revamps the "traditional" Type Class hierarchy, using Scala's intersection types feature. The name ("Prelude") is the only Haskellism there :)
Author doesn't say he has trouble finding a Haskell job. If I had a Haskell blog that regularly reaches the HN front page, I'd write a "looking for a job" post there as the first thing in my search, not after exhausting all other avenues.
After running a whole lot of coding interviews, one thing I've noticed is that people that take a functional approach to solving problems more typical end up having a hard time. Mostly because the functional style is more difficult to debug.
This can also be a classic case of why coding interviews are often a poor approximation of real world tasks.
Imperative (and especially dynamic) languages typically make it easy to get something "working", but it can take many iterations or lots of unit tests until it's robust enough to be worthy of handling a production load. That time spent futzing around with it isn't often capturable in an interview. If it is, chances are the interview isn't asking something representative of real-world scenarios, or it's taking a very narrow slice of one where someone's approach is going to change a lot of they're not just working in the narrow slice.
Functional (and especially typed functional) languages do make it harder to get something up and running, but they tend to have a nice side effect that if the compiler is satisfied, it won't need more work. That usually happens because you can capture the domain in a type declaration that the compiler requires you to account for all cases of. And if you're missing something, it's easy to adjust because the act of adding another case to your domain makes your compiler point out exactly where else to update your code.
I'm still a newb to F#, but did a few Advent of Code 2021 in it. Once I learned to do a log function that logged/dumped input to a file - and then returned the input - it was trivial to stick this log function anywhere in the pipes or folds or wherever to get a view of the program state.
I would then use the "Send to repl" feature to fire off single pieces of my program expressions to get instant feedback on the code I was writing. Long before the entire program was run in whole, each part had been run many times.
If you're in a classic whiteboard interview sessions you are robbed of this possibility. That's unfair because it's a big part of working with F# (I would guess other functional programs as well). You might feel you "pay" a bit in avoiding mutable state and having everything as an expression, but you gain so much in return, but you gotta use it!
I guess my argument is that a whiteboard situation might favor an imperative style, where you would write, compile, run and not use repl throughout development?
I haven't really figured out the "why", but the observation is that people that start using the typical functional portions of a language (map/reduce/whatever) are more likely to get bogged down if the code doesn't do what they expect. And this is even for people that seem really good at it.
Debugging functional code is a bit different and not everyone picks up this skill. That's why functional code tends to be harder to debug and people who pick up this skill will take longer in debugging it.
The main reason is printing. All your code is inlined into a single expression. You can't really throw a print statement in there. With haskell it's even crazier as if you do manage to print your code it comes out backwards.
This is because creating the exact right abstraction for the job is time consuming. It may pay off later, and your typical FP person is fairly convinced that it will in terms of being able to be confident you got things right without having to test a lot of basic shit first (types tend to replace tests).
This is not suitable for the typical interview format.
That theory seems relatively sound. I'm digging more into functional programming again, because I think reading code needs to be easier than writing code, or at least reading code should be as easy as possible, and maybe it can meet that need.
F# knowledge is valuable even if you don't use it. I've been down that rabbit hole a few times in the past 10 years or so, and even though I don't use it for work, it changed the way I code.
There's other things in the world than money. Even if that is your philosophy, consider that learning obscure functional languages might make you a better programmer across the board.
Don't worry about it. The functional style can be translated to helping you code functionally in other languages and solve problems with a functional bias.
