Hacker News Reader

Comment by noelwelsh | Hacker News Reader

I'm confused by the discussion of OO. Just use an enum, aka algebraic data type, if you want control over the data. You can build an extension point into the ADT for user defined components, if that is desirable. The tradeoffs of OO style vs FP style vs having-your-cake-and-eating-it aka the expression problem are well studied. (This comment is a bit cryptic. Sorry. Don't have much time right now. Might return later.)

My experience using ECS in bevy is it feels like fancy spaghetti code. I'm not convinced it's a great approach, at least on the small scale I'm working at.

View on HN

>I'm confused by the discussion of OO

I don't think anyone's saying you can't do it without OO. Just that existing popular patterns for UI tend to rely on OO patterns like inheritance and classes with instances, and easy-ish namespacing and ownership concepts that map to those ideas.

So doing it without OO is harder, as it requires something different, that may be studied, but is less well explored and documented to the average person.

I recall similar discussions about doing UIs in C. GTK, for example, sort of fakes OO in C, I assume for related reasons.

All frameworks that I know for WebApps, don't rely on OO though.

React, Angular (esp. with ngrx), Svelte

Yew and Leptos don't fake oop either

>All frameworks that I know for WebApps, don't rely on OO though

Sure, though they rely on a lot of things that are only bundled with a web browser like the DOM and CSS and their concepts of namespacing, encapsulation features, etc.

Which concepts specifically?

Rust can provide encapsulation namespacing as well

Yes. Just saying there's less existing UI specific examples and material to draw from.

Please do return later and elaborate on what you mean by having-your-cake-and-eating-it aka the expression problem.

I'm super interested in this stuff and would like to hear more.

The expression problem is, roughly, how easy it is to extend a program without recompiling it.

OO is typically regarded as making it easier to extend the data types of a program, since you can introduce new ones by inheritance at any time. Whereas pure FP systems specify types exhaustively at definition.

FP typically makes it easier to extend the functions, since you can define arbitary more functions on the "public" type system; whereas OO encapsulates stuff and makes it harder to do that.

> You can build an extension point into the ADT for user defined components

I assume that means there are ways of making the pure-FP approach OO-like, and vice versa.

I think its nevertheless to speak about affordances here, and rust is in my view, one of the poorest DX/affordancey languages --- the syntax and semantics conspire to create lots of friction.

This friction isnt really considered in "the expression problem", but i think is very important in practice.

We should have a "frictionless expression problem" and I think that's the issue with rust: it doesnt frictionalessly extend in the ways needed by UI programming.

Thank you for taking the time to explain!

I agree with the sketch given in the sibling comment. I think this is the paper from which I learned this: https://www2.ccs.neu.edu/racket/pubs/icfp98-ff.pdf

Searching for "expression problem" should find other discussion of the problem and solutions. The two best known solutions to the expression problem are:

- data types a la carte, which takes an FP style approach; and - tagless final or object algebras, which takes an OO style approach.

Other solutions are possible depending on language features. E.g. the linked paper above uses mixins and units.

Overall I find the discussion in the original post to be a bit naive. It doesn't make the case that an OO approach is necessary or desirable. E.g. that an OO approach provides a form of extensibility that is needed.

In the FP world, if I wanted to build a UI toolkit I would start by defining by a combinator library (usually implemented as an algebraic data type) that describes the UI and then have an interpreter that constructs everything on the screen. This hides all the state within the interpreter, which makes it easier to avoid issues with the borrow checker. The OP didn't discuss this approach either.

Thank you for the explanation and linking the paper!

Reply on news.ycombinator.com