Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A small but complete JavaScript engine

bellard.org

Post reply on HN
Print view View original

121–130 of 151 posts

Re: A small but complete JavaScript engine

#121

Post by derangedHorse »

jonex wrote: post #113
thamer wrote: post #34

Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. 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.…

It would probably be easier to read, but as a one-man project, my guess is that readability is less of a concern than for the average code base. Splitting code up in files requires some extra work and makes refactoring harder as you have to spend a lot of effort on trivial tasks such as moving dependencies between files and updating includes all over the place. Personally I tend to want to split up code written by ot…

I do agree that it’s easy for a single programmer to not think about future readability for other all that much but in terms of refactoring code and straitening file dependencies, an IDE or code editor like VSCode can probably do it for you.

Re: A small but complete JavaScript engine

#122

Post by derangedHorse »

coder4life wrote: post #76
bigyikes wrote: post #58

Earlier quoted context omitted.

> Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones. 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.

Working with 1 or 2 large files is vasty more productive/faster (for me) than working with 50 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.

Although I agree with the fact it was easier/faster for him, don’t fall into the fallacy of him being productive meaning he was efficiently productive

Re: A small but complete JavaScript engine

#123

Post by mantap »

chii wrote: post #73
Macuyiko wrote: post #6

Earlier quoted context omitted.

Agreed. 10 years ago, I could still pretend I'd be able to come close to his productivity if I "just set my mind to it." Today (being older, slower, and having a family), I can only be humble.

Many people don't have the misconception that they can compete athletically at the level of olympics. And yet, somehow, a lot of people mistakenly believe they could perform intellectually at that same high level!

I'm not convinced. Our brains are well know for their plasticity. Our musculoskeletal and circulatory systems: not so much. The brain is capable of rewiring itself after some quite traumatic injuries, of course the people who go through rehabilitation after a traumatic brain injury do so with the focus of someone whose life depends on it.

I would suggest that most people reading this are capable of Bellard level productivity, if their life depended on it.

Re: A small but complete JavaScript engine

#124

Post by nt2h9uh238h »

so it's 50X smaller and 30X slower than Googles V8 Engine - cool, but not that impressive. I would still use V8 on any decision, because 30MB is really not such a big deal anymore. SPEED is what matters in 2020, not disk size!

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.

Re: A small but complete JavaScript engine

#125

Post by derangedHorse »

megous wrote: post #37
thamer wrote: post #34

Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. 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.…

Http is not part of JS engine, because it has nothing to do with JS. 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.

The original comment was about separating components out for reuse in other projects. He wasn’t wondering why http wasn’t part of the js engine, that was just the example he chose

Re: A small but complete JavaScript engine

#127

Post by [deleted] »

interfixus wrote: post #114
thamer wrote: post #34

Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. 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.…

Well, this sparked off a whole and quite predictable thread. We can only hope Fabrice Bellard reads it all so he can learn himself some coding.

[deleted]

Re: A small but complete JavaScript engine

#128

Post by brabel »

bitwize wrote: post #116
brabel wrote: post #100

Earlier quoted context omitted.

To suggest that not using an IDE is a sign you're a better developer makes as much sense as suggesting that not using an electric screwdriver to fit things is a sign of a better handyman.

To suggest that GP could have written better software had he used an IDE is to suggest that Michelangelo could have painted a better Sistine Chapel fresco had he used an electric paint sprayer. Or, to bring it back within realistically achievable levels of talent, that Bob Ross's trees would've been happier if he used one.

No one suggested OP could do a better job had he used an IDE (and I have no idea if he did). The claim was that NOT using an IDE somehow signals you're a better developer, which is simply absurd.

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

Re: A small but complete JavaScript engine

#129

Post by ddelt »

kelnos wrote: post #108
chii wrote: post #70

Earlier quoted context omitted.

> get shoved into management long before his age. 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.

It doesn't have to be that way, and indeed many orgs are moving away from that. Where I work, individual contributors who are talented and want to put in the work can attain a level comparable to a Director or Senior Director, and often even make quite a bit more money than their level-peers on the management track. There's still a cap, of course; you can't remain an IC and have the level equivalent of a VP or C-leve…

Yes, where I am at we also have a similar career track just introduced a year back or so. For the most part it’s a welcome change and recognition that an IC can be just as if not more valuable than a manager.

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.

Post reply on HN