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

81–90 of 513 posts

Re: Functional programming should be the future of software

#81

Post by ch4s3 »

zzzeek wrote: post #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 willi…

You should give elixir a try. It’s easy to learn, the tooling is really good, and the community is super friendly. I’ve found the mix of immutability and dynamic/structural typing to be great in practice.

Re: Functional programming should be the future of software

#82

Post by photochemsyn »

Hybridization of object-oriented and functional approaches seems like a decent approach to theses problems.

> "Nearly all modern programming languages have some form of null references, shared global state, and functions with side effects..."

Which is to say, code is organized into discrete classes, instantiated as objects, but those objects only use the functional paradigm with respect to their bound functions, i.e. no side effects, no shared global state. Some sort of input validation and screening can be used with each to sanitize values and avoid null references. Then you have a collection of discrete modular elements which can be reasoned about or debugged independently.

Such classes would be essentially 'stateless' but you could have other classes that stored mutable state and were queried by the functional types, much like the application-database model:

> "The trend has been to keep stateless application logic separate from state management (databases): not putting application logic in the database and not putting persistent state in the application. As people in the functional programming community like to joke, “We believe in the separation of Church and state”"

https://ebrary.net/65011/computer_science/separation_applica...

Re: Functional programming should be the future of software

#83

Post by christophilus »

munchler wrote: post #63
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…

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.

Last time I used F# on Linux, the REPL was a mess and mostly unusable. Compilation takes forever. You have to edit an fsproj rather than inferring modules from the file system structure like most modern languages.

It’s a great language— maybe my favorite, but the tooling stinks if you’re not using VS. I’m not switching to Windows, so that leaves me in limbo.

Re: Functional programming should be the future of software

#84

Post by zelphirkalt »

Functional programming (FP) is great, no question. However, we who know about FP should not forget, that there are other worthwhile paradigms out there. Just think of Prolog-like things or programming in relations (for example minikanren) for example. The good thing is though, that mostly-FP/FP languages can be used to make DSLs, which in turn enable such kinds of paradigms, so that we are not limited to FP itself.

Re: Functional programming should be the future of software

#85

Post by savingsPossible »

UncleMeat wrote: post #33
yobbo wrote: post #25

Earlier quoted context omitted.

The extent to which immutability leads to duplication seems a matter of implementation rather than a principle. The compiler/runtime could optimize such that memory is reused, as long as all other laws are obeyed.

To some degree. But it really is the case that a persistent functional data structure is going to have a slower insert operation than a traditional mutable set. There's no getting around that.

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

log(n) slowdown to add in the end

but the cost to add in the middle is cheaper then the trivial array (see insertAt)

Re: Functional programming should be the future of software

#86

Post by jve »

jvanderbot wrote: post #26
halfmatthalfcat wrote: post #2

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.

There is nothing magical about functional programming, it is the elimination of non functional programming features that is important. A language that can do either is exactly the wrong thing, from the perspective of TFA

> There is nothing magical about functional programming

How come not? I read that F# gives you compiler exception when you didn't match all possible values. Or when you didn't handle __maybe__ cases. JS even doesn't mind comparing strings with ints and incorrectly summing them together and not throwing a runtime exception less alone a compiler complaint.

  "1" == 1
  true
  "1" + 1
  '11'

Re: Functional programming should be the future of software

#87

Post by zelphirkalt »

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…

You gave up using a programming language after a day? And Haskell after installing/building some dependencies for 20mins? Tbh, this sounds like you were not really trying. What kind of experience with a programming language do you expect to have after a mere day? Learning takes time. Anyone might spew some not idiomatic code within a day, but really becoming proficient usually takes longer.

Do you have any references for the "Rust is heavily influenced by FP" thing? To me it does not feel that much FP. I have (for now) given up writing FP like code in Rust. ML-influence -- Yeah maybe, if I squint a bit.

Re: Functional programming should be the future of software

#88

Post by rileymat2 »

louthy wrote: post #23
skohan wrote: 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…

If the first thing you talk about is performance and not quality and maintainability, then you're already missing the point. Most software just isn't in some super high-perf environment - what matters is fewer bugs, easier maintainability, better communication with other engineers (through declarative code). The code we work on in the 2020s is much, much more complex than code written 20 years ago. We need better pri…

Can you give some examples of increased code complexity over the last 20 years? I am blanking on that.

I have noticed a lot more ops complexity and additional library usage, but not complexity in the code I am responsible for.

Re: Functional programming should be the future of software

#89

Post by UncleMeat »

savingsPossible wrote: post #85
UncleMeat wrote: post #33

Earlier quoted context omitted.

To some degree. But it really is the case that a persistent functional data structure is going to have a slower insert operation than a traditional mutable set. There's no getting around that.

https://hackage.haskell.org/package/containers-0.6.5.1/docs/... log(n) slowdown to add in the end but the cost to add in the middle is cheaper then the trivial array (see insertAt)

The asymptotic behavior is not the entire story. Because persistent data structures almost necessarily need to have their data allocated non-contiguously they have terrible cache performance and prefetching/speculation behavior in comparison to data structures that take advantage of contiguous memory locations.

I also mentioned sets, not lists.

Re: Functional programming should be the future of software

#90

Post by fallat »

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.

Is this actually true? I feel like the majority that software exists is non-business software simply because there's zero cost...
Post reply on HN