5 ms·

I think it's Haskell. I know sometimes it gets some hype but Haskell and its ilk is just so above the quality of any other language it's mind bending. Whenever

I think it's Haskell. I know sometimes it gets some hype but Haskell and its ilk is just so above the quality of any other language it's mind bending. Whenever a hard language design problem comes up in any new language, Haskell has solved it more than 2 decades ago. The ecosystem (Hackage etc) is pretty bad though.

howToLearnSpark 9y ago
that's so true. I woulnd't call it underrated though as it's pretty much one of the defacto starting programming languages universities use.
- maxiepoo 9y ago
  Where are you from that this is true? England? I think very few universities in the USA use Haskell in intro classes.
jjaredsimpson 9y ago
Haskell was the first language I learned that I actually loved in an irrational way. I consider myself to be a 3/10 haskeller because I've written a couple thousands lines, but never built anything "real" with it. But it is just such a beautiful experience to be writing it. It feels very much like a pit of success.
jstimpfle 9y ago
why is the ecosystem bad? While no metrics for "underrated" are proposed here, I would say, empirically Haskell does not seem like your go-to language if you want to develop useful and maintainable software.
- austenallred 9y ago
  Sounds a bit like a chicken and egg problem.
  - jstimpfle 9y ago
    It's not like the ecosystem is non-existent. At all. Only are most libraries really hard to use (IMHO), and they don't compose well (too many complicated types), have terrible compile times... The language might be elegant at the core, but it's too far removed from reality (efficiency on real computers is super hard to control from Haskell) and it's far too focused on types (which, while they catch some errors, slow development down, and encourage unnecessary complexity ("easier" and "more type-safe")). After all, it's an academic language.
  - sanderjd 9y ago
    But every language has that problem, and most mainstream languages overcome it. Why not Haskell? From an interested outsider's perspective, it seems like the community is focused more on ideas than on solutions. For me, this makes it endlessly intriguing (the ideas are interesting and often mind-bending) but not very useful (the solutions for the things I want to do appear under-developed).
ulrikrasmussen 9y ago
Stack (haskellstack.org) has pretty much solved the problems associated with building directly from Hackage though. The biggest pain when developing Haskell code continues to be the lack of good debugging facilities.
- js8 9y ago
  I am not really well versed in Haskell debugging, but a thought.. Current debuggers are built around very imperative notion of program state. I have breakpoints, I can look at variables (state in a given time).. What would debugging look like if we looked at it from the functional perspective? For example, execution "filters" instead of breakpoints. What happens if this function receives value that satisfies certain condition? Instead of variable watches, give out a breakdown of the data passed in and out from the function. Etc.
