One example that just occurred to me: The base 2 log of the number of legal positions of a 9x9 go game is about 126.3, which means if I use a good hash of board positions yielding twice that number of bits, I have a better than 50/50 chance of having no collisions. That is very good to know if you've got anything like a transposition table in a Go playing program.
Dropbox Pro is same rate (https://www.dropbox.com/plans). You do have to buy a it $10/month at a time, but you can get to it whenever you like without paying 9 cents per GB. AWS is usually worth it but it is never super cheap.
Even if a JIT compiler can prove that all the code in your app doesn't change that function pointer, because the variable is volatile, the compiler must assume that you intend to read from actual metal every time you refer to it and it can not predict what the value will be. Even a JIT compiler is not allowed to optimize away that read, or else you'd never be able to write a driver.
Yes, it refers to a memory location, without implying anything about the semantics of the bits located at that location. You can't dereference or assign to the location because you don't know the type at that location. You can however assign that pointer to a typed pointer variable to actually read or write to that memory location. This is useful when you really care about the bits of memory but you're variable pointing to that memory could just as well be an (int64_t ) as a (char ) and those types are not interchangeable with each other, only with (void ). So library functions that just care about memory locations, not the semantics of the bits there, take (void ).
Some of this may be technically incorrect. This is my own mental model of the C language which is sometimes incomplete.
He says several times that JavaScript succeeded in spite of being a bad language because it was the only choice. How come we're not all writing Java applets or Flash apps?
The original machine that influenced C's model of computers was the PDP-11 (http://en.wikipedia.org/wiki/PDP-11). It had a mov instruction instead of load/store. It had no dedicated IO instructions. It could be treated as a sort of generic random access machine (http://en.wikipedia.org/wiki/Random-access_machine) and that is what C did and still does. So there was a reality that C simply modeled, and it was copied (with all sorts of modifications) many times.
If you keep the same distance between you and the car in front of you regardless of your speed - which you seem to say -, I hope you are never behind me.
I personally have often gotten the impression that a large portion of developers already have The One Programming Language in their mind. It's usually Java or C# or sometimes still C++.
JavaScript fills me with joy because it is so unlike these languages and I get to watch people grow when they stop kicking and screaming and learn it. JavaScript doesn't have any super unique features or anything; it's just so not Java while frequently being suddenly essential to people who think in Java.
This is a fundamental place where the worlds of C# and Java differ. Where the Java world would say, "developers might misuse this, better not have it in the language," the C# world says, "developers could really use this, better put it in the language."
A better analog than fixing a literal car might be changing the tire of a car which doesn't have any tires when it is parked but which instantiates some with the help of an instance of ITireFactory. Obviously it makes no sense for a car to use a tire factory instead of just having tires. That is exactly how everyone who prefers PHP feels about everything.
I don't think that those problems are really independent, but rather, share a common cause with some of the things that made PHP a success. PHP evolved as it did in large part because its benevolent dictator refused to think about more than one problem at a time. I don't argue that that's the optimal way to do things, but it did provide a unique experiment for us all to learn from.
I confess to making the mistake many times of thinking that I was capturing a value when I was capturing a variable, but the author has me confused and concerned that the semantics of lambdas have been changed such that a lambda always captures the value and not the variable. Capturing variables is darn useful and more general than capturing values. It would be totally unlike MS to break all of my code as much as I wish they would in other cases, so I'm going to assume that they've done something more clever than that.
I'd also be afraid they'd put lobbying efforts into state legislatures to make home grown text books illegal or set standards that are difficult to meet for teachers and which are easy for big publishers.
And the only "classic" mentioned was "War and Peace". I haven't read that one but I've read Anna Karenina, also by Tolstoy, and a few of Dostoevsky's books. Yeah they're long, but they're long like concept albums are long. They're classics 'cause they're awesome, not 'cause some imaginary egghead wants to bore you with them!
I find this deliciously ironic. I can hear myself arguing as a sophomore CS student, "but whatever is going on that constitutes the mind is observably a process on information that happens entirely inside your skull, of course we can model it with software," to which I would today answer "you can model any phenomena with software, stating as such doesn't constitute a model."
The global namespace in PHP is awesome. I don't have to learn a framework to solve a problem, there's a function for it.
Namespace qualifiers in names are a fine solution to the collision problem. That's effectively what's there already except every darn function has to be in a module.
Names don't have to be treated like property, you can invoke policy on them and change bad names. His dreams about rich metadata probably include version tags and hashes that would prevent this from silently breaking anything or in a way that couldn't be repaired by a tool.
Modules don't solve the problem you think they do, they just make the name of all functions longer and harder to figure out. They're not hierarchical.
He addressed issues of visibility/encapsulation and gave a great example of where modules fail to solve the problem. Though I don't quite follow his suggested fix, it looks like using lexical scope to encapsulate fib/3 but my Erlang is actually a bit rusty.
He is probably imagining that the name of that function would be "nameofproject_assign_user_activity/2", and that you would typically use it along with some others from the same source, following some conventions. Seems that obviates modules to me. In Erlang you give the name of the module with a function anyway, so names like that harm nothing. It would be real nice to type "map" instead of "lists:map" though.