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.

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.

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!

Wow. You guys went all-out.

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.

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.

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.

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.

Seems like they did what was best for them.

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.

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.