mpweiher

There has been reporting on this in many places. Here is one:

https://packaging-journal.de/en/eu-commission-wants-to-scrap...

"According to the Händlerbund, the European Commission's proposal to abolish the requirement has been on the table since December 2025. However, discussions in the Council of the EU were suspended a few weeks ago after a majority of member states spoke out against it."

"A restricted version is currently being discussed in the European Parliament. According to this, an exemption is only to apply to micro-enterprises with up to 49 employees and an annual turnover of a maximum of 10 million euros. A first reading is scheduled for October 2026 at the earliest."

A couple of things to note:

1. The EU commission wanted a single central registry

2. It was the member states, via the Council of Ministers, that torpedoed this.

3. The EU now advises its member states to not implement/enforce this

4. Until the correction, which is on its way, can be fully enacted.

So the same old same old: member states do shitty stuff and blame the EU.

Cool idea, but let's take it to the next step:

What if the "pseudocode" were real code, but in a higher level language than we have today that can actually be compiled deterministically?

The convenience of having the thing in your pocket or on your local machine without having to worry about a network connection, sign up, payment, privacy issues etc. cannot be beat.

The efficiency doesn't matter as long as it's good enough, because you already have the computer.

"The counterpoint is that specifications are closer to informal requirements than implementations are (and thus a mistake is easier to spot)."

I found exactly the opposite to be true when I took formal verification at university, and that was the major point that made formal specification / verification unattractive to me.

Yep, for example for predicting future access patterns in a VM subsystem.

Practical Prefetching via Data Compression; Vitter, Krishnam, Curewitz. 1993

The page addresses ('names') were the characters and the built-up LZ dictionary used to predict which "characters" → pages would come next.

https://www.ittc.ku.edu/~jsv/Papers/CKV93.practical-prefetch...

Optimal Prediction for Prefecting in the Worst Case; Vitter, Krishnan

https://dl.acm.org/doi/pdf/10.5555/314464.314575

Apparently the same trick was later rediscovered for web-pages.

Objective-Smalltalk with Interscript. https://objective.st

It ain't a version of Squeak, though.

> Well, [throwing away the complete rendered graphics] is what "retained mode" GUIs (i.e. those using control/widget trees and such) do too.

That turns out not to be the case.

The widget tree is retained.

When changes come in, the resulting damage from those changes is assessed and then the damaged parts are redrawn in an optimized fashion.

https://developer.apple.com/documentation/AppKit/NSView/draw...

No. Just that within the Apple ecosystem, the terms were used in a specific way.

Apple GC is a form of GC. There is no redefinition going on. It is correct.

However, it is ridiculous to say "we will replace garbage collection with garbage collection" and it is too cumbersome to say "we will replace reference counting garbage collection with tracing garbage collection".

Both "garbage collection" for the tracing garbage collection mechanism and "reference counting" for the reference-counting garbage collection mechanism are correct uses of terminology.

Using these shorthands instead of either the cumbersome complete terms or the confusing other shorthand is perfectly fine.

Although admittedly some Apple zealots started insisting that the Apple shorthands were the correct terminology. Or that programs that were broken by the broken GC had always been broken. Or that what Apple calls "MVC" is actually the correct definition of MVC when it is not.

https://blog.metaobject.com/2015/04/model-widget-controller-...

https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...

> until they saw the Objective-C adoption numbers were high enough.

Nope. Until they saw that (a) CocoaJava was a complete dud, not just technically, but also in terms of developers buy in and (b) Cocoa/ObjC was accepted well by a large part of the dev community.

> > "Garbage collection is deprecated in OS X 10.8. Use ARC

> ARC is garbage collection,

In terms of the Apple ecosystem, "Garbage Collection" refers to the failed attempt to introduce a tracing garbage collector. Apple/OSX always had reference counting (introduced by NeXT pre-acquisition with Foundation in EOF and later in OPENSTEP 4.0), which technically is also a form of garbage collection, but again in this case the terms are distinct.

> So they need to sell ARC as the great saviour, so much better than "GC".

Again, in the Apple ecosystem, "Garbage Collection" always referred to the tracing collector, even before they had to abandon it due to it not working.

And ARC is markedly better than their GC, but only arguable and at best marginally better than the reference counting they had pre-GC, and in some significant sense worse. Which is why I generally don't use ARC. For my style of programming the benefits are minuscule and the drawbacks real.

