Hacker News Reader

Comment by iamleppert | Hacker News Reader

The problem with these libraries are significant ramp up time. Unlike what the authors are claiming it’s not because it’s a difficult or greatly different mental model to grasp, it’s because the API is clunky and poorly designed. You’ll notice most of the popular and highly successful abstractions all share the common trait of being easy and quick to pick up.

It should be a red herring to anyone these days when they see demo code that looks completely unintuitive which purports to make something easier. If the author’s haven’t factored in ease of use and uptake it’s already failed at its first principles.

View on HN

> The problem with these libraries are significant ramp up time. Unlike what the authors are claiming it’s not because it’s a difficult or greatly different mental model to grasp, it’s because the API is clunky and poorly designed.

Regardless of the quality of API design, reactive programming (and by extension RxJS) does indeed require a different mental model, as it is a different model for the flow of a program.

> You’ll notice most of the popular and highly successful abstractions all share the common trait of being easy and quick to pick up.

That is subjective. I remember how many people found node's async callback style unintuitive and confusing on first sight, and I personally find (at least the core abstractions of) RxJS pretty intuitive.

> If the author’s haven’t factored in ease of use and uptake it’s already failed at its first principles.

Yes this is part of the goal with CONNECTIVE, to bridge the gap between the description of a reactive flow (the code) and the most intuitive way to think about it (a directed graph), so that the end-result would be much more easily readable and intuitive code. I would love to hear if you have any more specific feedback on this front.

I don't believe this is the 'most' intuitive. A spreadsheet is a directed graph but that's not how people think when they use it--they just write function expressions.

Svelte 3 does a better job of making it intuitive.

[0] https://svelte.dev/blog/svelte-3-rethinking-reactivity

> Svelte 3 does a better job of making it intuitive.

It might just as well be the case. Svelte is going is towards traditional reactive programming languages, which for example because of the implicit change propagation, typically bare the possibility of glitches, which translates into unreliability on the most basic level of the program. I do not know how Svelte 3 handles glitches (or change propagation for that matter), but am just mentioning this as a one of the hurdles of that approach that actually makes it less intuitive (though definitely it looks more magical).

> A spreadsheet is a directed graph but that's not how people think when they use it--they just write function expressions.

That is true, though people also do not utilize spreadsheets to even one percent of what is possible to do with them, mostly due to the fact that the representation masks the directed graph and makes it harder for people to think of a little bit more complex things they can achieve with it. Saying this as a person who (with a friend) has created a full-blown CRM using google sheets.

> I don't believe this is the 'most' intuitive.

I can't (and didn't) claim it is either. I just suspect it is a really intuitive model since it reflects the actuality of what is being programmed.

EDIT: on closer inspection of Svelte 3's implementation of reactivity, it seems that they are not actually implementing support for reactive programming, just keeping the DOM reactive to variable changes in a transient way. This of course means that it will (most probably) not result in glitches, since its not true reactive programming.

On this front it is notable that:

1) CONNECTIVE (and RxJS) are general-purpose libraries, not just for front-end, 2) I suspect that mere DOM reactivity of Svelte will also not hold up in more complex front-end settings, where you would need (and benefit from) proper reactive logic.

There is an implementation of functional reactive programming which is a shining beacon of easy learning curve and empowering the end user.

You can find it used widely in every successful company, and equally used by hobbyists and non-IT people around the world.

It's called "spreadsheet".

So, at least the root idea of the approach is viable.

I would beg to differ. The FRP aspect of a spreadsheet is not the aspect that is widely used. It is actually a pretty uncomfortable one for even many programmers, though for really simple cases it is possible to get used to it. Actually, for example imagine how powerful the extent of the FRP in something like Google sheets is, IF it was such a shining beacon of easy learning curve I would bet that it would be a really popular programming tool for at least organizational automation software, which it is not.

Like, well, edit a cell, have every dependent cell recomputed? I thought it's one of the killer features, if not the one.

The API looked pretty normal to me...

is this a good thing or a bad thing? like is it "The API looked pretty normal and understandable to me..." or is it like "The API does not seem to have anything special at all, why does this exist"?

A good thing.

Reply on news.ycombinator.com