As the things that I am working on are not KDE-related anymore (and Blogger.com now allows comments :), I have moved my english blog to tjansen.de.

I am watching the static vs dynamic typing wars with some curiosity. On the one hand, I can't
understand how to write any large application without the help of static typing. The lack of information
in the code, especially the imprecise and fuzzy specification of APIs, reduces the confidence
that my code will work in all situations. It also does not fit my usual coding style for large
programs and applications: I tend code for days, weeks or even months until I have a usable state,

I've been thinking about C's control statements (if, while, switch, for etc) for a little while, and I think there's some room for improvements in the later two...


switch

The C# guys have made two interesting modifications to C's switch statement: fall-through
is only allowed when there's no statement after the case (thus if a statement
follows a case, there must be a break or similar jump statement).
And it added the 'goto case' statement that can be used for

The most annoying thing when writing public APIs is that it's a lot of redundant typing. A good API implementation should check all arguments and return a useful error message if an argument is invalid. Good API documentation should document which arguments values are valid and which return values are possible. Both tasks are work-intensive and annoying for the developer, which is probably one of the reasons why there so many bad APIs.

I think the whole discussion can be simplified with three points that hopefully everyone can agree to:

Most functions do not need more than one return value, but when you need
more there's no easy way around it. Java has this problem, functions are limited to one return value, and in my experience it is often complicated
to get along with this limitation. In most cases you either write more
functions than necessary or you need to create a additional classes
that need even more constructors, accessor methods and documentation.


C++ and C# allow multiple return values using pointers and references. This solves the problem,

This time it started with a a thread on kde-core-devel:
I wrote about using classes for organizing functions and later wondered why I am using
static class methods - that's what C++ has namespaces for. I think the answer lies somewhere
between the way I am using namespaces and the way tools like Doxygen organize
the documentation. I am using namespaces in a Java-package-like way. They are a
coarse categorization for classes, with 5-50 classes per namespace. That's what I

My favorite Qt feature is the Signal/Slots mechanism. Before working with Qt I only knew the horrors of Java's event handling by implementing interfaces, and libraries that worked only with simple functions but not with class methods. Qt was the first library that allowed to handle an event in a method of a specific object instance - which is what you actually want most of the time. Unfortunately Qt Signal/Slots are not really well integrated into the language. This is mainly due to the preprocessor mechanism that works only on the declarations.

For a long time I have hoped that managed code will beat statically compiled code one day. Managed code can make software more secure, CPU-architecture-independent and makes it easier to generate executable code. The only remaining problem is the performance. Theoretically managed code should be faster than native code that the linker does not understand, because of the better optimization opportunities. But in practice and especially in public perception it always trailed behind.

1. DTDs and everything in the <!DOCTYPE> tag is horrible. The syntax is cryptic, the allowed types are odd and the degree of complexity is very high (parameter entity references!). RelaxNG and even XML Schema are much better solutions, and the XML specification could be reduced by at least 75%.
2. Entity references are not needed in a Unicode world (exceptions: the predefined entities and character references).