10 ms·

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language t

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming across from Haskell. I think the problem with Haskell as a language as a mainstream thing is that it requires a lot of upfront investment to get used to. C# -> Ruby is 10 hours to be productive, 100 hours to be reasonable. C# -> Haskell is ten times that. A lot of stuff to get your head around. There are complex topics from category theory to metaprograming. Sure you can ignore it - until you want to use a web framework that uses those concepts, then it's on you. Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. How do we make immutability easy and ergonomic and get rid of nulls in C#? Can we have guarantees in our program. There are even features not in Haskell proper like Liquid Haskell that would be interesting to have in C# or Typescript. This is what is needed if we want the Haskell ideas to be popular. That might not be what other people want.

cies 6y ago
> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). Also FB putting it weight behind Reason/OCaml clearly shows the movement. To be fair: sdiehl did mention in the preso that copying these concept over to other languages takes 10-20 years. > How do we make immutability easy and ergonomic and get rid of nulls in C#? The problem here is: you dont. To some extend you have to get these things right from the start. The father of null, Tony Hoare, now considers it his $1B mistake. Why? Because this is hard to fix. > Can we have guarantees in our program. Sure you can. C# gives you some typing guarantees. Now pattern matching switch statements (with exhaustivity checking) combined with sum types are coming: this will help! But the guarantees that Haskell (and Idris/Elm/PureScript) bring are next level, and impossible to replicate in a language that does not encode purity in the type system nor has type classes.
- lmm 6y ago
  > I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). But only at the most superficial level. It was heartbreaking to hear Kotlin ignore decades of Haskell and Scala experience when it couldn't be condensed into a 10-line example. They've adopted a fundamentally broken approach to representing absence and they'll regret it in 10 years, but it's already too late to fix it. Heck, look at Go ignoring Java's experience with not having generics.
  - cageface 6y ago
    What do you see as the deficiency of kotlin's handling of nulls?
    - lmm 6y ago
      Nested nullable types collapse to the same type, meaning it's very easy for generic code to contain really subtle bugs. If you have some generic code that has a T? and assumes that whenever it is null it is not T, this assumption will be almost correct and very easy to miss during testing. Also, it's very common to have option-style code and as your code evolves you need to refactor it to either/result-style code (that includes a reason why something was not present) - indeed I'd say this almost always happens in code that lives long enough. In kotlin this is unnecessarily difficult because it's impossible to write code that works with both nullable types and an either/result-like type, and since null has special language-level support you can't even use the same syntax.
      - mwcampbell 6y ago
        For me, there are two killer reasons for Kotlin to handle nullability as it does: smooth host platform interoperability and zero overhead. The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. And with some annotations, Kotlin's nullability support can be applied to those existing libraries. As for zero overhead, an Option or Optional is another object, and the overhead of that object can't be completely optimized away by the JIT. And both of these concerns apply to all of Kotlin's target platforms.
chrisseaton 6y ago
> Then there are language features in C# and Java, Typescript etc. that are coming across from Haskell. What language features in Java came from Haskell?
- quickthrower2 6y ago
  Stream API would be my first thought but I am not as familiar with Java. Maybe I should have said "ideas", I'm not sure there are any language level changes for Stream API.
  - chrisseaton 6y ago
    > Stream API would be my first thought but I am not as familiar with Java. Can you name any design characteristics in Java's stream API that came from Haskell, rather than were already common in many languages when Haskell itself was designed? I can't.
    - atombender 6y ago
      Java's "stream fusion" is inspired by the same technique that was originally implemented, I believe, in Haskell [1]. [1] http://fun.cs.tufts.edu/stream-fusion.pdf http://fun.cs.tufts.edu/stream-fusion.pdf
      - chrisseaton 6y ago
        But Java doesn't do stream fusion as you're describing. It does conventional inlining and combining loop bodies, which can in some trivial cases achieve the same effect, but these are techniques you'd find in any compiler or even an 80s text book - they didn't come from Haskell. Here's the limitation of Java's 'fusion' - you'll notice there's no pass to do this in Hotspot - it just happens due to the inlining and GCM passes. https://github.com/openjdk/jdk/blob/883a4f65b9b1533c8a51d156640020ae0f87f263/test/micro/org/openjdk/bench/java/util/stream/pipeline/PipelineParMultiple.java https://github.com/openjdk/jdk/blob/883a4f65b9b1533c8a51d156... And here's a paper on trying to add actual Fusion to Java, which they wouldn't be doing if Java had it already. https://dl.acm.org/doi/pdf/10.1145/3355378.3355386?download=true https://dl.acm.org/doi/pdf/10.1145/3355378.3355386?download=...
