Delphi wish list

Hi,

Some thoughts about directions and marketing of Delphi post sale to
Embarcadero:

1. Marketing focus.
Delphi should be marketed as "one of the best and most productive
general-purpose programming languages", not as a GUI or database front end
builder, even though the latter spin may fit better with Embarcadero's
product range.

I quote from the introduction to Jon Shemitz' "NET 2.0 for. Delphi
Programmers":
"It's rough being a Delphi programmer. We know we have a wonderful,
productive environment- but jobs are few and far between. We know that we
can write any sort of application with Delphi-yet Delphi is seen as a GUI
builder and a database front-end."



This perception can only be due to misguided marketing spin in the past. The
risk is that the acquisition by Embarcadero will make the marketing focus
even more biased towards database applications, rather than tell the story
as it ought to be told - Delphi is a powerful, efficient, at core reliable,
high level, potentially cross platform, algorithmic compiled language, as
good, if not better than C++, Java, C#, etc. Are these other development
languages marketed primarily as GUI and database front-end builders? No. Can
they also be used to build GUI's and database front ends? Yes. With the
wrong marketing spin, if we see any new books at all about Delphi in the
bookshops, they will as likely as not be languishing in the Database
shelves.



2. Simplicity and reliability should be primary ongoing design goals of
Delphi.

The original Pascal language was designed to be powerful, well-suited to
expressing data structures and algorithms in a human-readable form,
reliable, yet at the same time considerably simpler than its Algol
precursor. It was very sparing of high level composite features when tasks
could be accomplished by a small number of elementary features. Certain
features considered at the time to be powerful tools in the armoury of a
skilled programmer, like the Goto statement, were spurned because of their
adverse reliability implications. A data structure or procedure that does
just one thing well is intrinsically more reliable than a class framework
having dozens of properties and methods than may interact in an
undocumented, and possibly undocumentable, manner.

Simplicity also means exposing functionality through static data types and
global procedures rather than classes, when the procedural approach
suffices. It doesn't however preclude conversions between static and
reference types by boxing/unboxing etc. Simplicity means minimising the use
of overloaded methods and procedures - it is much better to use different
identifiers for different parameter signatures. It means consistency in
formulation. It means implementing (or properly hiding) all inherited
abstract virtual methods.

I wish to paraphrase an excellent quotation from Bruce Schneier. He is
talking about software security, but his words are equally applicable to
software reliability. The words in *..* are my substitutions for his
original words in (..):

"If we can distill our recommendations into a single paradigm, it's one of
simplicity. Complexity is the worst enemy of *reliability* (security), and
systems that are loaded with features, capabilities, and options are much
less *reliable* (secure) than simple systems that do a few things reliably.
Clearly *Delphi* (Windows) is, and always will be, a complex *language*
(operating) system. But there are things *Codegear* (Microsoft) can do to
make even that complex system simpler and more secure. *Codegear*
(Microsoft) must focus its programmers on designing *reliable* (secure)
software, on building things right the first time."

Let me say that the core Delphi language seems to be reliable enough,
because it is built on very sound foundations - it's the additions and class
frameworks, that often mimic the complexity of Microsoft prototypes, that
leave one wondering about what confidence one can have in their reliability.

3. Make available published language and library specifications
How can a developer verify whether or not a piece of software is doing what
it is supposed to be doing? Only if there is an unambiguous specification of
its required functionality. This means an EBNF syntax for all language
elements, and a clear description of the behaviour/semantics of all
operations and class methods. The implementation of how this is achieved is
the intellectual property of the vendor - I do not advocate making the
compiler open source. What is needed is a clear and complete syntax
specification for Delphi, Interbase SQL, and any composite method parameters
(e.g. Filter property of TDataset - what is the EBNF syntax of the predicate
expression?)

Bruce Schneier's writings in relation to Windows security issues are also
relevant to Delphi. To paraphrase him:

"The published specifications must be complete, readable, and generally
available. It's not sufficient to make the specifications available to
specific researchers, or to people who have signed non-disclosures or paid
for the privilege. Again, this is not easy from a business point of view,
but if *Codegear* (Microsoft) is serious about putting *reliability*
(security) first, it needs to engage rather than ignore the *developer*
(security) community."

3. Zero tolerance to quality defects (bugs, documentation gaps and errors,
etc).
New versions should focus on simplicity, quality and reliability rather than
new features. Each new version should prioritise improvements to existing
features and bug fixes over the introduction of new features. New features
should be included in shipped versions only after the satisfactory
completion of a rigorous quality verification process applied to both the
code and the documentation.

It would be interesting to compare the number of existing Delphi developers
that buy a new release of the product attracted by its new features with the
number that hold back from buying the new release inhibited by the fear of
having to waste time coping with a new crop of bugs or omissions in the
documentation, or by knowing that reported bugs or omissions have not been
fixed "for reasons of backward compatibility".

The tolerance of long-standing bugs recorded in Quality Central but left to
persist uncorrected over many releases is again rather reminiscent of
Microsoft. I quote from a contributor to Bruce Schneier's blog:

"I sat next to a Microsoft coder (and sometime manager) on a flight from
Seattle recently. He explained that as long as a coder's bug count was below
some level, the bugs could be ignored, and the coder could continue
implementing new features. If the bug count crossed the threshold, he would
have to stop until it was brought back down -- not to zero, just to the
limit. This systematic tolerance for faults of all kinds is why their
software is so bad today, and it won't change quickly. Nothing in the press
release suggested that they saw security as inextricably connected with
reliability. "
The excellent Craig Stuntz commented in a recent thread that "Followers of
Raymond Chin's writings know that "many of the so-called "bugs" in Windows
are an intentional decision to favour backwards compatibility over
perfection in future programs. People who want the opposite emphasis can
get a Mac." It would be nice if Codegear were to adopt the Mac policy.

4. Cross-platform capability

Software, particularly database front ends, is becoming more distributed
and web-centred. It is therefore important that Delphi retains and improves
its ability to compile high level source code into a variety of different
platform codes, including Win32, Linux, and .Net. Clearly there will be some
operating system functions and some GUI components that do not have
equivalents on multiple platforms, and cannot be included in cross-platform
source mode modules. But for the most part, web application servers, SOAP
and REST servers, etc. do not and should not use such facilities.

These comments are expressed in a spirit of constructive criticism. Long may
Delphi prosper!

EM







.

Relevant Pages

  • Re: Microsoft giving Delphi advice
    ... He was directed to the following Microsoft ... > publishing HOWTOs for Delphi. ... regarding this product's performance of reliability. ... By merley mentioning this in this way, ...
    (borland.public.delphi.non-technical)
  • Re: Kudos to the team!
    ... Runtime code speed and reliability: ... With all the press on Delphi 2005, we skipped installing ... Installed Delphi 2006 and was amazed that every major complaint ... Editor Enhancements. ...
    (borland.public.delphi.non-technical)
  • Re: usual nontechnical issues
    ... Delphi can take anybody almost anywhere, ... Unfortunately it is a bit of marketing and technology ... Or Borland's aficionados syndrome too, in some other cases or KBMW or RO ... > are going to work on the Longhorn platform for many years to come. ...
    (borland.public.delphi.non-technical)
  • Re: Yo, Borland Marketing...
    ... I try not to be critical, but Borland's sales and marketing leaves much ... I have been a Delphi purchaser/user (professional ... It almost breaks my heart to see how Delphi and other Borland ... I imagine that if one began programming in C from the ...
    (borland.public.delphi.non-technical)
  • Re: Focussed Product
    ... > but also stick to market standards for the languages and features. ... Yeah, but that can be said of Delphi, IMO. ... > making investing in ECO very risky right now IMHO. ...
    (borland.public.delphi.non-technical)