Board index » delphi » Re: Why Delphi is not More Popular

Re: Why Delphi is not More Popular


2006-10-03 07:09:14 PM
delphi207
"John Jacobson" <jake@j[nospam]snewsreader.com>writes
Quote
I've been thinking about Delphi's future a lot lately and I'd like to
proffer a hypothesis as to why Delphi is not more popular. This hypothesis
will
sound wacky without the ensuing explanation, so bear with me as I state my
theory and then why I think it is a decent explanation.

Hypothesis: Delphi is not more popular because of the poor quality of
software
engineers in general.

..
I suppose you could summarize this whole post in a single sentence:
Delphi
makes it too easy for {*word*99}py programmers to produce their {*word*99}.

Beg to differ, only the conclusion, not the facts :-) VB(Visual Basic) is/was popular
because a {*word*99}py programmer can easily and speedy create their {*word*99}py
software. Delphi being Pascal syntax orientated is already too difficult for
most of them. If Borland would ever remove the standard Form1 : TFrom1
declaration most starting programmers would try Delphi and stopped using it
immediate after trying and failing to set the caption of the form. That
really would be the end of Delphi.
For Delphi to become popular again they should improve the VCL components
even add some more and then add some 1000 or so examples. And they should
not forget to add these examples to the helpfile!! RAD all the way!
Do not forget that the impression that software development is easy is a
major reason for this industry for doing so nice and providing us a way of
making a living and have some fun with/on the WTF. Getting a few million
extra developers even with {*word*99}py software will create an even bigger
software development industry.
 
 

Re: Why Delphi is not More Popular

He said that in his experience, C++ programmers were more competent
than Delphi programmers, but in my experience, the language (C++) led
one to write more obscure programs than Delphi ones. I have yet to find
a Delphi program I couldn't maintain. Granted, I have seen Delphi code
that could have been written better, but I have also seen a lot of C++
code that were worse, especially when constructs like this are used.
In other words, Delphi makes the code more maintainable, while it takes
more "expert" people to maintain C++ programs, and maybe that is what
John meant.
Guillem writes:
Quote
Phillip Woon writes:

>You call this good code?
>
>float (*(*fp2)(int,int,float))(int);
>

That's horrible but, what's your point? John didn't write anything
nearly similar to that in his post
--
 

Re: Why Delphi is not More Popular

"Jeroen Vandezande" <XXXX@XXXXX.COM>a crit dans le message de news:
XXXX@XXXXX.COM...
| Tell me about it...
| This is code I found in an application I "inherited"... always nice to add
| functionality to such a code base :)
|
| procedure TSeFluidLite.ExecuteLISSetup;
| var
| AForm: TLISSettingsForm;
| begin
| AForm := nil;
| try
| AForm := TLISSettingsForm.Create(Self);
| AForm.ShowModal;
| FreeAndNil(AForm);
| except
| on E: Exception do
| begin
| try AForm.Free; except end;
| Error('Error getting the LIS''s settings', 0, E);
| Exit;
| end;
| end;
| end;
Uhhhaaahhhh !!!! I feel faint, get me a chair :-)
Did this make it into the Daily WTF ?
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re: Why Delphi is not More Popular

Quote
That's horrible but, what's your point? John didn't write anything
nearly similar to that in his post
That there are popular languages that force you to write bad to read code, let
alone the temptation to write 'cool' constructs that allow rapid and {*word*99}
coding. Often I see people 'optimizing' C/C++ code, most of the time their only
contribution.
If you use C/C++ in a disciplined way you can write reasonably good to read code
(except some rare constructs), but there are many who don't do it because they
don't have to. Similar to the RAD issue.
 

Re: Why Delphi is not More Popular

"Joanna Carter [TeamB]" <XXXX@XXXXX.COM>writes
Quote
"Jeroen Vandezande" <XXXX@XXXXX.COM>a crit dans le message de news:
XXXX@XXXXX.COM...