nightski 6y ago
I can't speak for everyone but for me the type system is not what made Haskell difficult. I loved it. What made it difficult was laziness. I'd find myself always trying to reason about execution (even though most of the time you probably shouldn't). Laziness might even be fine in a world built around it, but for a language to be practical it has to interface with systems that are not designed that way (numerous external libraries developed in strict languages). This isn't to say laziness is bad, or even worse - just that for a typical engineer switching from strict languages it's a large mental tax. The problem is while you can adapt and bolt on some functional programming techniques to existing languages like C# - to bring the power of the type system to an existing language is all but impossible. There are a few areas it has started to sneak in, like nullable types. But from my naive perspective you just can't bolt on an expessive type system like that, let alone a dependently typed one.
- tunesmith 6y ago
  Is laziness at all related to IO/effects libraries in Scala like cats-effect or zio? Like where you have to switch your mental model to view a program as something that just describes an eventual outcome but doesn't actually "do" it until some last-minute side effect thing that is bolted on?
  - lmm 6y ago
    In a lazy-by-default language (Haskell) you absolutely have to use those kind of approaches, because you can't write code where effects are important any other way. You have no control over evaluation order (other than dirty hacks), so you can't rely on that to control effect sequencing. Of course in a strict language with a decent type system like Scala you eventually find you want to use that style anyway. But you can come to it in your own time and see the benefits for yourself rather than having it forced on you.
- bcatanzaro 6y ago
  I felt that way too. I remember the first time I tried to make a lazy list of random numbers in Haskell. It didn't work because of course the random number generator is stateful which conflicts with laziness. It was a disappointing moment for sure.
nh2 6y ago
Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a project to know a wide array of libraries and feel ready to tackle almost anything. The companies involved were happy to make this time investment for increased productivity over the time they expected their employees to stay with them. On an individual level, it makes sense that if you're just getting into programming, and you have the choice between investing 2 weeks into Python to be productive, or 3 months for Haskell, you pick Python. It's rational. But after you've been in it for a few years, and you realise you want to do it for another 40 years, investing 3 months for life-long increased productivity (even if it's just a few percentage points; most feel the effect is larger) suddenly becomes a great deal. Counter point on "complex topics": After 6 years of industrial Haskell, I know nothing about category theory. It has not prevented me from using web frameworks.
- pydry 6y ago
  I've always been somewhat skeptical of Haskell due to the scarcity of things you could point to and say "that was made with Haskell and it made it so much better". it's usually the same 3 pieces of software people point to, none of which are particularly noteworthy. with rust, by contrast, which is ostensibly much less general purpose and hasn't been around as long there's already quite a collection and it's easy to see why it was chosen for those things.
  - JoelMcCracken 6y ago
    Haskell does have an issue of people using it being more interested in doing clever things and researching topics than building cool applications. Haskell jobs do exist, I have one of them. The big problem is that there are more people who want to do those jobs than there are jobs, so they seem very scarce. But anyway there are also a number of investment banks I have heard that use Haskell as their “secret weapon” and do not advertise it, in fact those who could speak to details are all under NDA. Personally I am hoping to help with this issue by building cool open source things in Haskell (and purescript) I was skeptical for years for all the reasons you said, but I finally decided to set my skepticism aside and see for myself, and oh boy is Haskell great. It has a lot of problems, but I consider myself at least 2x more productive in Haskell.
