4 ms·

What scares me about Haskell is that it seems even people who used it extensively for a while call themselves "intermediate", and still find themselves in Haske

What scares me about Haskell is that it seems even people who used it extensively for a while call themselves "intermediate", and still find themselves in Haskell-shaped holes. If something breaks and I need to fix it now, I don't want to be fighting with a language that says, "no-o, no shortcuts, use a proper monad", or takes years to master to that level. Maybe I'm just missing the point.

lallysingh 6y ago
Ha! Try C++. Usually when someone calls themselves an expert they're either a fool or lying.
- gilmi 6y ago
  Reminds me of the Deep C slides https://www.slideshare.net/olvemaudal/deep-c/255 https://www.slideshare.net/olvemaudal/deep-c/255
- higerordermap 6y ago
  Stroustrup is what?
  - lallysingh 6y ago
    "Usually" and I stand by that.
thinkharderdev 6y ago
I'm not a Haskell user but am a Scala developer and it has the same sort of thing. But I think it is more about the culture than it is about the actual reality of the language. First, it is often a sort of humblebrag (as the kids say). I am using this language that is SO advanced that I am a mere intermediate after X years of development. Looks how smart I am for using it. That tends to lead people to dramatically over-estimate how hard it is to become productive in the language. Second, the emphasis on correctness means that the ecosystem goes to great lengths to explain how all the abstractions work internally and how they are grounded in Category Theory. In other ecosystems (such as Java) they seem to be more focused on talking about the interface and the practicalities of using a library. Spring is extremely complicated but you don't see much ink spilled explaining all the internal implementation details.
- mordae 6y ago
  It doesn't have to be a humble brag. Some language ecosystems tend to have a lot of DSLs in them. I consider myself intermediate in Haskell because I don't grok Lens. I also consider myself intermediate, because I often can't readily grok what are the compiler devs talking about when they discuss e.g. linear types. I consider myself a Python expert since I can follow PEPs and DSLs with ease. That doesn't mean that Python is a better language. It does not make the same value proposition.
- hocuspocus 6y ago
  I believe you can be fairly experienced and realize there are many parts of the language and its ecosystem that you don't completely understand. For instance in Scala, I've never written any macro or used something like Shapeless in depth. Spring is a good example too. I used it quite a bit in my junior years and felt like I would never come to master a framework that is so broad (and that felt over-engineered). This doesn't mean you cannot be productive using a subset of the language. There's a balance in what you should allow in a codebase being maintained by a team of varied skillset. Maybe Haskell is on the extreme end here, but the other way (like Python, JS, Go) is even worse in my opinion.
  - the_only_law 6y ago
    > Spring is a good example too. I used it quite a bit in my junior years and felt like I would never come to master a framework that is so broad (and that felt over-engineered). I still feel this way. I work on all kinds of weird / cool technologies on the side and I can’t imagine ever coming to call myself in expert on anything because I only use a subset to solve a problem.
mordae 6y ago
What you see is the result of the fact Haskell gives you expressiveness to build anything from a shed to a bridge or a sky scraper and people who adopt Haskell are curious by nature and thus go as deep as possible and try to build a small house taking air currents and earthquakes into the equation. Servant is very complex by itself. It's hard to tell at what scale it pays off. But it gives you more safety than other solutions. I would love to have the OP on my team, because they have the ambition to build reliable software and I can compromise with them. It's hard to compromise the other way around.
- bweitzman 6y ago
  I've used Haskell + Servant help reduce backwards compatibility issues with an iOS app depending on the API. We had Servant automatically generate OpenAPI specs from the API, and then diff them against the version in prod during CI testing. Certainly possible with other languages + frameworks, but I felt really confident relying on it to catch issues due to the strong type guarantees.
