this post was submitted on 23 Apr 2025
24 points (90.0% liked)
Programming
19710 readers
377 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You don't actually need to know any of the functional programming languages to work in the AI sphere. Moreover, codebase in pure funcional languages is hard to understand and maintain, that's why they are rarely used in production. Of course you can learn any language for funsies, but I'd recommend Kotlin as a modern hybrid OOP language with a solid functional toolkit
hahahah how to trigger a lot of people working with these pure functional languages (like me).
I've worked with both "normal languages" like C++, java, Perl, javascript (node + UI), etc... and then I switched to Haskell and Clojure. And our current production code is a LOT better than in traditional languages. In particular, maintenance is a lot cheaper that what I was used to when working with more traditional languages.
Regarding the community impact I would advise to use Clojure instead of Haskell (or Purescript, or Elm). Clojure is a nice middleground that has a huge advantage of being very stable (by that I mean, the code you write today will probably be very easy to deploy in 10, or 20 years from now).
Note however, the language alone is not sufficient to write good code, but it helps you choose better abstractions that will be easier to maintain. If you dive into the spirit of the language, you will have a better intuition and understanding about state management of big applications and will probably make more visible some design issues.
It depends on when have you switched from those "normal" languages to functional, and where do you work now. Java 10 years ago is not Java nowadays, and not Kotlin. These modern languages influenced by advantages of functional languages, and you can even write thr most of your code in the functional style.
Our company has some codebase in Clojure and Haskell, and it was a huge headache to find a substitution for a Haskell engineer when they left. There are so few experts on the market. But of course, if you're an American big tech company, you'll find an engineer.
And I'm not saying to you "hey, switch to Kotlin!" Nope, if you're enjoying what you're doing and it brings you money — keep going. But the sad reality is that it's much harder to find a job for a pure funcional coder.
This is incorrect. They are rarely used because procedural languages have momentum. It's way more likely you'll get Joe Codemonkey to learn and be productive quickly with functional features added to a procedural language than to learn and be productive quickly with an entirely different paradigm. So that's what happens.
So, basically that's what I meant, but without disrespect to Joe :)
Fair. I just think is prudent to draw a line between natural difficulty and cultural resistance to change.
This is incorrect. Functional code bases exist in many production environments. Twitter (pre musk) migrated their bloated code base TO Scala because functional code bases are easier to maintain and understand.
If you think about it, it makes sense, side effect free code will be easier to maintain just due to the lack of side effects.
As I said in another response here, it's incorrect to compare Java 21 or Kotlin and Java 8. You can rewrite your bloated slow Java 8 code in functional reactive approach in Java 21 as well.
You can make a mistake writing any sort of code. What actually matters if it's readable enough to catch the bug. I would argue that functional languages is the best option here, especially when we're talking about about huge enterprise applications on complicated frameworks like Akka or ZIO.