Symbiotic Languages [video] | Hacker News Reader

Symbiotic Languages [video]

ashkenas.com

45 pointslispython16 comments

I think the technique of having language A which is homomorphic to language B is a powerful tool which deserves more recognition.

For one thing, Apple should realize the power in this technique and welcome languages other than Objective-C targeting their runtime, provided that there is an automatic facility for ensuring feature-completeness of the environment to the SDK. Such homomorphic languages would let Apple retain all of its control of the environment/ecosystem while giving developers choices.

Also, that's just one example of the power of this technique.

What do you mean "welcome"? AFAIK they don't stop you from using an alternative language now as long as it can work within the same constraints as Objective-C (e.g. runtime code generation is a no-no). Hence MonoTouch and its kin.

What they do currently is tolerate. If they set out some concrete criteria, that would be a positive step.

I don't mean to be difficult, but I'm not quite following. It seems to me that setting out concrete criteria would be more exclusionary than the current policy of "If it runs OK, we don't care how you made the sausage." The only reason I can see to want Apple to be less permissive is if we're beset by a flood of crappy alternative languages and we need some standards to hold language implementors to — but I don't see that problem being a real thing. So I'm a little confused about what you're looking for.

> The only reason I can see to want Apple to be less permissive is if we're beset by a flood of crappy alternative languages and we need some standards to hold language implementors to

I think the reason why there aren't more alternative languages, is that right now Apple is completely arbitrary about accepting a language/environment or not. The fact that one still has RubyMotion, eero, MonoTouch, and a host of others, despite their original stance of no is a nice circumstance. For the most part, they are as I described -- they are architected such that the whole of the SDK is covered automatically, little or no manual intervention required.

Your mind is stuck on "less/more permissive." What I'm asking for is "more explicit" and as a consequence an element of commitment. As it stands now, it's arbitrary, and Apple can just say no in the future.

Apple was bitten once by the Metroworks Codewarrior thing, where a 3rd party environment was the de-facto way of doing development and became a brake on progress with their APIs. Introducing a standard where automatic coverage of newly released SDKs is the central point would get them out of the business of ad-hoc approval of such environments while protecting their interests.

> So I'm a little confused about what you're looking for.

Either you didn't have all of the background info, you didn't bring it to mind, or you think of those circumstances in a different way.

> I think the reason why there aren't more alternative languages, is that right now Apple is completely arbitrary about accepting a language/environment or not. The fact that one still has RubyMotion, eero, MonoTouch, and a host of others, despite their original stance of no is a nice circumstance.

Well, it's a little more than "those exist despite Apple's original stance." Apple explicitly changed its rules to eliminate that restriction in response to developers' feedback.

> Your mind is stuck on "less/more permissive." What I'm asking for is "more explicit" and as a consequence an element of commitment. As it stands now, it's arbitrary, and Apple can just say no in the future.

Ah, I think this might be where we are seeing things differently. Apple very clearly changed its rules to allow alternative languages, which means it's "supported right now," which I view as close to the maximal level of commitment one can get from Apple about anything. I don't feel like something more formal would indicate more of a commitment. Apple could change its rules to disallow alternative languages tomorrow; it could also do the same thing the day after it set down standards for alternative languages.

After how abruptly Apple cut off Carbon and Java developers, killed development on the Objective-C garbage collector almost as soon as it was released, deprecated the garbage collector shortly after the App Store was released (meaning that GC apps were then banned from the store) and axed Rosetta after just two OS updates, I've come to realize that Apple has absolutely no qualms about changing its mind no matter how explicitly it supported something yesterday.

The approach of Dart, of being both "symbiotic"/"transpiled"-to-JS and having its own fast standalone VM is an intriguing adoption strategy.

You can see the other talks from dotJS 2012 here: http://dotjs.eu

The 2013 conference will be announced soon, you can register here to be kept updated: http://dotconferences.eu

I was there. Jeremy's talk was very inspiring. Among the top three of the day, easily.

Fat's talk (http://www.youtube.com/watch?v=UIDb6VBO9os) was the funniest and Mathias Bynen's (http://www.youtube.com/watch?v=XD_5xDN7KUA) was the most instructive.

Nice jacket :)

Great talk. Does anyone know how I can get that inline complier Jeremy was using? I don't use Coffeescript just yet but I figured that could be useful when I decide to pick it up.

I believe it's a plugin he is using inside Sublime Text. Might be this one: https://github.com/Xavura/CoffeeScript-Sublime-Plugin

alt+shift+d - Display compiled JavaScript

He's using TextMate, and apparently wrote the appropriate plugin/bundle himself: https://github.com/jashkenas/coffee-script-tmbundle

Command to show the JS equivalent: https://github.com/jashkenas/coffee-script-tmbundle/blob/mas...

Actual work is done via `coffee -scp -bare`, then the output is massaged and formatted for the editor popup.

I would say CoffeeScript is a parasitic programming language. We will only "get rid" of it by "curing" the original langage from all its flaws(which might never happen ).

I only see it being used on startup projects.

Wouldn't that make sense, given the youth of the language (3 years old) and the (justifiable) reluctance of a company to switch its codebase to another language? Most tech companies that have started in the last three years are probably in the startup category.

Reply on news.ycombinator.com