google "top coder" contest = stacked against C++ coders

[Nicolas Pavlidis]

(e-mail address removed) (Jerry Coffin) wrote in message


I disagree. I think learning STL is more difficult than learning C++.
What with traits and policies etc, I think this is best left to
specialists.

Here is a nother problem, the documentation. The documentation of SGI is
one of the "best". And to find a good tutorial on the net is like
searching for dead pointers on the heap . Without a (most times
expensive) book one can not learn STL in a way that makes him know a
lot.

But a least it is absolutely necessary to learn STL, or better the C++
Standardlibrary. It's a very useful part of Standard C++. Leaving it out
would be the same as for example, learning Java without its library.

Everyone thinks that he or she can do it better, I thought that way
myself, but if you think about which decisions were taken before clases
like std::vector, std::list or algorithms like std::for_each and so on
were implemented, you'll understand that there is no sense in inveting
the whell several times.

C++ give every programmer, or better softwaredeveloper, the tool to do
things right or possibly wrong, STL is definitely atool to make
things right, even if its a bit hard to learn.

There are problems, like threadsavety, but I'm sure that this things
will be corected by those people who are working on the library.

Kind regrads,
Nicolas

 

[Francis Glassborow]

I prefer to be open minded, and hence prefer to think that
portabilty can apply to many areas. And I agree that 100%
portability can sometimes be hard to achieve, even with option a,
whatever it means. As with the compromises mentioned above,
instead of dealing with perfection, I prefer to think we're
dealing with something relative, since it too will have its
pros and cons, etc. Same things can be said of efficiency
and many other things. So to me, whatever it is that we're
talking about that can be portable, we wanna strive for it
the right dynamics of adapability, extensibililty, design,
API, etc etc. realizing there will be cases where it might break,
need an alternative, whatever.

Let me add a little more on the value of portability even to novice
programmers. My co-author of You Can Do It! wrote a program that greatly
impressed a group of friends and others who are interested in a somewhat
esoteric problem domain. This program did something they wanted to do
and there were no other competing programs. None of them were
programmers. So here we have a newcomer to programming writing something
useful and of interest to a specialist group. Then one of the group
asked if he could have a copy of the program to run on his Apple Mac. No
he wasn't naive and realised that it would have to be recompiled.
However the problem was that there was no implementation of my
minimalist GUI library for a Mac. Deep disappointment all round.

Note that porting my library to other platforms requires someone with
quite a bit of knowledge (and yes, it is now available for Linux and
OS X systems as well as MS Windows ones). However anyone porting the
programs rather than a support library will need exactly the same level
of skill and knowledge. Placing the material in a library empowers
others to write correct and tested programs on one platform and have
others use the results on entirely different ones.

I contend that novices as well as commercial programmers greatly benefit
from well designed libraries that can be ported to all suitable
platforms.

The concept of writing, testing and debugging a linked list
implementation every time I want one (or even just the first time I need
one for a specific type) is taking the 'not invented here' view to
ridiculous and costly extremes.

Part of being a skilled MS Windows programmer lies in knowing how to
handle (dynamic) objects across DLL boundaries. Those skills are
independent of the actual objects and are applicable to Standard Library
based ones just as much as they are to home-brewed ones.

 

[Francis Glassborow]

I disagree. I think learning STL is more difficult than learning C++.
What with traits and policies etc, I think this is best left to
specialists.

Full, complete knowledge of the STL is hard, but so is full, complete
knowledge of the core C++ language. However using a working subset is
much easier. For example programmers do not need to concern themselves
with the second parameter of std::vector or with the latter parameter of
std::sort. They may never have to worry about the former and only the
latter when they have a need to do so.

One of the great positive aspects of the STL (however you choose to
interpret that acronym) is that you can learn it on a basis of what is
useful to you today. You do not need to know even 5% of it to start
getting benefit. You can use vector, map, linked-list, sort, partial
sort etc. long before you are a sufficiently skilled programmer to write
safe versions of those things for yourself.

 

[Greg Comeau]

Let me add a little more on the value of portability even to novice
programmers. My co-author of You Can Do It! wrote a program that greatly
impressed a group of friends and others who are interested in a somewhat
esoteric problem domain. This program did something they wanted to do
and there were no other competing programs. None of them were
programmers. So here we have a newcomer to programming writing something
useful and of interest to a specialist group. Then one of the group
asked if he could have a copy of the program to run on his Apple Mac. No
he wasn't naive and realised that it would have to be recompiled.
However the problem was that there was no implementation of my
minimalist GUI library for a Mac. Deep disappointment all round.

Note that porting my library to other platforms requires someone with
quite a bit of knowledge (and yes, it is now available for Linux and
OS X systems as well as MS Windows ones). However anyone porting the
programs rather than a support library will need exactly the same level
of skill and knowledge. Placing the material in a library empowers
others to write correct and tested programs on one platform and have
others use the results on entirely different ones.

I contend that novices as well as commercial programmers greatly benefit
from well designed libraries that can be ported to all suitable
platforms.

The concept of writing, testing and debugging a linked list
implementation every time I want one (or even just the first time I need
one for a specific type) is taking the 'not invented here' view to
ridiculous and costly extremes.

Part of being a skilled MS Windows programmer lies in knowing how to
handle (dynamic) objects across DLL boundaries. Those skills are
independent of the actual objects and are applicable to Standard Library
based ones just as much as they are to home-brewed ones.

Indeed. Furthermore, I will even go so far as to say that
some of those principals (requiring skill, forethought,
a well designed library, etc) also apply to code that does not
need to be portable. Otherwise, code is just pounded out,
ill designed, unnecessarily laced with dependencies, etc.
I am not saying the concerns are equal, but that it might
be highly dependent on something does not necessarily mean
tossing all such concerns or combos of them, and actually
may mean placing additional concerns.

 

[Jerry Coffin]

(e-mail address removed) (Paul) wrote in message
[ ... ]

I'll start by pointing out that I'm taking "STL" to mean the
containers, iterators and algorithms in the standard library -- the OP
was talking about the Google top coder contest, and based on looking
at their contest materials, that seems to be the correct
interpretation.

I disagree. I think learning STL is more difficult than learning C++.

If there's any logic here, I have a hard time following it. STL is
_part of_ C++. Learning C++ includes learning STL, and quite a few
other things as well. As such, I have tremendous difficulty
understanding how it would be possible for learning X+Y to be easier
than learning X alone. In any case, as I said before, I advocate
learning X and Y together as an integrated whole. You say you
disagree, but then say that learning the whole is easier than learning
the one part alone.

As far as I can tell, then, you not only think it's easier to learn
the whole than the part, but since you go on to say that's not the
right way to do things, you apparently also believe that making it
easier to learn should NOT be done. Either you haven't said what you
really intended to, or else we'll have to agree to disagree. I, for
one, believe that C++ provides enough challenges without our throwing
artificial ones in the way of a student.

What with traits and policies etc, I think this is best left to
specialists.

I certainly agree that beginners (most of them anyway) probably don't
want to (and shouldn't be forced to) learn _every detail_ of every
container, etc. That doesn't mean ignoring them entirely though. Much
the same is true in general: a rank beginner doesn't need (or normally
want) to learn all the intimate details of virtual inheritance,
two-phase name lookup, similarities and differences between partial
specialization of class templates vs. partial ordering of function
templates, all the rules of conversions between signed and unsigned,
etc., ad naseum.

Nonetheless, if somebody remains ignorant of inheritance in general,
templates in general, and even simple expressions in general, it would
be hard to see how that person could be said to have any more than a
truly minimal knowledge of C++.

[ ... ]

I don't think he is ignorant,

He's openly professed his ignorance of STL, so the only way he's NOT
ignorant of this subject is if he's really lying and DOES know STL
after all.

I think a bare minimum of decency requires that you either provide
evidence to back your accusation that he's lying, or else that you
apologize and retract the accusation.

STL should be a standard extension to the language and not an integral
part of the language.

Your opinion of how things should be is irrelevant to the question of
how it IS right now. The fact is, that as it stands right now, the
standard library is standardized right along with the rest of C++, and
the standard library includes algorithms, iterators and containers.
Your wishes to the contrary have no effect on that.

Templates is the part of the language we need to acknowledge here.

You are, of course, entitled to your opinion. If, however, you want
any of us to believe it, you would do well to provide some backing for
it. An obvious argument would be to show how your readers collectively
would benefit if it was made an extension.

I consider arrays to be a more significant part of the language than
vectors, plenty around here disagree , you seem to be one of the STL
fans.

I find the containers and algorithms in the standard library quite
useful, but in the end, my opinion on the matter is more or less
irrelevant. You can find "arrays to be a more significant part of the
language", but your opinion is irrelevant as well.

The question at hand is fairly simple: what constitutes C++. The
answer is also quite simple: C++ is exactly (nothing more and nothing
less) that what the C++ standard says it is. As it happens, that
includes a standard library which, in turn, includes iterators,
algorithms and containers.

As such, knowing C++ involves knowing those iterators, algorithms and
containers.

I definately look upon STL and 'the language' as 2 different things,
as the OP seems to do.

I agree that the standard library is separate from the language, but
C++ includes both.

If you're honestly advocating that the language should be taught in
isolation from the standard library, I'm forced to disagree -- without
the standard library you have only two choices: write only totally
platform-specific programs, or else write programs that are utterly
useless.

Your leaning heavilly on this 'ignorance' thing you've made up here, I
think your out of order. I'm not ignorant.

I've made nothing up -- as I've already pointed out, the OP started
out by openly stating his ignorance of the STL.

Your claim that you're not ignorant leads to only two possible
conclusions: either you're ignorant of what you're saying, or else
you're the most conceited person I've ever even heard of. The only
possible alternative to being ignorant is to know _everything_.

[ ... ]

After calling the guy lazy and ignorant, what makes you think you have
the right to preech about what does or doesn't make a good programmer?

I would have thought the answer to that was obvious: arrogance!

[ ... ]

What happened to creativity?

Nothing, to my knowledge. I didn't claim to be giving an exhaustive
list of all the traits of a good programmer, or anything like it.

Nonetheless, since you've brought it up, I'll address it directly:
while creativity is extremely useful in some situations, I'm fairly
sure somebody could be quite a good programmer with little or no
creativity. Admittedly, I think somebody who's more creative is likely
to be a BETTER programmer, but I'd guess that many (probably most,
truth to tell) managers of programmers wish their people were LESS
creative as a rule.

You do not seem to understand 'The will to succeed' and what drives
women/men, it certainly doesn't derive from arrogance.

As always, you're entitled to your opinion. So far, I see little
reason to consider your opinion on this subject more accurate than my
own.

Consider, just for a moment, one obvious measure of the bases of our
opinions: the degree to which we know other C++ programmers via our
interaction on Usenet. A quick check on Google shows that you've
posted around a dozen articles over the course of approximately one
month.

I'm almost scared by the degree of geekiness implied by my own
statistics: somewhere around 11,000 articles posted over the course of
nearly a decade. If there was a list of the 100 best C++ programmers
on earth, there's a pretty fair chance that I've conversed (or argued)
with the majority of them at least once, and in many cases have had a
more or less ongoing dialog for years.

Now, I'm the first to admit that by itself that doesn't _prove_
anything -- but I think it does give at least a minimal indication
that when I say something about what is or is not involved in being a
good programmer, that there's at least the _possibility_ that I might
know what I'm talking about.

If you read even a small sampling of those articles, I'm fairly sure
you'll realize that regardless of programming ability, that at least
in the area of arrogance, my background and personal experience are
nearly unequalled!

 

[Francis Glassborow]

If you read even a small sampling of those articles, I'm fairly sure
you'll realize that regardless of programming ability, that at least
in the area of arrogance, my background and personal experience are
nearly unequalled!

