[astrange]

> It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically.

Most good ideas are old school. Data is more powerful than code because it can be analyzed in more ways - for instance, you can extract all the UI and text from an app, localize and re-insert it, then verify the UI won't break, all without having to execute the app.

If it's all in code you may not be able to get to some of the views or even know it's there. This is called the rule of least power - an example of getting it wrong is C++ iostreams.

Of course I'm sure SwiftUI has solved this.

[tsss]

Bullshit, any language with a macro system can do this. LISPs in particular are known for being code and data at the same time and this idea is way more old school than XML. You could also make a DSL that builds something like an AST of your UI in a similar fashion to free monads.

It's no surprise that XML seemed more attractive when your alternatives were Java or, even worse, Objective C. But really both options are absolutely terrible.

Thankfully we are very slowly making some steps forward again with Swift.

[astrange]

But we don't want the data and code to be the same, we want the data to be less dynamic than the code. You can't find out what the UI of a Lisp program would be without executing the program. It has everything available all the time, which is bad and turns you into a Lisp weenie.

SwiftUI is using new Swift features sort of similar to Haskell's "do" notation, which isn't actually itself monads.

[infinite8s]

Well the oldest ideas are around the notion that code is data and should be manipulated as such (from the 50s).