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:S
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.
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...
The real underlying reason these apps feel flimsy is probably that Javascript is a single-threaded language. It's like going back to the 80s. 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.
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)
Reception Some groups of browser developers support the Native Client technology, but others do not.
Supporters: Chad Austin (of IMVU) praised the way Native Client can bring high-performance applications to the web (with about 5% penalty compared to native code) in a secure way, while also accelerating the evolution of client-side applications by giving a choice of the programming language used (besides JavaScript).[30]
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."[31]
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."[32]
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.[4]
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."[4]
Agree. I use Python with open source packages like scipy, numpy, matplotlib and others, to achieve almost the same thing as Matlab. Also the language (Python) is much cleaner.
Apple is keeping its number of products (devices/models) to a minimum. If I invest in Apple products now, I'm sure that in the future -when I am locked in, or when Apple has destroyed the competition- I have only less to choose from.
Can somebody please explain why it would be smart to buy some of these devices?
And what about asymmetric upload/download speeds that most ISPs provide. Good luck running a server with an uplink that can handle only 1/10th of a decent tranfer speed.
I once bought a DVD in a shop. Turned out it contained fictitious stuff that was pretty much useless by any scientific standard. Now I download my fairy tales through some Swedish website.
1) Choosing a password should be something you do very infrequently
Wrong. Once your password is compromised (e.g. by use of a keylogger or otherwise), hackers can use it over and over again. It is much better to use One-Time-Passwords (OTPs) such as the ones generated by two-factor authentication systems.
Wikipedia states it (Bremelanotide) was found as a side-effect of a tanning agent.
I genuinely wonder... is this how research works in neurology? Do we even have a basic understanding that could help us design such drugs, or are we just dependent on whatever side-effects come out of drugs from other fields?
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 :S
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
The real underlying reason these apps feel flimsy is probably that Javascript is a single-threaded language. It's like going back to the 80s.
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)
Reception
Some groups of browser developers support the Native Client technology, but others do not.
Supporters: Chad Austin (of IMVU) praised the way Native Client can bring high-performance applications to the web (with about 5% penalty compared to native code) in a secure way, while also accelerating the evolution of client-side applications by giving a choice of the programming language used (besides JavaScript).[30]
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."[31]
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."[32]
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.[4]
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."[4]
See http://en.wikipedia.org/wiki/G...
Interesting. Do you know what book(s) on data-mining are most widely used/seen at Google?
Just curious.
Please don't give robots religion. We don't need to have robots fighting for the same reasons we do.
vi versus emacs?
However, your note is taken. This won't look good on your Google "behind-the-curtains" resume.
Looking back at my old Matlab code also makes me cringe a bit about the syntax of that language.
Then you haven't seen the "R" programming language yet.
Agree. I use Python with open source packages like scipy, numpy, matplotlib and others, to achieve almost the same thing as Matlab.
Also the language (Python) is much cleaner.
Right. So why choose the ecosystem which offers the smallest amount of choice?
Apple is keeping its number of products (devices/models) to a minimum.
If I invest in Apple products now, I'm sure that in the future -when I am locked in, or when Apple has destroyed the competition- I have only less to choose from.
Can somebody please explain why it would be smart to buy some of these devices?
And what about asymmetric upload/download speeds that most ISPs provide.
Good luck running a server with an uplink that can handle only 1/10th of a decent tranfer speed.
I can see it coming now: "CUPS 3.0 for tablets"
I once bought a DVD in a shop. Turned out it contained fictitious stuff that was pretty much useless by any scientific standard.
Now I download my fairy tales through some Swedish website.
1) Choosing a password should be something you do very infrequently
Wrong. Once your password is compromised (e.g. by use of a keylogger or otherwise), hackers can use it over and over again.
It is much better to use One-Time-Passwords (OTPs) such as the ones generated by two-factor authentication systems.
And how do you get rid of them before the wedding night?
Wikipedia states it (Bremelanotide) was found as a side-effect of a tanning agent.
I genuinely wonder... is this how research works in neurology? Do we even have a basic understanding that could help us design such drugs, or are we just dependent on whatever side-effects come out of drugs from other fields?
This story is rated too complicated for a broad audience to understand.
It's a clear case.
What's next?
FBI Says It Will Hire No One Who Lies About Masturbating
Proposed 20 years ago, and it's still not Turing complete.
What a bummer.
It would be running in a browser in ugly-quirks mode inside an emulator inside an emulator inside an emulator.