pka 9y ago
Yeah. Haskell is so imba people don't believe you when you tell them :) It's understandable to show skepticism about "the new shiny thing" (although Haskell is > 30 years old) because most new shiny things turn out to be not that great after all. I've been struggling to communicate the "no, but really" distinction without much success to other people and it's frustrating. (...for purely egoistical reasons though, I don't really care what people are using as long as I get to use a sane language in my day job, which is currently not the case.)
js8 9y ago
I agree, I think the diagram on page 12(?) of http://dev.stephendiehl.com/nearfuture.pdf http://dev.stephendiehl.com/nearfuture.pdf sums it up nicely. If you think this is smugness, look into it. The features that come up with GHC extensions have no equivalent in other languages, because the commonly used stuff in Haskell so far ahead.
saosebastiao 9y ago
Haskell hasn't solved GUI design, and it probably never will unless it comes up with a better way of modeling mutable state.
- js8 9y ago
  What about FRP? I haven't tried it but in theory it very much reminds me of Qt (which I think today would be called "reactive"), and the Qt was probably the most pleasurable GUI toolkit to write in. I think this has more to do with lack of polished UI editors (build tools) than with the language.
  - saosebastiao 9y ago
    All GUIs are "reactive", because all UIs (mechanical, analog, digital, whatever...) are abstracted state machines. And state machines are defined by the following formulate: state0 + event = effect + state1. You can't design a GUI without having a state and reacting to events. One could easily say that Qt was pleasurable because it was a well designed object-oriented and inheritance based toolkit. I have my reasons to believe this is objectively better within the context of UI design, and that pure functional programming in GUI design will never break out of it's magnificently tiny niche, but I'm not gonna go into that here. I'd rather just point out that some shared theoretical idea behind both Qt and Haskell UI design doesn't in any way imply that Qt's success could be Haskell's as well. Only Haskell programmers, working in Haskell code, could prove that idea. And if it really is that great, then surely they could do it.

howToLearnSpark 9y ago

that's so true. I woulnd't call it underrated though as it's pretty much one of the defacto starting programming languages universities use.

maxiepoo 9y ago
Where are you from that this is true? England? I think very few universities in the USA use Haskell in intro classes.

jjaredsimpson 9y ago

Haskell was the first language I learned that I actually loved in an irrational way. I consider myself to be a 3/10 haskeller because I've written a couple thousands lines, but never built anything "real" with it. But it is just such a beautiful experience to be writing it. It feels very much like a pit of success.

jstimpfle 9y ago

why is the ecosystem bad? While no metrics for "underrated" are proposed here, I would say, empirically Haskell does not seem like your go-to language if you want to develop useful and maintainable software.

austenallred 9y ago
Sounds a bit like a chicken and egg problem.
- jstimpfle 9y ago
  It's not like the ecosystem is non-existent. At all. Only are most libraries really hard to use (IMHO), and they don't compose well (too many complicated types), have terrible compile times... The language might be elegant at the core, but it's too far removed from reality (efficiency on real computers is super hard to control from Haskell) and it's far too focused on types (which, while they catch some errors, slow development down, and encourage unnecessary complexity ("easier" and "more type-safe")). After all, it's an academic language.
- sanderjd 9y ago
  But every language has that problem, and most mainstream languages overcome it. Why not Haskell? From an interested outsider's perspective, it seems like the community is focused more on ideas than on solutions. For me, this makes it endlessly intriguing (the ideas are interesting and often mind-bending) but not very useful (the solutions for the things I want to do appear under-developed).

ulrikrasmussen 9y ago

Stack (haskellstack.org) has pretty much solved the problems associated with building directly from Hackage though. The biggest pain when developing Haskell code continues to be the lack of good debugging facilities.

js8 9y ago
I am not really well versed in Haskell debugging, but a thought.. Current debuggers are built around very imperative notion of program state. I have breakpoints, I can look at variables (state in a given time).. What would debugging look like if we looked at it from the functional perspective? For example, execution "filters" instead of breakpoints. What happens if this function receives value that satisfies certain condition? Instead of variable watches, give out a breakdown of the data passed in and out from the function. Etc.

pka 9y ago

Yeah. Haskell is so imba people don't believe you when you tell them :) It's understandable to show skepticism about "the new shiny thing" (although Haskell is > 30 years old) because most new shiny things turn out to be not that great after all. I've been struggling to communicate the "no, but really" distinction without much success to other people and it's frustrating. (...for purely egoistical reasons though, I don't really care what people are using as long as I get to use a sane language in my day job, which is currently not the case.)

js8 9y ago

I agree, I think the diagram on page 12(?) of http://dev.stephendiehl.com/nearfuture.pdf http://dev.stephendiehl.com/nearfuture.pdf sums it up nicely. If you think this is smugness, look into it. The features that come up with GHC extensions have no equivalent in other languages, because the commonly used stuff in Haskell so far ahead.

saosebastiao 9y ago

Haskell hasn't solved GUI design, and it probably never will unless it comes up with a better way of modeling mutable state.

js8 9y ago
What about FRP? I haven't tried it but in theory it very much reminds me of Qt (which I think today would be called "reactive"), and the Qt was probably the most pleasurable GUI toolkit to write in. I think this has more to do with lack of polished UI editors (build tools) than with the language.
- saosebastiao 9y ago
  All GUIs are "reactive", because all UIs (mechanical, analog, digital, whatever...) are abstracted state machines. And state machines are defined by the following formulate: state0 + event = effect + state1. You can't design a GUI without having a state and reacting to events. One could easily say that Qt was pleasurable because it was a well designed object-oriented and inheritance based toolkit. I have my reasons to believe this is objectively better within the context of UI design, and that pure functional programming in GUI design will never break out of it's magnificently tiny niche, but I'm not gonna go into that here. I'd rather just point out that some shared theoretical idea behind both Qt and Haskell UI design doesn't in any way imply that Qt's success could be Haskell's as well. Only Haskell programmers, working in Haskell code, could prove that idea. And if it really is that great, then surely they could do it.