I completely failed to explain to a group why I think C# 3.0’s pile of features are a poor design. Somehow people keep missing my point. Can you believe English is my first language? If anyone is reading this post, please tell me if this makes any sense to you.

Imagine how Anders, head of the C# design team, might think about the next version of C#. Ten different groups within MS propose 10 brilliant features to add to C# 4.0. Things like pattern matching, concurrency, transactional memory, assertions, categories, etc. Big, complicated, cool features. How does he decide which one to implement? Anders would think long and hard about which feature will have the biggest impact. He’ll choose 1 or 2 and the rest will get shot down. C# 4.0 introduces a few big new features, and this process repeats itself for version 5.0.

If I were running the C# team, I would resist adding any features to C# for fear of feature creep. Instead, I would tell all 10 groups to implement their features as libraries. They will grumble and complain, then they will build a prototype using some insane hackery to get around some limitations in C# and the CLR. I would study those gross hacks, not the features themselves, because that’s where they ran into a roadblock with the language. The goal of language design is to reduce the number of gross hacks needed to implement complex libraries. Because if I can fix C# so these guys can implement their 10 great features as libraries more easily, then I’ve magically enabled hundreds of groups outside MS to also implement their very complex features.

The changes I envision making to C# would be much more subtle than a giant feature like LINQ. I would tinker with some dynamic typing features, better integration with code generation tools, and maybe a way to use attributes within the body of a method (i.e. a parallel loop declaration above a foreach stmt). Small, subtle changes that would have wide impact on library writers, but not most programmers. I’m against adding feature X. Instead, I want to change C# so you can write feature X as a library. Does this make sense?

IE vs. Safari Javascript test

September 7, 2007

I rant this Javascript performance test in both IE 7 and Safari 3 for Windows. IE tooks 3454 ms, whereas Safari took 219 ms. The exact numbers don’t matter, it’s the magnitude of the difference that is shocking. Why is IE so insanely slow?

iPhone Review

September 4, 2007

My gal got an iPhone, which means I’ve been playing with it nonstop and she’s been begging to use it. The iPhone is fantastic. It is insanely great. For the record, I’m not an Apple fanboy. The only Apple product I own is a 1st gen iPod I got as a gift. So here are the few things that are less than perfect with the iPhone:

Read the rest of this entry »

I watched Linus Torvalds rant on Git and distributed source control management (SCM). First of all, Torvalds is a hard-core jerk. He is stunningly obnoxious and egotistical; the very embodiment of the poorly socialized nerd stereotype. As for the talk, he takes a lot of credit for some fairly well known ideas (much like Linux OS).

Read the rest of this entry »

The primary benefit of static type checking is that a compiler can catch a wide variety of bugs at compile-time. With dynamic languages, on the other hand, some bugs aren’t revealed until they actually blow up in your code. Between run-time and compile-time, however, there exists “binding-time”. This is when you actually load all the libraries you are using into a runtime to begin execution. It might be useful to delay type checking until this point to allow runtime manipulation of modules and environments. I can generate code and interfaces at binding-time, then run the type checker and report errors. This gives you most of the flexibility of dynamic code, but preserves most of the safety of statically typed code. You won’t discover the error until you load everything into a runtime. I know of some early static checking tools for C that did this, but I don’t know of any statically typed languages that move checking to this phase of development.

Inventing a new PL

August 21, 2007

I’d like to implement a new programming language for my personal use. Here are some qualities I’m interested in:

  • small: It should be as small as possible, like lambda calculus.
  • extensible: All syntactic sugar added here. Also, must support compiler extensions.
  • concurrent: need abstract notion of concurrency built in.
  • typed: static is better than dynamic typing, but it should support both.
  • lazy: the implementation can still be strict, but lazy gives more freedom to programmers
  • modules: need a simple, yet reflective, module system.
  • FFI: should be able to easily access foreign code, preferably C-like.

It seems like I could build my language on top of Clean. I’ll try writing some programs in Clean first.

Two security experts described some ways to improve voting machines. In designing a secure voting machine, the central assumption should be that the machines will be hacked. Therefore, it’s foolish to rely on one machine from one company. Instead, as these guys describe, one machine should generate a machine-readable paper record of the vote that can be verified by the voter and scanned in by another machine. A voting site might have a dozen voting machines and 1 optical scanner. It’s still possible to hack the optical scanner to manipulate votes. So I propose that each voting machine map the candidate names to a set of random numbers: (Machine1 Bush 8204). Every machine is different. After voting, the receipt will say you voted for Bush, but the optical scanner will read in the number 8204 (and 2947 from machine 2, 1695 from machine 3, etc.). The scanner tabulates the number of votes for 8204, but it has no idea what that means. Therefore, a hacker wouldn’t be able to manipulate votes because he doesn’t know what these numbers represent. The scanner sends these random numbers to the central computer. Again, the central computer has no idea what these numbers represent. Finally, the voting machines send their mappings and votes to another central computer. Now the central computers can map (8204 -> Bush) to determine the final tally and verify it against each voting machines records. The central computer can send a report back to each voting station for poll workers to manually verify the total against the voting machines’ numbers.

How can a hacker defeat this system? If he hacks the optical scanner or the first central computer, he’ll only see a bunch of meaningless random numbers. If he hacks the second central computer (the one that gets the mappings and votes), he can’t do anything because the results must match the first central computer. If he hacks both central computers, he still can’t do much because the numbers will be double-checked against the voting machines. If he hacks all the voting machines, he could assign Bush’s number to Gore; therefore, the voter see “Gore” on his paper ballot, but optical scanner reads Bush’s number. However, the poll workers can spot check the numbers to ensure they are different. This seems like a decent solution, though it’s rather complicated. It needs to be simplified because poll workers are fairly dumb. You can’t rely on them to do anything right, especially when there are several independent steps. Nevertheless, I don’t think it’s difficult to build a secure electronic voting system. It would certainly be different from the one we’ve got today.