Friday, June 6th, 2008

An interview with 280 North on Objective-J and Cappuccino

Category: JavaScript, Library, Podcasts, Toolkit

<>p>280 North

As I say in this podcast interview, I got an early look at 280 Slides the application that launched yesterday to much acclaim. People are calling it “Keynote on the Web”, which the team finds very humbling, and hope that one day they have all of the great features (and more!).

As you can hear from the interview I sit down with Ross Boucher, Tom Robinson and Francisco Tolmasky to discuss their new application and how they built it.

I really like these guys. A couple of them worked on cool products at Apple, and it turns out that they started the language and runtime work back at school.

Objective-J is the language that takes JavaScript and makes it Objective (as Obj-C did to C). Lots of square brackets. When the browser gets served .j files, it preprocesses them on the fly. This means that you can do things like, use standard JavaScript in places.

Cappuccino is the port of the Cocoa framework.

The guys talk a little about the toolchain an why they did this, and even how it enables future cool things such as generating a native Mac application from the same code.

We also get into the fun cross browser issues that they work around, and how they are abstracting developers high up, so you don’t have to deal with these issues.

Finally, I was excited to hear that they will be open sourcing the code at objective-j.org shortly (may not be there yet). They are going through the usual issues of choosing a license (Apache2 please?), a source control system (Subversion vs. Git), and documenting the thing ;)

We have the audio directly available, or you can subscribe to the podcast.

The team was very interested in learning what JavaScript developers think (They have heard from Objective-C folk who love it), so let them know in the comments!

Posted by Dion Almaer at 3:41 pm
48 Comments

++++-
4.2 rating from 74 votes

48 Comments »

Comments feed TrackBack URI

While an impressive technical feat I think it’s use is questionable, Objective-C is nice and all, but JavaScript isn’t so bad that jumping through these hoops is justified.

Comment by iconara — June 6, 2008

Its important to realize that Objective-J isn’t about jumping through hoops, its simply about taking a different approach to development. It’s really important to us that Objective-J is easy to use, and that powered a lot of our decisions. For example, there’s no compilation needed to run Objective-J programs, you can just load a file in your browser, make changes, refresh, etc. The way JavaScript programmers are used to.

Comment by rboucher — June 6, 2008

If there’s no compilation, how does it work? Is there an interpreter written in JavaScript? What’s the overhead?

Comment by Nosredna — June 6, 2008

If writing a whole application runtime in JavaScript isn’t jumping through hoops I don’t know what is.

Don’t get me wrong, I’m really impressed that you’ve been able to do this, but I guess what I’m trying to say that time will tell if you’ve done something that is that much better to work with than, say, JavaScript and jQuery as to justify the added layers of interpretation, complexity, load time, etc.

I mean, this is basically about you wanting to write web applications in Objective-C, and well, is that really so important? There’s nothing wrong with wanting to use your favourite language everywhere, but what does Objective-C/J add to writing web applications that you don’t get from using a pure JavaScript framework? That is what it all boils down to, what does this add, and is it worth it?

It wasn’t long ago that someone ported the Processing runtime to JavaScript, and that was impressive too, but it’s not obvious that it actually was more than that, an impressive technical feat.

You guys have proved that you can write impressive applications with your framework, so you’ve come some way towards proving Objective-J, but others have written applications just as impressive as yours using JavaScript, Flash and Flex and they didn’t feel the need to write their own runtime.

I’m looking forward to seeing more info on the runtime, though, because as I’ve said, I’m really impressed with it from a technical standpoint.

Comment by iconara — June 6, 2008

I’d be more interested in seeing a C#/Java runtime in JavaScript. With a combination of local side caching (Gears and such) you could download an application, compile (convert) it to JavaScript (on the fly), and store the application (.js file) on the local cache for future visits.

Comment by matanlurey — June 6, 2008

matanlury,

There is an excellent C# compiler that goes to JavaScript as a target.

In case you didn’t know about it…

http://www.nikhilk.net/Category.ScriptSharp.aspx

It’s not a C# runtime, of course. But it does let C# developers target the browser.

Comment by Nosredna — June 6, 2008