> CocoaJava was when they were not certain devs educated in C++ and Object Pascal would ever accept Objective-C.

They actually went all in on CocoaJava. I was there for the WWDC.

> Garbage collection is still there

"Garbage collection is deprecated in OS X 10.8. Use ARC instead—see Transitioning to ARC Release Notes."

https://developer.apple.com/documentation/foundation/nsgarba...

Because the UI is supposed to be stable.

That's pretty much where immediate mode GUIs and to a less extent React came from. (Though for React the provenance is probably closer to the HTML web-app: send request - update model - return HTML with complete and completely new UI.)

The difference is that for most games, throwing away the complete rendered graphics and re-rendering from the world model is often the right approach.

For most UIs, it isn't, unless they really are very close to video games, for example mostly passive feed readers, video players etc.

Happy to rename my stuff "Objective-Swift" :-)

> I like my Controller to be responsible for all the "business logic" so that its all in one place.

Business logic is supposed to go in the model. All of it. Because it's the important part.

Controller these days can be largely empty.

"MODELS Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.

There should be a one-to-one correspondence between the model and its parts on the one hand, and the represented world as perceived by the owner of the model on the other hand. The nodes of a model should therefore represent an identifiable part of the problem.

The nodes of a model should all be on the same problem level, it is confusing and considered bad form to mix problem-oriented nodes (e.g. calendar appointments) with implementation details (e.g. paragraphs)."

https://web.archive.org/web/20090424042645/http://heim.ifi.u...

>How do you handle UI state vs. underlying data (model) state, and dependencies between them?

I don't. And I don't have to, as I delegate that sort of stuff (mostly) to Cocoa/CocoaTouch etc.

https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

When you have stateful view objects, these stateful view objects maintain the view state. When updating themselves with new data due to a ModelDidChange notification, they take care of reconciling their current display state with the underlying model state.

> When displaying a scrollable and selectable list of items

So for example an NSTableView or NSCollectionView. I personally use a subclass that interacts directly with a table representation, meaning a lot of the glue code that Cocoa(Touch) requires disappears.

> Who updates the UI state accordingly to make it valid again?

Always the view. Who else?

> In the general case, application code needs to be involved in choosing the desired valid UI state when the underlying model state changes.

How so? The view is always a reflection of the model data. Whether that is a "change" is actually mostly irrelevant, even though the notification is called ModelDidChange in my case. In Smalltalk MVC it is the #changed message. It means "you are out of date, please make yourself reflect the model".

This same mechanism also handles the model being changed by some other party without any further code. "The model has changed, please update yourself to reflect the current state of the model". That's it, modulo optimizations.

> How is the corresponding application code prevented from triggering further events?

Model code isn't involved. A ModelDidChange event is only triggered when...er...the model changes.

That said nothing prevents you from manually invoking the ModelDidChange notification, just like nothing prevents you from calling abort(), running an infinite loop, creating an unbounded recursion or reading from /dev/random until it is exhausted ...

Doing it by accident, though, is very hard, because it just isn't part of the programming model.

Common misconception, but nope.

The quote is from the original definition by Trygve Reenskaug, the inventor of MVC (see link above).

https://en.wikipedia.org/wiki/Trygve_Reenskaug

Here some more on that misconception:

https://blog.metaobject.com/2015/04/model-widget-controller-...

> For example, sync updates 100 items in a list changing their titles. Items are bound to a list in the UI. Thus, 100 unique title update events triggered.

Those "updates" go in the queue. When the UI gets around to updating itself, it looks at the queue and invalidates all the UI elements that refer to the model items in the queue.

It then updates those elements, using the coarsening to update larger elements in bulk if that becomes better.

> Button clicked -> model change -> view update -> new event triggered -> model or view updated again

Once again, that is not allowed. View updates are not allowed to trigger any events in MVC. A model → view update updates the view. That's it.

The only event is "model changed", so it also doesn't make sense for the view to generate those events.

Many, though I have to start with this disclaimer: I still don't fully understand why Objective-C is such a sweet spot.

One very important one is that, empirically, it showed how much of what we think we know about language design is ... shall we say ... "incomplete".

After all, Objective-C is a car-crash of a language: take some Smalltalk and jam it into C. Done. How can you write software with this? And yet NeXTStep and Cocoa/CocoaTouch, arguably the most elegant pieces of OS-level/UI-framework software ever, were written in Objective-C. And not despite of it, but because of it.

