If one ever wants non-strict semantics to stay, one should just create a new language for just that. It is that minor of a concept, and incredibly close to extinction.
And yes, I mean just non-strict semantics, divorced from purity or anything else. You need to abandon every other feature that you consider nice to have, just to rescue this one. Specifically, you need a dynamically typed, object-oriented imperative language with non-strict semantics.
Just take a look at the trend, with open eyes. Computing can outlast well beyond lambdas.
All I know is if Haskell were to become more widespread in production, I hope it’s on its own merits. Instead of changing its own merits to fit professional software engineering.
Professional software engineering has a lot of money, but it is not some paragon of excellence or legitimacy that is the peak of software development. The mainstream is about making engineers fungible and minimizing their decision making. Golang is optimized for professional software, and its founding principles match that description exactly.
Luckily, Haskell went from “niche hobby” to “viable for billion-dollar businesses” on its own merits without compromising its core values much at all. The parts good for industry that have been added play nice. So I’m optimistic it’ll stay that way Haskell’s diverse community with diverse and conflicting goals serves as a great system of checks and balances.
Regarding hiring, speaking from the position of someone who may well hire Haskell people soon, I’d say my view on the outlook of hiring is good. I’ve chosen Haskell for the startup where I work, and I would do so again. I know from talking to my old (Haskelling) colleagues that there is a big demand for interesting Haskell jobs. As a job hunter, I find that the outlook is very bad; there seems to be less jobs typically, and if there are any, they are in industries that I don’t particularly connect with.
Speaking from a community/language aspect, I do share the feeling that Haskell may die. My interpretation of it is that the Haskell community is aging; and without a focus on dramatic changes in the way we operate as a community: who we engage, how, what our focus is, we won’t connect with upcoming generations very well. (It’s probably worth noting that I do say with this some sadness, given that I tried to get more involved in this respect, and wasn’t successful.)
That said, I personally will continue using it as I enjoy it; but I am very aware that I am part of the aging population that uses it.
…it’s just that a few seem desperate to have someone confirm their bias about the disappearance of Haskell happening “soon”. I refer such individuals to this post:
Clean is still available, along with Miranda(R). Lazy ML still exists (and now has a second compiler!), and Gofer’s sources are still available. If more domain-specific languages are included, there’s also R.
Some of these now sit idle, whereas others are still actively used. Where will Haskell end up in this list? If only I could make a prediction like that - things for me would be very different! So I’ll guess cautiously (and vaguely :-) - somewhere in “the middle”.
Well, all of Clean, Miranda, Lazy ML and Gofer are only ever relevant for haskellers, other 99.99% of programmers do not care. They likely think they are obscure tidbits of the past, which were forgotten for a good reason. So what happens when haskell dies? They all get wiped out from memory except for the most eccentrics. Those are nowhere near e.g. scheme’s popularity, and most prigrammers do not even care about variants of schemes.
R gives a different, sadder story. While we cherish the concept of laziness, most past R programmers consider it as a weird quirk that should have been patched away. I met some of the migrants, they despise the language and are eager to change. In the end, programmers are migrating away from R to Python - they prefer the straightforward control flow that does not require much tinkering. Many of those praise python.
So yeah, I don’t think there is much time left for these. The world is moving onto making programming an unskilled labor, trying to save the cost if possible. It turns out, paying the cost when trouble happens is much cheaper than hiring a skilled dev! Notwithstanding the users who are willing to report bugs, and even fix them (open source).
Please, open your eyes and look around.
Ah, one more note. Any of these languages are only a thing in the very center of the west (US and Europe). Outside, anything other than C, Java, JS and Python is considered a crank.
If I understand this correctly, you believe programming will eventually be just another form of mass production, like electronic parts used in most of our devices - resistors, capacitors, inductors, diodes, transistors, ICs, etc. Or if you prefer, mechanical parts like nuts, bolts, rivets, hinges, bearings, gears, pulleys, drive belts and such.
Because most of us have seen mechanical devices - bikes, cars, trucks, trains, aircraft, door hinges, door locks, padlocks, cables, chains, and the like - I’ll stay with that domain (where the objects are more tangible :-). Now consider a towing hitch (or towbar ) for a road vehicle - it uses a variety of parts:
the towball, and its mounting nut and washer/s,
the releasable mountpoint for the towball, and its locking pin/s,
the metal towing frame, and its mounting nuts, bolts and washers;
(…these days, other parts are probably used, but that list more or less gives the basic idea of what’s involved.) When all those parts are assembled together on the vehicle, they all work as required to allow the towing of trailers.
So how can we achieve that same level of simplicity with “parts of software” ? If it wasn’t already obvious, the modularity of all those mechanical parts helps considerably - each one is self-contained; how it behaves can be determined independently of any other part. But more importantly, the behaviour of the towing hitch is merely the behaviour of all its parts.
If your point is that we should all collectively stop striving for a better functional programming experience and instead go for boring high-paying jobs in companies that don’t care, then I don’t think you’re in the right space.
I don’t know why the community cares this much about industrial adoption. In my mind the best example of industrial adoption within Haskell is Snoyman’s work, that’s how we got a yaml library that uses JSON parsers and an xml-conduit library that cannot parse anything large because there were “no plans on working on optimizations” back in the day. This system produces tools that are good enough for a specific use-case, but they’re not good enough for the community as a whole.
It’s not just this, the tools and libraries should reflect Haskell’s vision: pure, composeable and concise, no hacks or shotcuts taken. The performance of an individual library matters only in terms of asymptotic analysis, the actual speed comes from the application doing the bare minimum of work required at a reasonable pace.
The ecosystem doesn’t need a plethora of XML parsers with no supposed go-to, it needs the definitive XML parser. It doesn’t need the hacky json-stream on top of the gargantuan post-parser that is aeson, there should just be a minimal JSON parser library that does everything in an extensible way. I shouldn’t have to invent lazy radix trees from scratch in a lazy programming language.
The same applies to Cabal’s internal design, which from the outside looks like 15 years of “things that worked” mushed together and I wouldn’t be surprised if it’s half the reason why the Cabal dev team is this swamped.
You might be happy to know that we have been working on the new tar release, which now supports long filenames, symlinks, 8GB files etc.
This library has been in an awful state for over a decade. The main user was Cabal and for its small use case it was “good enough”, but not for anything else.
It’s a great example of the lifecycle of many Haskell libraries, which never make it beyond PoC stage.
I find it hard to comment on the reasons. I’m not even sure if it’s that different in other languages.
Tbh, I think the Haskell ecosystem would be far worse off without his contributions.
Although I have very different opinions in certain areas, fpcomplete seems to be (or was) one of the few companies in Haskell land who actually care about user experience.
Hmm, this sounds more like a praise for encapsulation. Internal details are hidden from outside, so theoretically each component should do their job independently. Of course in practice it can break - it is not perfect. However, the same can be said for everything else. After all, you have to test the finished product again, to see that the constituting parts work in harmony.
In fact, we can see this kind of ‘modularization’ working in software industry at large. Cloud service providers, Operating system, Database, Supporting applications, and various web services… et cetera. IMO, this is alike the towing hitch production industry as well. Each part company produces specific part, and the hitch assembler company gathers them to create a finished product (which will be sent to car company, I guess). Yet, each company might not practice modularity discipline internally.
Well, rather, I am saying that one shall not develop clinging to a language. Be as flexible as possible, and prepare for the high possibility that languages and ecosystems that you once loved could vanish in a few years.
Career wise, IMHO (and I am less certain about this one but) a better approach would be to leave programming industry as a whole. The software industry does not have a good outlook once you exclude AI. Tech industry has been growing for long time, and it is basically everywhere now. Can it expand further? Maybe, but I am noticing some ripples suggesting otherwise.
As always, everything is already politicized; the people that can ignore it are just the ones that are currently in control and/or currently benefitting.
Unfortunately for me, I feel myself being quite aligned with the author of this post recently. I love so much about Haskell, but lately I’ve pulled away and I’m not sure I’ll be coming back.
I recently gave Rust an earnest evaluation and realized it really works quite well. The type system is not quite as strong as Haskell, and it has some annoyances which Haskell handles better (such as Result types and the ? operator, which is sort of like a Result specific do notation), but overall it’s been pretty fantastic.
I moved to Haskell because I wanted a type system that catches the majority of my bugs, and Rust definitely does that well. Ive been using it for just a few months now but I haven’t been hit by a runtime crash that didn’t involve me deliberately ignoring error cases.
But I think the big thing I’ve enjoyed more about it is that the libraries are more ergonomic. The libs always work in a simplistic way. I haven’t hit a scenario where it was awkward of painful to implement the functionality I want to write. E.g: Yesod requires all kinds of weird stuff to get routes setup. In Rocket, it was much simpler.
I like type safety, but I need simplicity too. Of course, dealing with Rust’s ownership/borrow system is a bit of a pain, but Ive found it to be a small hurdle to get over compared to some of the errors I’ve had to deal with in Haskell. I guess you might say Haskell in a way prepared me for Rust.
Anyways as I said, I’m basically aligned with the author at this point. I will always have a special place in my heart for Haskell, and I’ll probably try to keep up with all the recent developments of Haskell, but I don’t think it’ll be my default language choice anymore
…amongst others! So I would suggest that you be as flexible as possible, and prepare for the high possibility that a certain programming-language paradigm that you still love could vanish in a few years.
Enjoy your new career, and try not to worry about the rest of us…
Haskell’s diverse community with diverse and conflicting goals serves as a great system of checks and balances.