brianberns 6y ago
> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. How do we make immutability easy and ergonomic and get rid of nulls in C#? F# pretty much plays this role within the .NET ecosystem. Almost all of the important advancements in C# over the last few years originated in F# (and FP in general).
- xvilka 6y ago
  Almost all of F# features originated in OCaml, since F# is just a limited copy of OCaml.
lmm 6y ago
> A lot of stuff to get your head around. There are complex topics from category theory to metaprograming. Sure you can ignore it - until you want to use a web framework that uses those concepts, then it's on you. I'm convinced this is just FUD. Every language's main web framework has a bunch of complex concepts to learn - if you want to use Rails you're going to have to learn about ActiveRecord, metaclasses, whatever it is that rails uses for routing. By the time you've got productive in an enterprise-scale codebase, you've learnt just as much as if you were using Haskell - the only difference is that the knowledge is less transferable.
nine_k 6y ago
None of the languages that let you achieve certain top qualities (top performance, proven correctness, concurrency, compactness, etc) are trivial or "feel natural". Haskell, Rust, APL / K / Q, Erlang, hell, even C++ and Scala (though these two are unnecessarily bloated). You got to study and internalize concepts that underlie them, change your way of thinking. This is because reality is not intuitive, too. Take natural numbers. They are utterly intuitive. Three-year-olds can grasp them. But as you try to calculate more and more complex things in the real world, you discover the need in counter-intuitive concepts like zero, negative numbers, fractions, even the aptly named irrational numbers. If you try to calculate √3 using the intuitive natural numbers, your solution will be rather approximate. Same thing with many "intuitive" languages, from Basic-80 to ES6. You can solve a number of problems with them, but many solutions end up inexact and full of holes. In a lot of cases, this is acceptable, or seen as acceptable. But when you need tools for a precise solution, you have to study some "advanced concepts" (another word for math) and take a language like Haskell which support them. Sometimes you end up with something as unwieldy as your average three-story analytic formula, but this is often not a shortcoming of the language but the nature of your problem domain, described correctly.
- Smaug123 6y ago
  I'd definitely argue that no language ever will "feel natural" unless it fundamentally changes the metaphors of computation. Humans just don't think in sufficiently "hard-boundary" terms for programming as currently phrased to come naturally. Granted, culture has made up for a lot of that - in the UK, children are expected to be able to perform arithmetic, which presumably helps a lot in instilling the appropriate style of yes-no exact thinking - but I don't think the programming mindset aligns well at all to what was in the ancestral environment. Our minds are classifying machines built to do Just Well Enough in a world where everything is shades of grey; programming is the art of making the world concretely align to a well-specified model.
  - xamuel 6y ago
    When we tell a person to do something, we always give them some freedom in how to do it. When we tell a computer to do something, we don't. If one were to instruct a human being to go to the grocery store in absolutely full micromanaged detail, it would look equally unnatural ("Lift your right knee. Swing your right foot forward. Put down your right foot...") Sort of like that videogame QWOP.