| Tell me about it...
| This is code I found in an application I "inherited"... always nice to
add
| functionality to such a code base :)
|
| procedure TSeFluidLite.ExecuteLISSetup;
| var
| AForm: TLISSettingsForm;
| begin
| AForm := nil;
| try
| AForm := TLISSettingsForm.Create(Self);
| AForm.ShowModal;
| FreeAndNil(AForm);
| except
| on E: Exception do
| begin
| try AForm.Free; except end;
| Error('Error getting the LIS''s settings', 0, E);
| Exit;
| end;
| end;
| end;

Uhhhaaahhhh !!!! I feel faint, get me a chair :-)
:) you should have seen my face when I opened the unit for the first time...
It should be noted that this code was written by C++ (or just C) programmers
forced onto Delphi by management...
They also implemented polymorphism by using records with method pointers in
it... :(
Quote

Did this make it into the Daily WTF ?
I could submit this yeah...
 

Re: Why Delphi is not More Popular

"Eric Grange" writes:
Quote
Sorry, but this doesn't fit this reality.
<snip>
IMO, the reasons for popularity rather are
1) marketing and buzz, need those to get started, and going.
2) long term investment, by whoever is promoting the language, to build
confidence, to build showcases, to build/extend support.
3) being taught in schools, sustains the popularity when 1) or 2) aren't
there anymore, or in a period of slumber.
OMG Eric, I more or less agree with you!
Much of the reason that Delphi didn't take the world by storm has to do with
the language being Pascal like which way too many prospective customers
simple reject out of hand. As I mentioned a few days ago, back in '95-96 I
attempted to convert 25+ fellow Clipper programmers to Delphi and only one
made the transation. The most common reason was they didn't like Pascal and
most all of them became VB(Visual Basic) programmers. And these guys were not {*word*99}py
programmers.
When Delphi was introduced Borland did make an attempt by publishing
articles and papers showing the superiority of Delphi over VB, but that
campaign was short lived where a long term effort was clearly called for.
Then there has been a constant belittling of VB(Visual Basic) programmers as simply too
stupid with no ability while simultaneously not providing "on ramps" to help
them get aboard. That continues today, review Dan Barclay's comments on the
subject of "on ramps".
To say as Jake did, "I suppose you could summarize this whole post in a
single sentence: Delphi makes it too easy for {*word*99}py programmers to produce
their {*word*99}." is chauvinistic, bellicose and IMO un{*word*62}erated {*word*99}. It's
just just the latest turnoff for prospective customers.
 

Re: Why Delphi is not More Popular

Jeroen Vandezande writes:
Quote

They also implemented polymorphism by using records with method pointers in
it... :(

Seen this myself. *g*
Quote

>Did this make it into the Daily WTF ?

I could submit this yeah...

Well, it isn't really stupid code.
It just shows that the author knew he had to protect the allocation, but he didn't knew Delphi,
especially the Delphi RTL, all that well.
He basically simulated a try-finally by using nested try-except.
But those polymorphic records; and more interesting: their usage, would be quite ...
enlightening. *g*
 

Re: Why Delphi is not More Popular

"Dave Nottage [TeamB]" <XXXX@XXXXX.COM>writes
Quote

implementation

uses
UnitA, UnitB;


DoSomething;


If you're aware of the scoping issue(s), it is not a problem to make
sure it does what is expected, much like "with".

This is a major weakness in Delphi. The lack of a warning has caused me
major headaches on more than one occasion.
I have heard that the way that the units are designed / searched is not as
efficient as it could be. Terminating the search as soon as the first
candidate is found saves time but means that duplicate occurrences are never
detected. Consequently, you should resist reordering the list of units in a
uses clause if you want to avoid {*word*193} surprises.
There should at least be a switch to optionally force a full search whenever
required. In the meantime, the safest approach is to qualify all such calls
e.g.
UnitA.DoSomething
or
UnitB.DoSomething
 

Re: Why Delphi is not More Popular

Grandfathers discussion about which langauge is better. :)
Vladimir Grigoriev
"Phillip Woon" <XXXX@XXXXX.COM>writes
Quote
He said that in his experience, C++ programmers were more competent
than Delphi programmers, but in my experience, the language (C++) led
one to write more obscure programs than Delphi ones. I have yet to find
a Delphi program I couldn't maintain. Granted, I have seen Delphi code
that could have been written better, but I have also seen a lot of C++
code that were worse, especially when constructs like this are used.

