11 ms·

> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type

> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1! In contrast Haskell is often self-taught which gives a very different set of incentives and motivations. As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system is one of the most important part of my job and make the language very easy to use when you use an IDE which allows to click on an error and going to the right place in the code.

Blikkentrekker 6y ago
I learned both Haskell and Rust self-taught an still find the latter's type system a bit of a cage for it's lack of higher kinded types, frankness be. I know not much of Java, but my sentiments concerning C++ are even worse. I do not regularly program in Haskell and far more often in Rust.
- platinumrad 6y ago
  "I don't know much about this thing but I don't like it, and I know even less about this other thing and I like it even less!" For what it's worth, C++ has HKTs in the form of template template parameters, making it possible to write, e.g., monad transformers, which cannot be done in Rust, last I checked. Now as for whether you'd actually want to do this in a production codebase...
- marcosdumay 6y ago
  Rust metadata (not just types) have an habit of getting in your way. It is all for good reason, you can't ditch the GC and have control over the memory structure without the compiler complaining about details here and there. But fixing those strings versus slices and iterator type mistakes is really annoying.
js8 6y ago
Actually, the reason why I found static typing annoying in the past (and why I felt more productive in Python) were the types are really low level (missing basic things like tuples) and lack of type inference. You have to repeat the type information, a lot. And also you have to declare lot of intermediate data structures. In Python, this became easier and one could focus on the data transformations, thinking about the code a level higher. But then I learned a bit of Haskell 5 years ago, and with type inference, this problem goes away. So it convinced me back to benefits of static typing. (Although I still feel the most productive in Python, their library APIs are IMHO unmatched in any language. But Haskell is catching up.)
- jcelerier 6y ago
  > the types are really low level (missing basic things like tuples) and lack of type inference how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009
  - mjburgess 6y ago
    There's also the culture around the language to fold in. A culture of writing code assuming inference and structural typing is quite different than it merely being available.
    - sfg 6y ago
      So, OCaml or something? Or has Haskell added structural typing?
      - mjburgess 6y ago
        Haskell is structurally typed...
        tome 6y ago
        Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.
avl999 6y ago
> the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1! Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.
- bird_monster 6y ago
  > Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix. You cannot get mad at errors you don't know about. Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.
- ZephyrBlu 6y ago
  In my experience, you quickly develop an intuition for where things are going wrong with interpreted languages. Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object" Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.
  - cjfd 6y ago
    The thing is, though, that you mostly only get errors for code that is actually executed. So, your program is only fully type checked when all code paths are executed. In the case of python one can ameliorate this situation a bit by using mypy. At my job I see very often code being broken because, e.g., the signature of a function was changed but not in all places and so on. Now somebody will say that the IDE can solve that but these colleagues who are regularly breaking the code are actually using IDEs and it somehow still does not help. I have come to think that code that is not compiled and/or otherwise type checked is just not very serious and certainly not worthy of production environments.
corty 6y ago
Annoyance about C++ errors isn't only about the error occuring. With me, it is predominantly about the utter unusability of the error messages. C++ has postprocessors you can use to get your 20 page STL errors down to a few lines just by reversing the expansion the compiler did to show you mere mortal something that you might recognize as your code instead of template-cthulhu. Haskell has such situations as well, but usually far less verbose. Getting something to typecheck because you wrote down something incompatible uninferable still sucks. But far less than C++.
- Rompect 6y ago
  In contrast, Rust's compiler sometimes gives suggestions for changes which can often just be copied.
  - emteycz 6y ago
    That's not entirely true. It gives suggestions in the cases where the C++ compiler does too. There are more than a few very cryptic errors you can encounter with Rust. I like it though, just needs more work.
    - 3836293648 6y ago
      Depends on the compiler. In my very limited experience I've found that Clang is far superior to GCC in this matter (but rustc is better still, apart from iterator errors)
      - srean 6y ago
        I am curious about which GCC, G++ version you have in mind. Clang definitely took the lead, but by GCC caught up and I prefer GCC's do Clang. But even I am behind the bleeding edge quite a bit so not sure how things stand now.
    - leshow 6y ago
      It's been a while since I used C++ but I have never seen suggestions of the same quality that the rust compiler produces. Do you have a link that shows the error messages you're talking about? For sure though, not every error has a great message and some can be cryptic. But those cases are relatively rare these days IMO
slifin 6y ago
"acts as an invaluable pair-programming buddy that gives instantaneous feedback during development." This is the key bit, this is called static analysis, you don't need a type system in your language to do this, and you don't need to force doing it at compile time Most developers appear to conflate the two, uncoupling static analysis and type systems would benefit most workflows
- mrkeen 6y ago
  > you don't need to force doing it at compile time What assembly instructions should the compiler emit if you write sum ["foo", "bar"] ?
dsign 6y ago
Amen to that. I love dearly both C++ and Haskell, but I remember those times when I wanted to cry because the C++ error message broke the OS clipboard when I was trying to copy it to a text editor so that I could write a program to analyze it and find which "const" didn't match in the jungle of type names. I have never had that situation with Haskell.
- Vosporos 6y ago
  Oh dear :o
