Re: OO-Inquisition

On Apr 21, 2:50 am, topmind <topm...@xxxxxxxxxxxxxxxx> wrote:
Alvin Ryder wrote:
On Apr 19, 10:49 pm, Thomas Gagne <tga...@xxxxxxxxxxxxxxxxxx> wrote:
Alvin Ryder wrote:
<snip>

I've witnessed the work of hundreds of OO developers, the state of
affairs isn't exactly pretty.

20 years ago, the same was true of C and FORTRAN. I worked with a staff
of 50 programmers, fewer than 10 of which were excellent, which for most
staffs is above average.

That said, given any sampling of programmers, only have of them will be
better than average. Programming isn't math or baking. Programmers
can't just follow recipes and come up with good programs, or understand
how to wield paradigms to the greatest affect. It matters little
whether its procedural, OO, or relational.

So it's unfair to measure a language's or paradigm's effectiveness by
measuring how 90% of programmers use it. To realize what really can be
done we should look at how the top 10% of programmers are able to bend
any language, paradigm, or idiom to their will and learn from that.

I think it does count at least *some* against the language/technology
if it is hard to get right.



Actually that 90% is bit of a hobby horse of mine. When I began my
career I started getting the feeling that 90% of programmers weren't
worthy hiring whatsoever. It wasn't the technology, the rage back then
was "procedural / relational" and cobol it was just them. They were
simply sloppy operators.

COBOL and relational have never been "in style" at the same time. The
first commercial relational product didn't even exist until the late
1970's and didn't become mainstream until a few years later, and by
that time COBOL was already starting to look old. Pascal and C were
far more "in".



Sure their introduction dates were different but they certainly did
overlap.

When I started in the mid 80s COBOL was the way "real business" apps
were built but Oracle 3 then 4 were kicking around and making big
waves. Rightly or wrongly I chose the Oracle/SQL*C path for "big
stuff" and Turbo Pascal for PC work.


I began wondering, then actively observing other fields, I came to the
same conclusion about teachers, mechanics, managers ... even doctors!
It wasn't just my imagination I've worked with some of the best
managers and doctors around, they reckoned the same thing.

Everybody wants "A" workers/services at "C" prices. No news there.


Not if you put it that way but nearly everyone I meet thinks all
doctors are the same and all are brilliant, the news that they are not
disturbs them.



So yes, I agree with you.

Cheers ;-)

-T-


.

Relevant Pages

  • Re: Why C is really a bad programming language
    ... It /started/ with COBOL (or rather, in the era in which COBOL ... I find it hard to credit programmers who are always part, so they say, ... dependencies means that due diligence is required even if the ... Managers don't want to be seen as spending money on potential events ...
    (comp.lang.c)
  • Re: CoBOL and Contracting (Was: All X0D lost during...)
    ... coexistence with offshoring, the declining CoBOL marketshare, and all ... it may well be that the treatment of contractors is different ... Indian managers mistreat ... interest and enthusiasm by COBOL programmers. ...
    (comp.lang.cobol)
  • Re: Declining Cobol job market
    ... pursuing Cobol jobs. ... server side programming in PL/SQ. ... A lot of COBOL programmers (and RPG programmers, and Assembler ...
    (comp.lang.cobol)
  • Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... possible that Cobol programmers see themselves as defenders of an intellectual lost cause?The last hangers-on of an idea whose time has passed. ... The absolute power was a corrupting influence, just as it has been in certain other religions. ...
    (comp.lang.cobol)
  • Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... people to think about why COBOL is in the state it's in. ... a dollar for every time I have seen Business people put down by programmers. ... >> There are certainly parallels with religion in that. ...
    (comp.lang.cobol)