Glen <lpepicel@nycap.rr.com> wrote
> I think it is right that there is no barrier to bad programmers working
> in 'hard' langs like C++ and assembly.  But I also think that most bad
> programs avoid hard langs in favor of very popular 'easy' ones.

So what's an 'easy' language? COBOL? Basic?

Try manually updating virtual tables and every function that makes a
virtual call, every time you change a class. That's hard!

Try writing your own equivalent of C++ exceptions in BASIC. Try creating
COBOL equivalents of objects that know how to initialize, copy, and clean
up after themselves without being told to.

And if you do find a language besides C++ that can do all of that, let's
see how well it does on non-portable platform-specific stuff. Use this
language to write a device-driver, or a program that (with suitable
permissions) can read and write the disk directly, bypassing the OS for
the sake of run-time performance or else in order to check for low-level
errors.

You find a language that can do all of that easily, and you might make me
a convert.

> Also, without going on and on I'd just suggest that you will find bad
> programs on most langs but you might find different types of bad guys on
> different langs.  So if someone said "He/she is a bad C++ programmer"
> "..is a bad VB programmers" "..is a bad Perl programmer" I would pretty
> much have a different stereotype of all three in mind.

One of the features of good COBOL programs, is that anyone can read it --
even non-technical managers that know very little about programming.
But a bad COBOL program can look like gibberish. Just because COBOL makes
it possible to write programs that are almost self-documenting, doesn't
mean that everyone will. ANY feature of ANY language can be abused!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

d.mikesell@computer.org (Dave Mikesell) wrote in message news:<a671c47f.0301080454.3ca7b7e6@posting.google.com>...
> shannon.barber@myrealbox.com (Shannon Barber) wrote in message
> news:<de001473.0301060824.7f0c065d@posting.google.com>...
> > kaz@ashi.footprints.net (Kaz Kylheku) wrote:
> >>> What language promotes the most humility in programmers?   I suggest
>  that
> >>> language as "best" because the quality of the code written in it is
>  probably
> >>> somewhat higher.
> >>
> >> That language is best which minimizes time-to-market, and defect
> >> rates.
> >
> > Well, those are only two software qualities of many.  What about
> > cost-to-build and cost-to-deploy?
>
> Don't forget cost to consumer.  If you can get your software out
> fastest with language J, but it requires the customer to upgrade
> hardware because it's a resource hog, you may have a problem.

That is what I was considering with cost-to-deploy.  If it's internal
software, all the cost is on the company, if it's external then you
share this cost with your customer.  A balence needs to be found
between increasing hardware requirements and the dropping cost of new
hardware.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

d.mikesell@computer.org (Dave Mikesell) wrote
> Don't forget cost to consumer.  If you can get your software out
> fastest with language J, but it requires the customer to upgrade
> hardware because it's a resource hog, you may have a problem.

Microsoft has demonstrated otherwise.

I'm not just talking about how each version of Windows requires more
RAM and disk space (and for a while, CPU model and video hardware) than
the one before it -- though that's proof enough.

They were also the first company to insist on packaging development
software for CDs. When Visual Studio 5 shipped, the packages with CDs
had a "certificate" good for the floppy disk version... but it would
take 8-12 weeks to ship and would cost extra (not available in stores).

Rather than hurting Microsoft's sales, it seems to have boosed the
economy by sending a lot of businesses shopping for CDs much earlier
than they otherwise would have.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0301091518.5ce6a79e@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>So what's an 'easy' language? COBOL? Basic?

Perhaps an easy language is one that well fits our thinking processes. I
can build simple mental models of how much of most procedural languages
work, that includes a large part of C++. Pure OO languages such as
Smaltalk are more difficult (for me) because some aspects of them seem
contrived and do not map cleanly to my thought processes. As a
mathematician I have little problem with TILs such as Forth (and taught
a considerable number of teenagers to use them). The Turtle Graphics
part of Logo is easy for almost everyone because it has an obvious
real-world mapping but the rest of Logo together with Prolog, Lisp
etc.cause me increasing confusion -- I just do not think that way.

While functional languages such as Haskell are fine for me, they do not
map well to the way that a lot of people think.

So what is an easy language? Superficially one that allows me to express
my intentions in a way that  is close to the way I think. Unfortunately
some languages map rather too easily to sloppy thinking :-)

>

--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

************************************************************
[Moderator's note: can those contributing to this thread
all please try to tie the discussion back to the topic of
C++ design and standardization?  -moderator.]
************************************************************