In other words, Delphi makes the code more maintainable, while it takes
more "expert" people to maintain C++ programs, and maybe that is what
John meant.


Guillem writes:

>Phillip Woon writes:
>
>>You call this good code?
>>
>>float (*(*fp2)(int,int,float))(int);
>>
>
>That's horrible but, what's your point? John didn't write anything
>nearly similar to that in his post



--

 

Re: Why Delphi is not More Popular

Quote
But those polymorphic records; and more interesting: their usage, would be
quite ... enlightening. *g*
here it comes :)
type
TODValues = array[1..MAX_MICROPLATE_COLUMNS, 1..MAX_MICROPLATE_ROWS] of
Real;
TReaderType = (rtAnthos2010, rtBioRadModel680, rtBioTekELx800,
rtTecanSunrise, rtVirtualReader);
PInitFunc = function(AComPort: TCustomComPort; TransportInit: Boolean):
Integer;
PFinishFunc = function(AComPort: TCustomComPort): Integer;
PGetWavelengthsFunc = function(AComPort: TCustomComPort;
var WaveLengths: array of Integer; var Count: Integer): Integer;
PGetODValuesFunc = function (AComPort: TCustomComPort;
const WaveLengths: array of Integer; var Count: Integer;
var ODValues: array of TODValues): Integer;
POpenDoorFunc = function(AComPort: TCustomComPort): Integer;
PCloseDoorFunc = function(AComPort: TCustomComPort): Integer;
TReaderProperties = array[rtAnthos2010..rtTecanSunrise] of record
MaxNumberOfFilters: Integer;
InitFunc: PInitFunc;
FinishFunc: PFinishFunc;
GetWavelengthsFunc: PGetWavelengthsFunc;
GetODValuesFunc: PGetODValuesFunc;
OpenDoorFunc: POpenDoorFunc;
CloseDoorFunc: PCloseDoorFunc;
end;
...
var
ReaderProperties: TReaderProperties;
...
initialization
//The properties of the Anthos 2010
ReaderProperties[rtAnthos2010].MaxNumberOfFilters :=
ANTHOS2010_MAX_NUMBER_OF_FILTERS;
ReaderProperties[rtAnthos2010].InitFunc := ANTHOS2010_Init;
ReaderProperties[rtAnthos2010].FinishFunc := nil;
ReaderProperties[rtAnthos2010].GetWavelengthsFunc :=
ANTHOS2010_GetWaveLengths;
ReaderProperties[rtAnthos2010].GetODValuesFunc := ANTHOS2010_GetODValues;
ReaderProperties[rtAnthos2010].OpenDoorFunc := nil;
ReaderProperties[rtAnthos2010].CloseDoorFunc := nil;
//The properties of the Bio-Rad Model 680
ReaderProperties[rtBioRadModel680].MaxNumberOfFilters :=
BIORAD680_MAX_NUMBER_OF_FILTERS;
ReaderProperties[rtBioRadModel680].InitFunc := BIORAD680_Init;
ReaderProperties[rtBioRadModel680].FinishFunc := BIORAD680_Finish;
ReaderProperties[rtBioRadModel680].GetWavelengthsFunc :=
BIORAD680_GetWaveLengths;
ReaderProperties[rtBioRadModel680].GetODValuesFunc :=
BIORAD680_GetODValues;
ReaderProperties[rtBioRadModel680].OpenDoorFunc := nil;
ReaderProperties[rtBioRadModel680].CloseDoorFunc := nil;
//The properties of the Bio-Tek ELx800
ReaderProperties[rtBioTekELx800].MaxNumberOfFilters :=
BIOTEKELX800_MAX_NUMBER_OF_FILTERS;
ReaderProperties[rtBioTekELx800].InitFunc := BIOTEKELX800_Init;
ReaderProperties[rtBioTekELx800].FinishFunc := nil;
ReaderProperties[rtBioTekELx800].GetWavelengthsFunc :=
BIOTEKELX800_GetWaveLengths;
ReaderProperties[rtBioTekELx800].GetODValuesFunc :=
BIOTEKELX800_GetODValues;
ReaderProperties[rtBioTekELx800].OpenDoorFunc := nil;
ReaderProperties[rtBioTekELx800].CloseDoorFunc := nil;
//The properties of the Tecan Sunrise
ReaderProperties[rtTecanSunrise].MaxNumberOfFilters :=
TECANSUNRISE_MAX_NUMBER_OF_FILTERS;
ReaderProperties[rtTecanSunrise].InitFunc := TECANSUNRISE_Init;
ReaderProperties[rtTecanSunrise].FinishFunc := TECANSUNRISE_Finish;
ReaderProperties[rtTecanSunrise].GetWavelengthsFunc :=
TECANSUNRISE_GetWaveLengths;
ReaderProperties[rtTecanSunrise].GetODValuesFunc :=
TECANSUNRISE_GetODValues;
ReaderProperties[rtTecanSunrise].OpenDoorFunc := TECANSUNRISE_OpenDoor;
ReaderProperties[rtTecanSunrise].CloseDoorFunc := TECANSUNRISE_CloseDoor;
end.
...
depending on what reader you selected (stored in a ini file) the program
would use another indexer on ReaderProperties...
It works, but this is why polymorphism was invented :)
Regards,
Jeroen Vandezande
 

