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

491–500 of 513 posts

Re: Functional programming should be the future of software

#491

Post by darksaints »

hajile wrote: post #489
darksaints wrote: post #481

Earlier quoted context omitted.

Not only have I used SML, but I've also used F# and Scala extensively, both of which are well rooted in the ML philosophy. And for completeness, I've also used Common LISP, Haskell, Clojure, and Erlang. Not once have I made an argument about the efficiency of objects oriented languages. Although that is important for performance wherever performance matters, it isn't my point in the slightest, and I already would agr…

What encapsulation exists in OOP or procedural code, but not in functions and modules? The complexity in games is peanuts compared to any random business UI logic at whatever random company. Managing this complexity is an explicit reason to use functional paradigms. If OOP were better at managing complexity, why has everything been shifting from OOP to functional paradigms? What about the functional approach makes it…

Nah, I'm not gonna write an essay just for some random dude on the internet. Try writing a game. Like a real one, not tic-tac-toe. You'll learn quickly enough.

Re: Functional programming should be the future of software

#492

Post by hajile »

darksaints wrote: post #491
hajile wrote: post #489

Earlier quoted context omitted.

What encapsulation exists in OOP or procedural code, but not in functions and modules? The complexity in games is peanuts compared to any random business UI logic at whatever random company. Managing this complexity is an explicit reason to use functional paradigms. If OOP were better at managing complexity, why has everything been shifting from OOP to functional paradigms? What about the functional approach makes it…

Nah, I'm not gonna write an essay just for some random dude on the internet. Try writing a game. Like a real one, not tic-tac-toe. You'll learn quickly enough.

An Entity Component System is literally the functional approach to programming under a different name and with mutation by default. There’s even been a huge move toward keeping ECS data classes separate from behaviors. At that point, it’s just a less ergonomic functional approach with better performance due to lower-level languages (though ATS or Rust are just as fast as C).

Maybe you’re thinking of FRP (functional reactive programming), but that isn’t even super mainstream among most functional programmers. I know some small games have used it, but it’s mostly used for specific kinds of UI in languages that enforce immutability and no side effects.

Re: Functional programming should be the future of software

#493

Post by taeric »

tankorsmash wrote: post #483
taeric wrote: post #286

Earlier quoted context omitted.

Yeah, that isn't surprising, in that the book even mentions using LISP. However, this is a touch of a goal post shift with what folks typically mean by modern functional programming. (Which, to be fair, was always far more nebulous than folks admitted.) Specifically, though, this is my point. The turtle geometry abstraction is very imperative, by nature. It is still declarative, at a high level. But it is not functio…

Not quite turtle, but Elm (a pure FP) has something prettier, a full 3d renderer https://package.elm-lang.org/packages/ianmackenzie/elm-3d-sc... Demo: https://ianmackenzie.github.io/elm-3d-scene/examples/1.0.0/m...

Does this have examples of a fractal that I just couldn't find? The outputs are certainly pretty, but I'm not entirely clear where this fits into what I was trying to say. :(

That is, my argument is ultimately that for some things, having a section of code that is more imperative is actually far shorter than trying to accomplish the same thing otherwise.

It is akin to changing coordinates. Some things are trivially conveyed with polar coordinates. Just as some are made much more difficult in that setting.

Re: Functional programming should be the future of software

#494

Post by epgui »

knaekhoved wrote: post #486
sidlls wrote: post #437

Earlier quoted context omitted.

> Unless you have a very particular background, I'm suspicious that you can actually follow the frontier of that argument. More likely, you're getting the ELI5 explanation. People who actually understand complex things are able to provide ELI5 level explanations for people who haven't the background for more rigor. You're presenting a false representation of the OP's comment anyway: it never suggested the explanation…

> It's so divorced from writing software as to be gibberish. Only if the software you're writing is A) aggressively simplified, so as to be amenable to informal analysis, or B) garbage. If you're only interested in writing garbage, or perhaps you don't even notice that's what you're doing, then the appeal of FP is significantly reduced.

Minus the tone, I agree with the substance of your comment. In my experience, people who don't care about this don't really understand it either.

Re: Functional programming should be the future of software

#495

Post by epgui »

