(I forgot to add "return x;" inside the function, but I guess that's clear)
The language is single threaded, doesn't mean it can't support "threads" in a message-passing way. The fact that my old Apple ][ can support threads by hooking 2 of them up through a serial interface doesn't make them "multithreaded". But if you want to look at it that way, then I apparently can't stop you
your assumptions simply don't match reality
Ok, so if a "for" loop is transformed so easily into an equivalent asynchronous structure, please enlighten me and show me how.
For example, take these simple nested loops, and I'm curious what code it transforms into.
for(var i = 0; i < N; ++i)
for(var j = 0; j < N; ++j)
for(var k = 0; k < N; ++k)
x = g(x, i, j, k);
where g is some constant-time function.
I know this is Slashdot, but you must be talking about Google here.
If they can tell legal from non-legal, why do they even show the illegal stuff?
In related news, most people earning over $1M through the development of an iOS app have the profession: software developer.
A man is sitting in this ship, and throws a massive Korean-made LED TV-screen overboard into the water.
As a result, will the water level rise, or drop?
As threads are not an option in JS, it's a great opportunity for you to explore various alternative approaches.
Please don't forget that the whole point of my comment was that threads are broken in JS.
Go do some reading about asynchronous programming and event-driven programming.
The problem with event-driven/asynchronous programming is that it requires a lot of work, and makes your code look awkward. For example, a simple "for" loop turns into a monster of functions calling eachother, in order to break the inside of the for-loop into small chunks that can't lock the UI. Now imagine a doubly-nested for-loop. You'd need special compilers to keep your code clean.
Remember that Windows 3.1 was replaced by true multitasking for a reason.
Also, asynchronous code can only make use of 1 core of your CPU, which is also a waste.
A customer just called. He pressed "Ctrl+End" to go to the end of the document, while it was counting words. He complains that the user interface is frozen.
Just because you can't think of a way to solve a particular problem you've just thought of, doesn't mean that high-quality performant programs can't be written in the language.
Yes. But because of this problem of the (fictituous) customer, I now have to rewrite my 30.000 lines of code from web-worker style to single-threaded asynchronous style. Unless you have a better idea
The problem is that "threads" are supposed to be a solution to dividing work.
If you don't have threads, how will you divide work without ruining the nice hierarchical structure of your code?
You'll need a special compiler that does this for you. And the result will be *slow* (albeit perhaps more responsive).
Maybe you should just, you know, leave the text in the non-GUI worker to start with?
Let me get this straight. This means that when the user scrolls the document, the web-worker would feed the GUI with lines of text incrementally (?)
However, if, at the time of scrolling, the web-worker would be busy counting words in the document, I don't see how the GUI would not *effectively* freeze just as well (the main thread would be waiting for new lines from the web-worker which is busy counting words).
Or you can incrementally update the background thread as the data changes.
This is like splitting up the task of counting words into smaller tasks that execute incrementally.
"Splitting-up tasks" is the keyword here, and the thing is, that's what threads are supposed to do. If we split up all our tasks manually, we wouldn't need threads.
The web-worker thread-model is not really helping, because we'd have to split up tasks anyway ourselves.
You're probably still running Windows 3.1, with pre-emptive multitasking.
Web-workers are not cutting it. For the following reason.
Real multi-threaded programs have a shared address space. Web-workers do not.
Example: suppose your GUI runs on a 1 megabyte long text-file.
The data-structure that models the text-file is 2 megabytes long.
Now you want a web-worker to do something with this text-file in the background (e.g., count the number of words).
So you start a web-worker thread. But then you need to send the text-file as a message to the thread (since there is no other way the thread can reach the data).
Sending this 2 megabyte chunk of data will surely freeze your GUI for a while, and so the whole point of multiple-threads is mostly lost.
Lets stop pretending they are anything close.
Google docs/sheets/whatever is a really crappy imitation of a full fledge office suite
This means that when processing one action of the user (especially if it is a complicated action), the user interface will temporarily freeze.
In this day and age, this is totally unacceptable.
Totally agree with that.
The only problem seems to be the acceptance of NaCl by the other big browser vendors (Microsoft, Mozilla).
Here's what wikipedia says:
(warning: could be outdated)
Some groups of browser developers support the Native Client technology, but others do not.
Id Software's John Carmack praised Native Client at QuakeCon 2012, saying: "if you have to do something inside a browser, Native Client is much more interesting as something that started out as a really pretty darn clever x86 hack in the way that they could sandbox all of this in user mode interestingly. It's now dynamic recompilation, but something that you program in C or C++ and it compiles down to something that's going to be not your -O4 optimization level for completely native code but pretty damn close to native code. You could do all of your evil pointer chasings, and whatever you want to do as a to-the-metal game developer."
Detractors: Other IT professionals are more critical of this sandboxing technology as it has substantial or substantive interoperability issues.
Mozilla's vice president of products, Jay Sullivan, said that Mozilla has no intention of running native code inside the browser, as "These native apps are just little black boxes in a webpage. [...] We really believe in HTML, and this is where we want to focus."
Mozilla's Christopher Blizzard criticized NaCl, claiming that native code cannot evolve in the same way that the source code-driven web can. He also compared NaCl to Microsoft's ActiveX technology, plagued with DLL hell.
Håkon Wium Lie, Opera's CTO, believes that "NaCl seems to be 'yearning for the bad old days, before the web'", and that "Native Client is about building a new platform – or porting an old platform into the web [...] it will bring in complexity and security issues, and it will take away focus from the web platform."
Interesting. Do you know what book(s) on data-mining are most widely used/seen at Google?