502 karma · joined October 4, 2012
>In this paper we announce that checkers has been weakly solved. From the starting position (Fig. 1, top), we have a computational proof that checkers is a draw. The proof consists of an explicit strategy that never loses — the program can achieve at least a draw against any opponent, playing either the black or white pieces.
Not the focus of the talk, just thought I'd point it out.
When you take a hard course it consumes a disproportionate amount of attention. Even if the teacher is bad at his/her job a harsh grading scheme will drive you to spend hours in the library. You will learn a lot because you are burning valuable attention; attention other classes can not have. So such a class necessarily good? Of course not. Not if the learning benefit is outweighed by learning opportunity cost.
So regarding the finding of the study
The better the professors were, as measured by their
students' grades in later classes, the lower their
ratings from students.
I'm not confident that performance in later classes of the same sequence is a fair measure of learning; what matters to me is performance in ALL later classes. How do evaluations correlate then?Aside I have to admit I am confused by the word "neurological". If a condition is neurological does that mean it is rooted in the nervous system (which includes the brain)? Is a condition that is rooted in the nervous system, but we do not yet know how to observe or study it, still "neurological"? That seems like the case for synesthesia.
I'm not sure that's true, other sites report he got a 4.0.
http://www.notablebiographies.com/news/A-Ca/Carmack-John.htm... http://www.statemaster.com/encyclopedia/Carmack
Aside from that the made up terms are annoying. It would be more readable if he used
voodoo code => dead code
bulldozer code => high cohesion subroutines
pinball programming => unreliable code
I can't think of anything good to say about this article.The Nim code's more concise in this case but the Rust code can be more clearly written:
impl Add for Point {
type Output = Point;
fn add(self, other: Point) -> Point {
Point(self.0 + other.0, self.1 + other.1)
}
}
The "type Output = Point" line isn't boilerplate, it makes it possible to define the result of an addition as something other than a Point. (Off of the top of my head I can't think of any use cases, but I'm happy with the capability personally).Programmers can't easily streamline like this. Maybe there are multiple forces locking us in: the keyboard, text editor, and programming language. Sure, maybe the optimal way to write code is with a string of ascii characters arranged left to right top to bottom but I doubt it. So even in the visual-symbolic space there is unexplored potential.
I'm glad someone is out there tackling these assumptions and much more, I should keep an eye on his work.
On an unrelated note, his website is entertaining: http://worrydream.com/
But admittedly conversion between Points and Sizes is not a pain point for most people. It's much worse when dealing with types that have the exact same purpose, just from different libraries.
struct Point { int X; int Y; ... }
struct Size { int Width; int Height; ... }
In either case the data structure is (int, int). But they're typed differently: one is typed as Point and the other as Size. This makes it very annoying to write functions that are compatible with both. Let's say we write AddThenSquare(Point A, Point B) {
return new Point((A.X + B.X)*(A.X + B*X),
(A.Y + B.Y)*(A.Y + B.Y));
}
To make Size compatible with that function you need to either refactor your code so that both Point and Size adhere to the same interface, or alternatively implement conversion functions. The latter option is what C#'s .NET framework opts for where Point and Size are taken as parameters to each others constructors. But it doesn't scale. What happens when you use a third party math library with its own point implementation? Your number of conversion functions grow by n*(n-1) where n is the number of classes that need to be converted between. To be fair I think C# has technical reasons for not having an interface between Point and Size (structs don't play nicely with interfaces) but even if it was included it would still be a royal pain making sure all other math libraries adhered to the same one.In practice it's rare anyone will have the foresight to put interfaces everywhere they're needed, and it's even rarer that programmers will use the same interfaces across libraries. It begins to sound like the "specialization within functions that inhibits and penalizes casual cooperation" that Alan Perlis was talking about.
At some point you start to wonder why the compiler cares at all what the name of the data is if the underlying information is the same. You could have dodged the headache altogether if you were in Python where a point is a tuple (x, y).
Still I'm not convinced static typing is to blame... it's more that the kind of static typing employed by Java, C++, C# is especially rigid.
Then the sample is probably taken from internet dwellers who are interested in seeing how good their vocabulary is. I wonder if that's also why Paladin is so high up on that list.
I bet we'll produce a really interesting brain within the next ten years that doesn't seem human at all.