From a safety standpoint, it's hard to see how you can get worse: all the static type safety of Smalltalk (none) combined with the memory safety of C (none). And these interact.

And while it certainly is possible to use it very, very badly, in practice I haven't seen the horrors that we are supposed to get.

https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi...

As an example, we got the same level of improvement from doing an Objective-C → Objective-C rewrite with Wunderlist (from WL2 to WL3) that others claim for Objective-C to Swift transitions.

Also, dynamic messaging is said to be slow, yet Objective-C programs consistently outperform the much more static Swift ones.

https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...

And of course, we all know that to do dynamic OO, you need a large runtime and better yet a VM. But it turns out that you can get much if not all of it with a tiny sliver of an extension to portable PDP-11 assembly language.

https://blog.metaobject.com/2024/08/objective-c-is-just-like...

With so much being provided by so little, you can actually put the rest of the language design space to better use, IMHO:

https://objective.st

You obviously have some very non-standard definitions at work here. apply/map/collect are just higher order operations, they have nothing to do with reification, except that you need the functions that are arguments to be first class.

> dataflow programming is almost always considered functional programming

That turns out not to be the case. Dataflow programming shares some aspects with functional programming, they are not the same at all.

> Object oriented, by contrast, is all about hidden state and mutation.

That also turns out not to be the case at all. Heck, there were even object-functional programming languages.

> And increasing evidence suggests that MVC doesn't work beautifully today because it doesn't parallelize,

What does MVC have to do with parallelization, in your humble opinion?

> Swift should have been a modernized Objective-C. It should have kept the best parts of it, which made it a joy to use, and leave the archaic and the weird things behind.

That's what Objective-Smalltalk is, or rather, what it started out as.

https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...

It has now gone further to actually implement Brad Cox's idea of a "Software IC", by taking on ideas from software architecture and metaobject protocols.

https://2024.splashcon.org/details/splash-2024-Onward-papers...

> SwiftUI, should have been a rendering template/library integrated with UIKit.

Do you mean it should have used some sort of XML-ish/HTML-ish templating mechanism? For Interscript, I keep looking at that approach, but so far haven't gone down that road (except for HTMXNative, but there it actually is HTML, so...).

> Swift should have just been a much improved syntax over that same runtime

That's exactly how Objective-Smalltalk started, and it's still very good at being just that.

https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...

However, it has grown to be, er, a bit more.

https://2024.splashcon.org/details/splash-2024-Onward-papers...

https://objective.st

> SwiftUI should have unapologetically been a convenient, reactive wrapper over UIKit and AppKit,

I am also working on a UI "framework" I call InterScript that is (for starters) a wrapper over UIKit and AppKit, and basically solves what I perceive to be the biggest problems of Cocoa:

