[deleted]
On Leaky Abstractions and Objective-J
31–40 of 50 posts
Re: On Leaky Abstractions and Objective-J
#32Earlier quoted context omitted.
"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…
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.
"LISP territory where the line between mini-language and library is truly thin"
Which demonstrates how successful Brandon Eich was when he set out to make Javascript a Lisp-like language.
Re: On Leaky Abstractions and Objective-J
#33Does anyone else find the term "leaky abstraction" annoyingly redundant?
Re: On Leaky Abstractions and Objective-J
#34This 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…
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.
Re: On Leaky Abstractions and Objective-J
#35Earlier quoted context omitted.
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.
That's inconsistent with how quickly Apple had Carbon ready using C. Just a matter of effort.
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.
Re: On Leaky Abstractions and Objective-J
#36Earlier quoted context omitted.
"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…
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.
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).
Re: On Leaky Abstractions and Objective-J
#37The 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 c…
"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…
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.
Re: On Leaky Abstractions and Objective-J
#38This 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…
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.
Re: On Leaky Abstractions and Objective-J
#39I 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…
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 - a…
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.
Re: On Leaky Abstractions and Objective-J
#40I 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…
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 - a…
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.