kccqzy 6y ago
> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I feel like that's what the Scala people are doing. Yet the end result is that this kind of Scala code is just as slow to compile as Haskell, and just as hard to learn for newcomers as Haskell. The difficulty lies in the concepts enabled by the language, not the language itself. Go read the GHC user guide, especially the part about language extensions, and you'll finish in an afternoon. Yet people are always coming up with new ideas and abstractions that use these language features in new ways. Haskell is an especially rich platform for new ideas and abstractions to foster. Lens is somewhat difficult to learn, yet in its simplest form it can even be used without any language extensions. (You won't be able to name the Lens or Traversal type itself without RankNTypes, but you just need to expand the synonyms; in other words it's just sugar.)
travisgriggs 6y ago
I'll respect your opinion but sign up for the "not what other people want" crowd. I started learning Haskell last week. I have a small rest service I need to write and I want to try something new. Why Haskell? Because I miss seeing excellence/purity in computer languages. Nearly 10 years ago I jumped out of the Smalltalk balloon. It was one of the only languages where Object Oriented felt like a paradigm shift (CLOS and Self were also purist and paradigmy). It was sadly headed for the pile of lost languages. I have spent the last many years polyglotting, learning and plying Python, Ruby, Objective C, some C++, Kotlin, Swift, Dart (both 1 and 2), Lua, Go, and even a smattering of JavaScript (plus coffee script). It's been a journey through language populism. Language features pulled from multiple disciplines and mashed together with no real rhyme or reason other than what crowd or favorite feature the steering committees cater to at any given point. Consistency and guiding principles seem to be a thing of the past. I'm too new/naive on the Haskell journey to know what lies ahead. I've discerned that it seems to be one of the golden standards of "pure functional" paradigm. And at 49, I may be too old to be enlightened by another paradigm shift. But what I yearn for is computer languages that feel like the design elements all work together so that the whole is greater than the sum of the parts, instead of languages with a checklist of "good ideas" that thrown together create a whole that is lesser than the sums of their features. Will Haskell take me there? Time will tell. Wish me luck.
- acomar 6y ago
  there's a moment with the language where you go from trying to do things the way you would have done them in another language and instead, your brain adapts, and you learn to do them the functional way. because it's Haskell, you learn that you can quickly simplify things -- a little glue, a better understanding of the various functions you can pull out from the standard library, etc. -- and something that seemed incredibly complex reduces (like, for a very strong definition of like, algebra) to a few simple terms. many parts of the language come together and make it all click in this way: the syntax, the automatic currying of functions, the purity, and the type system. you start to look at all code differently. you start to see it as a bunch of puzzle pieces that can be fit together just so. and when you go back to try and use something else, you find yourself reflexively reaching for tools that aren't there, or that, removed from their original context, no longer have the support that made them quite so useful or so pleasant in Haskell. you even feel it going to other functional languages -- sticking all these parantheses into this lisp is obscuring the simple details, the puzzle pieces extended with decoration that makes them fit together less well. i don't mean to suggest Haskell is without flaws. but i do think you'll experience the paradigm shift as something concrete. there are almost no languages like it, after all.
jakequade 6y ago
I love haskell, but personally don't want haskell ideas to be popular until they're possible for a given language. Yes, lazy evaluation and tail-call recursion are awesome... At least they are in haskell. Outside of haskell, it's just a fun trivia fact that some other language does it.
- Smaug123 6y ago
  I've got a blog post in the oven about tail-call recursion and how to use it in F# to write your loops more safely. By using recursive (possibly side-effectful) functions instead of iteration, you make the decision about "whether or not to loop" explicit in code, making it much harder to make e.g. certain classes of off-by-one errors. When it's an explicit decision to loop, by calling yourself with an amended immutable state parameter, it often sticks out like a sore thumb when you loop wrongly (e.g. by forgetting to update your state, or by looping one too many times).
namelosw 6y ago
> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I believe Scala is already such a language. > There are even features not in Haskell proper like Liquid Haskell that would be interesting to have in C# or Typescript. There are many advanced type system feature are very hard or mathematically impossible to implement in main stream languages. The reason Haskell can maintain its novelty is due to purist and minimalist approach on many aspect of the language. For example, Hindley-Milner languages cannot add sub-typing. But it can easily infer the type of parameters and the return type of the recursive function, while Scala cannot despite the fact it's very advanced. > C# -> Ruby is 10 hours to be productive, 100 hours to be reasonable. C# -> Haskell is ten times that. > would be interesting to have in C# or TypeScript While I tend to agree, there are also many teams are also burnt by these languages because multiple paradigm actually makes things even harder. It's easy to be productive, but as people climbing the tower of advanced type, the code diverse, the idioms people speak diverse, too. It's not as easy as we thought to be reasonable. There are also many people in Scala community eventually found out it's better to just use the functional part only rather than mix everything.
- mratsim 6y ago
  > For example, Hindley-Milner languages cannot add sub-typing Subtyping? Haskell has ADTs.
  - namelosw 6y ago
    ADT cannot be extended. Maybe I should say Algorithm W instead of Hindley-Milner languages - Haskell added extensibility via Type Classes.