I used to tell my maths students that there were three essential
qualities required for success: laziness (not wanting to do work that
could be avoided), an unlimited desire to solve problems and the
arrogance to think you can.

I think much the same qualities are required for success as a master
programmer. However like maths, it is possible to be a perfectly good
journeyman without all those qualities, you just won't ever be a master.

However there are other desirable qualities for a master of anything,
one of which is the humility to learn from ones students and give them
credit for what they teach you.

 

[Old Wolf]

perhaps not every one on the group is a native speaker of English?

In my experience, native speakers of English make this mistake
much more often than people who've learned English from a book.

 

[assaarpa]

Oops! This cannot be guaranteed to work, someone might have..

#undef add
#undef a
#undef b

Now it can be guaranteed to COMPILE, the code I posted didn't and that is
what was being asked of me to provide.

 

[George Privalov]

Now,


Yes, it is.

std::string foo();

If you call that method across dll boundary, you crash and burn. Bye bye
reusability. QED.

I think you are just forgetting that template objects are instantiated
at compile and there are differences in flags at which DLL and calling
program is compiled that may lead to incompatibility of the objects
generated in two project. I can not imagine the worse applications
for templates in general than to call them from separate project
spaces be it DLL or LIB.

I hope there is no need to remind that STL stands for Standard
TEMPLATE Library.

 

[assaarpa]

I think you are just forgetting that template objects are instantiated

at compile and there are differences in flags at which DLL and calling
program is compiled that may lead to incompatibility of the objects

I'm not and that's why don't use std::string, among other things, in
sourcecode that must be portable and provide communication between different
modules of compiled project (think plugins that are dynamically loaded be
they dll, so, whatever).

Some libraries, however, that are deployed, do, therefore have to provide
translation layer between our modular architechture and the std::string
(among other things) using sourcecode, which is supposed to be, "portable"
and "reusable" -- which is what they should be, according to the standard,
but in practise, fail to be.

You can take perfectly solid, portable, functional code and have it fail
miserably in real production use. You cannot rely on code being portable
just because it was "written correctly"-- portability is abstract concept,
it gives promise that within certain parameters the code can be expected not
to invoke undefined behaviour but in the real world you will be hard pressed
to find such ideal platform and system where everything "just works like it
should", precisely the reason why standardization process itself took, what,
a decade?

When someone says that sourcecode is portable, that just means that there
are no side effects or invocation of undefined behaviour because some
obscure design rules were broken. It just means that the code is clean of
such behavious but doesn't mean when you actually go and compile it on
unspecified platform it would actually go and function as the programmer
intended or expects.

Obviously the goal is to write code that has POTENTIAL to function correctly
on as wide range of platforms as possible, but that's as far as it goes.
Sorry that I don't believe in portability except as a tool to achieve a set
of goals.

The fundamental of design of C++ is a bit perverse, one one hand the goal is
to generate efficient translation to architechture specific language, and on
the other hand the goal is to do this regardless of the architechture! To
satisfy both of these design criteria from client's point of view it means
taking all the constraints these requrements put to the design of the
language syntax and semantics, means a lot of work for the programmer when
the idea was to take the work away from the programmer.

There are plenty of instances when you can easily write so-called portable
code. But times come, when you are writing code for a specific
architechture, this code by nature is non-portable. When you write code for
Sony Playstation2 using their libraries, is this code portable? No, it is
not. When you are writing code for embedded or mobile device, and have
hardware-specific (!) formats to work with, just because you use c++ to
program for these platforms, do you and can you write "portable code"? Maybe
you can maybe you can't.

Such discussions are not appropriate to these newsgroups, since they are not
c++ specific the c++ in these topics is just tool used to do some specific
work, but this crystallizes one aspect of writing c++ code: just because
code isn't "portable", it doesn't mean that the code is without value,
poorly written or just plain wrong. If you have a job to do, you can do it
in c++, or you can choose completely different language only for the merit
that you aren't "being a shitty programmer and look for another line of work
just because a guy in Usenet said so". When I have a job to do, say, to
implement a OCP support in device driver kit for ARM9 I wouldn't care less
if the code, even if written in c++, is portable or not as long as the
interface is more generic and allows to drop the module into different
environments w/o too much extra investment.

