first language

75 views
Skip to first unread message

Fred Kunkel

unread,
Jun 17, 1998, 3:00:00 AM6/17/98
to

Is perl a good language for the non-programer to attempt learning a cgi
programing language? Is there a logical aproach to learning perl or
should one start with some other language that might be easier to
understand?

Tom Phoenix

unread,
Jun 18, 1998, 3:00:00 AM6/18/98
to

First and foremost, Perl is not "a CGI programming language". Sure, most
web-related things involve Perl in some way. But most of Perl has nothing
to do with the web. And yes, you can do CGI programming in Perl, but it's
hard to find a useful language in which you _wouldn't_ be able to write
CGI programs. Perl is often chosen for CGI programming because it's good
for many tasks, not just that relatively-small subset of tasks.

You may as well call a TV set "a device to keep sleeping cats warm". :-)

Having said that, Perl isn't generally a good choice for a first
programming language. A good introductory course on programming will teach
you important concepts which will make learning Perl easier and more
useful in the long run. For a first programming language, I usually
recommend Pascal - not because it's a great language that you'll want to
use for everything, but because it's generally taught at your local
community college by competent, patient instructors who will teach you how
good programming is done for a nominal fee.

Hope this helps!

--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/


Abigail

unread,
Jun 18, 1998, 3:00:00 AM6/18/98
to

Fred Kunkel (fku...@cp.duluth.mn.us) wrote on MDCCLII September MCMXCIII
in <URL: news:358875...@cp.duluth.mn.us>:
++ Is perl a good language for the non-programer to attempt learning a cgi
++ programing language?

There is no such thing as a "CGI programming language". CGI is written
in English.

You might want to learn how to program - a necessity if you want to
write a program that uses the CGI protocol. Personally, I would not
recommend Perl as a first language, althought there is a probably a
small group of people for which Perl would be a better first language
than something else.

Start with Pascal. Or Modula. Or, if possible, LPC. Find someone to
teach you *programming*. (Not a language, *programming*).

++ Is there a logical aproach to learning perl or
++ should one start with some other language that might be easier to
++ understand?

Learning another language first will help you understand why Perl is Perl.

Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=new Math::BigInt+qq;$^F$^W783$[$%9889$^F47$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W98$^F76777$=56;;$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V%$^U;$^V/=$^U}while$^V!=$^W'

F.Quednau

unread,
Jun 18, 1998, 3:00:00 AM6/18/98
to

Fred Kunkel wrote:
>
> Is perl a good language for the non-programer to attempt learning a cgi
> programing language? Is there a logical aproach to learning perl or

> should one start with some other language that might be easier to
> understand?

Many people say that Perl isn't a good choice for a start. But it depends so
much what kind of person you are. I have done a bit of programming before, but
Perl is the first laguage that I am trying to explore in depth. And that is only
because Perl is what it is, and Fortran, Delphi and VBasic failed to do the
same, that is, gripping my imagination. I perceive Perl as a kind of freestyle
language, where you have so many ways to do something that people tend to say
'this is no good for a beginner'. But hey, you can grow with the language, and
you can use Perl on a very basic level (I know what I am talking about). And,
not to forget, Perl is FREE. It's availability is excellent, Documentation is
good, and you get to speak to nice people :). So if you like coolness, and a bit
of weirdness , go for Perl! I luvvit!


--
____________________________________________________________
Frank Quednau
http://www.surrey.ac.uk/~me51fq
________________________________________________

Dan Nguyen

unread,
Jun 18, 1998, 3:00:00 AM6/18/98
to

F.Quednau <qued...@nortel.co.uk> wrote:

: Fred Kunkel wrote:
: >
: > Is perl a good language for the non-programer to attempt learning a cgi
: > programing language? Is there a logical aproach to learning perl or
: > should one start with some other language that might be easier to
: > understand?

: Many people say that Perl isn't a good choice for a start. But it depends so

: much what kind of person you are. [snip]

The person needs to be a "natural" programmer. Generally I feel that
most people have hard time not with the language but with the process
of programming. A person could learn Perl as a first language very
easily and have no problems, while others could become stuck on the
syntax of the language. What help me was knowing C. Perl IMHO is a
C-type language. Most of the operators and control constructs are
derived from C. That made learnging the simple stuff simple. I did
have a really hard time with pattern matching. That was due to it
being a brand new concept. I hadn't learn it before in any other language.

: Perl is the first laguage that I am trying to explore in depth. And


: that is only because Perl is what it is, and Fortran, Delphi and
: VBasic failed to do the same, that is, gripping my imagination.

Well Fortran is not usually an all purpose language. It tends to be
used more often by scientist, because it has good handling of
formulas. BASIC (where VBasic comes from) is more of an all purpose
language, but certain programming concepts were nearly imposible to
implement with its core compenents. Pascal (where Delphi is derived)
was a teaching language. I think its a good langauge to learn. Its
similar to many pseudolanguages that are used in text books. Pascal's
goal was to keep programmers from doing really dangerous things, and
learn how to program correctly. If you wanted to do "bad" things you
would need to jump through many hoops.

: I perceive Perl as a kind of freestyle language, where you have so


: many ways to do something that people tend to say 'this is no good
: for a beginner'.

I have to agree with you there. There tends to be many ways to solve
a problem. But with many other programming languages. There usually
are a few other ways too.

: But hey, you can grow with the language, and


: you can use Perl on a very basic level (I know what I am talking
: about). And, not to forget, Perl is FREE. It's availability is
: excellent, Documentation is good, and you get to speak to nice
: people :). So if you like coolness, and a bit
: of weirdness , go for Perl! I luvvit!

Perl on the very basic level tends to be the only thing you need to
learn in other languages like C. Where there is almost no built in
functions. C is free too. You can get a compiler released under the
GNU license as well. But the perl world is the best. The people are
awesome.

It may sound like I'm telling people not to learn Perl. I think that
perl is a terrific language. And if you can learn it. You'll love it.

-dan
--
Dan Nguyen |
nguy...@cps.msu.edu | Remember Byron.
http://www.cps.msu.edu/~nguyend7 |


Rich Morin

unread,
Jun 18, 1998, 3:00:00 AM6/18/98
to

In article <6malar$iee$9...@client3.news.psi.net>, abi...@fnx.com wrote:

> Find someone to teach you *programming*. (Not a language, *programming*).

Bingo!

As a language buff and occasional book reviewer, I have had the opportunity
to amass a great number of books on programming languages. To my dismay,
virtually all of them assume that the reader already knows another language
or two, as well as fundamental programming concepts.

Aside from making life difficult for beginners, this approach can produce
programmers who lack basic theory. There ARE some books which meet this
problem head-on. Possibly the best is Abelman and Sussman's "Structure
and Interpretation of Computer Programs". Unfortunately, this book is
based on Scheme, a Lisp variant, so many folks will avoid it.

Getting back to "Perl as a first language", here are my (windy) thoughts:

Programming languages have a certain "combinatorial complexity", based
on the number of constructs they support and the degree to which the
constructs interact.

Fortran has few constructs and little interaction, so it is pretty
simple. Pascal has few constructs and more interaction, making it more
complex. Ada and Perl have many constructs and high interaction, and
are therefore *really* complex.

In general, the number of constructs and level of interaction are well
correlated with the expressive power of the language. In "orthogonal"
languages (roughly, languages with one tool for each job), the size of
the syntax is thus a good indication of the expressive power.

Perl, however, is not an "orthogonal" language. (rather, according to
Larry, it is a "diagonal" language). So, many of Perl's constructs are
roughly equivalent, leading to the slogan that There's More Than One Way
To Do It (TMTOWTDI). This is great for experienced programmers; having
a diverse, if overlapping, set of tools can ease many programming tasks.

For a beginner, however, this diversity can be confusing. S/he has no
way of knowing which tool to use, and the increase in combinatorial
complexity does not (yet) bring any real benefits.

Complicating the matter still further, Perl can be used either as a free-
wheeling "scripting" language:

open FOO, ">foo" or die "can't open foo";

or as a more restrained "programming language":

open(FOO, ">foo") or die("can't open foo");

The first form is (slightly) faster to write, but it presents the reader
with a much harder parsing challenge. (Perl's 24 levels of operator
precedence can be a bit much to memorize!) Making matters worse, Perl
code is rife with idiomatic usages:

1;

For these reasons, aspiring programmers are often directed to languages
such as BASIC or Pascal. Once they have their feet wet, the thinking
goes, they can "move up" to Perl.

Although this is a "safe" approach, it is a bit inefficient. Wouldn't
it be more reasonable to teach the new programmer some basic theory,
followed by a useful (not to mentioned restrained and non-idiomatic)
subset of Perl? This allows the new programmer to learn "real" Perl,
while avoiding most of the pedagogical problems mentioned above.

<Promo>
"MacPerl: Power and Ease", an introduction and reference for MacPerl,
takes exactly this approach. An online copy is available at:

http://www.ptf.com/macperl/ptf_book/HTML

For general information on MacPerl (Perl 5 for the Macintosh), visit
PTF's MacPerl Pages:

http://www.ptf.com/macperl
</Promo>

-r

--
Canta Forda Computer Laboratory | Prime Time Freeware - quality
UNIX consulting, training, & writing | freeware at affordable prices
+1 415-873-7841 | +1 408-433-9662 -0727 (Fax)
Rich Morin, r...@cfcl.com | www.ptf.com, in...@ptf.com

Dan Nguyen

unread,
Jun 18, 1998, 3:00:00 AM6/18/98
to

Rich Morin <r...@cfcl.com> wrote:

: In article <6malar$iee$9...@client3.news.psi.net>, abi...@fnx.com wrote:

: > Find someone to teach you *programming*. (Not a language, *programming*).

: Bingo!

