Hacker News Reader

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.

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.

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.

Interesting, do you have any details on that? I've always seen it's origin story start in telecommunications.

Sure, that was AXD 301 ATM switch http://erlang.se/publications/ericsson_review_axd301_1998012...

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.

> 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

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?

> 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.

> Reading articles like this makes me want to avoid Haskell.

Huh? The article doesn't even mention Haskell!