I think the comparison of bitcoin with gold is a better one than stocks.
The value of gold today is not tied to the underlying precious metal any more. Gold is kept in vaults likely never to be looked at or touched. It might as well be a digital number.
Instead gold is a place to store capital with a value agreed between buyers and sellers. It is limited in quantity and is very difficult to copy. Bitcoin is quite similar is many respects. It also doesn't have to be stored and corrupt governments cant easily steal it.
I don't know Scanner Darkly and I don't have the app. But I have done a lot of my own images using the same algorithm as that used in the app. And, yes, it can definitely render photos is anime or cartoon like styles.
On the waiting time point. I was putting together a similar service to yours (though you got there first). We managed to get our processing time down to under 50s for a 300x300 image. How do you cope with such long times? Or, how long is the waiting time?
> "Practically, switching away from as many Google services as possible will help alleviate the most obvious issues like most of your personal data being in the hands of one company and the related issue of ads following you around the Internet."
Ads that follow you has absolutely nothing to do with Google services. These are retargeting companies using their cookies to track you. They use ad exchanges, so even that is not principally Google.
I'm surprised they do not reference GraphLab from Carnegie Mellon, http://graphlab.org/projects/index.html
It's built for the same purpose and has been around for a number of years. The core is in C++ with python bindings.
It has quite a few ready made applications built on top of it as well.
"None of these libraries (or many others) have competing implementations written in other languages."
Except the ones they were written to copy. Each example you give is an open-sourced clone of an pre-existing version implemented in a different language.
That's not true at all, Lucene is a Java project from the beginning, and has since been copied to virtually every other environment because it is such a kick-ass indexing engine.
C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.
You shouldn't really use the term "always" either. You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
> C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction.
Modern machines have, I don't know, say, 64GB RAM? How much of that can you use for thread stacks? 1GB tops? Modern applications work with really big heaps. Stack allocation is irrelevant for most of what the application is doing.
> Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.
Yeah, it seems that way, but it turns out that it isn't. Previous attempts to allocate Java objects on the stack showed little or no improvements.
A heap allocation in Java is a pointer bump, and deallocation of a short-lived object is free (Well, this is not quite true, because many allocations will trigger a young-generation collection which, in the JDK's GCs – though not in some commercial ones – takes linear time in the size of surviving objects)
> You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
You have the same option in Java, too, and it's pretty much the same amount of work.
> Stack allocation is irrelevant for most of what the application is doing.
Well I disagree with that. In C++ it is quite common for most objects to be allocated on the stack. I have never heard stack allocation being described as irrelevant. Of course if the language puts everything on the heap then that statement might be true.
> In C++ it is quite common for most objects to be allocated on the stack.
Most objects? You have 64GB of RAM! You want to tell me that you can take advantage of all that RAM with thread stacks? You're unlikely to even use 4GB of stack.
If you don't, then you're talking about a small application.