Glen <lpepicel@nycap.rr.com> wrote in message
news:<3E1B6E26.7070302@nycap.rr.com>...

>  > That's the inverse of what I said.  I did not claim that bare metal
>  > programmers were the worst.  I claimed that there is no barrier to
>  > bad programmers working on bare metal.

> I think it is right that there is no barrier to bad programmers
> working in 'hard' langs like C++ and assembly.

There's no barrier to bad programmers anywhere.  But...

> But I also think that most bad programs avoid hard langs in favor of
> very popular 'easy' ones.

I'm not sure that a really bad programmer can tell a hard language from
an easy one.  What I have seen is that bad programmers tend to follow
the latest fads.  In the beginning of the 90's, we got a lot of them in
C++.  Since then, Java has come along, and scooped most of them up.
(This is NOT a criticism of Java.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kaz@ashi.footprints.net (Kaz Kylheku) wrote in message news:<cf333042.0301081034.673020c3@posting.google.com>...
> shannon.barber@myrealbox.com (Shannon Barber) wrote in message news:<de001473.0301060824.7f0c065d@posting.google.com>...
> > kaz@ashi.footprints.net (Kaz Kylheku) wrote:
> > > > What language promotes the most humility in programmers?   I suggest
>  that
> > > > language as "best" because the quality of the code written in it is
>  probably
> > > > somewhat higher.
> > >
> > > That language is best which minimizes time-to-market, and defect
> > > rates.
> >
> > Well, those are only two software qualities of many.  What about
> > cost-to-build and cost-to-deploy?  It's no good to have zero-defect
> > software ready tomorrow if it cost a trillion dollars to do it.
>
> Throwing a trillion dollars at a software project won't make it
> materialize tomorrow. Nine women won't gestate a baby in one month. A
> shorter time-to-market is not necessarily more costly, in fact it is
> probably less costly. These are not independent variables.

It's a hyperbole; take eleven women and average (some could miscarry
or have other complications), or better yet find a pregnant women
who's about to give birth and buy her baby.  Voila, an expensive baby
"made" in one month :0)

To maximize any one quality, some others must suffer.  If we can lower
our time-to-market without sacrificing anything, then it's not an
interesting choice, just do it.  It becomes "interesting" when we must
sacrafice something else to accomplish it, e.g. the defect-rate or
cost-to-deploy.  This is where different systems must make difficult
choices - to garbage collect or not to collect garbage?

If you allow both, then you increase complexity.  This is what happned
to C++, it allows lots of freedom, so there's lots of complexity when
compared to Java which makes a number of architectural decisions for
you.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Dan'l Miller" <Daniel.Miller@tellabs.com> wrote:
> Shannon Barber wrote:
> > kaz@ashi.footprints.net (Kaz Kylheku) wrote:
> >
> >>>What language promotes the most humility in programmers?   I suggest
>  that
> >>>language as "best" because the quality of the code written in it is
>  probably
> >>>somewhat higher.
> >>
> >>That language is best which minimizes time-to-market, and defect
> >>rates.
> >
> >
> > Well, those are only two software qualities of many.  What about
> > cost-to-build and cost-to-deploy?  It's no good to have zero-defect
> > software ready tomorrow if it cost a trillion dollars to do it.
>
>    Since you think that cost-to-build and cost-to-deploy are valid
> metrics which
> must be considered as part of C++ language standardization orthogonal to
>
> time-to-market and defect-rates

They are not orthogonal but they are also affected by different
factors.  I do not have demographics in front of me, but I'm willing
to bet that Visual Basic programmers do not command the salaries that
C++ programmers do.  Even if it took longer to build a product in VB,
it could still cost less than building it in C++ because the
developers cost less.

My purpose was not to single out cost-to-build or cost-to-deploy, but
raise the question of what other qualities are important in addition
to time-to-market and minimizing defect-rates.

One portion of the standardization process that affects this, is the
standardization of libraries.  Right now, there's neither standard
networking, threading, nor GUI/WIMP mechanisms for C++.  Even when
there are standards, the vendors do not fully implement them (e.g.
STL).  This negatively affects all four qualities mentioned thus far.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:

> In article <7f2735a5.0301091518.5ce6a79e@posting.google.com>, Allan W
> <allan_w@my-dejanews.com> writes
> >So what's an 'easy' language? COBOL? Basic?
>
> Perhaps an easy language is one that well fits our thinking processes. I
> can build simple mental models of how much of most procedural languages
> work, that includes a large part of C++. Pure OO languages such as
> Smaltalk are more difficult (for me) because some aspects of them seem
> contrived and do not map cleanly to my thought processes. As a
> mathematician I have little problem with TILs such as Forth (and taught
> a considerable number of teenagers to use them). The Turtle Graphics
> part of Logo is easy for almost everyone because it has an obvious
> real-world mapping but the rest of Logo together with Prolog, Lisp
> etc.cause me increasing confusion -- I just do not think that way.
>
> While functional languages such as Haskell are fine for me, they do not
> map well to the way that a lot of people think.
>
> So what is an easy language? Superficially one that allows me to express
> my intentions in a way that  is close to the way I think. Unfortunately
> some languages map rather too easily to sloppy thinking :-)

I think the term "easy" needs a little refinement.  In the text above it is
not always clear whether easy is shorthand for easy-to-learn or easy-to-use.
Sometimes these properties are related, but often they are somewhat opposed,
especially if easy-to-use really means easy-to-use-well.   That latter
distinction tends to exclude the languages that promote sloppy thinking from
the domain of interest. (obligatory reference to Djikstra/BASIC/goto)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

shannon.barber@myrealbox.com (Shannon Barber) wrote in message
news:<de001473.0301060824.7f0c065d@posting.google.com>...
> kaz@ashi.footprints.net (Kaz Kylheku) wrote:
>>> What language promotes the most humility in programmers?   I suggest
>  that
>>> language as "best" because the quality of the code written in it is
>  probably
>>> somewhat higher.
>>
>> That language is best which minimizes time-to-market, and defect
>> rates.
>
> Well, those are only two software qualities of many.  What about
> cost-to-build and cost-to-deploy?

Don't forget cost to consumer.  If you can get your software out
fastest with language J, but it requires the customer to upgrade
hardware because it's a resource hog, you may have a problem.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

shannon.barber@myrealbox.com (Shannon Barber) wrote
> kaz@ashi.footprints.net (Kaz Kylheku) wrote:
> > That language is best which minimizes time-to-market, and defect
> > rates.
>
> Well, those are only two software qualities of many.  What about
> cost-to-build and cost-to-deploy?  It's no good to have zero-defect
> software ready tomorrow if it cost a trillion dollars to do it.

The early adopters always end up paying the most.
Surely the SECOND project in this language would only cost a few
hundred million? The third only a few dozen million?

Suppose the first, $1 trillion project, was one that automatically
fixed all programming problems instantly no matter what language was
used. As you know, missing subroutines (or even missing main routines)
are programming problems... so the program would write code for you,
if needed. Likewise for incorrect or incomplete designs or analysis.
For your $1 trillion investment, you now get an infinite amount of
perfect software instantly from now on. Just think of what you want,
and this program will develop it for you instantly.

Might be worth it. 'Course, it also puts us all out of work!

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

shannon.barber@myrealbox.com (Shannon Barber) wrote in message news:<de001473.0301060824.7f0c065d@posting.google.com>...
> kaz@ashi.footprints.net (Kaz Kylheku) wrote:
> > > What language promotes the most humility in programmers?   I suggest
>  that
> > > language as "best" because the quality of the code written in it is
>  probably
> > > somewhat higher.
> >
> > That language is best which minimizes time-to-market, and defect
> > rates.
>
> Well, those are only two software qualities of many.  What about
> cost-to-build and cost-to-deploy?  It's no good to have zero-defect
> software ready tomorrow if it cost a trillion dollars to do it.

Throwing a trillion dollars at a software project won't make it
materialize tomorrow. Nine women won't gestate a baby in one month. A
shorter time-to-market is not necessarily more costly, in fact it is
probably less costly. These are not independent variables.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

Shannon Barber wrote:
> kaz@ashi.footprints.net (Kaz Kylheku) wrote:
>
>>>What language promotes the most humility in programmers?   I suggest
that
>>>language as "best" because the quality of the code written in it is
probably
>>>somewhat higher.
>>
>>That language is best which minimizes time-to-market, and defect
>>rates.
>
>
> Well, those are only two software qualities of many.  What about
> cost-to-build and cost-to-deploy?  It's no good to have zero-defect
> software ready tomorrow if it cost a trillion dollars to do it.

   Since you think that cost-to-build and cost-to-deploy are valid
metrics which
must be considered as part of C++ language standardization orthogonal to

time-to-market and defect-rates (presumably because they contribute
factors
which are not already contributed by decreased time-to-market and
decreased
defect-rates as a vector in some N-dimensional cost-space which is to be

optimized), please itemize a set of real-world quantities:
   1) which, when present, cause increased cost-to-build and increased