marcosdumay 6y ago
> How do we make immutability easy and ergonomic and get rid of nulls in C#? Can we have guarantees in our program. There are even features not in Haskell proper like Liquid Haskell that would be interesting to have in C# or Typescript. Will any of that be enough to bring the refactoring powers of Haskell? I bet not, you need the entire type system for that, and if you bring the entire type system, your language will become as hard to learn as Haskell. Without the refactoring powers, you are stuck again into the old school "design it well or you'll suffer" development cycle.

cies 6y ago

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). Also FB putting it weight behind Reason/OCaml clearly shows the movement. To be fair: sdiehl did mention in the preso that copying these concept over to other languages takes 10-20 years. > How do we make immutability easy and ergonomic and get rid of nulls in C#? The problem here is: you dont. To some extend you have to get these things right from the start. The father of null, Tony Hoare, now considers it his $1B mistake. Why? Because this is hard to fix. > Can we have guarantees in our program. Sure you can. C# gives you some typing guarantees. Now pattern matching switch statements (with exhaustivity checking) combined with sum types are coming: this will help! But the guarantees that Haskell (and Idris/Elm/PureScript) bring are next level, and impossible to replicate in a language that does not encode purity in the type system nor has type classes.

lmm 6y ago
> I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). But only at the most superficial level. It was heartbreaking to hear Kotlin ignore decades of Haskell and Scala experience when it couldn't be condensed into a 10-line example. They've adopted a fundamentally broken approach to representing absence and they'll regret it in 10 years, but it's already too late to fix it. Heck, look at Go ignoring Java's experience with not having generics.
- cageface 6y ago
  What do you see as the deficiency of kotlin's handling of nulls?
  - lmm 6y ago
    Nested nullable types collapse to the same type, meaning it's very easy for generic code to contain really subtle bugs. If you have some generic code that has a T? and assumes that whenever it is null it is not T, this assumption will be almost correct and very easy to miss during testing. Also, it's very common to have option-style code and as your code evolves you need to refactor it to either/result-style code (that includes a reason why something was not present) - indeed I'd say this almost always happens in code that lives long enough. In kotlin this is unnecessarily difficult because it's impossible to write code that works with both nullable types and an either/result-like type, and since null has special language-level support you can't even use the same syntax.
    - mwcampbell 6y ago
      For me, there are two killer reasons for Kotlin to handle nullability as it does: smooth host platform interoperability and zero overhead. The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. And with some annotations, Kotlin's nullability support can be applied to those existing libraries. As for zero overhead, an Option or Optional is another object, and the overhead of that object can't be completely optimized away by the JIT. And both of these concerns apply to all of Kotlin's target platforms.

chrisseaton 6y ago

> Then there are language features in C# and Java, Typescript etc. that are coming across from Haskell. What language features in Java came from Haskell?

quickthrower2 6y ago
Stream API would be my first thought but I am not as familiar with Java. Maybe I should have said "ideas", I'm not sure there are any language level changes for Stream API.
- chrisseaton 6y ago
  > Stream API would be my first thought but I am not as familiar with Java. Can you name any design characteristics in Java's stream API that came from Haskell, rather than were already common in many languages when Haskell itself was designed? I can't.
  - atombender 6y ago
    Java's "stream fusion" is inspired by the same technique that was originally implemented, I believe, in Haskell [1]. [1] http://fun.cs.tufts.edu/stream-fusion.pdf http://fun.cs.tufts.edu/stream-fusion.pdf
    - chrisseaton 6y ago
      But Java doesn't do stream fusion as you're describing. It does conventional inlining and combining loop bodies, which can in some trivial cases achieve the same effect, but these are techniques you'd find in any compiler or even an 80s text book - they didn't come from Haskell. Here's the limitation of Java's 'fusion' - you'll notice there's no pass to do this in Hotspot - it just happens due to the inlining and GCM passes. https://github.com/openjdk/jdk/blob/883a4f65b9b1533c8a51d156640020ae0f87f263/test/micro/org/openjdk/bench/java/util/stream/pipeline/PipelineParMultiple.java https://github.com/openjdk/jdk/blob/883a4f65b9b1533c8a51d156... And here's a paper on trying to add actual Fusion to Java, which they wouldn't be doing if Java had it already. https://dl.acm.org/doi/pdf/10.1145/3355378.3355386?download=true https://dl.acm.org/doi/pdf/10.1145/3355378.3355386?download=...

