New Product From 280North: Atlas

Re:New Product From 280North: Atlas by gstar on Wednesday February 25, 2009 @05:02AM (#494195)

You've got some good points, but Interface Builder (and I imagine Atlas) departs fundamentally from VB and PowerBuilder in that the code doesn't live directly behind the GUI elements. Instead, it's connected by a series of inlets and outlets that are designed to allow for reusability and model-view-controller disconnect.

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.

[ Parent | on HN ]

Re:New Product From 280North: Atlas by ashleytowers on Wednesday February 25, 2009 @06:10AM (#494222)

To be precise Interface Builder doesn't actually generate ANY code at all. You are manipulating in-memory objects and setting their properties. When you save your UI it's effectively just a serialized form of the objects you were playing with.

[ Parent | on HN ]

Re:New Product From 280North: Atlas by gstar on Wednesday February 25, 2009 @07:06AM (#494262)

The key point that I was trying to make is that IB is fundamentally separate from the code that is running in the application. In traditional RAD tools like VB, Delphi and Powerbuilder the interface and application logic are one and the same, you literally have code behind each form and each UI element.

I didn't say anything about IB generating code.

[ Parent | on HN ]

Re:New Product From 280North: Atlas by ashleytowers on Wednesday February 25, 2009 @09:00AM (#494353)

Apologies - I read "in that the code doesn't live directly behind the GUI elements" as an inference that it lived somewhere else. I just wanted to add a clarification in case others read it the same way.

[ Parent | on HN ]

Re:New Product From 280North: Atlas by fauigerzigerk on Wednesday February 25, 2009 @08:44AM (#494333)

IB is a standard run-of-the-mill GUI builder. I found nothing in it that current versions of Microsoft tools don't do, quite the contrary. But the important thing is that separating code from the UI a bit better than VB did in 1992 is not what I mean by abstraction.

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 ;-)

[ Parent | on HN ]