Yet Another Comment at C# 4.0

Yes, me too. I need to comment on this.

I was at first a little disappointed. All that buzz around the new dynamic type, and Spec# did not reach the podium...

Well, actually it did. They got the idea of implementing contracts in a language neutral manner, by rewriting the IL the compiler generated. Whoa. Now that is cool. It works with every language that targets .NET even your own DSL if you've written one. And the Pex utility that automagically finds input values that break your preconditions, kinda seems nice too...

That is an order of magnitude more useful than canadian ducks being able to Quack() and Walk() anywhere, eh!

Now, what will happen with .NET implementations of Eiffel and RemObjects Oxygene? Will they target the new Contracts framework?

A new start

A long time ago, I wrote a little utility to keep a historical record of all changes made to a source file. It was (and still is) called Synchrotron, and written in Delphi.

Now I've moved to a much more powerful version, always called Synchrontron, with so much more to it, and written in C#.

Maybe I should have managed to release it into production today...

Yet another example of Dynamic Typing abuse

In this example, they managed to break the test framework itself. You can't even be sure that your tests are actually running! That's a nice programming paradigm :-)

Dynamic Weenies are crazy !

I tried to understand the monkey-patch concept. I drove into that gem:

http://blog.nicksieger.com/articles/2008/03/14/monkey-patching-is-part-of-the-diy-culture

Excerpts (bold text is by my own decision) :

So, it took me a while before it occurred to me that something in my project might be overriding make_tmpname. But even after I found it, notified MenTaLguY, and he fixed it, it still left me wondering: who’s in the wrong here? Akira-san, for not making a better way to hook into make_tmpname, Rick for monkey-patching it, or MenTaLguY for changing the method arity in his rewrite? I can’t really point the blame at any of them.

There are certainly more egregious and offensive monkey-patches than this example (and I include myself in that camp). In any case though, I could live with just about any monkey-patch if I had better debugging tools. For example, it would be great if you could ask Ruby to track and retain references to all methods, including those that get replaced, along with the source locations where each was defined. Another possibility might be a before_method_added hook that could let you track method replacements as they’re about to happen (and maybe even veto method redefinitions!).

Yeah, and why not veto the veto, and allowing some other code to veto that also :-)

You can't point the blame? The blame is to consider monkey patching a valid programming practice! If you want to be able to veto method definition, or need debugging methods to track the changes, maybe there is something wrong with the concept...

Think of it: he even considers that the guy who changed a private method could be the one to blame :-)

Incredible! Everyone with common sense agrees that statefulness is evil, and these guys try to add yet more state to try to control the state. And we have to trust them to build secure software?

I'm not that much against dynamic typing, you know

By reading my posts you may think that I'm against dynamic typing. I am not. I am just (very) unconvinced by its promises. Dynamic typing is not the next big thing. It is just a brand new way of making the same old mistakes. Tenfold.

One of these mistakes it to believe that building computer programs is - or at least should be - a simple task. It is not. It requires deep understanding of the problem at hand. In turn, this requires to build an abstract model of the reality, and implement this abstraction. There is no reason that building a computer program should be significantly simpler than building a bridge. You may throw a little amount of plywood to allow you to cross the stream at the back of your house, but to build the Golden Gate Bridge, you do not simply assemble iron bars and test along the way that they still support your weight.

What I don't like is the way the dynamic typing zealots - which are probably in their very early twenties - are pushing their toy, and calling everybody else dinosaurs, afraid of change, blocked in their ivory towers.

Dynamic typing has intrinsic weaknesses. Weaknesses that computer science has tried hard to eradicate, and we the dinosaurs are now witnessing their resurgence as they are hyped as the new great leap forward. Yes we are afraid that we'll have to deal again with self-modifying code. Yes we are afraid that duck typing is yet another way of reliving the glorious days of DLL hell.

We will never agree

From another post :

In Ruby I can write this:

10.times { i puts i }

But in C# I have to write this:

for (int i = 0; i < 10; i++)
{
Console.Write (i);
}

Which do you find more beautiful? :-)

Actually, I strongly prefer the C# version. Not because it is more beautiful, but because it is more descriptive. How do I know whether "10.times" will count from 0 to 9 or from 1 to 10? Or from 412 to 421? How do I know that it will count upwards ? Or backwards? Or randomly?

And anyway...

10.Times (i => Console.Write(i) )

:-)))

Statefulness considered harmful... again :-)

Serious programmers keep telling you ... again and again. Dynamic weenies keep not wanting to hear ... again and again.

http://kurt.karmalab.org/articles/2008/04/24/monkey-patching-core-classes-bad

"the first thing that happened was that 20 completely unrelated specs broke"


---


"This, in turn, snuck into our codebase in all sorts of little unexpected places."

Having the possibility to modify any behaviour of any object at runtime (monkey patching) is the silliest idea since trying to manufacture nitroglycerin in a rollercoaster. Whether it is a core class or not is irrelevant, it is still a stupid idea. Modifying a method in a class is the same as the nice Cobol feature ALTER PARAGRAPH TO PROCEED TO.

Thank you again for these few minutes of irrepressible laugh :-)

