8 ms·

Symbiotic Languages [video]

45 points by lispython 14y ago

sylvinus 14y ago
You can see the other talks from dotJS 2012 here: http://dotjs.eu http://dotjs.eu The 2013 conference will be announced soon, you can register here to be kept updated: http://dotconferences.eu http://dotconferences.eu
why-el 14y ago
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.
- xutopia 14y ago
  I believe it's a plugin he is using inside Sublime Text. Might be this one: https://github.com/Xavura/CoffeeScript-Sublime-Plugin https://github.com/Xavura/CoffeeScript-Sublime-Plugin alt+shift+d - Display compiled JavaScript
  - mhd 14y ago
    He's using TextMate, and apparently wrote the appropriate plugin/bundle himself: https://github.com/jashkenas/coffee-script-tmbundle https://github.com/jashkenas/coffee-script-tmbundle Command to show the JS equivalent: https://github.com/jashkenas/coffee-script-tmbundle/blob/master/Commands/Compile%20and%20Display%20JS.tmCommand 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.
johncoltrane 14y ago
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 http://www.youtube.com/watch?v=UIDb6VBO9os) was the funniest and Mathias Bynen's (http://www.youtube.com/watch?v=XD_5xDN7KUA http://www.youtube.com/watch?v=XD_5xDN7KUA) was the most instructive.
pdog 14y ago
Nice jacket :)
6ren 14y ago
The approach of Dart, of being both "symbiotic"/"transpiled"-to-JS and having its own fast standalone VM is an intriguing adoption strategy.
camus 14y ago
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 ).
- pjmlp 14y ago
  I only see it being used on startup projects.
  - danso 14y ago
    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.
tiredofthesame 14y ago
Yawn. Another SAWCASM. Is this really the best we can do? Another straight, pasty cis dude?
stcredzero 14y ago
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.
- chc 14y ago
  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.
  - stcredzero 14y ago
    What they do currently is tolerate. If they set out some concrete criteria, that would be a positive step.
    - chc 14y ago
      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.
      - stcredzero 14y ago
        > 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.

45 points by lispython 14y ago

You can see the other talks from dotJS 2012 here: http://dotjs.eu http://dotjs.eu The 2013 conference will be announced soon, you can register here to be kept updated: http://dotconferences.eu http://dotconferences.eu

why-el 14y ago

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.

xutopia 14y ago
I believe it's a plugin he is using inside Sublime Text. Might be this one: https://github.com/Xavura/CoffeeScript-Sublime-Plugin https://github.com/Xavura/CoffeeScript-Sublime-Plugin alt+shift+d - Display compiled JavaScript
- mhd 14y ago
  He's using TextMate, and apparently wrote the appropriate plugin/bundle himself: https://github.com/jashkenas/coffee-script-tmbundle https://github.com/jashkenas/coffee-script-tmbundle Command to show the JS equivalent: https://github.com/jashkenas/coffee-script-tmbundle/blob/master/Commands/Compile%20and%20Display%20JS.tmCommand 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.

johncoltrane 14y ago

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 http://www.youtube.com/watch?v=UIDb6VBO9os) was the funniest and Mathias Bynen's (http://www.youtube.com/watch?v=XD_5xDN7KUA http://www.youtube.com/watch?v=XD_5xDN7KUA) was the most instructive.

pdog 14y ago

Nice jacket :)

6ren 14y ago

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

camus 14y ago

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

pjmlp 14y ago
I only see it being used on startup projects.
- danso 14y ago
  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.

tiredofthesame 14y ago

Yawn. Another SAWCASM. Is this really the best we can do? Another straight, pasty cis dude?

stcredzero 14y ago

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.

chc 14y ago
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.
- stcredzero 14y ago
  What they do currently is tolerate. If they set out some concrete criteria, that would be a positive step.
  - chc 14y ago
    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.
    - stcredzero 14y ago
      > 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.