The parallels you draw are very insightful,
especially if the next upgrade of Cocoa has optional garbage collection and CoreData can become slightly more EOF-like by having more built-in attribute data types and a larger set of connectable databases on the back end .

Per your suggestion, I'll give Rails and Ruby a try.

Change "then" to "rather than". Smile.

Would it stand to reason that Apple may (or could) work some magic to incorporate Ruby on Rails and WebObjects? Would it be out of the question? Beneficial? Practical?

M.T.

"Rails might just be a better fit for today's Mac OS X developers than WebObjects.".Rails is probably very nice but the Nextstep revolution was the tools like interface builder. The scripting developers and rails developers specifically seem to turn away from that and use the language more.I think cocoa and rails are therefor at two oposite sites of a debate and not comparable. I do think webobjects is going to have a hard time competing with jsf and sun studio creator.

"Rails might just be a better fit for today's Mac OS X developers than WebObjects.".Rails is probably very nice but the Nextstep revolution was the tools like interface builder. The scripting developers and rails developers specifically seem to turn away from that and use the language more.I think cocoa and rails are therefor at two oposite sites of a debate and not comparable. I do think webobjects is going to have a hard time competing with jsf and sun studio creator.

I don't think there are many parallels between Rails and Cocoa other than the fact that they're both APIs designed for dynamic (in varying amounts) languages. In particular, Cocoa has a much finer granularity for its building blocks, and is much more "design agnostic" than Rails.

Would it stand to reason that Apple may (or could) work some magic to incorporate Ruby on Rails and WebObjects?

You know, I actually considered this, but it's not clear how such a thing would work or who would benefit. There is undoutably value that is unique to WebObjects, but it I'm not sure how it would fit into Rails.

Rails is probably very nice but the Nextstep revolution was the tools like interface builder. The scripting developers and rails developers specifically seem to turn away from that and use the language more.

I see Cocoa as much more than Interface Builder. I also think the IB issue is less significant in a web environment. Rails has scaffolding, which tackles the same problem from a slightly different angle.

I think cocoa and rails are therefor at two oposite sites of a debate

Compared to what else is out there, Rails and Cocoa have a lot in common in terms of overall goals and the actual experience of sitting down to write an app. If you see WebObjects through the lens of WebBuilder and EOModeler, things will look different.

I do think webobjects is going to have a hard time competing with jsf and sun studio creator.

I think it's a moot point. It looks like there's a bit of a rebellion in the making against Java. That's not to say Java is going away anytime in the next decade, but momentum seems to be shifting to simpler, more accessible solutions.

I also don't think that Studio Creator (and, by extension, WebBuilder) is in line with the way most sites are created nowadays. Some larger companies may try to wedge their workflow into this kind of tool, but I don't think it's the type of approach that comes naturally at this point. Desktop and web apps just aren't the same thing.

In particular, Cocoa has a much finer granularity for its building blocks, and is much more "design agnostic" than Rails.

What do you mean by this?

"It looks like there's a bit of a rebellion in the making against Java."

I must say i find it easier to program and debug in java then in perl or python and probably also ruby and eclipse (a tool) makes me faster with java to. I think it is just that programmers like debugging half a day more than they like typing half a minute. It is like installing linux and x-windows a lot of nerds really like that to.

Regarding Cocoa being finer grained: each generally useful piece in Cocoa (NSWindow, NSButton, NSTableView, etc.) is made up of smaller, but equally useful pieces (NSView, NSControl, etc.) It's more finely grained than Rails. In Rails, the "top-level" abstractions like ActiveRecord are pretty much opaque (in that they aren't made of smaller, but also useful pieces).

As for being design agnostic, Rails is self-admittedly "opinionated software" that dictates (or at least "suggests very, very strongly") how you shall go about building a Rails app. Cocoa, on the other hand, is more in the tradition of general-purpose APIs where you're given the pieces and some ideas about how they could work together (usually under the umbrella of some other piece, like NSApplication), but not much else. Think Lego bricks vs. a model car kit.

I must say i find it easier to program and debug in java then in perl or python...
That's a pretty bold statement. I have more experience with python than either java or perl, but I tried the other two first and gave up - I could never get my head around java (I think you should be able to create a "Hello World" app without a textbook in any language after about a half hour of study. Java's syntax required way too much coding for me. Perl, on the other hand, is extrememly terse, and I found it easier to write slightly wordier scripts in python than to look up all of the cool functions in perl. The two things I like about python are that it's easy to learn, and that it's easy to read. Right now I'm working my way through a book on Cocoa with the intent of coding in PyObjC. Sorry if this is slightly off topic.