Yet another silly debugging session

var RantLevel : integer;

begin
RantLevel := MaxInt;
end.

I again lost a few hours today, tracking the silliest problems of them all. A problem that is so easy to get rid of, once you stop listening to all the hype.

One of the forms (in Delphi 7) does not load. Cannot find the class implementing a component... Works on my development machine, breaks on the build server. Why? Oh why? ... Depending on the order in which your units are loaded in the EXE file, the class gets registered on time, ... or not.

Solutions to this? Soooo simple. In Java and (until recently) in C# / .Net you do not rely on dynamic retrieval of classes. Your forms are created by actual code that gets compiled when you build your application. Yes, you heard correctly: static checking by the compiler; does not find all bugs; just avoids losing hours on silly things. Now of course the hype is to remove this life saver, and replace that by XAML. Unfortunately one day or another I will no longer have the choice, and I will have to use it :-(

Don't you ever learn? As you may know, there are two main classes of bugs. The ones that are due to a bad algorithm, locally; an array index that is off by one. And there are those bugs that are due to a bad state left by some code that triggers problems in another part of the program; a variable does not get initialized, or contains a string when it should contain an integer.

The latter are an order of magnitude harder to track down. Statefulness considered harmful...

Adding statfulness adds comfortable nesting places for the nastiest bugs. Having types being dynamically changed (eg by having type definitions be executable statements like in Python) adds statefulness where there was none previously.

Python definitely beats them all

Whoa, I tried to write some Python code today (trying that nice Google App Engine, of course.)

Guess what... After three typed lines I managed to hit the first wall of laughability. My code does not compile (oh you may want to say "parse", I don't care) and that was because...

because some "unexpected indentation".

Indeed... there were blank lines at the end of the file, and those blank lines were actually not blank, but full of spaces. How do you distinguish an empty line from a line with only spaces? The funny thing is ... you don't :-)

The sad thing is that some people still believe that Python is a valid programming language :-(

Too much stress, lately :-)

I don't know how I did that, but I managed to write... this piece of code :

procedure TEditTestDefSimpleForm.ClearNotesGrid;
end;
  NotesGridTableView.DataController.SelectAll;
  NotesGridTableView.DataController.DeleteSelection;
begin

It does not compile ...

More wasted time today

This week, I spent (read: wasted) a lot of time.

1. Some database did not have a foreign key constraint, and a user removed some data that was referenced elsewhere.
2. Some customer managed to call a function, passing an object that had just the appropriate method names, but was definitely not the appropriate object.
3. I needed to map object properties to fields in a CSV file. By name.

Why? Again because the constraints are not at the right place. When you remove data from a database, some other place that relies on that data to be present will fail. It will fail much after the original cause. And that's where you lose all your time, trying to get back in time from the error message to the actual event.

Dynamic typing is like doing that all the time. You do not get an error message when you call a method with the inappropriate arguments. It may be some totally unrelated piece of code that fails.

Now, you might say, my database was not very well tested. That is true, it's entirely my fault that the integrity constraint was not there. Or was it? The constraint can be removed at any time, by anyone. I do not have a guarantee that my constraint is still there in production code. Welcome to dynamic programming!

Not for me, thank you.

Silliest pro dynamic typing argument to date

According to this paper (see in particular section 2.3) race conditions in multithreaded programs occur because of static typing. Dynamically typed systems are a cure for this, of course :-)

Section 2.2, we learn that having your method either handle exception RMIException, or statically declare it in its throws clause, leads to an abstraction leak. Does he realize that RMIException derives from RuntimeException, and as such does not need to be listed in the throws clause?

This, and many other hilarious fallacies (mainly if you tell the compiler that class A implements interface B, then you should be allowed to code only the part of B that you care to implement kind of stuff) makes for a good laugh.

By Grabthar's hammer, do dynamic weenies have any clue what they are talking about?

Unfortunately, this nonsense seems to emanate from a guy having some position (janitor apparently) in a known university, and presented in the standard format for academic papers, and so will be touted by Rubyist as academic proof of soundness for their beloved concepts.

Why Java programmers are afraid of dynamic typing

Read the Ruby blogs. All hardcode Java programmers are described as being "afraid" of moving to dynamic typing. One post goes as far as saying that Java programmers feel that static typing gives them a sense of security, because they fear that their fellow Java programmers are idiots.

The article is right, but for the wrong reasons. Now I know why Java programmers are afraid of moving to dynamic typing: as long as their programs use static typing, they can rest assured that no Rubyist will join their team and make the same old mistakes in a brand new way :-)

Types as automated tests of your design

Apparently, I praised the concept of blessed interface.

No, I'm not. I'm just saying that if you rely on an interface, then explicitly define that interface instead of letting it magically appear from your coding. No, you should not predefine your interface and stick to it whatever the cost. Yes, during the development phase, the interface will evolve until it contains what you need.

But when this is done, you have defined an expected behavior. You have successfully built an abstraction. Congratulations.

Now, imagine you have trouble defining that abstraction, because you keep adding to it, or you can't possibly find a way to express what you want. Congratulations again. You have found a flaw. Do you think you've found a flaw in the concept of static typing? Think again. You have probably found a flaw in the way you try to model the problem space. You are probably writing code that is expecting too much of the object it receives.

