A small but complete JavaScript engine
bellard.org
bellard.org
Some people are just born to be able to work all day all week, if you are one of those people please don't throw it away (I am not one of them). I think I have the knowledge to do most of his projects e.g. I have the mathematics, and RF engineering to do (say) the LTE stuff but there is absolutely no way in hell I could ever sit down and write it (I've done my own RF projects but I burn out so quickly).
Problem is that management pays so much better than a contributor of code. Society has collectively decided that management is worth more economically, than individual contributors.
Good managers increase the output of their team, bad ones try to make themselves look the best.
If you make a PR and it gets left to die after a few days, who cares? If someone keeps an eye on it and tells you what they're looking for with a smile, you're going to try and get it done.
You seem to be assuming that there is an equivalence between good programmers and good managers?
I wish I lived in this alternative reality you describe. My career has been littered where non technical managers--essentially clerks--get paid more than I do to sit around with a others and talk about what should be done while I (and colleagues) do all the doing. I end up doing a LOT of "managing" from behind the lines in all these cases.
Frankly, the reality distortion field where "a good manager has increased the output of their team" has been such a small observed sample, that I wouldn't be able to claim there was even a correlation between the two, much less causality; I'd just chalk it up to something like "the water" or "the lighting" if I saw it happening with any regularity.
(QuickJS seems tres cool; hat tip to the author)
That's a nice economics just-so story. But do people think that the median manager is effective? I'd say less than half of my managers have been effective. Some of them even got promoted.
And I would argue the difference between a mediocre manager and a good manager is more than that.
I firmly believe that 10 geniuses will go nowhere without direction 8 times out of 10. And non geniuses it will be 9.99/10. Managers were the people that turned human potential into outcomes.
But yeah you're right a bad one will turn a team comatose.
> leadership is nature's way of removing morons from the productive flow
There's still a cap, of course; you can't remain an IC and have the level equivalent of a VP or C-level. The theory there is that the higher you climb the IC ladder, the more difficult it is to have increasing levels of impact without leading groups of people larger than just yourself. (And indeed, our higher-level IC positions often involve some amount of non-management leadership outside of heads-down coding all day.)
I'm not 100% sure I agree with the reasoning behind the IC ceiling, but things can be awesome for you outside of management, with plenty of career and salary growth opportunities, if you find a company that understands and values individual contribution. I wouldn't say this is a lot of companies, likely not even a majority, but it's a number that seems to be growing, at least in technical fields.
However, for extremely large organizations, despite my personal desires to see an equivalent to a VP/exec level for an IC, I just don’t see anyone being interested in that.
The rationale I’ll probably hear for why it will never happen is something like “execs are responsible for so many staff’s eventual success or failure, that there is no way an IC can compare to that level of impact”.
If I don my tinfoil hat though, the conspiracy theorist in me thinks that these sorts of changes to an IC’s career path are ultimately made possible by execs themselves, and that they would not be able to compete with someone of equal stature who has spent 99% of their time thinking about hard engineering problems. A certain fear of appearing mediocre or protecting your rank perhaps.
I’d also say that my assumptions above are probably meaningless in a startup or company less than 100; I’ve seen plenty of postings looking for a magical “co-founder/CTO/principle engineer” hybrid. Which I take to mean a really good engineer who is also responsible for some part of executive leadership. It’s not an exact comparison /shrug.
Young ones take SO much time. I don’t regret kids at all but I regret not doing even more with my time previously!
I would have thought it was an asshole comment for implying that having kids makes you less productive. But having kids DOES make you less productive (at least when they are young) or at the very least removes great swaths of time that you would have had available otherwise, if you involve yourself with their lives at all.
Having kids or not is intensely personal and everyone has to make that decision themselves, not having them is extremely valid
https://web.archive.org/web/20110726063943/http://www.freear...
No mention of his secret sauce other than, well, things bore him and he moves on.
I wish they had talked a little about his work on the Amiga. He wrote a full color MacOS emluator that actually multi-tasked with the AmigaOS rather than taking over the whole machine. It actually ran Mac programs faster than the fastest Mac hardware of the day as well. Really impressive work on such low end hardware.
As the parent of a 3 year old, I know that it’s at least older than 3 XD
Sure, let's say 20% of it is genetics, 80% of it is still putting in the work.
Whereas with intellectual work it's often hard to assess the gap, not least because the further you are from closing it, the less understanding you'll tend to have of how hard the remaining parts are.
I would suggest that most people reading this are capable of Bellard level productivity, if their life depended on it.
And in Emacs mode.
Also wanna throw Mike Pall & Arthur Whitney in there as an honourable mentions (productive gods/100x)
I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules?
In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components. One good example of this is node's http-parser[1] that was extracted to a self-contained C file with associated headers and is a pleasure to use.
I kinda like large files (vs splitting the code), because they are easier to navigate in vim. I have no idea about why the choice was made for QuickJS, aside from ease of inclusion into other projects, mentioned in the docs.
It could be that his workflow is to always navigate by searching function names. Then it doesn't really matter if the project is 1 file or 1000.
Fun to run into you, Geo!
But I stand by what I said now and nearly a decade ago, and now try to be blunt: Fabrice Bellard didn’t organise quickjs this way because he isn’t as smart as you. He did it because it makes things easier for him to write quickjs and qemu and tcc and ffmpeg and all sorts of other stuff used by all sorts of other people. And if you ever figure out how to learn from watching people who can do things you cannot, I think you could be an amazing programmer.
All the best.
No. This is exactly my point.
You can do it too, you just might need to organize your code this way to do it.
On the other hand, I hate finding a project that looks useful, but then the code is scattered across many files which are barely one screen long, or worse, also spread throughout different deeply nested directories. Regardless of whether the organisation makes sense, navigating directory trees is annoying.
Why is this a good thing? The same amount of code and same number of results need to be scanned either way. With many files, you at least have the file name to give you some small amount of context without needing to read the code.
Seeing as Bellard is very prolific and has done more than you me and three others in a lifetime, there must be some merit to his approach.
My best guess is that this is more of a fun project than anything and spending too much time on such concerns would detract from the fun. I do the same with my side projects.
if the LOC is similar in size, i don't see why having them in different files vs same file makes any difference at all.
Also, your IDE should be able to navigate you to definitions and usages etc. If it doesn't, it's not a good IDE. So the problem of understanding code reduces understanding the abstract structure, not how that structure is represented on file.
And slippery slope...
1. Click class name (or any other top level identifier).
2. Click light bulb.
3. Click move to a new fie.
I know of automatic renaming, moving parts you select automatically to another file, but full automatic refactoring to multiple modules is something I haven’t seen.
How does this tackle circular dependencies etc. I guess the IDE must parse the code, generate the syntax tree, populate symbol tables etc. and then make the refactoring.
A side point I sometimes dream of writing an emacs module which would let me to write in a single file (for easy search and edit reasons), and then cut it into several modules where I mark them with =======xyz.h========= etc.
I also want to use this in each repo where it automatically does this. I’ll hopefuly stop procrastinating and write the thing one day :).
To end with a Game of Thrones analogy, hearing about the latest developments I sometimes feel like we editor/linux/bsd/cli users are like Wildlings beyond the wall. We live in harsher conditions, but are amazed when we see large cathedrals, castles being built inside the wall. Our life is more free but also burdensome.
Try using Visual Studio or Jetbrains IDEs and you'll see the difference.
I don't use an IDE. In fact, I'd say it's a problem if code requires an IDE in order to work on it effectively (Enterprise Java is the most prominent example of this.) I'm nowhere near Bellard level, but would consider myself above average, and have observed that some of the most productive programmers don't either --- and their code is far easier to understand than e.g. the mostly-autogenerated, split-into-many-tiny-files projects created by those far less skilled.
Or, to bring it back within realistically achievable levels of talent, that Bob Ross's trees would've been happier if he used one.
So your comparison is wrong in this aspect, as the correct comparison would be "Painters who do not use modern tools made specifically to make painting easier are probably better painters. Michelangelo was the greatest master and he did not use modern tools, after all". Would you agree with that??
Maybe I am steelmanning too much but it could have simply meant to indicate the existence of a trend that move people toward IDEs and another trend that moves people away from IDEs
... one third of which is the copyright notice and license, and another third is boilerplate.
This reduces the cognitive load and gives the compiler a way to enforce separation.
In short - files in C can give you namespaces -- which are sometimes a useful way to organize code.
In newer languages like C# you can do the same. Probably works in lots of other languages too, see Rosetta Code: Nested Function:
https://rosettacode.org/wiki/Nested_functionPersonally I tend to want to split up code written by others so I can focus on the parts that go together without having to read through irrelevant parts, but I can easily navigate larger files/classes I've authored myself. I mainly split it up for the sake of future readers.
We can only hope Fabrice Bellard reads it all so he can learn himself some coding.
Is QuickJS a viable way to write command-line apps in JavaScript? In particular, does it have enough of a standard library to work with, or would it be a struggle because (I assume) it can’t use packages from NPM?
I know there’s the alternative of bundling Node.js and V8 into an executable, but the resulting binaries are large - it feels like the command-line equivalent of using Electron.
https://bellard.org/quickjs/quickjs.html#std-module
It would be enough for a good number of CLI tools, I'd think. But one big issue is going to be that every library on NPM is hardcoded to use Node's modules (e.g. fs) so you're not going to be able to use any external modules at all.
Here's one example: https://www.npmjs.com/package/squat
So yes, there are plenty of pure JS modules. But if you want to read a file from a disk you’re going to end up with a library that assumes you’re using Node.
https://github.com/DigitalMars/DMDScript/tree/master/engine/...
23,906 lines of code.
Unfortunately because it lacks stuff like JIT it'll never rival the likes of V8 in performance. But in terms of bang for buck it's unbeatable.
Luajit packs a similar punch, and actually has performance comparable with v8.
Plenty of things with performance and size similar to quickjs, though; regular lua, micropython, chibi scheme, s7 scheme...lots of great options.
https://www.youtube.com/watch?v=aC_QLLilwso
The basic points: They watch functions for "hotness" (how often they are ran). Then, any function that is super hot, they'll see if it's being ran consistently (ie always receives two numbers as its arguments). Then they'll make a streamlined interpretation of the js code which only checks the arguments and then skips pretty much all the other checks. By doing this, it makes JS significantly faster.
If you're trying to compare and contrast v8 to quickjs, this is the first thing that comes to mind for me as to what they may be doing differently.
Small and easily embeddable: just a few C files, no external dependency
Whereas v8's project description opens with:
V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. It is used in Chrome [...]
The stuff in the video is definitely super interesting but much of it is about how design goals in v8 are met.
You should really think about why javascript is the de facto standard for web scripting. Other alternatives have appeared but even the likes of Google, which control the entire web stack and can pretty much dictate what the world uses, decided against it.
Technically the answer should be "yes", but given the event-driven nature of javascript and a shell script's very specialized design goals (launch processes, control the runtime environment, provide a workable REPL, etc) then it wouldn't be an improvement over any of the current shell scripting languages.
As a general-purpose scripting language... That's an entirely different matter, and the answer is definitely yes. In fact, node.js and deno already do just that.
Turtles all the way down!
Thanks for the link, I'll be sure to bookmark it this time...
- Support ISO-8859-1 encoding (true ISO-8859-1 encoding, not Windows-1252) in addition to UTF-8, for all of the functions that can read text from files and write text to files, to avoid having to implement it by yourself one byte at a time. This is useful when you want text which is mostly ASCII, but which may contain extended characters that aren't Unicode. (There is no need to support any other character sets or encodings, though.)
- Document the C API better. Currently, the documentation isn't very good.
- Implement WTF-8 (if it isn't already), so that arbitrary JavaScript strings (which are strings of 16-bit characters) can be represented as UTF-8 without losing data. Often the text will be ASCII anyways, and you will want to use ordinary C strings,
- Add a API function to read/write strings of 16-bit characters. (This is probably unnecessary for property names, although it is helpful for strings.)
- Add an option to disable use of Unicode tables, in case your program does not use them. (UTF-8, String.prototype.codePointAt, etc would still work regardless, since they don't need Unicode tables to work. However, it would prevent Unicode properties from being used in regular expressions, remove String.prototype.normalize, and case conversion would be limited to ASCII (or perhaps ISO-8859-1) only.)
Additional optional extensions may be wanted, even if not enabled or even included in the executable by default (due to complexity), such as:
- PCRE.
- Option to disable automatic semicolon insertion.
- A "goto" command; you cannot jump into blocks, past declarations at the same level (in either direction), or out of functions. You can otherwise jump forward and backward within a block (including past nested blocks) or out of a block.
- Possibility for a function called by one JavaScript program to suspend that program while executing a different JavaScript program (which may possibly share objects with the first one), and later resume execution.
AFAIK, 8859-1 is a subset of 1252.
Browser diversity is top of mind for me...
One reason you might not want to build a general-use browser on QuickJS is performance. QuickJS is one of the fastest JS interpreters in its weight class, but engines like V8 achieve much better runtime speed by using fifty times the code to do all kinds of complicated just-in-time optimizations. Websites built in frameworks like React are often bottlenecked by JS engine performance (spending 100ms or more just doing tons and tons of object instantiations and function calls and stuff), so a QuickJS browser probably wouldn't provide a good experience for those.
What makes a "modern" browser is all of these technologies together not just quirk free, but matching quirks with whatever browser is popular. Even this won't really be enough since most people also depend on a bunch of online services provided by browser vendors at this point (push, bookmark syncing, password management etc.)
“layout”, including CSS? Hey, good joke, that’s amusing.
const m = {year: 2019, month: 12};
console.log(m); // [object Object]
{ year: 2019, month: 12 }Node does some custom fanciness, but Object.prototype.toString() is equally correct.
let m = {year: 2019};
let s = JSON.stringify(m);
console.log(s); // {"year":2019}Fabrice Bellard truly is one of a kind in the programmer world.
Try to make a JS engine than is 50X faster than Googles V8, and you become a centimillionaire! :D <3 Would love to see that.