7 ms·
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 runti
by haberman 13y ago
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.
- Derbasti 13y agoBut why not use Lua itself then? It is a very elegant, beautifully consistent language. In a way, it is JavaScript Done Right.
- haberman 13y agoI 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.
- justincormack 13y agoThere are a fair number of Lua in browser projects with a variety of techniques. Often game porting uses them.
- catwell 13y agoLua 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.
- Jhsto 13y agoOne reason might be the npm package manager which comes with Node.JS
- catch23 13y agohaving 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.
- TheZenPsycho 13y agoThe 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.
- catch23 13y agoRight, 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.
- TheZenPsycho 13y agoORM is a terrible idea anyway. Just don't use it.
- catwell 13y agoThe 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 http://www.lua.org/wshop13.html).
- morkbot 13y agoSorry to nit pick, but (for example) variables being global by default it's not exactly an epitome of elegance.
- panic 13y agoIt's the same in JavaScript: x = 5; // global var x = 5; // local Lua just replaces var with local: x = 5 -- global local x = 5 -- local
- riquito 13y agoWhatever javascript does, it does not make Lua's default global variables look any better
- nilkn 13y agoTo be fair, using 'local' instead of 'var' does make the situation a lot clearer.
- icambron 13y ago"JavaScript Done Right" requires actually doing it right.
- woah 13y ago'Use strict';
- catwell 13y agoThis is actually what we do in Lua, often written `require "pl.strict"`...
- haberman 13y agoIf you are arguing in favor of "local by default", there are strong arguments against this: http://lua-users.org/wiki/LocalByDefault http://lua-users.org/wiki/LocalByDefault
- seldo 13y agoTo repeat my own comment from a few week back ( https://news.ycombinator.com/x?fnid=rYqgO4wMtljd4zBdfWM3wt https://news.ycombinator.com/x?fnid=rYqgO4wMtljd4zBdfWM3wt ): because enormous numbers of programmers already know JavaScript, and familiarity trumps + libraries being available trumps every other consideration when choosing a programming language, according to actual research ( http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/papers/adoptquant.pdf http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/pap... ). 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.
- jotux 13y ago>There are more web developers than there are any other kind of programmer Is there any data to back this up? I would think Java or VB or C++ programmers far outnumber web developers.
- gcb1 13y agothere are more rockstar web developers influencing VCs than any other kind. ftfy.
- taude 13y agoIs 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?
- ubernostrum 13y agoIs 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?
- Someone 13y agoThe big questions, of course, are - is it full Javascript? If not, what is missing? - how fast does that Javascript run? 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-equality-operators-and-comparisons/ 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 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"."
- erikpukinskis 13y agoEven if the answers are "everything but the basics" and "very, very slowly" it is still a pretty cool thing. I want a computer that can open and close my chicken coop door on a schedule. We're not talking rocket science for this to be pretty valuable.
- skrebbel 13y ago> 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.
- m0th87 13y agoMost 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.
- skrebbel 13y agoOh, 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.
- haberman 13y agoDo 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.
- tonyplee 13y agoKind 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.
- tudborg 13y agoI would assume (hope is maybe a better word) they have some kind of decent source mapping for debugging.
- bradleyjg 13y agoI 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.
- jwarkentin 13y agoI'm curious if there's any advantage to this over the Espruino which actually runs JavaScript.