Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]

[seebs@solutions.solon.com (Peter Seebach)]

In article <3202876B.BC7@online.no>, Alf P. Steinbach <alfps@online.no> wrote:
>Peter Seebach wrote:
>> And, if their language doesn't specify a binary representation, they may get
>> an algorithm right on a weird machine that still uses BCD or decimal
>> internally.

>Been to a museum lately?

Well, I work for a large corporation... :)

Who says binary is here to stay?  C will always act like it's on a binary
machine, unless they change that aspect of the standard, but assuming that all
languages will act like that is silly.  Among other things, who does bignums
in binary?

>(A)
>> >Any professional developer must understand several assembly languages,
>> >and how they work in general.

>(B)
>> I think this is no longer true.  Understanding an assembler buys you nothing;
>> all it tells you is that at least one machine had a certain kind of semantics
>> inside it.  You *don't care*.  If you're writing a *solution* to a *problem*,
>> those are the only things you need to be working with.

>Pardon me, but this is utter bullshit, both (A) and the response (B).  That
>(A) is untrue is not necessary to discuss.  (B) is more subtle, but builds on
>several assumptions, which can be summed up as a "mathematicians" view of
>programming:  only abstract semantics matter.  At least when discussing C,
>the most popular high level assembler in existence, that argument is
>clearly not valid.  Could be valid in other contexts, though.

I would say it certainly *is* valid.  I have a tiny little 75k project I've
written over the last couple of weeks, and it doesn't depend in any way on
anything but the abstract semantics of the language.  It's not like you *need*
anything else for the majority of code.

I'm a reasonably active real-world programmer, and I concern myself
exclusively with the abstract semantics.  I believe this is called an
existance proof.

>The advice as misguiding advice
>says something quite different:  disregard the machine completely.  That's
>stupid.  When you build a house, you need both a good understanding of the
>plans (abstractions) and the physical materials and other resources. 
>Disregarding or playing down the importance of one or the other leads to
>failure.

It is a common mistake to assume that the machine is the building block of
code.  This is true only in device drivers.  In the majority of code, your
building materials can be, and *must* be, the abstract semantics of the
language.  To write good code, you generally have to ignore the machine
entirely, and leave the machine details to the compiler.

Anything else leads to code which is too tightly coupled to your understanding
of a given machine.

>A very nice goal (getting paid for programming without using computers would
>indeed be ideal).  Aber doch, porting isn't quite that easy... :-)

*I* always find porting easy.  Generally, 50% of my porting time is waiting
for the compile.  The other 50% is writing a makefile for a new platform.
Hmm.  As soon as I eliminate my current bug, I'll try to compile this program
under Borland C, MPW on the Mac, and SAS/C on the Amiga.  I betcha it all
compiles and runs without trouble.  This is about 75k of code, written over
about 3 weeks *exclusively* on BSD-derived Unix using gcc to compile.

Any bets?  :)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.