nightski 6y ago

I can't speak for everyone but for me the type system is not what made Haskell difficult. I loved it. What made it difficult was laziness. I'd find myself always trying to reason about execution (even though most of the time you probably shouldn't). Laziness might even be fine in a world built around it, but for a language to be practical it has to interface with systems that are not designed that way (numerous external libraries developed in strict languages). This isn't to say laziness is bad, or even worse - just that for a typical engineer switching from strict languages it's a large mental tax. The problem is while you can adapt and bolt on some functional programming techniques to existing languages like C# - to bring the power of the type system to an existing language is all but impossible. There are a few areas it has started to sneak in, like nullable types. But from my naive perspective you just can't bolt on an expessive type system like that, let alone a dependently typed one.

tunesmith 6y ago
Is laziness at all related to IO/effects libraries in Scala like cats-effect or zio? Like where you have to switch your mental model to view a program as something that just describes an eventual outcome but doesn't actually "do" it until some last-minute side effect thing that is bolted on?
- lmm 6y ago
  In a lazy-by-default language (Haskell) you absolutely have to use those kind of approaches, because you can't write code where effects are important any other way. You have no control over evaluation order (other than dirty hacks), so you can't rely on that to control effect sequencing. Of course in a strict language with a decent type system like Scala you eventually find you want to use that style anyway. But you can come to it in your own time and see the benefits for yourself rather than having it forced on you.
bcatanzaro 6y ago
I felt that way too. I remember the first time I tried to make a lazy list of random numbers in Haskell. It didn't work because of course the random number generator is stateful which conflicts with laziness. It was a disappointing moment for sure.

nh2 6y ago

Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a project to know a wide array of libraries and feel ready to tackle almost anything. The companies involved were happy to make this time investment for increased productivity over the time they expected their employees to stay with them. On an individual level, it makes sense that if you're just getting into programming, and you have the choice between investing 2 weeks into Python to be productive, or 3 months for Haskell, you pick Python. It's rational. But after you've been in it for a few years, and you realise you want to do it for another 40 years, investing 3 months for life-long increased productivity (even if it's just a few percentage points; most feel the effect is larger) suddenly becomes a great deal. Counter point on "complex topics": After 6 years of industrial Haskell, I know nothing about category theory. It has not prevented me from using web frameworks.

pydry 6y ago
I've always been somewhat skeptical of Haskell due to the scarcity of things you could point to and say "that was made with Haskell and it made it so much better". it's usually the same 3 pieces of software people point to, none of which are particularly noteworthy. with rust, by contrast, which is ostensibly much less general purpose and hasn't been around as long there's already quite a collection and it's easy to see why it was chosen for those things.
- JoelMcCracken 6y ago
  Haskell does have an issue of people using it being more interested in doing clever things and researching topics than building cool applications. Haskell jobs do exist, I have one of them. The big problem is that there are more people who want to do those jobs than there are jobs, so they seem very scarce. But anyway there are also a number of investment banks I have heard that use Haskell as their “secret weapon” and do not advertise it, in fact those who could speak to details are all under NDA. Personally I am hoping to help with this issue by building cool open source things in Haskell (and purescript) I was skeptical for years for all the reasons you said, but I finally decided to set my skepticism aside and see for myself, and oh boy is Haskell great. It has a lot of problems, but I consider myself at least 2x more productive in Haskell.

brianberns 6y ago

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. How do we make immutability easy and ergonomic and get rid of nulls in C#? F# pretty much plays this role within the .NET ecosystem. Almost all of the important advancements in C# over the last few years originated in F# (and FP in general).

xvilka 6y ago
Almost all of F# features originated in OCaml, since F# is just a limited copy of OCaml.

lmm 6y ago

