Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Why pascal is not good

Author: Keith Evans

Date: 21:46:15 07/29/03

Go up one level in this thread


On July 29, 2003 at 22:31:46, Vincent Diepeveen wrote:

>On July 29, 2003 at 20:16:59, Matthew White wrote:
>
>>On July 29, 2003 at 16:53:05, Vincent Diepeveen wrote:
>>
>>>On July 29, 2003 at 03:15:54, Hristo wrote:
>>>
>>>>On July 28, 2003 at 19:12:56, Vincent Diepeveen wrote:
>>>>
>>>>>On July 28, 2003 at 17:34:46, Russell Reagan wrote:
>>>>>
>>>>>>Is there any reason to start new projects with C anymore? It seems like most (if
>>>>>>not all) of the drawbacks of C++ have faded away with modern compilers.
>>>>>>
>>>>>>Note that I am talking about new projects, and maintaining old projects is
>>>>>>obviously a good reason to still use C.
>>>>>
>>>>>If i would learn coding today i would prefer C++.
>>>>>
>>>>>However let's be clear, for good programmers there is not much diff between C
>>>>>and C++. Every complex problem which you can solve in 10000 lines of C++ you can
>>>>>solve in 10000 lines C too.
>>>>>
>>>>
>>>>Vincent,
>>>>with all due respect I must disagree. In 10K lines of C++ code one can solve a
>>>>much more general or larger set of problem(s) or cram in more features. :)
>>>>(think templates, exceptions, and often inheritance ... all of which can shorten
>>>>your code)
>>>
>>>I do not know about you, but i program both in C and C++.
>>>
>>>Do you?
>>>
>>>Not a single program where you can use all the nice toys you can also make a few
>>>functions for in C.
>>>
>>>In general the average programmed C++ program you program more compact in C.
>>>
>>>That's not what i'm talking about.
>>>
>>>If you do not know how to program in C, then just say it loud instead of writing
>>>it down like this.
>>>
>>>the advantages of what you mention here (assuming 1 man products) you can show
>>>great in 50 line examples or even 200 line examples.
>>>
>>>But as soon as you write a 10000 line product then it doesn't matter what you do
>>>in C++. I can do the same in C too. No problem!
>>>
>>>>In your post, latter, you indicate that C++ offers some advantages over C,
>>>>especially for large projects. In my experience this is %100 true, so we are in
>>>
>>>I see no other advantages to C++ than for big projects in fact.
>>>
>>>The advantage is *really* huge there for companies.
>>>
>>>Given the importance of those companies for the world, the choice to teach
>>>students C++ instead of C is a logical choice.
>>>
>>>teaching them Java, delphi i find a bad idea.
>>>
>>The best reason that I see to teach students using Java is that Java gives you
>>useful information when an error occurs (remember the first time you saw a
>>segmentation fault how lost you felt?). Java has strong typing and it FORCES
>>object orientedness. C and C++ are too frustrating for new programmers...
>>
>>Matt
>
>I agree fully with Bob here. His Pascal argument is very valid.
>
>Let me give you a bunch of reasons why you should not teach in a language like
>that JAVA or delphi or pascal:
>
>  1) the students will later use the language they are learned. So
>     if you directly learn them C++ they will use that. now they are doomed
>     to use java or pascal because that's what they are familiar with.
>  2) your students will earn thanks to that you learned them this toy language
>     a lot less. C++ programmers earn better than Java programmers in general.
>     In fact even some 'older' languages like fortran earn very well.
>     Majority of
>     programmers in netherlands at the KPN (which is about a 1000) is fortran
>     programmers just to give an example. But also at supercomputers fortran
>     is very important.
>  3) If you learn them C++ you achieve 3 objectives at the same time
>       3a - they learn a language they can later use
>       3b - you can show them the great things of object orientation
>            in 50 line programs
>       3c - they are not fearing to program in C++ as they are familiar with it
>  4) In big companies decisions get taken by management. Not by programmers.
>     Managers in general are doing what is good for their company.
>     If statistics show that 80% of all programmers with very small shoe
>     sizes will make buggy code, then in theory the law doesn't allow you
>     to discriminate. However managers do not work like the law there. They
>     fear hiring someone who writes buggy code, so they never hire someone
>     with a small shoe size if that statistic would be the case.
>     Same is true for Pascal. Pascal is for newbies, exactly as you say so.
>     Therefore managers will not hire people who are good in pascal, because
>     a manager always finds out the truth. With his questions to the programmer
>     the programmer in the end will confess he's better in pascal than in
>     C++, so the manager concludes he's a pascal coder. So the programmer
>     deduces from that he gotta be a crappy coder. So he isn't hired.
>     Managers work very instinctive and they should. They are there to prevent
>     disasters for their company, not to play the advocate of the devil which
>     will say that a coder isn't a bad coder unless you have clear proof
>     of that. Trivially it's easier to not hire someone than to fire someone.
>   5) This really is important. In university and colleges they still do not
>understand a thing very well and that is that 99% of the time you are busy
>fixing bugs and 1% of the time you are busy creating something new. I will not
>say throwing someone in the deep is a good thing. I have no opinion there.
>But for sure it is better to learn to debug. Example at my own university out of
>all the years that i was there i saw only 1 course which had 1 sheet which said
>that debugging was important.
>
>All the other theories about debugging i have figured out myself. What is a
>boundschecker. How the debugger works and how to effectively write testbeds.
>
>Your simple programming language when preventing severe bugs will definitely
>create a bad coder. Someone who can't debug. That's a horror.
>
>If someone has followed your course i bet he can't debug. yet 99% of his time he
>will lose debugging in his programming career.
>

A while back I worked at a company that built MPEG encoders using custom
hardware that interfaced to the Macintosh platform. That was back in the days
before "OS X" existed and it was trivial to crash the whole Mac OS with a bad
pointer or similar problem.

Anyways the GUI guys always made potential interviewees draw a stack frame and
explain how to figure out why a program crashed. The low level debuggers were
simply horrid, and they didn't want to hire anybody that didn't have this
necessary skill. (Macsbug was the basic free one, but real men had to use
Jasik's "The Debugger.")

A lot of recent grads thought that this was a ridiculous interview question, and
it just showed that they hadn't done much development on the Mac. They were
silly enough to think that the source level debuggers actually worked on the Mac
at the time...

It was funny because at that company the GUI guys used straight C code (they did
have a nice plug in architecture though), and the device driver guys were using
C++. Sick!

-K



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.