Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

Post reply on HN
Print view View original

71–80 of 513 posts

Re: Functional programming should be the future of software

#71

Post by pera »

zamalek wrote: 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…

That's interesting, I often find the tooling one of the best things that FP languages offer. In OCaml for instance I found Dune to be fantastic and extremely intuitive. Another very good experience I had was with Elixir and Hex. In Haskell I personally think that there are indeed quite a few things that could be improved around build system and packaging, but overall it's not really that bad once you learn the quirks.

Re: Functional programming should be the future of software

#72

Post by capableweb »

zamalek wrote: 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…

> it is heavily influenced by FP

Is it really? I agree with the rest of your post, that Rust provides great tooling, but not sure it's "heavily influenced by FP", at least that's not obvious even though I've been mainly writing Rust for the last year or so (together with Clojure).

I mean, go through the "book" again (https://doc.rust-lang.org/book/) and tell me those samples would give you the idea that Rust is a functional language. Even the first "real" example have you mutating a String. Referential transparency would be one of the main point of functional programming in my opinion, and Rust lacks that in most places.

Re: Functional programming should be the future of software

#73

Post by exyi »

waselighis wrote: post #36

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…

Actually, implementing AVL tree in purely functional way is easy, I'd say it's easier than doing it in the mutable in-place way. It will allocate more, but will have the optimal O(something) complexity.

Many other algorithms are much harder, though, especially those requiring fast array indexing (graph search, hash tables, ...)

Re: Functional programming should be the future of software

#74

Post by spion »

brabel wrote: post #50
chrisseaton wrote: post #46

Earlier quoted context omitted.

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.

Or lets look at persistent data structures, a staple of functional programming:

https://github.com/tobgu/peds

Notice how you'd need to generate the DS for every type you'd like to use it with, which is not the case with built in mutable maps and slices.

To make them type-safe, you need to generate them for every type you use. While this is technically possible, it does make the language quite hostile towards functional programming. With generics, this is rectified but the problem with non-composable multi-return-value functions still remains

Re: Functional programming should be the future of software

#75

Post by savingsPossible »

poorlyknit wrote: post #40
waselighis wrote: post #36

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 note regarding your binary tree example: I'd argue that FP is actually great for working with tree-like data structures. For example, the common implementations for sets and maps are based on balanced trees. IME it's graph-like or array-based stuff where the paradigm struggles.

Pay a log(n) slowdown and you have arrays in all their glory (and more!)

https://hackage.haskell.org/package/containers-0.6.5.1/docs/...

Re: Functional programming should be the future of software

#76

Post by kitd »

zamalek wrote: 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…

Tooling is why Go gets its foot in the door much quicker than other languages IMHO. A single binary with no dependencies that does pretty much everything.

Re: Functional programming should be the future of software

#77

Post by throwaway1492 »

throwawaymaths wrote: post #52
throwaway1492 wrote: post #41

Earlier quoted context omitted.

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.

And also the vast majority of "working" applications have a full devops team, legions of highly paid senior developers, etc. "You" do not.

Ok so we’re adding “developer productivity” on to the list. Aside from moving the goal, one does not have faith a lot faith in the knowledge of people making these claims, like where’s the proof?

Hint read Joe Armstrong’s dissertation.

Re: Functional programming should be the future of software

#78

Post by throwaway17_17 »

cafard wrote: post #58

Functional programming: the future of computing since 1977. (Dating it from John Backus's Turing Award lecture.)

Is that really a fair date to use? The functional programming Backus is talking about bears little resemblance to the functional programming which is being discussed now(and in the article). I think an interesting discussion can be had about what defines functional programming (and I’m not really trying to argue with you), but Backus’s FP doesn’t fit the definition the article or other posters are using (or implying).
Post reply on HN