mlthoughts2018 6y ago
I find the compiler an annoyance in Haskell just as much as C++ - it just forces me to write more code (more liability) and leads to overly rigid type system designs, like modeling behavior with classes or traits/type classes. I’ve only found these ways of writing software to be universally worse than simple module-oriented programming, writing C-like code in languages like Python or Ruby and only selectively using C extensions for isolated cases where speed provably matters. Compilers do not offer compensating benefits, like catching bugs or ensuring behavioral correctness, that justify all the extra rigidity, slowness, and especially liability of all the extra code (even in Haskell).
cogman10 6y ago
I run into the same thing with Java. Code that always upsets me is something like `Map<String, Object>` where a concrete type would work so much better (and faster). Using a statically typed language, the most important thing you can do is USE IT. Let the type system save you from problems. Encode whatever you can in the types. Bypassing it by casting always causes headaches.
portal_narlish 6y ago
Strong point! As a non-CS engineering student learning C++ for the first time, the compiler all but turned me off from wanting to be a programmer. No one explained why the compiler was even there, it just seemed like an annoying hindrance stopping me from getting good grades on the homework. Fast forward a decade and I'm evangelizing statically typed FP at conferences. The value of the compiler is redeemed after self-teaching and learning the "Whys".
labawi 6y ago
> As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system .. When selecting a language for a recent project, that needed to run correctly, without extensive debugging that would be hard to simulate (too many states and interactions), I had a couple of important criteria: 0) checked static typing 1) ADTs (that are reasonably easy to use, read and write) 2) pattern matching (no way I'll get all the if/else right) 3) reasonably easy to write static const (pure functional) code 4) memory-safe I've considered rust, but settled on haskell, as I needed it fast and I know haskell. While technically any Turing-complete language would work, I don't think C++ would be a fit for must-work code, even disregarding (4). While I haven't used C++ in a while, it seems to me, encoding the constraints would be 3-10x as much code, or even more, with many checks/cracks left, and a lot of readability gone. Clean and correct functional haskell code took a bit longer to write than say happy-path imperative python, but after fixing 2 or so bugs that manifested on pretty much the first (partial) use (like incorrect "<" vs. ">" and a bad constant), it has been running happily ever since. I didn't even bother simulating a full system configuration before a real-world customer acceptance test, because components worked on 1-2 inputs I tried, setting up a system would take a couple of hours and I couldn't think of reasonable failure scenarios. I haven't experienced similar correctness in other languages.

Blikkentrekker 6y ago

I learned both Haskell and Rust self-taught an still find the latter's type system a bit of a cage for it's lack of higher kinded types, frankness be. I know not much of Java, but my sentiments concerning C++ are even worse. I do not regularly program in Haskell and far more often in Rust.

platinumrad 6y ago
"I don't know much about this thing but I don't like it, and I know even less about this other thing and I like it even less!" For what it's worth, C++ has HKTs in the form of template template parameters, making it possible to write, e.g., monad transformers, which cannot be done in Rust, last I checked. Now as for whether you'd actually want to do this in a production codebase...
marcosdumay 6y ago
Rust metadata (not just types) have an habit of getting in your way. It is all for good reason, you can't ditch the GC and have control over the memory structure without the compiler complaining about details here and there. But fixing those strings versus slices and iterator type mistakes is really annoying.

js8 6y ago

Actually, the reason why I found static typing annoying in the past (and why I felt more productive in Python) were the types are really low level (missing basic things like tuples) and lack of type inference. You have to repeat the type information, a lot. And also you have to declare lot of intermediate data structures. In Python, this became easier and one could focus on the data transformations, thinking about the code a level higher. But then I learned a bit of Haskell 5 years ago, and with type inference, this problem goes away. So it convinced me back to benefits of static typing. (Although I still feel the most productive in Python, their library APIs are IMHO unmatched in any language. But Haskell is catching up.)

jcelerier 6y ago
> the types are really low level (missing basic things like tuples) and lack of type inference how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009
- mjburgess 6y ago
  There's also the culture around the language to fold in. A culture of writing code assuming inference and structural typing is quite different than it merely being available.
  - sfg 6y ago
    So, OCaml or something? Or has Haskell added structural typing?
    - mjburgess 6y ago
      Haskell is structurally typed...
      - tome 6y ago
        Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.

avl999 6y ago

> the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1! Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.

bird_monster 6y ago
> Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix. You cannot get mad at errors you don't know about. Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.
ZephyrBlu 6y ago
In my experience, you quickly develop an intuition for where things are going wrong with interpreted languages. Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object" Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.
- cjfd 6y ago
  The thing is, though, that you mostly only get errors for code that is actually executed. So, your program is only fully type checked when all code paths are executed. In the case of python one can ameliorate this situation a bit by using mypy. At my job I see very often code being broken because, e.g., the signature of a function was changed but not in all places and so on. Now somebody will say that the IDE can solve that but these colleagues who are regularly breaking the code are actually using IDEs and it somehow still does not help. I have come to think that code that is not compiled and/or otherwise type checked is just not very serious and certainly not worthy of production environments.

corty 6y ago

Annoyance about C++ errors isn't only about the error occuring. With me, it is predominantly about the utter unusability of the error messages. C++ has postprocessors you can use to get your 20 page STL errors down to a few lines just by reversing the expansion the compiler did to show you mere mortal something that you might recognize as your code instead of template-cthulhu. Haskell has such situations as well, but usually far less verbose. Getting something to typecheck because you wrote down something incompatible uninferable still sucks. But far less than C++.

Rompect 6y ago
In contrast, Rust's compiler sometimes gives suggestions for changes which can often just be copied.
- emteycz 6y ago
  That's not entirely true. It gives suggestions in the cases where the C++ compiler does too. There are more than a few very cryptic errors you can encounter with Rust. I like it though, just needs more work.
  - 3836293648 6y ago
    Depends on the compiler. In my very limited experience I've found that Clang is far superior to GCC in this matter (but rustc is better still, apart from iterator errors)
    - srean 6y ago
      I am curious about which GCC, G++ version you have in mind. Clang definitely took the lead, but by GCC caught up and I prefer GCC's do Clang. But even I am behind the bleeding edge quite a bit so not sure how things stand now.
  - leshow 6y ago
    It's been a while since I used C++ but I have never seen suggestions of the same quality that the rust compiler produces. Do you have a link that shows the error messages you're talking about? For sure though, not every error has a great message and some can be cryptic. But those cases are relatively rare these days IMO

slifin 6y ago

"acts as an invaluable pair-programming buddy that gives instantaneous feedback during development." This is the key bit, this is called static analysis, you don't need a type system in your language to do this, and you don't need to force doing it at compile time Most developers appear to conflate the two, uncoupling static analysis and type systems would benefit most workflows

mrkeen 6y ago
> you don't need to force doing it at compile time What assembly instructions should the compiler emit if you write sum ["foo", "bar"] ?

dsign 6y ago

Amen to that. I love dearly both C++ and Haskell, but I remember those times when I wanted to cry because the C++ error message broke the OS clipboard when I was trying to copy it to a text editor so that I could write a program to analyze it and find which "const" didn't match in the jungle of type names. I have never had that situation with Haskell.

Vosporos 6y ago
Oh dear :o

mlthoughts2018 6y ago

I find the compiler an annoyance in Haskell just as much as C++ - it just forces me to write more code (more liability) and leads to overly rigid type system designs, like modeling behavior with classes or traits/type classes. I’ve only found these ways of writing software to be universally worse than simple module-oriented programming, writing C-like code in languages like Python or Ruby and only selectively using C extensions for isolated cases where speed provably matters. Compilers do not offer compensating benefits, like catching bugs or ensuring behavioral correctness, that justify all the extra rigidity, slowness, and especially liability of all the extra code (even in Haskell).

cogman10 6y ago

I run into the same thing with Java. Code that always upsets me is something like `Map<String, Object>` where a concrete type would work so much better (and faster). Using a statically typed language, the most important thing you can do is USE IT. Let the type system save you from problems. Encode whatever you can in the types. Bypassing it by casting always causes headaches.

portal_narlish 6y ago

Strong point! As a non-CS engineering student learning C++ for the first time, the compiler all but turned me off from wanting to be a programmer. No one explained why the compiler was even there, it just seemed like an annoying hindrance stopping me from getting good grades on the homework. Fast forward a decade and I'm evangelizing statically typed FP at conferences. The value of the compiler is redeemed after self-teaching and learning the "Whys".

labawi 6y ago

> As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system .. When selecting a language for a recent project, that needed to run correctly, without extensive debugging that would be hard to simulate (too many states and interactions), I had a couple of important criteria: 0) checked static typing 1) ADTs (that are reasonably easy to use, read and write) 2) pattern matching (no way I'll get all the if/else right) 3) reasonably easy to write static const (pure functional) code 4) memory-safe I've considered rust, but settled on haskell, as I needed it fast and I know haskell. While technically any Turing-complete language would work, I don't think C++ would be a fit for must-work code, even disregarding (4). While I haven't used C++ in a while, it seems to me, encoding the constraints would be 3-10x as much code, or even more, with many checks/cracks left, and a lot of readability gone. Clean and correct functional haskell code took a bit longer to write than say happy-path imperative python, but after fixing 2 or so bugs that manifested on pretty much the first (partial) use (like incorrect "<" vs. ">" and a bad constant), it has been running happily ever since. I didn't even bother simulating a full system configuration before a real-world customer acceptance test, because components worked on 1-2 inputs I tried, setting up a system would take a couple of hours and I couldn't think of reasonable failure scenarios. I haven't experienced similar correctness in other languages.