Saturday, 27 October 2007

What Delphi needs

This is my current wish list for Delphi

Platforms:
* 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 asp.net 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.

3 comments:

UA3QRZ said...

Very good wish list. Agree in every point.

What I would like to add is Modula-2/Oberon style statements syntax, e.g. as an compiler option for units.

Salvador Gomez Retamoza said...

That is a really, really nice list!

That is the kind of great decisions I was talking about in my own spanish blog in the last few months. The kind of ideas that I'm certain that could take Delphi to double its market share the less, being its uniqueness and the dynamism their better features.

Anonymous said...

You don't want the widestring implementation, but you don't say what's wrong with it. (I assume performance) Note that there are two (Kylix and Delphi one). The Delphi one is COM, the Kylix base is simply ref counted like ansistring. IMHO CG should have separated widestring from COMString.

>* More focus on units, less focus on classes

I don't here this to often enough, and I fully agree.

I don't agree on the automated creation/destruction. Without effective control of the compiler this will become an enormous performance sink (if you want to know how, look at the package DECAL, both in behaviour as implementation). A true compiler solution will be better, but not THAT much.

Determinism for the compiler devel is btw something else than for the avg user. If you want an example, do you think the avg programmer the rules about how long a pointer to a temp string lives in an expression?

>* Compile-time option that makes cyclic unit dependencies illegal

While I wouldn't mind, I'd tackle the same problem with an investment in error msgs. I'm with Delphi for two reasons: Efficient GUI building and decent compiler msgs. Let's take that advantage a step further.
Also fix the horrible mess with .dpr files with mismatched paths. (the most confusing errormsg for new users)

* Multithreading in code.

Very hard. FPC has some attempts, but in general, the compiler can't automatically assess the granularity of paralellism needed. An automatic solution requires too much insight of the computer in the problem domain.

Of course you can do syntax assist e.g. MPI or co-pascal style, but this is hard to use efficiently outside the odd scientific app, which typically aren't Pascal users anymore.

ua3qrz: Modula2 export import behaviour would be nice. (from x import and import x) Afaik the Extended Pascal ISO standard has some of these features too, since afaik the M2 module system was somewhat backported to it.

A FPC developer.