chriswarbo 6y ago
> What scares me about Haskell is that it seems even people who used it extensively for a while call themselves "intermediate" They're not so much talking about the language itself, but more about the way thing can be built in it. That's an open-ended problem, since Turing-complete languages let us use any computatable process. I might consider myself a 'Python expert', since I've used it for over a decade, written code at the CPython level, all the way up to the metaclass level, built many projects, written extensively about the language, critiqued and discussed proposed features, taught it to others, etc. Yet I wouldn't consider myself an expert in 'the way things can be built with Python'. For example, I can build Python wrappers for native binaries, but that doesn't imply that I'd come up with a design as clever as numpy. I've done a lot of statistical analysis using Python, but that doesn't mean I could come up with a library as elegant as pyro.ai. And so on. > If something breaks and I need to fix it now, I don't want to be fighting with a language that says, "no-o, no shortcuts, use a proper monad", or takes years to master to that level. What do you mean? System.IO.Unsafe.unsafePerformIO lets us write impure code; Unsafe.Coerce.unsafeCoerce lets us bypass the type system. Is there something else you'd want to do?
agentultra 6y ago
What scares me about C++ is that it seems even people who used it extensively for a while call themselves, "intermediate," and still find themselves in C++-shaped holes. If something breaks and I need to fix it now, I don't want to be fighting with a language that says, "it's fine to cast that pointer, don't worry about it," or takes years to master to that level. Maybe I'm just missing the point(er). You can repeat this argument for any X language you want. For me you want to work in a language that doesn't let you cut any corners by default. This is what Haskell and some other FP languages do. I can perform unsafe pointer operations in Haskell but it's going to be loud, noisy, and painful to write. As it should be! In languages like C++/Java/etc you have to be disciplined and opt-in to maintaining the kind of code that Haskell defaults to.
- rich_sasha 6y ago
  My point is, the gap between competence and expert knowledge seems to be much wider in C++ among others. I’m a pretty basic C++er but can use it effectively, if not efficiently. It seems, from the outside, in Haskell you need to know a lot more before even a basic level of effective use is possible.
  - agentultra 6y ago
    I can see that. The effect is pronounced if you're experienced in C++ (and C-like languages in general) and attempt to learn Haskell. There is almost no transferable knowledge from those kinds of languages to Haskell which means you're basically starting from the beginning. That can be infuriating for an experienced developer. It certainly was for me -- twenty-some years of programming knowledge that wasn't terribly useful at all! When moving from C++ to C# or Rust it's not as big a deal: there are the familiar concepts we can use to bridge the gap towards understanding the missing information. Haskell is just fundamentally different. Fortunately though I feel like the "Haskell cliff," is over-stated. The concepts you need to learn to get started and write useful programs is not as high as you might think. The ceiling, like in C++, is really high. Most mainstream languages have, or are planning to add in the next couple of years, all of those features you need when getting started with Haskell: ADTs, pattern matching, parametric and ad-hoc polymorphism, type inference, higher-order functions, and immutable values. So I think it depends on the code-base you're starting on and what you mean by effective use. If you're trying to contribute to a security analysis tools that uses a lot of type-level programming to encode specification invariants then you'll have a lot of learning to do before you can get started. If you're contributing to a SaaS web application then there's a good chance that only a "basic" level of knowledge about how to program with monads is all that will be required.

lallysingh 6y ago

Ha! Try C++. Usually when someone calls themselves an expert they're either a fool or lying.

gilmi 6y ago
Reminds me of the Deep C slides https://www.slideshare.net/olvemaudal/deep-c/255 https://www.slideshare.net/olvemaudal/deep-c/255
higerordermap 6y ago
Stroustrup is what?
- lallysingh 6y ago
  "Usually" and I stand by that.

thinkharderdev 6y ago

I'm not a Haskell user but am a Scala developer and it has the same sort of thing. But I think it is more about the culture than it is about the actual reality of the language. First, it is often a sort of humblebrag (as the kids say). I am using this language that is SO advanced that I am a mere intermediate after X years of development. Looks how smart I am for using it. That tends to lead people to dramatically over-estimate how hard it is to become productive in the language. Second, the emphasis on correctness means that the ecosystem goes to great lengths to explain how all the abstractions work internally and how they are grounded in Category Theory. In other ecosystems (such as Java) they seem to be more focused on talking about the interface and the practicalities of using a library. Spring is extremely complicated but you don't see much ink spilled explaining all the internal implementation details.

mordae 6y ago
It doesn't have to be a humble brag. Some language ecosystems tend to have a lot of DSLs in them. I consider myself intermediate in Haskell because I don't grok Lens. I also consider myself intermediate, because I often can't readily grok what are the compiler devs talking about when they discuss e.g. linear types. I consider myself a Python expert since I can follow PEPs and DSLs with ease. That doesn't mean that Python is a better language. It does not make the same value proposition.
hocuspocus 6y ago
I believe you can be fairly experienced and realize there are many parts of the language and its ecosystem that you don't completely understand. For instance in Scala, I've never written any macro or used something like Shapeless in depth. Spring is a good example too. I used it quite a bit in my junior years and felt like I would never come to master a framework that is so broad (and that felt over-engineered). This doesn't mean you cannot be productive using a subset of the language. There's a balance in what you should allow in a codebase being maintained by a team of varied skillset. Maybe Haskell is on the extreme end here, but the other way (like Python, JS, Go) is even worse in my opinion.
- the_only_law 6y ago
  > Spring is a good example too. I used it quite a bit in my junior years and felt like I would never come to master a framework that is so broad (and that felt over-engineered). I still feel this way. I work on all kinds of weird / cool technologies on the side and I can’t imagine ever coming to call myself in expert on anything because I only use a subset to solve a problem.

