Update: For the last few months, Asana has moved from
writing Lunascript for our application code to Javascript.
The two main things that were slowing down our development:
too much remaining research-level work to make the compiler
output more performant code
lack of tool support
We're *not* a framework company, so we didn't want to devote
years to this work at the expense of building our product. We're
still using the framework primitives we developed for the
language -- most importantly, systems for reactively recomputing
our UI and synchronizing changes with the server -- we're just no
longer using the slightly nicer syntax (and functional style)
that Lunascript provided.
Long term, we may revive the Lunascript compiler. We think this
may be especially appealing once we shift from focusing Asana as
a single product to Asana as a platform. But for the immediate
future, we're focused on releasing our first product at the
expense of continuing work on Lunascript proper.
Nice find. I think it Lunascript might the classical case of programmer naiveté: "I can re-invent the wheel so much better, and it will take not that much time".
Usually is part of the process of maturing up as a programmer/engineer. Get the main stuff done (wow, this looks like a cool idea), but soon you are treading in deep waters as soon as the technology start hitting the edge cases, and day to day usability.
My self have started a couple of these overambitious projects, without realizing the amount of work it takes to get something in production level. Sure you can cover the base functionality pretty quickly, but it is the edge cases and polishing and making a robust solution that actually take the most time.
Sometimes these over-ambitious projects, succeed (Linux is the prime example), but usually they do because there is a huge need in the market for such product.
Perhaps Lunascript is something more 'interesting in paper, but not that great in practice'.
As much as I don't really like the "DSL" terminology for anything less than a true language with a parser and AST of its own, the advantage of the Ruby-esque "DSL"/library-with-carefully-chosen-name-conventions is that you are starting from the base of a known-working language. I have a "DSL" I wrote at work for decorating functions with various metadata and recurring bits of functionality like permissions checking in Perl for work, but because it's just not-really-even-glorified Perl I still have the full power of Perl to do things like programmatically generate these functions. Using a recurring set of decorations is as easy as sticking them in a bog-standard Perl array and just passing them as bog-standard arguments in the right place.
It's tempting to replace your language entirely and compile down to something else, but IMHO this sort of thing shows that's a very dangerous play that generally succeeds big or fails big, usually the latter. Incremental expansion of an existing language, even with something as powerful as a syntax preprocessor (that ideally compiles to results that are themselves manipulable language constructs like closures or simple values passed in an idiomatic way), is generally the way to go; most of the win, hardly any of the risk. Something like StratifiedJS or something, if I understand it properly, adding meaningful additional syntax without trying to be its own independent language: http://onilabs.com/stratifiedjs Or, from the sounds of it, the way this language ultimately went.
Javascript may not be quite as slick as Ruby, but, well, to be honest I think Ruby partisans really oversell the value of being able to drop a few parentheses out of your code, and while the block syntax may be nicer JS still has relatively decent closures.
> Sometimes these over-ambitious projects, succeed (Linux is the prime example), but usually they do because there is a huge need in the market for such product.
Linux was not that ambitious to start with. That's why it succeeded: while everyone else was waiting for Hurd or AT&T-free BSD, Linux was rapidly gaining momentum.
This is the first time I've heard of Asana or Lunascript, but that sounds amazingly like the application server, language and framework I worked on at the previous company I was with.
Reactive / dataflow languages are just perfect for UI binding, and in data-intensive applications (think things like insurance quotes, finance) they can minimize the amount of kludgy UI update logic. The language I wrote was called Gravity (because it kept on sucking in responsibility), and compiled to .NET, which was very easy because it could just use Reflection.Emit and DynamicMethod.
With an in-process debugger I wrote, and the state storage mechanism it used (a bit like a Smalltalk image but with the code referred to via an intranet http URL, so it was really small, less than 60K usually), it had other powerful features, like migrating an app session from one machine to another (think of a helpdesk investigating a problem), playback of the entire application session (for testing or fault reproduction), or post-mortem investigation of the heap.
These kinds of features are very hard to get if you just take what a host language gives you and try and build a DSL on top of it. I understand why many people shy away from it, but the productivity advantages can be substantial, sustainable and strategic. The grammar and semantics of the Gravity language I developed for this were very similar to a subset of C#, except with more SQL-like null handling. That can minimize the learning and unfamiliarity overhead without losing a lot of that advantage. If I were doing a startup today, and it involved the same kinds of challenges, I'd still take a similar approach - and as a compiler engineer in my day job, I don't have illusions as to the depth of the technical problems around production-ready languages and tooling.
If you're still around: did you evaluate flapjax? And if so did you find it lacking, or just not a good fit for your needs? I'm curious about FRP, but don't have any experience with it.
That blog post is from a year ago. In the intervening time, Asana's actually moved away from developing Lunascript. [1] Instead, they're just coding in Javascript. There's a lesson in there somewhere [2]
:P
It's important to note that we abandoned (or "put on hold") Lunascript, but not Luna. The vision for Luna always revolved around making it easy to write bug-free, real-time, responsive, collaborative, interactive webapps. The syntax of Lunascript over directly using the framework in Javascript was always a nice-to-have.
I'm not denying your lesson, of course. To this day we still have some Lunascript in the codebase, and it does create some developer friction that costs real time. In retrospect, I'm sure it seems obvious that we should skipped the language and just built the framework.
However, it's important to understand that the language itself was built mostly by Justin very early in the company's history, and basically no work was poured into it after we hired employees and built out the product. One framing of Lunascript is two guys taking a few months to try a few big ideas out before building a company they want to do the right way. We always knew we would have to compromise on ideals once we moved forward, but we wanted to see what stuck. I think a lot of the reason we're under scrutiny here is because people look at the time since D+J left Facebook and are like "what did you guys do with all that time?" The answer is the company didn't get started in earnest until almost a year later when we hired Greg and Malcolm.
Polish and strap this baby to Node.js and we got something interesting!
This functional model is something I've been striving towards in Rails, but over the years I feel the "rails way" more emcompasses development idioms instead of application idioms.
Rewriting a web framework from the ground up is so often a trap made alluring by the illusion of repeated code. Could there be a more optimal way of writing UI code? Of course. But a lot of UI code should just be treated for what it is: largely unmaintainable and unextendable, especially in the face of design changes. I'd love to spend a weekend hacking out a sexy, interactive app, but I'm not yet willing to invest 2 years to save a couple days of redundant development. I'll leave that for the companies not worried about making money or do it on the side through an open source project.
Two people, six months - most of it discussion, ~40K C# code, in my previous job we had a framework, compiler, debugger, mini IDE, app server with a kind of tiny in-memory database (supported object-graph-style navigation) that let us write interactive UIs using databinding with minimal repeated or hacky code, and a whole bunch of other hard-to attain features (for example, application code version rollovers with old sessions running in parallel with new versions until they're finished with, without needing to restart any process or machine anywhere). I've seen it done - more than that, I've been part of doing it - and I have yet, in the intervening 4 years, to see anything as well suited to its purpose.
It's cheap and easy to be cynical about these kinds of things. But it's very important to realise that there is so much that is possible today, but will be dismissed by cynics, that tomorrow we'll say "sure, that was easy, anybody could have done it" - but very few did.
I've never seen this problem better solved in a web framework than in some combination of libraries. I'm sure it can be done and I welcome people who want to do it, all I'm saying is that I couldn't justify the ROI on it myself. On our projects, we get 90% of the way there by using a server-side REST library coupled with a small Javascript library on the client to handle the common paths.
Anywho, cynics are useful- they make us reconsider the value proposition we are putting forward. However, an idea shouldn't be discarded just because a cynic addressed it :)
A Lunascript application specifes a data model and a function from the model to the view or user interface, annotated with handler functions from user inputs to model mutations. From this the Lunascript compiler produces a functioning Web 2.0 application — the client-side JavaScript, the server-side SQL, and everything in between
Debugging can still be somewhat tricky, but we are disciplined about creating and improving debugging tools
We hope to release Lunascript more widely once it’s more mature
the few core features of the video seem generally unnecessary. automatic data binding on multiple clients and auto syncing with offline storage is cool- but not really imperative for most apps to get started (which is where tools like this will shine).
that said, the project is obviously young and i obviously know very little about it, so i am interested to see how it develops.
that said, this is a problem many have tried to solve (without writing their own language), and (imho) failed. backbone is (imho) taking the first step in the right direction. to be clear, i am not comparing lunascript to backbone directly. they seem to be two very different solutions for the same problem.
To some extend Angular is doing something similar today and it's available, http://angularjs.org
It does not synchronize multiple clients yet, but I certainly wish it will ; with Comet becoming increasingly easy to integrate, this may happen sooner than expected.
http://www.quora.com/Why-is-Asana-developing-their-own-progr...
To quote: