←back to thread

Why Isn't Functional Programming the Norm? [video]

(www.youtube.com)
296 points gyre007 | 6 comments | 17 Oct 19 10:10 UTC | HN request time: 0.001s | source | bottom
Show context
_han ◴[17 Oct 19 11:49 UTC] No.21281004[source]▶
The top comment on YouTube raises a valid point:

> I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage collection, you name it. FP will always occupy a niche because of where it sits in the abstraction hierarchy. I'm a real time graphics programmer and if I can't mentally map (in rough terms, specific if necessary) what assembly my code is going to generate, the language is a non-starter. This is true for any company at scale. FP can be used at the fringe or the edge, but the core part demands efficiency.

replies(29): >>21281094 #>>21281291 #>>21281346 #>>21281363 #>>21281366 #>>21281483 #>>21281490 #>>21281516 #>>21281702 #>>21282026 #>>21282130 #>>21282232 #>>21283002 #>>21283041 #>>21283257 #>>21283351 #>>21283424 #>>21283461 #>>21285789 #>>21285877 #>>21285892 #>>21285914 #>>21286539 #>>21286651 #>>21287177 #>>21287195 #>>21288087 #>>21288669 #>>21347699 #
bryanphe ◴[17 Oct 19 15:25 UTC] No.21283041[source]▶
In terms of performance, the way we build applications today is such a low bar that IMO it opens the door for functional programming. Even if it is not as fast as C or raw assembly - if it is significantly faster than Electron, but preserves the developer ergonomics... it can be a win for the end user!

I created an Electron (TypeScript/React) desktop application called Onivim [1] and then re-built it for a v2 in OCaml / ReasonML [2] - compiled to native machine code. (And we built a UI/Application framework called Revery [3] to support it)

There were very significant, tangible improvements in performance:

- Order of magnitude improvement in startup time (time to interactive, Windows 10, warm start: from 5s -> 0.5s)

- Less memory usage (from ~180MB to <50MB). And 50MB still seems too high!

The tooling for building cross-platform apps on this tech is still raw & a work-in-progress - but I believe there is much untapped potential in taking the 'React' idea and applying it to a functional, compile-to-native language like ReasonML/OCaml for building UI applications. Performance is one obvious dimension; but we also get benefits in terms of correctness - for example, compile-time validation of the 'rules of hooks'.

- [1] Onivim v1 (Electron) https://github.com/onivim/oni

- [2] Onivim v2 (ReasonML/OCaml) https://v2.onivim.io

- [3] Revery: https://www.outrunlabs.com/revery/

- [4] Flambda: https://caml.inria.fr/pub/docs/manual-ocaml/flambda.html

replies(6): >>21283323 #>>21283373 #>>21286241 #>>21293953 #>>21296672 #>>21303464 #
tick_tock_tick ◴[17 Oct 19 15:51 UTC] No.21283323[source]▶
They already said they were working in games. None of what you said applies to that field.
replies(4): >>21283706 #>>21285424 #>>21285426 #>>21306369 #
1. yogthos ◴[17 Oct 19 19:14 UTC] No.21285426[source]▶
Here's a talk on making real world commercial games with Clojure on top of Unity.

https://www.youtube.com/watch?v=LbS45w_aSCU

replies(2): >>21286119 #>>21289022 #
2. jcelerier ◴[17 Oct 19 20:34 UTC] No.21286119[source]▶
come on, the "games" showcased here have the complexity level of a 2003-like game and they barely achieve 200 fps on modern hardware. When I look at similar trivial things ran with no vsync on my machine, it's >10000 fps
replies(1): >>21286960 #
3. yogthos ◴[17 Oct 19 22:34 UTC] No.21286960[source]▶
That's just moving goalposts. The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019. If you're doing triple-A game development, maybe you need to get down to the metal, but for tons of games you'll be perfectly fine with FP.

Also worth noting that the idea is to use FP around stuff like the actual game logic, and then handle rendering details imperatively.

replies(2): >>21289072 #>>21289271 #
4. thowfaraway ◴[18 Oct 19 05:56 UTC] No.21289022[source]▶
I think you are seriously overselling the talk, and what Arcadia is ready for.

you: Here's a talk on making real world commercial games with Clojure

video: dozens of game jam games have been made

5. thowfaraway ◴[18 Oct 19 06:13 UTC] No.21289072{3}[source]▶
The Poker prototype could be from 30 years ago, and drops to 15FPS on any game action! Arcadia is a neat toy at this point, but run far away if you are looking to do real world commercial development.
6. jcelerier ◴[18 Oct 19 07:08 UTC] No.21289271{3}[source]▶
> The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019

I mean, fucking todo apps are making "good money" in 2019, it does not mean that they are good examples. These kind of presentations should improve on the state of the art, not content themselves with something that was already possible a few decades ago. No one gets into game dev to make money, the point is to make better things than what is existing - be it gameplay wise, story wise, graphics wise...