You can also define UI things in code in Cappuccino (as well as Obj-C).
IB is optional with Obj-C, and I imagine Atlas will be optional with Cappuccino.
I didn't say anything about IB generating code.
There are a few fundamental requirements for a language to allow for powerful abstractions. I think self-referentiality and closure (in the maths sense not in the CS sense: http://en.wikipedia.org/wiki/Closure_(mathematics) ) are among those requirements.
GUI tools are ages behind what today's programming languages can do in terms of abstraction. So I don't see why it should be a good idea to limit the expressiveness of my toolset by inserting static blobs or nibs of visual somethings everywhere.
To make it perfectly clear: I want to be able to insert a function in place of any static structure, anywhere! I don't want barriers that make this process more difficult. And that's what GUI builders do.
You say I can define UI things in code as well. Great, I'll gladly take that offer, thank you very much ;-)
People in this culture don't tend to build the kind of endless, mindless forms you're talking about. They build real apps.
And they don't generate code--they generate linked objects (freeze-dried in .nib/.xib and now .cib? files) that are unfrozen at runtime.
If you had to generate a whole bunch of mindless forms, you're right--metaprogramming solutions would be a big win.
Also, I think Atlas allows for the sort of abstractions you're looking for. It comes with a bunch of built in widgets which are great, certainly for prototypes and simple UIs, but even fairly advanced ones too. But if they're not good enough, or you have some custom widget/layout you can easily add it to Atlas as a plugin and treat it as if it were a built in component.
But I'm certainly interested in hearing more about the problems people have with these sort of tools.
Challenge: how could one make a visual version of abstraction? Would you say that there is no abstraction in templates?
Yes there is abstraction in templates. Templates typically let you indicate (visually or otherwise) what the static parts look like and where the dynamic parts go. That's it. We have done that forever. There's no progress. Templates don't describe interaction and that's what UIs are there for and it's the growing part of UI design.
Tool vendors have tried for many years to describe the interaction parts visually as well. But interaction is not inherently visual. A condition is not visual. A data transformation is not visual. Even the difference between two visual states is not visual itself.
It's a logical abstraction that manipulates visual objects. Mixing logic that manipulates visuals with the visuals themselves is not useful, and in terms of established software design principles it violates the separation of concerns.
Painting logic with a GUI builder is like entering a sine function by drawing squiggly lines on the screen.
Maybe we could create a better visual version of abstraction, but I don't feel it's the most promising direction to take in order to make abstraction more powerful.
I agree that visual programming seems to be one of the great failed dreams - lots of academics and practitioners tried it, and it just doesn't seem to work. Although, the crop of XML-mappers (mapforce, biztalk mapper) do represent simple functions in a visual language, and seem to own that market. I agree it's not serious programming, but more "coding for non-coders" (and it's marketed as such). Yet, it has a place - this time, for business analysts. There are non-programmers everywhere who need to do some kind of coding - and creating a safe, useful tool for them is worthwhile. And maybe even for coders sometimes, if (and only if) the task really doesn't need serious programming. Examples: make; regular expressions; paths; printf/scanf; JSON; HTML (though these mini-languages aren't visual, they also aren't suitable for serious programming). I'd add SQL, bash, sed and awk, but they are powerful enough; just awkward.
I was intrigued by your suggestion that one can't abstract a visual language. While there are templates, maybe one can do better. The anchors and widgets changing the placement on resize are a kind of abstraction - but you're right, you can't make your own abstractions. No one's done it - it doesn't mean there isn't a way to do it. Maybe there is.
However, for interaction, I think you're pretty right. Although some standard styles of interaction, and standard ways of generalizing/abstracting them could be captured, you can't have create new styles or generalizations using this system. It isn't powerful enough.
> Maybe we could create a better visual version of abstraction, but I don't feel it's the most promising direction to take in order to make abstraction more powerful.
The thing about visual programming is that it helps people. I agree it's unlikely to make abstraction more powerful (though with pure research you don't know what you'll find). I think it would be really cool to create visual abstraction, that is usable and intuitive, when it seemed impossible.
PS: just a thought: if an "interaction" a kind of mapping where by if you do X, then Y happens, could that not be represented in the same visual way that XML mappers use (above)? Functional abstraction could also be represented as a visual mapping - but it certainly is not a natural or intuitive form for it.
What's important, though, is that these people don't build UIs. First and foremost they manipulate or analyse data. The data is at the center. The important thing is a simple data model that follows the closure principle (filter tables and you get tables, filter text and you get text). The UI is there to support this simple data model and it has to be similarly reductionist I think. Placing arbitrary UI widgets on forms is not the way to do this.
Yes, more fundamental research please :-) Maybe machine learning could be used to let users correct the system's guesses rather than initiating some action. That would go further in the direction that graphical UIs have begun, which is to let users select from what is offered to them and react instead of making them give commands to the system.
Or maybe some of the thinking that has gone into computer games would be useful, I don't know.
I like your point about users "reacting" to an limited range of choices, explicitly stated (and surely using domain specific terminology). It's a grammar you don't have to internalize, with libraries you don't have to know about, or know the search terms to find term. It's very "discoverable", and the limited and clear range of choices minimizes the information content (increasing the probability of obtaining the desired outcome). I'm sure it would also prune the tree by omitting choice combinations that don't make sense.
I think people don't like the system guessing for you, like Office's Clippy. Maybe it's OK if the user asks for the guess - like getting a list of search results; or vim/bash completion; or suggestions (google, Stackoverflow)
LabView is pretty powerful. Commercial, expensive, often annoying -- but pretty powerful. Integrates very cleanly w/ Visual Studio for text-based programming, too.
The aim, of course, is for the designer to generate the exact look and feel for the wireframes and render them (using Catalyst) to MXML for the Adobe Flash/Flex developer to code in the behavior/functionality. Catalyst will require Flex Builder 4 (which will not be out until 2nd half of 2009).
http://labs.adobe.com/technologies/flashcatalyst/
FXG (the interchange format spec):
http://opensource.adobe.com/wiki/display/flexsdk/FXG+1.0+Spe...
As an aside, I work on a large project (at least 10 UI developers) that uses Flex. We don't even use the GUI builder.
OTOH, there's an argument that standard interaction is a good thing, so maybe a lack of customization/abstraction isn't so bad?
(That goes for any other Flex developers here as well. Seems that the intersection between HN readers and Flex developers is pretty small!)
I'm not sure how Atlas works, but on the mac code is not Generated in the way you are thinking. You should really check it out.
The usual criticism is that they generate awful code, but that's not necessarily the case. The problem is really that these tools ask you to keep clicking on lots of little sliders and lines and bars and shapes and then click over there in that text box to enter a name and then select this or that from a list or menu, wait until that three pixel graphic changes its shape into a handle so you can drag that line over here, etc, and there's no way to automate this.
It's a matter of taste whether you like to do it that way when you create _one_ form, but once you create an application or two or three you have to abstract from the repeating patterns and you can't do that with the GUI builder.
GUI builders make you stay on the same level of abstraction forever because they don't have the equivalent of meta programming or even just plain procedural programming.
The reason why code built with GUI builders is so awful is not so much that they necessarily generate bad code. It's that developers who can put up with repeating the same clicks and drags on the same level of abstraction for years and years are in the wrong profession and create bad code regardless of the tools.
Programming is all about abstracting and automating stuff. The pinnacle of GUI builder based abstraction is what Microsoft calls "user controls". All they abstract is a bunch of widgets statically glued together on a panel. Great, but that's like 5% of what you want to do.
I'm afraid GUI builders are hopeless for any serious programming.