53 ms·

Reading articles like this makes me want to avoid Haskell. It seems like the language is so over-complicated that it requires developers to invent an entire re

Reading articles like this makes me want to avoid Haskell. It seems like the language is so over-complicated that it requires developers to invent an entire religion to be able to effectively apply it to real world use cases. From the perspective of a non-Haskell coder who worked with many different mainstream languages, I find that many articles written about Haskell, Erlang and Elixir seem to have no meaning outside of their own narrow domain; they try to present some solutions as some universal insight which is applicable to all languages. In fact, they seem to revolve around solving problems which the language itself created and only exist in that language. I like languages which stay out of my way and don't create any new problems or require inventing unnecessary abstractions and ideology (my OOP philosophy is so simple, I could explain it to a 10 year old). I can't believe that you would need several articles to explain to developers how to do something as trivial as validation. It's not rocket science (...well it shouldn't be). In the communities I participate in, most developers seem to intuitively know how to do validation... There are multiple ways to do it. You just have to think a bit to figure out which way is the best for your project. A lot of these trendy languages seem to be on a futile mission to try to automate away some of the complexity of building software. Building software is irreducibly complex because there are always going to be a huge number of possibilities at every step; this is because the real world (which software tries to model) is complex, always more complex than it seems. That's why I like simple expressive languages which stay out of my way. Any tool which constrains my thinking into specific narrow patterns is going to make my work harder and more error-prone, not easier.

golemiprague 6y ago
What do you mean by simple expressive language that stay out of your way? Every language has some concepts and assumptions and abstractions and certain ways to model this complicated world. Can you give some concrete example and explain why?
reuben364 6y ago
Reading articles like this make me want to avoid OOP. It seems that like the concept is so over-complicated that it requires developers to invent an entire religion to be able to effectively apply it to real world use cases...( my procedural philosophy is so simple, I could explain it to a 10 year old). There are many ways to build software, but only few ways to build it reliably. One major aspect of reliable software is composability, so that may ensure correct large systems are out of correct smaller systems. Correctness in the small, trivial bits and their glue is what makes correctness at large. You say you just have to think about what's best for your project. Why not think about and understand the problem in general and build tools to tackle the specific complexities you have. Feel free to not use Haskell. Just keep in mind that you too live in a bubble with a certain mixture of doctrine and trade-offs.
lambda_obrien 6y ago
Haskell has been around for a really long time, almost 4 decades. It's used quite a bit by programming language theorists and category theorists to prove their mathematical theorems in a real language. It's not trendy or experimental, although some parts are one or both. There are about 5 ways to do everything in Haskell, but that's not bad once you understand it. It's not a language you can just pickup in a weekend and easily Google questions about, it's generally used for applications that require some higher level of data and quality assurance, from a fully proven program using Coq to simply a program that's easier to use equatorial reasoning on, like industrial processes or stream processing pipelines. Erlang has been around about as long. It's also not trendy, and it's designed for telecommunications applications, where the extremely distributed actor model is great. Others might try to shoehorn it everywhere, mostly via elixir, but it's a very reasonable language for many uses, like chat programs or distributed in memory stores. You might want to understand something before you crap all over it, everything exists for a reason, try to figure out the reason.
- betaby 6y ago
  Your statement about Erlang in telecom is mostly a myth. There was one somewhat successful niche piece of equipment from Ericsson and even that was ~20 years ago. Erlang is basically unheard in the telecom field.
  - lambda_obrien 6y ago
    Interesting, do you have any details on that? I've always seen it's origin story start in telecommunications.
    - betaby 6y ago
      Sure, that was AXD 301 ATM switch http://erlang.se/publications/ericsson_review_axd301_1998012.pdf http://erlang.se/publications/ericsson_review_axd301_1998012...
