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
Functional programming should be the future of software
41–50 of 513 posts
Re: Functional programming should be the future of software
#42Re: Functional programming should be the future of software
#43Doesn't include Clojure in GitHub repo count. "Functional programming also requires that data be immutable" Not true
Re: Functional programming should be the future of software
#44Functional 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…
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
#45Re: Functional programming should be the future of software
#46Earlier 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.
Re: Functional programming should be the future of software
#47Oh! From Hacker News trends, I thought the future of programming was going to be Rust...
Re: Functional programming should be the future of software
#48Re: Functional programming should be the future of software
#49I 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…
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
#50Earlier 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?