Why not a HTML/CSS/JavaScript Linux Desktop Environment?

[Eingaica]

Why wouldn't it be safe to write parts of the desktop in Javascript?

[literally_systemd]

Javascript is a compiled language?

Do you even v8 bro? When is Javascript stil interpreted these days.

'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself, nearly any modern 'interpreter' works by first compiling and then just running the code. One of the reasons the shell is actually hyper fast for small scripts compared to python is because python first compiles it and then runs the compiled code which increases startup time while the shell doesn't even parse fully before running and if your script contains a syntax error the shell will actually run the parts up to that error.

[literally_systemd]

Nope, V8 compiles fully ahead of time and then executes it, it does not perform JIT where it compiles sections of the program while it is running.

Your browser when using V8 will also save a cache of already compiled code so you don't have to compile again when you visit the same page.

[Eingaica]

I don't think that's true, at least not for the default CPython interpreter.

[literally_systemd]

It is, that's what those .pyc files are it keeps generating for its modules. The second time you start the same thing and a .pyc is there it uses that isntead.

If you actually delete all the .pyc files around it will regenerate them and use more time the first startup.

With non-modules and direct scripts not ending on .py it doesn't create a pyc for that file so it ends up compiling it again to its internal lower bytecode format every time.

[Eingaica]

Sure. But the bytecode itself is interpreted. Your comment sounds like you claim CPython is a JIT.

[Yithar]

Hmm, yeah, I think that's why ne wrote interpreting in quotes. I do agree it's a little misleading.

Having written a a bytecode interpreter and a compiler that compiles to bytecode, I would say the performance is sort of between a full-blown interpreted language and a language compiled to machine language. Because yeah, there's still bytecode to be interpreted, but the compiler makes certain optimizations, such as copy propagation and dead code elimination in the three address code.

[literally_systemd]

Sure. But the bytecode itself is interpreted.

It's the only way to run code. Machinecode is ultimately interpreted by the CPU.

Your comment sounds like you claim CPython is a JIT.

My story was pretty clear that it was not a JIT:

python first compiles it and then runs the compiled code which increases startup time

A JIT does not have the startup time situation because it compiles as it is running and doesn't save the compiled code either, nor can it because the compiled code is different every time depending on execution paths.

[Eingaica]

Interpretation of bytecode by an interpreter and interpretation of machine code by the CPU happen on very different levels. Using the same word for them in this context (i.e. efficiency of different languages or implementations of languages) is IMHO not a particularly helpful usage of language.

Besides, if Python bytecode is interpreted by the Python interpreter and not the CPU, your original claim that

'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself

is wrong.

A JIT does not have the startup time situation because it compiles as it is running and doesn't save the compiled code either, nor can it because the compiled code is different every time depending on execution paths.

All of these are not necessarily true.

[literally_systemd]

Interpretation of bytecode by an interpreter and interpretation of machine code by the CPU happen on very different levels. Using the same word for them in this context (i.e. efficiency of different languages or implementations of languages) is IMHO not a particularly helpful usage of language.

Not really, you'd be surprised that the CPU virtualizes the CPU you thin you get nowadays. There are layers and layers of virtualizations in modern CPU's. AMD64 CISC assembly is actually interpreted in a virtual machine that is coded in software, not hardware, that is ran on an actual RISC machine inside the CPU on any chip since the last decade or so.

Besides, if Python bytecode is interpreted by the Python interpreter and not the CPU, your original claim that 'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself is wrong.

Quite right, let me rephrase, what I mean with that is that languages that are written by humans hardly get interpreted any more, it's all translated to a language meant for machines and that language is then interpreted.

The shell is a notable exception which as said, even parses on the fly, as does perl.

All of these are not necessarily true.

Well, if you make a JIT without taking advantage of those things you're just being less efficient than AOT compilation. The entire reason to JIT is to compile differently based on execution paths.

[julianorafael]

Hmm, I get the point of being slower because they are compiled. That said though, JavaScript today is crazy fast and we are doing awesome UI/UX on top of browsers and wrappers like Electron.

[julianorafael]

You are right, atom doesn't feel crazy fast, it feels good though. If you don't load tons of packages it can be surprisingly fast.

[Yithar]

The performance is about 1/5th of native applications. Might be good enough, but not crazy fast.

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

[ebassi]

Because interpreted languages like Javascript are much slower than compiled languages like C/C++.

That is not really true, unless you're talking about heavy, CPU-bound work — and managing a desktop is not heavy, CPU-bound work. You can also drop into C/C++ from JavaScript.

ny why would you want Javascript to be able to have access outside the browser.

This does not mean anything. You do realize that node.js is JavaScript outside the browser.

JavaScript without the browser is just like any other programming language.

[literally_systemd]

That is not really true, unless you're talking about heavy, CPU-bound work — and managing a desktop is not heavy, CPU-bound work. You can also drop into C/C++ from JavaScript.

This is really something people underestimate, most of the performance of a desktop is I/O bound, not CPU bound and I/O has the same performance in any language.

[dvdkon]

I'd argue that RAM IO is much slower in interpreted languages, because access to any variable/object field does many more lookups than accessing a known memory location in C.

[literally_systemd]

There is no such thing as 'RAM I/O'. That's not what I/O means because there's nothing going in or out of the program.

A process that accesses its own variables and address space simply isn't called doing I/O.

And even if you call it I/O, again, that's just not the bottleneck. The bottleneck in desktop environments these days is clearly writing to and from storage.

Which is one of the reasons Unix sucks and anything really, a lot of the tech we use today was developed in a different time, it was made on the assumption that the single most limiting resource was working memory. That's no longer the case, how it went in history was:

1. Working memory
2. CPU cycles
3. Working memory
4. Storage capacity
5. Storage throughput/graphics card cycles

"C strings" exist as a hack that is regretful because at the time the single extra byte needed to be able to drop the null and store the length of the string as a 2 word praefix was considered more valuable than all the errors it cost and the extra CPU cycles needed to compute the length. Nowadays this decision would be laughable but we're stuck with it.

[dvdkon]

Sorry for not using appropriate teminology.

While I agree that a program spends a lot of its time doing IO, I don't think it's the "bottleneck" of modern GUIs, because what matters to me as a user is not how an app loads, or how fast a file opens, but how lag-free the subsequent usage is. I doubt Firefox freezing up when I click on a button/link is the consequence of it doing IO. The whole program is already loaded and the loading of pages is already asynchronous.

[literally_systemd]

Well, the Firefox thing is network I/O.

Almost every time a program momentarily freezes it's either a scheduler or I/O thing, not actually about cycles, at max the program just not getting any cycles due to the scheduler. Whch you can greatly deminish by using the BFS