But as said, this is not c++ specific, that is just applying c++ to real
world problems.. which is, well, as Kipling would say, another story.

 

[JKop]

Old Wolf posted:

of English?

In my experience, native speakers of English make this mistake
much more often than people who've learned English from a

book.

Some people will always write crap... no matter what the
language.

-JKop

 

[Paul]

I used to tell my maths students that there were three essential
qualities required for success: laziness (not wanting to do work that
could be avoided), an unlimited desire to solve problems and the
arrogance to think you can.

I think much the same qualities are required for success as a master
programmer. However like maths, it is possible to be a perfectly good
journeyman without all those qualities, you just won't ever be a master.

However there are other desirable qualities for a master of anything,
one of which is the humility to learn from ones students and give them
credit for what they teach you.

Laziness(not wanting to do unneccessary work)
Laziness is a negative trait , this was a joke thing.
It does not make sense for a mathematical genius to do long division
by hand or to use logarithm tables when we have calculators, this is
not really laziness it'a common sense.

Arrogance again is a negative trait, being proud is a good thing and
when someone is correct there is no harm in them being proud but when
someone is arrogant they are proud whether they are correct or not.
This is plain wrong.

I have heard teachers use laziness in this way before but it was
rapidly followed with a "haha" to ensure that his intention was a
joke. I have seen an attempt at this arrogance thing as a joke too but
it never went down too well with the class, everyone looked at each
other bewildered and straight faced, and there were no laughs.
Arrogance doesn't fit here.

Seems to me that you are trying to use arrogance in place of "pride of
work" and/or "confidence". No-one likes an arrogant bastard so it
doesn't fit.

Paul.

 

[Val]