> A lot of stuff to get your head around. There are complex topics from category theory to metaprograming. Sure you can ignore it - until you want to use a web framework that uses those concepts, then it's on you. I'm convinced this is just FUD. Every language's main web framework has a bunch of complex concepts to learn - if you want to use Rails you're going to have to learn about ActiveRecord, metaclasses, whatever it is that rails uses for routing. By the time you've got productive in an enterprise-scale codebase, you've learnt just as much as if you were using Haskell - the only difference is that the knowledge is less transferable.

nine_k 6y ago

None of the languages that let you achieve certain top qualities (top performance, proven correctness, concurrency, compactness, etc) are trivial or "feel natural". Haskell, Rust, APL / K / Q, Erlang, hell, even C++ and Scala (though these two are unnecessarily bloated). You got to study and internalize concepts that underlie them, change your way of thinking. This is because reality is not intuitive, too. Take natural numbers. They are utterly intuitive. Three-year-olds can grasp them. But as you try to calculate more and more complex things in the real world, you discover the need in counter-intuitive concepts like zero, negative numbers, fractions, even the aptly named irrational numbers. If you try to calculate √3 using the intuitive natural numbers, your solution will be rather approximate. Same thing with many "intuitive" languages, from Basic-80 to ES6. You can solve a number of problems with them, but many solutions end up inexact and full of holes. In a lot of cases, this is acceptable, or seen as acceptable. But when you need tools for a precise solution, you have to study some "advanced concepts" (another word for math) and take a language like Haskell which support them. Sometimes you end up with something as unwieldy as your average three-story analytic formula, but this is often not a shortcoming of the language but the nature of your problem domain, described correctly.

Smaug123 6y ago
I'd definitely argue that no language ever will "feel natural" unless it fundamentally changes the metaphors of computation. Humans just don't think in sufficiently "hard-boundary" terms for programming as currently phrased to come naturally. Granted, culture has made up for a lot of that - in the UK, children are expected to be able to perform arithmetic, which presumably helps a lot in instilling the appropriate style of yes-no exact thinking - but I don't think the programming mindset aligns well at all to what was in the ancestral environment. Our minds are classifying machines built to do Just Well Enough in a world where everything is shades of grey; programming is the art of making the world concretely align to a well-specified model.
- xamuel 6y ago
  When we tell a person to do something, we always give them some freedom in how to do it. When we tell a computer to do something, we don't. If one were to instruct a human being to go to the grocery store in absolutely full micromanaged detail, it would look equally unnatural ("Lift your right knee. Swing your right foot forward. Put down your right foot...") Sort of like that videogame QWOP.

kccqzy 6y ago

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I feel like that's what the Scala people are doing. Yet the end result is that this kind of Scala code is just as slow to compile as Haskell, and just as hard to learn for newcomers as Haskell. The difficulty lies in the concepts enabled by the language, not the language itself. Go read the GHC user guide, especially the part about language extensions, and you'll finish in an afternoon. Yet people are always coming up with new ideas and abstractions that use these language features in new ways. Haskell is an especially rich platform for new ideas and abstractions to foster. Lens is somewhat difficult to learn, yet in its simplest form it can even be used without any language extensions. (You won't be able to name the Lens or Traversal type itself without RankNTypes, but you just need to expand the synonyms; in other words it's just sugar.)

travisgriggs 6y ago

I'll respect your opinion but sign up for the "not what other people want" crowd. I started learning Haskell last week. I have a small rest service I need to write and I want to try something new. Why Haskell? Because I miss seeing excellence/purity in computer languages. Nearly 10 years ago I jumped out of the Smalltalk balloon. It was one of the only languages where Object Oriented felt like a paradigm shift (CLOS and Self were also purist and paradigmy). It was sadly headed for the pile of lost languages. I have spent the last many years polyglotting, learning and plying Python, Ruby, Objective C, some C++, Kotlin, Swift, Dart (both 1 and 2), Lua, Go, and even a smattering of JavaScript (plus coffee script). It's been a journey through language populism. Language features pulled from multiple disciplines and mashed together with no real rhyme or reason other than what crowd or favorite feature the steering committees cater to at any given point. Consistency and guiding principles seem to be a thing of the past. I'm too new/naive on the Haskell journey to know what lies ahead. I've discerned that it seems to be one of the golden standards of "pure functional" paradigm. And at 49, I may be too old to be enlightened by another paradigm shift. But what I yearn for is computer languages that feel like the design elements all work together so that the whole is greater than the sum of the parts, instead of languages with a checklist of "good ideas" that thrown together create a whole that is lesser than the sums of their features. Will Haskell take me there? Time will tell. Wish me luck.

