Hacker News Reader

Comment by tree_of_item | Hacker News Reader

Chrome already ships a compiler today. Why wouldn't it continue to do so in your hypothetical?

Are you referring to the JavaScript compiler? I don't understand your point, would you elaborate? The article is about factoring out all inputs from a program. Chrome's compiler is used to compile new inputs on the fly, it's reason for existence doesn't seem to mesh with the author's goal.

FWIW, I'm trying to imagine the author's hypothetical. If you think I'm imagining something other than what he proposed, I'm all ears!

> I'm imagining that if only the compiler were allowed to do I/O, I'd have to rebuild Chrome whenever I wanted to see a new site, or even see an update to a site, or change my preferences. Wait, scratch that, I can't change preferences, because it can't save.

Chrome IS the compiler. Your preferences are a program provided as input. Websites are programs provided as input. You wouldn't need to rebuild Chrome to change things.

Can you elaborate on what you mean?

How would I save my preferences?

Do all websites have to be compiled as programs first, so they can be input as programs into new Chrome?

If my websites were provided as input and compiled into Chrome, how do I avoid rebuilding Chrome when the websites are updated?

If Chrome is the compiler, then Chrome is allowed to do all the I/O it wants, just like it does right now?

I mean, at some point you're just asking me to implement it for real, but I'll give you some hand-wavy answers:

You save your preferences the same way you might save `jquery.js` on your computer.

Chrome IS the compiler, you don't need to compile them first to give them to Chrome.

I'm not sure what you mean by "compiled into Chrome". Since when you do compile a program "into" the compiler? Look, your browser probably JIT compiled a dozen programs just for you to be able to view this page and comment. Did you need to rebuild Chrome?

Yes, Chrome is doing the IO. Importantly, the page is NOT doing the IO. So, there's no XMLHttpRequest, for example.

To make an analogy to Python: you don't need to recompile Python to interpret new Python programs. Chrome would be like Python: Chrome is itself a compiled program, but it interprets user settings and web pages.

Chrome is allowed to do whatever I/O it wants, but the programs it interprets (like user settings and web pages) are not allowed to do any I/O at all. These interpreted programs are sandboxed.

This isn't really surprising if you think about it. Chrome is already an interpreter for a sandboxed language (JavaScript)

A closer analogy to Dhall would be if web pages were assembled entirely from JavaScript instead of HTML, URLs were just pointers to Javascript expressions, and JavaScript code could refer to other JavaScript code anywhere within the syntax tree just by URL (instead of out-of-band via a <script> directive)

I don't know Dhall, but that sounds like what we already have. URLs are already pointers to JavaScript expressions, and many websites are already JS that constructs HTML... that's the main direction React is going, for example. The script directives are irrelevant, it'd be easy to show equivalence without them. And I don't see what any of this has to do with writing programs that don't read inputs or write outputs.

Right, and where I'm going with this is that we should take the JavaScript model to its natural conclusion and use it more pervasively in other domains. In other words, more applications and domains should be configured via sandboxed and interpreted programs that can easily reference other programs

However, the difference is that I don't think we should use an untyped and Turing-complete language for doing this (which is my primary objection to JavaScript). Also, I think the mechanism for referring to other programs should be more lightweight (i.e. just dump the path and URL into your code and you're done)

Reply on news.ycombinator.com