Lua is the only language I can truly say I love. If more people used it (and used it responsibly, not letting it become a mess of odd libraries), the world would be a better place.
Why? I've worked with Lua before and to me it's not a bad language, but nothing special either. I'm honestly wondering.
I think Lua is a bit unique in this for two reasons. First, they have in intentional open-source but not open development model. Second, because of the way that Lua is embedded inside other projects, there is more willingness to implement backwards-incompatable changes. I'm sure this is a negative for some who want to build a larger, less fractured community, but it has advantages for language cohesiveness.
You’re given a small set of tools and it’s incredibly easy to build off them.
the one confusing element - one-based indexing of arrays! that is something i found hard to adjust, as it makes off-by-one errors more prominent...
but otherwise it's a nice language.
But that said, I'd prefer that Lua had 0-based indexes, simply because that's what most other languages have, not because it's superior.
unless you can exclusively program in 1 language only, these confusions would be the cause of various bugs, or at least, increase the cognitive load. Programming is already hard enough, without artificially increasing the cognitive load!
Agreed that interaction with C or other 0-based languages or systems (eg screen coords) makes things more difficult.
This is not necessarily a bad choice. Exceptions and such can be a real pain. However, accidentally getting a null value because you didn't check and then have it propagate much further in your program is extremely difficult to debug. Instead of blowing up at the site of the bad lookup, you only see the distant effects of it (e.g. put the null value into another table, which gets put in another table, and then is attempted to be called as a function, etc).
It’s pretty unfortunate. You can mitigate it using meta tables though.
> t = {}
> t['a'] = nil
> t['a']
nil
> t['b']
nilThat's usually what people like about Lua: it's barebone, yet high level and clean.
If one likes Python, then the chance of liking Lua are low.
E.G:
Both python and lua can open something (a file, a socket, a transaction...) in one line.
But only Python has the `with` construct that means it's easy to guaranty you close it in case of an error.
Lua is then easier to learn: one less concept to master. But the high level tool of Python, that you had to learn, make your life easier.
They have very different trade off.
I don't know. I quite like both as well. The design ethos feels similar although Python has certainly added more features over the years.
Python was always chock-full of advanced features, people just usually don't notice because they get productive in 3 days with the basic features and don't need to go further. It's has the quality of a very smooth learning curve, but a very long one if you care.
Unkike the __gc hook which provides no guarantee as to when it will be called, if ever, the __close hook is called when a value goes out of scope.
Probably someone else can shed light on exact numbers, but Lua is faster than Python.
Folks who sniff at putting a scripted/interpreted language into an embedded environment really need to think twice with Lua. It is fast, tight and highly performant - and if you bundle it along with LuaJIT and Turbo.lua, it'll give you the best of all worlds - aynsc i/o, coroutines, very, very fast performance and a great execution environment upon which to build truly useful apps.
If all the time and effort and treasure that was wasted cobbling together JavaScript from scratch with all its naive unforced design flaws and security holes and interoperability issues -- and then everyone else pissing away so much effort working around and fixing subtle bugs in JavaScript code due to those terrible design flaws (cough cough "this" cough cough "equality") -- had been put into Lua instead, which was cleanly designed from the start by incredibly smart people who actually had a clue about what they were doing, the world would be a much better place.
People who are that confused about equality shouldn't design programming languages:
https://dorey.github.io/JavaScript-Equality-Table/
"All animals are equal, but some animals are more equal than others." -George Orwell, Animal Farm
https://news.ycombinator.com/item?id=29379272
>For Netscape in 1995, I believe Python would have been a better choice than JavaScript, but Lua would have been an even better choice, given how much smaller, simpler, and more efficient Lua is, and the eventual excellence of LuaJIT. (If only Lua indexed its array from 0 instead of 1...) But Python and Lua didn't "look like Java" enough for Netscape.
https://news.ycombinator.com/item?id=17061967
[...]
>But if not PostScript, Python, or Lua, then at least Netscape didn't use TCL in the browser. Around 1994, long after NeWS and right before Java, Sun announced they were going to make TCL the official scripting language of the world wide web, which triggered RMS into kicking off the Great TCL War:
>RMS's "Why you should not use Tcl" flame:
https://news.ycombinator.com/item?id=17061858
>And with that diplomatically worded message, RMS kicked of The Infamous TCL War. That was Stallman's response to Sun bombastically pushing TCL as the official scripting language of the web, BEFORE Live Oak / Java was a widely known (or evangelized) thing.
>At the point anybody started talking about a Java/TCL bridge, it was already all over for TCL becoming the "ubiquitous scripting language of the Internet".
>Sun's unilateral anointment of TCL as the official Internet scripting language trigged RMS's "Why you should not use Tcl" message, which triggered the TCL War, which triggered Sun to switch to Java.
>After the TCL war finally subsided, Sun quietly pushed TCL aside and loudly evangelize Java instead. The TCL community was quite flustered and disappointed after first winning the title "ubiquitous scripting language of the Internet" and then having the title yanked away and given to Java.
>Any talk of bridges were just table scraps for TCL, the redheaded bastard stepchild sitting outside on the back porch in the rain, smoking a cigarette and commiserating with NeWS and Self.
>Tom Lord's description of what happened is insightful and accurate:
https://web.archive.org/web/20110102015130/http://basiscraft...
This is a very dull criticism of JavaScript, everybody uses ===. While it's definitely true the language has some poor decisions (`with`, `==`, etc.). You can write JS without using any of these features (and almost everyone does).
Infact, just using a decently strict ESLint config will get you most of the way there.
It's controversial, but I think somewhere under the cruft of JS is a good language. The syntax is dead simple, functions are first class, and with something like TS you can get static typing ontop of all of that.
It really annoys me that people confuse ease of use due to familiarity with simplicity.
Many programmers will be familiar with the typical curly-braced C-style syntax many mainstream programming languages have and so find JS syntax easy to get into but that has nothing to do with simplicity.
Building a parser for JS is not exactly simple nor is teaching new programmers the syntax. Lua is vastly superior in both aspects. People just tend to forget the pain most new programmers have to go through learning a curly braced languages, having to figure what all these weird symbols and different kinds of braces and how to type them.
JS is arguable even worse than other curly braced languages because of weird exceptions like automatically adding semicolons to line endings or these fancy arrow functions. Honestly JS is one of very few languages were I actually need to look up syntax after having not used it for a while.
I do agree that Lua is simpler, but I don't think this is an area where JS is that bad.
A perfect example: I read hey there’s a cool simpler way to write small anonymous functions called arrow syntax. Nice let me try it, hm it’s not working —> google —> arrow functions have no access to ‘this’.
That's a bit like complaining about a language without types not having interfaces. I mean, sure, but it's also clearly not what that language is trying to do. Prototype-based programming is object-oriented programming without defining classes, that's basically the thing that sets it apart. If you're trying to do classical OOP with prototypes, you're not really embracing the paradigm of the language you're using.
> A perfect example: I read hey there’s a cool simpler way to write small anonymous functions called arrow syntax. Nice let me try it, hm it’s not working —> google —> arrow functions have no access to ‘this’.
Not sure what this has to do with OOP vs prototypes, or even Objects. But yeah, new language features sometimes modifies behavior like in this case with arrow functions (which are not just a different syntax to write anonymous functions). You're also wrong that they don't have access to `this`. They do, but arrow functions don't define a new lexical scope so `this` is referring to the closest part that did define the bindings for `this`, `super`, `arguments` et al.
Totally agree. I wouldn't make the mistake I see often of saying "for this reason JavaScript is objectively bad" -- but it's bad for me.
> you're not really embracing the paradigm of the language you're using
That's true, and related to the problem. I don't want to learn another paradigm, I want to get my work done. JavaScript's paradigm isn't intuitive to me, and at this point I assume will never click since I've been using it fairly consistently for 25 years and it still makes me uncomfortable.
> Not sure what this has to do with OOP vs prototypes, or even Objects
It doesn't. It's an example where JS often doesn't behave the way I expect it to. Some examples of this unpredictability have been fixed with newer versions over the last 25 years but this just illustrates the problem I often have where I make what I feel are reasonable assumptions about how its scoping or execution model works and have to trial-and-error my way into getting it to work right. This is after countless time spent reading JS books and posts over the years.
I accept that this may just be a personal issue, but I also don't think I'm the only one.
If you try to use a new language feature without reading the documentation first, you will probably run into difficulties. This is not a unique problem to JS.
People like Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar Celes, James Gosling, Guido van Rossum, and Anders Hejlsberg are enlightened, experienced programming language designers who actually know what they're doing, and they don't make stupid amateur-hour mistakes like JavaScript was cursed and riddled with from day one, that make it difficult for compilers to optimize code, and which we're still using tooling and linters and IDEs and compilers to work around, because they're still in the language and will never go away.
"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
But you also missed the reference to how deeply and tragically confused the bigoted designer of JavaScript is about equality when it comes to human beings, not just programming languages. And the terrible damage his confusion about equality and his promotion of inequality did to Mozilla and his co-workers and his own reputation and legacy.
I love what JavaScript finally evolved into after decades of intense development and revision and optimization, which took the precious time and effort of uncountable extremely talented people, but all that effort that was pissed away working around JavaScript's original stupid unforced flaws could have been applied in so many much more productive and useful ways, instead of wasted the way it was, and the world would be a much better place if a language like Lua that wasn't so naively and incoherently designed in the first place was used instead of JavaScript.
Zero relevance to programming language design, makes your argument look very weak and emotionally-motivated. If you have to sink to bringing up the personal views of the language designer you're criticizing on an entirely unrelated matter to make a point, you don't really have a point.
>his own reputation and legacy
His legacy is quite fine, I love Brave browser and use it everyday and so are countless individuals. Not all of us are so fragile to the point of not using good software because its author just so happens to disagree on a completely irrelevant social issue.
As for Javascript, it's a terrible mistake but I would love seeing the ones you will make when you're forced to design and implement a language in 10 days.
My reasons for not using brave have nothing to do with the author, and everything to do with not wanting to participate in cryptocurrency bullshit.
I couldn’t find this reference in your little essays here. Where is it?
If Netscape had even heard of an obscure two-year-old scripting language from Brazil, and chosen to use it, we wouldn't have gotten the Lua we know and love in the bargain. 1995 Lua wasn't the obviously superior Javascript alternative that it's been since the early 200s.
Easily one of the most productive tools in my suite, and I made a lot of money as a Lua developer last year, using Lua in a realtime analysis application.
Would love to see a Lua-only browser arise from these efforts. Its just such a delightful language to code in ..