each generally useful piece in Cocoa (NSWindow, NSButton, NSTableView, etc.) is made up of smaller, but equally useful pieces (NSView, NSControl, etc.) It's more finely grained than Rails.

Having actually gone down the road of porting a framework from the desktop space to the web, I think it's a mistake to assume that you're solving the same sorts of problems and need the same kind of design. Having a browser wedged between the app and the user changes everything.

In Rails, the "top-level" abstractions like ActiveRecord are pretty much opaque (in that they aren't made of smaller, but also useful pieces).

Cocoa's counterpart to ActiveRecord is NSManagedObject. You really can't break a managed object down into separate parts but this doesn't prevent Core Data from being effective at what it sets out to do.

Rails is self-admittedly "opinionated software" that dictates (or at least "suggests very, very strongly") how you shall go about building a Rails app. Cocoa, on the other hand, is more in the tradition of general-purpose APIs

I don't think I could disagree more, especially when Core Data is factored in. You can certainly choose not to use the standard design patterns, Xcode's models or NIB files, but you'd be making just as much work for yourself as if you chose to go against the grain in Rails.

Maybe if you had some specific examples I'd get a better idea of what you're getting at.

NSManagedObject is a good example in that Cocoa existed, and was good and useful, long before NSManagedObject came along. NSManagedObject is just one more way to do things. Cocoa != NSManagedObject, and Cocoa - NSManagedObject is still Cocoa. But Rails - ActiveRecord is what, exactly? It'd be like removing NSView from Cocoa. But you have to go way down to the smaller pieces to render Cocoa "not Cocoa" whereas removing almost any piece of Rails makes it "no longer Rails."

(Also, a lot of the "opaqueness" of things like NSManagedObject comes from the closed-source nature. You can bet that CoreData is built using plenty of the smaller Cocoa bits, most of which are already in use in shipping, successful Cocoa apps. It just looks opaque because we can't see how it was done.)

So, that's what I mean by "granularity." Rails is few, large, essential pieces. Cocoa is many, small, generic pieces. Were Cocoa more Rails-like, the source code, structure, and logic of all Cocoa apps would look a lot more similar than they do.

There's been talk of integrating rails and core data.

http://wrath.rubyonrails.org/pipermail/rails-core/2006-February/000768.html

However it's not likely to hit the 1.1 release, perhaps in the future though.

"I think it is just that programmers like debugging half a day more than they like typing half a minute. It is like installing linux and x-windows a lot of nerds really like that to."

Of course, I can only speak for myself, but I have to disagree very strongly with this. Debugging can be extremely tiresome and I would prefer to do a minimum amount of it.

For me, I've found that the ability to write very terse code goes a long way to reducing time spent debugging. This is certainly something I have noticed while using ruby. Shorter, simpler code is much easier to read, interpret (how is it doing what) and debug.

Less time debugging means more time spent on design and actual implementation. Frankly I can't afford to spend half a day debugging if I can avoid it.

Shorter, simpler code is much easier to read, interpret (how is it doing what) and debug

I know a technical text / code is easier to read with a introduction / declarations. looking at a declaration of method in java tells you a lot. and you do not even need to follow the code!

I've found that the ability to write very terse code goes a long way to reducing time spent debugging

I found exactly the opposite. writing tests , splitting code into more smaller functions, using descriptive names thus writing more code reduces debugging time for me

Frankly I can't afford to spend half a day debugging if I can avoid it.

I agree. And that is a good reason to use java. You will type a lot more but debug less.

Cocoa != NSManagedObject, and Cocoa - NSManagedObject is still Cocoa. But Rails - ActiveRecord is what, exactly? It'd be like removing NSView from Cocoa

Hmmm, I think we just see things a bit differently.

I wouldn't judge ActiveRecord by the class declaration. I don't like dealing in the abstract for these things. My approach is to put it to use in an application using the recommended design patterns and see how well it works.

My personal experience with ActiveRecord is that it works quite well, and I haven't encountered any problems that I'd attribute to a shallow class hierarchy and/or limited compositing. In fact, I prefer a reserved design at this point, given the newness of the framework. I'd rather the class structure evolve naturally over time then have developers go crazy generating a web of code.

Certainly Cocoa and Rails are not identical, but I'm curious if you have specific issues with Rails that are due to class structure, or you'd just anticipate problems based on what you've seen?

I also really believe in recognizing that desktop and web apps are not the same thing. I know CEOs get all hyped up at the idea of app convergence, but it rarely pans out well. They're different mediums and I think they will be for at least a little while.

Were Cocoa more Rails-like, the source code, structure, and logic of all Cocoa apps would look a lot more similar than they do

Is that a bad thing? I think that's the direction we're heading in now with Core Data, Bindings and Xcode models.

<blockquote>Certainly Cocoa and Rails are not identical, but I'm curious if you have specific issues with Rails that are due to class structure, or you'd just anticipate problems based on what you've seen?</blockquote>

The world of problems that Rails is well-suited to solve is much smaller than Cocoa's. This isn't necessarily a bad thing, it just is what it is. For example, Rails assumes that the database schema does not exist beforehand, but is created to serve the app, and is managed according to the needs of the app. No, it's not "technically" a hard limitation since you can make Rails work with an existing db if you put in the effort, but it's clearly a poor fit.

Another example: Rails makes little effort to factor out common application model functionality into libraries that are reusable outside the web app itself. Most classes, if not outright assuming they're running in a Rails web environment, are at least decorated with features and methods that are specific to the web app. This is different than creating a completely generic data model and supporting classes, and then building a web app, offline batch jobs, a desktop app, etc. all on top of these generic libraries.

In general, Rails is up-front about its assumptions and limitations and scope of applicability. The less your app and dev environment is like the prototypical Rails app and company, the more "impedance mismatch" you'll experience while trying to use it.

For example, if you have a big, complex, preexisting database schema managed by a team of DBAs and accessed by many different apps owned by several different departments, Rails is probably not a great fit for your app.

Cocoa, on the other hand, has a much broader range of applicability, from NetNewsWire to Aperture, hobby/home-use apps to the Fortune 500 "enterprise" apps, or even games. As for Cocoa moving towards more sameness within apps, I think that's only true among apps that already do very similar things.

Cocoa is just much more mature and flexible than Rails. In a decade or so, if Rails is still kicking, maybe its toolset and range of applicability will have broadened. But maybe not, if the current design philosophy is still adhered to. Rails solves very specific problem in a particular environment. That's one of its greatest strengths, but also its most fundamental weakness.

I must say i find it easier to program and debug in java then in perl or python...
That's a pretty bold statement. I have more experience with python than either java or perl, but I tried the other two first and gave up - I could never get my head around java (I think you should be able to create a "Hello World" app without a textbook in any language after about a half hour of study.

He didn't say it's easier to learn Java than Perl or Python, he said it's easier to program and debug. He then cited tools. Having programmed extensively in Java and in Python, I can completely understand and agree with someone who says that it is easier to program in Java, and this is mainly due to the incredible tools support. And I'm a rabid Python fan. Also, no disrespect intended, but Java is a big language, and you need more than a half hour to understand some of the basics, including what's needed for a "Hello World". It's unfortunate that the initial learning curve is so steep, but once you get over it a lot of things start to make sense, as they tend to enforce consistency (such as starting a program from a static main method, or using a classpath instead of hardcoding file path references to libraries). Fortunately, Python, Ruby, and friends exist to let us write totally sweet well-designed OO programs without all that overhead required by Java.

Rails certainly has a leg up in that WebObjects hosting isn't as available or as cheap as Rails, and hosting WebObjects requires a license while Rails is free. I think Apple should release WebObjects for free and also offer cheap, minimal WebObjects hosting as part of the .Mac service.

If we're talking about WO & Rails, shouldn't the comparison being made be between ActiveRecord etc and EOF, rather than ActiveRecord and CoreData?

Anyway,

WebObjects is a great piece of software, but Rails has momentum and visibility. Apple is probably better off overall for highlighting Mac OS X's role in this framework then trying to swim upstream with WebObjects.

I'm not sure if I agree with this, on a couple of points.

Firstly, something's momentum and visibility is not a reason to swim with it per se. If that were the case, Apple would have given up years ago.

Secondly, I'm sure people will point to JBoss on OS X Server, WO5.3, integration with CoreData in XCode etc, but personally I'm really not sure that Apple cares that much about making WO a development success in its own right, certainly not a commercial one, for a couple of reasons.

WO is used within Apple to turn out applications like the Apple Store, iTunes Music Store, and .mac. Compared to a lot of other application server systems, the development tools, having as they do (and has rightly been pointed out here) the NS heritage, are leaps and bounds ahead of anything else out there; the whole application development metaphor has been much more believably ported to a web environment than in any other toolkit of system I've seen; the rules/D2W system is extremely powerful and flexible. Thus, WO gives Apple a nice competitive advantage in deploying this sort of application, all of which is geared around shifting hardware, which is pretty much always the bottom line with Apple.

I don't think they're particularly interested in making WO a JSP-killer or a PHP-killer or a Rails-killer or Rails-ally. It's a neat piece of software that they use to do neat things with; it can also be used by other people to do neat things with, so they give the space-age (although admittedly often buggy) development tools away with OS X client licenses so they can sell desktops and notebooks to developers who like WO and recognise its capabilities; they give the deployment tools (the WO application server, JBoss, etc) away with OS X server licenses so that people can feel happy and warm about having a rackful of nice XServes with web app servers.

Don't get me wrong, by that argument Apple would love to see WO succeed as it would drive more hardware sales - my point is really that although Apple make some clever and sometimes beautiful software, its bottom line is and always has been shifting hardware, and the software is there to support that. It's not there to drive Web standards, Web application development, Open Source, or any of the rest of it - Apple uses these, or subsets of these which suit it (viz. Darwin/BSD/Mach) to serve its own ends. Which it does, successfully.

Rails certainly has a leg up in that WebObjects hosting isn't as available or as cheap as Rails, and hosting WebObjects requires a license while Rails is free. I think Apple should release WebObjects for free and also offer cheap, minimal WebObjects hosting as part of the .Mac service.

Well, you do need a license, which comes free with OS X server, but you can then deploy it within any J2EE servlet container, which are not ubiquitous, but getting there. I suspect that's as close as you'll get to free; as I've said, it's all about driving users - developers, admins, business units, whoever - to Apple hardware.

Apple has smartly decided to give public recognition to Mac OS X's preferred status in the Rails community and post an article on Rails basics at ADC. The side effect of this, though, is that WebObjects is pushed even further into obscurity. Whether intentional or not, the message here is that Ruby deserves a featured article and WebObjects does not.

Well, Rails has the 'new'/'latest & greatest' buzz around it, so it serves Apple well to be associated with it. There's a lot of WO documentation on the developer site, and it's highlighted/featured when there's (e.g.) a new release.

However, more importantly, again the message here is really that if people want to use Macs to develop Rails applications with, then that suits Apple just fine because they'll have to buy those Macs to do it with. Posting the article can't possibly hurt Apple - if Rails comes to be perceived as the best way to make web apps, then if you can get people to associate Rails with Macs - of course, for perfectly valid reasons, like Ruby has been in OS X since whenever, like Mac has great developer tools etc - then you do Apple's bottom line good.

I agree. And that is a good reason to use java. You will type a lot more but debug less.

Not at all true in my experience. I've programmed in Java for almost 10 years, Python for less than 1, and am already much more productive in Python. I find both development and debugging time significantly reduced; the line of code I don't have to write isn't going to have a bug.

There's a lot of WO documentation on the developer site, and it's highlighted/featured when there's (e.g.) a new release.

There are minor news items, but nothing in the vain of the "featured content" articles that JDD is writing.

There's something that has been on my mind for a while now, and re-reading this comment thread I've thought to post it here -albeit a bit late- to gather your opinions.

I'd like to do a Cocoa On Rails. Using the ruby-cocoa bindings, write applications with ActiveRecord and everything else except for the views, which would be NIB files loaded at runtime (à là tm_dialog) and data-bound with the ruby classes.

Being a Cocoa newbie it'll take me still a while, but I'm not in a hurry. However, if any of you is so inclined, please do give it a try.

I'd like to do a Cocoa On Rails. Using the ruby-cocoa bindings, write applications with ActiveRecord and everything else except for the views

To play devil's advocate, why not use Core Data?

Because CoreData can only use XML, SQLLite and a binary format. I'd like to (be able to) use Postgres or oracle.
However, I like CoreData's visual representation of my models too... you're right, Cocoa developers are spoiled

Because CoreData can only use XML, SQLLite and a binary format. I'd like to (be able to) use Postgres or oracle

The Persistent Store Coordinator only supports those formats, but Core Data in the larger sense is not married to any one format. You can use Core Data for change tracking and just write your own code to write to PostgreSQL when necessary.

Also, I believe SQLite's dump format is compatible with PostgreSQL, so the easiest approach might just be to use SQLite as a local cache and periodically write out the results to a larger database.

Technically, you could use Active Record instead of Managed Objects, but you'd be missing out on a ton of very useful code that Apple provides, both now and in Leopard.

Great stuff. Thanks!