3 ms·

Could you give another example of how this would be used? It seems like a cool idea, but I think I'm too stupid to quite understand why yet. > When you attempt

Could you give another example of how this would be used? It seems like a cool idea, but I think I'm too stupid to quite understand why yet. > When you attempt to dereference the pointer, a page fault fires, which causes the underlying system to load the image from the server. When the loading is complete, your program resumes. This first half doesn't sound very exciting, this is exactly how your program already works when it communicates with the OS. It's also how co-routines work, this space has already been pretty well explored. > When you dereference the pointer to the image, you know the user's viewport size. Meaning you know how large the image should be. Therefore the underlying system can automatically request a perfectly-sized image from the server This part seems pretty cool, it's not currently easy to reconfigure your OS and have it change the answers it gives you (except in some obvious cases, like changing the file your program is going to read() ). I like the idea of "dynamically reconfiguring the syscalls", but I'm not sure what I would use it for.

sillysaurus3 8y ago
I like the idea of "dynamically reconfiguring the syscalls", but I'm not sure what I would use it for. Exactly this. Little things, like why can't you just write `fs.readFileSync(<server URL>)`? That's all you want to do. You don't want to deal with issuing a fetch call and setting up handlers and so on. That should be abstracted from you. Ad everyone has their own ways of doing this, and you just search for whatever JS lib happens to tickle you that day. It's the opposite of a unified engine model. Why does that matter? Because the easier your code is to write, the faster you can write. And the larger the systems you can create, individually. Since system value scales inversely proportional to the number of people working on it, that means you alone can build something in a few days that would normally take a team of programmers quite a lot longer. Think of it this way. Why bother writing React? There were existing solutions. Yet we all saw what happens when you ignore standard ways of doing things and push for something better. Two specific examples: You want to write blocking code, no callbacks and no awaits, and you want greenthreads. The reason you want this is because your codebase becomes exponentially smaller. And the only way to accomplish this in JS is to essentially write your own programming language on top of JS. Not really a transpiler, but more like an entire scheduler with heap allocated memory and page tables. If that sounds crazy, just imagine how crazy it would've sounded to try to mix HTML inside of javascript before JSX. The central theme here is simplicity and generality. HN's codebase proves what a single dev can achieve when you focus exclusively on these two goals. EDIT: Some design inspiration: https://www.youtube.com/watch?v=Ox2H3kUQByo&t=1340s https://www.youtube.com/watch?v=Ox2H3kUQByo&t=1340s This is one of the few games where Lisp is used, and they show how and why it enables them to do easily what other games struggle to.

sillysaurus3 8y ago

I like the idea of "dynamically reconfiguring the syscalls", but I'm not sure what I would use it for. Exactly this. Little things, like why can't you just write `fs.readFileSync(<server URL>)`? That's all you want to do. You don't want to deal with issuing a fetch call and setting up handlers and so on. That should be abstracted from you. Ad everyone has their own ways of doing this, and you just search for whatever JS lib happens to tickle you that day. It's the opposite of a unified engine model. Why does that matter? Because the easier your code is to write, the faster you can write. And the larger the systems you can create, individually. Since system value scales inversely proportional to the number of people working on it, that means you alone can build something in a few days that would normally take a team of programmers quite a lot longer. Think of it this way. Why bother writing React? There were existing solutions. Yet we all saw what happens when you ignore standard ways of doing things and push for something better. Two specific examples: You want to write blocking code, no callbacks and no awaits, and you want greenthreads. The reason you want this is because your codebase becomes exponentially smaller. And the only way to accomplish this in JS is to essentially write your own programming language on top of JS. Not really a transpiler, but more like an entire scheduler with heap allocated memory and page tables. If that sounds crazy, just imagine how crazy it would've sounded to try to mix HTML inside of javascript before JSX. The central theme here is simplicity and generality. HN's codebase proves what a single dev can achieve when you focus exclusively on these two goals. EDIT: Some design inspiration: https://www.youtube.com/watch?v=Ox2H3kUQByo&t=1340s https://www.youtube.com/watch?v=Ox2H3kUQByo&t=1340s This is one of the few games where Lisp is used, and they show how and why it enables them to do easily what other games struggle to.