On Leaky Abstractions and Objective-J

On Leaky Abstractions and Objective-J(cappuccino.org)

52 points by tr4nslator 17 years ago | 46 comments

jimbokun 17 years ago |

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.

kentosi 17 years ago | |

He does make the distinction that Cuppaccino/Objective-J is for web-applications and not web-pages. see: http://cappuccino.org/discuss/2008/10/21/web-pages/

For web-pages i agree with you that traditional html/css is sufficient in most cases.

volida 17 years ago | |

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.

I think this Objective-J is the wrong thing.

boucher 17 years ago | | |

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.

stcredzero 17 years ago |

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.

tolmasky 17 years ago | |

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:

call_method_or_send_method_missing(object, "method_name")

And again, since Objective-J is a proper superset of JavaScript, it doesn't lose any of its powerful features.

drwh0 17 years ago | | |

And again, since Objective-J is a proper superset of JavaScript

really? what can it do that js can't do?

jimbokun 17 years ago | |

"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.

eggnet 17 years ago | | |

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.

sayrer 17 years ago |

Does anyone else find the term "leaky abstraction" annoyingly redundant?

ced 17 years ago | |

Why? Mathematical abstractions are leak-free, and so are a lot of computer abstractions. What's wrong with emphasizing the leakiness in some cases?

poub 17 years ago |

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.

Tichy 17 years ago |

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).

shaunxcode 17 years ago | |

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?

Tichy 17 years ago | | |

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.

volida 17 years ago | | |

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.

newt0311 17 years ago |

Interesting article but I for one genuinely prefer libraries to syntactic language changes. We do not need another language among the thousands already there.

jimbokun 17 years ago | |

"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.

newt0311 17 years ago | | |

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?

If that is true, then said "thing" is a library.

drwh0 17 years ago |

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.