To me the big story here is that Tessel apparently has a working JS->Lua-bytecode compiler.
Lua has by far the smallest, most portable, easy-to-integrate runtime of any embeddable language I am aware of. JavaScript has good implementations (V8, etc) but they are orders of magnitude larger, more complex, and imposing if you're linking them into your binary.
If this is truly a robust JS implementation, this means that there is now a tiny, easy-to-embed implementation of the programming language that powers the web. This could enable JavaScript to start making inroads in the "embedded language" space, and really become the language of both client and server.
If it can compile to LuaJIT bytecode also, it could also possibly be competitive in speed with other JS implementations, though some of that would depend on how efficient the resulting bytecode can be.
I think this would actually be a cool trend. Having a code-base that can run either in the browser or "natively" is a powerful approach. Though Lua is a cleaner language, JavaScript is a totally decent language if you use it right -- much better than a lot of people give it credit for. Hint: if you think JS sucks because of browser incompatibilities, what you really hate is bad implementations of the language, not the language itself.
Of course another approach to achieve "one language" would be to have a Lua->JS compiler (or Lua->asm.js, or a Lua interpreter in asm.js). But Lua the language is a bit more of a moving target; to preserve cleanliness and orthogonality they sometimes break the language in non-backward-compatible ways.
> Hint: if you think JS sucks because of browser incompatibilities, what you really hate is bad implementations of the language, not the language itself.
At the risk of going slightly off topic, this is true only if you have purely academic interests.
A programming language, fundementally, is just a document with a spec (for the sake of argument, let's ignore the languages that have a reference implementation as a "spec"). That spec is all there is to it for PL geeks.
Us engineers, however, we want to use a language. I don't care what's in a spec, I care about whether it works, and how. Whether it works is completely related to the implementations of the language that I need to consider, and completely unrelated to the language spec.
Besides bad JS implementations, Python is a fun example. It effectively has two mainstream implementations: CPython 2 and CPython 3. If you want to support both, you face all kinds of hurdles, much like cross-browser JS programming.
Does this mess badly reflect on the language itself? Hell yeah.
Do keep in mind though that writing JS for the web is one of the few instances today where an app is expected to run flawlessly on several completely independent implementations. Put any other language in JS's place and you'd probably have gotten a similar number of incompatibilities between browsers (especially since many/most of these incompatibilities are actually in the DOM -- an API). This is a symptom of software diversity, not of JS.
"Do keep in mind though that writing JS for the web is one of the few instances today where an app is expected to run flawlessly on several completely independent implementations."
This is indeed a hard problem, and is precisely why the ECMAScript specification exists. Whether it's precise enough in all instances is another question. In other realms, the same problem is faced by Java, and there the implementation is split into the compiler and the JVM. Breaking it into two pieces at these boundaries has advantages - compliance suites can test that the compiler generates valid bytecode (the Java equivalent to native machine code) and further test that the JVM behaves as expected with known bytecode.
Most of the inconsistencies in JS are with respect to the DOM / standard library exposed by the various browsers. That is surely not part of the PL.
As for Python 3, if they hadn't made breaking changes, people would complain instead about the various warts the language has acquired over the years that they refuse to fix for the sake of backward compatibility. There's no solution that makes everyone happy, but I'm glad that the python community is still willing to make high risk / high reward decisions about the language's evolution. That's a sign that it's not yet set in its ways.
Oh, sure enough. I agree with the Python 3 decisions. In fact, my beef is mostly with the (otherwise excellent) ecosystem not doing enough effort to keep up. You only need a few major frameworks and libraries to say "ok, next release is Py 3 and Py 3 only" and the whole ecosystem moves over within a year, I'll bet.
>CPython 2 and CPython 3. If you want to support both, you face all kinds of hurdles, much like cross-browser JS programming. Does this mess badly reflect on the language itself? Hell yeah.
I don't think that it's at all the same as the current JS problems. Most Python devs (myself included) are sticking to the newer 2x releases because
- things work perfectly well in 2x
- 2x is still actively developed
- we can pull down 3x behavior from 'future' when wanted
- no one is putting a gun to heads to make people upgrade
- python isn't client side. if you can't make up your mind or ship correctly, that's on you, the dev
Which is to say, I don't see how this reflects poorly on the language. If a developer feels that he needs to support Cpython 2 and 3, that's his own deal because he could pick one and bundle his application appropriately.
Now for JS, you don't really get a say as a front-end dev because the client is in charge of what interpreter he brings to the table. You don't get a say, unless you know what browsers you can get away with targeting (e.g. ie6 users aren't likely to be shopping for the latest android device).
The latter, in particular, is important. If there is runtime translating Javascript idiosyncrasies to Lua, performance may be really bad. For example, it may be a lot of work to map Javascript's == with all its quirks (http://www.rossgledhill.co.uk/2011/10/12/javascript-quirks-e...), where the integer 3 equals the string "3" to Lua's equality operator (http://www.lua.org/pil/3.2.html), which behaves like Javascript's ===: "If the values have different types, Lua considers them different values."
And no, that does not stop at "but no sane person should use == in Javascript". '<' is different, too: "To avoid inconsistent results, Lua raises an error when you mix strings and numbers in an order comparison, such as 2<"15"."
This is why the presentation keeps talking about web developers. There are more web developers than there are any other kind of programmer. If you want to make your programming platform accessible, make it accessible to web developers.
Is it really this hard for devs to learn proper languages for whatever they're doing? I almost think knowing multiple languages and having the ability to learn new ones quickly is what it means to be a programmer/developer, etc...
I'd be more interested in what embedded JavaScript would allow to be done that other existing tools can't currently do. After all, if you're a JavaScript person and you needed to do something on a device or platform, you wouldn't wait for a language runtime to become available, you'd just go learn the existing language/tools and build it?
Is it really this hard for devs to learn proper languages for whatever they're doing?
It's not hard.
But given a choice between Platform A which says "write in a language that all of you already know", and Platform B which says "write in this language most of you don't already know and would have to put in time and effort to learn before you could do anything useful with this platform"... which one would you bet on?
Not sure what sort of crack everyone else is smoking, but I generally base my decisions on how painless it is to develop for a new platform rather than one I already know. Other than that, if I don't know the language, but the environment really kicks ass, I'm going to learn the damn language.
Unless I'm really rushed and have 2 days to do a vast amount of work.
I addressed this in my last paragraph. Lua is a nice language (and I use it myself) but it has downsides too. Noticeably it is a moving target that breaks backward compatibility. And I'm not sure what the state of the art is in terms of running Lua in the browser.
Lua breaks backwards compatibility every 3-5 years in minor ways, and they support version n-1 in version n. And it is not very hard to migrate code bases between versions of the language.
having written a fair amount of lua code, there aren't many libraries out there. Their npm equivalent is called 'luarocks'. To give you an idea of how old the libraries are: many of them mention the perl package it was translated from.
The reason for that of course is that it's so trivial to embed it in a C program, that if you want a library you can just expose a C library in lua. luajit even makes this absurdly easy with its FFI api.
Right, but libraries consist of many other things, including ORM or testing suites. There aren't many great ORM libraries written in C, and you need the test suite to work in lua because you're testing lua code. In general, the world of lua is pretty small, probably smaller than languages like Clojure or OCaml.
The fact that many libraries are "translated from" Perl packages does not mean they are old, it means a significant part of the Lua community has used Perl before. Actually, because Lua 5.2 has been released recently and broke compatibility, libraries that support it are by definition not "old" (or at least they are maintained).
That being said, the community is small and there are indeed way too few libraries available in LuaRocks (slightly over 300). We have been discussing that on the language's mailing list and I will probably talk about it at the upcoming Lua Workshop (http://www.lua.org/wshop13.html).
The parent isn't arguing for local by default, just against global by default. Insomuch as you buy into the arguments in that link, the answer is to do neither (i.e. you must always use "var"). Most of those arguments are actually even more damning to global by default.
> I would personally be happy to sacrifice that feature and add an explicit "global" keyword but not everybody agrees, and it would break a lot of code.
For sure. That ship has probably sailed. And, like you said, linters alleviate a lot of that pain. But that's a separate question from, "is this a good language feature?"
Anything by default is idiotic. Lexical scoping works when variables are declared. Lexical scoping becomes a burden when deceleration is not required and variables fall back to some default scope.
Kind of remind me of GWT Compile Java to Javascript.
In order for "debug" (not just writing/copy-paste some demo code) any "real" project with that, you have to to be expert in Java, Javascript and all the tiniest details of GWT framework. Any crash, stack trace involve stack trace thru the JAVA framework, javascript stack and all the wonderful translation, compilations, VM layers.
The only few programmers who can really do that is probably the few folks who wrote GWT.
Have been programming C, Linux Kernel Driver, Embeded, VB, Tcl, Python, Android/Java, JS, SQL, for past 20+ years, one thing I still love is KISS - Keep It Simple Stupid.
I think that was one of the big drivers of source maps in the first place (along with dart and coffescript). They now have a pretty good implementations, but it's still not complete.
The traditional way of debugging GWT is in eclipse as java emulating javascript emulating java. This actually worked surprisingly well most of the time, but sometimes you did have to step through the compiled code in the browser. Luckily there was a "pretty" compile option.
Lua has by far the smallest, most portable, easy-to-integrate runtime of any embeddable language I am aware of. JavaScript has good implementations (V8, etc) but they are orders of magnitude larger, more complex, and imposing if you're linking them into your binary.
If this is truly a robust JS implementation, this means that there is now a tiny, easy-to-embed implementation of the programming language that powers the web. This could enable JavaScript to start making inroads in the "embedded language" space, and really become the language of both client and server.
If it can compile to LuaJIT bytecode also, it could also possibly be competitive in speed with other JS implementations, though some of that would depend on how efficient the resulting bytecode can be.
I think this would actually be a cool trend. Having a code-base that can run either in the browser or "natively" is a powerful approach. Though Lua is a cleaner language, JavaScript is a totally decent language if you use it right -- much better than a lot of people give it credit for. Hint: if you think JS sucks because of browser incompatibilities, what you really hate is bad implementations of the language, not the language itself.
Of course another approach to achieve "one language" would be to have a Lua->JS compiler (or Lua->asm.js, or a Lua interpreter in asm.js). But Lua the language is a bit more of a moving target; to preserve cleanliness and orthogonality they sometimes break the language in non-backward-compatible ways.