[snip]
: Getting back to "Perl as a first language", here are my (windy) thoughts:

: Programming languages have a certain "combinatorial complexity", based
: on the number of constructs they support and the degree to which the
: constructs interact.

: Fortran has few constructs and little interaction, so it is pretty
: simple. Pascal has few constructs and more interaction, making it more
: complex. Ada and Perl have many constructs and high interaction, and
: are therefore *really* complex.

Pascal, IMHO is a good language to learn as your first language.
Especially if your planning on learning C along the way. Its been my
experience that learning the first language is always the hardest.
Learning new ones is simply a making connections with previous
language. i.e. I did it this way in this language, and in this one
these things act like those things, and this keyword is like that
keyword. e.g. Pascal and C

PASCAL C Perl
while( i > 0 ) while( i > 0 ) while( $i > 0 )
begin { {
. . .
. . .
. . .
end; } }

The perivous examples show how things you can make connections, and
make your programming experience more enjoyable.

: In general, the number of constructs and level of interaction are well


: correlated with the expressive power of the language. In "orthogonal"
: languages (roughly, languages with one tool for each job), the size of
: the syntax is thus a good indication of the expressive power.

: Perl, however, is not an "orthogonal" language. (rather, according to
: Larry, it is a "diagonal" language). So, many of Perl's constructs are
: roughly equivalent, leading to the slogan that There's More Than One Way
: To Do It (TMTOWTDI). This is great for experienced programmers; having
: a diverse, if overlapping, set of tools can ease many programming tasks.

: For a beginner, however, this diversity can be confusing. S/he has no
: way of knowing which tool to use, and the increase in combinatorial
: complexity does not (yet) bring any real benefits.

Pascal is a good language (though it is begining to be taught in fewer
and fewer high schools.) to learn. One of the things that helps
begining programmers is the strictness of the language. Generally
there is either one way or a few ways of doing things. That one way
usually is the best for most situation. Though it may not always
produce the most effient code.

: Complicating the matter still further, Perl can be used either as a free-
: wheeling "scripting" language:

: open FOO, ">foo" or die "can't open foo";

: or as a more restrained "programming language":

: open(FOO, ">foo") or die("can't open foo");

: The first form is (slightly) faster to write, but it presents the reader
: with a much harder parsing challenge. (Perl's 24 levels of operator
: precedence can be a bit much to memorize!) Making matters worse, Perl
: code is rife with idiomatic usages:

: 1;

: For these reasons, aspiring programmers are often directed to languages
: such as BASIC or Pascal. Once they have their feet wet, the thinking
: goes, they can "move up" to Perl.

Most languages were invented (made up) for a reason.
FORTRAN (FORMula TRANslation): give programmers the ability to produce
code that had actually algebraic expressions.

COBOL (COmmon Business Oriented Language): give business people
something to do.

Pascal (in honor of Pascal): teaching language.

C (sucessor to the B programming language): write powerful code with
the least amount of typing.

Smalltalk (?? just thank the people at XeroxPARC): parent of all other
Object oriented programming

C++ (C += 1): oop implementation of C.

Ada (??): something the DoD made up

Java (named after the coffee they drank): write an OOP language that
could be run on any OS without any changes to the code.

BASIC (Beginners All-purpose Symbolic Instruction Code): simple
language with thousands of different derivatives. BASICA QBASIC
VisualBASIC to name a few. What the names implies. Its fairly
simple.

Perl (Practical Extraction and Report Language || Pathologically
Eclectic Rubbish Lister): Something that Larry Wall came up with. It
grew and grew. Now its the king of scripting languages. If not
programming languages in general.

: Although this is a "safe" approach, it is a bit inefficient. Wouldn't


: it be more reasonable to teach the new programmer some basic theory,
: followed by a useful (not to mentioned restrained and non-idiomatic)
: subset of Perl? This allows the new programmer to learn "real" Perl,
: while avoiding most of the pedagogical problems mentioned above.

My greatest difficulty while learning Perl was the pattern matching.
(Wish I new Awk and Sed). The implementation of objects was difficult
for me. It was nothing linke C++ or Java.


Sorry I took the promo out.

Rich Morin

unread,
Jun 18, 1998, 3:00:00 AM6/18/98
to

In article <6mbktf$5qp$1...@msunews.cl.msu.edu>, Dan Nguyen

<nguy...@egr.msu.edu> wrote:
> Ada (??): something the DoD made up

Actually, Ada is a very interesting case study. The DoD had a very real
need to fill:
a language suitable for building mission-critical embedded systems. They
also had a
plethora of one-off languages which had been written for individual
projects. They
thought that by designing a single language, by committee and review, they
could get
a language that met all of their needs. Some very smart people were
involved in this
effort; don't take their effort lightly!

I don't work in the military arena, so I don't know whether Ada is meeting
the needs
of its intended audience. I do believe, however, that the "combinatorial
complexity"
of Ada makes it a difficult language to learn, maintain, support, etc.
And, because
most of us do not write "mission-critical embedded systems", we aren't
willing to
work that hard. Hence, Ada remains a "curiosity", rather than a popular
language.

Larry Rosler

unread,
Jun 18, 1998, 3:00:00 AM6/18/98
to

In article <6mbktf$5qp$1...@msunews.cl.msu.edu>, nguy...@egr.msu.edu
says...
...
> PASCAL C Perl
Pascal :-)

As one of the first who tried to teach C many years ago, I can vouch that
it is a poor choice for beginners, for one spcific reason that is seldom
discussed: the difficulty of doing simple text input with data
conversion.

Once one gets past single-character input (getchar or getc) or perhaps
line-at-a-time-and-parse-it-yourself input (gets or fgets, atoi, atof,
...), one encounters the horrible scanf function, which demands an
understanding of pointers and internal representations. Fuggedaboudit!

C++ is better on input conversions, and Perl can rely on text isolation
via regexes and automatic conversions. Regexes are hard unless one has
been weaned on ed/vi/grep/awk/sed/... but the student must learn them
right away to get much useful work done anyway. But Perl references can
wait till much later, while C pointers cannot.

Don't teach C to beginners!

--
Larry Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
l...@hpl.hp.com

Randal Schwartz

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

>>>>> "Dan" == Dan Nguyen <nguy...@egr.msu.edu> writes:

Dan> The person needs to be a "natural" programmer. Generally I feel that
Dan> most people have hard time not with the language but with the process
Dan> of programming. A person could learn Perl as a first language very
Dan> easily and have no problems, while others could become stuck on the
Dan> syntax of the language.

I'll second this. I see far too many people *attempting* programming
that would probably have a better time being firefighters or line
chefs or congressmen or something. Sure, maybe nearly anyone with
enough effort can hack out a VB script to automate a repeated task,
but programming *well* seems to require a twisted aptitude only some
small percentage of the population seems to have. I think I was lucky
to be born with it, given the time at which I was born. :-) No
ordinary amount of education can seem to teach people how to "think"
like a progammer. ("You have these seven transformations possible and
this problem requires converting Q to W... go!")

I suppose it would be too much to ask that if you're not a natural
programmer, either stay out of the business, or flag your work
properly so that we cleanup people know what to throw out first. :-)

On the other hand, *I* can't draw worth beans. It's a struggle for
me. Huge. No amount of education is gonna fix that. So, it's a good
thing that there are artists for hire out there. I think in the end,
it all balances out. I can't cook either. But I know how to operate
a VISA card at a restaurant. :-)

print "Just another Perl hacker," # but not what the media calls "hacker!" :-)
## legal fund: $20,990.69 collected, $186,159.85 spent; just 74 more days
## before I go to *prison* for 90 days; email fu...@stonehenge.com for details

--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

Randal Schwartz

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

>>>>> "Dan" == Dan Nguyen <nguy...@egr.msu.edu> writes:

Dan> Pascal is a good language (though it is begining to be taught in fewer
Dan> and fewer high schools.) to learn. One of the things that helps
Dan> begining programmers is the strictness of the language. Generally
Dan> there is either one way or a few ways of doing things. That one way
Dan> usually is the best for most situation. Though it may not always
Dan> produce the most effient code.

I tell people frequently:

To master structured programming, learn Pascal *first*.
To master object-oriented programing, learn Smalltalk *first*.

There's no excuse for not knowing Pascal and Smalltalk given the free
implementations out there.

Mark-Jason Dominus

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

In article <MPG.ff322ab6...@nntp.hpl.hp.com>,

Larry Rosler <l...@hpl.hp.com> wrote:
>As one of the first who tried to teach C many years ago, I can vouch that
>it is a poor choice for beginners, for one spcific reason that is seldom
>discussed: the difficulty of doing simple text input with data
>conversion.
>
>Once one gets past single-character input (getchar or getc) or perhaps
>line-at-a-time-and-parse-it-yourself input (gets or fgets, atoi, atof,
>...), one encounters the horrible scanf function, which demands an
>understanding of pointers and internal representations. Fuggedaboudit!

I had to teach an introductory programming course in C to people with
no programming experience, and the first thing I realized was the
problem you describe.

So I pondered my two choices: (1) Avoid sprintf, perhaps by giving them a
library of special-purpose input routines, or (2) Cover pointers very
early on.

I decided that (1) was essentially a waste of time, because the skills
and techniques they learned for dealing with my special-purpose input
functions would be useless.

But more important, I asked myself where the problem was really coming
from. I want to teach scanf, but to do that, I have to teach
pointers. Why does scanf need pointers?

`scanf' needs pointers because without them it cannot modify variables
in the calling subroutine. Why not?

`scanf' cannot modify variables in the calling subroutine without
pointers because the variables are lexically scoped so that they can
be hidden from other subroutines.

That decided me. Data hiding and encapsulation issues must be at the
heart of any programming course. By avoiding pointers, I would be
avoiding these elementary issues.