This discussion should take place in fron of many C++ teachers who teach at a university or teachers who try to teach
quality C++ coding at a high school or so.
The relactance to learn STL - for younger ones especially - is a direct negative spin-off from their education at school
or uni.
I know many students:
` They learn the very basics of C++.
` Then they learn about arrays without knowing about pointers often.
` Then they learn about pointers.
` Then they have quite a few excersises to get decent with pointers and arrays handling.
` Then they reach a level beyond this homework.
` Then they learn to actually code the datastructures they learned during the data structures classes.
` Then they learn to actually code the algorithms they read about in the school books.

Guess what.
a ) The teachers make them use arrays over and over again. The teachers present code with practially no STL containers
and algortihms.
b) The teachers present them "concepts" by showing sample "driver" code in their "int main()" so the students can "see"
what the teachers wants from them.

Two things that come immediatly to my mind:
- ad a:
Many students think after while they are comfortable with arrays and pointer handling. And when you're feeling
comfortable, why teaching something "new" like
STL? Once they try, they will encounter insights that no most teachers didn't even mention.
- ad b:
Many students learned from the ground up to think in terms of a "driver" sample to start design and coding. EVEN when
they attended the "Analisys and Design" classes.

Therefore, I personally doubt that many younger laddies (and ladies) have the *capacity* to analyse if they want to
learn STL or not.
And I blame the teachers. That's my whole point basically.
I am a crappy coder myself. But I do my best not to make the same mistakes wich I described above

Coding is communicating,
Val

 

[jeffc]

I recently tried out the Google "top coder" contest, as a C++
coder. I noticed immediately that they expected me to know STL.
To which I say, what the ****?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL? I ask because at every
job I've had, and every job interview for that matter, whenever
STL comes up it's not I, but a manager who says effectively
yuck, we don't use that crap.

I've never seen anywhere that DIDN'T use it, or some equivalent. And "some
equivalent" is only used when the compiler is too old, or some such reason.
I've used C++ with STL, or the Micrsoft version (MFC) in Visual C++, or
third party libraries such as RoqueWave that provide basically the same
thing. How could you code very productively in C++ withOUT that stuff?

 

[jeffc]

You seem to be a bit out of touch. This is akin to saying
"I went for a programming interview for a C job and they
expected me to know pointers.

I wouldn't say that. I'd say it's more akin to buying Visual C++, and then
just using the command line.

 

[Francis Glassborow]

Seems to me that you are trying to use arrogance in place of "pride of
work" and/or "confidence". No-one likes an arrogant bastard so it
doesn't fit.

No, I meant what I said. Believing you can do something that has never
been done before requires arrogance, not pride in ones work. I also sort
of meant laziness but not quite. It is the quality that drives the
person to want an efficient solution rather than just a solution. It is
why any mathematician worthy of the name finds the current proof of the
four-colour map problem some how inadequate. It lacks any insight, any
revealing quality and it just a tedious proof by exhaustion (in this
case so exhaustive that it needs a computer to do it

 

[Tabrez Iqbal]

Laziness(not wanting to do unneccessary work)
Laziness is a negative trait , this was a joke thing.
It does not make sense for a mathematical genius to do long division
by hand or to use logarithm tables when we have calculators, this is
not really laziness it'a common sense.

Arrogance again is a negative trait, being proud is a good thing and
when someone is correct there is no harm in them being proud but when
someone is arrogant they are proud whether they are correct or not.
This is plain wrong.

I have heard teachers use laziness in this way before but it was
rapidly followed with a "haha" to ensure that his intention was a
joke. I have seen an attempt at this arrogance thing as a joke too but
it never went down too well with the class, everyone looked at each
other bewildered and straight faced, and there were no laughs.
Arrogance doesn't fit here.

Seems to me that you are trying to use arrogance in place of "pride of
work" and/or "confidence". No-one likes an arrogant bastard so it
doesn't fit.

Paul.

I first read about this so called virtue "laziness" in Larry Wall's
"Programming Perl" and then in some of his articles.

"We will encourage you to develop three great virtues of a programmer:
laziness, impatience, and hubris."

"A truly great computer programmer is lazy, impatient and full of
hubris, says Larry Wall. Laziness drives one to work very hard to
avoid future work for a future self.[snip]"

I quite liked the differentiation between two kinds of laziness -
whether you are too "lazy" to spend some time designing your app and
so directly start the implemention or too "lazy" to invest lots of
time in making it work by trial-and-error cycles and hence will design
the app first. the latter "laziness" is preferred to the former, and
someone may chose to call it "common sense".

tabrez

 

[Paul]

I first read about this so called virtue "laziness" in Larry Wall's
"Programming Perl" and then in some of his articles.

"We will encourage you to develop three great virtues of a programmer:
laziness, impatience, and hubris."

"A truly great computer programmer is lazy, impatient and full of
hubris, says Larry Wall. Laziness drives one to work very hard to
avoid future work for a future self.[snip]"

I quite liked the differentiation between two kinds of laziness -
whether you are too "lazy" to spend some time designing your app and
so directly start the implemention or too "lazy" to invest lots of
time in making it work by trial-and-error cycles and hence will design
the app first. the latter "laziness" is preferred to the former, and
someone may chose to call it "common sense".

tabrez

I hope you got your money back !


Paul

 

[nebjy]

I first read about this so called virtue "laziness" in Larry Wall's
"Programming Perl" and then in some of his articles.

"We will encourage you to develop three great virtues of a programmer:
laziness, impatience, and hubris."

"A truly great computer programmer is lazy, impatient and full of
hubris, says Larry Wall. Laziness drives one to work very hard to
avoid future work for a future self.[snip]"

I think that the use of the word "laziness" is justified in this
sense... rather than meaning sloth, it's a desire to not do more work
than is needed to complete a task. It's efficiency. So if someone
accuses you of being lazy, you can tell them "I'm not lazy, I'm efficient!"

 

[White Wolf]

And with the attitude he has, he is unlikely to work for a company that
uses the Standard C++ Library.

With that attitude he is unlikely to work at any company, unless it serving
clients with excuses or ranting.