One guy complained that once he created the concept of Ball and added a radius to it, there was no easy way of defining a rugby ball, because it was not spherical, and thus radius had no meaning. He - of course :-) - blamed static typing for his own mistake of making all balls in the world round.

Static typing requires you to think in order to find appropriate abstractions. If you can't find them, or need them to change constantly, you have an incomplete - or plain wrong - idea of the reality you try to model. Types allow you to test your design against reality. Yes, your design will be better if you use properly designed interfaces, it will relate to problem space. Yes, it is worth the cost, because this interface is no less than an automated test against your comprehension of the problem.

The conclusion indicates where you stopped thinking

In a technical article, the conclusion usually indicates where you became tired of thinking, and want to leave the rest to the reader.

When doing analysis, I need to recognize behaviour in objects. In design, the type I give to my objects is the conclusion I reach. Programmers tend to favor duck typing because it allows them to skip the part where they have to build and recognize abstractions, and they can simply implement all needed objects without actually giving them a type.

When using duck typing, if an object implements walk() and quack() they can treat it like a duck, but they do not have to define exactly what a duck is, nor do they have to explicitly recognize duck behaviour in their objects. More precisely, they longer need to reflect the is-a hierarchy using types, but simply a behaves-mostly-like hierarchy using classes. This is of course much simpler to design, as they may throw theoretical issues (like the Liskov Substituion Principle) out of the equation.

When using static typing, I have to recognize up front that my function requires duck-like behaviour, I have to precisely define what duck-like behaviour means (that is define a type, not a class, in the form of a DuckInterface) and identify precisely which classes in my hierarchy exhibit duck-likle behaviour (and make them implement the DuckInterface.)

Static typing does not limit my expressiveness. It merely forces me to think about what I'm saying before I actually say it. It means that I have to carefully identify the abstractions and design the corresponding interfaces. It means that I have to recognize the difference between subtyping and subclassing.

I am reasonably good at building and recognizing abstractions, and that is why I don't usually need duck typing. If you are not good at handling abstractions, then you will find that duck typing greatly simplifies your work. Consider it the "lite" version of object oriented analysis and design. You do not define types, you just let the reader discover them.


However, the lack of clearly defined types has its price: interfaces are the building blocks of loose coupling, so you need to design them anyway. In duck typing, interfaces will tend to emerge from the code instead of the analysis; this might not be the best way, as you usually end up with ad-hoc types instead of carefully thought ones.

From the master himself

I know it's a long time ago, but in an interview with Bill Venners, on November 17, 2003, the master Yukihiro Matsumoto himself said:

So for day-to-day programs that aren't not as serious as enterprise systems, you don't have to be as robust. It's not worth the cost of declaring types, for example.

So he agrees: declaring types has a cost, but it adds robustness.

http://www.artima.com/intv/tuesday3.html

Dynamic typing, the keyboard and the mouse

Dynamic typing proponents like to think that way: type errors are not frequent. It is therefore best to have a language that allows you to plug any object anywhere, and write tests that ensure your program is doing what it should, instead of restricting your choices in the first place.

Using a dynamic language is therefore like not-so-long time ago computers that had exactly the same plug for the keyboard and the mouse. At startup, if you plugged the mouse in the keyboard socket and vice versa, your computer did not emit blue smoke but it did not work either, and you had to unplug and swap the cables.

This was not user friendly. Dynamic languages are not user (where the user is the other programmer that has to use your object) friendly.

Yet another attempt at publishing my code

I registered an open source project on Google Code today. This is the n-th attempt at publising my source code reliably.

I tried SourceForge (a long time ago) and was never able to use it properly. Either you need a complicated set of tools to do SSL tunnelling (just in case someone impersonates your connection; hint: I don't care if FTP is not as secure as it should be.)

Next I tried to enable Subversion on SourceForge. Never worked.

Then I switched to GotDotNet. The source control client never worked properly. And the site was shut down shortly afterwards.

Then I gave a try to CodePlex. I was happy with that one. It had (almost) all I dreamed of. Except of course a reliable backup, so a guy hit the wrong switch and whoosh all my data was gone. This disagreement led Microsoft to discover that their backup procedure was sub-optimal (i.e. the backup could not be restored :-) Not only mine, by the way. Dozens of projects were gone for good.

Now I am willing to try again... Oh but I miss some of the CodePlex features though. Anyway, let's hope it will work this time.

http://flimbase.googlecode.com

What's in a title

Welcome to my coding blog. This is where I will rant about the features I miss in my usual programming languages, make fun of other people's errors, and sometimes say something sensible about programming. Expect topics about why I like multiple inheritance and static typing.

Now. Where does that silly title come from? From a book I owned a long time ago, titled Microsoft Basic Decoded & Other Mysteries for the TRS-80. This book contained the entire disassembly of the TRS-80 Model I, Level II Rom. It used a clever technique to avoid copyright problems. I think you can still order it... from Russia: http://www.urss.ru/cgi-bin/db.pl?cp=&page=Book&id=18425&lang=en&blang=en&list=319