cost-to-deploy
   2) but which, when present, do not contribute to increased
time-to-market and
to increased defect rates.
   And then for each of these cost-to-build and cost-to-deploy factors,
identify
how a C++ language-standard document can address them (as that would
relate to
the purpose of the comp.std.c++ newsgroup site to which this thread is
cross-posted.)

   As an example demonstration of what I am seeking, a factor which
contributes
to cost-to-build (e.g., cost to author code/implementation, cost to
design
technique/structure/mechanism, or cost to compile-and-link) is C++'s
ability to
support separate units of compilation which then can be analyzed for
dependencies on files which have changed since last compilation.  This
is the
foundational technique of make(1).  This effort-reduction via make(1)'s
analysis
of C++'s language-standard-required separate compilation units
contributes
directly to a reduced cost-to-build, due to reduced build-times and thus

begetting increased number of cycles and thus begetting decreased total
cycle
time and thus begetting less expenditure on engineer salaries and
betting less
expenditure on otherwise world-record-breakingly-fast computers/networks
for
building the software.  It is debatable whether this effort reduction
via
make(1)'s analysis of C++'s separate compilation units does or does not
directly
contribute to time-to-market reduction, since the time-to-market
reduction was
almost certainly incurred as a direct result of the reductions in total
cycle
time permitted by the increased number of builds per unit of time which
in turn
was permitted by the increased number of cycles of learning per unit of
time
which in turn was permitted by reduced time-to-build which is one direct
measure
of cost-to-build, incurring costs in two economically-crucial
quantifiable
metrics: (real-)time expended and human-resource consumption (e.g.,
salary,
hourly wage/billable-hours) of the engineer waiting for a build to
complete.

   Based on what I have seen time and again in my industrial experience,
I would
claim that every increased cost-to-build factor also directly
contributes to
increased time-to-market (and vice versa: that which increases
time-to-market
also increased some one or more quantifiable metrics of
cost-to-build/cost-of-production along the way), but I would like to see
the
opposing line of reasoning.

   The cost-to-deploy seems more likely to have factors which contribute
to
neither increased time-to-market nor increased defect-rates (unless one
contortedly construes the inability to afford the requisite deployment
royalties/costs as the most-severe infinite-trump-card-level
show-stopping
*defect* of all, which is a contortion which I am willing to grant as
being too
contrived of an excuse to fold cost-to-deploy into defect-rate).

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

\

 > That's the inverse of what I said.  I did not claim that bare metal
 > programmers were the worst.  I claimed that there is no barrier to bad
 > programmers working on bare metal.
 > ---


I think it is right that there is no barrier to bad programmers working
in 'hard' langs like C++ and assembly.  But I also think that most bad
programs avoid hard langs in favor of very popular 'easy' ones.

Also, without going on and on I'd just suggest that you will find bad
programs on most langs but you might find different types of bad guys on
different langs.  So if someone said "He/she is a bad C++ programmer"
"..is a bad VB programmers" "..is a bad Perl programmer" I would pretty
much have a different stereotype of all three in mind.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

Witless <witless@attbi.com> wrote:
> Francis Glassborow wrote:
>
> > I think the whole issue of which language is faster is a futile one.
> >
> > Let us have a new argument as to which language has the better
> > programmers. I guess something like 8051 assembler probably wins
that as
> > bad programmers keep away from getting quite so close to the metal
:-)
>
> If the definition of "bad programmer" is one who lacks skills, that's
true.
> But I don't think that's the proper definition.

> The figure of merit for a "bad programmer" is the ratio between their
opinion
> of their skills and an objective appraisal of their skills.  Given
that
> definition some of the worst programmers work directly on bare metal.

I think that's a rash statement to make.  I do not see any intrinsic
reason why 8051 programmers would have an inflated opinion of their
skills, relatively to other programmers.

> What language promotes the most humility in programmers?   I suggest
that
> language as "best" because the quality of the code written in it is
probably
> somewhat higher.

I do not think humility is right thing to focus on, nor do I think
that 'somewhat higher' is satisfactory goal.  If one does not aspire
for great things, great things do not happen.
I do not see how any language would invoke humility.  I experience
various flavors of disappointment.

Your topic is code quality, but I think you may mean more than the
quality of the code.  In-so-far as code quality is concerned, you want
to make it easy for someone else (or yourself at a future date) to
review the code and understand how it works.
Miss-paraphrasing Code Complete from memory; writing structured code
provides approx. a 30% increase in (relative) comprehension.  The
'absolute' result is about 8% more correct answers.  While I see this
is an improvement, it's not a solution.