I, for one, am excited to get my hands on Objective-J and I registered with this site just to let you know that. It sounds wonderful, actually. Thanks in advance for open sourcing it and I agree with Dion — Apache2 license…pretty please? :-)

Comment by smoody — June 6, 2008

Technically this is not only interesting but also impressive. But i have come to regard Apple-related/inspired stuff with a grain of salt, because of the attached hype factor. It’s like a supposed quality seal. But yes, it’s too early to discuss Objective-J, better wait until it’s released.

Comment by Rob — June 6, 2008

Nosredna: short answer: yes, it’s written in JavaScript; long answer: it’s actually a preprocessor and a runtime, so in the end the browser still just executes JavaScript. While the preprocessing can take place in the browser at run time, the overhead (which is already pretty low) can be minimize by performing the preprocessing ahead of time. The former is great for development, and the later is ideal for deployment.

iconara: The goal of Cappuccino is to make the *application developer* (not us) jump through as few hoops as possible. Objective-J itself does add language features used by Cappuccino that would have been difficult and ugly to replicate in pure JavaScript.

Comment by tlrobinson — June 6, 2008

I wrote ObjC code for ~5 years in the early 90′s. I’ve written JS since 1999. I’m now back to writing ObjC for the iPhone. (Heck, for that matter, I helped write iAmaze Presenter – a web based presentation application, written in DHTML/JS – back in 2000.) Which is a long-winded way of saying, I’ve got plenty of experience in 280North’s problem space to justify an opinion. So here goes …

As cool as Objective-J is, I’m completely baffled by why the developers thought it was a good idea. Frankly, the ObjC language has barely evolved in the 15 years I’ve used it. After doing JS work, the syntax and style feel cumbersome and archaic. There’s very little about it that would seem to recommend it. As for the frameworks. Now that I’m doing iPhone dev, I *yearn* for the simplicity and ease-of-use of the native JS APIs. I mean, come on, string construction alone is a nightmare, and that’s just one example.
ObjC: [NSString stringWithFormat:@"Today: %@", date]
JS: “Today:” + date

Now, I know these guys aren’t idiots, so I’m pretty sure I’m missing something. I just have no idea what. Any chance you could elaborate in more detail on what the benefits of this approach are? (I mean, aside from the hand-waving about not making developers jump through hoops).

Comment by broofa — June 6, 2008

@broofa

Hey broofa, I’m from the 280 North and I’ll try to shed a little light on this, because I think people are focusing too much on the language of Objective-J and not Cappuccino. Let me first lessen your concerns by telling you that can *still* do string = “Today” + date. That’s the beauty of Objective-J, it’s both languages, which means you get all the benefits of JS, while still getting to have real classes and so forth.

Now, completely separate from this, is that no *language* truly makes writing applications easier. Sure, little pet peeves may come up here and there, but 90% of what happens in an application deals with the frameworks you use. I’m sure all the iPhone “problems” you’re having with Objective-C are more than compensated by all the amazing power you get from things like CoreAnimation, which is precisely why we wrote Cappuccino.

JavaScript does not have any way of writing applications today in the same way mature platforms like Cocoa do. Cappuccino provides you with very high level features like copy-paste (of anything), undo and redo, document management and archiving, vector graphics and animation, etc etc. when you write an application for Mac OS X or iPhone, you can truly focus *just* on your application, not whether it will work on some obscure browser or how to get something as simple as undo working, and that’s precisely what we are trying to provide.

Again, Cappuccino is not for everyone. There is an incredibly wide spectrum of web content out there, from completely static pages, to dynamic pages, to full blown applications. We *only* serve the latter. It would not make sense to put Cappuccino on something like Amazon.com, but 280slides would have been an incredibly more difficult task for a 3 person team like ours without having all of the foundation already complete.

Comment by tolmasky — June 6, 2008

Is there any possibility of using cappucino without Objective-J? I’m kind of interested (on an academic level, not really on a practical level) with a port of Cocoa to javascript. However, for Objective-J, I’m not at all convinced by this assertion: “Now, completely separate from this, is that no *language* truly makes writing applications easier. Sure, little pet peeves may come up here and there, but 90% of what happens in an application deals with the frameworks you use”

