Lunascript, another language for writing great web apps
asana.com
asana.com
The good news is that a language for in-house use need not be finished to be useful. For example, FB's PHP compiler can't compile "eval." No problem, don't use eval in-house. If they were trying to "finish" it in the sense of writing a compiler for every possible PHP app, they would have to address that somehow. But instead, they punt on it and carry on using it in house.
I think they're likely to be an ongoing distraction for the above reason, and also because of the fun/intellectual challenge reason.
> punt on it and carry on using it in house.
Over time, that kind of thing can (if you're not careful) lead to dangerous cruft, where the in-house divergences pile up to the point where it's no longer so easy to go back and forth between the public/open version. And thus is born a new species with a far smaller ecosystem than the original.
of non compiler/language processing experts.
If you've built compilers before and know what you are doing (I have no idea if these guys are such experts or not) , it may be a reasoned decision taken after weighing benefits and costs.
Leon Bottou and Yann LeCun seems to have built the Lush dialect of lisp to build commercial systems. (http://lush.sourceforge.net/credits.html)
For example, I can easily imagine PG building a variant of lisp and building a product/company around that . Of course if you only have a vague idea of how to build a compiler/interpreter/whatever, then building a company around your first such project may be ... interesting.
Or perhaps using Lisp to write his own continuation-based web framework and building a company around that?
I'll grant that investing in language development is unusual. But the risks involved aren't sufficiently different from those taken by 37signals in choosing Ruby and developing a framework. There are payoffs for core technology development.
I didn't realize the technology used would deter an acquirer. This probably explains why most startups go with "safe choices".
Bizdev is an awful reason to choose technology, or for that matter to make any other decision about your product. I'm just refuting the statement that writing your own programming language will help you get bought.
When you evaluate a startup, what do you look at first, the idea or the team? Obviously, the team. Why? Because (a) you want to know if they're capable of implementing the idea and (b) because you know that ideas almost always change, so the team's ability to rapidly implement and iterate is its real strength.
I agree that this struck me as somewhat absurd when I heard Asana was developing a new language, but if it actually works as advertised then it's really smart.
The only way you are going to get 10x, with roughly equivalent people is if someone is using a wholly inappropriate language (Ruby vs Forth for web apps, say), or if you can avoid writing libraries because someone has already written them.
This is one of the positive network externalities involved in programming language economics: the more people involved, the more likely it is someone has already written the code you need. Of course, these effects are not so strong that everyone gravitates to only a few languages, but they are certainly a consideration.
By writing your own language, unless it makes it very easy to take advantage of some other language (the JVM languages are a good example), you are pretty much guaranteeing that you will have to do this work yourself.
Why so negative?
Perhaps there is some room for radically new implementations; something along the lines of Erlang, which makes it possible to do what is quite difficult with other languages.
I think there is more room in frameworks for existing languages, but still, an order of magnitude seems quite dubious to me.
I'm actually not at all negative about new languages (I hack on a simple one myself), startups just don't strike me as the place for them. What they're doing does look cool, but what happens when you need to process an image, or send email, or talk to a different database, or deal with any of the other various things that are often covered by language extensions? Maybe this would have been better as a hack/framework on top of Javascript.
Did you see the bit where they can drop into raw Javascript at will?
I guess without actually seeing the code behind it, it's difficult to really say with certainty.
Yes, but the difference is not one order of magnitude. Not if there is some level of sanity in the language (e.g., I am not talking about brainfk). For example, even though one can program faster in Python, it is not 10 times faster than in C, especially for large-scale software.
I will however finish with, there's a reason C applications don't have features or agile development cycles, and it's not because the coders are absurdly productive. Also, please don't ever try to be a manager.
Or if your competitors are using the standard languages and tools, and you're using a language that provides significant abstractions on top of the standard languages and tools.
I was on board with your comments until I watched the video. Their language looks to be a jump on the order of assembly to C.
find . -name "*.rb" | xargs wc -l | tail -1
161472 total
find . -name "*.rb" | xargs wc -l | tail -1
639682 total
find . -name "*.c" | xargs wc -l | tail -1
590656 totalThe Wikipedia link isn't terribly informative, but there's a ton of more relevant literature tied in with functional reactive programming. (That's the FRP in their to-do list). In particular, there's a research project called Flapjax that you can play with right now that drives home how nice it could be to program in this paradigm.
I have two worries about Luna, though. It doesn't look like they're using a nice type system, which will be a pain for larger apps. And I can't say I like that "Finish patent documentation for incremental computing framework" to-do item.
However, I am confused about this announcement since I cannot discover what your company does from the web page and except the video there's not much to go on about the language. Perhaps you want to fill in some blanks in the comment section?
Interesting approach.
The screencast is very good.
Wonder if that 1500 line todo list app is part of Asana?
To illustrate: You have some piece of state y, and you have x = f(y) that means "x is always the value of f(y), when y changes, update x." Furthermore x is shared state across many users. On the server side you want that statement to generate code for synchronizing values of x and y across users. On the client side you want to generate code for pushing and pulling Ajax/Comet updates from the others.
Edit: reading more closely, I see why you say that -- "incremental computing" link makes me think of FRP a little bit. But these people's goal with Lunascript seems to be automatic communication between the client and server. The "incremental" part is sending only what's needed to the client to execute the client-side code, which is a really cool idea, but not very much like FRP, I think.