Hacker News Reader

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

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.

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.

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

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

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

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.

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

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.

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?

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 would assume (hope is maybe a better word) they have some kind of decent source mapping for debugging.

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.

I'm curious if there's any advantage to this over the Espruino which actually runs JavaScript.