61,001 karma · joined March 30, 2012
http://www.metaobject.com/
http://objective.st/
1. The UI tells the model to change.
2. The model does the change and possible related changes.
3. The model notifies the UI that something has changed.
4. The UI updates itself from the model.
Alas almost nobody does MVC, despite calling what they do MVC.
UI is also very much not functional, and in fact the lack of progress in UI the last 30-40 years can largely be traced to trying to create UI with procedural/functional programming languages, an instance of linguistic-architectural mismatch.
Further reading:
Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering -- Stéphane Chatty.
https://link.springer.com/chapter/10.1007/978-3-540-92698-6_...
Can Programmers Escape the Gentle Tyranny of call/return?
https://2020.programming-conference.org/details/salon-2020-p...
UIs Are Not Pure Functions of the Model - React.js and Cocoa Side by Side
https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status
https://2024.splashcon.org/details/splash-2024-Onward-papers...
If you think your compiler will respect your code's semantics, you might be in for a rude awakening.
And there are certainly ways of influencing an LLM to be "more deterministic".
So the statement not only makes sense, it is fully inclusive of your claimed boundary condition of "completely vs. not at all". Last I checked, "not at all deterministic" is, in fact, "far less deterministic" than "completely deterministic".
YMMV.
¯\_(ツ)_/¯
Or as the poster put it
> When seeing the title of this post, I bet in some people's minds, the first thought was "Rust devs!". This connection is not unfounded.
Exactly. The Rust community has been very holier-than-thou on the memory safety front and quite absolutist ("how dare you code in non-Rust, don't you care about memory safety? You must be a bad person").
Now that it turns out that there is an alternative that is even safer, we suddenly get "well, it's a bit more complicated, memory safety isn't everything, you have to look at the broader context and requirements"
Excellent!
Glad you've come around to that point of view, dear Rust community. Now let's have civilized discussions about trade-offs.
Our programming languages are far too low level, and have been for a long time.
I've long held this view, LLMs are fairly clear evidence that this is true, because it looks like the much, much more compact prompt(s) have enough information content to create a much larger program in our current languages.
So it should be possible to create a non-natural language with the same information density.
IMHO, the key here is "coding" and "the spec".
The coding we used to do and that LLMs now do so well has exactly the same status as the coding that was referenced in the 1958 FORTRAN report and that was eliminated by coding.
That sort of (assembly language) coding to the spec that "the programmers" delivered to "the coders" was replaced by the programmers writing the spec in FORTRAN and the compiler doing the coding.
Except that human language quickly morphed to follow the reality, and after that "coding" was writing programs in FORTRAN. And later C, PL/I, Algol(?), C++, Smalltalk, BASIC, etc.
And people only very rarely look at the output of their compiler.
So in some case, the shift to LLMs and "no-look" coding is just the same old same-old, shifted one level higher.
Except we don't actually have a new FORTRAN for this era. The new FORTRAN is natural language, in most cases English. And that's both convenient and also troubling. Because the translation from English to code, wether it is high-level code or low-level code is far less deterministic than the translation from C or FORTRAN to machine code.
And that leaves us in a bit of a pickle, not least of which is what to check into source control: the prompt that we can't be sure will ever yield the same program again, or the "source" code that we never looked at (and isn't really "source" code at all).
As a language nerd, I find some of the concepts interesting, though pervasive use of failure has been tried in Icon and didn't work out well.
I am really struggling to see how
a) the weird bits lead to concrete improvements in actual programming practice
b) that translates to "scripting" usage.
But yeah: it'll be interesting, however it turns out.
So: better modularity.
https://blog.metaobject.com/2019/02/why-architecture-oriente...
For "ideas", substitute "code in a higher level language". At least if we actually want to control the ideas. Right now, with those ideas expressed only in English, our control is limited.
What LLM coding does is generate lots of code from a fairly small English (natural language) prompt.
If you look closely, I think you'll see that this is two processes:
1. Translate from fuzzy English to precise machine-executable language
2. Translate from high-level description to lots of low-level code.
Although these two are still pretty great when they are mashed-together, I think they'd be even better, lots better, if we could separate them.
But today we cannot.
I've also had reasonable success with the models generating fairly idiomatic Objective-Smalltalk, my own language of which there are likely few to no examples in the training data.
I do steer them towards my own sample programs.
I found this to be far less of a prblen than I thought it would be.
Do you have practical experience?
The type safety we gave up hasn’t been noticeable in any concrete way yet, especially considering our test coverage has never been better.
Did you mean APL?
Closely followed by nuclear.
In the first half of 2026, nuclear was the #1 electricity source in Europe, by quite a margin.
Citation needed.
China reportedly builds the CAP-1400, a localized and uprated version of the passively safe Westinghouse AP-1000, in 5 years and for around $3.5 billion.
Serial production of a known-good design with a savvy workforce rocks!
If those reported numbers are correct, which I cannot verify, they can profitably sell that electricy at 2 cents/kWh or below.
https://www.afr.com/policy/energy-and-climate/the-flaws-in-c...
https://theconversation.com/known-unknowns-controversy-over-...
Here's what Lazard actually says:
“We do not, in this study, try to cost out new nuclear” (2:35)
“We think nuclear will be a big part of the future” (2:47)
“the costs of nuclear should go down “ (12:54)
“next five to 10 years the nuclear bar the one that's most likely to change the most in in terms of cost reduction” (14:06)
https://www.youtube.com/watch?v=16HVh_Fx6LQ
And to claim this is the "low end" is a bald-faced lie.
They used a single nuclear power plant that was the most expensive nuclear power plant ever built in the US and one of the 3 most expensive in the world, ever. Of course, they note that this is the case, and that this is unrepresentative. Alas, all the anti-nuclear activists quoting Lazard are not this honest.
What's even better is to recycle it, because 95% of the original energy is still in the "waste". And when you do use all of it, the remainder remains radioactive for a much shorter period of time.
In Fukushima, there were no radiation deaths, and the long term effects of radiation on the population will be undetectable. The deaths that did occur were due to the unnecessary evacuations.
https://www.sciencedirect.com/science/article/pii/S095758201...
So due to Radiophobia, not radiation.
https://en.wikipedia.org/wiki/Radiophobia
The forced evacuation of 154,000 people ″was not justified by the relatively moderate radiation levels″, but was ordered because ″the government basically panicked″
https://www.nytimes.com/2015/09/22/science/when-radiation-is...
Personal note: the Fukushima accident turned me from a nuclear skeptic to a nuclear supporter. This happened quite a bit. At least for people who actually paid attention.
https://www.theguardian.com/commentisfree/2011/mar/21/pro-nu...
And remember that this was all due to a historically unprecedented earthquake and Tsunami that killed 18000 people and caused half a trillion dollars in damage (in 2025 dollars).
https://en.wikipedia.org/wiki/2011_Tōhoku_earthquake_and_tsu...
During that earthquake, more people died due to breaking dams than of radiation in that natural disaster. Are we dismantling our dams?
There is no 100% safe technology. Nuclear power is the safest form of electricity generation we have, although solar and wind are so close that the differences don't really matter.
According to this NASA study, nuclear power saved 1,8 million lives up to 2011, with many millions more lives saved in the future.
https://www.giss.nasa.gov/pubs/abs/kh05000e.html
On the flip-side, the most consequential negative health effects of Chernobyl and Fukushima came from turning off nuclear power plants and not building more.
https://www.sciencedirect.com/science/article/pii/S030142151...
If the US and the rest of Europe follow Germany's example they could lose the chance to prevent over 200,000 deaths and 14,000 MtCO2 emissions by 2035.
https://www.sciencespo.fr/department-economics/sites/science...
We estimate that the decline in NPP caused by Chernobyl led to the loss of approximately 141 million expected life years in the U.S., 33 in the U.K. and 318 million globally
And we absolutly know how to deal with the waste, and it's not particularly difficult. In fact, we have multiple ways of disposing of the small amounts of waste. NPPs are very secure against terrorism.
I am convinced we have done exactly the opposite: encode structures and particularly connections as sequences of operations over time.
Which are much harder to comprehend.
A lot of software is what I call accidentally algorithmic.
You're welcome!
> in-process implies exactly the absence of the isolation guarantees that OOP!Kay and microservices share.
OOP objects are in-process and are isolated using language mechanisms rather than machine/process boundaries.
Citation needed.
TFA quotes him saying almost the opposite:
> (I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)
Except that Kay did not envision the distinct computers communicating via REST.
https://blog.metaobject.com/2019/11/what-alan-kay-got-wrong-...
Also: microservices currently require at least process and frequently even VM/Container/Machine boundaries.
In-Process REST scales that down:
https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...
Language support for In-Process REST: