Api docs do tend to merely provide method signatures, which is great when you know what you are doing, but when you come upon a bunch of generics, implicit parameters, and thats in the docs for the first time, you end up combing through a lot of stuff. In many cases, a simple example use case embedded in the document with console output of the use case would admittedly be very helpful.
Call me crazy, but I think threading could be implemented via green threading or by utilizing a global event loop to manage script execution. Using pop up windows, one for each thread, might also be a solution that takes advantage of system level threads. It might also be possible to implement sleep using a synchronous ajax call to someting that doesn't exist that has a specific timeout attached to it.
Fingerprinting can be very useful to you as a user, as well. Imagine that you switch between devices and work locations all the time and you use a core suite of web applications. Fingerprinting could be used, with your permission, to uniquely identify you across all your devices, locations, and browsers for the suite of services that you depend upon. Not having to ever enter a password again while remaining secure sounds pretty nice to me.
It is not the technology, but the evil application of said technology that is evil.
IANAL, but: It's easy, "Just Say No." If they really want the information, they'll get it somehow or refuse you employment, at which point they may open themselves for a lawsuit involving discrimination based upon race/sex/creed and/or privacy violation and/or libel and/or slander, which will net you more money than if you had accepted the job in the first place. If everyone in an industry begins to refuse you based on your privacy standards, you may be able to sue based on suspicion of collusion.
On a humorous note, if personal lives are a deciding factor in whom a business chooses to employ over and above other, skills-based qualifications, the job you are applying to is likely very easy, and thus the kind of job that robots will be doing soon.
^^^^^^^ This. It is so important to be a great idea salesperson. Even if you are writing a OSS tool, if you want contributors you need to sell the idea.
I disagree that the paper is obsolete. References and pointers abound in nearly every popular modern programming language [C, C++, Java, C#, PHP, Python, Ruby, EcmaScript, etc.] and in fact are the defining feature of all OO languages. Operator overloading is only possible in a small fraction of popular modern programming languages. Fast compilation is not even a focus of most popular modern programming languages. Type inference and automatic coercion, declaration, and defaults are in vogue in most programming languages. Also, programming languages are increasingly large and complex. Compiler optimization is likewise a hot-spot topic, as are gotos/jumping and global and out of block variable definitions.
It would seem to me that if his hints and assumptions are correct that language designers may have inhibited the growth of programming; though a programmer that knows her/his language of choice can and does take advantage of all of the inefficiencies described in this paper.
I'm really beginning to realize that the functional languages probably have it right: single value assignment; recursive function execution; compact, readable code; monads; guards; readable case statements; and narrow interfaces seem to satisfy a lot of what he recommends. Most OO languages definitely do not, although I love the expressiveness I have learned to achieve by exploiting their nuances.
