Credit where it’s due, Microsoft’s CLR is a similar idea (many programming languages, one runtime / API library) but unfortunately they never got to do the cleansing operation that Cocoa offered. Well sort of, seeing as we have Carbon.

I’ve also been wondering about what would a new NextStep look like - i.e. NextStep/Obj-C/Interface Builder were state of the art in the early 90s, but in a lot of areas have been surpassed since, and of course some of the decisions were pragmatic (like C++, Obj-C was an answer to the problem of slow Smalltalk performance at the time, but VM technology has moved on a lot since then).

What would you get if you set out with the same intentions today?? (i.e. setting out to create an environment that made it easy to create desktop applications???).
I’m pretty certain you’d start with a current dynamic language rather than a C legacy.

The interesting point will come when / if we get new ‘Cocoa’ libraries implemented in languages other than ObjC - with toll-free bridging that starts to become possible.

I just Googled and found F-Script which is based on Smalltalk and apparently integrates very well with Objective C and Cocoa: http://www.fscript.org/

Etoile is also available and it looks like it’s a Smalltalk/Objective C bridge to GNUStep/NEXTStep: http://etoileos.com/etoile/

Rich, I get what you mean by reaching down the layers into the OS. Perhaps a good layer allows its guts to show when needed so that you can redefine the layer?

However! When it comes to interactive layouts and designs, there are whole new dimensions of complexity possible on top of static designs. Is HTML/JS/Flash enough for that? I’d say no—280 Slides is damn impressive, but it still does only a fraction of what Keynote does, and it does that through a (seriously impressive) series of hacks that cap its performance at, again, a fraction of its desktop counterpart.

That’s not to say it’s impossible to take some beautiful syntax and API and to fulfill the holy grail of “simple things simple; complex things possible.” I think Shoes has done a simply spectacular job of that for games. And while it can’t design a three-pane OS X interface with a toolbar and CoreAnimation and CoreWiggyWow, it’s not trying to!

Of course, HotCocoa is, and I think that might be a much harder challenge! Thanks for clarifying things, Rich—I think you’ve done great work here, and I think you’re on track to something truly awesome.

HotCocoa aims to simplify the simple things in Cocoa, but you can still drill down to the full Cocoa toolkit at any time. This is great. I think the only thing you’ve really got to be careful about is that confusion of “can I do this thing ruby-ishly?” A CamelCase -> under_scored converter would be truly sweet. Now that I examine HotCocoa more thoroughly, I see the vast majority of what it’s doing right now is constructors, so you’re in way better shape than you would be if you were trying to redefine large swaths of API.

Mostly, I wanted to bring up some Controversy to get a conversation going—and I’m glad that one has! For the record, I’d like to note that I think both Shoes and HotCocoa are The Bee’s Knees.

http://www.macruby.org/trac/wiki/HotCocoaMappings

Regarding your concern about remapping all of Cocoa’s API to idiomatic Ruby…that is not my goal. I want to map things where they make sense. When I started I began mapping any method I used to underscore from camelCase but I stopped doing that, and will likely revert mappings that simply do that. Laurent may come up with some magic switch to underscore all camelCased methods…but for now I am adding custom methods only where they actually make things more clear in the API.

As Jordan indicated HotCocoa is an attempt to mainly simplify the configuration of these classes, not create an abstraction layer to call through. In this way it is very unlike Shoes. Each HotCocoa method returns an instance of an Objective-C class #window => NSWindow, etc.

_why…I think the wall people are talking about, in things like WxWidgets, is when you want to take advantage of the complete API of a particular control on OS X, but Wx limits you to a subset which is cross-platform. These widget libraries go very deep, as you know, and although most of the time the shallows are perfect every once in a while you need to jump off the high-dive and in shallow water that’s quite a wall to hit.

But as for the concept of simplicity breaking down at a certain point, I would argue the contrary. Look at HTML. You have very few elements but people are able to build wildly complex things that wxWidgets or QT could never dream of. Yet HTML is far, far simpler than those. You have fewer things on hand to paint with. But it is less rigid, really. And that pays off hugely.

Maybe these other layers on top of HTML like SproutCore and — oh, there are others I’m sure — maybe those prove that HTML is too limited. One thing about Shoes though is that I think it could prove to be more extensible and easier to layer than HTML because Shoes uses methods where HTML would use tags. And you can’t just add tags to HTML, right?

I’m not arguing against HotCocoa at all. We’re all just out here feeling around for answers. Besides, Shoes is just for fun. But I still find myself wondering if there is a “wall”. I have heard tell of a “wall” and the wizards speculate that a “wall” may one day come down and keep the Shoesers from moving beyond it into the meadows, an obstacle with a very “wall”-like manner will descend… but, myself, I haven’t seen a wall at all!!

Idea: maybe it is an underground wall?

You’re right—that’s a correct alternative way to write it. I guess I’m just use to Rails and its =>-y style.