Re: Odd behaviur...

From: David Reeve (dree4456_at_big-pond.net.au)
Date: 09/01/04


Date: Wed, 01 Sep 2004 02:14:33 GMT


"Martin Harvey (Demon account)" <martin@nospam_pergolesi.demon.co.uk> wrote
in message
>
[snip]

> AAAAAARGH!!!!!!!!!!!!!!!
>
> I tell you, C is a P.O.S language. It's total ****. I sometimes wonder
> how on earth it ever got to be the most common language. It seems like
> 90% of the programming population is so busy beating their heads
> against brick walls that they've forgotten that there are better ways.
>

Roll back fifteen years to a happier time when apps were very much smaller,
and C was a language suitably scaled to the problems then in hand. When I
wrote an app, my actual application code often exceeded the included library
code, simply because there was very little library support. For example, all
scientific plotting was done by our own library, all comms using our comms
library, and as for GUI, what's that? When you only have a handfull of
libraries, most of which are your own, the includes are easily managed.

Roll forward to the modern scenario where the app is a small amount of code
linked into the vast libraries that support the GUI and yes, indeed, the
C/C++ tools are struggling. Any little piece of program is just fine, its
just when you come to linking it into the W32 platform that things become
flakey. What are all those includes that Builder drops in? Trying to
understand quite how your simple project will actually build is a
nightmare...... conditional include upon condional include recede out to the
perceptual (well patience) horizon.

People like to build upon that with which they are comfortable, and will
keep building upon the original platform far beyond the point where the
edifice is stable. Technology companies driven by marketing folk rather than
engineers are aware of this and reap the reward. Both Microsoft and Intel
built their current market positions by understanding this.

> >Some of the entries I have seen have been technically impressive; I am
> >left wondering why a programmer capable of producing such code would
> >want to do so.
>
> It'll tell you in one word: It's a feeling of technical superiority.
> The problem is that too many programmers take this to extremes and
> fell that just because things can be done the hard way, they should be
> done the hard way because (unconsciously) it gives them more
> opportunity to sneer at fools who can't.
>

Sometimes its just a love of codes and puzzles. Sometimes its the smart arse
in action. Either way, its not useful in a team environment.

> The worst thing is people who say that C and/or C++ are fine at being
> full of pitfalls because "the programmer should know what they're
> doing" - and then apply that rationalisation to *every single
> technicality they come across*. We're at the point where some crappy
> design decisions made back in the 70's regularly waste millions of
> programmer hours of time.
>

Making the change out of the C/C++ stream of development is not trivial. As
a small company we were able to do it. Firstly, all new development was in
Delphi and inserted as dlls into the existing C code base. Then a change was
made to new looking apps with Delphi GUI and C dlls carrying the older code.
Eventually everything was in Delphi except for stuff that was too fragile to
risk translation. This we ported to Builder. The nice thing about Builder is
you can seamlessly link in pas files, and so most of the code is being
maintained within the Delphi environment. However, roll on a few more years
when that small company is bought out by very large organisation..... the
shrieks of dismay on discovering the software is in other than C++ were
really too terrible. It is only then that you begin to realize how
uninformed, how irrational, how beligerent are the forces that hold C/C++ in
the mainstream.

Dave



Relevant Pages

  • Re: .NET and Delphis future
    ... Big name products are still being built for API. ... Real objects, decent languages, business apps ... The world's best kept secret is that an experienced programmer when writing ... desktop apps gets the most value for $ with Delphi. ...
    (borland.public.delphi.non-technical)
  • Re: Borland, how much for purchasing rights to develop a 64bits Delphiversion?
    ... However for new apps, I ... > don't see this advantage as beeing of any significance. ... A good delphi ... And a good C# programmer should be able to get up to 90% speed in Delphi in ...
    (borland.public.delphi.non-technical)
  • Re: C/C++ is dying... :-)
    ... I think delphi has more pitfalls than properly written C++. ... If I have a new programmer in my company with only general knowledge about programming, it would be SO much easier, faster and securer to make him/her productive with using Delphi than C++. ... Sure there are more C++ programmers out there, but every penny that I spend teaching Delphi to these new guys, I'll save in easier maintenance of the apps. ...
    (borland.public.delphi.non-technical)
  • Re: [LONG] Re: Why code completion and early error checking are needed
    ... >> the programmer who wants such features. ... > libraries to find the type declaration. ... If you type std::vector that means the one from the Standard. ... > of the language to have certain naming and declaration standards ...
    (comp.lang.cpp)
  • [LONG] Re: Why code completion and early error checking are needed
    ... > the programmer who wants such features. ... the guiding principles in the evolution of the c++ language should be ... the problem with this is that ide must first be able to assume ... libraries to find the type declaration. ...
    (comp.lang.cpp)