Sigh...Delphi is good enough to write crap
- From: Scout <Toothpaste@xxxxxxxxx>
- Date: Thu, 25 Aug 2005 20:35:12 +1200
I knew this was going to hurt:
a code review of all of our apps, focusing on
1) code that works
2) efficient code
3) code that plays nicely with the OS
4) fragile code
5) questionable algorithms
6) code that only works sometimes
7) code that doesn't work
8) inefficient code
9) code that works in one environment but not another
10) code that works but trashes the system
There's no particular order for these, and I'm very embarrassed about
how my own apps scored.
Unfortunately, I have managed to write a fair few #7s
#4 probably covers some of the rest, but is included as a catch-all
Where I have scored badly, I have tried to see how I could write the
same thing better, or if I could do it better in C, C++, Java, or some
other language.
Maybe it is my familiarity with the Delphi language that makes me want
to try again, but in each case I have found that I cannot improve what I
have been trying to do by switching languages. Every single case of bad
code that has been identified as a problem has been easily fixed by
slight tweaks to the Delphi code.
The thing that I find most difficult is the string handling in Delphi.
Not that I find it difficult per se, more that I find it difficult to
get things wrong in the spectacular ways that C and C++ programs often
manage to get things wrong when handling strings. It is easy to write
phenomenaly inefficient string handling routines in Delphi which (bad as
they are) will still work flawlessley.
I'm still a D7 programmer. I'm kinda stuck there 'coz I have no idea
how I can achieve some of the things that my apps are required to do in
..NET
I've read about a hack that can be used to make the IDE start faster
that has to do with discovering unit names in packages (and a limitation
in the loader mechanism that makes the hack essesntial)
All of my apps depend on a package which is in itself a package loader
which circumvents this limitation without hacking the IDE, but does rely
on some obscure Win32 stuff to do its magic.
It would be nice to re-write this package loader as some kind of .NET
assembly that could do the same thing (be a smart loader) but for the
moment I have no idea how to do this, or even if I should try.
The thing that bugs me is that all of the code to make this work, with
the exception of the package-loader magic, is pure Delphi classes and we
both know how powerful they can be. And even more irritating is that if
I supply the package loader class (and package) to the worst offenders,
they'll come up with some way to abuse it and tie it to either Win32 or
..Net.
Hence the post subject.
How can anyone stop people from writing crap Delphi code, releasing it
into the wild, and by so doing give Delphi a bad name?
.
- Follow-Ups:
- Re: Sigh...Delphi is good enough to write crap
- From: Scout
- Re: Sigh...Delphi is good enough to write crap
- From: Mark J. Wallin
- Re: Sigh...Delphi is good enough to write crap
- From: Eric Schreiber
- Re: Sigh...Delphi is good enough to write crap
- From: Dennis Landi
- Re: Sigh...Delphi is good enough to write crap
- From: Oliver Townshend
- Re: Sigh...Delphi is good enough to write crap
- From: Dave Nottage [TeamB]
- Re: Sigh...Delphi is good enough to write crap
- From: Robert Marquardt
- Re: Sigh...Delphi is good enough to write crap
- Prev by Date: Re: Database wars
- Next by Date: code auditing
- Previous by thread: Question to all people having issues with D2005 :are you using a non US O.S. ?
- Next by thread: Re: Sigh...Delphi is good enough to write crap
- Index(es):
Relevant Pages
|
