Hacker News Reader

Comment by deltaonefour | Hacker News Reader

My policy is OOP is like Heroin. Don't even start.

Never write GUI code then.

Yeah that's the one downside of not doing OOP. OOP is the only way to do GUI stuff.

Nobody on the face of the earth has ever used Functional Reactive Programming. It's a made up concept. In fact it's also definitely not one of the concepts that inspired the most popular pattern in React.

I am unaware of a single functional reactive UI library or framework that does not rely on other people's, most often object-oriented (or even *gasp* procedural) libraries to actually put anything on the screen.

Of course it's relatively easy to build shiny clean wrappers around the dirty work that others have had to do on your behalf.

You're right you are unaware. This is not an insult and I'm not trying to offend you. This is a factual statement. You truly are unaware as you stated yourself, and I can prove it to you.

First off FRP is actually a term. Functional Reactive Programming. It is 100% a functional paradigm that gasp by DEFINITION cannot be procedural. So you truly didn't know what you were talking about here: https://en.wikipedia.org/wiki/Functional_reactive_programmin...

Second there are many languages/frameworks that use this paradigm. React partially uses this paradigm. But I will list two popular ones that strictly follow it... just note that there are more. Much more.

Take a look at elm. Elm is a fully functional UI library and language that is 100% pure, functional and has no OOP. Believe it or not ELM is not some toy, it is production ready and actually measurably faster than react. This language is what popularized the FRP pattern which is partially used by React today. See here: https://elm-lang.org/examples/mario

Note the load time and latency on the mario game. React doing the same thing will be slower.

Another language is ReasonML. ReasonML is essentially a language that compiles to the browser and has one to one correspondence with another functional language... OCaml.

ReasonML is Created by the creator of React, Jordan Walke. Coupled with React as framework, ReasonML is essentially the ideal GUI paradigm that Jordan would recommend everyone to use in the ideal world. However due to the fact that everyone is use to javascript, Jordan instead as a first step, ported FRP concepts over to a language called JSX (essentially JavaScript mixed with html) and is slowly nudging the world in the direction of GUI programming using the functional style: https://reasonml.github.io/

Make no mistake the creator, of the most popular GUI framework in the world is a supporter of the pure functional paradigm, and he is heavily and successfully pushing the functional style programming of GUIs into the mainstream.

OOPs being the dominant paradigm for GUIs has, in the past five years, become a false statement.

You're right on the wrapper part though. Assembly language is essentially a procedural language so every functional thing that exists on top of it, is a wrapper. But I mean this is a pointless observation.

Ah so ReasonML doesn't transpile to JavaScript, an OOP language?

How does it run on the browser?

You mention React and Elm, which - as I said previously - both rely on other people's actual GUI work (the various browsers' rendering engines + DOM, the various platform-specific UI SDKs, etc) to actually put anything on the screen.

I can't speak to ReasonML, as I have not used it, but my impression also is that it takes advantage of other people's GUI libraries considering that I've heard Revery compared to Flutter (and Flutter outsources its rendering to Skia as well as relies on rather imperative RenderObjects beneath the functional reactive layers). Please correct me if I'm wrong.

I would be very interested indeed to see a GUI framework built from the actual ground level up in an entirely functional reactive manner. Do you know of any?

Actually there is NuclearJS a Flux (React) implementation in JS designed around immutability, FP and also reactive programming. As anything pure FP, it's ridiculously difficult/awkward to get started but it really shines in some areas. Namely complex UIs, state transitions and interrelated data "objects". The first 2 can be solved with proper OOP (it's obviously not nice but it solves the problem), but I've never seen a framework ironing out the nastiness of relational data so well. The idea is to combine multiple data objects using lambdas. It's incredibly elegant and so general concept is supposed to be the "Functional Lens".

Unfortunately it's discontinued, probably rightly because it's definitely not for teamwork. But really, it doesn't depend on anything OOP in the strict sense.

I try really hard not to. So far it's worked!

MVU doesn't need OOP though.

Yeah, assuming you are using something like C.

Are you by chance thinking of MVC?

MVU is more towards functional rather than imperative programming.

Not when using an OOP language like JavaScript, you are by definition using OOP constructs exposed as language fundamental types.

Reply on news.ycombinator.com