Frameworks are nice, but a bad language can really get in the way, and a good language can really have amazing effects on productivity (so long as you know how to use it). Javascript has its warts, but first class functions, prototypal object orientation, and dynamic typing more than make up for it.

I’ve been coding javascript for about 2 years now, and I’m just now getting into Objective-C. Comparing the two, Objective-C’s classes and static typing really really get in the way, so I’m quite baffled as to why you would want to painstakingly recreate that experience in a language that isn’t usually encumbered by such things, and doesn’t need to be.

Additionally I’m baffled by the statement “Objective-J is the language that takes JavaScript and makes it Objective (as Obj-C did to C).”
Javascript is already “Objective”, it just doesn’t have classes. It doesn’t need them, it has prototypes, which I think are far more flexible and powerful anyway.

Comment by Breton — June 6, 2008

@Breton So, Objective-J really just *adds* to JavaScript. You won’t have to worry about static typing or anything, it effectively lets you have 2 classes of objects in your program: those that behave like Objective-C objects, and those that behave like JavaScript ones. In fact, you can have objects that act like both, such as arrays:

var myArray = [5,6,7];

alert(myArray.length)
alert([myArray removeObject:5].length);

So you really can have your cake and eat it too. The reason we added Objective-C style message passing to JavaScript is simply that it is more dynamic, and many features in Cocoa rely on it. You can do things like handle methods that aren’t implemented (like in Ruby), you can change and swap out classes at runtime, KVC and KVO (allowing for bindings), and much more. Just the fact that you can call [super myMethod] is a plus.

As we stated in the interview, we initially did try to just add “Cocoa-like” features to JavaScript, and it simply didn’t work nearly as well. Also, what was said in the interview (although I admit it was a bit confusing), was not that it makes JavaScript objective, its that it adds *the same* features as “Objective-C adds to C”.

Hope this clears things up! :)

Comment by tolmasky — June 6, 2008

I’ll try anything once.

Comment by Nosredna — June 6, 2008

This is an incredible tour de force of programming. The app looks marvelous, and these guys build their own language and runtime translator/compiler. Kudos.

However, I really feel this app cries out for a GWT-like approach, either performing the translation on the server or in a compile step. It makes an insane number of HTTP roundtrips to load up all the .j files, and takes a long term to translate them. The files are non-obfuscated and full of comments and everything. In total, I could almost 800kb loaded to launch the app, but I’m betting with server-side compilation and obfuscation + gzip it could be reduced to ~100kb, load much faster, in 1-2 HTTP requests.

If it were written in GWT, it would make 2 requests to load the script, 1 request to load all of the toolbar icons, and a few to load data from the server.

But besides my criticism, again, major props, the end result looks amazing, much much better than Google’s Presently, it seems to work better than Presently too. Just need to work on startup and memory consumption.

-Ray

Comment by cromwellian — June 6, 2008

@tolmasky and the 280slides team: Amazing! I can somewhat understand the bafflement by some of the above comments about creating Objective-j, but I think they are missing the point(s). First, 280slides is probably the best looking browser based app I have seen in awhile. And if Objective-j and Cappucino helped you build it, then they obviously have a place in web app development. Being able to mix js and Objective-j is a nice touch.

Ajaxian: Did I really have to go through registration hell to comment? The registration screen reminded me of hotmail registration. Web 2.0 called, and she isn’t happy.

Comment by rubymaverick — June 6, 2008

This really is one great app. I’d much rather make ppt presentations in this than in PowerPoint.

Comment by Nosredna — June 6, 2008

@tolmasky: If the APIs are what’s important, why all this fuss with Objective-J then? Why not take advantage of established libraries like jQuery/Prototype that provide good OO structure and class inheritance, as well as a variety of really nice low and mid level APIs, then fill in whatever APIs from Cocoa you think are missing by porting them directly to JS?

As I think you alude to, there’e nothing about JS that prohibits you from writing APIs like UndoManager, or the nearly ubiquitous pasteboard pattern used to implement copy/paste support in Cocoa and other non-JS libs, or even animation support.

