Ultimately, asking programmers to relearn how to be programmers (or, more relevantly, asking businesses to accept that overhead and/or a vastly reduced hiring pool) is just too large of an ask for whatever marginal gain you might expect from using a "superior" programming language.
To be clear, I learned Haskell for fun and got to what I'd consider an intermediate level of expertise. It was an incredibly enriching experience, and gave me a new perspective on programming in general. But it was hard, and the rabbit hole just keeps going---sure, you can juggle monads in your sleep, but are you proficient with the `lens` library? No? Well, I can recommend you a pile of textbooks that might help.
As a somewhat experienced programmer, I would actually say that the language extensions are an important part in disincentivizing learning Haskell for me, because even if I learn the base language, it seems like I would need to understand all these weird extensions to read real-life code, which always seems to involve half a dozen of them.
https://downloads.haskell.org/~ghc/9.2.1/docs/html/users_gui...
Also typically language extensions are pretty simple, single purpose, and well documented.
I will try again to explain with an example how these extensions are borderline user-hostile.
One of those extensions in your article linked above is apparently something called `DoAndIfThenElse` which enables if..then..else syntax with if and then on the same line, so far as I can tell [1].
When building programs that assume this extension without declaring that pragma, you get helpful error messages like "Unexpected semi-colons in conditional" [2]. Dealing with oddities like this seems to be routine any time I work on a Haskell project that's not a tutorial, and the constant need to go hunting for these error messages and add random pragma headers saps energy and is discouraging.
There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim.
Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases. I think whoever is steering the ship in Haskell/GHC land should really focus on ways to freeze new language extensions, and make the current ones well-documented in addition to providing options like the one you linked. Newer languages have environments that are much friendlier towards newcomers in terms of both documentation and (for lack of a better word) runnability of real-world code.
----------------------------------------
[1] I would really like to know why this is considered a popular language extension, and/or why it was needed, but let's skip over that for the moment.
[2] https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-lang...
Well thats kind of the point of the GHC2021 extension. It will be a standard so that new programmers that format if else statements as they would in other languages don't get a weird error that very much does SAP their energy.
> There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim.
It certainly calls it into question, though I did say typically. I'm open to weakening to "many times" if there are more than a few other examples.
> Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases.
The problems described occur as a result of the extension not being turned on, so I find the logic doesn't work here.
But that isn't really the case today, is it? Almost all the cool power features of Haskell have been adopted by the rest of the world. Type inference, pattern matching, explicit nulls, algebraic data structures, rich type systems... although it isn't usually enforced, the world has woken up to the fact that "mutable state is dangerous and should be avoided whenever possible". Writing a program without any reassignment isn't nearly as alien to a programmer starting out today as it was 20 years ago. Back then, even passing a function as an argument was edgy (and, in C/C++, risky).
I think what's hampered Haskell, and made at least me reluctant to pick it up again, is that for all the ridiculous talent working on Haskell, there hasn't come some brilliant fix to the space leaks thing. Almost as if there's something fundamentally hard about composability and laziness. I'm really not sold on laziness by default anymore, it costs so much more than it tastes - and for everything else, Haskell is a victim of its own success in that so many of the things it pioneered has gone mainstream.
In brief, I think Haskell is still the purest expression of what makes it great. This is both a good thing, for the reasons I outlined there, and a bad thing, because e.g. stringing together a few iterator methods in Rust may be a functional style but it still prepares you for the concepts you'll encounter in Haskell about as well as zooming a Hot Wheels around on the kitchen floor prepares you to drive a lap in an F1 car without stalling out or flying off the track.
People with a modern imperative background know this intuitively---or maybe they just assume it, and happen to be correct---as soon as they look at a page of nontrivial Haskell code.
One thing people seem to miss about laziness in Haskell is that it's (unfortunately?) really tightly coupled with how "control structures" are expressed. For instance, instead of writing a loop with some infinite or indefinite condition, you might declare a list using a generator function and iterate over its values. I would like to see how other similar languages (e.g. Purescript) have done away with it, and how it impacts them. But my recollection from when I actually knew Haskell is that it was an incredibly powerful feature tightly integrated with the language design, not only from a data perspective but also from a perspective of allowing code structures to map much more closely onto the data structures they're manipulating.
(This is a big part of why, as I think I mentioned somewhere else in this thread, Haskell is so ergonomically suited for working with tree-like linked data structures.)
More likely, network effects can explain how something makes it to the mainstream. For example having a big corporation behind the development and marketing of the language.
Though I'd recommend a youtube channel called 'Low Level Javascript' (really!) which comes close in developing some of their parser combinator library.
Granted the ASCII tick/apostrophe is neither the proper symbol for primes nor quotation marks (should be curly), but programmers are reluctant towards Unicode.
If it’s because Rust is still mostly imperative, then you could look to Clojure or even Scala—less complicated when it comes to types, but also (usually) much less imperative. Both I feel are more popular than Haskell.
IMO, imperative vs. functional aside, Rust does suffer from a lot of the same learning curve issues people commonly pin on Haskell. Rust has plenty of libraries with weird, excessively "clever" APIs, weird experimental language features, a complicated metaprogramming facility, and so on. Personally, I have found lifetimes in Rust more annoying to deal with in semi-nontrivial situations than anything I ever encountered in Haskell, and it doesn't help that things that seem like they should work often don't.
(I always figure that's the language telling me that I should use a different memory management strategy, and I generally follow its advice, but I digress.)
This is very much my opinion, but I'd attribute Rust's success over Haskell to three main points:
* Functional vs. imperative, skill curves. Rust is still vastly more familiar to most programmers at a first impression, and IMO it also has a lower skill floor.
* Rust's tooling feels a lot more modern and streamlined. `cargo` is a joy to use. Maybe Haskell's ecosystem has improved, but back when I was actively using it, it was clearly inferior to Rust's. For me, this manifested mainly in significantly greater difficulties managing dependencies and reproducing builds. This stuff is a first-class priority for the Rust team, and it shows.
* Somewhat related to the last point, Rust is "cool". It isn't burdened by decades of academic cruft; it just feels approachable, modern, and relevant in a way Haskell doesn't.
The last two points aren't really Haskell's fault. I think the Rust team has done an absolutely top-tier job of making the language approachable and usable, obviously building on lessons of the past (including Haskell, Stack, cabal, haddock, etc.) and I'd almost say it's succeeded despite the essential nature of the Rust language itself.
Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means. Lazy evaluation is actually a double edged sword so it's not a clear win either.
Rust on the other hand is adding safety and correctness assurance specifically without or with very little runtime overhead while providing very predictable performance (both in runtime and space).
You can sub Haskell out for Clojure/Scala/OCaml and arguably mixed paradigm languages like Kotlin/Rust/Swift and be fairly happy.
However if the constraints of your problem call for Rust then your only other real options are to sacrifice correctness/data safety and use C/C++ instead.
FWIW I think Haskell is awesome, this is just why I think we don't see it in "the real world' much.
Back when I was fluent in it, I wouldn't reach for Haskell for functional purity or lazy evaluation---I'd reach for it because I wanted the richness and flexibility of its type system and pattern matching for building and manipulating a tricky data model, or because I was doing something involving tree-like linked structures and/or that lent itself well to recursion. Parsers are the obvious example, but they are a very narrow view of what Haskell excels at.
(In short, I'd reach for it for reasons that are basically impossible to explain to somebody who doesn't already know what I'm talking about.)
I can't be so effusive about Rust. It's a really great language with a thoughtful and restrained design, powerful and practical and flexible, but I would actually say the opposite re: filling gaps: Rust feels like more of an iterative improvement in the space occupied by C/C++/Go/etc., while Haskell is transcendently good for those classes of problem where it excels.
---
Today I'm more or less fluent in Rust after a few hours' warm-up, but it would take me days or weeks to warm up my Haskell. Why? Mostly because I've largely stopped programming for fun, and I use nothing like Haskell at work. Throw in the quality of Rust's tooling and the largely effortless reproducibility of its builds (great for warming up a 6+ month old project), and it's just a far more practical choice for the little hobby programming I do. Hence my earlier comment. But I still contend that Haskell has vast untapped potential, locked away behind an intractable adoption barrier. It's less that it has nothing new or useful to offer us, and more that we are unwilling to pay the price of admission.
Is the end result reached by other means the same? Can you give an example of a competing approach in a non-pure language that gives one Haskell's advantages?
There is maybe some niches where that wouldn't be the case like very high assurance software where instead of Haskell you might choose say ADA instead but I'm not really familiar with those domains.
Kotlin plus property testing gets you very far and the industry defaulting to that would be a huge improvement.
I'll have to rewrite one of my Haskell projects in Kotlin and see if I feel anything is missing.
Rust brings a new set of tools and tricks and safety to an important use case that has had no movement for such a long time. The only real advancement has been smart pointers and "modern" C++, but while they are an improvement they also contribute to C++ being a bag of all the features.
I haven’t yet tried programming rust, but I have read that error management and suggestions for correction in rust are superb. That makes a world of difference for a neophyte in a programming language.
I feel the burden of proof for the claim "superior languages make only marginal differences" is one that is very high and one you have not met.
The null hypothesis would be that all reasonably well supported modern general-purpose programming languages are about as productive as each other on average. I have my own anecdotal opinion(s)^[1], but the onus is really on anybody claiming language X is superior (no air quotes there) to prove it to the rest of us.
In this case, by using air quotes, I meant to draw attention to the fact that the aforementioned proposition regarding Haskell's superiority is (AFAIK) unproven, as well as to illustrate the skeptical attitude a practical business leader might have toward embracing it, for what I consider to be totally fair reasons.
Also note that I'm not necessarily using 'marginal' in a pejorative sense. A marginal improvement can be significant.
^[1] Anecdotally I think Haskell is transcendently good for certain kinds of problems, and a huge pain in the ass for others.
I noticed that and considered (and should have said) this to prevent any miscommunication:
I feel the burden of proof for the claim "language choice makes only marginal differences" is one that is very high and one you have not met.
Then if we want to disprove the null hypothesis there we give one programmer brainfuck and the other Python ;)
Hence "reasonably well supported modern general-purpose programming languages".
I think this null hypothesis is where most sufficiently jaded working programmers end up, and business leaders without a programming background will start there because it's all Greek to them. I'm not here to prove its correctness, just to raise it as a very real factor working against Haskell's adoption.
Nothing would delight me more than for somebody to come along and unequivocally prove that Haskell is a silver bullet. But the point here, really, is that nobody has yet.
There's also a burden of proof on those who claim there is no diffrence.
20 years ago you would've been saying C++. Rust is closer to the Haskell of 20 years ago than it is to most languages of 20 years ago. Hell, one could make a decent argument that Java 17 is closer to the Haskell of 20 years ago than it is to the Java of 20 years ago. Even Python is feeling the need to add types (and increasingly more people are using TypeScript rather than vanilla JavaScript), even Go is feeling the need to add generics...
> In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries.
This is completely backwards IME. In most languages, every new framework comes with its own abstractions that you have to learn (whether that's, IDK, Spring Beans, ActiveRecord, React Hooks, ...). Haskell-like languages where there are a few standard meta-abstractions like Monad/Applicative/Functor make it an order of magnitude easier to pick up a new framework, because they mean core abstractions work the same in every framework.
All that said, I do kind of agree with your conclusions, but I think that's more about the industry being dishonest about its priorities. IME Haskell really does deliver what it says: for less than twice the effort of something like Python, you can write software that approximately never has bugs, in the sense that it will always do what it was specified to do. But most of the industry doesn't actually care about getting rid of bugs; they'd rather have buggier software in less development time (and if that means more maintenance effort in the long term, well, who cares).
Exactly! The abstractions are less leaky, more sound, and give this gift and feeling of universality, unrivaled composition, and cohesion.
About the last point, my tiny observations is that language too advanced don't get used as dependencies.. they get ignored until the crowd matures enough to get the ideas in their own ways and pull a gene transfer.
- lisp idioms (map, filter, destruct) => all dyn langs
- react / vue .. basically let over lambda and closure based programming (I even believe vue provide/inject is near equal to dynamic variables)
wait until someone there likes to thread state or rng seeds through 'chains of functions' and you'll see monads pop up
Tooling still has a way to go, but I don’t think that’s all. Haskell’s abstraction is just too much when you need to design something which is ultimately kind of straitforward, and most apps are (design app, game, utility app, web server, etc.)
I do think Haskell is more than a research language, it does have some use in practical, mainstream programming. In particular, Haskell is great at anything which is “input to output”, like compilers or document converters. Or in a program which is ultimately complex, and not just for optimization but “math” complexity, like math programs or simulators. In those programs the implicit laziness actually comes in handy.
But Haskell for a real-time video game or editor, and you’re just wrapping everything in an IO monad or some restricted stateful equivalent, and executing most of the instructions in sequence anyways.
I've done a couple small projects in Blueprint which is a purely functional programming language embedded in UnrealEngine 4 and I enjoyed it a lot. Blueprint notably does not expose any type classes, at least not when I tried it a couple years ago, but it felt very expressive for building complex game logic.
Disagree from me. I spent a year writing Haskell professionally, and from my own personal experience Haskell's tooling was overly complicated and difficult to use.
Maybe my impression is totally wrong or outdated, and it's surely not applicable to the whole community, so I'm sorry if this is a little out of touch now, but I sometimes got the sense that Haskell's community just doesn't care about the developer experience. They hold to this false dichotomy that if you make tools easy to use, then you can't have advanced features. Or simply, Cabal works just fine the way it is, why do we need Stack? Why would you need more than one GHC installation on a machine? Holy wars on the mailing lists re: Stack, Cabal, Haskell Platform. And if someone tells me to "just use Nix" one more time I will cry...
Rust feels like a breath of fresh air. The community seriously cares about their developer experience both for newbies and experienced professionals, and it really feels like a lot of work has gone into making the tools and documentation accessible and useful.
I don't think they are. Having used both, Rust's tooling is more accessible to beginners, which makes a big difference. I find it even easier to use than npm, while I find Haskell's tooling harder (on roughly the same level as OCaml with dune, or Maven).
> Haskell’s LSP is making rapid progress and there are many formatters and linters.
Haskell's LSP is good, however it's not as good as rust-analyzer, and has a habit of chewing through a lot of RAM.
[0] https://www.researchgate.net/publication/3246772_Planning_th...
Some more effort in packaging this ergonomically, and we'll see purity annotations in TS and explicit passage of state objects around.
I feel like "not tending to companies needs for profits" is a way to elevate Haskell and monadic FP abstractions with appeal to conspiracy/(postmodern) ideology. I don't mean this to be a pro-or-anti capitalism sentiment, but the excuse here is that "in a more just/less captalist/<other> world, Haskell would be a great tool, but our flawed world makes it not so" and I disagree with that. I just don't think Haskell is that good of a tool regardless (and I see the Haskell community these days appealing to this take a lot, trying to blame anyone but themselves.)
I think that people genuinely don't derive much value from Haskell and monadic FP. My experience, having written and maintained non-production-grade Haskell code, has been that the community is obsessed with toys and small examples, derives a lot of pleasure from clever abstractions which don't materially affect development (like Lenses), and most importantly doesn't really care about shipping software. There's exceptions like SPJ and Joey Hess who definitely ship useful Haskell, but the community doesn't care nearly enough about making it easy to actually produce software that a non-Haskell enthusiast would care about using.
Libraries are often created for a Masters project and abandoned. Even if a library works, debugging edge cases is never thought of. Almost nothing is written about testing in Haskell. No two libraries can agree on which monad stack to use, so a non-trivial amount of integration code involves matching and lifting into other monads (nor the performance implications of doing all of this matching and lifting). There are very few examples of organizational patterns for Haskell codebases for folks trying to create a project other than GHC itself, Pandoc, and perhaps XMonad. The community loves talking about abstractions and unifying concepts but doesn't really seem to have any practical tips about writing software. The string types in the language are confusing and poorly differentiated. The cabal and stack split is confusing and makes no sense to outsiders. The weird cargo-cult obsession in the community about category theory from people with little formal mathematical knowledge is bizarre. I can go on and on, but I don't want to dunk on the language endlessly (and I can certainly do this to any language I've used in love or anger :)
Fundamentally I don't think Haskell offers the programmer much more than what you'd get out of a language like Rust, Java, or Go (yes even Go) as the GP said. It's a language with a lot of interesting concepts that's fun for folks who like to solve algebra problems and is certainly a clean introduction to monadic FP. I'm looking forward to a successor that takes its concepts, cleans them up, and offers a way to write actual software with them. Then again, Multicore Ocaml is landing soon...
The reason for that is that people who do haskell for a living are dwarfed by the hobbyist community which makes them invisible, and they're spread thin on maintaining the ecosystem. GHC, HLS and all the other good things there are are the work of people on their free time, while other, more successful languages simply have companies dedicating time, money and contracts to tooling.
All of that means that it's not easy to move from the hobbyist haskeller group to the paid haskeller group. Most people usually get there by getting hired in a place where the stack, library choices, etc. are made by people who had done haskell professionally before and have solved the problem you cite for the team.
Once you're in, the benefits of Haskell are tangible, otherwise people would stop using it, and there wouldn't be a professional community. That is not to say that there are no problems, it's just that they are different problems, and people that stick to haskell for their job usually do it as a tradeoff.
The tech itself really works well, but it required either an org mature enough to do the things correctly, or a shop purely focused on haskell that would accept the complexity.
Also, sometimes the library ecosystem is a bit lacking. It wasn't an immovable roadblock, but we did write stuff that may have been available as a lib in other languages. This was a minor impediment for us, but it can get bad in other contexts.
That's very true and the case at my job. We've taught people with 0 Haskell experience to write useful production code in under a month.
> Even if a library works, debugging edge cases is never thought of.
Many libraries use sum types to express their api which naturally leads one to consider edge cases.
> Almost nothing is written about testing in Haskell.
Yes there is! Did you verify your claim with a quick search? Here's what one gave me:
- https://mmhaskell.com/testing/test-driven-development
- https://jaspervdj.be/posts/2015-03-13-practical-testing-in-h...
Heck, here's one from 2007:
https://www.jasani.org/posts/2007/unit-testing-with-hunit-in...
It feels like this web of lies about Haskeller's not caring about real world concerns is being spun, but even with minimal effort that is trivial to disprove.
> No two libraries can agree on which monad stack to use,
The mtl library is the most used monad stack by far and it's not typical to see others very often.
> so a non-trivial amount of integration code involves matching and lifting into other monads (nor the performance implications of doing all of this matching and lifting).
I feel this may betray a lack of understanding because lifting between monad stacks is expected.
I agree there are performance implications on theory, but if you get out of the performance ivory tower you'll find it doesn't happen much in the real world ;)
Oh but they do materially affect development in the same type of way LINQ does for C# programmers.
https://youtube.com/watch?v=QZy4Yml3LTY
Then for a great book that gives a great understanding see Chris Penner's amazing and fun "Optics by example:
I don’t see how this is true. These common abstraction make reading code incredibly easy most of the time. Many Haskell libraries are based on compositional building blocks. Seeing a monoid, functor or monad instance gets you 90% there in understanding the usage. It’s really the superpower of Haskell that I miss (and badly reimplement) in every other PL.
Haskell usage in companies is currently niche at best. It's hard to know what you would consider reasonable use of the language if you believe it's currently overhyped. Maybe your idea of hype relies on conference talks or some other metric I don't get?
> in my personal opinion, you don't gain that much if you compare it to something like Rust, Java or even Go.
Rust is pretty similar to Haskell in terms of type system experience, the main difference being that, when you don't really care about how memory is used, Rust forces you to handle it. Any GC'd language will feel refreshing if you're annoyed by that. Aside from that, I don't challenge that Rust is a great language to program in.
Java's usability is built on a fundamentally different model: it benefits from decades of investment in IDEs, and all professional java users I know use it extensively. While a haskeller will rely on types to perform refactoring, a java dev will refactor using the IDE, with an equivalent peace of mind. Java's typesystem is poor, but it doesn't really matter in users' development experience.
I don't have much positive stuff to say about Go, and even less about its typesystem. You may find better advocates for this one.
> Lastly it's just incredible hard to estimate runtime characteristics
Most use cases don't care about that. You quoted Java earlier, a language in which most devs never ever really delve into runtime performance and simply let the runtime do its stuff. As it turns out, it's usually good enough.
It's quite surprising that aside from Fortran, C derivatives and Rust, no one gives a damn about performance, but when it's haskell, it suddenly becomes a problem.
> If Haskell is such an advanced language to make implementing reliable SW such a breeze
Is that some kind of strawman where if haskell doesn't deliver on being touted as the gift of God to programmers, then it's bad?
Yes, I'm referring to programmer circle related social networks (HN, r/programming, ...).
> It's quite surprising that aside from Fortran, C derivatives and Rust, no one gives a damn about performance, but when it's haskell, it suddenly becomes a problem.
Because performance problems are particularly hard to solve in Haskell due to its high level of abstraction.
> Is that some kind of strawman where if haskell doesn't deliver on being touted as the gift of God to programmers, then it's bad?
Yes, given the fact that it's praised to such a high degree, users might have extremely high expectations, but are likely to be underwhelmed if it does not solve their problems in a vastly superior way.
Does not match my experience. Haskell typically compiles to quite performant code, at least for all the cases that I’ve used it for.
Then few times I had to optimize anything for performance, it did not feel different than other languages. It was in almost every case about the architecture of the code and not something to do with the language itself.
> Yes, given the fact that it's praised to such a high degree, users might have extremely high expectations
May I suggest the problem is not with the language, then? As a fellow HNer that you can trust, I also have an extremely well-made bridge to sell you if you're interested.
> Because performance problems are particularly hard to solve in Haskell due to its high level of abstraction.
That doesn't match with my experience using the language. But again, how often do you have to solve performance issues that are more complex than a misplaced quadratic function in other languages? If it's frequent enough, wouldn't you consider using a language like rust or CPP rather than something like Java, Go or Python?
Why? This doesn't agree with my experience using Java or Go at all. Both languages have ways to reuse objects that significantly decrease GC pressure for bottlenecks to achieve competitive performance. Also anyone running net services at scale frequently runs into performance issues that are much more thorny than misplaced quadratic functions (are you deserializing JSON in a hot loop? is your HTTP connection pool too large? is your hash table too large, leading to significant collisions?)
Rust or C++ is overkill when reusing some objects, moving data structures, or memoizing some serde is all you need. Reasoning about them in Haskell can also be quite difficult, especially if you build a lazy chain of operations that leads to executing an expensive operation frequently in a hot loop, or forget to preallocate HTTP connections in a pool, or something like that. It's a high cost to pay for a better type system and awkwardly unifying abstractions.
I agree with that, but the consequence of these things is that developers don't have to care about it themselves. Thus these languages are usually good enough that optimization is not a concern for most devs in these ecosystems.
> (are you deserializing JSON in a hot loop? is your HTTP connection pool too large? is your hash table too large, leading to significant collisions?)
None of these things are language-related, though.
> Reasoning about them in Haskell can also be quite difficult
We didn't have specific trouble when this kind of problem came up, maybe your mileage is different ? Being used to it, it's kind of hard to understand what specifically you find hard in this.
And I spent way less time learning Go than learning Haskell.
...And you've got what you paid for.
I've read GHC assembly and it seems to be intentionally trying to run poorly - eg it calls everything through unpredictable function pointers. No, this isn't CPUs' fault, as GHC people do try to be optimal, they are just failing. jhc produced good code but isn't maintained afaik.
Author is not a "dev" nor a self-proclaimed "engineer". He has no computer science, maths, EE or physics degrees listed on his CV. He does list several languages. None are computer languages. He suggests the programs he has written may be "structured procrastination".
http://johnmacfarlane.net/macfarlane-cv.html
https://www.johnmacfarlane.net/BayHac2014/
https://usesthis.com/interviews/john.macfarlane/
I think Dhall looks interesting. Like MacFarlane, I am free to choose any language I find satisfying for procrastination purposes.
To piggy-back on this I'm a professional Haskell programmer with no degree and my math education stopped at shaky pre-calculus.
I'm not saying it's somehow magically more productive than other languages, because it's useless to throw around stuff you can't really prove like that, just some people find it to be the case.
I've never found "everyone writing their own DSL" to be problematic, because it's all exposed through the Monad/Applicative/Functor classes, so the way you use them are all very similar. Honestly, the usage of such eDSLs is one of my favourite parts of writing Haskell.
I use Haskell at my work for our main application, and we've been looking at adopting a style guide like https://kowainik.github.io/posts/2019-02-06-style-guide
And about interesting applications in Haskell, I'd consider https://hasura.io/ pretty interesting!
EDIT: And about language extensions, yeah, they can be a problem. What we do is settle on a base set of extensions, and if you want to use another one, you need to provide sufficient justification for it.
This is the opposite of my experience as a professional of many years. Most Haskellers I know think that this thing you're complaining about is extremely helpful, actually.
The fact that every library gives you shared instances for wildly different things makes them easier to use. If you give me an Applicative instance, I'll be able to use it in so many ways.
It's a shared abstraction language. No other PL compares.
At the end of the day, none of the languages you mention come close to being able build complicated programs out of smaller ones like Haskell can. It's all gunk, inherently.
I use my brain to write all those languages in an exhausting way. I barely do hard thinking with Haskell ever. Whether it be gamedev, web services, parsers .. I thank god every day I don't have to live like a normal programmer. My mind would be so tired.
I feel this. On slower days where I manage to eek out good productivity I joke that Haskell is the secret weapon of dumb and lazy people that managed to somehow not be lazy learning Haskell.
(I don't recommend it for production only because it has been partially abandoned, it seems, but it if hadn't been and the community had kept growing it would have been awesome).
I don't think your snarky section is that relevant, because it's hardly like the best technology wins. Software engineering has a bias towards either irrelevant nonsense to pad resumes or extreme conservatism.
Why do you say that?
Sure, there were some dramas around how the language/ecosystem should evolve and almost all external opinions are not considered. But again, you could argue that Elm is consistent because of this heavy handed approach to language design. I'm just wondering why you would consider it as `partially abandoned`.
The language itself is still mostly fine, so long as you don't run into its limitations. I still wouldn't recommend it going forward for the above reasons, though. Too many warning signs and contributor goodwill unnecessarily burnt. Evan is a perfectionist and clearly has no interest in developing a feature if he can't see the use case for it (his response to negative numbers in case..of expressions was a classic example).
Personally I think it's all a bit of a shame, Elm is one of my favourite things ever in web development. I really, really wanted/want it or something similar to succeed in terms of major projects being written in it.
This is an effort that takes best ideas from Elm. AFAIK, the creator was one of the high profile community members (or atleast a prolific Elm user).
I'm not sure how this language will pan out. There are too much options for UI development right now. Also, last when I checked, you have to buy in on this framework/lang completely and you had no option of plugging this in an existing project.
Still, I think Elm users may find this interesting.
TidalCycles would like to have a word with you. Easily one of the most interesting and unusual pieces of SW that currently exists.
If interesting and unusual is your thing for generative music, check out Orca[4]. That has eaten hours of my time far more than Tidal for me.
[1] http://commonmusic.sourceforge.net/
[2] https://extemporelang.github.io/
Even accepting the distinction (which I don't agree with) between "non RISC-y" ARM (v7 and earlier) and "RISC-y" (v8 and later), Apple M1 is "RISC-y" by that definition (instruction set ARMv8.5A)[1]. And it's doing well.
[1] Line 256 https://github.com/llvm/llvm-project/blob/main/llvm/include/...
It is more RISC than ARMv7 was. And I think if it was targeting smaller CPUs with less wide decoders, being more x86-like ("CISC") and having variable length instructions would be better.
Nix is implemented in C++, not Haskell
My school (UIUC) only just added a functional programming course to the CS course map in 2021. Of course you could always take a functional programming course if you wanted to, but not many do.
When you use it as a faster safer Python this almost never matters in the real world.
It's a good programming languages, but being "magnitudes better" is absolutely not true in my experience.
But it has one drawback that it's relatively slow to pack stuff to send between languages. On Python everything is so slow that this doesn't make much of a difference, but on the Haskell + Rust scenario you will want much larger library blocks.
Some languages have no implicit nullabillity and proper sum-types and exhausivity checks. This is what the main benefits of Haskell come from IMHO. Langs like Rust, Elm, OCaml/Reason/ReScript and Kotlin (even TypeScript) to some extend have this.
Go and Java dont have this, and I miss them every time I use these languages.
As to why it's not more popular? Well the entire industry caught OOP fever during Java's heyday, so platform holders pushed languages that were similar - see JavaScript, C#, Visual C++, etc... Now this paradigm has huge inertia, and smart software engineers are able to make it work (just about) anyway. In other words, an accident of history got us caught in a local minimum.
Things are shifting though. The most popular framework in the world in probably React, and it's a (pretty crummy) implementation of functional programming concepts. It's not hard to find OOP thought-leaders advocating for immutability, effect systems and so on. Implementation inheritance is going the way of the singleton.
I agree that Haskell in particular suffers from being lazy, which has genuine problems in practice.
- tooling is (used to be) bad
- compiler is hostile to new users
- even the simplest code is nigh undebuggable
- gotchas like foldl vs foldr due to lazy evaluation
Can you give one example of this?
Yeah, but with Haskell you have a usable healthy ecosystem for real world code now.
Lol, that is not how things work at all. An idea can be better and still be a minority. The imperative mindset has a lot of momentum.
Sure, it's nice to implement parsers/compilers in it (see ̶N̶̶̶i̶̶̶x̶̶̶, Elm, DHall) and it's to some extent popular for backend web development, but I don't think the strong static type system is such an advantage as advocates want you to believe.
Of course it's safer (and faster) than dynamic languages like Python (Ruby, JavaScript), but in my personal opinion, you don't gain that much if you compare it to something like Rust, Java or even Go.
In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries.
Furthermore it's still the case, that there's not much really interesting SW made in it. Some years ago you could argue, it's because of familiarity, but (static typed) functional programming is part of CS curricula for at least 10 to 20 years now.
Lastly it's just incredible hard to estimate runtime characteristics (clock-time, memory usage), because you never know which compiler optimizations kick in or not.
It's a nice language, but again, I don't think it's such a panacea as proponents often tell you.
And to be snarky: If Haskell is such an advanced language to make implementing reliable SW such a breeze, it should be part (maybe as a dependency) of more SW.
EDIT: Nix is implemented in C++ as correctly pointed out in a comment.