Earlier quoted context omitted.
In fact zero-based has shown some undeniable advantages over one-based. I couldn't explain it better than Dijkstra's famous essay: http://www.cs.utexas.edu/~EWD/ewd08xx/EWD831.PDF
It's fine, I can see the advantages. I just think it's a weird level of blindness to act like 1 indexing is some sort of aberration. It's really not. It's actually quite friendly for new or casual programmers, for one.
Fabrice Bellard Releases MicroQuickJS
381–390 of 594 posts
Re: Fabrice Bellard Releases MicroQuickJS
#382Earlier quoted context omitted.
This indeed is not Algol (or rather C) heritage, but Fortran heritage, not memory offsets but indices in mathematical formulae. This is why R and Julia also have 1-based indexing.
Pascal. Modula-2. BASIC. Hell, Logo. Lately, yes, Julia and R. Lots of systems I grew up with were 1-indexed and there's nothing wrong with it. In the context of history, C is the anomaly. I learned the Wirth languages first (and then later did a lot of programming in MOO, a prototype OO 1-indexed scripting language). Because of that early experience I still slip up and make off by 1 errors occasionally w/ 0 indexed…
Re: Fabrice Bellard Releases MicroQuickJS
#383Fabrice Bellard is widely considered one of the most productive and versatile programmers alive: - FFmpeg: https://bellard.org - QEMU: https://bellard.org/qemu/ - JSLinux: https://bellard.org/jslinux/ - TCC: https://bellard.org/tcc/ - QuickJS: https://bellard.org/quickjs/ Legendary.
For all the praise he gets here, few seem interested in his methods: writing complete programs, based on robust computer science, with minimal dependencies and tooling.
Can you elaborate a little about the methods you mention and how you analysed them?
Re: Fabrice Bellard Releases MicroQuickJS
#384Earlier quoted context omitted.
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…
>Lua is the only lightweight language that I am aware of with TCO. Scheme is pretty lightweight.
Re: Fabrice Bellard Releases MicroQuickJS
#385Earlier quoted context omitted.
This indeed is not Algol (or rather C) heritage, but Fortran heritage, not memory offsets but indices in mathematical formulae. This is why R and Julia also have 1-based indexing.
Pascal. Modula-2. BASIC. Hell, Logo. Lately, yes, Julia and R. Lots of systems I grew up with were 1-indexed and there's nothing wrong with it. In the context of history, C is the anomaly. I learned the Wirth languages first (and then later did a lot of programming in MOO, a prototype OO 1-indexed scripting language). Because of that early experience I still slip up and make off by 1 errors occasionally w/ 0 indexed…
The problem is that Lua is effectively an embedded language for C.
If Lua never interacted with C, 1-based indexing would merely be a weird quirk. Because you are constantly shifting across the C/Lua barrier, 1-based indices becomes a disaster.
Re: Fabrice Bellard Releases MicroQuickJS
#386Earlier quoted context omitted.
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…
> More importantly, Lua has a crucial feature that Javascript lacks: tail call optimization. There are programs that I can easily write in Lua, in spite of its syntactic verbosity, that I cannot write in Javascript because of this limitation. Perhaps this particular JS implementation has tco, but I doubt it reading the release notes. > [...] In my programs, I have banned the use of loops. This is a liberation that is…
I don't know why Lua implemented TCO, but if I had to guess, it's not because it enables you to replace loops with recursion, it's because it... optimizes tail calls. It causes tail calls to use less memory, and this is particularly effective in Lua's implementation because it reuses the stack memory that was just used by the parent call, meaning it uses memory which is already in the processor's cache.
The thing is, a loop is still going to be slightly faster than TCOed recursion, because you don't need to move the arguments to the tail call function into the previous stack frame. In a loop your counters and whatnot are just always using the same memory location, no copying needed.
Where TCO really shines is in all the tail calls that aren't replacements for loops: an optimized tail call is faster than a non-optimized tail call. And in real world applications, a lot of your calls are tail calls!
I don't necessarily love the feature, for the reasons that I detailed in the previous post. But it's not a terrible problem, and I think it at makes sense as an optimization within the context of Lua's design goals of being lightweight and fast.
Re: Fabrice Bellard Releases MicroQuickJS
#387If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the language ones... (small, fast, ANSI-C). I appreciate certain ideas in Lua, and people love it, but I was never able to like Lua, because it departs from a more Algol-like syntax and semantics without good reasons, for my taste. This creates friction for newcom…
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…
This. And not just Lua , but having different kind of syntax for scripting languages or very high level languages signal it is something entirely different, and not C as in system programming language.
The syntax is also easier for people who dont intend to make programming as their profession, but simply want something done. It used to be the case in the old days people would design simple PL for new beginners, ActionScript / Flash era and even Hypercard before that. Unfortunately the industry is no longer interested in it, and if anything intend to make every as complicated as possible.
Re: Fabrice Bellard Releases MicroQuickJS
#388I wonder if this could become the most lightweight way for yt-dlp to solve YouTube Javascript challenges. https://github.com/yt-dlp/yt-dlp/wiki/EJS (Note that Bellard's QuickJS is already a supported option.)
That's a great idea, but if they did, then YouTube could retaliate by specifically using features that MicroQuickJS does not support.
Re: Fabrice Bellard Releases MicroQuickJS
#389 a = []
a[0] = 1; // OK to extend the array length
a[10] = 2; // TypeError
If you need an array like object with holes, use a normal object insteadGuess I'm a bit fuzzy on this, I wouldn't use numeric keys to populate a "sparse array", but why would it be a problem to just treat it as an iterable with missing values undefined? Something to do with how memory is being reserved in C...? If someone jumps from defining arr[0] to arr[3] why not just reserve 1 and 2 and inform that there's a memory penalty (ie that you don't get the benefit of sparseness)?
Re: Fabrice Bellard Releases MicroQuickJS
#390Earlier quoted context omitted.
> Lua has a crucial feature that Javascript lacks: tail call optimization. I'm not familiar with Lua, but I expect tco to be a feature of the compiler, not of the language. Am I wrong?
I don't think you're wrong per se. This is a "correct" way of thinking of the situation, but it's not the only correct way and it's arguably not the most useful. A more useful way to understand the situation is that a language's major implementations are more important than the language itself. If the spec of the language says something, but nobody implements it, you can't write code against the spec. And on the flip…
You could not reliably depend on that implementation detail until much later, when optimizations were implemented in CPython that just so happened to preserve dictionary key insertion order. Once that was realized, it was PEP'd and made part of the spec.