On Leaky Abstractions and Objective-J

http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-and-objective-j/

by tr4nslator • 18 years ago

52 46 18 years ago

drwh08• 18 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.

boucher3• 18 years ago

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.

drwh08• 18 years ago

Separately, Objective-C is a great language, and plenty of people love it

so much so that its almost impossible to find it being put to use outside of places apple forces it. and before you say "gnustep"...no one uses that

Can you give me three reasons why you don't like it?

1. goofy/eyes-bleed syntax

2. i don't care about OO

3. i'll think of something later

Finally, claiming OO programming is dead is nonsensical. Java is by far the world's most popular programming language.

java is a ployglot language. they're busy now trying to turn it into a hybrid-functional language...just like c#, the other kitchen-sink language

and c++ was designed from the ground-up to be multi-paradigm, this is all over everything stroustrup says about it

IsaacSchlueter• 18 years ago

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.

drwh08• 18 years ago

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

stcredzero• 18 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• 18 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.

drwh08• 18 years ago

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

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

jimbokun7• 18 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• 18 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.

newt03112• 18 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.

jimbokun7• 18 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.

newt03112• 18 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.

jimbokun7• 18 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• 18 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.

volida4• 18 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.

boucher3• 18 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.

Tichy3• 18 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).

shaunxcode2• 18 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?

volida4• 18 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.

Tichy3• 18 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.

sayrer• 18 years ago

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

ced• 18 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• 18 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.

On Leaky Abstractions and Objective-J

Related Stories