I'd like to suggest that at least some of the problems associated with the term, for example the pomposity, are rooted in the "separation from programming" that is not just a suggestion, but an unfortunate fact of architecture today.

And I would further suggest that we could improve the situation if we could actually express our architectures in our programs, in our programming languages. Then software architecture wouldn't just be "deeply intertwined with programming", as it must be, but actually be part of programming and part of the program.

And once the architecture becomes part of the program, it becomes part of our feedback loops. My experience is that feedback loops are a good antidote to pomposity and great for building/evolving systems.

To do that, though, we have to retreat from this idea that software architecture must be fuzzy, an idea that IMNSHO is just a cope for the current sad state of affairs. We have pretty good definitions of architecture (connectors and components, systems, architectural styles, etc.), let's start using them in earnest and in our programs.

Very cool!

> But yes, lately I’ve been building mobile apps. ... What can I do?

I am currently building HTMXNative.

Together with Objective-Smalltalk, which has linguistic support for REST built-in.

The idea is that you create your model in a natural way and then thinly wrap it to deliver wherever.

Comments URL: https://news.ycombinator.com/item?id=48475292

Points: 2

# Comments: 0

- address space

- memory objects

- threads

Mix and match. A Task (process) is not a primitive, but a composite object combining address space with one or more threads. How you fill the address space with actual memory objects is up to you. Map from disk or COW your own address space...have fun!

https://developer.apple.com/library/archive/documentation/Da...

Comments URL: https://news.ycombinator.com/item?id=48432796

Points: 13

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=48425245

Points: 2

# Comments: 0

Code that is easy to test tends to be well-structured.

Code that is badly structured tends to be hard to test.

TDD is not a QA methodology, it is a design methodology. It also tends to help quality out a lot, but that's a secondary effect.

Comments URL: https://news.ycombinator.com/item?id=48408983

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48395022

Points: 1

# Comments: 0

It's one of those things that, like visual programming, is absolutely and obviously The Right Thing™ until you try to implement it and use it.

That said, we have made progress in both areas, and maybe we will figure them out in the future.

There certainly is lots and lots of potential.

Comments URL: https://news.ycombinator.com/item?id=48380764

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48372018

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48354317

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48348101

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48321678

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=48307967

Points: 2

# Comments: 0

What makes you think I trust Apple? So yes, that's very much a "you thing".

And SwiftUI is laughably bad. And my very early criticisms of Swift, for example, have panned out precisely as I predicted.

> > Every UI is always some mapping of the state.

> but it previously wasn't described as such.

Yes it was. Except this was seen as the obvious given that it is. Because, once again, a UI that is not a function (mapping) of the model is not a UI.

"In Smalltalk-80, a view is just a visual representation of a model" -- https://en.wikipedia.org/wiki/Model–view–controller#View

> IIRC, at the time, MVC had a common problem of controller bloat,

Nope. Non-MVC implementations had the problem of controller bloat, because they didn't actually implement MVC.

> the render function of the component is a 100% pure function of the state that the framework injects.

Except, as I've correctly pointed out: it's not.

[Advantages]

None of this is in any way specific ("The compiler". Seriously?) or clearly an advantage that can be tied to this type of framework. So yes: you're not even close to convincing me. Because there's no "there" there.

> the reason why this post rubs me the wrong way, is that you took a theoretical design document, misunderstood it for the actual, practical implementation

You misunderstood the post. Completely. The document claims "pure function". This is laughably false. The question is what is left when you remove "pure" from "pure function". And the answer to that is: nothing.

That doesn't mean there are no benefits, but the benefits cannot be "what you get from being a 100% pure function", because it ain't.

Just like the benefit of butter can't be "it's 100% fat free". Because it ain't.

And if you keep insisting that those are the benefits, then I don't know how to help you.

And again, it doesn't mean there are no benefits, but they are both smaller than and quite different from what you claim. And with the benefit being fairly small, the other question is what the cost is of pretending this is so when it is not. And the answer is: pretty high.

And it's funny that on the one hand you go with the same "well, you're taking the "100% pure" thing too literally", when just a few lines above, you yourself made "100% pure function" the defining characteristic.

So which is it? Make up your mind. It appears to be Schröding-important.

Any UI that actually is a UI is some sort of function of the state. Otherwise it is not a UI but random graphics and/or decoration.

Why do you think it would?

Did you misread my post as "ha ha, Apple does it differently and therefore react is wrong"?

If so, you certainly misread it a lot, and you have the wrong person. I have tons of posts about Apple getting things wrong.

Anyway, did you miss the following part?

I also think that despite all the flaws, react.js and react.native are currently eating native development's lunch.

Clearly I made the point in my post that this approach has a lot of mindspace, despite the obvious flaws, so not sure how you pointing out that this approach has a lot of mindspace invalidates my post.

> Hence ui = f(state).

Every UI is always some mapping of the state. Otherwise it isn't really a UI, is it? What would it be, in your opinion, if it didn't map the state?

> pure representation

What does "pure representation" mean to you? I covered in the post that it sure as hell isn't a pure function of the state. And cannot be.

Did you miss the part where David Abramov conceded that point?

To elaborate a bit, React components aren’t always “pure” in strict FP sense of the word. They’re also not always functions (although we’re adding a stateful function API as a preferred alternative to classes soon). Support for local state and side effects is absolutely a core feature of React components and not something we avoid for “purity”.

> This [ui=f(state)] gets you a metric ton of advantages,

Well, yes. Like being a working UI, for example, which is why MVC is also structured this way.

But can you elaborate the specific advantages you believe the react approach gives us over, say, MVC?

The post elaborates that it would be really nice if UI were a pure function of the state. But it just isn't. And trying to pretend that it is might seemingly buy you some of those advantages, but at a huge cost.

Emphatically yes. If you look at books written about the problem in the early 90s[1], they are still applicable today.

> The current solutions, although I find it hard to describe precisely, are always tantalizingly lacking in one way or another.

The best analysis of this I have seen so far is in Chatty's Programs = Data + Algorithms + Architecture: consequences for interactive software engineering [2]. It's a bit hard to get through, but absolutely worth it.

As a short summary, the problem is architectural, or more specifically linguistic/architectural mismatch: the architecture our "general purpose" programming languages induces, which is the call/return architectural style, does not match the architecture required for user interfaces, but rather conflicts with that style.

I also wrote about it in Can Programmers Escape the Gentle Tyranny of call/return?.

My current approach is to first build a programming language that can easily express alternative architectural styles: Objective-Smalltalk [4].

With that I am now working an a UI framework I call interscript, including HTMXNative and other goodies.

It seems to be working out...

[1] For example, Languages for developing user interfaces by Myers et al https://api.taylorfrancis.com/content/books/mono/download?id...

[2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...

[3] https://2020.programming-conference.org/details/salon-2020-p...

[4] https://objective.st