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 <4u55hu$o73@dawn.mmm.com>, Chris Sonnack <cjsonnack@mmm.com> wrote:
>Peter Seebach (seebs@solutions.solon.com) wrote:
>> Understanding an assembler buys you nothing;
>                                      ^^^^^^^
>That's taking it too far the other way.

Oh, my, I think my fanatacism is showing again.

>Understanding assembler //helps// you learn C faster. I've seen it with
>my own eyes and experienced it personally (see previous post). I wouldn't
>care to code assembly now; I don't think in terms of assembly when I write
>C; and I sure as hell don't use the asm() feature of C. But knowing what
>it is that I'm really turning out has been helpful.

C has no asm() feature.  There is no provision in the C language for inline
assembly.

A little knowledge is dangerous.  In the hands of an inexperienced programmer
learning C, assembly is like a Herb Schildt book - it gets you into a language
much faster.  Unfortunately, the language you learn isn't really C.  Assembly
tends to teach you a language in which the effects of overflow on signed
integers and floating point numbers are well defined, where address literals
are meaningful, and where you know all sorts of useful things about the layout
of memory.

An interesting language, but not C.

Some people manage to avoid this trap.  To them, assembly is powerful and
helpful, and exposes them to a good understanding of the underlying system.
But this is a good thing only when you can distinguish between a particular
underlying system, and the semantics of the C language.

>And I've been able to troubleshoot some really bizarre problems FASTER by
>either looking as the ASM output (via the -S switch most compilers support)
>or by tracing code in a debugger at the ASM level. Not that I couldn't have
>fixed the problem at a high level; I just did it //faster// at a low one.

I have a compiler where the ASM output is *NOT* used in normal compilation; it
may differ in internals or semantics from the normal compilation, which
compiles to an intermediate format, and then direct to object code.

>Agree on both points. But, again, you're a more effective tool if you
>DO know what's going on "under the hood".

If it's really going on, yes.  But it's *very* dangerous when you get confused
about what's really going on vs. what may have gone on once.

>Absolutely. Programming is about solving problems. A true programmer knows
>how to analyze a problem and synthesize a solution. The language doesn't
>matter; not really. The language is just the local way of expressing the
>solution.

I've written a couple of languages.  In my experience, you can tell whether a
language is complete or not by whether or not you can program in it.  If you
can find tasks you can't do, the language isn't finished yet.

>HOWEVER: it seems obvious to me that the more you know about your craft,
>the better you will be at deriving the most effective solution. And the
>better you'll be at dealing with problems along the path to that solution.

Probably.  I may eventually learn an assembly or two, out of curiousity.  But
I'm more likely to learn Icon, which I love but do not comprehend, and scheme,
first.  They'll teach me a lot more.  Assembly is just unportable, limited C,
without structures.  Why bother?  I know that model already.

-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.