[raydiatian]

Wouldn’t it be more useful to your audience (juniors I assume) to say that “learning patterns in software design helped you grow as an engineer?” I mean you call out things like discovering DDD and I’m sure you also came across Data-oriented design as well, Patterns of enterprise architecture, etc. In my experience knowing those patterns provides far more value in one’s toolkit than “knowing” Kotlin, Ruby, Scala, Golang, Rust & C++.

[sidlls]

Different languages provide different features and support these patterns in different ways. I think they’re complementary.

Not to mention that learning different languages can be quite valuable for one’s career, as it is another skill one can employ for practical purposes and for distinguishing oneself among peers.

[raydiatian]

> Different languages provide different features and support these patterns in different ways. I think they’re complementary.

I mean, I didn’t learn that much from learning FP that didn’t already know from reading Uncle Bob’s clean code and style guides. In fact I think for awhile it just made me a pretentious clown who wouldn’t stop calling things monads.

Furthermore, haven’t most languages today pretty much converged around the “imperative++” feature set:

Language-level async/await, object-oriented, garbage-collected, w/ a package manager for other people’s code. Whatever nuance between how Kotlin does abstract classes vs Typescript I can certainly learn on the job, for instance.

I don’t disagree that there is value in learning two or three languages but beyond that the marginal utility drops off quite sharply in my experience.

> Not to mention that learning different languages can be quite valuable for one’s career, as it is another skill one can employ for practical purposes and for distinguishing oneself among peers.

I mean if it comes right down to it, a decision between two otherwise identical candidates, hire the person w/ language experience. But we probably agree that theory knowledge precedes language familiarly in importance, always. Which is largely my argument for why the title thesis is probably inaccurate.

[cardanome]

> Furthermore, haven’t most languages today pretty much converged around the “imperative++” feature set:

If anything, functional programming has absolutely won.

Support for first-class and higher order functions, anonymous functions and so in are absolute must-haves for any modern language.

These features have become so bread and butter that people will not even think about them as functional programming but these were the main features that functional programming languages pioneered.

Now, PURE functional programming like in Haskell is not mainstream. It is a testament to the success of functional programming that these days we mostly think about these extreme examples when we talk about functional programming.

If anything, it is object oriented features that are becoming optional. At least the class based approach is starting to decline for good with many new languages explicitly not implementing them.

Also, I strongly disagree that all programming languages are starting to converge. It seems you just picked languages that are very similar which I agree, will not expand your mind much.

Learning languages like Common Lisp, APL, Forth, Prolog, Haskell and so on though will will greatly expand your understanding of programming.

[raydiatian]

> It seems you just picked languages that are very similar

No no, I picked languages that have jobs waiting in industry. 3 Billion devices run on a language that literally requires everything to be an object ;) I haven’t seen too many elm/elixir job postings, but rest assured when they start cropping up with the frequency of say JavaScript or C#, I’ll be dusting off my notes from previous side projects. I’ve also done Prolog, I’ve also done Haskell, I’ve also done Scala. Far more important than being able to write Haskellish code for my typescript backend is the ability to write idiomatic Typescript code with good patterns. And the whole discussion here is not whether you should check out FP (you should) but whether learning extra languages is more important than learning patterns in software design (ie canonical Martin Fowler, GoF, Uncle Bob). There are absolutely useful models and perspectives to be found in FP, but I haven’t found them to be stuff that I use every day. If every imperative language is shipping with first-class functions (which I personally don’t think is as dazzling a notion as it sounds—even C has shipped with function pointers since the days of old) and all the jobs are in imperative languages, it seems pretty practical to focus on learning patterns before learning FP. Respectfully.

[dopidopHN]

It’s two different things.

For instance using more functional language convinced me of the vertus of immutability.

Pattern won’t do that

[raydiatian]

> Patterns won’t do that

I’m pretty sure Clean Code by Uncle Bob has a section on why you should use const to achieve immutable variables. In any case, good style guides inevitably are preaching this as well, as are good senior engineers.

All in one’s first language (human), without needing to understand lambda calculus, or monads to run a hello world.

[mrkeen]

> I’m pretty sure Clean Code by Uncle Bob has a section on why you should use const to achieve immutable variables.

Doesn't go far enough.

Firstly, it's just advice. I might like it, but it doesn't mean I can get my teammates to do it.

Secondly, if I want to do it, I have to get it right, any mistakes I make are on me.

Thirdly, const is not enough. You'll probably end up with immutable pointers to mutable data, rather than any kind of referential transparency.

A language which helps you get immutability right is a world of difference. It's like the difference between a memory-safe language vs just using C (and a C textbook which recommends that you write memory-safe code)

[raydiatian]

> A language which helps you get immutability right is a world of difference. It's like the difference between a memory-safe language vs just using C (and a C textbook which recommends that you write memory-safe code)

I mean I understood how to get immutability right before I ever picked up an FP language, but I can see how this is a flexible point though. The virtues of immutability really don’t take a long time to extol, and they’re a concept you’re introduced to immediately in MyFirstFPLang™.

[dopidopHN]

Of course; but reading it from clean code 10 years ago I thought “yeah sure”.

Having no way to mutate my variable in List or Elm or scala … and seeing first hand that a lot whole class of bug disappeared, is different.

But we need both ! Absolutely both. And I will probably never code again in scala or lisp. That was fun. I learned a few things ( scala taught me how functional codebase can be unreadable as well )