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

461–470 of 513 posts

Re: Functional programming should be the future of software

#461

Post by mpweiher »

theCodeStig wrote: post #436
mpweiher wrote: post #342

Earlier quoted context omitted.

> An anecdote of one person with bad manners shouldn't be representative of the whole. It is so incredibly widespread, it's not just "an anecdote of one person". The entry-level courses at TU-Berlin where I studied had just been taken over by FP disciples when I started studying, and it was crazy. "Let me tell you about our Lord and Saviour Functional Programming, Hallelujah". And of course the reality didn't come cl…

> Not a pure function at all. And not really a function either. Just a mapping. A function is a mapping of an input to an output.

But not all mappings are functions.

Re: Functional programming should be the future of software

#462

Post by znafelrif »

ParetoOptimal wrote: post #204
znafelrif wrote: post #142

The properties mentioned in the article are not really tied to functional programming. - Not allowing null-references can be done with any paradigm. For example with object-oriented programming there really is no reason why it wouldn't work to not allow null references. - Immutability can also be done with every paradigm. The Java String for example is both object-oriented and immutable. I think the paradigm is actua…

Tis doesn't give you 1) ease of use and 2) composability.

The article actually mentions ease-of-use as the major downside of functional programming ("Functional programming has a steep learning curve")

Re: Functional programming should be the future of software

#463

Post by darksaints »

hajile wrote: post #444
darksaints wrote: post #442

Earlier quoted context omitted.

Until John Carmack actually writes a game in Haskell, I'm gonna choose to interpret his comments as "Hey, I like these ideas" over "Hey, this would be perfect to write a game in". He's had a lot of nice things to say about a lot of different languages, but it is far more telling to consider what he has actually written significant amounts of code in. Pure functions excel at reducing bugs, I'll give you that. They als…

Carmack ported Wolfenstein 3D to Haskell. That seems like a big enough project to make serious statements about the language in the context of games.

Really? Are we thinking of the same game from 1992? Innovative for it's time, sure, but nowhere near the magnitude of complexity of modern games. Porting an extremely old game that can be written in a few thousand lines of code sounds like a hobby project to help you learn a new language...not a proof that the language could take over decades of OOP-driven game design.

Do you know what would be a better statement about the language in the context of games? A game engine. And actual games. That people want to play in 2022.

Re: Functional programming should be the future of software

#464

Post by misja111 »

hither_shores wrote: post #325
misja111 wrote: post #49

Earlier quoted context omitted.

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))

> in pure FP either lookup or insert can be no better than O(log(n)) For single operations, yes. But what we really care about is usually the amortized performance over many operations, which can still be constant time.

No, this is not the case. It is actually for non FP solutions that the amortized performance converges to constant time. But for pure FP, there is no solution that performs in constant time, also not when amortized.

Re: Functional programming should be the future of software

#465

Post by forgotpwd16 »

dmitriid wrote: post #13
le-mark wrote: 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

Cloud Haskell brings ideas from Erlang to Haskell. But don't know how they compare.

Re: Functional programming should be the future of software

#466

Post by belmont_sup »

zamalek wrote: post #347
pera wrote: post #71

Earlier quoted context omitted.

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…

It would the OCaml community a great service if you wrote up a beginner's tutorial on working with Dune.

I felt the small section on dune here was enough for me.

https://ocaml.org/docs/up-and-running

Teaching anything beyond dune build or opam install feels out of place for a beginner tutorial.

However, there really should be more examples of “how to do X in dune”. It took me a bit to learn how to pin a git repo for local use and installation.

Re: Functional programming should be the future of software

#467

Post by belmont_sup »

stiiv wrote: post #118
munchler wrote: post #63

Earlier quoted context omitted.

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.

After learning a bunch of programming languages and their corresponding ecosystems (incl. Rust, Lisps, Scala), F# is still my favorite by a long shot. Its only serious shortcoming, imo, is the tooling. Visual Studio is great, but if you're not on Windows, your only practical choices are VS Code + Ionide (I was a sponsor for a while; ultimately lost hope), or JetBrains Rider, which is powerful, but heavy. Comparing my…

There’s also the jetbrain ide that I’ve heard good things about compared to ionide.

Re: Functional programming should be the future of software

#468

Post by stiiv »

belmont_sup wrote: post #467
stiiv wrote: post #118

Earlier quoted context omitted.

After learning a bunch of programming languages and their corresponding ecosystems (incl. Rust, Lisps, Scala), F# is still my favorite by a long shot. Its only serious shortcoming, imo, is the tooling. Visual Studio is great, but if you're not on Windows, your only practical choices are VS Code + Ionide (I was a sponsor for a while; ultimately lost hope), or JetBrains Rider, which is powerful, but heavy. Comparing my…

There’s also the jetbrain ide that I’ve heard good things about compared to ionide.

Yes, we ended up buying JetBrains Rider; I used it for a few years. I was much more productive in it than Ionide.

Code analysis was excellent, though it would sometimes get weird on multi-project repos. Unit testing (incl. Expecto tests) were a little flaky. Like many JetBrains products, it was a resource hog on large projects.

Probably the worst part of the Rider experience had more to do with other devs using different tools, i.e. Ionide or Visual Studio. (We were a "bring your own whatever" kind of startup.) Each IDE/toolchain had its own opinions about .fsproj files. A CI step to keep things "normal" would have been great, but there wasn't (isn't?) anything available, and we wouldn't spend the time building our own.

tl;dr - Rider better than Ionide; whole team should use it

Re: Functional programming should be the future of software

#469

Post by dottedmag »

spion wrote: post #459
spion wrote: post #453

Earlier quoted context omitted.

Its not a single value, so its not anything.

That may've sounded overly harsh - but as a first step, try for example to use the output of a Go function that returns two values in another expression. e.g. assuming `g` returns (err, res), try writing `f` in such a way that you can call `f(g(x))`. This has implications on how higher order functions like `map`, `filter` etc can be written in a way that makes them usable with any value (including those that represen…

func composeE[T](fn1, fn2 func(T, error) (T, error)) func(T, error) (T, error)

func liftE[T](func(t T) T) func(T, error) (T, error)

?

I'm not a big fan of functional programming though.

Re: Functional programming should be the future of software

#470

Post by balefrost »

DeathArrow wrote: post #167

Functional or procedural or whatever, it doesn't matter much for me as long as the paradigm is not OOP. I strongly believe that data should live separate from the actions performed on it. I also believe that inheritance is a bad thing as there are other, better means to achieve polymorphism. I do believe in a data oriented programming where we waste as little CPU cycles as possible and introduce as little abstraction…

I dunno, even in C codebases, it's not uncommon to have data structures containing function pointers. Polymorphism isn't inherently bad and trying to achieve it using, say, enums and big switch statements isn't particularly maintainable.
Post reply on HN