…just remember to get ear-plugs or noise-cancelling ear/head-phones when the bikeshedding begins at each code review: "this would be so much easier if we could just use $LANG_EXTENSION…"
1 Like
Unfortunately, it’s possible to abuse basic features like type classes and lazy evaluation (monad transformers and lenses do not require a lot of extensions).
Even a more concise syntax can be abused. OCaml uses @@ instead of $ and doesn’t have a function composition operator, so one needs to be either more explicit/wordy or not abstract some things at all.
Haskell allows a much better function composition style, but one needs to find a balance between making code cleaner and making it point-free garbage.
5 Likes
No language, natural or artificial, will make it unnecessary to learn and practice eloquence.
11 Likes
There it is:
…it wasn’t always like this:
So Haskell wasn’t always the centre of innovation it’s seen as now, with some of that occurring in a smaller Haskell-style language with its own (also smaller) implementation. Based on that observation, here’s a simple idea:
-
bring back Gofer for the purpose of innovation and exploration,
-
leaving Haskell to stabilise for use in production and education.
Ideally Haskell would then be a subset of Gofer, with new language features being migrated from Gofer to Haskell once they have proven to be useful for more than just (re)implementing Gofer. So there would be a need for Gofer to be accessible to the wider community, but in the manifest knowledge that Gofer will always be “subject to change with little, if any notice” - that would just be “life on the cutting-edge”…
2 Likes
I don’t think either direction is correct. Real word complex systems evolve through small changes. In principle it’s possible that a large industrial user base could trigger a tipping point that eliminates friction in the language; on the other hand it’s possible that a large user base could be wiped out by too-high friction, especially once an alternative with less friction arises. Nonetheless, magically creating a large industrial user base is not one of the possibilities before us, so the only question that’s really important in this regard is “will the benefits of reducing friction be worth the costs?”. I suspect they will.
3 Likes
I’m not exactly sure what your claim is, so it’s hard to know what exactly we disagree on. Mine is this: I can’t imagine Haskell becoming a widely-used language in industry if it doesn’t fix many of the frictions in its ecosystem first. This does not imply that those frictions wouldn’t be tolerated if Haskell was already widely used (although I think they wouldn’t) nor that fixing those frictions is the only thing that needs to be resolved nor even that Haskell can or should ever become widely-used at all – just that given from where we’re starting, I don’t see how we could proceed to wider use without fixing those frictions.
2 Likes
The problem with that curious reasoning is that most “current users”:
-
learned to use Haskell when it was a much smaller and simpler language;
-
and as @f-a noted elsewhere, have since then acquired more Haskell experience and knowledge since that time.
Because of that, only making things easier for “current users” would indeed fulfil your expectation to not “gain new users from it” (apart from a few determined individuals) - having seen such a comment, why would a new user even bother?
Tooling is like the manners of a language. It’s the first impression you get when interacting with it. And it certainly can drive new (and existing) users away. Others won’t mind, because they focus on the value underneath.
But it most definitely is also a value considered in industry when weighing language/technology options. Because tooling can an does improve productivity (and fun).
Why C++ is still used in industry? Because there has not been a good alternative with better tooling. But that seems to be changing too.
4 Likes
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.
Hmm…maybe you’d prefer Idris, rather than OCaml - as a bonus, you’ll also have dependent types.
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.
9 Likes
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.
7 Likes
…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.
About all those people you contacted: do many of them think Rust is also a “crank” ?
I forgot Go and Rust, but yes, many get-the-job-done folks consider Rust cranky. Debatable, though.
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.
That’s pushing to another extreme. I mean I think it is going towards treating programming as a blue collar job.
So you’re thinking more of a separation of duties like:
- electrician, as opposed to an electrical engineer,
- mechanic, as opposed to a mechanical engineer,
- carpenter, as opposed to a structural engineer,
and so forth.
1 Like
Yeah, but there will be no software engineer. Experts of each domain can instruct and see the results, and reiterate.