joelangeway

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.

> It's literally zero-sum for him.

Well it is. There are a finite number of consumers of C++ compilers. He is competing for the attention of potential free software advocates.

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.

I concede the point. I hope I never have to herd that many cats.

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."

OK, I might have change my mind about that. I have been lucky enough not to have had to use multiple selfishly named libraries I guess.

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.

Thank you for the suggestions.

I use both .NET and the LAMP stack everyday. I love .NET and C# is a beautiful language. But I have to use Windows to use .NET. There is nothing wrong with Windows, except it doesn't have a very good shell; it doesn't come with the GNU user land; I can't just grep and sed and awk on one line to solve problems and answer questions; when I google for help with stuff like mysql I don't find near as many answers that would apply to windows; I can't just type "apt-get install ..." somewhere to try out a new programming language or other large program for free; I can't solve problems with SSH. All of these problems can be solved to a large extent, but not in a well known, well documented and Free way. Maybe that's just a matter of culture, but until the not-artificially-limited version of Windows can be downloaded for free, I can't give it a fair try.

I don't think that strong typing is bad, but I would like to point out that from his point of view, arguments FOR strong typing are based on the premise that "everyone is stupid."

Orthogonally, you don't have assume that everyone is stupid for it to be a good idea to design things as though everyone is stupid, because the fractional slice of attention and working memory that the user can easily spare is effectively a moron. This argument applies easy to issues of usability, but for programming, it may equate to driving a car with blinders on. I don't really know.

It's interesting that so many commenters take issue with the term "dishonest minority." I agree that honesty is usually the best policy, but I would lie to the Nazis about the Jews in the addic. This is the value in the dishonest minority and the conflict that the term implies to people who equate dishonesty with evil is central to the point.

"You can't really prove anything with a computer model like this,"

Indeed, the behavior the article describes sounds like a normal failure mode for a natural language processing computer program, "spewing out a jumble of grammatically correct yet disassociated sentences".

The reason they should be compared is because getting comfortable enough in Javascript to stop complaining about asynchronousity causes one to think about that aspect of programming the same way Erlang programmers do.

Erlang and Javascript are similar in that they both developed in highly asynchronous environments. And with multiple instances of Node.js, they have similar models of getting things done concurrently; that is, share nothing, pass and handle messages.

Both communities seem to prefer dynamic and/or functional solutions to programming problems rather than the sort of solutions you see in statically typed, "object oriented" languages. Though Node.js does make use of Javascript's object model, whereas Erlang uses very light weight processes to separate concerns.

Erlang's syntax is "weirder" where weird means doesn't look like C. It's semantics and facilities are much more strictly functional, though with some discipline you could use the same semantics in Javascript, minus nice functional features like pattern matching.

The number thing is absolutely not ridiculous. A book is a small amount of data that can be expressed in bits and it is trivial to stamp a number on every possible book, including many versions of this book with numerous misspellings.

It is indeed a complicated matter to produce a book and an author should probably be compensated for producing the book that they did instead of one of the other numerable but less desirable possibilities. Readers of the book could not have guessed the correct number to get the experience of reading it.

There is no obvious threshold, where writing down a number becomes different than editing a home movie or sharing a Beatles tune. You may say, "well of course this case is obvious 'cause I wrote it!" but that can't always be a good reason or you'll allow anyone to turn a number into a thought crime.

Worse still, those making the money have done their damnedest to convince us that copy-right is an immortal entity that cometh from heaven to justly enrich the sacred gate keepers of knowledge and culture. This is why there are pirates and why they are so self righteous.

It can't be helpful though to pretend that books aren't information.

I agree that people ought to be entitled to keep secrets. But Google is not a person, it is a publicly traded corporation which wields economic power on the same scale as state governments. I don't argue that they aren't entitled to secrets, but if they are, it is for different reasons and the comparison of those rights is misleading.

I hope I never have to work for someone who'll fire me if I tell them I'm interested in issues of class or race.

The article only names the OO and functional paradigms. The reader is led to believe there are just two.