acomar 6y ago
there's a moment with the language where you go from trying to do things the way you would have done them in another language and instead, your brain adapts, and you learn to do them the functional way. because it's Haskell, you learn that you can quickly simplify things -- a little glue, a better understanding of the various functions you can pull out from the standard library, etc. -- and something that seemed incredibly complex reduces (like, for a very strong definition of like, algebra) to a few simple terms. many parts of the language come together and make it all click in this way: the syntax, the automatic currying of functions, the purity, and the type system. you start to look at all code differently. you start to see it as a bunch of puzzle pieces that can be fit together just so. and when you go back to try and use something else, you find yourself reflexively reaching for tools that aren't there, or that, removed from their original context, no longer have the support that made them quite so useful or so pleasant in Haskell. you even feel it going to other functional languages -- sticking all these parantheses into this lisp is obscuring the simple details, the puzzle pieces extended with decoration that makes them fit together less well. i don't mean to suggest Haskell is without flaws. but i do think you'll experience the paradigm shift as something concrete. there are almost no languages like it, after all.

jakequade 6y ago

I love haskell, but personally don't want haskell ideas to be popular until they're possible for a given language. Yes, lazy evaluation and tail-call recursion are awesome... At least they are in haskell. Outside of haskell, it's just a fun trivia fact that some other language does it.

Smaug123 6y ago
I've got a blog post in the oven about tail-call recursion and how to use it in F# to write your loops more safely. By using recursive (possibly side-effectful) functions instead of iteration, you make the decision about "whether or not to loop" explicit in code, making it much harder to make e.g. certain classes of off-by-one errors. When it's an explicit decision to loop, by calling yourself with an amended immutable state parameter, it often sticks out like a sore thumb when you loop wrongly (e.g. by forgetting to update your state, or by looping one too many times).

namelosw 6y ago

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I believe Scala is already such a language. > There are even features not in Haskell proper like Liquid Haskell that would be interesting to have in C# or Typescript. There are many advanced type system feature are very hard or mathematically impossible to implement in main stream languages. The reason Haskell can maintain its novelty is due to purist and minimalist approach on many aspect of the language. For example, Hindley-Milner languages cannot add sub-typing. But it can easily infer the type of parameters and the return type of the recursive function, while Scala cannot despite the fact it's very advanced. > C# -> Ruby is 10 hours to be productive, 100 hours to be reasonable. C# -> Haskell is ten times that. > would be interesting to have in C# or TypeScript While I tend to agree, there are also many teams are also burnt by these languages because multiple paradigm actually makes things even harder. It's easy to be productive, but as people climbing the tower of advanced type, the code diverse, the idioms people speak diverse, too. It's not as easy as we thought to be reasonable. There are also many people in Scala community eventually found out it's better to just use the functional part only rather than mix everything.

mratsim 6y ago
> For example, Hindley-Milner languages cannot add sub-typing Subtyping? Haskell has ADTs.
- namelosw 6y ago
  ADT cannot be extended. Maybe I should say Algorithm W instead of Hindley-Milner languages - Haskell added extensibility via Type Classes.

marcosdumay 6y ago

> How do we make immutability easy and ergonomic and get rid of nulls in C#? Can we have guarantees in our program. There are even features not in Haskell proper like Liquid Haskell that would be interesting to have in C# or Typescript. Will any of that be enough to bring the refactoring powers of Haskell? I bet not, you need the entire type system for that, and if you bring the entire type system, your language will become as hard to learn as Haskell. Without the refactoring powers, you are stuck again into the old school "design it well or you'll suffer" development cycle.