Excuses, Excuses...

I forgot (as I always do), how much I loathe a lot of standard libraries.

This time round, java got the better of me.

I am converting the BNFT tool from C++ (where I spent years creating libraries circumventing the standard libraries follies), but start again fighting with the java library.

I could name a hundred examples, but to some extent all of this also has to do with personal preferences. However, I hope to demonstrate my point with Dawn, if I ever get that BNFT tool working, so I can start some real work. Having been working in C# the last couple of months, shows me why some people prefer it over java. I have been cursing over it, but not to the extent of this experience. C# is not an option though, since I want to target the JVM for cross platform support (and MS/Windows specific source/executables are not really cool).

Ah, it helped to vent at bit, but I would hope that I can get done soon with it.

Reverse the power

The previous post was about what I hate, but it’s not very constructive to talk in negatives, and the obvious question would be "Well, what do you want to put instead then?".

I was pleased when I saw the override keyword in C#, because that illustrates the reversal of power. The user specifies that he intends to override a function, so the compiler can warn him of misspellings etc. Still the virtual keyword has to be present at the other side, so it’s not entirely rosy for my glasses.

Template/Generics is another place where power resides with the designer. The designer decides that you need to be able to utilize this code, for different types, but he decides entirely what can be changed.

Dawn allows the user to alter the lookup of names (read:types although dawn is prototyped). This allows the user to alter every type inside the black box of the API. Of course this is incredibly powerful and thus dangerous, but Dawn allows the change to be totally local, and the user should know that this is potentially dangerous. This is another point - I don’t mind languages have dirty/dangerous features, but you should be aware when you use them.

To sum up, reuse have failed insofar because power has been with the designer, not the user. Reversing this might lead to greater reuse.

The dictatorship of the designer

This is about why I hate exceptions and the private, protected, final, virtual keywords.

Obtaining reusability is a lot about creating API’s or code with great flexibility. If your design was great, your users will use it in ways you never imagined. But often the designer "knows what is best for you", and his or her design becomes inflexible.

The lauded information hiding principle is abused, so stuff not only are hidden (hidden stuff can usually be found) but generally unavailable because its private protected, final or not declared virtual. The sentiment behind these keywords is fine, but I would prefer they were hints to the compiler - so it could warn me if I violated them - BUT THAT I COULD VIOLATE THEM! Actually they should not even be hints, since they are a matter of convention, and conventions IMO should be tested for (unit testing), not built into the language (not unless testing is built in at least). Dawn does not have these keywords, although it will be possible to extend Dawn with them (but since such extensions are entirely local, I would be quite happy if someone made that extension - when Dawn has been published)

Exceptions are another side of this curse. They are not something you can choose to use. Unchecked or checked, they p*ss me off. Unchecked, because they in effect becomes c style null pointer exception bringing my program down, Checked because I have to rethrow them (at least often). Dealing with these API's, the first thing on my list is usually a wrapper that handles the exceptions, but gracefully encapsulates usage - maybe it does nothing, but it’s quiet. Exceptions are like Microsoft Dialog boxes, typically in your face and annoying and you can’t turn them off.

The last design issue is about types. The other day it dawned on me that types really just are a convention. Since Dawn is prototype based, it does not have types, but utilizes "duck typing" (if it walks like a duck and quacks like a duck then it is a duck), which in other words means that the interface to an object defines its type. And the interface is the convention. As stated earlier I want conventions tested, not part of the language itself.

Before I get flamed for all this, I must say that these ideas/realizations are somewhat intimidating to me, because my entire career has been spent in programming type strong languages. Dawn comes from a few basic thoughts about reuse, and I’m trying to follow them consequently to see where it leads me.

Return values considered harmful

One of the first really controversial realizations I had was that return values are bad. Don’t get me wrong, I utilize them hugely because current language's syntax gives a tremendous flexibility with the return value. However as other people besides me have noticed is that there is some problems when it comes to multiple return values. In order to do that you have to return struct’s and suddenly the syntactical elegance starts to vanish. Syntax sugar may mend this, but to me it does not solve the core of the problem.

My take? Return values are bad, because they reduce reusability. Well a rephrase or precision may be in place - functions are bad. A procedure can easily return a value trough a reference and this is the core of the argument: Designers choose to return values in many different ways - so users of API's (well - me) get annoyed about jumping through (different) hoops to use them.

Solution: abolish return values i.e. functions. Then add syntax sugar to re-introduce them.

This is another way of describing data flow programming. Alas usually dataflow programming takes elaborate graphical user interfaces. Dawn will try to allow dataflow programming to be specified in a somewhat understandable syntax, provide syntax sugar so programming can look like it does today, while still allowing for some graphical user interface to be built on top of the syntax.

Why blog?

I created this blog, so I would have a place to post my thoughts on programming, which I have found out are somewhat un-mainstreamish.

Much of the conventional wisdom I find to be off the point, and generally damaging to quality, productivity and the sheer joy of programming. People who have been sitting with me in offices throughout my career know that, on a daily basis, I curse programming language X, application Y and operating system Z. I curse, because ever since I started programming, I have had a clear vision about what can be done with programming, and alas X,Y and Z do little help me, they become obstacles.

Having dabbled into a lot of different fields, with a head overflowing from ideas, I have finally realized that I had to choose 1 of those ideas to run with. So Im running with creating a programming language for realization of all the other ideas.

The language is called Dawn, and I have set 2009 as deadline for its release - if it does not happen now, it never will.