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

81–90 of 151 posts

Re: A small but complete JavaScript engine

#81

Post by iratewizard »

sieabahlpark wrote: post #74
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.

Because good managers are hard to come by so you have to give some sort of incentive to attract and retain the good ones. Good managers increase the output of their team, bad ones try to make themselves look the best.

Plus good managers who were top notch contributors grow the next generation of top notch contributors.

Re: A small but complete JavaScript engine

#82

Post by mhh__ »

iratewizard wrote: post #81
sieabahlpark wrote: post #74

Earlier quoted context omitted.

Because good managers are hard to come by so you have to give some sort of incentive to attract and retain the good ones. Good managers increase the output of their team, bad ones try to make themselves look the best.

Plus good managers who were top notch contributors grow the next generation of top notch contributors.

Exactly, in my experience of open source so far, the biggest difference from a good project to a great project is management - even as simple as just keeping track of PRs.

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.

Re: A small but complete JavaScript engine

#83

Post by lisper »

userbinator wrote: post #52
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.…

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. 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 t…

> code is scattered across many files which are barely one screen long

... one third of which is the copyright notice and license, and another third is boilerplate.

Re: A small but complete JavaScript engine

#84

Post by breck »

z3phyr wrote: post #80
chii wrote: post #75

Earlier quoted context omitted.

> you can just search one or two large ones. 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.

Your IDE should be able to split a single file codebase into different readable modules. If it cannot do that, its not a good IDE. And slippery slope...

Is there a term for this type of refactor? Often I might end up with 2 exported classes in one file, both being used across other files. I then want to separate them into 2 files and update the imports. I feel like my IDE should be able to do this, I just can’t seem to google the right term.

Re: A small but complete JavaScript engine

#87

Post by barumi »

kdtop wrote: post #19
hansjorg wrote: post #16

Earlier quoted context omitted.

I realize you're joking, but a company called Samsung actually did something similar already: https://nodejs.org/

Serious question, why is this a joke? Couldn't javascript be just another language to replace bash?

> Couldn't javascript be just another language to replace bash?

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.

Re: A small but complete JavaScript engine

#88

Post by barumi »

PrinceKropotkin wrote: post #43
saagarjha wrote: post #23

Earlier quoted context omitted.

People typically write small, short scripts in bash, not web applications. The same goes for JavaScript, but in reverse. They were designed for different things.

There's nothing about javascript that makes it particularly suited for "web applications". This doesn't seem any more ridiculous than, say, using python or perl.

Being event-driven and simple and hot reloadable and forgiving does make it well suited for the task at hand.

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.

Re: A small but complete JavaScript engine

#89

Post by userbinator »

chii wrote: post #75
userbinator wrote: post #52

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. 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 t…

> you can just search one or two large ones. 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.

Searching in one file is easy in any text editor. Searching across files (and directories) is more difficult.

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.

Re: A small but complete JavaScript engine

#90

Post by travisgriggs »

sieabahlpark wrote: post #74
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.

Because good managers are hard to come by so you have to give some sort of incentive to attract and retain the good ones. Good managers increase the output of their team, bad ones try to make themselves look the best.

But... the Peter Principle?

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)

Post reply on HN