Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

61–70 of 513 posts

Re: Functional programming should be the future of software

#61
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…

Not only tooling is a problem. Name one FP language that I can use for high-performance and systems programming. Is there any one except ATS?

And ATS is pretty hard (unlike C, C++ and Rust). I think it will take a while until linear & dependent type languages will hit mainstream. Rust already succeeded in that regard, so it's a great stepping stone.

Re: Functional programming should be the future of software

#63
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 think F# has a good tooling story, since it's part of .NET and a first-class citizen in Visual Studio. It doesn't get as much love from Microsoft as C#, but it's still quite nice to use.

Re: Functional programming should be the future of software

#64
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…

Duplication problem is solved by immutable data structures with structural sharing. They are part of Clojure standard library and exist in some other languages.

Re: Functional programming should be the future of software

#65
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 think tsoding has the wrong idea here. Most mathematicians are not working on GHC or Haskell standards or even using Haskell. Most are still doing mathematics on pen and paper. Many use packages like Sage or Wolfram alpha. Few are using interactive theorem provers like Lean.

Haskell is a poor language to be doing mathematics in.

I’d say the majority of people working GHC are software developers and CS researchers. They’re a friendly bunch.

What’s holding back tooling is that the developers of the de-facto compiler for Haskell are spread out amongst several organizations and there isn’t tens of millions of dollars funding their efforts. It’s mostly run by volunteers. And not the volume of “volunteers” you get on GCC or the like either.

That makes GHC and Haskell quite impressive in my books.

There are other factors of course but the tooling is improving bit by bit.

The whole “Haskell is for research” meme needs to go into the dustbin.

Re: Functional programming should be the future of software

#66
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 think tsoding has the wrong idea here. Most mathematicians are not working on GHC or Haskell standards or even using Haskell. Most are still doing mathematics on pen and paper. Many use packages like Sage or Wolfram alpha. Few are using interactive theorem provers like Lean. Haskell is a poor language to be doing mathematics in. I’d say the majority of people working GHC are software developers and CS researchers.…

I think he counts academic computer scientists more as mathematicians than developers.

Re: Functional programming should be the future of software

#67
post #9

Earlier quoted context omitted.

Go is probably one popular exception.

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

I wish that were true. Unfortunately, functional composition breaks down when functions have multiple return values, as is the case for everything that returns an `err, res` pair. So even with generics added, Go is still hostile to functional programming.

If Go gets a Result generic type similar to the one in Rust to replace (err, res) that would work. That seems highly unlikely, however. The node.js community went through a similar migration from (err, res) callbacks to promises and it was quite painful, I think its highly unlikely this will happen in Go.

Re: Functional programming should be the future of software

#69
The first text sums it up:

    It’s hard to learn
Which is refreshing to see just stated up front: FP is for smart people who have some motivation to learn something hard, even when there's a whole world of alternatives that are not "hard" to learn. in this writer's case, it appears to be they own a company and they've mandated everything be written in Haskell or PureScript, which will select for employees that are willing / able to do that, etc.

as long as humans are employed to write the code directly, "hard to learn" is a non starter for being the "future".

Re: Functional programming should be the future of software

#70
post #50

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.

Lets take `map` for example. Before generics, you would have to reimplement map for every type combination. Each implementation would be done with a for loop. Now, while I'm willing to look over having one `map` implementation being done in imperative code and then everything else using that, I'm not exactly comfortable calling reimplementing map with imperative code for every type combination functional programming.
Post reply on HN