What matters far more is the use of familiar structures to the
programmer.
The ancillary example in the book was recalling the position of Chess
pieces.  If the pieces were randomly arranged, then everyone recalled
the position of the pieces poorly.  If the pieces were arranged in
valid game-states, experts recalled the positions far better than
neophytes.


> What aspects of the suggested changes to C++ bear on the attitude of
its
> users?

This is a weak point of C++.  There are few standard methods for
accessing OS features.  What standards there are, are not implemented
satisfactorily on many platforms.

This is why, I think, projects such as ACE and Boost have great
potential to be valuable to the C++ community.  However, their value
is only realized if virtually everyone uses them, likewise with the
STL.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

kaz@ashi.footprints.net (Kaz Kylheku) wrote:
> > What language promotes the most humility in programmers?   I suggest
>  that
> > language as "best" because the quality of the code written in it is
>  probably
> > somewhat higher.
>
> That language is best which minimizes time-to-market, and defect
> rates.

Well, those are only two software qualities of many.  What about
cost-to-build and cost-to-deploy?  It's no good to have zero-defect
software ready tomorrow if it cost a trillion dollars to do it.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Shannon Barber wrote:

> Witless <witless@attbi.com> wrote:
> > Francis Glassborow wrote:
> >
> > > I think the whole issue of which language is faster is a futile one.
> > >
> > > Let us have a new argument as to which language has the better
> > > programmers. I guess something like 8051 assembler probably wins
> that as
> > > bad programmers keep away from getting quite so close to the metal
> :-)
> >
> > If the definition of "bad programmer" is one who lacks skills, that's
> true.
> > But I don't think that's the proper definition.
>
> > The figure of merit for a "bad programmer" is the ratio between their
> opinion
> > of their skills and an objective appraisal of their skills.  Given
> that
> > definition some of the worst programmers work directly on bare metal.
>
> I think that's a rash statement to make.  I do not see any intrinsic
> reason why 8051 programmers would have an inflated opinion of their
> skills, relatively to other programmers.

That's the inverse of what I said.  I did not claim that bare metal
programmers were the worst.  I claimed that there is no barrier to bad
programmers working on bare metal.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2 Jan 2003 07:48:35 -0500, Witless <witless@attbi.com> wrote:

>What language promotes the most humility in programmers?

Hmmm... I would say COBOL.

Anyway, does this humility concept has any proven
record ? I've seen many interesting things done by
people that were anything but humile about their code.

Even in other dimensions we have both Bach and Mozart,
Capablanca or Fisher, Ronaldo or Maradona. My impression
is that however, deep inside, a very high consideration
of our work is needed. Then you may be the bragging type
or not, but that's another story.

Andrea

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

aptly named Witless <witless@attbi.com> wrote in message
news:<3E12FA84.A859CC5B@attbi.com>...
> Francis Glassborow wrote:
>
> > I think the whole issue of which language is faster is a futile one.
> >
> > Let us have a new argument as to which language has the better
> > programmers. I guess something like 8051 assembler probably wins
that as
> > bad programmers keep away from getting quite so close to the metal
:-)
>
> If the definition of "bad programmer" is one who lacks skills, that's
true.
> But I don't think that's the proper definition.
>
> The figure of merit for a "bad programmer" is the ratio between their
opinion
> of their skills and an objective appraisal of their skills.  Given
that
> definition some of the worst programmers work directly on bare metal.
>
> What language promotes the most humility in programmers?   I suggest
that
> language as "best" because the quality of the code written in it is
probably
> somewhat higher.

That language is best which minimizes time-to-market, and defect
rates.

Humility in programmers has no value, if it is the result of having
them stumble over idiotic, productivity-wasting, defect-causing
obstacles.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

Francis Glassborow wrote:

> I think the whole issue of which language is faster is a futile one.
>
> Let us have a new argument as to which language has the better
> programmers. I guess something like 8051 assembler probably wins that as
> bad programmers keep away from getting quite so close to the metal :-)

If the definition of "bad programmer" is one who lacks skills, that's true.
But I don't think that's the proper definition.

The figure of merit for a "bad programmer" is the ratio between their opinion
of their skills and an objective appraisal of their skills.  Given that
definition some of the worst programmers work directly on bare metal.

What language promotes the most humility in programmers?   I suggest that
language as "best" because the quality of the code written in it is probably
somewhat higher.

What aspects of the suggested changes to C++ bear on the attitude of its
users?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]