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
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