I get the feeling you may have underestimated the level to which JS web-app development has progressed in recent years. Sure, it’s not a hard-typed, compiled language with a comprehensive set of APIs like ObjC+Cocoa, but libraries like Prototype/jQuery/YUI/dojo and others, combined with Firefox + Firebug (and other plugins), are pretty darn compelling once you’ve learned how to use them. And they don’t have the walled-garden issue that Obj-J would appear to have by virtue of being in a completely different language. (Yeah, I know you _can_ write JS alongside ObjJ, but *sheesh* do you really want to have to code your client in two different languages???)

I’m certainly looking forward to taking a peek under the hood once ObjC/Cappuccino is open-sourced, but I’ll be approaching it with a skeptical eye. Returning to Cocoa development has actually been more painful than I expected or remembered, much of it due to how *easy* it is to work in JavaScript. :)

@cromwellian: Yeah, the similarity to GWT struck me as well. As for the differences in polish between Slides and Presently, yeah I agree, but most of those differences would seem to be fairly superficial design choices, rather than fundamental differences in the two technologies.

Comment by broofa — June 7, 2008

I think the reason that everybody falls over the Objective-J part is that they all know what a major pain it is to program in Objective-C.

I would love to work with Cappuccino though.
How much Objective-J would one have to use to use Cappuccino?

Comment by Jaaap — June 7, 2008

I’ve programmed for 30 years, and have discovered that JavaScript is the most enjoyable programming experience yet. I love everything about web development except for that feeling I get when I check to see if my app runs in IE after a change.

I’m so incredibly glad to be using a dynamic language.

But I understand that not everyone feels that way. I’m fine with choices. All these choices are interesting to me. I’m just skeptical I’ll find something as appealing as JavaScript among them.

I do like how you don’t have to compile Objective-J (a major pain in GWT, in my view), but I worry about the debugging experience. Can you tell us what it’s like to debug Objective-J in Firebug?

Comment by Nosredna — June 7, 2008

[shameless_plug]
@matanlurey
The thing you are interested in is not having to code in JavaScript I assume. In which case all you have to do is follow my link… ;)
If you want to code Ajax applications in C# or Java there exists solutions for this already. One of them is GWT the other is Gaia.
@nikhil
The last time I checked an Hello World application written in Volta BROKE my BROWSER…
It had several hundred HTTP requests and spent 5 minutes downloading before FireFox died…!
@both of you
GWT and Volta are interesting academic exercises, though the correct way (I think) to look at JS and abstracting it away is to look at the browser as a “display medium”. Then you can write hardcore super optimized JS widgets which you can “communicate” towards from the Server-Side. Which happens to be the way we do it…
[/shameless_plug]

Comment by polterguy — June 7, 2008

@polterguy
I have to say its extremly annoying that you try to “sell” your framework on every post on ajaxian. I don’t mind it once, but you are posting twice or three times per post. Please quit it.

Comment by matanlurey — June 7, 2008

Interface Builder?

Most folks think things like Interface Builder are crutches. But in Cocoa development, Interface Builder is central to app development. If you think you need to learn how to do it the ‘hard way’ before doing it the ‘easy way’, you already don’t ‘get it’.

Yes, you can build apps without Interface Builder, but that’s like developing without a debugger, doable, but not very nice, and it certainly inhibits rapid and iterative development.

So I ask again… anything like Interface Builder for Objective-J development?

Comment by oeddie — June 7, 2008

@matanlurey
Sorry, though I think it was relevant for the discussion, I guess it’s easy to get “carried away” sometimes ;)

Comment by polterguy — June 7, 2008

It’s really funny how many people don’t like Objective-C and Cocoa, while almost all really good developers I know love Objective-C and Cocoa.

Those other developers who don’t “get” Objective-C and Cocoa don’t write applications for Mac OS X and I believe that this is one of the reasons that the average quality of Mac OS X applications is so much higher than the average quality of Windows applications.

(Of course, not every programmer who dislikes Cocoa is a bad programmer, but most bad programmers dislike Cocoa, and many great programmers really like Cocoa)

Comment by helgeg — June 7, 2008

>>It’s really funny how many people don’t like Objective-C and Cocoa, while almost all really good developers I know love Objective-C and Cocoa.

