Hacker News Reader

Comment by Derbasti | Hacker News Reader

But why not use Lua itself then? It is a very elegant, beautifully consistent language. In a way, it is JavaScript Done Right.

View on HN

To repeat my own comment from a few week back ( 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/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.

>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.

there are more rockstar web developers influencing VCs than any other kind.

ftfy.

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.

Well how could you possibly know for a platform that you have no experience with?

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.

There are a fair number of Lua in browser projects with a variety of techniques. Often game porting uses them.

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.

ORM is a terrible idea anyway. Just don't use it.

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).

Sorry to nit pick, but (for example) variables being global by default it's not exactly an epitome of elegance.

It'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

Whatever javascript does, it does not make Lua's default global variables look any better

To be fair, using 'local' instead of 'var' does make the situation a lot clearer.

"JavaScript Done Right" requires actually doing it right.

'Use strict';

This is actually what we do in Lua, often written `require "pl.strict"`...

If you are arguing in favor of "local by default", there are strong arguments against this: http://lua-users.org/wiki/LocalByDefault

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 tend to agree with you, but here is the reasoning behind how Lua works:

- local by default weakens what you can do with the scope;

- we want something by default because the language is used for things like configuration files.

The 2nd point means this must be valid:

    param_1 = "foo"
    param_2 = "bar"

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.

What we do instead is use two kinds of tools: static global detectors and strictures (like in Perl). Similar tools are integrated in IDEs as well.

With these tools, I have never had an issue with scoping in code I have written. But it takes a little time to get used to it.

> 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?"

These arguments don't look particularly strong.

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.

One reason might be the npm package manager which comes with Node.JS

Reply on news.ycombinator.com