My thoughts about Delphi and its future

Delphi is for many still the most productive development environment and
many love to use, but there are many areas it can be improved in and not all
can be done in a short time / with little investment. A lot of them have
been mentioned in these newsgroups / blogs / QC, so I'm not claiming these
are my ideas. Also, I only mention the Pascal part of Delphi (BDS) because
this what I like and work with.

As has been said, Delphi is not one thing, it is many things: IDE, language
(Pascal), compiler, framework (VCL), community, ... so I tried to take a
look at some of them.

1. Compiler.

a. Cross-platform support.
Today Delphi compiles for 3 platforms: Win32, .Net and Linux (IA86). One of
the things we all seem to agree with, is that this list could and should be
extended. The obvious targets are IA86 (32 and 64 bit) HW platform and the
OSs that are not yet covered: Win64 and Mac (add any platform you see as
important and lives on IA86) and .Net: .NetCE and Mono. I have no idea how
the Delphi compiler works internally, but I suspect that it uses some kind
of abstraction and compiles to some sort of p-code which is then optimized
for a specific platform and codegened. So adding a compiler support for a
new platform (I am not talking about framework here) should include codegen
and optimizations for that platform but would not influence the itermediate
p-code generation. This should mean that the language itself should be
independent of the underlying platform (this in past years hasn't been the
case as we can see with operator overloading or generics for example, but is
more or less true for Java, C, C++). Implementing support for many IA86 (and
..Net) platforms does not bring a true cross-platform support (only one
processor type) but since this processor represents the vast majority of the
processors in todays PC and small / middle sized servers, this would mean a
great coverage. Of course, this would not exclude a possible coverage of
other (non-IA86) platforms in the not so near future.

b. Compiler capabilities.
The compiler capabilities can and should be extended. By this I mean:
- FP optimizations should be done so that Delphi generated code would be on
par with the fastest compiler generated code in this area.
- Inclusion of a support for new technologies (SSE, MMX, ...) in the
compiler and self recognition of these in a running program if so wished.
- Integrated support for multi-threading (this should also reflect in the
language itself).
- Support for new multi-core and multi-processor systems.
- More and better overall optimizations (smart register use, loop
optimizations, ...).
- Further improvements and tighter cooperation with FastCode Project and
others that can help in optimizing the basic compiler operations.

The goal of these new capabilities is the code generator that produces the
fastest possible execs and supports the newest technologies. This should
attract many developers of non-database applications that use C / C++
because of the execution speed. Today more and more of commercial software
is heading toward video and multimedia production and the speed here is
essential.

2. Language.

Object Pascal (Delphi) language can and should evolve further. One direction
is C# 2 and 3, another is shown in Chrome, yet more were described by Danny
(native multi-thread support). Since Delphi is not standardized and you can
do whatever you want with it, you can expand it in any way that makes sense.
It is not always necessary to innovate, sometimes it is useful to take other
concepts and integrate them (or make them even better) - after all isn't
this how C# was made. Expanding language must of course be very very
causious and I believe some sort of body (inside DevCo or with outside help)
should take decisions about it.

Pascal, though hated by many (esp. >real programmers<) is in my opinion the
most natural and readable and easiest to maintain language of
today's >major< languages (Cxx, Java, Basic) and most of us Delphi users
love it for this.

3. Framework.

VCL framework (and its component model) is in my opinion the single most
important thing that has made Delphi what it is. Before this OOP was nice
but hard. I still remember trying to make a small Windows 3.1 application
with Borland Pascal for Windows 1.5. It was a nightmare. VCL is what
(combined with language extensions introduced into Object Pacal) made the
Win development easy. However, since Delphi 2 or 3, not very much has been
done to do things better. I always feel like VCL is only half complete. Let
me clarify this:

a. UI controls.
UI controls haven't changed since the beginning. OK, each Delphi version
added some new properties and events, but visually they haven't been
enhanced. Which means that if I want to make my programs look modern (or
nice) I have to use 3rd party or self-made controls. This goes for all kinds
of controls: edits, grids, menus (most developers I know use DevExpress
components to make their applications look modern and appealing), tree- and
listviews (virtual tree view), ... Many of the controls that are standard in
most used commercial software aren't available or are inadequate (sidebars,
OfficeXp toolbars, ...). There is a relatively big market and free- or
shareware for Delphi UI controls, but I believe that most of us would like
to be this a part of Delphi itself.

Appart from the UI controls being good (modern) looking and having more of
them, I also believe that a great effort should be made to make those
controls more abstract. Today (almost) all visual VCL controls are tightly
integrated with underlying Win32 (or .Net) platform. I believe Delphi should
make a base (interface based) abstract model for all sorts of visual
controls that it supports (edits, labels, buttons, menus, panels, ...) and
then implement actual platform-dependent bits separately for each supported
platform (see cross platform support below).