I don’t personally know a single good programmer who loves Objective-C. Birds of a feather flock together.

Comment by Nosredna — June 7, 2008

It’s really funny how many bad developers formulate ridiculously elitist opinions regarding platforms and programming languages based on things they overheard rather than first hand experience.

I dislike Cocoa because I’ve actually seen the sources and because I can’t stand the bracket syntax of Objective-C. Why on earth anyone would want to graft that RSI inducing nonsense onto an already obnoxious closures-over-classes OOP implementation as some kind of chimeric DSL is beyond me. Looks great on a résumé, I’m sure, but from where I’m sitting, trying to force one language to look like another you’re more familiar with seems like more of a crutch than Interface Builder could ever hope to be. No thank you.

Comment by khiltd — June 7, 2008

Wow – I’m amazed at the amount of flak this post has caused. The Cappuccino framework promises so much to us as developers yet all we see here is some silly flamewar.

I’ve been involved in a couple of big JS webapp developments recently and in each I found it saved loads of time (and code) to implement some Cocoa idioms, specifically delegation and notifications… in fact one of the first things I do when tackling a large JS webapp is to implement an NSNotificationCenter clone… the amount of time and code this saves is incredible, even for very simple things like disabling a Delete button when no records in a list are selected.

I can’t wait to dig through the Cappuccino frameworks when they become available.

The issue here is nothing to do with Ojective-J vs MyFavoriteLanguage… it’s the abstraction that an API can bring to us webapp developers. JQuery, ScriptAculoUs et al are all brilliant and have saved us all hours of otherwise hell over the years, but this Cappuccino thing is a big step in the right direction.

Just my 2¢!

Comment by iiaann — June 7, 2008

RSI inducing? I’m no Objective-C/Smalltalk programmer, but you do realize that:

foo()

requires more fingers than

[foo]
?

The naming scheme of Objective-C functions coupled with the named-parameter stuff makes remember APIs easier too.

@polterguy, GWT isn’t “academic”, it’s mature, production ready, and being used by lots of developers now. Volta is more academic at this point, but I think GWT has proven the worth of compiling other languages to JS.

Comment by cromwellian — June 8, 2008

More fingers to produce the same number of characters? You must be doing some crazy typing. Also do try to realize that

foo(1)->bar->(2)->foobar()

requires fewer back arrows/mouse clicks than

[foo: 1] bar… oops need another bracket
[[foo: 1] bar: 2] foobar… oops need another bracket
[[[foo: 1] bar: 2] foobar]

Couple that with ridiculously verbose message and parameter names (you can’t even reorder/omit the parameters so the benefits of naming them are never fully realized as they are in other languages) and you’ve got a sprawling nightmare that XCode’s text editor is simply not fit to cope with in any capacity.

I’d like to see some proof that any of this makes the APIs easier to remember. It takes 12 lines of code to accomplish the same thing a single call to StringWidth() used to; 9 lines of code to run a shell tool and capture its output; and then you also have to worry about whether or not the person who cooked up the class you’re wrestling with used the same thesaurus as everyone else in choosing his nomenclature. Case in point:

[IKImageView setImageZoomFactor: (CGFloat)zoomFactor centerPoint: (NSPoint)centerPoint]

“Center” in this particular case actually means “origin” or “bottom left.” What a great mnemonic that named parameter is! Sorry, but while I may use this framework, it is not something which I consider worth emulating.

Comment by khiltd — June 8, 2008

@khiltd, I don’t know about your keyboard, but on my keyboard, parenthesis requires the shift key, square-bracket does not. The -> operator isn’t exactly light on the typing either. If you want lack of excessive syntax for precedence, you may as well look at one of the concatenative languages like Joy or Factor, although you pay for it by stack twiddling.

Comment by cromwellian — June 8, 2008

I actually think the whole thing is an impressive accomplishment. The main thing I’m curious about- As someone who has worked with javascript for quite a while- Is that someone claims to have found some things that “wouldn’t work” or “would look really ugly” to implement in javascript.