It turned out that pointers were very important and very essential.
They presented themselves in the earliest parts of the material not
out of perversity, but because they were central to the topic.

So I went with choice 2, and I discussed functions and private
variables in the second lecture. Then, by the fourth lecture, with
the idea of private variables already established, I discussed scanf
and pointers. I did not discuss arrays or pointer arithmetic until
much later.

This all worked very well. It is a very little pill to swallow.
Everyone understood. Later on, when we discussed arrays, the pointer
arithmetic part was a smaller pill because everyone was already
familiar with pointers.

It was a huge success, and it left me convinced that the problems with
teaching people pointers are on the delivering end, not the receiving
end. I think that people teach pointers the wrong way, and usually
the instructors do not understand pointers themselves.

Summary:

Pointers are an essential part of the solution to the data hiding
problem, which is an essential issue. Therefore, they cannot be
avoided, and in fact should be addressed as soon as possible. The
idea of a pointer should be separated from issues of pointer
arithmetic, which is not necessary until later.

Note crossposting.

Dan Nguyen

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Larry Rosler <l...@hpl.hp.com> wrote:
: In article <6mbktf$5qp$1...@msunews.cl.msu.edu>, nguy...@egr.msu.edu
: says...
: ...
: > PASCAL C Perl
: Pascal :-)

: As one of the first who tried to teach C many years ago, I can vouch that

: it is a poor choice for beginners, for one spcific reason that is seldom
: discussed: the difficulty of doing simple text input with data
: conversion.

When I was first learning C I was little amazed that it didn't have
any built in way of reading input, and writing output. Then I learned
about the library functions that come with standard ANSI C. Come to
think of it Java has this problem too. Its hard to get useful
information from the keyboard for an application (no gui) without
figuring out how to parse it yourself.

: Once one gets past single-character input (getchar or getc) or perhaps

: line-at-a-time-and-parse-it-yourself input (gets or fgets, atoi, atof,
: ...), one encounters the horrible scanf function, which demands an
: understanding of pointers and internal representations. Fuggedaboudit!

: C++ is better on input conversions, and Perl can rely on text isolation

: via regexes and automatic conversions. Regexes are hard unless one has
: been weaned on ed/vi/grep/awk/sed/... but the student must learn them
: right away to get much useful work done anyway. But Perl references can
: wait till much later, while C pointers cannot.

: Don't teach C to beginners!

If you want to learn C. Try your hand at Pascal first.

Rich Morin

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

In article <8c7m2db...@gadget.cscaper.com>, Randal Schwartz
<mer...@stonehenge.com> wrote:

> To master structured programming, learn Pascal *first*.
> To master object-oriented programing, learn Smalltalk *first*.
>
> There's no excuse for not knowing Pascal and Smalltalk given the free
> implementations out there.

If this were merely a discussion of languages that can teach nifty ideas,
I would be more than happy to agree with you. Ada, APL, assembler, Icon,
Lisp, PostScript, and Prolog would be some of my additions.

But, given that we are talking about first languages, and that many users
will have no enthusiasm for learning multiple languages, I cannot agree.

It isn't necessary to use Pascal to learn about structured programming.
I explained it to folks that were using Fortran-63 anbd they got it! I
would certainly promote Smalltalk as an elegant approach to OO (as C++ is
NOT), but I think the concepts are fairly clear in Perl and Objective-C.


A friend of mine is a very smart engineer/manager. He uses BASIC for the
occasional programming task he encounters. I've told him about Perl, but
he says BASIC meets his needs just fine:

* It has all the features he needs.
* He can use the language from memory.

There are quite a few "casual" or "occasional" programmers out there. I
don't despise their efforts, any more than I would want a chef to scorn
my technique for making egg sandwiches. Saying that Perl is "too good
for the likes of them" and such is a bunch of elitist garbage, IMHO. (I
do not program Perl as well as Larry, and never will, but he doesn't make
fun of me, so I don't make fun of them.)


Still, Perl presents a conundrum. BASIC (and even awk/sed/sh/tr/...)
doesn't have all the features *I* need, but I'm a bit embarrassed about
the number of books I need to keep next to my desk to get through any
significant Perl programming task.

Nonetheless, I think that a well-chosen subset of Perl can work as well
as BASIC for a beginner, while offering vastly more "growth potential".
Working with Unix over the years has been a tremendous learning exper-
ience for me. I have been able to use tools crafted by some real pros.
I have much the same feeling about Perl; I think it will take me just
about anywhere I really wish to go...

Abigail

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Randal Schwartz (mer...@stonehenge.com) wrote on MDCCLIII September
MCMXCIII in <URL: news:8cbtrpb...@gadget.cscaper.com>:
++ >>>>> "Dan" == Dan Nguyen <nguy...@egr.msu.edu> writes:
++
++ Dan> The person needs to be a "natural" programmer. Generally I feel that
++ Dan> most people have hard time not with the language but with the process
++ Dan> of programming. A person could learn Perl as a first language very
++ Dan> easily and have no problems, while others could become stuck on the
++ Dan> syntax of the language.
++
++ I'll second this. I see far too many people *attempting* programming
++ that would probably have a better time being firefighters or line
++ chefs or congressmen or something. Sure, maybe nearly anyone with
++ enough effort can hack out a VB script to automate a repeated task,
++ but programming *well* seems to require a twisted aptitude only some
++ small percentage of the population seems to have. I think I was lucky
++ to be born with it, given the time at which I was born. :-) No
++ ordinary amount of education can seem to teach people how to "think"
++ like a progammer. ("You have these seven transformations possible and
++ this problem requires converting Q to W... go!")
++
++ I suppose it would be too much to ask that if you're not a natural
++ programmer, either stay out of the business, or flag your work
++ properly so that we cleanup people know what to throw out first. :-)


That sounds as if programming would be an art. I disagree with that.
I believe that most people can be able to learn how to program. Just
like most people could learn how to become a car mechanic.

Whether everyone has the motivation to learn is a different issue.


Abigail
--
perl -MTime::JulianDay -lwe'@r=reverse(M=>(0)x99=>CM=>(0)x399=>D=>(0)x99=>CD=>(
0)x299=>C=>(0)x9=>XC=>(0)x39=>L=>(0)x9=>XL=>(0)x29=>X=>IX=>0=>0=>0=>V=>IV=>0=>0
=>I=>$r=-2449231+gm_julian_day+time);do{until($r<$#r){$_.=$r[$#r];$r-=$#r}for(;
!$r[--$#r];){}}while$r;$,="\x20";print+$_=>September=>MCMXCIII=>()'

Chris Nandor

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

In article <8c7m2db...@gadget.cscaper.com>, Randal Schwartz
<mer...@stonehenge.com> wrote:

# I tell people frequently:
#
# To master structured programming, learn Pascal *first*.
# To master object-oriented programing, learn Smalltalk *first*.
#
# There's no excuse for not knowing Pascal and Smalltalk given the free
# implementations out there.

I dunno, the only real language I know is Perl, and I am happy.

--
Chris Nandor mailto:pu...@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])

Deva Seetharam

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to


Abigail wrote:

"programming" and "Programming" are not the same.
Point is not whether somebody can learn to write a few lines of code;
But whether he/she can use the programming lang. to solve a real world problem
efficiently, elegantly and **effectively**.

Programming is undoubtedly an art.
It requires a brilliant mind to understand the problem domain, conceptualize
a suitable data structure and employ an efficient algorithm to produce
an elegant solution.

(:-) != (MonaLisa)

Deva

Chris

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Randal Schwartz wrote in message <8c7m2db...@gadget.cscaper.com>...


>>>>>> "Dan" == Dan Nguyen <nguy...@egr.msu.edu> writes:
>

> To master structured programming, learn Pascal *first*.

> To master object-oriented programing, learn Smalltalk *first*.
>

>There's no excuse for not knowing Pascal and Smalltalk given the free

>implementations out there.
>


I actually suggest to people who want to learn programming that they should
get source code for the same type of program in two different languages, and
compare and contrast.

As for early learning of langugaes, Forth is a perfectly good language to
learn early on,
though I'd not list it as a good First language. I'd also say that Scheme is
a great
early language, and may even work well as a first lamguage. ABC sems a good
choice too, although its historical ties to BASIC make many cringe, I'm
sure.

Really, though, I wouldn't teach programming in any of these languages to
beginners.
If I were actually teaching a course, I'd lean towards Lisp, Perl, or
Pascal,
because these languages each present a strong model of what is going on in
the
code. Pascal has very simple text manipulation, Perl has very strong
searching and
replacing methods - rivaling ome of the best libraries for a few other
languages - and
Lisp has a very good model of type and precedence, although the
type-by-structure idea is foreign to many of us.

Right now, I think Perl should take a front seat because of its use for CGI.
If a first
language has one most important feature, it's availability of examples. This
shows the
person learning that there are real-world applications for the language,
gives them source code to modify, and lets them begin working without
writing from scratch.
Programming from scratch requires knowledge of the syntax, when learning a
language should be about semantics first. Modifying other people's source
gives
this advantage, and much source is available in Perl lately.


=================================================================
Chris Stith
Asst. Network Administrator
DataStream Networks, Inc.
ch...@nemonet.com
-----------------------------------------------------------------
"Every program should do as much as is necessary, but much less
than what is possible." -- Anonymous

Andrew Johnson

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Abigail wrote:
>
[snip]

> ++ I suppose it would be too much to ask that if you're not a natural
> ++ programmer, either stay out of the business, or flag your work
> ++ properly so that we cleanup people know what to throw out first. :-)
>
> That sounds as if programming would be an art. I disagree with that.
> I believe that most people can be able to learn how to program. Just
> like most people could learn how to become a car mechanic.

Indeed, I agree --- I think of programming as a craft, like
writing or blacksmithing... not every writer creates literary
masterpieces, and not every blacksmith becomes an artisan...



