A Quantum Immortal

Last night I discovered this piece of code (simplified version):

private void Foo()
{
  bool b = false;
  new Thread((ThreadStart)delegate { b = true;}).Start();
  WaitForBool(b);
}

private void WaitForBool(bool b)
{
  while (!b)
  {
     Thread.Sleep(1000);
  }
}

I was immediately filled with disgust. How could someone write such a function (WaitForBool), which is one big bug? Of course the waiting will never be over, because bool is a value type, and no external influence can modify its value.

Later, I realized the fool is me.

I ran into this code a while back, and it did have a “ref” bool, which means it can be modified by the external thread. Resharper helpfully displayed a tip “this parameter can be declared as a value” , which I took without thinking too much about the consequences (I trust Resharper too much sometimes, it appears). So I deleted the “ref” with Resharper’s help and created the bug myself without noticing.

(As a side note, of course this method of waiting for a bool should never be used – use ManualResetEvent instead).

Update
Fixed in the next Resharper build (Resharper 4.0.1, build 913), within a few hours of reporting it. Cool.

Over here (and here is the Google cached version after the website fell because of the Slashdot effect). This article discusses why the language family of java,C, C# and C++ are here to stay, and won’t be replaced any time soon by new contenders such as Ruby and Haskell.

I agree. While as Eli likes to say, it’s important to know functional languages / paradigms, I really believe that most programming tasks should be done in either the C# or java flavors of Java# (A future hybrid of the Java and C#? It’s really sad IMO that two almost identical languages don’t join forces and user bases). C# is my current favorite, but I can see benefits to Java as well, not the least of which is the huge open community and plethora of available tools for Java. I do like the fact the functional programming is included in C# 3.0 and will be supported in Resharper 4.0 – a strong code analysis and refactoring tool is essential for developing and maintaining large projects.

To be fair, I’ll admit that most of my programming experience, and what I find most interesting, is classical server-side programming (that’s what I currently do in Delver). Also, besides a brief encounter with LISP and Prolog in university courses, I haven’t had the time/motivation to truly learn families outside of the C family tree.

What do you do when you want to read all the data from a Stream object in .NET? You use StreamReader.ReadToEnd().

Stream stream = ...;
StreamReader reader = new StreamReader(stream);
string data = reader.ReadToEnd();

Apparently there is no sane way to put a timeout on the above logic. If you call it and your stream doesn’t have a timeout, you’re doomed. Even if you stream has an internal timeout, you could still be doomed – for example, say you are reading from a website that sends you the letter ‘A’ every second. The timeout on the HttpResponseStream could be used, but still (assuming it’s higher than one second), you can’t set a timeout to the entire ReadToEnd() operation.

I wrote a small proxy class TimeoutStream that wraps any stream with a total timeout since the moment of its creation. Any blocking operation performed on it will fail if the stream has been created too far in the past.

I could use Asynchronous IO to sort of guarantee completion in this timeout without relying on a timeout on the stream itself – however, it appears to be impossible to do correctly in .NET – there is no good way to kill that IO operation if it does not complete within the allotted timeout (see here)- so far now this is good enough for our needs because we can indeed set a timeout on the HttpWebRequest object itself (in addition to using TimeoutStream).

The code is available here.

Today I took Eli’s challenge (whether he intended it as such or not not :).

Among other things, he mentioned on his blog his opinion that LISP is a more powerful programming language than C#. He offered Practical as an example of LISP’s power. Practical is a very simple database built using very few lines of codes.

The challenge I took on myself is to code Practical in C# and compare the implementation with the one given in LISP.

It took me 2-3 hours to read the link on Practical and code it in C#, and I wrote a great deal more lines of code than what I saw in the LISP code. So in a simple contest, C# (or just me as a coder) lost.

However, here are my thoughts:

1. About 80% of the code I wrote is general purpose. It simulates abilities already existing in LISP. General-purpose classes I wrote are:
   • ConsoleReader – Reading any class from the Console.
   • DefaultFormatter> and ListFormatter – Pretty-print any object or list.
   • Functors – Functors in C# are called delegates. I didn’t find (nor looked too hard) for functions to combine, negate and manipulate delegates – so I wrote some.
   • MoreXmlSerializer – As a naming convention, I like to name MoreFoo any class that contains methods that I believe should have been in Foo from the start, where Foo is some class supplied by the framework. Starting at C# 3.0, the ability to add methods to existing classes is supported, so I could adjust the naming convention accordingly.
   • StringConverter – Convert a string to to a given (dynamic) type.

   Besides this code, the actual Practical C# code is very small and concise.

2. The C# code is type safe. I’m not aware of type-safety in LISP, though as I said I’m not a LISP pro.
3. The code I wrote is in C# 2.0. Some new features in C# 3.0 should help make it a bit more concise (especially lambda expressions and LINQ).

I think this experiment didn’t change my opinion greatly. Yes, functional programming is good. It exists in C# as well as in LISP. Yes, LISP handles lists very well. But, not everything is life (or in programming) should be represented as a list.

I’m attaching my code here. If you have suggestions or comments, please let me know. Also, once I install Visual Studio 2008 (I’ll probably wait for the final release), I might try coding this in C# 3.0 and see how it helps the cause.