Tjansen 

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 think I found a very simple concept to allow dynamic typing in a Java-like statically typed language. The following examples are based on Java, but with two additional features: Read More

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 fall-through effects. Here's a C# snippet: Read More

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. Here is a Java snippet with Sun-style argument handling: Read More

I think the whole discussion can be simplified with three points that hopefully everyone can agree to: 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 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 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: Read More

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. The C++ syntax does not really help you with organizing your code or reading other people's code, especially if you are not using an IDE. It's hard to find out in which file a symbol is declared, and even more difficult to find out where it is implemented. Functions and global variables are the worst, unlike classes they usually do not have their own header. Avoiding these problems requires quite a lot of discipline, you need to keep a consistent naming scheme for all files. This does not help when you work with someone else's sources though. Another part of C++ that I don't like is the separation of declarations/headers and implementation. I hate typing more than necessary, syncing headers with the implementation can be annoying and the stupid #ifdef protectors that you need to write in every header are just braindead. Two features in Java that work really well are packages and the source file layout. When you have a class My.Library.Helper you are required to write both implementation and declaration into a file My/Library/Helper.java. This makes it easy to locate the implementation. As everything in Java is in a class there are no problems with locating functions. They are static methods and can only be invoked by specifying the class name (e.g. Math.round()). This is annoying to type, but makes reading someone else's source code much easier. Unfortunately Sun recommends to use a reverse DNS name as package name, and when you follow it you will have to hide your source code somewhere in a deep directory hierarchy. Unless you are writing a library I would suggest you to ignore Sun's advice and use a short one-step package name. Read More

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. Thus the declaration syntax is fine, but the use of signals and slots in the definition has some problems and limitations: Read More

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. The benchmarks published by OSNews suggest that, at least in the commercial space, managed code is already competitive and can beat unmanaged C code. The nice thing about the OSN article is that it's probably the first time that someone was so (stupid|brave) to violate Microsoft's licensing agreement and publish benchmarks for C# - but even Java did very well against gcc. Read More

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%. Entity references are not needed in a Unicode world (exceptions: the predefined entities and character references). 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. 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. 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. 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. 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. 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. 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... 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.

Since I wrote the last entry about properties, the comments and Groovy changed my mind about the property syntax: I think the accessor method syntax that panzi proposed is much better than my Java-like syntax or the C# syntax. If the language uses the 'virtual' keyword for virtual methods, virtual properties (properties without associated member field) can not use 'virtual' as a keyword. Otherwise it would not be possible to override the accessors in a sub-class. But the keyword is not needed anyway, because the new accessor syntax can unambigously define a property. You just need to write one or both accessor methods. For the API documentation only one accessor method must be documented, and it should be documented like a field (and not like a function) Groovy has the simple and effective idea that all public field members are properties. This removes the need for the 'property' keyword and also the difference between properties and fields. Just add a regular member, and it is accessed using auto-generated accessor methods, that can be overwritten by you There's one drawback when properties are accessed like field-members: you can't control anymore whether you access the field directly, or using the accessor methods. This can only be avoided with a syntax extension, and I think the least painful is the following: a method can access the raw field member of the object class without the accessor methods by prefixng the name with a '@'. It is not allowed to use this kind of access for other instances or classes (thus only '@field' is allowed, but never 'ref.@field'). In order to prevent errors, the accessors must not call themselves and thus the attempt to read the field without '@' would cause a compilation error. Here is the example class with these changes: class SubString { private int mEndIndex; /// Documentation! public int beginIndex; /// Documentation! public int length.get() const { return mEndIndex - @beginIndex; } public void length.set(int value) { mEndIndex = value + @beginIndex; } </pr Read More