dtwhitney 6y ago
Haskell simply makes you do a thing you should do: check that the thing you expect to be there is actually there. You can think of it simply as the compiler acting as a testing framework. On the other side there are things like TypeScript where selecting the 'n' index of an array does not give you a type representing the fact that the item may not exist, and thus does not force you the check if it does. You may call this "getting out of your way", but I don't see how this makes software less complex - it makes bugs more difficult to track down and necessitates more tests, which could simply be removed by an adjustment in types. TyoeScript/JavaScript is easier to learn, but dear God does it offer so many ways for your to shoot yourself in then foot.
tome 6y ago
> Reading articles like this makes me want to avoid Haskell. Huh? The article doesn't even mention Haskell!
valenterry 6y ago
> I find that many articles written about Haskell, Erlang and Elixir seem to have no meaning outside of their own narrow domain; they try to present some solutions as some universal insight which is applicable to all languages. As a developer who does not use Haskell (but understands most of it), let me put it into perspective: If you write an article about the visitor-pattern or any kind of other OOP pattern, how do you think this is perceived by a developer who ever only wrote assembly? Yes, they will think in the same way you think right now. This phenomenon has been described e.g. here: https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox Fact is that from the perspective of a Haskell developer, you are writing unorganized spaghetti code when not using the techniques they write about. In the same way you probably would see an assembly developer writing spaghetti code instead of using OOP techniques. > I like languages which stay out of my way Languages that stay out of _your_ way are languages that encourage the style that _you_ are used to. There are no languages that generally stay _out of the way_ because that's not possible and not even desired. So saying this just means "I want a language where I don't have to learn another way of doing things". That's fair, but it should be emphasized. > my OOP philosophy is so simple, I could explain it to a 10 year old Many people learn Haskell first and than have trouble learning classical OOP in e.g. Java. And the other way around. What does that tell you?
dragonwriter 6y ago
> I find that many articles written about Haskell, Erlang and Elixir seem to have no meaning outside of their own narrow domain; they try to present some solutions as some universal insight which is applicable to all languages. In fact, they seem to revolve around solving problems which the language itself created and only exist in that language. I don't find that to be the case often; Haskell articles, specifically, often have solutions to problems that static typing brings to the fore (they usually exist without it, but are less obvious without static typechecking and the solution approaches are sometimes different) and may present solutions that require a type system more powerful than is typically available outside of Haskell (though they are usually translatable to a weaker type system with some loss of safety.) In fact, I've learned a lot applicable to programming in languages like Python, Ruby, JavaScript, and C# from learning a bit of (and reading articles focussing on) each of Haskell, Clojure, Erlang, and Elixir. Most paradigms can be applied productively in most languages if you are familiar with the paradigm and target language (though they're are definitely things that depend on being on one side or the other of the static/dynamic divide.) And even workhorse languages these days tend to be multiparadigm to start with, so learning techniques from the languages where a paradigm has been most fully explored and is most naturally expressed is often a good source of understanding to apply in other languages when that paradigm is the right choice. > A lot of these trendy languages seem to be on a futile mission to try to automate away some of the complexity of building software All languages higher level than raw machine code exist for primarily that purpose (and, for that matter, the design of modern machine instruction sets itself does some of that, too.) That isn't limited to “trendy” languages, which probably just means popular ones that are outside of your particular zone of preference established through familiarity.

golemiprague 6y ago

What do you mean by simple expressive language that stay out of your way? Every language has some concepts and assumptions and abstractions and certain ways to model this complicated world. Can you give some concrete example and explain why?

reuben364 6y ago

Reading articles like this make me want to avoid OOP. It seems that like the concept is so over-complicated that it requires developers to invent an entire religion to be able to effectively apply it to real world use cases...( my procedural philosophy is so simple, I could explain it to a 10 year old). There are many ways to build software, but only few ways to build it reliably. One major aspect of reliable software is composability, so that may ensure correct large systems are out of correct smaller systems. Correctness in the small, trivial bits and their glue is what makes correctness at large. You say you just have to think about what's best for your project. Why not think about and understand the problem in general and build tools to tackle the specific complexities you have. Feel free to not use Haskell. Just keep in mind that you too live in a bubble with a certain mixture of doctrine and trade-offs.

lambda_obrien 6y ago

Haskell has been around for a really long time, almost 4 decades. It's used quite a bit by programming language theorists and category theorists to prove their mathematical theorems in a real language. It's not trendy or experimental, although some parts are one or both. There are about 5 ways to do everything in Haskell, but that's not bad once you understand it. It's not a language you can just pickup in a weekend and easily Google questions about, it's generally used for applications that require some higher level of data and quality assurance, from a fully proven program using Coq to simply a program that's easier to use equatorial reasoning on, like industrial processes or stream processing pipelines. Erlang has been around about as long. It's also not trendy, and it's designed for telecommunications applications, where the extremely distributed actor model is great. Others might try to shoehorn it everywhere, mostly via elixir, but it's a very reasonable language for many uses, like chat programs or distributed in memory stores. You might want to understand something before you crap all over it, everything exists for a reason, try to figure out the reason.

