4 ms·
Show HN: EmberScript - Ember.js Infused JavaScript
- ebiester 14y agoThe idea is intriguing. What if we think about tying a language to a library rather than the other way around? Lisp and Forth both had the idea that you should be able to build your language around the needs of your application, rather than the other way around, and this kind of source compilation feels like the extension of the idea. (Yes, we could always do the same thing, and often have, but not in web-world.)
- gte910h 14y agoThe web is a really weird platform for this though: There are SO many places the lower level language (the one you're translating to) has to properly handle, that DSLs feel like a big risk to many people I'm personally looking forward to stuff like "CoffeScript, a 5 year retrospective" etc, to show how safe all that stuff ended up being long term
- mhd 14y agoThis is basically what Vala is doing for glib/gtk (and it transpiles, too). Languages with a more flexible syntax probably don't need it as much, of course (lisp, forth, SmallTalk, tcl etc.).
- pavlov 14y agoNow that Objective-C finally has shorthand creation syntax for NSDictionary and NSArray, the language is officially tied to a particular library (Foundation -- although there are of course other implementations in addition to Apple's).
- bengillies 14y agoThis is interesting, but tying a language to a particular (version of) a specific framework strikes me as a bad idea. If the aim is to bake in syntactic sugar for different constructs within Ember that are awkward in plain CoffeeScript (and there are a few), wouldn't creating a CoffeeScript version of sweet.js[1] not be a better idea (I have no idea if such a thing exists already)? [1] http://sweetjs.org/ http://sweetjs.org/
- shaunxcode 14y agoI have been contributing to the strange cousin of the macro which is the notion of inline DSL fragment. https://github.com/ngn/coffee-subscript https://github.com/ngn/coffee-subscript In essence you get latex looking (\dsl) syntax to enter what ever DSL (which is just a standard node module). So this could be something as simple as an annotation style approach in which you consume the next chunk of coffee-script and simply wrap it - or something more involved like an entirely different language (this originally stemmed from the desire to have inline APL ala https://github.com/ngn/apl https://github.com/ngn/apl - which provides \apl and \apl.fn respectively). http://github.com/shaunxcode/jsedn http://github.com/shaunxcode/jsedn and http://github.com/shaunxcode/swedn http://github.com/shaunxcode/swedn also work currently. Right now they are naive e.g they just emit a call to parse at runtime, when I get the time they will actually be more clever and, well, actually compile at compile time hah. Recently I have been toying with adding type annotations so I can easily port a code base to typescript but have them be entirely ignored by coffee. One side note is that we have discussed adding support for sweetjs as right now these are definitely DSL hooks and not hygenic macros. In fact I would go so far as to call these toothless macros e.g. it is up to you to chew the food (parse) and swallow it (emit valid js).
- tlack 14y agoIt would be fantastic if this kind of stuff was embraced by the CoffeeScript people and something like Erlang's parse transforms was implemented: # mycode.coffee: "use parse_transform('observers.coffee')" class Gradebook +observe scores gpa: -> sum(@scores)/@nGrades Imagine the interesting (or perhaps chaotic) ecosystem that would develop if this kind of thing was encouraged?
- 14y ago
- machty 14y agoI love the CoffeeScriptRedux project and this is a perfect little application of it. It's very easy to pick up once you know CoffeeScript and I love the idea of stylizing your developer tools to fit a framework as rightfully opinionated as Ember.