kstenerud wrote: post #457
epgui wrote: post #439

Earlier quoted context omitted.

> are able to provide ELI5 level explanations Yes, in theory, and this sometimes works. But it rarely works in general . In practice, people come to your explanation pre-conditioned with a lot of (often politicized) misinformation, Dunning-Kruger type overconfidence in their own ability, very little curiosity or openness to new ideas, and exhibit the attention span of a 26th percentile squirrel. People tend to listen…

It simply can't be done. It's always possible in theory but never in practice. Or at least certainly not in this special snowflake case. Until someone bucks the trend and does it. But for that you need someone with actual intelligence and empathy; a Feynman of that sphere so to speak. In every gatekeeper community this is the order of things until someone finally destroys the gates to the knowledge and the monopoly o…

Well, I don't disagree with you, but also all of these things you list in the parentheses are just how humans generally behave. They are real obstacles.

And regardless of where we place the blame, at the end of the day:

> In life, there are a lot of obvious things that are very difficult to teach.

Re: Functional programming should be the future of software

#496

Post by colonwqbang »

AnimalMuppet wrote: post #323
colonwqbang wrote: post #194

Earlier quoted context omitted.

Efficient functional programming often uses tree-like data structures. These can be immutable but still avoid duplication. Consider if you "duplicate" a Data.Sequence Seq (finger tree) for modification. You're not actually copying the whole structure, you are creating a new root node and re-using as much as possible of the common structure. The end result is that a bit more memory is used in the simplest case, but no…

That's duplicating part of the structure. That uses more memory than just modifying a value in-place, but less than duplicating the whole tree.

Sure, but let's assume that the program has more than one thread and that another thread could still be using the old value. In that case, an imperative program might be required to copy the whole structure or sleep until the existing users are done, which is often less efficient and is always more complicated.

If it's ok to support only a single concurrent user of the value, then a mutable structure is indeed more efficient. Even in Haskell we have mutable structures that can be used for such purposes.

The interesting question to me is, what should be the default? I think there is a good argument that it should be the safer, simpler immutable structures.

Re: Functional programming should be the future of software

#497

Post by axilmar »

I will certainly be downvoted for this, but I want to be honest so here it is anyway:

In all my programming years, 20+ years that is, I've met hundreds of programmers, and 95%+ of them handled imperative programming languages just fine, with very few actual bugs coming from each one.

Each time there is such a conversation, I have yet to see some actual concrete proof that functional programming provides a substantial increase in productivity over well-implemented imperative code.

In other words, I am still not convinced about the merits of functional programming over imperative programming. I want some real proof, not anecdotal evidence of the type 'we had a mess of code with C++, then we switched to Haskell and our code improved 150%".

Lots and lots of pieces of code that work flawlessly (or almost flawlessly) have been written in plain C, including the operating system that powers most of Earth (I.e. Unix-like operating systems, Windows etc).

So please allow me to be skeptical about the actual amount of advancement functional programming can offer. I just don't see it.

Re: Functional programming should be the future of software

#498

Post by spion »

dottedmag wrote: post #469
spion wrote: post #459

Earlier quoted context omitted.

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.

I think you might want the opposite of liftE, i.e. to be able to convert any function with two returning values into a function with a single returning value.

Then you can use those functions normally with standard FP tools such as `map` etc.

Yes, the node.js community did something like that with (err, res) and it still does it. Its pretty awful to be unable to use any of the standard library or community library functions (that can error) in a... functional way without wrapping them.

Re: Functional programming should be the future of software

#499

Post by savingsPossible »

UncleMeat wrote: post #89
savingsPossible wrote: post #85

Earlier quoted context omitted.

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.

Not that this answers all your objections (it does not, caching might be a problem!)

But sets are also a mere log(n) away

https://hackage.haskell.org/package/containers-0.6.6/docs/Da...

Re: Functional programming should be the future of software

#500

Post by savingsPossible »

snovv_crash wrote: post #146
savingsPossible wrote: post #75

Earlier quoted context omitted.

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/...

It isn't just log(n), it's also L1 vs L3 access times and an extra level of pointer chasing.

Just to confirm, you are talking about L1 and L3 caches, right?
Post reply on HN