> Whether everyone has the motivation to learn is a different issue.

or to put in the effort to continually hone their craft.

regards
andrew

Mark Maurer

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Abigail (abi...@fnx.com) wrote:
: Randal Schwartz (mer...@stonehenge.com) wrote on MDCCLIII September
: MCMXCIII in <URL: news:8cbtrpb...@gadget.cscaper.com>:
: ++ >>>>> "Dan" == Dan Nguyen <nguy...@egr.msu.edu> writes:
: ++
: ++ Dan> The person needs to be a "natural" programmer. Generally I feel that
: ++ Dan> most people have hard time not with the language but with the process
: ++ Dan> of programming. A person could learn Perl as a first language very
: ++ Dan> easily and have no problems, while others could become stuck on the
: ++ Dan> syntax of the language.
: ++
: ++ I'll second this. I see far too many people *attempting* programming
: ++ that would probably have a better time being firefighters or line
: ++ chefs or congressmen or something. Sure, maybe nearly anyone with
: ++ enough effort can hack out a VB script to automate a repeated task,
: ++ but programming *well* seems to require a twisted aptitude only some
: ++ small percentage of the population seems to have. I think I was lucky
: ++ to be born with it, given the time at which I was born. :-) No
: ++ ordinary amount of education can seem to teach people how to "think"
: ++ like a progammer. ("You have these seven transformations possible and
: ++ this problem requires converting Q to W... go!")
: ++
: ++ I suppose it would be too much to ask that if you're not a natural

: ++ programmer, either stay out of the business, or flag your work
: ++ properly so that we cleanup people know what to throw out first. :-)
:
:
: That sounds as if programming would be an art. I disagree with that.
: I believe that most people can be able to learn how to program. Just
: like most people could learn how to become a car mechanic.

I used to think that way, but not anymore. Sometimes, it still seems as if
it is that way, but it really isn't. No more than I have a good chance at
being a good Chemical Engineer or Architect. I can learn some of the
concepts behind it, but that is as far as it goes.

There is a difference in knowing how to do something, and knowing how to do
something well...

: Whether everyone has the motivation to learn is a different issue.

I agree with this 100%

--
Mark Maurer ma...@dct.com mwma...@mtu.edu
Programmer, Digital Magic Interactive http://www.dminteractive.com
Senior, Michigan Technological University Houghton, MI
-- Views do not represent those of my employer or school

Larry Weiss

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Mark-Jason Dominus wrote:
> Pointers are an essential part of the solution to the data hiding
> problem, which is an essential issue. Therefore, they cannot be
> avoided, and in fact should be addressed as soon as possible. The
> idea of a pointer should be separated from issues of pointer
> arithmetic, which is not necessary until later.
>

And also by delaying the teaching of the concept and basic practice
of pointers it gives the subject an undeserved sense of mystery and
complexity.

- Larry Weiss

Larry Rosler

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

In article <6me11n$itv$1...@monet.op.net>, Mark-Jason Dominus <m...@op.net>
says...
...

> So I pondered my two choices: (1) Avoid sprintf, perhaps by giving them a
scanf (minor brain-o)
> library of special-purpose input routines, or (2) Cover pointers very
> early on.
>
> I decided that (1) was essentially a waste of time, because the skills
> and techniques they learned for dealing with my special-purpose input
> functions would be useless.
>
> But more important, I asked myself where the problem was really coming
> from. I want to teach scanf, but to do that, I have to teach
> pointers. Why does scanf need pointers?
>
> `scanf' needs pointers because without them it cannot modify variables
> in the calling subroutine. Why not?
>
> `scanf' cannot modify variables in the calling subroutine without
> pointers because the variables are lexically scoped so that they can
> be hidden from other subroutines.

No, that is not the reason at all. Scanf cannot modify argument
variables *anywhere* because of C's intractable call-by-value semantics.
In order for a C function to modify any of its arguments, the argument
must be a pointer to the actual lvalue to be modified. This is
independent of the scope of that lvalue.

> That decided me. Data hiding and encapsulation issues must be at the
> heart of any programming course. By avoiding pointers, I would be
> avoiding these elementary issues.
>
> It turned out that pointers were very important and very essential.
> They presented themselves in the earliest parts of the material not
> out of perversity, but because they were central to the topic.

As I said, they are central to C function linkage.

> So I went with choice 2, and I discussed functions and private
> variables in the second lecture. Then, by the fourth lecture, with
> the idea of private variables already established, I discussed scanf
> and pointers. I did not discuss arrays or pointer arithmetic until
> much later.

As you know, arrays are passed as pointers, which leads beginners to all
kinds of confusion between a[N] (which allocates storage) and *a (which
points to storage -- one hopes!).

> This all worked very well. It is a very little pill to swallow.
> Everyone understood. Later on, when we discussed arrays, the pointer
> arithmetic part was a smaller pill because everyone was already
> familiar with pointers.
>
> It was a huge success, and it left me convinced that the problems with
> teaching people pointers are on the delivering end, not the receiving
> end. I think that people teach pointers the wrong way, and usually
> the instructors do not understand pointers themselves.

Well, I think I really do understand pointers and can teach them the
right way. But I think they introduce concepts of physical address way
too soon for programmers who are trying to learn their first "higher-
level" language.

> Summary:


>
> Pointers are an essential part of the solution to the data hiding
> problem, which is an essential issue. Therefore, they cannot be
> avoided, and in fact should be addressed as soon as possible. The
> idea of a pointer should be separated from issues of pointer
> arithmetic, which is not necessary until later.

Pointers are needed only for allocated storage, not for named storage in
any scope. I think learning them should be delayed until necessary,
while the principles of expression evaluation and program structure are
being learned. Having to use pointers for data input is an annoying
burden.

Summary:

My *real* choice for a first language for students who want to become
"real" (i.e., professional) programmers would be an abstract assembly
language such as MIX (Knuth, vol. 1). With that as a basis, the C
concept of pointers becomes transparent.

Dann Corbit

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Larry Rosler wrote in message ...
[snip]

>Summary:
>
>My *real* choice for a first language for students who want to become
>"real" (i.e., professional) programmers would be an abstract assembly
>language such as MIX (Knuth, vol. 1). With that as a basis, the C
>concept of pointers becomes transparent.

Hello, ghost of Tim B.

I have a MIX interpreter I can send you if you like [written in C]. BTW,
Knuth has a new edition of "The Art of Computer Programming" Volume 1
Fundamental Algorithms completed. I just got my new copy.
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
Want Software? Algorithms? Pubs? http://www.infoseek.com

Lloyd Zusman

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

abi...@fnx.com (Abigail) writes:

> Randal Schwartz (mer...@stonehenge.com) wrote on MDCCLIII September
> MCMXCIII in <URL: news:8cbtrpb...@gadget.cscaper.com>:
> ++ >>>>> "Dan" == Dan Nguyen <nguy...@egr.msu.edu> writes:
> ++

> ++ Dan> The person needs to be a "natural" programmer. [ ... ]


> ++
> ++ I'll second this. I see far too many people *attempting* programming
> ++ that would probably have a better time being firefighters or line
> ++ chefs or congressmen or something. Sure, maybe nearly anyone with
> ++ enough effort can hack out a VB script to automate a repeated task,
> ++ but programming *well* seems to require a twisted aptitude only some

> ++ small percentage of the population seems to have. [ ... ]


> ++
> ++ I suppose it would be too much to ask that if you're not a natural
> ++ programmer, either stay out of the business, or flag your work
> ++ properly so that we cleanup people know what to throw out first. :-)
>
>
> That sounds as if programming would be an art. I disagree with that.
> I believe that most people can be able to learn how to program. Just
> like most people could learn how to become a car mechanic.
>

> Whether everyone has the motivation to learn is a different issue.

I agree. Quite a number of people that I know seem to be capable of
programming, but only a minority of these people are able to much
enjoyment out of it. Without this enjoyment, there's a much lower
motivation to learn.

For me, all the effort I have expended in learning to program and in
programming itself has been a labor of love, and hence, it didn't
*feel* like labor at all.

As for being a car mechanic ... I was very proud of myself 20 years
ago when I finally taught myself how to rebuild my car's engine, but
the work itself was not enjoyable for me, only the pride in
accomplishment. So even though I now know that I could be a very good
car mechanic, I haven't felt the slightest bit motivated to pursue
that vocation.

So, in my opinion, programming doesn't require an inordinate amount of
skill or intelligence or even creativity, but rather, a certain
emotional disposition. Just like some people enjoy vanilla ice cream
and others chocolate, some people enjoy programming and others enjoy
completely different pastimes.


--
Lloyd Zusman l...@asfast.com
perl -e '$n=170;for($d=2;($d*$d)<=$n;$d+=(1+($d%2))){for($t=0;($n%$d)==0;
$t++){$n=int($n/$d);}while($t-->0){push(@r,$d);}}if($n>1){push(@r,$n);}
$x=0;map{$x+=(($_>0)?(1<<log($_-0.5)/log(2.0)+1):1)}@r;print"$x\n"'

Mark-Jason Dominus

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

In article <MPG.ff47c2f2...@nntp.hpl.hp.com>,
Larry Rosler <l...@hpl.hp.com> wrote:


>Dominus said:
>> `scanf' cannot modify variables in the calling subroutine without
>> pointers because the variables are lexically scoped so that they can
>> be hidden from other subroutines.
>
>No, that is not the reason at all. Scanf cannot modify argument
>variables *anywhere* because of C's intractable call-by-value semantics.
>In order for a C function to modify any of its arguments, the argument
>must be a pointer to the actual lvalue to be modified. This is
>independent of the scope of that lvalue.

lvalues do not have scope. Only names have scope.

In any event, it is irrelevant to this discussion. Consider a
language that supports both call-by-value and call-by-reference
semantics, say Pascal. You will have to explain to the students why
one and not the other must be used in a case like this, and the
explanation will be nearly identical to the explanation of why scanf
arguments are preceded by & in C. So pedagogically, there is very
little difference between these two things.

You can either present it as an opaque incantation (`put var before
the formal parameter' / `put * before the formal parameter and &
before the actual parameter') or you can explain what is really going
on and why. But what is really going on, and why, is exactly the same
in both cases. So the call-by-value semantics are a red herring here;
they don't change the teaching order or the presentation at all.

>As you know, arrays are passed as pointers, which leads beginners to all
>kinds of confusion between a[N] (which allocates storage) and *a (which
>points to storage -- one hopes!).

My students were not confused by this.

>Well, I think I really do understand pointers and can teach them the
>right way.

And yet you say that your students were confused about all sorts of
things. Surely this is inconsistent?

>But I think they introduce concepts of physical address way too soon
>for programmers who are trying to learn their first "higher- level"
>language.

I did not discuss physical addresses at any point. In fact, I
conceived a crazy theory at the beginning of the semester that
physical address explanations were totally unnecessary, in spite of
having seen such explanations in nearly every C book I had ever read.

I resolved to see if I could get through the whole class without every
mentioning a physical address. I was successful in this. It turned
out to be a brilliant inspiration. I think that people who discuss
physical addresses are making a big mistake. Physical addresses are
irrelevant in a high-level language.

>Pointers are needed only for allocated storage, not for named storage in
>any scope. I think learning them should be delayed until necessary,

I agree, but I believe that in C, they are necessary right away.

Chapter 5 of K&R notwithstanding, pointers are not a single topic.
There are a lot of things to do with pointers. You need them for
scanf. You need them for passing arrays to functions. You need them
for address arithmetic on arrays. You need them for dynamically
allocated storage.

Surely the most ordinary principles of pedagogy would suggest that you
*don't* try to cover all of these things at the same time, but rather
one at a time, starting with the simplest, moving from each to the
next only when the students are comfortable?

>Summary:
>My *real* choice for a first language for students who want to become
>"real" (i.e., professional) programmers would be an abstract assembly
>language such as MIX (Knuth, vol. 1).

That is very interesting. I am skeptical, but I am very eager to hear
you recount your experiences if you have actually done that.

If your main point is that C is a bad first language to teach
programmers, you will not get much argument out of me. I agree with
you. All I am saying is that it can be taught more successfully than
it usually is.


Cyrand

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to


Larry Weiss wrote:

> Mark-Jason Dominus wrote:
> > Pointers are an essential part of the solution to the data hiding
> > problem, which is an essential issue. Therefore, they cannot be
> > avoided, and in fact should be addressed as soon as possible. The
> > idea of a pointer should be separated from issues of pointer
> > arithmetic, which is not necessary until later.
> >
>

> And also by delaying the teaching of the concept and basic practice
> of pointers it gives the subject an undeserved sense of mystery and
> complexity.

As a novice programmer, I would have to agree. The learning C book I am
reading introduced pointers as tricky, but important(Around chapter 9 of
21). They emphasized the tricky. I was nervous about using pointers,
and so had trouble using them the first few times. After a few uses, I
realized that they were more useful than they said, and less tricky.
But I'm still working on unlearing the pointer fearing mindset, which
does *much* more harm than good.

--
Email: cyr...@juno.com
"Strategy and appropriate use of the *available* resources does NOT
equate to godhood. --Barry Kearns"

John Mott

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

Larry Rosler wrote:

> burden.


>
> Summary:
>
> My *real* choice for a first language for students who want to become
> "real" (i.e., professional) programmers would be an abstract assembly

> language such as MIX (Knuth, vol. 1). With that as a basis, the C
> concept of pointers becomes transparent.
>

Although I have never taught programming I certainly had to learn it :-)

My first language was FORTRAN, because I was in physics.
Looking back, the good things about it were call by reference and (at
that
time with Fortran IV) heavy emphasis on the GOTO. This made for sloppy
code
but it also made the first steps easier to take. It was also easier to
not
have to declare variables. This is all heresy, of course, but for me the
essence of learning programming is learning about what happens as you
are
rewiring your brain so that you take a problem and translate it into
action.
In those first awkward stumbles a language that was more primitive was
better.
As I matured and took other languages was able to abstract the
importance
of structure, declarations, etc. because I had legs to stand on.

I also remember that it took me three solid weeks of staring at my
Pascal book
before I got pointers; it was a very painful time because the notion was
introduced in a
vaccum. Had I been thrown this as a tool that was needed for a specific
task its likely
that I would have (like many other programming lessons) just sort of
used them for a long
time until the 'AHA' moment hit and I popped to the meta-level where I
saw purpose.

John Mott
jo...@sandh.com
http://www.iplsystem.com/ ; A darn nice language for the web. It would
be good for teaching, too!

Judson McClendon

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

Cyrand wrote:
>
>As a novice programmer, ...
<snip>

>I was nervous about using pointers, and so had trouble using them
>the first few times. After a few uses, I realized that they were
>more useful than they said, and less tricky.
<snip>

There is a real connection here. If you don't think C pointers are
'tricky', it just means you haven't used them enough to be bitten by
their subtleties. :-)
--
Judson McClendon This is a faithful saying and worthy of all
Sun Valley Systems acceptance, that Christ Jesus came into the
judm...@bellsouth.net world to save sinners (1 Timothy 1:15)
(please remove numbers from email id to respond)

Snowhare

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

-----BEGIN PGP SIGNED MESSAGE-----

Nothing above this line is part of the signed message.

In article <6me68f$ijt$1...@client3.news.psi.net>,


Abigail <abi...@fnx.com> wrote:
>That sounds as if programming would be an art. I disagree with that.
>I believe that most people can be able to learn how to program. Just
>like most people could learn how to become a car mechanic.
>
>Whether everyone has the motivation to learn is a different issue.

You've stepped right into one of the oldest debates in programming.
I am on the programming as an art side. I can teach a person all
about the abstractions, the techniques, the theory and practice -
but I can't give them the 'spark' that is the difference between
what I'll call a 'cookbook' programmer and a 'chef' programmer.

'Cookbook' programmers can follow the recipies, answer the test
questions and often do adequate maintenance programming where the
basic problem has already been solved. But don't ask them to start
with a blank screen and a problem of significant proportions and
successfully design a fast, elegant and well written system that
can be maintained easily. They can't. Their minds don't work that
way. It requires the ability to literally _think_ in a programming
language with a high degree of creativity and absolute precision.

The 'chef' progammers are the ones who _write_ the recipies.

In 18 years of programming, I've run into only a handful of
'chef' programmers.

Benjamin Franz

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNYvNkujpikN3V52xAQFjVQQAjYcWxhaoyMJIR56KRHJaRYqPR3iC0kjV
2W3gz+hYOyMzw+HOu7atME+sPqAy6swe+ZKylnExEv58mA0/Me4d9THDp8aN1Ys3
IXAv1wLj6f1jCiZ/CcwQwIBEdruIaqkOD6XHNcBdfWDJ/GUKXPHfv3UWucLlRDly
u6px3QnAhO8=
=Yl9e
-----END PGP SIGNATURE-----

John Beppu

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

In article <odPi1.3807$RS.33...@news3.atl.bellsouth.net>,
Judson McClendon <judm...@bellsouth.net> wrote:

>Cyrand wrote:
>>
>>As a novice programmer, ...
><snip>
>>I was nervous about using pointers, and so had trouble using them
>>the first few times. After a few uses, I realized that they were
>>more useful than they said, and less tricky.
><snip>
>
>There is a real connection here. If you don't think C pointers are
>'tricky', it just means you haven't used them enough to be bitten by
>their subtleties. :-)
>--

I feel like putting in my own 2 yen here.


I am of the opinion that the best way to become familiar with
pointers is to learn an assembly language of the architecture
you use most often. I knew x86 assembly before I knew C, but
moving to C from assembly was not a problem. A lot of times,
I found myself thinking, "this is kinda like assembly" while
learning C.

If I ever taught anyone to program, I'd get some Assembly in
early on to harden them and make them fearless. ;)

--
/** be...@uci.edu ......................................................... */

T Jurik

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

Larry Rosler wrote in message ...

>In article <6mbktf$5qp$1...@msunews.cl.msu.edu>, nguy...@egr.msu.edu
>says...
>...

>As one of the first who tried to teach C many years ago, I can vouch that
>it is a poor choice for beginners, for one spcific reason that is seldom
>discussed: the difficulty of doing simple text input with data
>conversion.

This depends on the reason the 'beginner' is learning the language. If one
is using the language primarily for simple tasks with a good deal of user
input or other such work, then C is probably not the way to go. Teaching C
within the contect of other computer science courses is fine. C then
becomes the language with which one expresses the concepts one is learning.

(A previous poster mentioned Abelson and Sussman's excellent book. One of
reasons that this is such a good book is that it does not focus on the
language as much as other books such as the tree-killing 'teach yourself
<Some Language> in <N> days. )

One of the probelems with 'learning a languege' is the implied need to learn
how to program. This is the real reason (In my opinion) that most books
fall short and only serve to increase the number of people on this planet
who know some language syntax or enter obfuscated language contests.

A good example of this idea is what you write below regarding learning
regular expressions from Sed and Awk. (Mr. Nguyen also stated something
similar.) regular expressions are not unique to languages like perl, Awk
and Sed. Rather they are a language of defining patterns, etc. and regular
expressions are a part of every decent computer science curriculum that I
know of.