Re: Why Delphi is not More Popular

Jeroen Vandezande writes:
Quote
This is code I found in an application I "inherited"
Bah.. I have seen worse. Jim Cooper and Jeff Overcash can vouch for me,
because they saw it too.
I might even have some examples I could dig out.
--
Dave Nottage [TeamB]
 

Re: Why Delphi is not More Popular

Jeroen Vandezande writes:
Quote
this code was written by C++ (or just C) programmers forced onto
Delphi by management
Ah.. that closely matches what I have seen.
--
Dave Nottage [TeamB]
 

Re: Why Delphi is not More Popular

"I.P. Nichols" <XXXX@XXXXX.COM>writes
Quote
"Eric Grange" writes:
Much of the reason that Delphi didn't take the world by storm has to do
with the language being Pascal like which way too many prospective
customers simple reject out of hand. As I mentioned a few days ago, back
in '95-96 I attempted to convert 25+ fellow Clipper programmers to Delphi
and only one made the transation. The most common reason was they didn't
like Pascal and most all of them became VB(Visual Basic) programmers. And these guys
were not {*word*99}py programmers.
I can't agree that your guys were not {*word*99}py programmers! If they were not
then they chose C++ insteed of Basic! :)
Vladimir Grigoriev
 

Re: Why Delphi is not More Popular

Quote
>In Chrome it was changed to:
>
>with f := TYourForm.Create(nil) do

If I could do that then I'd use "with" again.
I'm also a "without" ;) I always declare a local var, maybe it is just 'f'
and use that.
Along Peter's line above, I would love to have the equivalent "using" where I
could declare something that *just* had that scope, and would automatically
free at end of scope.
 

Re: Why Delphi is not More Popular

Quote
The reason why the poor state of software engineers leads to troubles for
Delphi is this: poor software developers love to blame the pre-existing code or
the development tool for the errors in their code. And nothing attracts poor
developers like the alleged ease of RAD.
I guess one main difference for example to C/C++ is that usually the kind of
projects is different.
You have less GUI-centric apps in C or C++, most of the work is done under the
hood/not directly visible, less database-stuff (always similar patterns). RAD is
not the problem, but that many projects written in Delphi can be completed
almost only using RAD; not needing some more complex algorithms. Too much
code-reuse is also bad for developing intellectual skills.
In my oppinion it hurt Delphi that it has mainly degraded to a database-centric
tool. Delphi is versatile but is not pushed in other directions.
*Good programmers don't grow in a mono-culture*.
C/C++ is used for almost anything (except perhaps in safety critical aerospace
apps), thus a C/C++ programmer is much more likely to work in different areas.
Delphi itself isn't the problem, it is the mono-culture that built around it.
C/C++ leads to bad practices when writing code without discipline, but it is
used in a more varied environment, forcing to be more innovative and flexible in
mind, than when doing similar things over and over again.