

On Leaky Abstractions and Objective-J - tr4nslator
http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-and-objective-j/

======
jimbokun
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.

~~~
volida
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
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.

~~~
volida
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.

------
stcredzero
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
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
_And again, since Objective-J is a proper superset of JavaScript_

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

~~~
jorgeortiz85
Read his first sentence again:

"There is also the issue that implementing things like method_missing and
import are prohibitively difficult without new syntax."

~~~
drwh0
"difficult" has nothing to do with the power of languages

TeX macros are fundamentally as expressive as java.

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

~~~
ced
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
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
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
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
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.

~~~
shaunxcode
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.

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

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

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

~~~
boucher
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.

~~~
drwh0
_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

~~~
jimbokun
"1. goofy/eyes-bleed syntax"

This is almost always an indication that a programming language critic has
nothing really thoughtful to say. Same with Lisp and S-expressions.

If I may paraphrase: "It's slightly different than what I'm used to, therefor
I despise it."

~~~
thomasmallen
I agree, the middle part is weak, but the bookends are compelling arguments.

~~~
jimbokun
You mean:

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

~~~
drwh0
_Apple tried Java bindings to Cocoa at one point_

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

~~~
cpr
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.

~~~
thomasmallen
That's inconsistent with how quickly Apple had Carbon ready using C. Just a
matter of effort.

~~~
boucher
Carbon is a port of C APIs from the classic mac mostly. On top of that,
Objective-C is ultimately C, and its easier to talk between the two than Java.