>
>Once one gets past single-character input (getchar or getc) or perhaps
>line-at-a-time-and-parse-it-yourself input (gets or fgets, atoi, atof,
>...), one encounters the horrible scanf function, which demands an
>understanding of pointers and internal representations. Fuggedaboudit!
>
>C++ is better on input conversions, and Perl can rely on text isolation
>via regexes and automatic conversions. Regexes are hard unless one has
>been weaned on ed/vi/grep/awk/sed/... but the student must learn them
>right away to get much useful work done anyway. But Perl references can
>wait till much later, while C pointers cannot.
>
>Don't teach C to beginners!

I agree here -- only insofar as using C++, Smalltalk, Scheme, or Java rather
than C. One should try to teach 'beginners' as many languages as possible.
Using the right tool (language) for a particular problem/job is a
significant help in creating a solution.


Tim J


T Jurik

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

Deva Seetharam wrote in message <358AA28C...@execpc.com>...


>
>
>"programming" and "Programming" are not the same.
>Point is not whether somebody can learn to write a few lines of code;
>But whether he/she can use the programming lang. to solve a real world
problem
>efficiently, elegantly and **effectively**.
>
>Programming is undoubtedly an art.
>It requires a brilliant mind to understand the problem domain,
conceptualize
>a suitable data structure and employ an efficient algorithm to produce
>an elegant solution.


I do not think Programming or programming is an "art." It does not require
a brilliant mind to do any of what you described. Also, good programming
and design can be learned. Very good programmers do not have higher
intelligence than other people in professional positions. One must be
rigorous in one's thinking, yes, but this is not an art, nor is it
brilliance.

Most programmers will never really have to solve totally unique problems.
An understanding of what has been done already, how to do it and how to
apply the solved problems to one's domain is all that is really needed.
Granted, this is not what most programmers like to hear.


Tim


Larry Rosler

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

In article <6mhdpq$c...@news.service.uci.edu>, John Beppu
<be...@rigel.oac.uci.edu> says...
...

> I am of the opinion that the best way to become familiar with
> pointers is to learn an assembly language of the architecture
> you use most often. I knew x86 assembly before I knew C, but
> moving to C from assembly was not a problem. A lot of times,
> I found myself thinking, "this is kinda like assembly" while
> learning C.

Maybe I can dig up some old papers in which I describe C as a "portable
assembly language." This is because the basic abstraction is at the bits
and bytes level: bit-fields and unions and such, with all the baggage
including byte ordering out there to touch and feel.

> If I ever taught anyone to program, I'd get some Assembly in
> early on to harden them and make them fearless. ;)

At the risk of sounding like one of those old geezers who says, "That's
the way I learned, and it was good enough for me, so it should be good
enough for you.", that's the way I learned, and it was good enough for
me, so it should be good enough for you. :-)

LR>Summary:
LR>My *real* choice for a first language for students who want to become
LR>"real" (i.e., professional) programmers would be an abstract assembly
LR>language such as MIX (Knuth, vol. 1).

MJD>That is very interesting. I am skeptical, but I am very eager to
MJD>hear you recount your experiences if you have actually done that.

Sample of one, unfortunately. My kids started with Basic, which (as
Dijkstra says) is a terminal disease. They are *not* professional
programmers. :-)

Russ Allbery

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

In comp.lang.perl.misc, Mark-Jason Dominus <m...@op.net> writes:
> Larry Rosler <l...@hpl.hp.com> wrote:

>> Sample of one, unfortunately. My kids started with Basic, which (as
>> Dijkstra says) is a terminal disease.

> I am happy to report that Dijkstra is wrong again. I started with
> Basic, and was eventually able to eradicate it.

> It wasn't easy, thought, and since the remedy was injections of APL, one
> could argue that the cure was worse than the disease.

Funny, I started with BASIC and it proved to be an excellent introduction
to Pascal and a way to get me to appreciate Perl's statement modifier if.

But then I learned on VMS BASIC, not on some line-number-driven brain-dead
monstrosity. :)

--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print

Abigail

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Deva Seetharam (psd...@execpc.com) wrote on MDCCLIII September MCMXCIII
in <URL: news:358AA28C...@execpc.com>:
++
++
++
++ "programming" and "Programming" are not the same.
++ Point is not whether somebody can learn to write a few lines of code;
++ But whether he/she can use the programming lang. to solve a real world problem
++ efficiently, elegantly and **effectively**.
++
++ Programming is undoubtedly an art.
++ It requires a brilliant mind to understand the problem domain, conceptualize
++ a suitable data structure and employ an efficient algorithm to produce
++ an elegant solution.


Then you are entering the world of algorithm design; which is something
I don't see programmers do very often. But algorithm design isn't art
either. It's just a lot of work.

Abigail

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Snowhare (snow...@devilbunnies.org) wrote on MDCCLIV September MCMXCIII
in <URL: news:6mgh0j$6o9$1...@supernews.com>:
++ -----BEGIN PGP SIGNED MESSAGE-----
++
++ Nothing above this line is part of the signed message.
++
++ In article <6me68f$ijt$1...@client3.news.psi.net>,
++ Abigail <abi...@fnx.com> wrote:
++ >That sounds as if programming would be an art. I disagree with that.
++ >I believe that most people can be able to learn how to program. Just
++ >like most people could learn how to become a car mechanic.
++ >
++ >Whether everyone has the motivation to learn is a different issue.
++
++ You've stepped right into one of the oldest debates in programming.
++ I am on the programming as an art side. I can teach a person all
++ about the abstractions, the techniques, the theory and practice -
++ but I can't give them the 'spark' that is the difference between
++ what I'll call a 'cookbook' programmer and a 'chef' programmer.
++
++ 'Cookbook' programmers can follow the recipies, answer the test
++ questions and often do adequate maintenance programming where the
++ basic problem has already been solved. But don't ask them to start
++ with a blank screen and a problem of significant proportions and
++ successfully design a fast, elegant and well written system that
++ can be maintained easily. They can't. Their minds don't work that
++ way. It requires the ability to literally _think_ in a programming
++ language with a high degree of creativity and absolute precision.

I agree with that, up to where you say "programming language".
Skilled programming/algorithm design isn't tied to a language.
Just like a car mechanic works on cars, and a 'chef' with food.
Of course, a mechanic can be specialized in a certain type of
car, and a chef can be famous for his chocolate recipies.

++ The 'chef' progammers are the ones who _write_ the recipies.

Very much true. But even a non-chef cook can make an excellent meal.

++ In 18 years of programming, I've run into only a handful of
++ 'chef' programmers.

That's probably true for many professions.

Abigail
--
perl -wle 'print "Prime" if (1 x shift) !~ /^1?$|^(11+?)\1+$/'

Tom Christiansen

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

[courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc,
"T Jurik" <tju...@li.net> writes in an address now published:

:Very good programmers do not have higher


:intelligence than other people in professional positions.

A brilliant violinist might also not have higher intelligence
than an accountant. But that doesn't mean you can automatically
make anyone a great violinist. In fact, you cannot. There are
gifts. Do not forget this.

--tom
--
"I think I'll side with the pissheads on this one." --Larry Wall

Abigail

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

bir...@my-dejanews.com (bir...@my-dejanews.com) wrote on MDCCLIII
September MCMXCIII in <URL: news:6mejaq$j5q$1...@nnrp1.dejanews.com>:
++ In article <8cbtrpb...@gadget.cscaper.com>,
++ Randal Schwartz <mer...@stonehenge.com> wrote:
++ >

++ > >>>>> "Dan" == Dan Nguyen <nguy...@egr.msu.edu> writes:
++ >
++ > Dan> The person needs to be a "natural" programmer. Generally I feel that
++ > Dan> most people have hard time not with the language but with the process
++ > Dan> of programming. A person could learn Perl as a first language very
++ > Dan> easily and have no problems, while others could become stuck on the
++ > Dan> syntax of the language.
++ >
++ > I'll second this. I see far too many people *attempting* programming
++ > that would probably have a better time being firefighters or line
++ > chefs or congressmen or something. Sure, maybe nearly anyone with
++ > enough effort can hack out a VB script to automate a repeated task,
++ > but programming *well* seems to require a twisted aptitude only some
++ > small percentage of the population seems to have. I think I was lucky
++ > to be born with it, given the time at which I was born. :-) No
++ > ordinary amount of education can seem to teach people how to "think"
++ > like a progammer. ("You have these seven transformations possible and
++ > this problem requires converting Q to W... go!")
++
++ Aren't you both talking more about talent and gift ? No amount of
++ education in music composition seems to teach people either how to
++ compose like Beethoven.
++
++ The question, I think, was how you best learn to program. I have run
++ into many who believe that it is a matter of self-study and trial
++ and error. But I feel that is not enough.
++
++ What is then a structured way of learning how to program? How is it
++ taught at universities? (Not that I think being a Ph.D.candidate in
++ computer science makes you an expert automatically, but at least there
++ is a fair chance that you might become one, whereas the chance to become
++ one through self-study is most probably quite remote).

Many universities don't make a fixed link programming <-> programming
language. When I went to university, the first 6 weeks of the course
"Introduction to Programming" consisted of Hoare triples and correctness
proofs. Later that course, we got Pascal, as you need something to your
lab sessions on. But after the first half year, any programming course
mainly used pseudo-code. If later on you needed a specific language;
you could get a pointer to a manual. Only in the third year, some other
languages were discussed, just to introduce different concepts.
It was the concept that was important, not the language that acted
as an example.

Pick a book like "Introduction to Algorithms" from Cormen, Leiserson
and Rivest. It doesn't use an existing language. It uses English,
pictures and pseudo-code. Buy the bible of Computing Science, "The
Art of Computer Programming" from Knuth. Algorithms are described in
English, and when code for algorithms is shown, a low level make up
language is used.

Learning how to program should not focus on a programming language.
It should focus on how to translate a problem into a recipe for a
computer. Just like learning how to drive shouldn't focus on how
to operate the radio or the automatic windows; but how to behave
in traffic.

Abigail
--
perl -wle '$, = " "; sub AUTOLOAD {($AUTOLOAD =~ /::(.*)/) [0];}
print+Just (), another (), Perl (), Hacker ();'

Mark-Jason Dominus

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Will Rose

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Larry Rosler (l...@hpl.hp.com) wrote:
[...]
: Sample of one, unfortunately. My kids started with Basic, which (as
: Dijkstra says) is a terminal disease. They are *not* professional
: programmers. :-)

