Sebastian Makowiecki wrote:Hi there,
When it comes to functional programming paradigm does the language choice matter much in your opinion?
Briefly, in 'couple' sentences or just naming a few in a list, what are the main benefits of functional paradigm over the others?
Many thanks, lately I have been thinking about all the available paradigm choices, so far struggling to make sense of it and would appreciate your expert input.
Hi Sebastian,
Yep, the choice of a language is an architectural decision and it definitely affects everything that comes after. Let me try to make a short overview of FP languages as how I see this, but my overview won't be exhaustive by any means.
1. Clojure. Very simple FP language, very pleasant to use (#2 of the most loved languages in SO Survey). Fast development cycle, JVM, lovely tools. You'll have to write tests for making your apps reliable. I would avoid writing big programs in Clojure though.
2. Scala. Enterprise-level FP/OOP language. Also JVM. A lot of approaches, solutions, design
patterns, architectures. Great for data transformation pipelines. Somewhat a difficult language requires a lot of knowledge. An acceptable mix of FP and OOP.
3. Haskell. Great for financial apps and backends. For blockchains as well. Excellent for concurrent apps. Great for building reliable apps with a minimum of bugs. Small community - this risk is higher than with other languages. Learning can be somewhat challenging. But Haskell is what we call "real FP" today. Most of the mainstream languages borrow ideas from it, and I'd recommend learning Haskell to learn FP in its purest.
4. F#. .NET, MS stack. Well-established, quite ready for production, enough powerful and nicely documented. Not that difficult to learn.
There are other FP languages, for example, JavaScript, but I'm not sure if I need to characterise them.
What about the paradigm itself, let me copy-paste my answer from another
thread:
FP:
- Compilers, research, math
- Multithreaded and concurrent applications (if we want a better story with concurrency bugs)
- Data transformations and pipelines (for example, spam filters)
- Very complicated domains. (FP simplifies domain modeling very much)
- Stateless services
- Correctness (statically typed FP works extremely well for such domains as payments, bank software, blockchains etc)
OOP:
- All the traditional uses of OOP
- GUI (for now, FP doesn't work here that well)
- Business software (at least until we find a good way for FP)
- OOP can even work for soft-realtime apps. I wouldn't try FP there.
Hope this helps!