Ask HN: Functional programming allows you to do more work with less code?
5 comments
Maybe in general yes, but as a rule, no.
And it depends on what language you are using regularly and what functional language you would like to use.
E.g. If you normally write Java, then FP will almost always be more terse. I am learning Clojure and it’s a lot less code than Java, and it can even natively call Java code as it runs on the JVM
And it depends on what language you are using regularly and what functional language you would like to use.
E.g. If you normally write Java, then FP will almost always be more terse. I am learning Clojure and it’s a lot less code than Java, and it can even natively call Java code as it runs on the JVM
It's not functional programming so much as the verbose obtuseness of old-school OOP languages like Java and C++.
It takes so much effort to satisfactorily define a type, or a function, in earlier versions of these languages. They've improved, though.
It takes so much effort to satisfactorily define a type, or a function, in earlier versions of these languages. They've improved, though.
My experience from OCaml is that everything ends up terser than when writing TypeScript. So I think, at least the type systems of functional languages can get done stuff with less code.
It allows for more correct code in an concurrency environment so its easier to trace bugs and make less mistakes.
It can be more terse but that doesn't make less code overall.
It can be more terse but that doesn't make less code overall.
The result is that you can easily model a procedure as a series of discreet steps and abstract away clutter. Mutated state and implicit arguments (this) are also typically not used in FP (except where required by the language or for performance reasons)
Upsides to this is that code is explicit, terse, and doesn't get bogged down in the specifics of how the hardware might need to assign pointers to values, etc.
The downside to this is that some people find the mounting abstractions and endless new terms difficult to parse, since FP spends very little time working with primitive values, and since it often is so different from traditional OO languages.
Javascript in particular can be very terse because there's very little boilerplate necessary due to the type system, and because it places no restriction on side-effects, allowing very easy methods of getting things done (but also creating a lot of brittle, bug-prone behaviour)
Haskell and purescript have much more verbosity devoted to types and type manipulation, but produce much more stable/predictable behaviours.