Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

41–50 of 513 posts

Re: Functional programming should be the future of software

#41
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

That quote is absurd because the vast majority of applications on the planet are not written in Erlang and work just fine. Working and fault tolerance are in no way related. Being generous the majority of applications with very high uptime are also not written in Erlang.

Re: Functional programming should be the future of software

#42
I personally think Rust should be included in this group. It isn't technically a functional language, but it has a "functional flair" with many of the same benefits as functional programming provides, and with some of the features (pattern matching, sum types, etc.). It takes a different approach to mutability, but the net benefit I think is about the same.

Re: Functional programming should be the future of software

#43

Doesn't include Clojure in GitHub repo count. "Functional programming also requires that data be immutable" Not true

The D programming language is a good example which defines pure functions, not as strictly operating on immutable data, but simply as functions without side effects. So pure functions can still have local mutable variables, but cannot mutate any shared or global state. It goes further with "weakly pure" functions which can have mutable parameters/arguments, but still cannot mutate any global variables.

Re: Functional programming should be the future of software

#44
post #24

Functional programming won't succeed until the tooling problem is fixed. 'Tsoding' said it best: "developers are great at making tooling, but suck at making programming languages. Mathematicians are great at making programming languages, but suck at making tooling." This is why Rust is such a success story in my opinion: it is heavily influenced by FP, but developers are responsible for the tooling. Anecdotally, the…

I'm really happy with Meson, as a lot of Wayland (the new display protocol for Linux, the "successor" of X11) apps seem to be built in C, so using meson is super simple and I don't have to worry about tooling (I don't deal much with C/C++, so let me make my change and run away please).

Rust is the same, you can even define a nightly version if you want, so even the correct version is ran with rustup. It's fantastic, and I can contribute much easier to projects without worrying about tooling.

Re: Functional programming should be the future of software

#45
post #9

Earlier quoted context omitted.

Go is probably one popular exception.

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

It used to be impossible to do anything remotely like FP in Go before generics, but now I believe it's indeed quite possible.

Re: Functional programming should be the future of software

#46
post #45

Earlier quoted context omitted.

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

It used to be impossible to do anything remotely like FP in Go before generics, but now I believe it's indeed quite possible.

But everything you can do with generics you can do manually by copying and pasting code?

Re: Functional programming should be the future of software

#48
It's strange to me that this article focusses so much on nullability, which seems like a tangental issue. There's nothing stopping an imperative language from enforcing nullability checks. Indeed, with full strictness enabled TypeScript will do just that, including requiring you check every indexed access to an array.

Re: Functional programming should be the future of software

#49

I like the philosophy of Rust (and some other languages) of "safe by default". Rust variables are immutable by default, but can be made mutable using "let mut". Rust is memory safe by default, but can be made unsafe using the drumroll "unsafe" keyword. As for null references, other languages still have them but enforce "strict null checking", such as Kotlin and TypeScript. They force you to verify a reference is not…

A better example would be to implement an efficient HashMap in pure FP. This is simply impossible unless you fall back to some tree based solution which is less efficient.

Interested why this is downvoted .. Hashmaps can have O(1) time complexity for lookups and inserts in the imperative world, in pure FP either lookup or insert can be no better than O(log(n))

Re: Functional programming should be the future of software

#50
post #45

Earlier quoted context omitted.

It used to be impossible to do anything remotely like FP in Go before generics, but now I believe it's indeed quite possible.

But everything you can do with generics you can do manually by copying and pasting code?

Oh that's true. But you're a terrible masochist if you consider that an option.
Post reply on HN