I do not know much about Eiffel (and I can't stand its Pascal-like syntax...), but the Eiffel feature that I like is design by contract. Design by contract means that function interfaces, the APIs, are seen as a contract between the creator and the user. In most languages this contract is mostly written down in the documentation. Eiffel has them written in the source code. It is also possible to do this in a language like Java, but Java's syntax needs a small modification to make this really comfortable. Let's take this function as an example: Read More

One of my favorite C++ features is resource management with stack-allocated objects. It can hardly get more convenient than writing { QMutexLocker m(myMutex); } Read More

Today I realized that the property syntax of in all C-based languages sucks. Lets a assume a very simple class called 'SubString' that describes a fragment of a string and has two properties: its length and the index of the first character of the string. The class implementation has two field members, one containing the first character's index, and the other the index of the first character after the string. One problem is that there is no field member corresponding to the second property. This is what I call a virtual property. In this simple example there is no real reason for having a virtual property, but in reality this happens quite frequently when you want to expose a value of an aggregated object. Let's try to implement this in Qt/C++, Java and C#. Read More

In recent days I made the following thought experiment: how can XML processing be made easier by integrating XML support into a Java/C#-like programming language. I created the code snippet below to try out what such a language could look like. The syntax of this theoretical language: Read More

During the last years I encountered a number of problems in the Linux platform's architecture that cause problems for GUIs on top of it. When I say 'the Linux platform', I refer to the Linux kernel, glibc and the common GNU and Linux tools, but not X11. I also ignore distribution-specific solutions for the problems. In general the lack of a tool is not a real problem for me, it just is some work that needs to be done. I am talking about the architecture, problems that can not be solved without incompatibilities or at least a lot of work. A 'modern GUI-based OS' is, for me, a OS that does not require a user to know or use a command line tool, even for rare system-administration tasks. That does not mean that it should be impossible to work with the command line and a text editor, but the command line must not be the only way to do an administration task. So here is the (incomplete) list: Read More

In the last two weeks servers of Debian, Savannah and Gentoo have been compromised, as you probably noticed. And they won't be the last ones. Many people brag about the security of free software, but I have never seen a single technical reason why free server systems should be more secure. The only reason why there are fewer worms is that there's more fragmentation and the users are more experienced. It's easier for a worm to spread when 50% of the Internet's computer are binary compatible rather than only 0.1%. But when an attacker wants to attack a specific server, a Linux or OpenBSD server is not more secure than a Windows or MacOS server. This year there were exploits in the Linux kernel, Apache, OpenSSL, thttpd, MySQL, Samba, CVS, OpenLDAP, ProFTPd, Sendmail, PostgreSQL, Kerberos, rsync, CUPS, lsh and OpenSSH. Most of these exploits can be used by an attacker even without having an account on the server. In other words, you will hardly find a single server that has not been vulnerable for some time this year. Even worse, it's highly unlikely that those were the last exploits to be found, so you are still vulnerable after patching them. It's just a matter of time until an attacker finds the exploits. Read More

The main problem is to find out what users want. Did you know whether users will like Expose or they will use KXmlRpc before they have been implemented? I don't think so. Did users ask for Expose? Unlikely. Can we know whether WinFS's way of searching files with meta-data queries will replace today's file systems? No. All I know is that it sounds useful, and that if it is a success KDE will look pretty outdated with its file dialogs. Read More

OSNews has a poll and discussion about integrating Mono into Gnome. As KDE may face a similar decision at some point in the future - what to do when KDE's technology is not competitive anymore - I thought i write my thoughts down in my blog instead of the OSNews forum. In the last weeks I have spent a lot of time on taking a close look on .Net and Longhorn, and I think it is quite nice. Certainly not perfect, and there are many things that I would have done differently, but it seems to contain less brain damage than Java. They certainly took a good look at Java and fixed its problems and shortcoming while designing C# and the .Net APIs. Assuming that the Mono guys can complete the .Net clone and its GTK integration and get it stable, Mono+Gnome would be a development platform that's much more powerful than the current Gnome, and for applications that can make use of the .Net platform's advanced features (like their XML, SQL and Remoting support) also better than today's KDE. Mono will be also able to make use of libraries, both free and propritary, that have been written for Microsoft's platform. Developers who are used to .Net will feel home on Gnome. And books written for .Net will also help Gnome developers. I still think that it is a bad idea. Why? A cloned framework puts innovation in Microsoft's hand. You still have the chance to write better applications, but the innovation of the platform will always trail behind. What advantage does free software have when its innovation is limited to that of its competition? Sure, cloning gives developers a common goal, similar to Linux's original goal of cloning a Unix-kernel. And Linux has been very successful in replacing Unix. But the .Net situation is different. Unlike Unix, Windows and .Net are under active development. Microsoft recently announced massive improvements to .Net, and it is likely that this will continue. Linux has two advantages over Unix: it is free and it is better. Mono will just be a free clone that trails at least a year behind. And that will also be the public perception, Mono will look like a cheap imitation and not the real thing. Even if the original may be so good that an imitation is still nice, it's like saying "Hey, we aren't capable to produce something better than Microsoft, so just clone their work". For some people this may be fine, but it is certainly not a plan for world domination. Mono could, of course, try to add additional APIs to .Net. GTK# is an example for this, since it is a replacement for Winforms and certainly better than the original in many ways. But as these new components are also free software (assuming they are under LGPL or BSD, like Mono) all improvements to Mono will also be available for the proprietary .Net. So by adding new components you can't make Mono better than .Net, you will always improve both. Maybe it comes down to the question: why are you working on free software? If you only do it because hacking some code is fun, the Mono solution is ok for you. If you do it because you want to create a free alternative to proprietary software, Mono is a fine solution as well. But I do it because I want to create better software. Hopefully so much better that in the future the world's information flow is not solely controlled by companies whose main interest is increasing shareholder value. Being free is an important aspect for software, but being technically better is not less important for archieving this goal. And Mono is no solution for that. Read More

Today news sites repeated the monthly Microsoft execute says "Linux is insecure" articles. And while they are comparing apples with oranges (as Linux distributions ship with far more servers and network services than Microsoft offers), it's hard to deny the fact that Linux is also insecure. Essential and security critical packages like OpenSSH, LSH and OpenSSL had exploits in the last weeks and this should have convinced the last conservatives that it is not possible to write a complex server in C without having a remote exploit per year. All these exploits were caused by manual memory management that is relatively hard to avoid in C. But that's not even the point that I want to make, you can also have security problems in other languages. What free software (and also the proprietary competition mostly) lacks is a way to make securing your computer easy. Read More

I hope this becomes a loose series of various things that I would like to change for KDE 4.0. The code may appear in kdenonbeta/kdeutil where I keep utility classes for the KDE namespace. Read More

Seth Nickell wrote a blog entry about the relation between Gnome and KDE. The short summary is that Gnome and KDE are just two flavours of the free desktop(.org) that are technically too different to be merged, but work toward a common higher goal and should thus share as much components and standards as possible. Read More

Ok, with the official presentation of Qt 4 the pandora's box called KDE 4.0 is open, and people start discussing possible changes. So here is my personal contribution of wishes (that I would be willing to work on, of course, at least if I am not the only one): Read More

The lack of comfort when joining mailing lists is annoying. If anybody wants to make me a little bit less grumpy, try the following: design a XML Scheme / file format to describe a mailing list (and especially how to join and leave it) register a corresponding mime type in KDE add a handler for that file type in KMail, or write a stand-alone app that uses the KMail backend when somebody clicks on a link with that mime type in Konqui, start the handler the handler will, after some GUI to explain it to the user and asking for permission, create a folder for the mailing list in KMail, create a filter for the mailing list, write a mail to the registration address to join and reply automatically to the confirmation mail KMail should have a 'unsubscribe' context menu entry that lets a user unsubscribe automatically That would be useful... The next step, of course, would be a more comfortable way of browsing and finding mailing lists. KMail could have a build-in list of mailing lists (or download one) so people don't need to search for them. Read More