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,
without executing the code even once. I RELY on the compiler's ability to find all typos during that time.


On the other hand, I see that there are many people who prefer dynamic languages. Most of them have
a write-a-little/test-a-little style, which I know from writing JSPs, so I can understand the style
at least somewhat.

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...

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:

1. In the next 12-24 months the only way to get a somewhat competitive desktop is to pile up code from all sources, including kde and gnome, and try to integrate them somehow

2. If you think about the architecture of a desktop in 5-10 years, this mixture of pure C code, Gnome/Glib C code, KDE C++ code, Python, Bash scripts, maybe Mono C# code etc, all with different API conventions and wrapped by various wrapping mechanisms, all that sounds like a horrible nightmare that no one really wants
3. Whether you like freedesktop.org or not depends on whether you want to have a usable desktop soon (thus today's desktop has a high priority for you and the future a low priority), or whether your goal is to have the best desktop at some point in the future (future: high priority, today: low priority)

Make your choice.

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,
but I think it feels wrong and especially the C++ syntax does not
create very readable code. So I am going to show you an alternative, derived
from Python's tuples. But first the existing syntax variants and their
disadvantages:

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
am used to from Java, and it makes a lot of sense for classes. It would be possible
to collect functions in namespaces instead of classes, but then you would have to
browse through both the classes and the namespaces in Doxygen-generated documentation.
Having two kinds of categorization is just too much, it makes documentation too hard to read and code too hard to find.

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.

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).
3. Processing instructions are an odd and unstructured mechanism for meta-data about the XML and should not be needed anymore, because namespace'd elements and attributes could achieve the same.
4. CData sections may be somewhat useful when writing code by hand, but that does not compensate for the complexity that they add to document trees - without them there would be only one type of text.
5. Different char sets. There's no real need to allow different charsets in XML, it just hurts interoperability. It should be at least restricted to the three UTF encodings, maybe even only one of them. Allowing charsets like 'latin1' is useless if processors are not required to support them.
6. The lack of rules for whitespace handling. Actually there would be a very simple and sane rule for whitespace handling (always return whitespace unless a element contains only elements and does not have xml:space="preserved" set), but the specs require the XML processor to return even the useless whitespace.
7. The XML specification should set up rules that specify how to handle namespace'd elements and attributes that are not supported by the application. Right now the schema defines how to handle them and the application will not get any support by the XML processor. Ideally the application should tell the XML parser which namespaces it supports, and the XML specification should define what the XML parser does with the rest.
8. xml:lang is pretty useless without more rules for the XML processor. It would make sense if the XML parser could somehow only deliver text in the desired language to the application, but without any useful function it just bloats the specification.
9. XML Namespaces are probably the greatest invention in XML history, but they should be in the core specification. Otherwise the APIs are splitted into namespace-aware functions and those that ignore them. The main problem is that the ':' character has no special meaning in the core specification, so you can have well-formed XML with undefined prefixes, several colons in a single name and so on...
10. XML Schema should be deprecated in favour of RelaxNG. I haven't seen a single person who would claim that XML Schema is better. People just use it because of the W3C label.