The list of things from the developer was: “.. we added Objective-C style message passing to JavaScript [because] it is more dynamic, and many features in Cocoa rely on it. You can do things like handle methods that aren’t implemented (like in Ruby), you can change and swap out classes at runtime, KVC and KVO (allowing for bindings), and much more. Just the fact that you can call [super myMethod] is a plus.”

I did a bit of research to make sure I kinda knew what I was talking about– But maybe I’m just dense. I couldn’t find a single difference between Objective-C style message passing and the way javascript function calls already work. The case of handling unimplemented methods is easily done by exception catching. I can see why swapping out classes would be impressive in a C based language, but swapping out objects, and methods and changing them around has never been the slightest bit difficult in javascript. KVC and KVO can be done with callbacks, and in fact, ajaxian has reported on a library that replicates cocoa’s binding system, somehow without the use of objective-j. I honestly can’t fathom why being able to call [super myMethod] is a plus. I’ve never run into a situation where I’ve really needed that in javascript, since.. well, it’s not a class based language. So the idiom doesn’t make any sense, unless you’ve grafted classes on.

But all that is really beside the point. I think cappucinno looks really interesting, and the application built with it, 280 slides, looks quite impressive. I look forward to being able to try it out. I just don’t quite believe the argument that Objective-J was needed to implement it, so I’m really looking forward to what the real pain points were about javascript that led them to “jump through hoops” by inventing objective J. The previous comments from one of the authors don’t answer this particular niggling confusion for me. So maybe looking at the source code will.

Comment by Breton — June 8, 2008

From reading all these comments it’s amazing the negativity that exists regarding this. I suppose I just wonder the practicality of Obj-j and cappucino.

When developing for the web especially, there are a million ways to skin a cat with a large variety of languages and sublanguages, and many with a questionable purpose, and it all comes down to practicality. What’s the best way to do what you want and what makes the most sense. I’m sure Obj-j and capuccino have its purposes in some applications just as using straight up javascript with jquery has its purposes as well, and they vary in their abilities, so I think its unwarranted to crap all over Obj-J and Cappucino like some are doing in these comments as if it’s a convoluted way to do something you can already do with straight javascript or whatever. Perhaps in a relatively simple javascript application maybe using jquery is the way to go, but for something more powerful maybe obj-j will serve better.

Comment by jtothekay — June 8, 2008

I was also taken aback by the negativity. Some of it reminds me of Java programmers and how they attacked other languages being used in the stack along with Java. These guys have built themselves a tool, a DSL on top of Javascript, and yet, some JS programmers seem deeply offended that they dared to venture outside DSLs that are achievable via pure JS and JS syntax. They are skilled at Objective-C and Cocoa, so they opted to create tools that allowed them to leverage that. I’m not a fan of this DSL, but why should endusers care what was used to build the app?

Seems like they did what was best for them.

Comment by cromwellian — June 8, 2008

@khilted

In regards to:
some crazy typing. Also do try to realize that
foo(1)->bar->(2)->foobar()
requires fewer back arrows/mouse clicks than
[foo: 1] bar… oops need another bracket
[[foo: 1] bar: 2] foobar… oops need another bracket
[[[foo: 1] bar: 2] foobar]

If you’re doing anything like that in Cocoa, you’re doing it wrong. The entire point of Cocoa and why it’s so easy to work with, build things, and change things quickly is the adherence to OO and MVC design paradigms of which object encapsulation is a huge one. If you find yourself needing to go three calls deep in order to achieve something you’re likely doing it wrong since the goal is less lines of code with clearer selectors that tell you exactly what the intent was rather than exactly how it’s being achieved.

As to the API you sighted, clearly the author is at fault, since that’s not part of Cocoa.

@Breton
You’re not hearing yourself clearly. You’re saying that in order to get what message passing natively does, you need to merely handle exceptions. In order to get KVC and KVO you need to implement your own callbacks? Sure, if you do all that, it’s the same thing. There currently exists no JS library outside of Objective J that natively does this and the many other things Cocoa does, for you, and while you *could* do it this way yourself in js, you’d have to write more code to do it in the first place.