betaby 6y ago
Your statement about Erlang in telecom is mostly a myth. There was one somewhat successful niche piece of equipment from Ericsson and even that was ~20 years ago. Erlang is basically unheard in the telecom field.
- lambda_obrien 6y ago
  Interesting, do you have any details on that? I've always seen it's origin story start in telecommunications.
  - betaby 6y ago
    Sure, that was AXD 301 ATM switch http://erlang.se/publications/ericsson_review_axd301_1998012.pdf http://erlang.se/publications/ericsson_review_axd301_1998012...

dtwhitney 6y ago

Haskell simply makes you do a thing you should do: check that the thing you expect to be there is actually there. You can think of it simply as the compiler acting as a testing framework. On the other side there are things like TypeScript where selecting the 'n' index of an array does not give you a type representing the fact that the item may not exist, and thus does not force you the check if it does. You may call this "getting out of your way", but I don't see how this makes software less complex - it makes bugs more difficult to track down and necessitates more tests, which could simply be removed by an adjustment in types. TyoeScript/JavaScript is easier to learn, but dear God does it offer so many ways for your to shoot yourself in then foot.

tome 6y ago

> Reading articles like this makes me want to avoid Haskell. Huh? The article doesn't even mention Haskell!

valenterry 6y ago

> I find that many articles written about Haskell, Erlang and Elixir seem to have no meaning outside of their own narrow domain; they try to present some solutions as some universal insight which is applicable to all languages. As a developer who does not use Haskell (but understands most of it), let me put it into perspective: If you write an article about the visitor-pattern or any kind of other OOP pattern, how do you think this is perceived by a developer who ever only wrote assembly? Yes, they will think in the same way you think right now. This phenomenon has been described e.g. here: https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox Fact is that from the perspective of a Haskell developer, you are writing unorganized spaghetti code when not using the techniques they write about. In the same way you probably would see an assembly developer writing spaghetti code instead of using OOP techniques. > I like languages which stay out of my way Languages that stay out of _your_ way are languages that encourage the style that _you_ are used to. There are no languages that generally stay _out of the way_ because that's not possible and not even desired. So saying this just means "I want a language where I don't have to learn another way of doing things". That's fair, but it should be emphasized. > my OOP philosophy is so simple, I could explain it to a 10 year old Many people learn Haskell first and than have trouble learning classical OOP in e.g. Java. And the other way around. What does that tell you?

dragonwriter 6y ago

> I find that many articles written about Haskell, Erlang and Elixir seem to have no meaning outside of their own narrow domain; they try to present some solutions as some universal insight which is applicable to all languages. In fact, they seem to revolve around solving problems which the language itself created and only exist in that language. I don't find that to be the case often; Haskell articles, specifically, often have solutions to problems that static typing brings to the fore (they usually exist without it, but are less obvious without static typechecking and the solution approaches are sometimes different) and may present solutions that require a type system more powerful than is typically available outside of Haskell (though they are usually translatable to a weaker type system with some loss of safety.) In fact, I've learned a lot applicable to programming in languages like Python, Ruby, JavaScript, and C# from learning a bit of (and reading articles focussing on) each of Haskell, Clojure, Erlang, and Elixir. Most paradigms can be applied productively in most languages if you are familiar with the paradigm and target language (though they're are definitely things that depend on being on one side or the other of the static/dynamic divide.) And even workhorse languages these days tend to be multiparadigm to start with, so learning techniques from the languages where a paradigm has been most fully explored and is most naturally expressed is often a good source of understanding to apply in other languages when that paradigm is the right choice. > A lot of these trendy languages seem to be on a futile mission to try to automate away some of the complexity of building software All languages higher level than raw machine code exist for primarily that purpose (and, for that matter, the design of modern machine instruction sets itself does some of that, too.) That isn't limited to “trendy” languages, which probably just means popular ones that are outside of your particular zone of preference established through familiarity.