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.