Cocoa, and I expect Cappuccino to follow the same principle, is all about reducing the code burden on the application author. There’s no reason why you should have to do such tedious things, there should be one library that encompasses all these “basics” such that you don’t have to write a new one for each project, that you don’t need to extend a little bit more to do exactly what you wanted then end up having to rewrite since the code was too dependent on weird behaviors.

Objective-J is an amazing technical achievement but the programming paradigms it brings along from Cocoa are where the real value lies.

Comment by theKarlAdam — June 8, 2008

“I did a bit of research to make sure I kinda knew what I was talking about”

Very commendable, but you still don’t quite:

“The case of handling unimplemented methods is easily done by exception catching”

Exception catching doesn’t allow the callee object to handle the case when a method is called on it, which doesn’t exist. It only allows the caller to deal with it. To be able to do the former is a powerful feature as Ruby programmers and Objective C programmers alike already know.

On a more general level, you seem to be implying in several of your posts that the guys behind Objective J somehow must not have understood JavaScript. You are ignoring the obvious fact that to be able to implement something like Obj J to begin with, you’d have to have a very thorough understanding of the language you are implementing it in. It seems to me much more likely that it is you who have only a superficial knowledge of Obj C and Cocoa. Of course none of us have looked at the code yet, but we have seen the kind of application it’s apperently possible to build with this new language/framework. That in itself should at least give the developers at 280 the benefit the doubt. I’d be very surprised and impressed if any of the nay-sayers in this thread have ever created anything resembling this kind of app in pure javascript. If they haven’t, they should be careful with claims to suggest that their javascript knowledge and skills could even compare with the guys at 280.

Comment by KaptajnKold — June 8, 2008

“Exception catching doesn’t allow the callee object to handle the case when a method is called on it, which doesn’t exist. It only allows the caller to deal with it. To be able to do the former is a powerful feature as Ruby programmers and Objective C programmers alike already know.”

Ah I see. I’m not sure I see the value of it myself, but I’m sure if I had a hammer, I would begin to see the value of nails.

“On a more general level, you seem to be implying in several of your posts that the guys behind Objective J somehow must not have understood JavaScript. ”

On the contrary, I have been extremely careful not to imply such things. Also, I’ve only posted twice to this thread, I don’t know where you get “several”. I am merely curious. To be clear, as someone who has a current favorite language, I’m quite interested in what people outside of it have run into so far as limitations go, and I am especially interested in learning new things. I can’t learn new things by standing in silent awe of someone else’s obviously superior intelligence! I ask tough questions damn it! and I’m not ashamed of that! I suppose if you had an inclination towards conflict, you could read that as hubris. In this case though, I did not intend to give that impression at all.

“You are ignoring the obvious fact that to be able to implement something like Obj J to begin with, you’d have to have a very thorough understanding of the language you are implementing it in”

I’m not ignoring that, I have complimented them on their achievement in nearly every one of my posts.

“It seems to me much more likely that it is you who have only a superficial knowledge of Obj C and Cocoa.”

Of course I do! I’ve made no secret of that, and I said as such in an earlier post. My questions have also been an attempt to learn something about Objective-C. If there’s something valuable in it, I want to know about it, and such insights are not so easy to find rifling through apple’s reference documents unguided.

” Of course none of us have looked at the code yet”

what are you waiting for? it’s right there under the “view source” button in your browser.

“I’d be very surprised and impressed if any of the nay-sayers in this thread have ever created anything resembling this kind of app in pure javascript. ”

I haven’t, but I’d like to. It’s interesting and a little exciting. Otherwise I wouldn’t have bothered posting in this thread at all.

Comment by Breton — June 8, 2008

So, how to objective-j compare with Coherent and SproutCore? See discussion at http://ajaxian.com/archives/coherent-cocoa-databinding-for-ajax

Comment by Dylan Schiemann — June 8, 2008

I got about 5 slides in to building a presentation and then the user interface went all crazy. I couldn’t select text anymore. Undo stopped working right. This makes me kinda scared to do any production work in it. I assume it’s still beta (everything is beta on the web, it seems).

So now, again, I’m interested in how well debugging workis in Firebug if you’re seeing JavaScript being executed but you’ve programmed in Objective-J with a different waay of thinking about the code.

Comment by Nosredna — June 8, 2008

