I just bought a PSP, partly because there are finally enough games (at least 10) to justify it, and because it by default does most of the things I wish the DS could do, to wit: browse the web, read text files and play old games. Well, by default, only old PSX games, and only like 10 in the US, but still.

OK, I’m lying. The real reason is that there are a couple of Metal Gear games and you can download Parappa the Rapper (and I think Umjammer Lammy if you are willing to sign up for a Japanese PSN account and import Japanese gift cards). The web browser is decent, though; the PSP has about as much memory as the Wii*, and you can turn off Flash, in which case the browser is about as fast as Opera on the Wii.

Alas, there is a totally dead pixel on the screen. I’m not sure what to do about it; the Internet at large seems to say that Sony is not replacing PSPs over dead pixels and that they suggest “you’ll just get used to it", especially for games. Maybe so, but it’s still kind of annoying when reading web pages. Has anybody out there gotten a PSP with a dead pixel? What did you do? Did Sony replace it if you asked?

*The Wii has 64 MB main memory and 24 MB of graphics RAM. The PSP has 64 MB main RAM, but I can’t find a reliable number for graphics RAM.

Eric Lippert, who works on the C# compiler, points out a corner case in (what else) overload resolution in the presence of ambiguous type/value names. If you have a type Color and you name a method or property Color, funny things will happen if you then call Color.Method().

I have a number of snappy comebacks and perfunctory solutions to this, none of which really help C#, since it’s locked into looking like Java and C++, syntactically at least.

Snappy comeback

Don’t even allow different meanings for identical names. Lisp-1 is far more usable. Every name is bound to one thing only.

Unfortunately, anything with a multi-pass compiler poses a strong temptation to break away from this rule. If you just have a single pass, it’s a lot more natural.

Perfunctory solution

Get rid of the Pascal-style initial-capital CamelCase for public members. The public/private distinction isn’t as important as the type/value distinction**. Now, require types to have an initial capital (class Class : Object) and values to have an initial lowercase (Class object = null;). Methods can do whatever, but lowercase would be better :) While only a few languages require initial capitals for types (Ruby and Haskell that I know of), most languages use this convention.

Both the snappy comeback and perfunctory solution would require major changes to C#. But they are so right.
**At least to a functional programmer who doesn’t do much OO. Speaking of which, ad-hoc overloading is kind of a dumb idea too–it feels like it got left in Java just because of primitives, and then was copied into C#.

Speaking of C#, that reminds me of Python iterators. (This will (I hope) be the last I talk about them for a while.)

The problem is not that I want Python iterators to be lazy lists. I’m fine with imperative iteration in an imperative language. It’s not even a *huge* problem that iterators are promoted in Python 3.0 as a common replacement for lists. The big problem is that many other languages make one simple change–returning iterables by default–that makes the whole thing much more user-friendly. Why didn’t Python adopt this style? It makes the default case (use-once) just as efficient as bare iterators, but protects users if they keep a reference to an iterable and iterate over it twice. Multiple iteration is safe as long as the iterator doesn’t make destructive changes, which most do not (pipes are a good counter-example).

Even worse, some of the new list removals in Python 3.0 DO return iterables instead of iterators. Specifically, dict.values and dict.keys. That’s because Guido expects you to use dict.keys in set operations, so they are custom iterables with efficient set operations. But something like map directly returns an iterator. … INCONSISTENT.