Earlier quoted context omitted.
It has all the power of something like Python, but is much faster and with far less cruft and basically no confusing elements. You’re given a small set of tools and it’s incredibly easy to build off them.
> basically no confusing elements. 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.
Fengari – Lua for the Browser
71–80 of 145 posts
Re: Fengari – Lua for the Browser
#72Earlier quoted context omitted.
It has all the power of something like Python, but is much faster and with far less cruft and basically no confusing elements. You’re given a small set of tools and it’s incredibly easy to build off them.
Lua definitely does not have the power of something like Python. That'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 th…
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.
Re: Fengari – Lua for the Browser
#73Earlier quoted context omitted.
It has all the power of something like Python, but is much faster and with far less cruft and basically no confusing elements. You’re given a small set of tools and it’s incredibly easy to build off them.
> basically no confusing elements. 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.
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).
Re: Fengari – Lua for the Browser
#74Earlier quoted context omitted.
Lua definitely does not have the power of something like Python. That'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 th…
> If one likes Python, then the chance of liking Lua are low. 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.
Re: Fengari – Lua for the Browser
#75Earlier quoted context omitted.
Not sure why'd you think this would have anything to do with WASM, the homepage is really clear what this is: > Fengari is the Lua VM written in JavaScript. It uses JavaScript's garbage collector so that interoperability with the DOM is non-leaky. WASM wouldn't use JS's GC, nor would provide interop with the DOM, so for the stated goals of this project, WASM would be a non-starter. There is prior art for Lua -> WASM…
I have no problem interoperating with the DOM in WASM. Granted, reusing a GC is a good reason to use JavaScript.
What? How? Was a year or two ago I dived into WASM last time, but at that point there was no direct DOM access, and all the talk around it was pointing to it maybe existing far into the future, not anytime soon.
How are you accessing the DOM from WASM without using any of the JS host? You're not talking about just sending messages from WASM to JS and "manipulating" the DOM that way are you?
Re: Fengari – Lua for the Browser
#76Earlier quoted context omitted.
> People who are confused about equality shouldn't design programming languages: 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,…
I’ve used JavaScript for about 25 years, sometimes more seriously, and always hated it. I’ve always found it unpredictable, I don’t like the turtles-all-the-way-down thing going on with its objects. I’d like to leverage my experience with regular class definitions and instantiation from Java workalikes. I’m sure many people love JS’s take on OO but I find it annoying. A perfect example: I read hey there’s a cool simp…
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.
Re: Fengari – Lua for the Browser
#77Earlier quoted context omitted.
> People who are confused about equality shouldn't design programming languages: 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,…
Decades later you may believe that "everybody" uses "===", but actually "==" is still there, and many people still use that regardless of what you choose to believe, simply because it's there and 33% shorter and looks like C and Stackoverflow is full of examples of it, and it STILL commonly causes many subtle hard-to-find bugs. People like Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar Celes, James…
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.
Re: Fengari – Lua for the Browser
#78Earlier quoted context omitted.
Not sure why'd you think this would have anything to do with WASM, the homepage is really clear what this is: > Fengari is the Lua VM written in JavaScript. It uses JavaScript's garbage collector so that interoperability with the DOM is non-leaky. WASM wouldn't use JS's GC, nor would provide interop with the DOM, so for the stated goals of this project, WASM would be a non-starter. There is prior art for Lua -> WASM…
I have no problem interoperating with the DOM in WASM. Granted, reusing a GC is a good reason to use JavaScript.
WebAssembly GC phase 2 standardized: https://twitter.com/tlively52/status/1493681050693738501
Dart already has a prototype: https://github.com/dart-lang/sdk/commit/6faa5f3bd00ad8cbc640...
Re: Fengari – Lua for the Browser
#79Earlier quoted context omitted.
> People who are confused about equality shouldn't design programming languages: 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,…
I’ve used JavaScript for about 25 years, sometimes more seriously, and always hated it. I’ve always found it unpredictable, I don’t like the turtles-all-the-way-down thing going on with its objects. I’d like to leverage my experience with regular class definitions and instantiation from Java workalikes. I’m sure many people love JS’s take on OO but I find it annoying. A perfect example: I read hey there’s a cool simp…
Re: Fengari – Lua for the Browser
#80Earlier quoted context omitted.
> basically no confusing elements. 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.
iirc, one other confusing element is that tables (hash tables? I don't remember what they're called) return null when a lookup is done for a nonexistent key. 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 th…
It’s pretty unfortunate. You can mitigate it using meta tables though.