If I’m using Cocoa incorrectly then someone should tell the people who wrote it that, because there doesn’t seem to be much of an alternative. AppKit sources are not kept private because they contain any trade secrets or patentable algorithms; it’s just butt-ugly code nobody wants their name associated with.

Comment by khiltd — June 8, 2008

Nosredna: We’ve got several debugging tools, including a custom version of Firebug that understands Objective-J method names. A lot more could be done as well.

Comment by tlrobinson — June 8, 2008

>>Nosredna: We’ve got several debugging tools, including a custom version of Firebug that understands Objective-J method names.

Wow. You guys went all-out.

Comment by Nosredna — June 8, 2008

re: Cocoa inducing RSI – Personally, Apple’s ObjC/Cocoa environment is far and away my least favorite environment when it comes to the ergonomics of writing code. I wrote NeXT/OpenStep apps for 5 years and my fingers/forearms *killed* me most of the time. It got so bad I had to use a Kinesis (ergonomic) keyboard and wear a wrist brace just to be able to code.

When I switched to doing JS/DHTML/AJAX coding, those symptoms disappeared almost immediately, and stayed away for 9 years of coding webapps. Now, having switched back to Cocoa Touch development 2 months ago, my wrists and forearms once again throb from the contortions required by Xcode and the Apple in general.

I believe there are three factors that cause this:
- ObjC selector syntax: ObjC forces every parameter to be named. E.g. [object argument1:foo argument2:bar argument3:baz]. While this does make code self-documenting (sort of), it essentially doubles the amount of typing required to invoke a method. Moreover, method names end up being more obscure than necessary, so you have to refer to documentation far more often (see gripe about “help” hotkey below).
- Cocoa method naming style: Compounding the overly verbose method invocation required by ObjC, is the insanely long method signatures given to the Cocoa APIs. It’s absolutely ridiculous how long some of the method names that Apple uses.
- XCode keyboard shortcuts: You pretty much have to excel at using keyboard shortcuts to be an effective Cocoa developer. Unfortunately XCode uses some of the most bizarre vulcan-nerve-pinch shortcuts of any environment out there. I mean, come on, who in the h*ll thought it was a good idea to have as the shortcut for “help” (where other platforms use simply “F1″).

These three problems combine to have Cocoa developers contorting their hands into uncomfortable positions dozens of times a minute, for hours on end.

Is Cocoa/ObjC development physically uncomfortable? Abso-frickin-lutely!

Comment by broofa — June 8, 2008

good idea to have as the shortcut for “help”
-> good idea to have [shift+meta+alt+?] as the shortcut for “help”

Comment by broofa — June 8, 2008

Wow. It sure helps to be the last story before the weekend if you want a lot of comments.

Comment by Nosredna — June 8, 2008

>> – ObjC selector syntax: ObjC forces every parameter to be named.
>> [object argument1:foo argument2:bar argument3:baz]

This is incorrect. The parameters are not named, those bits are part of the method name. ie. “argument1: argument2: argument3:” is the method name. You can’t reorder them as you could with named parameters.

You could just as easily name the method argument1:::

As for method name length, I use code completion. I read the code a whole lot more than I write it, so descriptive names are worth far more than saving keystrokes on a method name that I’ll only ever type once.

Comment by terrywilcox — June 10, 2008

Kudos 280North – your work is extremely impressive. For an analogy, I do not write desktop applications in assembly language. I consider HTML and CSS to be the assembly language of web applications. And so I absolutely welcome Cappuccino. I have also been impressed with some newer toolkits such as Echo3 and Ext – specifically Echo3. I hope that one day soon Objective-J and Cappuccino will be licensed for use by all.

Comment by philmaker — June 15, 2008

For my part, Cocoa+objective C are truly a great framework/language to do modern application.

It’s very powerful, dynamic and it emphasizes MVC development at the core.

-

I’m not convinced by JS. not the syntax, the js syntax is nice. No, the main problem is it needs a standard framework to develop real applications.

-
I’m looking forward to see what objective-J/cappucino can bring. The real important part is cappucino.

Comment by oomu — June 16, 2008

Leave a comment

You must be logged in to post a comment.