Saturday 27 October 2007

What Delphi needs

This is my current wish list for Delphi

* Unicode everywhere, using utf-8 or utf-16, but not using the current widestring implementation
* SilverLight, Flash or something like it for thin-client apps using client-side and server-side code, using as server platform

Language features:
* More focus on units, less focus on classes
* Automatic but deterministic destruction and deallocation of objects
* Compile-time option that makes cyclic unit dependencies illegal
* GNU gettext for Delphi as internationalization system
* Compiler should assist the programmer in ensuring full multithreading capability of parts of code, by looking at dependencies, and by having language constructs that indicate multithreading capabilities in source code that looks as if it doesn't have it.

IDE features:
* Project-specific packages with relative paths, enabling easy branching of packages.

Wednesday 24 October 2007

Back from today's DAPUG meeting

I've just arrived back from today's DAPUG meeting (the Danish CodeGear user group). It was very good - focus was on telling news from various conferences, QA/QC and various development techniques. It is clear that CodeGear is gaining momentum again and regaining their competitive edge, and Delphi 2007 has very positive feedback from those, who have upgraded. Also, it was obvious, that we had some topics, on which we can spend some more time, so I hope that we will see another DAPUG meeting in january.

Sunday 21 October 2007

Microsoft Tech Fest in Denmark is also for Delphi businesses

Microsoft has traditionally bought companies that use Microsoft technology, but according to this interview, Ballmer said "We will do some buying of companies that are built around open-source products". So I guess they're not restricted in any way to Microsoft development tools. If you have an innovative company with buyout as possible exit strategy, the Microsoft Tech Fest may be for you.

Saturday 20 October 2007

Multi core CPUs - what does it mean to Delphi?

It seems as if the entire IT industry agrees, that more performance in PCs will be achieved by using more cores in CPUs. Is it true, and what are the implications for Delphi programmers?

Let's start with the assumption about multiple cores. In order to match CPU I/O count performance in a modern PC, you would have to make more than 50 harddisks work in parallel. RAM also has its performance limits, especially as core count grows, so multiple cores are really more about CPU-bound calculations than about anything else. The harddisk problem can be solved by using network attached storage with arrays of harddisks, and the RAM limits can be solved by letting each CPU have its own RAM (like NUMA or other architectures). These solutions are obviously good for servers, which have many concurrent requests, where each request can be served by one thread. This doesn't have much influence on how we write source code, and Delphi does the job very well.

If you want greater performance on a desktop PC, we're usually talking games and simulations or data handling software (database applications). I'm not much into games and simulations and will focus on client/server database applications. The typical performance problems with database applications are about data retrieval over the network, sorting, lookups and filtering. If you have a performance problem in such an application, you will usually not want it to be 2 times faster, but 10 times faster. Given the architectural problems in a desktop PC, this is not possible by using multithreading.

What is needed, is to minimize the time from a user action until something happens. You can do this by caching data, doing things in the background, and by preparing data for user actions that you expect to happen. Multithreading is a very good tool for doing this, so enabling multithreading in applications is something we need - but it's not because the CPUs are going to be multi-core. There are many ways that CodeGear can make Delphi support these techniques, either using technologies like MIDAS, or by modifying the language slightly. But there is no reason to fundamentally change the programming language.

Friday 19 October 2007

CMMI, Six Sigma, Agile, ...

When programmers are told to spend time on various programming techniques and software development management techniques, it removes focus from the actual programming. Managers tend to impose too many techniques and methods, and programmers try not to spend too much time on them.

One of the problems is, that the brain has a limited capacity. If you're doing something difficult, it doesn't help you if somebody tells you to do it in a way that's even more difficult. You may think you have to compromise: Do you want to use brainpower on programming techniques or on programming?

The answer is different: You want to spend your team's brains on solving the customer's problems, and reduce the amount of brainpower needed to do programming and programming techniques.

Wednesday 17 October 2007

How to become a manager

I meet a lot of programmers who want to become managers. However, their motive is not good - they want to become managers because they have specific ideas they want to do in programming.

