This is very well thought out, and their reasoning was surprising to me. I knew the whole point about Objective-C choosing its syntax to allow it to be a compatible superset of C, but never applied the same reasoning to Objective-J and Javascript.
Having said that, I still maintain some skepticism about using a single language for the entire webapp stack. I understand their desire, for example, to be able to swap out the "rendering layer" in the future. However, CSS is a pretty good language for specifying how things should look across an entire web site, or part of a website, or single page, etc. I don't think Objective-J is a better tool for this particular job. Likewise there may be times when you just want to express structural relationships, and HTML might be better than Objective-J for that purpose (less sure about this one).
I don't know the details about Objective-J. Maybe they address this point elsewhere. The counter argument may be that Objective-J is for "rich web applications," and you don't worry so much about site-wide CSS style in that case.
I agree, probably HTML+DOM+JS isn't going anywhere, at least for the next 5 years, so who cares about an SVG rendering engine today? Probably someone who is focused solving the wrong problem and burning money unnecessarily, because there are enough issues to handle with a web startup.
Who said anybody was working on an SVG rendering engine? Also, SVG is now available in the latest release of every major browser, so it doesn't matter what else is around, the point is that SVG is now one option for building web apps.
What does burning money have to do with anything? Cappuccino is an open source project. 280 North is a 3 person company.
When you are building for the web you make some browser backward-compatibility choices. Their implementation in that case which is build to be backward-compatible suffers significantly for being really slow.
I would not consider SVG as an option or necessary except if you are a building an well targetted network app served over the web.
Burning "money" is valid when you can't afford it. For a startup that "money" is the effort. So it's more important for a group of 2 or 3 to solve real problems.
YouOS, a team of smart guys got busted for getting caught in wrong execution.
The author is against language features implemented as a library. However, the drawbacks he points to are really a lack of community programming conventions. If there were an agreed on standard Javascript way to do things like traditional OO class based inheritance, then there wouldn't be the problems he cites. Having such conventions encoded as syntax would reduce some of the power of Javascript. The fact that you can implement your own domain-specific mini-language is very powerful.
This is really pointing back to the old "Cathedral vs. Bazaar" dichotomy.
There is also the issue that implementing things like method_missing and import are prohibitively difficult without new syntax.
Objective-J's code importer is one of the more complex pieces (as it manages to do so completely asynchronously).
All the approaches that use a simple JavaScript function to grab code, like grab_and_eval("file.js") are forced to happen synchronously (since you have to guarantee that the code is evaled before the next line). Without some sort of lexing support, its really not possible to both grab files asynchronously and also be able to continue executing.
Also, as stated in the article, you can't intercept JavaScript method calls, so if you want something like method missing you're forced to do something like:
"The author is against language features implemented as a library."
I don't understand how you can say that, when the entire article is a defense of why they added a bunch of features to Javascript as a library. That is, as opposed to adding those features as part of a new language specification.
I think the actual argument is "as long as you are adding language features as a library, you might as well introduce new syntax for them while you're at it." They present several arguments in defense of this claim.
That's part of it but equally important is the idea of separating language / syntax changes, Objective-J, from the real goal of the library, Cappuccino. The other frameworks mentioned blend the two together, for example you can't get the JavaScript extensions implemented by Prototype without including all of Prototype.
But, with Objective-J you can write for example, some math library that has nothing to do with Cappuccino and not load Cappuccino.
As a graphic designer I can tell that if we could replace any transparent PNG with their bogus gamma by a simple SVG, it will make instantly any “traditional” web page more beautiful, richer yet simpler and faster.
I see a big advantage to switch the rendering layer to SVG when appropriate and on the fly. And I don’t see Flash being an alternative for this.
So Cappucino really kick ass for me.
At the end of the day we’re still dealing with pixels. But with monitors at 200ppi or more, it’s not a viable option, we need to use vectors, proper mathematics and abstraction layers.
I don't think languages have to change every few years, in fact, I prefer they wouldn't in many cases. I also think that the JS libraries kind of define language extensions, but it also feels better to me to stick with the JS syntax than to redefine the syntax.
Even with LISP, I am not sure if I am so happy about the new trend to add syntactic sugar. Having just brackets is pure, in a way, throwing in square brackets makes me feel a bit uneasy (not that I am much of a LISP specialist, so maybe my judgment is completely off base).
Why would you NOT want to redefine syntax if that new definition could make you dramatically more productive and or your code more readable? Sure if you are working on a large project for a large company (or even a large open source project) of course you want to make sure your code can be understood/maintained by johnny random but when you are talking about your journeyman type project - why would you compromise - and better yet why is it you aren't tackling problems which make you "up your game" in terms of abstractions and tools available to you?
Mechanics have wrenches with the edges ground off or thinned down, even heated and bent to fit special applications. So why shouldn't I have my own syntax which sits on top of a readily available platform?
Not against changing syntax in general, but in the case of LISP, it seems hard to change it without messing it up.
I guess I don't like more and more "special signs" (like @, [], <>, #) invading the code.
I've witnessed it with Java where a lot of new syntax was introduced. The thing is, these are all new concepts adding to the complexity of the language (annotations, generics,...). I prefer to keep things simple.
Good point - there is definitely fundamentally beautiful and intrinsic about the balance and simplicity of lisp. Personally I find removing syntax (another way of changing it) to be an empowering project. My current project is to introduce a syntax for php which is something more along the lines of smalltalk meets lisp - the real trick here was removing syntax and making it more gramatically relevant if used at all.
Well as the article pointed out Objective-C is supposed to be a better C. Do you see anyone who knows C care about this Objective-C? Obviously the original is around now for almost 40 years.
I wouldn't say Objective-C is supposed to be "a better C", just different, and better. They're quite different (besides the obvious fact that Objective-C is indeed a superset of C). C is a statically typed procedural language while Objective-C is a very dynamic object oriented language with optional static typing.
It's really quite elegant if you think about it. It's a highly dynamic language that was designed more than 20 years ago and is still very relevant today as the platform of choice for developing nearly all Mac OS X and iPhone apps. As far as dynamic languages go it's very fast since it's compiled. It integrates seamlessly with C (and even C++).
Just because you don't know or care about Objective-C doesn't mean there aren't plenty of people who do. I regularly see articles about Objective-C on the front page of Hacker News, Reddit, etc.
I didn't dispute the potential of Objective-C being better and more useful. What I said, is that although Objective-C may be better it never got more popular than the original.
Therefore although their effort with what they call Objective-J may be worthwhile, it's certain it will never go mainstream.
One significant reason? It runs toooo slow on IE. IF it ever gets fast, maybe more people will give it a shot.
Hm, isn't it only relevant because Apple forces people to use it? If there was a public vote for the programming language for the iPhone, would people really vote for Objective-C?
Interesting article but I for one genuinely prefer libraries to syntactic language changes. We do not need another language among the thousands already there.
"Interesting article but I for one genuinely prefer libraries to syntactic language changes."
I feel like there is some terminology confusion here (I already replied to someone else in the same vein).
I think it makes more sense to say "I prefer libraries that do not introduce syntactic language changes to ones that do." Technically, I would say Objective-J is a Javascript library, in addition to being a language in and of itself.
I think that Prototype, jQuery, etc. also add some syntactic changes, so I would say the difference is one of degree, not of kind.
At that point, we are venturing into LISP territory where the line between mini-language and library is truly thin (and sometimes non-existant like in the CL loop macro).
My standard: Can a common JS interpreter (say firefox) execute the code without modifications?
Check out parenscript. http://common-lisp.net/project/parenscript/ It is the only non js way of coding js that ever made sense to me. I saw Vladmir speak at an event and he got js and lisp.
I have looked through some of the code for parenscript and although I'm not a lisp expert I could grok what it was doing. I could also see how I could write my own macros if I put my mind to it. One huge advantage of compiling to js is that it makes obfuscation and compression a lot easier (this is true for GWT, objective-j, pyjamas, and parenscript).
if the only reason to embraced objective-j is its support for an (apparently) more "natural" means of OO programming, then to me that isn't a reason at all. how many people are modelling client software these days strictly by virtue of OO techniques? i'd go as far as to say OO is dead. i much prefer something like jQuery which doesn't get hung up on methodologies, instead looking to adapt better to the specific task at hand.
my guess is that objective-j is DOA. the pool of objective-c programmers is not a motivating factor...i'm not even sure there are many people who really love objective-c. indeed i would offer that the "leaky abstraction" is that which tries to graft one so-so language on top of another so-so language. just man up and use javascript for what it is.
I can't help but feel you did not read this post. Simply saying Obj-J is a "leaky abstraction" is meaningless, and yet you offer no examples of how the abstraction leaks (or why its actually problematic).
On top of that, you seem dedicated to the argument that Objective-C is a bad language, and that Objective-J is silly for wanting to re-implement it. Of course, as mentioned in the post, that was in no way the goal of Objective-J. The actual language isn't the point.
Separately, Objective-C is a great language, and plenty of people love it. More every day thanks to the iPhone. Can you give me three reasons why you don't like it?
Finally, claiming OO programming is dead is nonsensical. Java is by far the world's most popular programming language. Right below it you'll find C++ and C#. Three strictly OO languages. Not to mention the fact that two of the three most popular JavaScript libraries build in classical inheritance.
"impossible to find it being put to use outside of places apple forces it."
That's a huge caveat. iPhone development is extremely popular. Maybe the point is that people just put up with Objective C in order to do iPhone/Mac development. But I don't think that is true. NextStep had a small but rabidly devoted following, and part of that was because they really liked Objective C. Apple tried Java bindings to Cocoa at one point, but found everyone used Objective C anyways.
In general, I think it's true that most developers don't know much about ObjC until they want to develop for iPhone/Mac. But once they learn it, they tend to like it, from what I can tell.
oh come on, it is well known that apple intentionally dragged their feet on their java support for years
probably because they realized that as gross as java was, very few people would bother with objective c if they could get first-class support for java on cocoa
> oh come on, it is well known that apple intentionally dragged their feet on their java support for years
Apple (or more, exactly, the part from NeXT) did initially bet a lot on Java adoption. They ported the entire WebObjects stack from ObjC to Java, only to watch the technology get abandoned by those in the banking and eCommerce communities. The conversion was so total that when the Cocoa-To-Java bridge in OS X was deprecated, it was no longer possible to continue using the original WO tool chain. (What WO development outside of Apple exists made a new chain based on Eclipse, from what I read.)
No, if they "dragged their feet" it was simply because Java's static OO-ness doesn't map well to Objective-C's fully dynamic nature. Objective-C is basically just Smalltalk semantics (minus control structures) bolted on to C.
It works surprisingly well, but you can't and won't believe it until you try it yourself.
I certainly agree with the "man up" sentiment. That's my complaint about GWT and Pyjamas. But jquery and YUI and prototype all add these OOP features in different ways. Objective-j is still javascript. It's not compiled, it's just uniquely funny-looking. (Note: there are advantages to a single-language stack, and compilation is not the end of the world.)
As it happens, the javascript language is incredibly flexible and expressive. Maybe we in the js community should man up and accept that there are many ways to skin the DOM cat. They may look rather different from one another, but they're all javascript.
to me jquery feels less heavy-handed about the abstraction. every abstraction has a price, i tend to avoid them unless they have a demonstrated value. to me, OO has no demonstrated value
to be honest, i see the basis of objective-j born from some notion that apple does things right so naturally we all want to do things they way they do...but objective c sucks (having coded in it), and i have no idea why people would want to muck up another stack by pasting objective c onto it
"to be honest, i see the basis of objective-j born from some notion that apple does things right"
The word "apple" DOES NOT APPEAR IN THE ARTICLE. (I just checked.) Please, read the article and reply to the very thoughtful points made there. Ascribing some vague, unsubstantiated motives to people who have carefully laid out their entire reasoning behind their decision does not reflect well on your ability to engage in substantive discussion.
Having said that, I still maintain some skepticism about using a single language for the entire webapp stack. I understand their desire, for example, to be able to swap out the "rendering layer" in the future. However, CSS is a pretty good language for specifying how things should look across an entire web site, or part of a website, or single page, etc. I don't think Objective-J is a better tool for this particular job. Likewise there may be times when you just want to express structural relationships, and HTML might be better than Objective-J for that purpose (less sure about this one).
I don't know the details about Objective-J. Maybe they address this point elsewhere. The counter argument may be that Objective-J is for "rich web applications," and you don't worry so much about site-wide CSS style in that case.