Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

481–490 of 513 posts

Re: Functional programming should be the future of software

#481
post #473

Earlier quoted context omitted.

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 abo…

It took a long time to write that engine and porting the whole thing properly also takes time. It just moves goalposts. Why didn’t he spend 80M on a new AAA game? If he spent any less than that, he certainly can’t draw any useful conclusions. Have you ever looked over the codebase? It’s plenty large enough to draw useful conclusions from for most people let alone someone with his vast game experience. https://github.…

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 agree with you that there are functional languages out there that are equivalent in performance.

My point is that the raw exposed complexity of functional state management (and especially pure functional state management) makes it worthless for game development. And until someone actually develops a real game, up to modern AAA standards using a functional language, all of your posturing is theoretical.

I can carry a pallet worth of goods to a supermarket using a pickup truck. It might be a little messy cause it can't pull up to a dock, so I'd have to unload it by hand instead of using a pallet jack, but the time I save by driving faster more than makes up for it. I could argue until I'm blue in the face about the theoretical benefits of using faster and more nimble pickups instead of slow and cumbersome lorries, but until someone actually builds a supermarket logistics network with them, those benefits are just theoretical. More importantly, the people who actually work in logistics industry would never attempt to do so because they can immediately see the problems with it.

So if you're that convinced your functional language would be better for game dev, then just do it already, cause nobody in the industry is gonna do it for you. I can guarantee it won't take long for you to understand what it is like when your paradigm choice puts you on the wrong side of the Expression Problem. And by the end of your experiment, you'll just be another crusty old insider that is too dumb and stuck in your ways to consider the amazing benefits of functional programming, just like what you're trying to do with me here.

Re: Functional programming should be the future of software

#482
post #428
post #400

Earlier quoted context omitted.

It's not about being afraid to define a struct/record (rigid type). It's about being afraid of being stuck with something that doesn't meet your needs later or elsewhere, if only by a little bit. That Range type is great until you have cases where you want variations on a Range, such as a MeasuredRange (same start and end, but with a new field called step_cost). Original functions which take a Range can't cope with t…

re Haskell: I just looked at a few arbitrary files in arbitrary Haskell projects on Github, and I retract that part. I was either thinking of another language, or had seen a lot of bad Haskell code before that I cannot find now. ---- Isn't this just the nullability thing again that most people have decided was a bad idea, but with a different name? Instead of two ints, now your function takes two maybe-ints and crash…

> Instead of two ints, now your function takes two maybe-ints and crashes at runtime if they're not there.

The idea in Haskell (and many more, I'm sure), is that if you take a maybe-int, you can't get the int without unpacking it (or using a function that only operates on the int if its there), so then when you pass the unpacked int around, you are 100% sure it's there at all times. No worrying about a JS-style undefined, or some other function altering the value to become null again. It's a guarantee, which is a huge part of why all this FP stuff is so great.

Re: Functional programming should be the future of software

#483
post #286

Earlier quoted context omitted.

> Really, anything from the book Turtle Geometry would have a challenging time in a lot of functional languages. https://github.com/sergv/turtle-geometry Is an implementation of the book Turtle Geometry in Scheme. A Lisp dialect. > Which is not that most functional languages are bad. Just they don't usually even try to abstract over the graphical. I hate that folks see how well the abstract over functions and assume…

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

Re: Functional programming should be the future of software

#484

Earlier quoted context omitted.

The claim was that Rust is "heavily influenced by FP"; I think that's clearly the case, while "Rust is FP" is probably not (which case you make pretty well).

FPLs yes, FP no. We might argue it's influenced by FP indirectly because those adopted features from ML etc also jive well with functional programming, for example pattern matching as a control flow construct...

Eh, I think that's a distinction we could make, but it's not clear to me it's useful, and FPLs themselves are (definitionally?) shaped by FP.

Re: Functional programming should be the future of software

#485

Earlier quoted context omitted.

FPLs yes, FP no. We might argue it's influenced by FP indirectly because those adopted features from ML etc also jive well with functional programming, for example pattern matching as a control flow construct...

Eh, I think that's a distinction we could make, but it's not clear to me it's useful, and FPLs themselves are (definitionally?) shaped by FP.

It's true it's arguable. But if we start calling the languages that adopt FPL pioneered features "heavily influenced by FP" we end up putting a lot of languages in that set, like Java, Python etc for having GC and closures. So in order to use that as a distinguishing feature I think it's warranted to make the distinction.

Re: Functional programming should be the future of software

#486
post #437

Earlier quoted context omitted.

> The typical argument for vaccines is much less shaky than the typical argument for pure FP. I suspect you aren't that knowledgeable about either. > For one, vaccine people can actually explain why vaccines are good. 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. > FP people seem to mostly just…

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

Re: Functional programming should be the future of software

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

> a Feynman of that sphere so to speak

Hopefully people who read QED don't go around thinking that they know all they need to know to make an informed judgement about lagrangian QM.

Re: Functional programming should be the future of software

#488
post #144

Earlier quoted context omitted.

While the title doesn't specify this, the article is about pure functional programming. I don't think OCaml fits this bill exactly.

It doesn't fit "pure", but it solves the same problems the article is talking about, as other functional programming languages do. In fact the article is excluding most functional languages by saying "pure", and then goes on with "Of the top dozen functional-programming languages, Haskell is by far the most popular" under the graph, which is wrong because it's missing "pure", a feature that is _not_ required to solve…

Which part of Haskell is impure?

Re: Functional programming should be the future of software

#489
post #473

Earlier quoted context omitted.

It took a long time to write that engine and porting the whole thing properly also takes time. It just moves goalposts. Why didn’t he spend 80M on a new AAA game? If he spent any less than that, he certainly can’t draw any useful conclusions. Have you ever looked over the codebase? It’s plenty large enough to draw useful conclusions from for most people let alone someone with his vast game experience. https://github.…

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 inferior at state management in your mind?

Re: Functional programming should be the future of software

#490

Earlier quoted context omitted.

The npm install experience should be baseline for newer languages. Simply let me get into hacking fast. This is one of the top reason I like tinkering with JS because it just works. (Yes, I know all weaknesses of JS ecosystem, but getting is really easy)

Please, no. Node tooling is such a mess and I can almost never get anything running easily on Nix because Node developers download binaries from the internet without understanding the system. All of these executables fail because of linked libraries. If instead they told you what libraries and executables you'd need instead loosy-goosy installing garbage all over my system, more things might work.

Sure npm is not silver bullet. But I want the npm experience. Technical implementation can be improved as you say and I agree.
Post reply on HN