[MacRuby-devel] Hotcocoa design ethos

[Rich Morin]

The result we're looking for (IMHO) is a way to write Cocoa apps
that "look right" to Ruby programmers.  The number of Objective-C
programmers who don't work on OSX apps is vanishingly small.

By opening up OSX programming to MacBook-carrying Rubyists, Apple
can grow its developer base in relatively short order.  Jordan's
"artist cum programmer" folks may follow along, but the Rubyists
(and some book authors) will have to pave the way.

More than one step will be needed to bridge the gap between ObjC-
based OSX programming and the Ruby crew.  First, we need a Ruby
implementation with direct, efficient access to OSX functionality.
For example, it should be straightforward to read about the ObjC
API and then code up the appropriate MacRuby call(s).  MacRuby is
expected to provide this implementation.

However, this means that MacRuby code is going to look a lot like
transliterated ObjC.  Java and Objective-C programmers are inured
to their languages' verbosity (and downright inconvenience), so
they may not understand how WRONG this code looks to a Rubyist:

  "Programming in TSO is like kicking a dead whale down the beach"

  -- Ken Thompson

The first step in making MacRuby look reasonable to a Rubyist is
to reduce the verbosity of method names and arguments, fill in
common defaults, etc.  I see no problem with letting HotCocoa do
this, if it does so in a well-documented and -engineered fashion.


I would also be delighted to have HotCocoa provide high-level
abstractions for Cocoa (etc) functionality, cute ways to lay out
windows programmatically, etc.  My only real concern is that it
may become unwieldy, because it is trying to do too much.  So, I
might suggest a bit more modularity, along the lines of Merb...

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development