If you want to become a good manager, then you need to make sure first, that your are genuinely interested in administrative work. Your value will be measured by the work of other programmers, so your own personal programming skills are really not that important, as long as you are able to keep the team capable and focused on what other parts of your company think is valuable.

Monday 15 October 2007

Which character set?

There are many reasons to choose a particular character set. Some believe that choosing widestring everywhere solves all problems. It doesn't. Widestring is slow because it needs to be Microsoft BSTR compatible, and it's also complicated. A widestring can contain UCS-2 encoding and UTF-16 encoding, and with UTF-16, you can have 4 bytes per character.

One of the problems is the Unicode standard. It allows a character to be built in more than one way. There is no one-to-one match between the binary representation and the look of a character. Therefore, if you want to do Unicode, text handling becomes complicated, no matter what you do.

A good way to choose a character set, is by performance and compatibility. How much space does it use, and is it compatible with other software systems. UTF-8 uses very little space if most characters are ASCII characters. If you add some ISO-8859-1 characters, like in many west european languages, it's still very compact. It only gets less optimal than other character sets, if you want to encode chinese, japanese and other languages that don't use ASCII characters a lot.

UTF-8 is also very compatible with other systems. It's a defacto standard for XML files, it only exists in one version (unlike UTF-16 with exists as UTF-16BE and UTF-16LE), and it encodes 31 bit, much more than UTF-16's 20 bit. UTF-8 is also compatible with zip filename encoding (unlike UTF-16 and UCS-2 which is not), and UTF-8 texts can be handled by many applications that were not originally designed to do so.

Linux already installs with UTF-8 as default, for most distributions and locales. This makes it possible to zip files in Moscow, send them to Copenhagen, unzip them, and all filenames are preserved. This doesn't work on Windows.

Delphi, being a Windows tool, uses Windows 8-bit and 16-bit character sets by default, in ansistrings and widestrings. There's also an utf8string, but it's actually the same as an ansistring. You can convert from widestring to utf8 and back using utf8encode() and utf8decode().

If you store and transmit unicode information using utf-8, most of you will experience a reduction in space usage and a reduction in transmission time.

One of the very nice features of utf-8 is the ability to be autodetected. Utf-8 does not allow all possible bit combinations, and the bit combinations that are being used, are usually extremely unlikely in other 8-bit encodings. For 99% of all applications, it is safe to apply autodetection to utf-8.

Saturday 13 October 2007

Why Delphi?

I have seen many explanations on why to use a specific software development tool, and I was actually planning to write a post on why we have chosen Delphi as our main software development tool. There are many good reasons to list, however, after attending a number of conferences, and hearing about several companies who switched tools years into the project, from C++ to .net, from .net to Java and others, I need to write it in a different way.

The choice of tool depends on the problem that you try to solve. You need to ask yourself, what the problem is. If you're doing commercial software development, the problem is usually related to money. You need to ask yourself: Which tool provides most value to the company, in the short run, medium term and in the long run.

That question seems easy, but it isn't. If this question is answered without reading the business plan or involving business strategies, you made a mistake. If the customer's weren't involved in providing information to make the decision, you made a mistake. And once you made a decision, make sure to test this using a Devil's advocate, which is not a software developer. It doesn't need to take a lot of time, but it needs to be done right.

I have one important tip: before evaluating how a tool matches your problems, analyze the tool's features, and sort them into the categories: Critical for solving this problem / nice to have / don't use. The last one is important: it should contain all the features that are in conflict with your business plan, for instance by locking into something you don't want to be locked into, or by storing vital business information in bad ways.

Wednesday 10 October 2007

Nohau QA/QC seminar review

I just came back from Nohau's seminar about QA/QC, and it was a good experience. It's nice to attend a seminar, that's free and not just a presentation of software, but also tries to raise the general knowledge level of the audience. If you haven't introduced QA/QC measures in your organization, yet, you should seriously be considering doing that.

I noticed, that most speakers were asserting that good quality requires the use of agile software development techniques. It's nice to see the software development business maturing.