mordae 6y ago

What you see is the result of the fact Haskell gives you expressiveness to build anything from a shed to a bridge or a sky scraper and people who adopt Haskell are curious by nature and thus go as deep as possible and try to build a small house taking air currents and earthquakes into the equation. Servant is very complex by itself. It's hard to tell at what scale it pays off. But it gives you more safety than other solutions. I would love to have the OP on my team, because they have the ambition to build reliable software and I can compromise with them. It's hard to compromise the other way around.

bweitzman 6y ago
I've used Haskell + Servant help reduce backwards compatibility issues with an iOS app depending on the API. We had Servant automatically generate OpenAPI specs from the API, and then diff them against the version in prod during CI testing. Certainly possible with other languages + frameworks, but I felt really confident relying on it to catch issues due to the strong type guarantees.

chriswarbo 6y ago

> What scares me about Haskell is that it seems even people who used it extensively for a while call themselves "intermediate" They're not so much talking about the language itself, but more about the way thing can be built in it. That's an open-ended problem, since Turing-complete languages let us use any computatable process. I might consider myself a 'Python expert', since I've used it for over a decade, written code at the CPython level, all the way up to the metaclass level, built many projects, written extensively about the language, critiqued and discussed proposed features, taught it to others, etc. Yet I wouldn't consider myself an expert in 'the way things can be built with Python'. For example, I can build Python wrappers for native binaries, but that doesn't imply that I'd come up with a design as clever as numpy. I've done a lot of statistical analysis using Python, but that doesn't mean I could come up with a library as elegant as pyro.ai. And so on. > If something breaks and I need to fix it now, I don't want to be fighting with a language that says, "no-o, no shortcuts, use a proper monad", or takes years to master to that level. What do you mean? System.IO.Unsafe.unsafePerformIO lets us write impure code; Unsafe.Coerce.unsafeCoerce lets us bypass the type system. Is there something else you'd want to do?

agentultra 6y ago

What scares me about C++ is that it seems even people who used it extensively for a while call themselves, "intermediate," and still find themselves in C++-shaped holes. If something breaks and I need to fix it now, I don't want to be fighting with a language that says, "it's fine to cast that pointer, don't worry about it," or takes years to master to that level. Maybe I'm just missing the point(er). You can repeat this argument for any X language you want. For me you want to work in a language that doesn't let you cut any corners by default. This is what Haskell and some other FP languages do. I can perform unsafe pointer operations in Haskell but it's going to be loud, noisy, and painful to write. As it should be! In languages like C++/Java/etc you have to be disciplined and opt-in to maintaining the kind of code that Haskell defaults to.

rich_sasha 6y ago
My point is, the gap between competence and expert knowledge seems to be much wider in C++ among others. I’m a pretty basic C++er but can use it effectively, if not efficiently. It seems, from the outside, in Haskell you need to know a lot more before even a basic level of effective use is possible.
- agentultra 6y ago
  I can see that. The effect is pronounced if you're experienced in C++ (and C-like languages in general) and attempt to learn Haskell. There is almost no transferable knowledge from those kinds of languages to Haskell which means you're basically starting from the beginning. That can be infuriating for an experienced developer. It certainly was for me -- twenty-some years of programming knowledge that wasn't terribly useful at all! When moving from C++ to C# or Rust it's not as big a deal: there are the familiar concepts we can use to bridge the gap towards understanding the missing information. Haskell is just fundamentally different. Fortunately though I feel like the "Haskell cliff," is over-stated. The concepts you need to learn to get started and write useful programs is not as high as you might think. The ceiling, like in C++, is really high. Most mainstream languages have, or are planning to add in the next couple of years, all of those features you need when getting started with Haskell: ADTs, pattern matching, parametric and ad-hoc polymorphism, type inference, higher-order functions, and immutable values. So I think it depends on the code-base you're starting on and what you mean by effective use. If you're trying to contribute to a security analysis tools that uses a lot of type-level programming to encode specification invariants then you'll have a lot of learning to do before you can get started. If you're contributing to a SaaS web application then there's a good chance that only a "basic" level of knowledge about how to program with monads is all that will be required.