Well, maybe. I started with HP Technical Basic, writing fairly large
programs which I then had to maintain; it taught me a lot about coding
standards pretty quickly. OTOH, I was reading Software Tools at the
same time, which gave me some idea of how things might be better
arranged.


Will
c...@crash.cts.com

sylv...@mypc.microtec.net

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

On 20 Jun 1998 22:40:58 GMT, be...@rigel.oac.uci.edu (John Beppu)
wrote:

>
>
> I am of the opinion that the best way to become familiar with
> pointers is to learn an assembly language of the architecture
> you use most often. I knew x86 assembly before I knew C, but
> moving to C from assembly was not a problem. A lot of times,

> I found myself thinking, "this is kinda like assembly" while
> learning C.
>

Well, I've done some assembly on 6502 and 8080 microprocessor as well
as some Forth and I would say that they introduced a hurdle when I try
to learn C the first time, to the point where I abandoned it for a
couple of year. I was too thinking physical memory too much and it
made pointer arithmetic hard to grasp. I had a very hard time
understanding why adding 1 to a pointer would not just increment it by
one byte.

After getting over that, I would say that Forth and assembly helped
me, but it didn't look that way back then.


--
Sylvain Poirier
sylv...@mypc.microtec.net (remove mypc. for reply)
___
C is mother, C is father.

Tom Christiansen

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

[courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc, sylv...@microtec.net writes:
:I was too thinking physical memory too much and it


:made pointer arithmetic hard to grasp. I had a very hard time
:understanding why adding 1 to a pointer would not just increment it by
:one byte.

Because the precursors of C dealt only in words, not types of
varying sizes.

--tom

--
"Espousing the eponymous /cgi-bin/perl.exe?FMH.pl execution model is like
reading a suicide note -- three days too late."
--Tom Christiansen <tch...@mox.perl.com>

Jason E. Steele

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

be...@rigel.oac.uci.edu (John Beppu) writes:
[SNIP]

> I am of the opinion that the best way to become familiar with
> pointers is to learn an assembly language of the architecture
> you use most often. I knew x86 assembly before I knew C, but
> moving to C from assembly was not a problem. A lot of times,
> I found myself thinking, "this is kinda like assembly" while
> learning C.

I'll second that. I learned 6809 assembly before I learned C and
once I connected pointers in C with analagous concepts in assembly, I
had very little trouble with them.

Of course, that works with other things as well. I was a physics
(i.e. math) major before I was a computer science major. I remember
the first time I saw recursion, I said, "Hey, this looks sort of like
proof by induction."

--
Jason E. Steele
jes...@compugen.net

Ben Pfaff

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Of course, that works with other things as well. I was a physics
(i.e. math) major before I was a computer science major. I remember
the first time I saw recursion, I said, "Hey, this looks sort of like
proof by induction."

That's funny: I was a programmer long before I learned serious math.
The first time I saw proof by induction, I said, ``Hey, this looks
sort of like recursion.''

Ronald J Kimball

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Larry Rosler <l...@hpl.hp.com> wrote:

> Sample of one, unfortunately. My kids started with Basic, which (as
> Dijkstra says) is a terminal disease. They are *not* professional
> programmers. :-)

I started with BASIC, and I *am* a professional programmer. :-P

--
_ / ' _ / - aka - r...@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chip...@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."

Sunil Rao

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Ben Pfaff <pfaf...@pilot.msu.edu> wrote, and I reply...

funny... to me they always seemed to be quite separate and different.
until one day it all clicked together. i was using both Proof by
Induction and Recursion for months before the connection clicked...

but the first thing that came to mind when i saw recursion was
Recurrence Relations... the conenction with Induction was not
immediately apparent to me... :(

--
"I see you have books under your arm, brother. It is indeed a rare pleasure
these days to come across somebody that still reads, brother."

- Anthony Burgess

Tom Christiansen

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

[courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc,
r...@coos.dartmouth.edu (Ronald J Kimball) writes:
:I started with BASIC, and I *am* a professional programmer. :-P

So did Larry. So did Randal. So did I.

I first learned BASIC (BASIC-PLUS under RSTS/E), followed by Fortran,
Pascal (UCSD Pascal), and both PDP-11 and Z-80 assemblers before I even
started on C, which was in turn then followed by sh, csh, awk, REXX, lisp,
and so many others that I long ago lost count. I don't know whether C
would have made as much sense without that prior BASIC/Pascal/assembler
background. I don't know whether Perl would have made as much sense
without the prior C/sh/awk background.

Of course, I have never understood why anyone thinks they need anything
but K&R to learn C, either. :-)

--tom
--
If you want to program in C, program in C. It's a nice language. I
use it occasionally... :-)
--Larry Wall in <75...@jpl-devvax.JPL.NASA.GOV>

Graeme Fenwick

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

sylv...@mypc.microtec.net wrote in message
<358d0d34...@news.microtec.net>...
> [assembly] introduced a hurdle when I tried

>to learn C the first time, to the point where I abandoned it for a
>couple of year. I was too thinking physical memory too much and it

>made pointer arithmetic hard to grasp. I had a very hard time
>understanding why adding 1 to a pointer would not just increment it by
>one byte.


I can kind of sympathise- knowing how the machine works and being aware of
the dual high/low level nature of C means you start to think about things
too deeply at an early stage (if you can still find my recent post "A few C
questions"- probably gone by now- you'll see the way I approach the
language), and worrying about things that probably don't matter at that
stage. Quite often now, although I initially saw C as more high level, I
tend to automatically assume things are done at a much lower level, and then
I think "Oh, I don't have to worry about that, the compiler will
automatically promote it", and so on....
When I was learning BASIC I just didn't think that way. I just played around
with it- the downside with that was I never learned a lot of important
things, and I caught the terrible "8-bit-BASIC-with-no-procedures" bug of
using GOTO and writing code at the machine, only having a semi-formed idea
of the specification of the game (or whatever), let alone the algorithm, let
alone the pseudo-code, let alone the code!!!!!
When I first got Turbo Basic for my Atari XL (which added procedures to the
previously GOTO/GOSUB only Atari BASIC), I sat down and wrote an algorithm
for my program, and I was gobsmacked how easy it was to debug.
Did I learn from that? Did I ****!!!
I wish, when I had first been taught about pseudocode etc, that they had
pointed out that, although it was a bit boring if you were used to writing
code straight off, the pay-off in terms of debugging and ability to improve
your program (and general lack of what-the-***-am-I-looking-at type
spaghetti code)
easily justified the time spent working out algorithms, charts, proper specs
etc.
In fact, I've noticed (now that I'm getting back into programming) that most
of the problems in my code are evident at the algorithm stage, and a hell of
a lot easier to correct when they're still in plain English.

All that having been said (more than enough...!), I don't think that a good
structured BASIC is *that* bad a language to start off with. If anyone out
there can successfully teach C to programming novices, they have my respect,
because I reckon it needs a bit too much understanding of a number of
computer concepts, and I'm not sure about Pascal. Just make it clear *why*
they should be using good programming practice, and that they are following
it, and I don't believe there is such a thing as a totally bad language.

Enough enough waffle. If I'd planned all that out completely I could have
said what I'd wanted to in half the space ;-)

>C is mother, C is father.

??!

-Graeme Fenwick

Cameron Dorey

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to Randal Schwartz

[cc'd to RS with apologies, I just couldn't help it]

Randal Schwartz wrote:
>
> [snip]
> ... programming *well* seems to require a twisted aptitude only some


> small percentage of the population seems to have. I think I was lucky

> to be born with it, given the time at which I was born. :-)

> [actual relevant stuff snipped again]

What time were you born? I think I was born at 7:53 A.M. Is this why I
have to work so hard at it, that there is some kind of circadian rhythm
involved in aptitudes, which actually starts at the time of your birth?

Sorry, I said I couldn't help it.

BTW, I can't draw, either, but I _can_ cook, so mornings must be good
for something ;^).

Cameron
came...@mail.uca.edu

Josh Kortbein

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Abigail (abi...@fnx.com) wrote:
: bir...@my-dejanews.com (bir...@my-dejanews.com) wrote on MDCCLIII

: September MCMXCIII in <URL: news:6mejaq$j5q$1...@nnrp1.dejanews.com>:
: ++ In article <8cbtrpb...@gadget.cscaper.com>,
: ++ Randal Schwartz <mer...@stonehenge.com> wrote:
: ++ >
: ++ > >>>>> "Dan" == Dan Nguyen <nguy...@egr.msu.edu> writes:
: ++ >
: ++ > Dan> The person needs to be a "natural" programmer. Generally I feel that
: ++ > Dan> most people have hard time not with the language but with the process
: ++ > Dan> of programming. A person could learn Perl as a first language very
: ++ > Dan> easily and have no problems, while others could become stuck on the
: ++ > Dan> syntax of the language.
: ++ >
: ++ > I'll second this. I see far too many people *attempting* programming
: ++ > that would probably have a better time being firefighters or line
: ++ > chefs or congressmen or something. Sure, maybe nearly anyone with
: ++ > enough effort can hack out a VB script to automate a repeated task,
: ++ > but programming *well* seems to require a twisted aptitude only some
: ++ > small percentage of the population seems to have. I think I was lucky
: ++ > to be born with it, given the time at which I was born. :-) No