b. Database support.
Database support is one of the strongest sides of Delphi (Delphi - Oracle
name relation) and is in my opinion responsible for Delphi's enterprise
acceptance. However, it could be even better:
- When Borland decided to stop supporting BDE (SQL Links, more precissely),
we were left with three possibilities: ADO, dbExpress and 3rd party support.
dbExpress has in my opinion only recently (in D2006) become stable and
usable enough (note: I work exclusively with Oracle DB). However: switching
from BDE to ADO to dbExpress has not been done in a way that is as easy as
changing TQuery with TADOQuery or TDBQuery. ADO TParameters for example are
not compatible with TParams, dbExpress doesn't support bi-directional and
live queries, ...
- .Net database support is a bit confusing: you cannot use ADO.Net or BDP in
VCL.Net applications (at least easily), so you are stuck with dbExpress or
ADO. On the other hand, BDP is a great technology but in D2006 it still
doesn't support named parameters which alone makes its use and switch from
BDE / ADO (at least for me) extremely difficult. The way I see things, BDP
(and ADO.Net) should be supported by VCL just as BDE / ADO / dbExpress are.
- DB aware components should in my opinion be improved in two ways:
-- UI components should be renewed (see UI controls above).
-- DB awareness in VCL controls should be made much more transparent (using
interfaces).

c. Cross platform support.
I believe that VCL should be the only Borland's (hm, NewCo's) framework that
Delphi supports on any platform it compiles to - that doesn't mean that it
should not support other native frameworks like Winforms, ASP.Net, ... I
believe that CLX experiment has proven that (and that this is one of the
factors why Kylix hasn't been more widely used). Of course, when it comes to
cross-platform support, the abstraction of VCL framework that I mentioned in
a. and b. should greatly help to transfer VCL to new platforms.

d. Un- (or half) supported technologies.
As I mentioned, database support in Delphi is the thing that made Delphi
accepted in enterprise market. However, Borland itself soon found out that
it alone is not enough. This gave us technologies like Midas (DataSnap),
WebSnap, ... However, as with many other VCL components and technologies, I
believe that Borland could and should have done more. Midas is a great
multi-tier concept, but should be improved. Today, many that want multi-tier
support turn to 3rd parties (like RemObjects) that provide much better and
enhanced support. WebSnap never made it very far as I know, today most use
other technologies with Delphi (IntraWeb and ASP.Net). I believe I can say
that these technologies got abandoned instead of improved in time which is a
great shame. The same goes for reporting, which Borland never tried to do as
it should be done (we always had to rely on 3rd party solutinons from
QuickReports to RaveReports to CrystalReports, ...).

There are also many technologies that in my opinion should be part of VCL
but are not. I would for example really like to have in integrated plug-in
framework included in VCL (today I have to use 3rd party RemObjects or TMS
or so). One other thing that in my opinion should be a part of VCL framework
is a scripting Pascal (Delphi) engine (I know, there are a lot of 3rd party
solutions, but...). Still another one is a better XML, XSLT, XSLF, XPath,
.... support. Wouldn't it be great to have a native VCL support for all of
these X... technologies that would simplify their use in a way VCL
simplified Win32 API? .Net made a good progress in this direction but we
need this also on Win32 (and Win64, of course).

I believe a lot can be done in simplifying common app. development tasks and
this could be one of the directions NewCo could lead to. Like VCL simplified
use of Win API and ECO simplifies data access and data relations, I can see
a foundation of common building blocks that further simplifies the way we
develop applications. You want to make a plug-in based application: no
problem, just use this template. Want to make a Win Service: no problem, use
another template. Want to make your app neat: just use this style template
and it will auto-beautify all your forms. Of course, you can already do this
today, but not or hardly without help (and this is where Delphi Community
excels) or 3rd party support.

e. Unicode support in VCL. I believe this needs no further explanation.

4. IDE.

Delphi IDE was always one of the best compared to other dev. environments. I
believe that Borland made a right choice when it decided to develop a new
Galileo (BDS) environment and that (at least in its current version) it is
great and extremely productive to use (could be a little faster, though).
However, one thing that Borland never could do right (in spite of its
declared SDO and ALM direction) is team support. This includes (from my
point of view) tightly integrated versioning control and requirements
tracking system. BDS2006 finally inegrates StarTeam and CaliberRM but I
believe the cost of it prevents most of small / middle sized developers from
ever using it. I hope that NewCo will be able to provide IDE support for 3rd
party vendors (or freeware solutions) which would probably mean to document
end expose the OTA.

I don't, however, see a chance (or a need) of BDS becoming an open solution
for including other vendors' compilers and technologies (like Eclipse or
VS), but I could be wrong.

One thing that must be improved ASAP is the help system that as it is now is
almost unusable. I am not an expert on help systems and have no idea how to
approch this problem, but I know it can be done. Heck, even the old D7 help
was much, much better.

5. Modeling and ECO.

While I believe modeling support and ECO can be very productive and could
become widely used in the future, especially in database applications, the
lack of documentation (books, videos, demos, code examples) is preventing it
from being at least looked at and experimented with (at least for me). In
today's world there is less and less time to study more and more
technologies, so the ones you wish to get accepted must be presented in such
a way, that a user at once sees their value and can play with them without
having to lose hours and hours on searching for examples and documentation.

I will stop here and not touch other views that should also be mentioned
(priceing, marketing, educational use, ...). To conclude: there are so many
possibilities and ways Delphi can be extended and made better. I believe
(ex)Borlanders have many, many more brilliant ideas of how the Delphi will
evolve in the future. So let's hope that NewCo becomes reality and that new
owners will learn on Borland's mistakes and let their developers' hands and
minds free to make Delphi what it should and can be and make us, users of
Delphi, happy again. And with this their ROI is guaranteed.


.

Quantcast