first language
Fred Kunkel
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
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
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
Fred Kunkel wrote:
>
> Is perl a good language for the non-programer to attempt learning a cgi
> should one start with some other language that might be easier to
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
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
> 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
Rich Morin <r...@cfcl.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
In article <6mbktf$5qp$1...@msunews.cl.msu.edu>, Dan Nguyen
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
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
>>>>> "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
>>>>> "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
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
Larry Rosler <l...@hpl.hp.com> wrote:
: In article <6mbktf$5qp$1...@msunews.cl.msu.edu>, nguy...@egr.msu.edu
: ...
: > 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
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
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
# 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
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
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
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
Abigail (abi...@fnx.com) wrote:
: Randal Schwartz (mer...@stonehenge.com) wrote on MDCCLIII September
: MCMXCIII in <URL: news:8cbtrpb...@gadget.cscaper.com>:
: ++
: ++ 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!")
: ++
: ++ 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
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
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
> 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
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
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
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
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
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
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.
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
-----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
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
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
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
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
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
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
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
[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
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> 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
++ > 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!")
++
++ 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
In article <MPG.ff5e8a73...@nntp.hpl.hp.com>,
Will Rose
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.
sylv...@mypc.microtec.net
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
[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
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
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
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
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
[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
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
>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
[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
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,
: ++ > 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
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.
Brian lLuethke
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
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
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
In article <m3u35f2...@windlord.Stanford.EDU>,
Russ Allbery <r...@stanford.edu> wrote:
>In comp.lang.perl.misc, Mark-Jason Dominus <m...@op.net> writes:
>
>>> Sample of one, unfortunately. My kids started with Basic, which (as
>>> Dijkstra says) is a terminal disease.
>
>> 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.
>
>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
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
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
>>>>> "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
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).
I learned C from a crummy tutorial and reading and writing lots of (at
first pretty crummy too) code, then when I got serious about it I
bought a copy of the Standard. This is actually a pretty good way to
go about it since reading the Standard straightens out all the
misconceptions, and writing code made me aware of practical
considerations.
Mark-Jason Dominus
In article <6mf1o8$nc4$1...@monet.op.net>,
m...@op.net (Mark-Jason Dominus) wrote:
>> 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.
In article <6mka4n$n1j$1...@nnrp1.dejanews.com>, <r...@cs.wisc.edu> wrote:
>This is wrong.
>
>In Pascal, read and write have the same syntax (except for optional
>formatting in write). Call by value and call by reference are
>distinguished when defining a function or procedure, not when calling
>it. Since C does not have call by reference, it must simulate it
>with explicit pointers; and this is relevant for calls of standard
>functions like scanf, which look very different from printf.
I must be missing something fundamental here. You begin with `this is
wrong', and then you say a bunch of things that I think are evidently
true.
The contradiction is not apparent to me, and I am not sure what your
point is. If you are refuting me, could you say what it is you are
refuting?
r...@cs.wisc.edu
> Larry Rosler <l...@hpl.hp.com> wrote:
> >
> >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.
This is wrong.
In Pascal, read and write have the same syntax (except for optional
formatting in write). Call by value and call by reference are
distinguished when defining a function or procedure, not when calling
it. Since C does not have call by reference, it must simulate it
with explicit pointers; and this is relevant for calls of standard
functions like scanf, which look very different from printf.
Pointers should be taught early in C, because they are so fundamental.
--
MJSR
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Judson McClendon
John Beppu wrote:
>
> 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. ;)
I completely agree, John. My first language was assembler, and I believe
that I have profited from that throughout my 30 year career. The problem
is that many people won't spend the time and effort to go that rout. This
is the reason I didn't recommend that in my post.
--
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)
Judson McClendon
firewind wrote in message ...
>
>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.
I suspect your problem was not that you started with BASIC, but that you had no,
or little, instruction in good structured programming technique, and possibly a
version of BASIC which did not support good structured constructs. With the
proper instruction, QuickBasic is almost as good a programming language as Pascal,
perhaps better in some respects. Though QuickBasic does not enforce the structure
as Pascal does, QuickBasic supports it. You have subroutines and functions, with
formal declarations and data typing, flexible global and local variables, parameter
passing by reference or value (in PDS 7.1), etc. This is quite enough to teach and
learn good fundamental programming skills. And with the advantage that programming
in BASIC is *quick* and *easy*. I would not choose BASIC to write a large
application, but I write small utilities in BASIC all the time. I can often write
and run a small utility in BASIC before I could fire up my VC++ or VB compilers and
begin coding. My major complaint about BASIC is the implicit declaration of
variables as encountered. While convenient for 'quick and dirty' small programs, it
can be a serious disadvantage on large programs. Like VB, every BASIC should have
an option to require explicit variable declarations. A similar characteristic in
FORTRAN caused a Venus probe to go astray many years ago. This was one of the
triggering events which caused the U.S. DOD to develop Ada.
Now, if you want to discuss languages which *can* leave permanent brain damage if
learned as a first language, I suggest RPG and APL as top contenders. ;-)
? the platypus {aka David Formosa}
In <pudge-19069...@dynamic162.ply.adelphia.net> pu...@pobox.com (Chris Nandor) writes:
>In article <8c7m2db...@gadget.cscaper.com>, Randal Schwartz
><mer...@stonehenge.com> wrote:
[...]
># 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.
I wouldn't touch a monolinguial programer with a brage pole. By learning
new languges you get a new perspective on the univers that improves your
programing ability. IMHO A cultured programer would have under there belt
A Languge of chouse, Knowlige of C, Knowlige of a functional languge
(Commen Lisp or Scheam), Knowlige of an OOP languge that is not C++,
Knowlige of a least 2 other languges, and the knowlige of an obscure
little know languge that its not raly used anywhere.
Also given a set of turing compleat tools a cultured programmer should be
able to use them. Even if most peaple wouldn't consider them a progerming
languge.
--
I'm a perl programer; if you need perl programing, hire me.
Please excuse my spelling as I suffer from agraphia; see the url. Support NoCeM
http://www.cit.nepean.uws.edu.au/~dformosa/Spelling.html http://www.cm.org/
I'm sorry but I just don't consider 'because its yucky' a convincing argument
Mark Morgan Lloyd
In article <MPG.ff5e8a73...@nntp.hpl.hp.com>, l...@hpl.hp.com
(Larry Rosler) wrote:
> 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.
A way that I've used when explaining such things is to introduce a pointer
as something which is returned by a (not necessarily genuine) operating
system when it wants to refer to an internal structure. The worst possible
way of introducing pointers is muddled in with dynamically-allocated
memory and structures such as trees and lists, i.e. the way most books do
it :-)
I learnt FORTRAN first (on punched cards)-: followed by about three years
in which I did nothing but assembler... later BASIC then Pascal (etc.) but
I've never done anything in anger in C or C++.
Mark Morgan Lloyd
mark...@cix.co.uk
[Opinions above are the author's, not those of his employers or
colleagues]
r...@cs.wisc.edu
In article <6mkgnr$38m$1...@monet.op.net>,
m...@op.net (Mark-Jason Dominus) wrote:
>
> In article <6mf1o8$nc4$1...@monet.op.net>,
> m...@op.net (Mark-Jason Dominus) wrote:
> >> 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.
>
> >
> >In Pascal, read and write have the same syntax (except for optional
> >formatting in write). Call by value and call by reference are
> >distinguished when defining a function or procedure, not when calling
> >it. Since C does not have call by reference, it must simulate it
> >with explicit pointers; and this is relevant for calls of standard
> >functions like scanf, which look very different from printf.
>
> wrong', and then you say a bunch of things that I think are evidently
> true.
>
> The contradiction is not apparent to me, and I am not sure what your
> point is. If you are refuting me, could you say what it is you are
> refuting?
Pedagogically, there is a vast difference between simulating call by
reference with pointers and having actual call by reference. As should
be readily apparent, I am contradicting the statement that immediately
preceded "This is wrong.".
"The case like this" was concerned with an early stage of learning: in C,
you must either supply non-standard input routines (which must at
some point be unlearned) or use scanf (with an explanation of pointers
in order to understand &, or with no explanation at all). The best option
is to explain the pointers, since pointers are so fundamental to C. By
contrast, the complexities in Pascal can generally be ignored at this
level.
With Pascal, you can use readln and writeln with symmetry because
call by reference is actually available. With C, you must treat the
simulated call by reference parameters and arguments differently: in
the function prototype, when calling the function and when referring
to the arguments. In particular, no syntactic difference will be noted
by the students in calling readln or writeln; pointers are in any event
much harder to understand than procedures that change the variables
supplied as arguments.
We can continue the discussion by e-mail if this is still unclear.
Lawrence Kirby
In article <6mj3a3$ank$1...@csnews.cs.colorado.edu>
tch...@mox.perl.com "Tom Christiansen" writes:
> [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.
I think more fundamentally you would end up with a very odd language if
pointer arithmetic did work in bytes. I think the decision would be the same
for any language high level language that supports pointer arithmetic,
even for a language with no historical baggage.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
TNap
In article <6mhevk$jrp$1...@news01.li.net>, T Jurik <tjurik_...@li.net> wrote:
>
>>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
You hit it right on the head. I've been programming since the 1950s
and have used quite a few tools over the years. So many of the newer
employees are "one trick ponies" and fail to see the utility of a variety
of tools. Getting back to the newsgroup, perl is one tool that, once learned
speeds up getting jobs out the door, which is what they pay us for. Aesthetics
be damned but some tools are just better than others for writing cleanly.
--
Cheers, Tom Napolitano |
tom...@concentric.net |
Clinton Pierce
In article <6mhfcc$k4q$1...@news01.li.net>,
"T Jurik" <tjurik_...@li.net> writes:
>Deva Seetharam wrote in message <358AA28C...@execpc.com>...
>>
>>Programming is undoubtedly an art.
>
>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.
I disagree. Any number of non-brilliant people are currently employed as
adaquate programmers. (Carefully sidestepping the loaded word "good" and
I won't step into the intelligence == good programmer bear trap either...)
I think adaquate programming can be taught to anyone willing to learn.
But original and creative programming is something you have to be born
with, or at least predisposed to.
I can be taught to draw. Learn the concepts of perspective, shading, and
contours. I'm no good at it, I have no "knack" for it. If pressed, I
can render a usable image. Certainly not beautiful or "art" by any stretch.
I know many people who can draw beautifully. I think the same principle
applies to programming, or writing novels, or playing voilin.
--
+------------------------------------------------------------------------+
| Clinton A. Pierce | "If you rush a Miracle Man, | http://www. |
| cpie...@ford.com | you get rotten miracles" | dcicorp.com/ |
| fu...@ameritech.net |--Miracle Max, The Princess Bride| ~clintp |
+------------------------------------------------------------------------+
GCSd-s+:+a-C++UALIS++++P+++L++E---t++X+b+++DI++++G++e+>++h----r+++y+++>y*
Steve Linberg
In article <8csoky8...@gadget.cscaper.com>, Randal Schwartz
<mer...@stonehenge.com> wrote:
> >>>>> "Tom" == Tom Christiansen <tch...@mox.perl.com> writes:
>
> 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.
Heck, I started with TRS-80 BASIC (listing the "source code" to Hamurabi
to learn how to sell my wheat. Amazing.) And shortly thereafter moved up
to Atari (400) BASIC and AppleSoft BASIC. In fact, I dimly recall
Sinclair 1000 BASIC, where you couldn't type keywords, each was bound to a
key. And I think I still have my old Atari 2600 BASIC cartridge, which
allowed you to write a nine-line program using a joystick. There were
some great programming contests on that box...
From there it was straight to 6502 assembler, then C (courtesy of K&R, of
course) a year or two later.
Perl would have destroyed me for all other languages had I not known 6502
assembler (any would have done) and C first, however. I've mucked about
in a dozen or so languages over the years, but have really done 99% of my
stuff in 6502, C, BASIC (yes) and of course, Perl.
_____________________________________________________________________
Steve Linberg National Center on Adult Literacy
Systems Programmer &c. University of Pennsylvania
lin...@literacy.upenn.edu http://www.literacyonline.org
Stuart McDow
lin...@literacy.upenn.edu (Steve Linberg) writes:
>
> Heck, I started with TRS-80 BASIC (listing the "source code" to
> Hamurabi to learn how to sell my wheat. Amazing.)
Hey, me too! When was that? 1976? I think I was a freshman in high
school....
> From there it was straight to 6502 assembler, then C (courtesy of
> K&R, of course) a year or two later.
Hmmm, I found an Z80 assembler for the TRS-80 (had to load it via the
cassette tape interface), so my next language after TRS-80 BASIC
(which was produced by Micro$oft, BTW) was Z80 assembly. Quite fun,
actually. That was probably 1978. Fortran and Pascal followed in quick
succession. Alas, I didn't start learning C until 1982. And double
alas, I didn't start learning perl until 1989 or so. I'll always be a
newbie. <SIGH> :-)
> Perl would have destroyed me for all other languages
Perl has destroyed me for all other languages. I gave up on C and C++
many years ago. Nowadays, the only thing C is good for is for XS
modules. <Insert diety here> save us all from java.
--
Stuart McDow Applied Research Laboratories
smc...@arlut.utexas.edu The University of Texas at Austin
"Look for beauty in roughness, unpolishedness"
Chris Engebretson
In article <6mjheb$shg$1...@csnews.cs.colorado.edu>,
Tom Christiansen <tch...@mox.perl.com> writes:
[ snip ]
|> 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.
This illustrates one of the problems with the answers that people
inevitably give when posed the tired-but-true "What language
should I learn first?" question. The die-hard Bazzle (for lack
of a better hypothetical language name) fanatics are quick to
leap to their feet and shout "Learn Bazzle! The syntax is
intuitive! The facilities are endless! Fooble rots your brain!
Barble gives you gas! Bazzle is the end-all silver bullet!"
But since these individuals have become so deeply entrenched into
the Bazzle way of doing things, and perhaps since they have been
using Bazzle for so long, they have forgotten the road they took
to get to their current position. Additionally, as you note
above, they also may be in no position to judge how their prior
experiences with other languages (a la Fooble and Barble) have
influenced their current style and methodologies, and as a
result, influenced their outlook on Bazzle. [*]
Typically, the knee-jerk responses that questions such as this
provoke are not based on experiences with one single language,
but instead on a good number of languages in a good number of
distinct environments. The people helpfully providing the
answers may not be consciously aware of it, but the answers
themselves are invariably skewed. In part, this is because the
original question is not very good to begin with.
Essentially, the unqualified question "What's the best language
to start with?" is about as useful as the question "What's the
best color?" There *are* some differences; for example, the
latter is somewhat less likely to ignite a full-scale flame war.
We can turn these into better questions by further qualifying
them with specifics: "What's the best color for camoflauge?" is
a somewhat more useful question. If somebody were to answer
"hot pink," then we could probably safely ridicule the
respondent (unless the desired operation was to ambush a flock
of flamingos, in which case you could argue that the question
should have been qualified even further.)
|> Of course, I have never understood why anyone thinks they need
|> anything but K&R to learn C, either. :-)
K&R2 is certainly an excellent book, and can be considered the de
facto C reference (ISO and ANSI standards notwithstanding.) It
may not be quite enough for the virgin C programmer to get up to
speed, however. Perhaps the most useful way for a new C programmer
to use K&R is to keep it within reach while going over a piece of
well-written, well-documented C code.
Regards,
[*] No offense to the Fooble and Barble devout. :-)
--
Chris Engebretson - Raytheon STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6940
http://edcwww.cr.usgs.gov/ mailto:enge...@sg1.cr.usgs.gov
Opinions are not those of Raytheon Systems Company or the USGS.
Aaron Crane
In article <linberg-2206...@projdirc.literacy.upenn.edu>,
lin...@literacy.upenn.edu (Steve Linberg) writes:
> In fact, I dimly recall Sinclair 1000 BASIC, where you couldn't type
> keywords, each was bound to a key.
A brilliant design idea for a machine with 1024 bytes of RAM: each keyword
is just a keypress, internally and externally, and so takes only one byte of
storage. The ZX81 manual has detailed explanations of memory usage for your
BASIC source code.
--
Aaron Crane <aaron...@pobox.com> <URL:http://pobox.com/~aaronc/>
Lawrence Kirby
In article <6mm281$l...@espresso.cafe.net> k...@cafe.net "Kaz Kylheku" writes:
>In article <898514...@genesis.demon.co.uk>,
>Lawrence Kirby <fr...@genesis.demon.co.uk> wrote:
>>>Because the precursors of C dealt only in words, not types of
>>>varying sizes.
>>
>>I think more fundamentally you would end up with a very odd language if
>>pointer arithmetic did work in bytes. I think the decision would be the same
>>for any language high level language that supports pointer arithmetic,
>>even for a language with no historical baggage.
>
>No, you would end up with BCPL! Hardly odd at all. In BCPL, a pointer refers
>to a cell, and arithmetic works in cell units.
And BCPL supports vectors of cells. Pointer arithmetic works in units of
cells (i.e. the array/vector element unit), not bytes or characters.
Indeed BCPL was the ``historical baggage'' I was thinking of specifically
above.
>Scaling for aggregates is done
>the hard way. :)
That's because the language has rather limited support for this sort of
thing built in. WHat support it does have is, I believe, consistent with
my statement above (although my BCPL is a little rusty these days).
Abigail
Chris Engebretson (enge...@sg1.cr.usgs.gov) wrote on MDCCLVI September
MCMXCIII in <URL: news:EuyxM...@igsrsparc2.er.usgs.gov>:
++
++ K&R2 is certainly an excellent book, and can be considered the de
++ facto C reference (ISO and ANSI standards notwithstanding.) It
++ may not be quite enough for the virgin C programmer to get up to
++ speed, however. Perhaps the most useful way for a new C programmer
++ to use K&R is to keep it within reach while going over a piece of
++ well-written, well-documented C code.
It probably also depends on your prior knowledge and experience. K&R may
be too terse if C is your second language, and your previous language
was Lisp. It's enough for someone knowing 5 different ALGOL derivates
and having 7 years of programming experience.
For everyone else in between, the answer whether K&R is enough to
learn C from is "maybe".
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'
Paul Buder
In <6mlctf$vam$1...@nnrp1.dejanews.com> r...@cs.wisc.edu writes:
>"The case like this" was concerned with an early stage of learning: in C,
>you must either supply non-standard input routines (which must at
>some point be unlearned) or use scanf (with an explanation of pointers
>in order to understand &, or with no explanation at all). The best option
All this talk of scanf. I hope you people don't actually use that
horrid function in your C code. Can you say buffer overflow? fgets
and fread take a little more work sometimes but at least you can
control the size of things getting put into your variables.
David Adler
On Sun, 21 Jun 1998 21:27:22 GMT, Randal Schwartz <mer...@stonehenge.com> wrote:
>Me too. I learned C from K&R (first edition) and the source code to
>Unix (V6 and V7).
Then again, you're nuts. :-) (kidding, kidding!)
--
David H. Adler - <d...@panix.com> - http://www.panix.com/~dha/
"We are the Borg. You will be assimilated! Nah, only kidding. We're
just the Sontarans. Care to take part in some 'medical research'?"
Cameron Foster
On Mon, 22 Jun 1998 22:37:00 GMT, pa...@user1.teleport.com (Paul
Buder) wrote:
[followups set to comp.lang.c]
>
>All this talk of scanf. I hope you people don't actually use that
>horrid function in your C code. Can you say buffer overflow? fgets
>and fread take a little more work sometimes but at least you can
>control the size of things getting put into your variables.
I suspect that if you did an analysis of the responses to questions
posed in c.l.c, you would find that a distillation of those responses
would be that the three most frequent responses boil down to:
1. Read the FAQ.
2. You will get better and more knowledgeable answers in [insert
appropriate newsgroup here]
3. scanf() is evil.
--
Cameron Foster
cdfo...@ix.netcom.com
http://www2.netcom.com/~cdfoster/
Larry Rosler
In article <6mrfv3$2p7$1...@nnrp1.dejanews.com>, bir...@my-dejanews.com
<bir...@my-dejanews.com> says...
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
There are so many! Cobol because it is too wordy; APL because it is too
terse; Pascal because it is uselss; Ada because it is overblown; ...
--
Larry Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
l...@hpl.hp.com
dg...@rand.dimensional.com
[posted and mailed to the cited author]
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
I'm not sure that I qualify as an expert, but the *last* language
I'd want to have to write in is C++.
Unfortunately, my current project requires it. *sigh*
>Birgitt Funk
Daniel
--
Daniel Grisinger dg...@perrin.dimensional.com
"No kings, no presidents, just a rough consensus and
running code."
Dave Clark
Ronald J Kimball
<bir...@my-dejanews.com> wrote:
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
Is this a trick question?
Perl, of course. After I started using Perl, I never wanted to deal
with any other language again. Therefore, Perl should be the last
language I ever deal with.
--
_ / ' _ / - 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."
Cypher
In article <6mrfv3$2p7$1...@nnrp1.dejanews.com> bir...@my-dejanews.com writes:
>In article <3588E674...@nortel.co.uk>,
> "F.Quednau" <qued...@nortel.co.uk> wrote:
>
>
>> Perl is the first laguage that I am trying to explore in depth. And that is
>> 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!
>>
Perl rocks as a first language. I'm learning it very quickly and am
enjoying even staying up late at night reading the camel book. :)
>
>And I 'luvve' this thread - very luvvly statements from ol' realist
>programming moms and dads. So I can't resist:
>
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
>
I don't look forward to learning Java, it just bores me. It's
just applets and wierd things that don't really interest me. Assembler
will be tough, but very useful, so I must learn it, but am not looking
forward much to that either... hehe. :)
>Who bets with me ? Will the thread be as long from here on
>as it was for *first* language ?
>
>:-)
>
>Birgitt Funk
>
>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>http://www.dejanews.com/ Now offering spam-free web-based newsreading
--
~Cypher A.C.S. @Plymouth State
****--->finger cyp...@mindwarp.plymouth.edu for pgp key<---****
"Any sufficiently advanced technology is indistinguishable from magic."
--Arthur C. Clarke
-----------------------------------------------------------------------
Bart Lateur
Judson McClendon wrote:
> I can often write
>and run a small utility in BASIC before I could fire up my VC++ or VB compilers and
>begin coding.
VB *is* BASIC. Very similar to QuickBasic, as you describe it.
Bart.
F.Quednau
bir...@my-dejanews.com wrote:
>
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
>
> as it was for *first* language ?
>
> :-)
> Birgitt Funk
Sooo hard to predict the length of threads, 's like those superstrings...Don't
know enough languages, but I could imagine that writing out binary sequences
must be fairly tough....
01100110110100011011100100101011
There's something nice, simplistic about it, though.
--
____________________________________________________________
Frank Quednau
http://www.surrey.ac.uk/~me51fq
________________________________________________
Judson McClendon
Hmmm. Since I mentioned 'my VC++ or VB compilers...', perhaps you think
I didn't know what VB is? ;-) Actually VB is a GUI development system
which supports a dialect of BASIC for writing what amount to macros,
and which supports some OO concepts. BASIC is a free-standing, purely
procedural language, not embodying any OO concepts. C and C++ are
different languages, after all, are they not? In other words, VB
*includes* a *highly modified subset* of BASIC. VB is *not* BASIC. And
if you think VB is 'very similar to QuickBasic', you couldn't possibly
have used both. It is true that some of the syntax is virtually identical,
but QuickBasic and VB are far more different as a whole than say, Pascal
and ALGOL. The user interfaces are *totally* different, and way programs
are structured is *totally* different. If you are still unconvinced, just
write a minimal 'Hello World!' program in both, print the entire source of
each, and examine them. Very little similarity, eh? The text "Hello
World!" itself is the only part which is even remotely the same. 8-)
John Porter
F.Quednau wrote:
>
> I could imagine that writing out binary sequences
> must be fairly tough....
> 01100110110100011011100100101011
> There's something nice, simplistic about it, though.
In that case, you want Brainf***.
The "hello, world" program looks like this:
>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]>++++++++[<++++>-]
<.#>+++++++++++[<+++++>-]<.>++++++++[<+++>-]<.+++.------.--------.[-]>++++++++[
<++++>-]<+.[-]++++++++++.
(Or so I'm told. I can't even tell you if the linebreaks
need to be where they are.)
http://www.pangea.ca/cet/soft/lang/bf/
--
John Porter
John Porter
dg...@rand.dimensional.com wrote:
>
> I'm not sure that I qualify as an expert, but the *last* language
> I'd want to have to write in is C++.
Surely this is an exaggeration.
You would rather program in Basic? Pascal? Asm? Intercal?
--
John Porter
John Porter
bir...@my-dejanews.com wrote:
>
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
This question assumes that all the languages (!) can be assembled
into one long ordered list. But I don't think that models the
real world accurately. Really, you want a tree.
Perl is at the root node.
From there we branch out through C++, Smalltalk, Scheme, Python...
When you get to the level of "worst" there are hundreds of
languages, none of which I would prefer to another.
--
John Porter
Stuart McDow
dg...@rand.dimensional.com writes:
>
> I'm not sure that I qualify as an expert, but the *last* language
> I'd want to have to write in is C++.
Agreed. What a mess. It's the COBOL of the 1990s.
Gre...@my-dejanews.com
> "F.Quednau" <qued...@nortel.co.uk> wrote:
>
> > Perl is the first laguage that I am trying to explore in depth. And that is
> > 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!
> >
>
> programming moms and dads. So I can't resist:
>
> deal with ? Don't say there isn't one.
>
> as it was for *first* language ?
>
> :-)
>
> Birgitt Funk
>
> http://www.dejanews.com/ Now offering spam-free web-based newsreading
>
My first four years commercial programming were in Hewlett Packard's
'Transact/3000' - it had it's good points but I'll bet you've never heard of
it and that's my main argument against it.
Jan Moren
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
Intercal. Unlike other languages, it was constructed explicitly to be as
difficult and obtruse as possible. Apparently the compiler is available for
several platforms, together with all source written in it. Look it up in the
Hacker's dictionary for more info.
--
MvH Janne Mr. Janne More´n
(jan....@fil.lu.se) Kognitionsforskning
046-222 9758 Kungshuset, Lundagård
046-211 4973 S-222 22 Lund, Sweden
Jonathan Stowe
On Wed, 24 Jun 1998 18:19:15 GMT, bir...@my-dejanews.com wrote :
>
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
>
The Axis GIS system language (Sorry Eric). Check out the docs at
http://www.axis2000.co.uk/ for confirmation.
/J\
Jonathan Stowe
Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>
Daniel Grisinger
In article <35924D...@min.net>
jdpo...@min.net wrote:
>dg...@rand.dimensional.com wrote:
>>
>> I'm not sure that I qualify as an expert, but the *last* language
>> I'd want to have to write in is C++.
>
>You would rather program in Basic? Pascal? Asm? Intercal?
>
someone else's C++, but it is an improvement over the other choices
you presented.
I had never heard of Intercal but found an implementation. I've been
playing with it for a couple of hours and all I can say is, `Wow, and
people think perl looks line noise' :-). Not to mention the amusing,
but somewhat obscure error messages.
>John Porter
Regards,
F.Quednau
Jonathan Stowe wrote:
> > What is the *last* language all you experts would ever want to
> > deal with ? ...
> >
> The Axis GIS system language (Sorry Eric). Check out the docs at
> http://www.axis2000.co.uk/ for confirmation.
Indeed, it looks very cryptic. But it's for making maps, isn't it? Now I realize
how I could get so hopelessly lost once...oh well.
John Porter
Daniel Grisinger wrote:
>
> I had never heard of Intercal but found an implementation. I've been
> playing with it for a couple of hours and all I can say is, `Wow, and
> people think perl looks line noise' :-). Not to mention the amusing,
> but somewhat obscure error messages.
That reminds me of another language which is probably worse...
no, I take that back. But pretty bad, and more resembling
line noise: Teco.
--
John Porter
John Adams
Tom Christiansen wrote:
> I first learned BASIC (BASIC-PLUS under RSTS/E), followed by Fortran,
I first learned Fortran II out of a programmed IBM text I found for $.50
in a used book store, way back in 197...um...let's just say it was the
seventies. Doing all the excercises by hand, without access to a
mainframe, did me a whole lot of good.
> Of course, I have never understood why anyone thinks they need anything
> but K&R to learn C, either. :-)
Well, that's a bit like saying that no one should need anything but the
Camel book to learn Perl, eh? I have access to the A.W.K. awk book, but
I certainly use Dougherty and Robbins by preference.
And I have to second that emotion from whomever (Abigail?) recommended
Knuth's books. I've only bought volume two (Sorting and Searching), but
I wouldn't be without it.
John A
speaking strictly for himself
Tom Christiansen
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
John....@BentonvilleAR.ncr.com writes:
:And I have to second that emotion from whomever (Abigail?) recommended
:Knuth's books. I've only bought volume two (Sorting and Searching), but
:I wouldn't be without it.
Agreed whole-heartedly. But it's "whoever". :-)
--tom
--
There is, however, a strange, musty smell in the air that reminds me of
something...hmm...yes...I've got it...there's a VMS nearby, or I'm a Blit.
--Larry Wall in Configure from the perl distribution
Michael Rubenstein
On Fri, 26 Jun 1998 13:41:57 GMT, John Porter <jdpo...@min.net>
wrote:
But teco was actually intended to be used. In fact, I did use it a
lot until some easier to use editors with reasonable power became
available. I hated teco, but I hated it a lot less than any of the
other editors I saw during most of the 1960s.
Even by today's standards, teco was a very powerful editor. In a head
to head contest, it could destroy a file 3 times as fast as vi and 10
times as fast as emacs :-)
--
Michael M Rubenstein
Abigail
Tom Christiansen (tch...@mox.perl.com) wrote on MDCCLX September
MCMXCIII in <URL: news:6n16r7$9f9$2...@csnews.cs.colorado.edu>:
++ [courtesy cc of this posting sent to cited author via email]
++
++ In comp.lang.perl.misc,
++ John....@BentonvilleAR.ncr.com writes:
++ :And I have to second that emotion from whomever (Abigail?) recommended
++ :Knuth's books. I've only bought volume two (Sorting and Searching), but
++ :I wouldn't be without it.
++
++ Agreed whole-heartedly. But it's "whoever". :-)
Just a minor point: Sorting and Searching is volume 3.
Abigail
--
perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET", "http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl")) -> content)) =~ /(.*\))[-\s]+Addition/s) [0]'
Bart Lateur
bir...@my-dejanews.com wrote:
> What is the *last* language all you experts would ever want to
> deal with ? Don't say there isn't one.
Cobol, ADA, C. Popular for some mysterious reason taht escapes me
completely. I'd prefer Smalltalk, Lisp, FORTH, Modula, APL, ... any
time, although I've not done any real work using these.
And I just can't grasp Prolog.
Bart.