[MacRuby-devel] Hotcocoa design ethos

[Eloy Duran]

> 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:

That's simply because at that time they don't know any better.
But real rubyists will educate themselves is my experience.

>  "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.

Well actually there are a few problems with this:

- First of all, it would mean hundreds of man hours to create  
basically just shortcuts, and then also need to be maintained.

- Then there's the documentation part, you say “if it does so in a  
well-documented and -engineered fashion”.
    Which means: Someone will have to write documentation for the  
shortcuts _again_ because the docs already exist in Apple's Cocoa  
reference docs.
    Honestly, nobody would want to do that. Apple has a much better  
track record for keeping their docs up to date.

- Then there's the point I tried to make earlier, but apparently  
failed at:
    Say, hypothetically, that all of Cocoa would be wrapped in  
shortcuts and even docs would exist.
    Then at some point I would like to start using other OSS Objective- 
C code,
    should I ask the maintainers to write shortcuts for that as well?
    Or should I simply take the effort to learn the syntax used by  
idiomatic Objective-C? Which really only takes 1 afternoon.

Just to restate the last point:

Smart rubyists _will_ be able to figure out how to use Objective-C  
classes in 1 afternoon,
I have seen it happen many many times over the past years that I have  
been active in the RubyCocoa area.
(Lazy people don't. But my guess is this applies in all areas.)

After using it for a while, they _will_ figure out that it was best  
option to learn some Objective-C and cherish
the big API and it's documentation provided by Apple.
And let's not forget the wealth of info available through Google, all  
in Objective-C and it's verbose syntax.

> 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...


Like stated before, I hope HotCocoa will _only_ provide high level  
abstractions and maybe some shortcuts.
Not the other way around.

To put this all in perspective:
- I am a rubyist pur sang, not a Java/Objective-C programmer, and  
never used Cocoa before RubyCocoa.
- I too thought it would be a good idea to create ruby like syntax  
abstractions around all of Cocoa, but
   have realized after actually doing stuff that that would have been  
a cumbersome task.
   And more importantly, it would not have taught me to educate myself  
where needed.

- Eloy