1. UI specification using object literals. This makes UI-creation very compact and readable. The following example (mostly) reproduces a SwiftUI "Form" example from Apple documentation:

    #Grid{ frame: (20@20 extent: 400@340), #rows: [
       [ #Label{ text: 'Name' },          #TextField{ stringValue: 'Taylor', frame: (200@24) } ],
       [ #Label{ text: 'Email' },         #TextField{ stringValue: 'taylor@example.com', frame: (200@24) } ],
       [ #Label{ text: 'Notifications' }, #NSSwitch{ state: 1 } ],
       [ #Label{ text: 'Sounds' },        #NSSwitch{ state: 1 } ],
       [ #Label{ text: 'Summary' },       #PopUp{ items: [ 'Daily', 'Weekly', 'Monthly' ] } ],
       [ #Label{ text: 'Color scheme' },  #NSSegmentedControl{ segments: [ 'System', 'Light', 'Dark' ] } ],
       [ #Label{ text: 'Text size' },     #Label{ text: 'Default' } ],
       [ #Button{ title: 'Reset All Settings' } ],
    ] }.
   

There are actually even better ways of accomplishing this, but this should give you an idea.

2. Better communication between model and UI by using the support in the language for polymorphic identifiers and dataflow. Because dataflow is in the language, it can be expressed succinctly without making it hidden magic like in SwiftUI. With dataflow and polymorphic identifiers, you also get a dataflow-constraint mechanism similar to Cocoa Bindings, but again with proper support and less magic.

Essentially the solution to this:

https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an...

There is more, for example cross-platform, MDA/Naked Objects/Direct2Web style simplification and web integration with HTMX and HTMXNative.

>> UI is also very much not functional,

> I disagree, and I believe that the complete stagnation of GUIs is due to ignoring this.

I disagree with your assessment.

>Description->Pack->Apply events->Generate assets->Render assets.

1. What does that even mean? I don't see a UI in there at all, at best some graphics (Render).

2. That's not "functional". If anything, it looks like a pipeline, so dataflow. But then again, see (1)

3. Not sure why reification, that is turning things into objects, is functional to you. Reification, that is turning things into objects, is object-oriented.

4. MVC was actually created on 5.8 MHz machines with 128KB of RAM (including the display buffer). And still works beautifully today.

https://en.wikipedia.org/wiki/Xerox_Alto

"A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter."

https://web.archive.org/web/20090424042645/http://heim.ifi.u...

View and model are related, but neither is procedurally dominated by the other. The view is not a subroutine of the model, or vice versa.

They are related entities that communicate in order for the view to function as a representation of its model to the user, and for the model to be manipulated by the user.

To get the details I really recommend the Chatty paper. It is a bit hard to read, but delivers the goods.

Yes, they don't ever openly admit mistakes.

But they do quietly drop or fix them, covertly acknowledging they were mistakes. Often with this messaging: "we have this new shiny thing that is even better than the old shiny thing (that was really a turd)".

Remember "garbage collection"? Or "modern syntax"? Or CocoaJava?

And with hardware they had their "come to Jesus" moment a while ago. And then hit it out of the ballpark with Apple Silicon.

The one for software is still upcoming.

Dude, what I describe is exactly MVC.

Your interpretation is a common misconception, for example promulgated by Apple. It is not MVC.

https://blog.metaobject.com/2015/04/model-widget-controller-...

https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...

"A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. "

https://web.archive.org/web/20090424042645/http://heim.ifi.u...

Yes and no.

Conceptually, the UI re-renders itself completely in order to always be an accurate reflection of the model.

That is the #1 job of the view: be an accurate reflection of the model.

And re-rendering itself completely is a safe way to implement that requirement.

However, the UI can also look at the model in more detail and figure out what parts need to change, as long as the effect is the same as re-rendering everything.

And the model can tell the view that specific subparts of the model have changed to make that job easier for the view.

But if it can't figure out the details, the fallback is to re-render the entire view from the model. But not to recreate the view. The view sticks around.

One way of doing this optimization is "damage rects" like Cocoa does. Another are the polymorphic identifiers used in the update queue of Blackbird.

Yep, to anybody who actually knows MVC, the whole Elm/React/SwiftUI stuff is funny.

"We solved the problems of MVC by properly applying MVC".

https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...

Yeah, M-V-C are all roles, not concrete objects. The C mediates between the input devices and the model, but in practice views can and often do fulfill that role as well. Cocoa views, for example, also fulfill the C role.

Different formulations of M-V-C have the C deal with more complex interactions, with sequences of interactive prompts like wizards.

The update is essentially automatic, and yes: MVC already solved the "problem with MVC" React/Redux/Elm/SwiftUI claim to solve. In 1979.

I never claimed MVC is a silver bullet. Just that it solves "... incredibly easy to forget an edge case in your update logic."

> UI does not re-render itself too much?

Glad you asked! In my Blackbird reference architecture (which is an instance of MVC), I use a coalescing queue to capture the updates. The coalescing is two-level: first, simple duplicates are weeded out. Second, if the update queue gets very full, it becomes coarser-grained, and weeds out duplicates based on that coarser grain. This has multiple steps of grain up to "just re-render the whole UI". Worked like magic in Wunderlist. Except it wasn't magic at all and very simple, inspectable and tractable.

> step 4 UI triggers an event that your model happens to listen

That's not allowed in MVC.

> Because you rely on events how do you avoid “event hell”?

I don't "rely" on events and there is no "event hell". Events are only used in the M→V communication part and there are no subsequent triggers, because the only event is "the model has changed", with an optional payload specifying which part of the model. Important: it must not contain the data that changed, this the view has to fetch from the model once it processes the update event.

Since the only event used is "the model changed", the view cannot ever be a source of those events, so no "event hell".