WingNews logo WingNews GitHub [2]

joelangeway's comments

joelangeway | 11 years ago | on: Number of legal 18x18 Go positions computed. One more to go

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.

joelangeway | 11 years ago | on: How to zero a buffer

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.

joelangeway | 11 years ago | on: How to zero a buffer

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.

joelangeway | 12 years ago | on: The descent to C

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.

joelangeway | 12 years ago | on: How traffic actually works

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.

joelangeway | 13 years ago | on: JavaScript is the future...maybe

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.

joelangeway | 13 years ago | on: Why C# is the best language for mobile development

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

joelangeway | 14 years ago | on: PHP: A fractal of bad design

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.

joelangeway | 14 years ago | on: PHP: A fractal of bad design

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.

joelangeway | 14 years ago | on: What else is new in c# 5

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.

joelangeway | 15 years ago | on: Geek anti-intellectualism: replies

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!

joelangeway | 15 years ago | on: Geek anti-intellectualism: replies

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

joelangeway | 15 years ago | on: Erlang inventor: Why do we need modules and files?

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.

joelangeway | 15 years ago | on: Erlang inventor: Why do we need modules and files?

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.
page 1
more