Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

11–20 of 513 posts

Re: Functional programming should be the future of software

#11

The article picks on Javascript (of course) however you can write almost exclusively functional code in Javascript with the help of Rambda, fp-ts or the like. Yes, there is no "compiler" (outside of tsc) that will help you (yet) but stylistically, it's possible.

You can write exclusively functional code in pretty much any language can't you?

Reminds of

https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Re: Functional programming should be the future of software

#13
post #7

It would be helpful if the article started off defining what a functional language is. A lot of languages have functional features but are not “purely” functional. I think most would agree there’s a spectrum; dynamic vs static, eager vs lazy, mutable vs immutable. So what flavor of functional programming one might ask, since javascript is a dynamically typed flavor that is ubiquitous nowadays? The fine article sugges…

To quote "Stop Writing Dead Programs" [1]: "If what you care about is systems that are highly fault tolerant, you should be using something like Erlang over something like Haskell because the facilities Erlang provides are more likely to give you working programs."

[1] https://www.youtube.com/watch?v=8Ab3ArE8W3s

Re: Functional programming should be the future of software

#14
post #3

Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality. The thing about functional programming is that the confidence you get from immutability comes at the cost of increased memory usage thanks to data duplication. It's probably going to create a ceiling in terms of the absolute performance which can be reached. There are…

Data duplication is coming to all minstream languages these days, whether it's a community best practice or a requirement for some libraries (e.g. streams in Java).

I'm not saying that in-place operations don't have their uses, but to me, these use-cases look more and more like niche cases, as opposed to being the default choice in the past. That is well-reflected in new languages like rust, where a new name is by default immutable, and must specifically be flagged as mutable in order to be variable.

It means that the benefits of immutability and the performance tradeoffs people are willing to take are evolving. I would assume larger codebases and faster hardware means performance is less valuable, and clarity comes at a premium.

I do agree with you that NPEs and memory safety are unrelated problems, though.

Re: Functional programming should be the future of software

#15
post #3

Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality. The thing about functional programming is that the confidence you get from immutability comes at the cost of increased memory usage thanks to data duplication. It's probably going to create a ceiling in terms of the absolute performance which can be reached. There are…

Immutability does not even have to be bound to functional programming. One can use persistent (= immutable from the user's perspective) data structures, like immutable.js and get most of the benefits.

Moreover, persistent data structures can be optimized well (see Clojure), so that the performance issues may be relegated to the inner loops, as usual, and the rest of the program may use safe-for-sharing data structures.

Re: Functional programming should be the future of software

#16
post #9

Earlier quoted context omitted.

You can write exclusively functional code in pretty much any language can't you?

Go is probably one popular exception.

You still can if you wish to. First-class functions are there.

Re: Functional programming should be the future of software

#18

ML language != functional programming. There is more out there than Haskell. The article doesn't even mention OCaml, the second most popular ML-derived language on Github. Makes me suspect the article is not very well researched.

While the title doesn't specify this, the article is about pure functional programming. I don't think OCaml fits this bill exactly.

Re: Functional programming should be the future of software

#19
post #3

Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality. The thing about functional programming is that the confidence you get from immutability comes at the cost of increased memory usage thanks to data duplication. It's probably going to create a ceiling in terms of the absolute performance which can be reached. There are…

My problem with functional programming is refactoring. If you don't have side effects when you want to do 2 things deep into the call tree to something that is in completely different call tree branch - you have to extract it all the way up to the common parent and pass it through all the intermediates just so that one function deep there can access it.

It's incredibly frustrating when you work in a functional language, and yet it's the main benefit (no side effects).

I'd like to have a language that is imperative when written and functional when read :)

Re: Functional programming should be the future of software

#20
post #3

Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality. The thing about functional programming is that the confidence you get from immutability comes at the cost of increased memory usage thanks to data duplication. It's probably going to create a ceiling in terms of the absolute performance which can be reached. There are…

This is actually an area where there’s room to improve FP languages.

If you track ownership in functional languages, you can statically determine if a value is used more than once.

If it’s only used once, you can apply any updates to that value in place without allocating more memory.

This gives the performance benefits of mutability with the safety benefits of immutability, in some common cases.

The main trick is adjusting memory layouts accordingly. You can keep it simple by only applying this optimisation for functions of A -> A, or if you’re replacing it with a different type you can analyze the transformations applied to a value and pre-emptively expand the memory layout.

If a value is likely to be used only once, but might be used multiple times, you can also apply the same approach at runtime by reference counting and updating inplace when there’s only a single reference (for functions of A -> A at least).

I believe the Roc folks are aiming to have aspects of this functionality, and I also believe there’s similar stuff becoming available in Haskell under the guise of linear types.

Finally, if you really need a shared mutable value, that can be achieved with mechanisms like the State type in Haskell.

In short, the pieces are there to create a functional programming language that doesn’t introduce needless memory usage overhead, but I don’t think anyone has put all the pieces together in a convenient and accessible way yet.

Post reply on HN