: ++ > ordinary amount of education can seem to teach people how to "think"
: ++ > like a progammer. ("You have these seven transformations possible and
: ++ > this problem requires converting Q to W... go!")
: ++
: ++ Aren't you both talking more about talent and gift ? No amount of
: ++ education in music composition seems to teach people either how to
: ++ compose like Beethoven.
: ++
: ++ The question, I think, was how you best learn to program. I have run
: ++ into many who believe that it is a matter of self-study and trial
: ++ and error. But I feel that is not enough.
: ++
: ++ What is then a structured way of learning how to program? How is it
: ++ taught at universities? (Not that I think being a Ph.D.candidate in
: ++ computer science makes you an expert automatically, but at least there
: ++ is a fair chance that you might become one, whereas the chance to become
: ++ one through self-study is most probably quite remote).

: Many universities don't make a fixed link programming <-> programming
: language. When I went to university, the first 6 weeks of the course

Then again, many of them do. Three years ago, when I took a (snooze of
a) CS class at my university, they were using Scheme in the intro class,
in order to keep things fairly theoretical. They were well-intentioned,
but obviously things didn't work out because they've since switched to
C++.

I think they might require one semester of algorithm analysis before
graduation. Long before my time, there was a course in logic required.
No longer.


Josh


_________________________________________________________
I do not trust your bitch.
- Frederich Nietzche, in _Also Sprach Zarathustra_


Will Rose

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

Graeme Fenwick (gfen...@BYESPAMprimex.co.uk) wrote:
: sylv...@mypc.microtec.net wrote in message

: <358d0d34...@news.microtec.net>...
: > [assembly] introduced a hurdle when I tried
: >to learn C the first time, to the point where I abandoned it for a
: >couple of year. I was too thinking physical memory too much and it
: >made pointer arithmetic hard to grasp. I had a very hard time
: >understanding why adding 1 to a pointer would not just increment it by
: >one byte.


: I can kind of sympathise- knowing how the machine works and being aware of
: the dual high/low level nature of C means you start to think about things
: too deeply at an early stage (if you can still find my recent post "A few C
: questions"- probably gone by now- you'll see the way I approach the
: language), and worrying about things that probably don't matter at that
: stage. Quite often now, although I initially saw C as more high level, I
: tend to automatically assume things are done at a much lower level, and then
: I think "Oh, I don't have to worry about that, the compiler will
: automatically promote it", and so on....


One quite important part of writing standard C is knowing what not to
know; preferably, do not attempt to find out how this structure is
laid out in memory, how this bitfield is packed, and so on. This need
for selective ignorance is hard for beginners to grasp, and a major
difference from assembly language where, in principle, the programmer
knows everything.

Note that C9X will be different; there will be, for instance, a lot of
data types of specific sizes, so the programmer can 'hard-wire' a lot
more code. Whether this is a good thing is left as an exercise for the
reader. Certainly the standard is a lot bigger, and the general (but
not universal) opinion in software nowadays is that bigger is better.


Will
c...@crash.cts.com


Brian lLuethke

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

John Beppu wrote in message <6mhdpq$c...@news.service.uci.edu>...


>In article <odPi1.3807$RS.33...@news3.atl.bellsouth.net>,
>Judson McClendon <judm...@bellsouth.net> wrote:
>

> I am of the opinion that the best way to become familiar with
> pointers is to learn an assembly language of the architecture
> you use most often. I knew x86 assembly before I knew C, but
> moving to C from assembly was not a problem. A lot of times,
> I found myself thinking, "this is kinda like assembly" while
> learning C.
>

> If I ever taught anyone to program, I'd get some Assembly in
> early on to harden them and make them fearless. ;)
>
>
>

>--
>/** be...@uci.edu .........................................................
*/

I wholeheartedly agree. Assembler was the best thing to ever happen
to my c and c++ code. So many pointer problems just went away when I knew
what was going on underneath( not to mention what was going on when
functions were called ). I also found that by having the compiler produce an
assembler file I could spot some problems very quickly that would have
otherwise have taken along time. I learned IBM 370 and 80x86 assembler and
would gladly go through the experience of learning them again.

firewind

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

On 21 Jun 1998, Jason E. Steele wrote:

> I'll second that. I learned 6809 assembly before I learned C and
> once I connected pointers in C with analagous concepts in assembly, I
> had very little trouble with them.

The problem with these lines of thinking (and especially of connecting the
abstract semantics of C to the concrete semantics of the underlying hardware)
is that it, all too often, leads to the unrestrained usage of unportable
constructs.

--
(initiator of the campaign for grumpiness where grumpiness is due in c.l.c)

-Please-! Do -not- copy posted articles to my personal e-mail. Thank you.


firewind

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

On Sun, 21 Jun 1998, Ronald J Kimball wrote:

> Larry Rosler <l...@hpl.hp.com> wrote:
> > Sample of one, unfortunately. My kids started with Basic, which (as
> > Dijkstra says) is a terminal disease. They are *not* professional
> > programmers. :-)
>

> I started with BASIC, and I *am* a professional programmer. :-P

I started with BASIC and, while I eventually overcame the myraid and horrendous
flaws it instilled in me (or so I'd like to think; I'm sure there are many in
this newsgroup who would probably care to debate that fact) it was not
pleasant, it was not easy, and it was not fun. It took some time. Time that,
for certain, could have been better spent. Had I started with a real,
non-braindamaged language first, I am conviced I would have faired much better.

Don't start with BASIC. While it might not leave -permanent- brain-damage, it
just isn't worth it.

--
(initiator of the campaign against BASIC)


Brand and Karina Hilton

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

In article <m3u35f2...@windlord.Stanford.EDU>,

Russ Allbery <r...@stanford.edu> wrote:
>In comp.lang.perl.misc, Mark-Jason Dominus <m...@op.net> writes:
>> Larry Rosler <l...@hpl.hp.com> wrote:
>
>>> Sample of one, unfortunately. My kids started with Basic, which (as
>>> Dijkstra says) is a terminal disease.
>
>> I am happy to report that Dijkstra is wrong again. I started with
>> Basic, and was eventually able to eradicate it.
>
>> It wasn't easy, thought, and since the remedy was injections of APL, one
>> could argue that the cure was worse than the disease.
>
>Funny, I started with BASIC and it proved to be an excellent introduction
>to Pascal and a way to get me to appreciate Perl's statement modifier if.
>
>But then I learned on VMS BASIC, not on some line-number-driven brain-dead
>monstrosity. :)

I almost started with a line-number-driven brain-dead BASIC monstrosity...
BASIC on the TI 99-4. Fortunately, the machine itself cured me. I had
entered about 300 lines of a game I was writing when Mom called me for
supper. I set the computer aside on my bed and when I got back, all the
line numbers in my GOTOs had morphed into 32767s. I never programmed in
BASIC again, but I did learn a valuable lesson about air flow in electronic
equipment. Specifically, if your computer has vents on the bottom, turn it
off before you set it on your pillow. :-)


Brand

Ben Pfaff

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

On 21 Jun 1998, Jason E. Steele wrote:

> I'll second that. I learned 6809 assembly before I learned C and
> once I connected pointers in C with analagous concepts in assembly, I
> had very little trouble with them.

The problem with these lines of thinking (and especially of connecting the
abstract semantics of C to the concrete semantics of the underlying hardware)
is that it, all too often, leads to the unrestrained usage of unportable
constructs.

I think that, before you can be a top-notch programmer, you have to
learn a low level language (some machine's assembly language,
preferably), and a high level language (maybe a Pascal variant or
BASIC or Perl). That way you know how it works at the hardware level,
and you understand how it can be abstracted. After that, you should
be ready to know what is efficient and what not to know, in C.

FWIW I learned MS's GW-BASIC under MS-DOS first, then Turbo Pascal,
then C, with a few unimportant obscure languages thrown in for good
measure.


jes...@compugen.net

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

firewind <fire...@metroid.ml.org> writes:
> On 21 Jun 1998, Jason E. Steele wrote:
> > I'll second that. I learned 6809 assembly before I learned C and
> > once I connected pointers in C with analagous concepts in assembly, I
> > had very little trouble with them.
>
> The problem with these lines of thinking (and especially of connecting the
> abstract semantics of C to the concrete semantics of the underlying hardware)
> is that it, all too often, leads to the unrestrained usage of unportable
> constructs.

You are correct, of course, and I was not trying to suggest that knowledge
of an implementation is sufficient to learn C. However, with the
proviso that all analogies are suspect, I still think there is a great
deal of value in using analogies with things you already know when you
are trying to learn something new; particularly difficult abstract
concepts.

Randal Schwartz

unread,
Jun 21, 1998, 3:00:00 AM6/21/98
to

>>>>> "Tom" == Tom Christiansen <tch...@mox.perl.com> writes:

Tom> [courtesy cc of this posting sent to cited author via email]
Tom> In comp.lang.perl.misc,
Tom> r...@coos.dartmouth.edu (Ronald J Kimball) writes:
Tom> :I started with BASIC, and I *am* a professional programmer. :-P

Tom> So did Larry. So did Randal. So did I.

Tom> I first learned BASIC (BASIC-PLUS under RSTS/E),

Ooooh. You had a *real* BASIC. I had to use the HP2000 BASIC, which
was VERY primitive compared to BASIC-PLUS. Imagine 80-character
strings (all 26 of them!) and arrays of a single dimension only.

Tom> Of course, I have never understood why anyone thinks they need anything
Tom> but K&R to learn C, either. :-)

Me too. I learned C from K&R (first edition) and the source code to
Unix (V6 and V7).

--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

Ben Pfaff

unread,
Jun 21, 1998, 3:00:00 AM6/21/98