LiveScript

I was looking at some of my old repos today. Enjoyed the nostalgia. Lots of CoffeeScript there. I had to switch to ES and then TypeScript because CoffeeScript was abandoned at the time and I was stretched over other projects to be able to help maintain it. Reading my old code, I was surprised by how clean it looks. How easy it is to digest. There is a certain sense of calm when your brain doesn't have to process all the visual clutter of a C-style syntax. I miss that. I wish I didn't have to choose between CoffeeScript and TypeScript. TypeScript first and foremost is about type safety and tooling. Its architecture is largely syntax-agnostic. It operates on the AST, so the parser and code generator can be swapped for a different syntax. CoffeeScript is all about syntax and does not (and should not) concern itself with most of the semantics

I did an experiment about a year ago when I re-wrote part of LiveScript's code emitter to produce a babel-compatible AST rather than javascript code. It would then pipe the AST to babel's generator and produce the final JavaScript. The benefit was that I could then use any babel-compatible toolset and still write code in LiveScript. ESLint worked with almost no tweaks necessary. Theoretically, you could also use Flow and TypeScript with this approach. Anyway, I didn't have enough time to finish the project, but somebody took the idea and did most of the work [0]. [0] https://github.com/dk00/livescript-next Would love to explain more, but have to board the plain now :) These links might help: https://github.com/gkz/LiveScript/issues/821 https://github.com/facebook/flow/issues/1515

Haha, yes. When I saw that LiveScript was using Makefiles[0] to build, I was baffled. To me they were ancient and complicated C/C++ stuff. But when I looked into them, everything seemed rather straight forward, even a bit nicer than Gulp, because of the syntax. [0] https://github.com/gkz/LiveScript/blob/master/Makefile

Since sweet.js code can't be directly run in the browser, you need some "compiling" or "interpreting" step. It's not obvious why this is any different from a compile-to-js language that had support for macros. For example, someone wrote a macro system for coffeescript: https://github.com/mrluc/macros.coffee Related discussions: https://github.com/jashkenas/coffee-script/pull/3171 https://github.com/gkz/LiveScript/issues/328

Fun facts: Grasp is by the author of LiveScript[1]. This was submitted by the author of CoffeeScript[2] [1] https://github.com/gkz/LiveScript [2] https://github.com/jashkenas/CoffeeScript

As CoffeeScript also went through this same process, bootstrapping itself away from an original Ruby-based compiler (at this moment: https://github.com/jashkenas/coffee-script/commit/6446e0004c...), Kal is now in some sense "two self-hosted steps" away from a "normal" language. That's pretty neat. GorillaScript (here: https://github.com/ckknight/gorillascript/tree/master/src), Coco (here: https://github.com/gkz/LiveScript/tree/master/src) et al, are also implemented in themselves. I hope that this trend of compile-to-JS languages tending to self-host continues.

They discussed this, and decided: a) partially-applied operators fills some of the gap, and b) they're far too complicated to implement. https://github.com/gkz/LiveScript/issues/19 https://github.com/taku0/placeholder_syntax_for_coffeescript...

Coco is amazing. To avoid becoming a "ghost town", I have made LiveScript much more compatible with CoffeeScript, easing transitions. I have invested time into making a decent website, and have now composed a couple of blog posts promoting LiveScript. Already several people have written projects in LiveScript: https://github.com/gkz/LiveScript/wiki/Projects-using-LiveSc... I hope with my continued efforts that the scenario you describe can be avoided.