Teaching Programming
Scott Gunderson
I am a high school math teacher and wish to reestablish computer
programming as a course offering at my school. I've been out of the
loop for awhile. My question is which language/compiler do you
recommend for upper level high school students? Unfortunately, I will
probably only have a '286 lab available. My first inclination is to go
for Turbo Pascal 6.0 (no OOP). Others have recommended C++ but I just
don't think it's the best learning environment as a first language.
Also any suggestions on texts/references would be a great help.
Thanks.
Randy Smith
Why not Java?
**********************************************
Randy Smith
Cryonics: Gateway to the Future?
http://www.mindspring.com/~cryon
Roberto Waltman
sgu...@shocking.com (Scott Gunderson) wrote:
>I am a high school math teacher and wish to reestablish computer
>programming as a course offering at my school. I've been out of the
>loop for awhile. My question is which language/compiler do you
>recommend for upper level high school students? Unfortunately, I will
>probably only have a '286 lab available. My first inclination is to go
>for Turbo Pascal 6.0 (no OOP). Others have recommended C++ but I just
>don't think it's the best learning environment as a first language.
>Also any suggestions on texts/references would be a great help.
C++ is definitely NOT a good choice as a first programming
language. For teaching principles, as opposed to technical
details, Turbo Pascal would be ok. You may also consider scheme
or Smalltalk. There are good free versions of both languages
with adequate performance on a '286 platform.
Scheme together with Brian Harvey's "Simply Scheme" as a textbook
would be an excellent starting point.
RW.
PS: Before the flame wars start in response to my opening
statement, let me say, for the record, that I earn my living
writing C++ programs ...
Ben Farley
You could attempt Java but the kids might have trouble with it at first.
I would try C but start it with an introduction to C (C++ if you want
OOP) like possibly C(++) for dummies for a few weeks before getting into
the harder more in depth programming. That will filter those who are not
interested in the actual programming and give those that are a firm base
to start with.
-ben
Stefan Pindl
My first programming language has also been Pascal
I never doubt about this language to be a good choice as first
programming language!
It's easy to change to C or similiar later. I'm doing in software
development now, and i don't think it's wrong to have Pascal as a
"mother language"
Roberto Waltman
Scott Gunderson
On 25 May 1998 21:37:48 GMT, St.P...@t-online.de (Stefan Pindl)
wrote:
Thank you for your replies concerning teaching an introductory
programming course for high school students. Part of my inclination
toward Pascal is that after several years out of the programming loop,
it is a language I would feel very comfortable starting up with again.
Having also programmed in C, it does not strike me as a learning
language. Unfortunately, I have not worked with C++. I will definitely
investigate the scheme suggestion. Thanks again.
Antonio
El Mon, 25 May 1998 20:52:15 GMT, Roberto Waltman escribió:
>sgu...@shocking.com (Scott Gunderson) wrote:
>>I am a high school math teacher and wish to reestablish computer
>>programming as a course offering at my school. I've been out of the
>>loop for awhile. My question is which language/compiler do you
>>recommend for upper level high school students? Unfortunately, I will
>>probably only have a '286 lab available. My first inclination is to go
>>for Turbo Pascal 6.0 (no OOP). Others have recommended C++ but I just
>>don't think it's the best learning environment as a first language.
>>Also any suggestions on texts/references would be a great help.
>
>C++ is definitely NOT a good choice as a first programming
>language. For teaching principles, as opposed to technical
>details, Turbo Pascal would be ok. You may also consider scheme
>or Smalltalk. There are good free versions of both languages
>with adequate performance on a '286 platform.
>Scheme together with Brian Harvey's "Simply Scheme" as a textbook
>would be an excellent starting point.
I am a physicist and I'm presenting elementary programming courses as
well. I usually program my simulations using C++. I do _NOT_ recommend
C++ for teaching purposes, since people will start wasting time with
memory-management problems.
I'd choose MODULA-2 or Scheme. Since MODULA-2 is a (strong typed)
imperative language maybe it's a better choice if what you want is to
focus on the problem (maths?) and not in the language (I mean, most
people is used to imperative languages).
Hope it helps,
Antonio Vieiro
Kumar Balachandran
>>>>> "Antonio" Antonio <ant...@NoSpam.Please> writes:
El Mon, 25 May 1998 20:52:15 GMT, Roberto Waltman escribió:
>sgu...@shocking.com (Scott Gunderson) wrote:
>>I am a high school math teacher and wish to reestablish computer
>>programming as a course offering at my school. I've been out of the
>>loop for awhile. My question is which language/compiler do you
>well. I usually program my simulations using C++. I do _NOT_ recommend
>C++ for teaching purposes, since people will start wasting time with
I agree that C++ is the wrong language to teach begining programmers.
>I'd choose MODULA-2 or Scheme. Since MODULA-2 is a (strong typed)
One of the objectives of any elementary programming course should be
to introduce the fundamentals of programming languages. Scheme lacks
an object system, and is inadequate for demonstrating object oriented
programming (unless you use a package such as miniCLOS (STk:
http://kaolin.unice.fr). However, it helps bring together the Turing
machine and Church's thesis (see The Emperor's New Mind by R. Penrose)
by the utilization of lambda calculus.
I learnt programming in the succession
BASIC-FORTRAN-Pascal-C-C++-Scheme-Lisp (I don't consider
Matlab a real language, it is an interpreted FORTRAN derivative)
In an ideal world, I would have chosen
Scheme->Lisp->C++.
Lisp/Scheme is very convenient for two reasons:
1. Lisp allows almost every useful programming construct (except
call/cc which can be
spoofed with difficulty -- I have never been able to use
continuations myself in any program I wrote, but my brain is
stunted because of the learning process I used.).
2. Lisp allows easy prototying since it is interpreted. A class
heirarchy for C++ is easily converted from Lisp, ignoring the lack
of lists in C++.
3. Of course, Scheme is useful to learn about continuations, it is
elegant and easy to learn. However, Lisp has the tools necessary to
write any reasonable piece of code in a short time.
C++ is useful for speed, and because its what everyone uses?! I
consider it similar to English -- a bastardization of many different
languages to create a "lingua franca" of the programming world -- it
works, and it is evolving and everyone speaks it:-) In contrast, Lisp
is more akin to a classical language such as Latin or Sanskrit -- it
is useful to get the right frame of mind, the right religion, and a
sense of root and origin.
-- Kumar
PS. If there is a double post, 'twas because the quoting got upset.
Martin Rodgers
In article <02vhqry...@rtp.ericsson.se>,
kumar*xspam*@*xspam*rtp.ericsson.se says...
> 2. Lisp allows easy prototying since it is interpreted. A class
> heirarchy for C++ is easily converted from Lisp, ignoring the lack
> of lists in C++.
s/interpreted/incremental/
A language can be compiled, and yet still support incremental
development. Lisp is such a language. I know this is a pedantic point,
but ANSI Common Lisp supports compiling _and_ interpreting.
Incremental development is more of a language than an implementation
issue. Ask yourself: what is the unit of compilation? What do we mean by
"compile"? P.J. Brown answered this in "Writing Interactive Compilers and
Interpreters".
An interactive language also makes prototyping easy. For anyone new to
programming, all code is effectively a prototype.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
J Adrian Zimmer
Scott Gunderson wrote:
> I am a high school math teacher and wish to reestablish computer
> programming as a course offering at my school. I've been out of the
> loop for awhile. My question is which language/compiler do you
> recommend for upper level high school students?
J Adrian Zimmer responds:
Is the advanced-placement exam still Pascal based? If true, that would be
another point in favor of this fine teaching language.
Java has been mentioned by one respondent.
Java is better than C++ because it does memory management and
prevents pointer errors. In fact, it's run time checking will help
students find bugs.
However, what makes Java easier to motivate is its support of
GUI programming. That makes Java more complicated to
program in as well.
I think it would be possible to introduce Java for use with
web browsers. Set up a relatively simple web page and
teach students concepts by having them change the page.
Anybody teaching a class to beginners that way?
J Adrian Zimmer -- jazi...@acm.org
voice: (701) 746-8187 -- fax: (701) 746-4971
http://www.MapFree.com/software_build_and_fix
Kumar Balachandran
>>>>> "Martin" == Martin Rodgers
Martin> In article <02vhqry...@rtp.ericsson.se>,
Martin> kumar*xspam*@*xspam*rtp.ericsson.se says...
>> 2. Lisp allows easy prototying since it is interpreted. A class
>> heirarchy for C++ is easily converted from Lisp, ignoring the
>> lack of lists in C++.
Martin> s/interpreted/incremental/
Martin> A language can be compiled, and yet still support
Martin> incremental development. Lisp is such a language. I know
Martin> this is a pedantic point, but ANSI Common Lisp supports
Martin> compiling _and_ interpreting.
I stand corrected. C++ has no such support for incremental development.
Larry Weiss
Randy Smith wrote:
> Why not Java?
I'd give it a try. There are free implementations available
so the students can have a copy at home with no license or money
issues. The language is free of the nit-pickiness of C's
memory management. The syntax is concise and easy to write
and read. It is object-oriented without needing to learn much
about the theoretical underpinnings of the methodology.
Java applets and programs can be made to do some interesting
things (like display GIF's) without much fuss, so the projects
will be fun and the student's will remain motivated to embellish
their basic programs with work on their own initative. It's
a commercially viable language with a growing base of support.
There's a lot of online tutorial and example resources.
It does not encourage any "bad" programming habits.
It's fun!
- Larry Weiss
Mark Framness
In message <356b667d...@news5.bellatlantic.net> -
rwal...@bellatlantic.net (Roberto Waltman) writes:
ś
ś sgu...@shocking.com (Scott Gunderson) wrote:
ś >I am a high school math teacher and wish to reestablish computer
ś >programming as a course offering at my school. I've been out of the
ś >loop for awhile. My question is which language/compiler do you
ś >recommend for upper level high school students? Unfortunately, I will
ś >probably only have a '286 lab available. My first inclination is to go
ś >for Turbo Pascal 6.0 (no OOP). Others have recommended C++ but I just
ś >don't think it's the best learning environment as a first language.
ś >Also any suggestions on texts/references would be a great help.
ś
ś C++ is definitely NOT a good choice as a first programming
ś language. For teaching principles, as opposed to technical
ś details, Turbo Pascal would be ok. You may also consider scheme
ś or Smalltalk. There are good free versions of both languages
ś with adequate performance on a '286 platform.
ś Scheme together with Brian Harvey's "Simply Scheme" as a textbook
ś would be an excellent starting point.
ś
ś RW.
ś
ś PS: Before the flame wars start in response to my opening
ś statement, let me say, for the record, that I earn my living
ś writing C++ programs ...
No argument here! I have a pretty good grasp of C++ but do agree with you
that C++ is not a great language for brand spanking new programmers.
I would even recommend BASIC. Not Visual BASIC either but plain old BASIC.
Actually I'ld probably not spend the whole course with BASIC but get them
doing some basic [duck, pun intended] programming and once the students are
comfortable with variables and some basic control structures, then move them
onto Pascal or another "classroom language" and concentrate more on problem
solving and simple data sructures.
C++ is extremely feature rich and those who have never seen programming in any
language would be overwhelmed by C++!
I've favored Java in the past but then again the ability to fairly easily do
pink fuzzy bunny programming (PFBP) would be distracting for beginners (the
same argument for Visual BASIC). So I'ld not recommend Java either.
FROM: Mark Allen Framness
HOME: far...@netnet.net
HTTP: http://netnet.net/~farmer/index.html
URL for comp.lang.c NG: http://www.eskimo.com/~scs/C-faq/top.html
URL for comp.lang.c++ NG: http://www.cerfnet.com/~mpcline/c++-faq-lite/
FAQ archive ftp site: rtfm.mit.edu/pub/usenet
Friends don't let friends post drunk!
BenEBrady
I guess I will post my two cents into this thread... If you want a language
that is EASY to teach and will give you almost INSTANT gratification,
(necessary for limited class time, student motivation, etc.) I would strongly
suggest that you look at Clarion from Topspeed Corporation (www.topspeed.com) I
am sure they would give you the product at a good price. The language is very
elegant and very strongly typed. It is data-centric and database neutral in
that you can connect to almost any type of database files. The primary
objective in todays programming classes should be how do I get the job done
quickly. Clarion is the ticket. There are versions for DOS and Windows
available. You can check out comp.lang.clarion for further information.
Topspeed sells a "personal" edition for under $100.00 US. The Professional
Edition comes with replaceable database engines and some nice bells and
whistles. You can get an evaluation copy from Topspeed by requesting it from
them at their website.
Ben E. Brady
Brady & Associates
Ben E. Brady
Brady & Associates
Shriram Krishnamurthi
Kumar Balachandran <kumar*xspam*@*xspam*rtp.ericsson.se> writes:
> 2. Lisp allows easy prototying since it is interpreted.
This is nonsense. It is essentially meaningless to call a _language_
interpreted. Language _implementations_ may be interpreted or
compiled or some hybrid combination thereof, but these are not
properties of languages themselves.
I'm guessing you mean the same thing many others do when they say that
Lisp or Scheme is "interpreted": that you can interactively enter
expressions and get results (in MOST, but not ALL, implementations).
I prefer to call this an interactive programming environment. Some of
these do, in fact, use interpreters. Some others automatically
compile the expression, link it, and execute it. (I know, this is
such radical stuff to most C and C++ programmers!) Some even choose
the strategy based on the expression. For example, Chez Scheme, a
high-quality optimizing compiler for Scheme, also has an interpreter
built in. Depending on the expression in question, it chooses whether
to interpret or compile-link-execute it. The interface in both cases
is the same, so the user can't tell which evaluation strategy was used.
'shriram
Daniel C. Wang
Shriram Krishnamurthi <shr...@cs.rice.edu> writes:
{stuff deleted}
> This is nonsense. It is essentially meaningless to call a _language_
> interpreted. Language _implementations_ may be interpreted or
> compiled or some hybrid combination thereof, but these are not
> properties of languages themselves.
{stuff deleted}
Perhaps so, but it is the case that certain languages are easier to
interpreter rather than compile. Consider for instance Tcl, or any language
with eval and dynamic scope (Emacs Lisp). Not that these language features
can't be "compiled" but that languages with these features are harder to
compile. So the notion of an "interpreted language" is probably a poor
choice of words, but I woldn't call it a meaningless notion.
Fred Gilham
But this flies in the face of the fact that almost every non-toy
implementation of LISP has been compiled. Even Emacs Lisp is
byte-compiled. And the byte-compiler is a true compiler, emitting
machine instructions for a virtual machine; the only reason native
machine-code instructions aren't emitted is portability.
Historically speaking, LISP was being compiled at least as early as
the late 1960s. Maclisp, which had `the first good Lisp compiler',
was available in the early 1970s. The famous example of the LISP
program that ran faster than the equivalent FORTAN program was given
by Fateman in 1973.
The fact is, it's easy to write interpreters for lisp and lisp-like
languages. By contrast, writing interpreters for languages such as C
is more difficult and problematic. Ironically, the ADDED FEATURE of
being easy to interpret has been counted against LISP.
What's more, Lisp is not that much harder to compile than to
interpret---though a high quality compiler requires a lot of attention
to grungy details.
Lisp has been `a compiled language' since before most languages even
existed.
--
Fred Gilham gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
Richard Katz
Daniel C. Wang wrote:
>
> Shriram Krishnamurthi <shr...@cs.rice.edu> writes:
> {stuff deleted}
> > This is nonsense. It is essentially meaningless to call a _language_
> > interpreted. Language _implementations_ may be interpreted or
> > compiled or some hybrid combination thereof, but these are not
> > properties of languages themselves.
> {stuff deleted}
>
> Perhaps so, but it is the case that certain languages are easier to
> interpreter rather than compile. Consider for instance Tcl, or any language
> with eval and dynamic scope (Emacs Lisp). Not that these language features
> can't be "compiled" but that languages with these features are harder to
> compile. So the notion of an "interpreted language" is probably a poor
> choice of words, but I woldn't call it a meaningless notion.
Daniel,
I agree it may be difficult to compile macro-enabled languages but that
just makes it a job for the compiler to deal with. Maybe the compiler
has to work incrementally, or as a compiler part of the time, and an
interpreter part of the time.
I look at it from a practical perspective: The proof of the pudding is
in the tasting. Fast is fast. If we have a very fast executing
application, regardless of whether its language allows macros or whether
the application takes advantage of the macros, it's still fast.
I also think we need to look at the "fast relative to what?" question.
If we look relative to the computer hardware, we're dealing with
machines that are very fast. Simple desktop systems run at 300 Megahertz
with over 128M of memory and 8 millisecond disk drives. In 1980, the
fast commercial mainframe computers had maybe 1 Meg of memory and 33
millisecond disk drives. So today, we have Prolog languages that run at
12M LIPS, and at who- knows-what in 2 years.
If we look relative to the application, "slow" may be fast enough. If
the purpose of the program is to parse information coming over a T1
line, the application can operate fairly slowly without severely
impacting performance.
It's also important to gauge what the language implementation "compiles
to" or "interprets to," and these are not part of the language itself
either. Byte code might be less efficient in some circumstances, but
you have to look at the hardware itself too. Hardware design
limitations can account for lack of efficiency. The hardware approach
in which the processor is designed around one high-level language: be it
Pascal, Lisp, C, the JVM or WAMM have historically shown performance
limitations. There are at least two reasons for this.
First, general purpose computers are cost conscious. Computers that run
general purpose low-level machine languages are designed from the
perspective of increasing raw processor speed at a low cost. The
increment in speed with the next generation will fairly easily catch up
to and surpass a "one language" design.
Second, general purpose computers are designed by hardware engineers,
not language designers. Focusing on language can leave rough spots in
the hardware design. For instance, the JVM is distinguished by having
built-in dynamic garbage collection. So, if you build a processor based
on the JVM, it's going to have that as a limitation. If instead you
build a processor that enables planned garbage collection and it's going
to be more efficient at least from that perspective.
Macro capability is severely missing from the commercial world. Maybe
that's because macros are not treated seriously enough in the academic
world. Maybe the commercial world needs to be put on notice: macros are
good things for commerical development purposes. In any event, if a
macro capability gives a given language more power, better prototyping,
more genericity, clearer functionality, and more accurate ability to
translate form into function, it's certainly no detriment.
Richard Katz
rich...@earthlink.net
John Katic
Randy Smith (cr...@mindspring.com) writes:
> On Mon, 25 May 1998 15:14:46 GMT, sgu...@shocking.com (Scott
> Gunderson) wrote:
>
>>I am a high school math teacher and wish to reestablish computer
>>programming as a course offering at my school. I've been out of the
>>loop for awhile. My question is which language/compiler do you
>>recommend for upper level high school students? Unfortunately, I will
>>probably only have a '286 lab available. My first inclination is to go
>>for Turbo Pascal 6.0 (no OOP). Others have recommended C++ but I just
>>don't think it's the best learning environment as a first language.
>>Also any suggestions on texts/references would be a great help.
>>
>>Thanks.
> Why not Java?
> **********************************************
Because he said he has access to 286 machines!!!!
Minimum Java machine is 32MB Pentium and up!
--
John Katic e-mail address aq...@freenet.carleton.ca
fax number 1-613-224-0805
-----------------------------------------------------------------
Alan Daniels
sgu...@shocking.com (Scott Gunderson) wrote:
[snip...]
>I am a high school math teacher and wish to reestablish computer
>programming as a course offering at my school. I've been out of the
>loop for awhile. My question is which language/compiler do you
>recommend for upper level high school students?
First off, I agree with the others here: C++ is a bad choice for
a first language: Its feature set is so overwhelming that it ends
up with a learning curve that ruins it as a effective teaching
tool. Rather than teaching them programming principles, you'll
spend too much time teaching them the weird syntax and mechanics
of getting C++ to work. Here's what you should look for:
- A simple, easy to understand syntax.
- Preferably intepreted, so that students can experiment.
- Preferably object oriented.
The language I'd recommend is Python. Its syntax is extremely
clean, almost like reading pseudo-code, and free of all the
oddball punctuation madness of other languages such as, say, Perl
or C++. It can be run in a line-by-line interpreter, which makes
for good feedback. It has built in types which should make
algorithms easier to teach: Objects, growable arrays, hash
tables, etc. The reason I'm recommending it over Scheme is that
Python is a procedural language, rather than a functional one.
Most of the languages in use today (C, C++, Delphi, Perl, Python,
event (ick!) Visual Basic) are some combination of procedural
and object-oriented. Python is this kind of language, but
without the historical baggage. Scheme fans will probably
flame me for this, but most of the functional languages (Lisp,
Scheme, Haskell, etc) have pretty small user bases in comparison.
Also, from my own personal experience, its easier to teach a
first-time programmer how line-by-line scripts work, rather
than how to make recursive function calls.
Anyway, just my $.02. Please try out Python for a couple of
hours before you make your decision. See www.python.org.
--
=======================
Alan Daniels
dan...@mindspring.com
dan...@cc.gatech.edu
Brian Harvey
dan...@mindspring.com writes:
>sgu...@shocking.com (Scott Gunderson) wrote:
>>I am a high school math teacher and wish to reestablish computer
>>programming as a course offering at my school. I've been out of the
>>loop for awhile. My question is which language/compiler do you
>>recommend for upper level high school students?
>The language I'd recommend is Python. [...]
> The reason I'm recommending it over Scheme is that
>Python is a procedural language, rather than a functional one.
I'm coming into this discussion late; I guess it only got crossposted
into comp.lang.scheme midway through. But if you're a math teacher,
perhaps you want to consider how the programming language you choose
will help your students use programming to help them learn math.
And from that point of view, there is a lot to be said for a functional
language.
There was just a thread like this in another set of newsgroups, in which
I suggested a computer algebra system such as Maple or Mathematica as
an alternative to a mainstream programming language. These programs have
fully capable (but notationally unusual) programming languages built in,
and also have both first-class functions and first-class algebraic expressions.
But even with just first-class functions, as in Scheme, you can do a lot
of math exploration. As a trivial example, consider writing a little
program that takes a function as argument and prints a table of the values
of the function for small positive integer arguments. Students can use this
to try to find a closed-form or recursive definition for the function.
P.S. And if you're interested in computer science, it's important to note
that the best CS book ever written, _Structure and Interpretation of
Computer Programs_ by Abelson and Sussman, uses Scheme. There really is
nothing that any other programming language might have to offer that
outweighs the importance of that book! (It's probably not a good first
Scheme book for most high school students, but there are easier books to
start with -- mine and others -- that lead into SICP.)
Yaron M. Minsky
First off, just a note -- it's kind of bad form to post in HTML -- a
lot of people who read news don't have news readers that do HTML.
Mine (gnus) happens to, but it's still bad form.
As for the differences between scheme and python, I think it's
valuable not to get religious about it. The uniformity of scheme
notion is convenient, but it has some problems. Namely, it leaves one
prone to a bad case of "parenthesis blindness". But it's not a bad
syntax.
Python also has a nice syntax, but one advantage of python is that it
is incredibly easy to read. Much easier to read than your average
scheme program, I would say. Also, python has the advantage of being
enough like various other common programming languages to give you a
leg up in learning them. Also, writing programs that are sequences of
actions is more straightforward for your average rank beginner (or so
I believe.)
Anyway, I think they're both good choices. It's one of these
situations where you can hardly go wrong. I would suggest that anyone
interested just try them both out and see what seems more
straightforward.
y
--
|--------/ Yaron M. Minsky \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|
Michael Powe
>>>>> "Roberto" == Roberto Waltman <rwal...@bellatlantic.net> writes:
Roberto> sgu...@shocking.com (Scott Gunderson) wrote:
>> I am a high school math teacher and wish to reestablish
>> computer programming as a course offering at my school. I've
>> been out of the loop for awhile. My question is which
>> language/compiler do you recommend for upper level high school
>> students? Unfortunately, I will probably only have a '286 lab
>> available. My first inclination is to go for Turbo Pascal 6.0
>> (no OOP). Others have recommended C++ but I just don't think
>> it's the best learning environment as a first language. Also
>> any suggestions on texts/references would be a great help.
Roberto> C++ is definitely NOT a good choice as a first
Roberto> programming language. For teaching principles, as
Roberto> opposed to technical details, Turbo Pascal would be ok.
Roberto> You may also consider scheme or Smalltalk. There are
Roberto> good free versions of both languages with adequate
Roberto> performance on a '286 platform. Scheme together with
Roberto> Brian Harvey's "Simply Scheme" as a textbook would be an
Roberto> excellent starting point.
Well, as a novice I'll pitch in two cents: many universities and
two-year colleges teach 'fundamentals of programming' courses using
C++ (and yes, some use Scheme). I don't have any love for C++, but I
have a text that uses it to teach programming and in my opinion, it
serves that purpose just fine. I'd rather be learning Scheme but
that's as may be.
It's not necessary to do OOP in order to use C++ for this purpose.
As far as python goes, I see no way to separate python from OOP.
Language specific properties such as the necessity of importing
modules, observing namespaces &c, obscure the programming essentials.
I agree that python is easier on the eyes than some other languages,
but achieving that appearance is not easy. It might be an easy
language to learn if you already know how to program.
mp
///////////////////////////////////////////////////////////////////////
// "Thus shines a good deed in a naughty world." //
// Michael Powe lo...@teleport.com //
/////////////// pgpk -a finger://teleport.com/looie ///////////////////
Mike Meyer
In <357908E8...@mail.webspan.net>, Andy Gaynor <sil...@mail.webspan.net> wrote:
> The object oriented paradigm can be saved for a second/later course,
> though.
I'd argue that this was a mistake. More accurately, you can put off
inheritance and the like, but the variable/object relationship needs
to be handled right. Which means you need to discuss objects and
labelling them.
> There's a huge selection of straightforward topics available
> to an introductory programming course. The object oriented paradigm
> adds complexity of interrelationships between data and function which can
> easily be deferred.
Can you find a topic that teaches basic programming without OO
concepts that also does not leave a lot to be unlearned when the OO
paradigm is taught? I have as yet to see a text that even tried to
deal with this problem. Most teach conventional programming, then
backtrack. Recommendations for better aproaches appreciated.
<mike
--
Do NOT reply to the address in the From: header. Reply to mwm instead of
bouncenews at the same machine. Mail to bouncenews will be returned with
instructions on reaching me. Sending unsoliticed email I consider commercial
gives me permission to subscribe you to a mail list of my choice.
Greg Ewing
Andy Gaynor wrote:
>
> This hybrid bastardization of
> prefix, infix, and postfix is confuscated and unnecessary.
> Python folks... We're continually reinventing the wheel to make it
> rounder. It doesn't appear to me that Python is round
> enough.
He doesn't just want his wheels round, he wants them
spherical!
Personally, I find the "conventional" way of writing
expressions much easier to read than the Scheme way.
The Scheme way is too uniform, too bland - there's
not enough for the pattern matching engine in my
brain to get its teeth into.
> Regards, [Ag] sil...@mail.webspan.net
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
Rainer Joswig
Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
> Andy Gaynor wrote:
> >
> > This hybrid bastardization of
> > prefix, infix, and postfix is confuscated and unnecessary.
>
> > Python folks... We're continually reinventing the wheel to make it
> > rounder. It doesn't appear to me that Python is round
> > enough.
>
> He doesn't just want his wheels round, he wants them
> spherical!
>
> Personally, I find the "conventional" way of writing
> expressions much easier to read than the Scheme way.
> The Scheme way is too uniform, too bland - there's
> not enough for the pattern matching engine in my
> brain to get its teeth into.
How is
sin(cos(x)) different from (sin (cos x))
x:=pi; different from (set! x pi)
{ (begin
do-this(); different from (do-this)
do-that(); (do-that))
}
Andy Gaynor
In response to ymi...@cs.cornell.edu (Yaron M. Minsky)...
> First off, just a note -- it's kind of bad form to post in HTML -- a lot of
> people who read news don't have news readers that do HTML. Mine (gnus)
> happens to, but it's still bad form.
Busted. When someone pointed out that I was posting in HTML, I cancelled the
offending message, but forgot about this one.
> As for the differences between scheme and python, I think it's valuable not
> to get religious about it.
The passion of religious disputes is the incentive behind many an elegant
exposition. It's unfortunate that this same passion often closes the minds of
the combatants. At least the contestants benefit from the careful exposition
of their own arguments. Those who stand the most to gain, though, are the
majority, the open-minded bystanders.
> The uniformity of scheme notation is convenient, but it has some problems.
> Namely, it leaves one prone to a bad case of "parenthesis blindness". But
> it's not a bad syntax.
Agreed.
Every time I upgrade my Linux distribution, I fervently hope that someone has
built an option into GNU Emacs for allowing parens to increase/decrease in size
the shallower/deeper they are nested. Or for subscripting matching parens. Or
for attaching matching parens with a faint underline. Or something. Or any
combination. This is an implementation limitation difficulty, not a conceptual
monster like allowing the user to choose the fixedness based on preference.
Anyway, I think that mainstream tools will eventually address the issue of
visual association of grouping-lexemes? matching-critters? in a general way.
While everyone could benefit from this, Lisp/Scheme would *really* benefit.
> Python also has a nice syntax, but one advantage of python is that it is
> incredibly easy to read. Much easier to read than your average scheme
> program, I would say. Also, python has the advantage of being enough like
> various other common programming languages to give you a leg up in learning
> them.
See below, "Familiarity may breed contempt, ...".
> Also, writing programs that are sequences of actions is more straightforward
> for your average rank beginner (or so I believe.)
Some prior discussion...
Earlier, dan...@mindspring.com (Alan Daniels) wrote:
> The reason I'm recommending [Python] over Scheme is that Python is a
> procedural language, rather than a functional one.
In response, I wrote:
> Scheme *is* a procedural language. To its credit, Scheme lends itself nicely
> to the functional paradigm. It even does well in the object-oriented
> paradigm despite its lack of a native interface, even moreso to Scheme's
> credit.
_______________________________________________________________________________
In response to m...@contessa.phone.net (Mike Meyer)...
Earlier, I wrote:
> The object oriented paradigm can be saved for a second/later course, though.
> There's a huge selection of straightforward topics available to an
> introductory programming course. The object oriented paradigm adds
> complexity of interrelationships between data and function which can easily
> be deferred. Oh, don't get me wrong, I love the paradigm. I'd defer it's
> formal introduction, though, the same way I'd defer the explanation of, oh,
> say, complexity analysis.
> I'd argue that [completely deferring the introduction of OOP] was a mistake.
> More accurately, you can put off inheritance and the like, but the
> variable/object relationship needs to be handled right. Which means you need
> to discuss objects and labelling them.
>
> Can you find a topic that teaches basic programming without OO concepts that
> also does not leave a lot to be unlearned when the OO paradigm is taught? I
> have as yet to see a text that even tried to deal with this problem. Most
> teach conventional programming, then backtrack. Recommendations for better
> aproaches appreciated.
This is kind of what I meant regarding deferring its *formal* introduction. My
first line should have reflected this sentiment. You captured the spirit much
better than my own ambiguous text. For the starter course, just the basics of
everything presented, including OO. I'd like a side of crow fries.
_______________________________________________________________________________
In response to Greg Ewing <gr...@cosc.canterbury.ac.nz>...
I wrote:
> [Python] retains the inherent complexities of the typical hybrid expression
> format. This hybrid bastardization of prefix, infix, and postfix is
> confuscated and unnecessary.
> Personally, I find the "conventional" way of writing expressions much easier
> to read than the Scheme way. The Scheme way is too uniform, too bland -
> there's not enough for the pattern matching engine in my brain to get its
> teeth into.
Familiarity may breed contempt, but it also breeds expertise. We're all
familiar with misfit -ehh, mixfix notation (heh heh), and so we are all good at
it. That doesn't mean that we can't get good at a more limited version of the
notation, considering the benefits. By limiting ourselves to a single
keyword/operator orientation, we reduce the amount of material to learn, we
reduce the number of errors that are a direct consequence of mixfix (usually in
precedence and ambiguity), we simplify the composition and decomposition of
code, etc. Many benefits are derived directly from easy code de-/composition,
such as better and more reliable tools, better and more reliable macros, etc.
The price is a small kick in the learning curve. Oh, and a medium kick in the
paren blindness factor mentioned earlier.
In the interests of conserving our energy for more productive arguments, I've
got two somethings to say.
First, in analogy, each pro/con is a college course at our individual
universities attended by programming languages. We individually assign credit
hours to each course. For each language, we grade its performance in each
course. The languages we like most are the ones with the highest GPAs.
Second, won't it be lovely when the mainstream tools allow us to choose things
like fixedness based on our own preference?
I wrote:
> Python folks... We're continually reinventing the wheel to make it rounder.
> As a metric, the anticipated roundness should justify the effort of
> reinvention. It doesn't appear to me that Python is round enough.
> He doesn't just want his wheels round, he wants them spherical!
[Chuckle] Damn the spheres, full speed ahead! Some better unit languages:
(= 1 (+ (^ a 2) (^ b 2) (^ c 2) (^ d 2) (^ e 2) (^ f 2) (^ g 2) (^ h 2) (^ i 2)
(^ j 2) (^ k 2) (^ l 2) (^ m 2) (^ n 2) (^ o 2) (^ p 2) (^ q 2) (^ r 2)
(^ s 2) (^ t 2) (^ u 2) (^ v 2) (^ w 2) (^ x 2) (^ y 2) (^ z 2)))
1 = a ^ 2 + b ^ 2 + c ^ 2 + d ^ 2 + e ^ 2 + f ^ 2 + g ^ 2 + h ^ 2 + i ^ 2 +
j ^ 2 + k ^ 2 + l ^ 2 + m ^ 2 + n ^ 2 + o ^ 2 + p ^ 2 + q ^ 2 + r ^ 2 +
s ^ 2 + t ^ 2 + u ^ 2 + v ^ 2 + w ^ 2 + x ^ 2 + y ^ 2 + z ^ 2
a 2 ^ b 2 ^ c 2 ^ d 2 ^ e 2 ^ f 2 ^ g 2 ^ h 2 ^ i 2 ^ j 2 ^ k 2 ^ l 2 ^ m 2 ^
n 2 ^ o 2 ^ p 2 ^ q 2 ^ r 2 ^ s 2 ^ t 2 ^ u 2 ^ v 2 ^ w 2 ^ x 2 ^ y 2 ^ z 2 ^
+ + + + + + + + + + + + + + + + + + + + + + + + + 1 =
_______________________________________________________________________________
Regards, [Ag] sil...@mail.webspan.net
Brian Harvey
Andy Gaynor <sil...@mail.webspan.net> writes:
>For the starter course, just the basics of everything presented, including OO.
Sounds like a good description of SICP! :-)
(For the non-Schemers: _Structure and Interpretation of Computer Programs_ by
Abelson and Sussman.)
a...@pythonpros.com
In article <6lc7pb$st$1...@agate.berkeley.edu>,
b...@anarres.CS.Berkeley.EDU (Brian Harvey) wrote:
>
> dan...@mindspring.com writes:
> >sgu...@shocking.com (Scott Gunderson) wrote:
> >>I am a high school math teacher and wish to reestablish computer
> >>programming as a course offering at my school. I've been out of the
> >>loop for awhile. My question is which language/compiler do you
> >>recommend for upper level high school students?
> >The language I'd recommend is Python. [...]
> >Python is a procedural language, rather than a functional one.
It's not. It's a come-as-you-are language. Join the party.
> But even with just first-class functions, as in Scheme, you can do a lot
> of math exploration
Yes, but I'd argue it's not a very natural way of thinking. ymmv.
Please take a look at http://www.pythonpros.com/arw/pysimplex
for object-oriented symbolic explorations...
> P.S. And if you're interested in computer science, it's important to note
> that the best CS book ever written, _Structure and Interpretation of
> Computer Programs_ by Abelson and Sussman
sicp is nice enough, but the best cs book ever written is "Algorithms
and Complexity" by Herbert Wilf. He uses psuedocode that vaguely resembles
Python. -- Aaron Watters
===
The Jury had each formed a different view
Long before the indictment was read
And they all spoke at once so that none of them knew
One word that the other had said
-- from "The hunting of the snark" Lewis Carroll
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Amit Patel
Rainer Joswig <jos...@lavielle.com> wrote:
|
| How is
|
| sin(cos(x)) different from (sin (cos x))
|
| x:=pi; different from (set! x pi)
|
| { (begin
| do-this(); different from (do-this)
| do-that(); (do-that))
| }
It's not that column one is different from column two in length or
structure.
The main thing is that different levels of detail look different in a
more conventional language -- expressions using "()", statements using
";", blocks using "{}". In column one, rows 1, 2, 3 look different
from each other. In column two, they all use the same syntax.
I find it much easier to understand when I *separate* things, like
letters, words, sentences, paragraphs, chapters. The different levels
of the hierarchy look different. The uniform approach on the other
hand makes everything look the same -- where everything's an object
(Smalltalk), or everything's a file (Unix), or everything's an
expression (Scheme), or everything's an int (C - ha ha), or
everything's a string (tcl?), or everything's a function (lambda
calculus).
The uniform approach is more general, more powerful, more clean, more
beautiful... but the conventional approach seems to mesh with the way
the non-mathematical part of my brain works. I don't want or need an
endless hierarchy -- I want a small fixed number of levels, like
species, phyla, family, genus, etc., or alley, street, main road,
highway, or city, state, country, planet.
I don't know if everyone's brain is this way, but I've found that
although I love Scheme, _my_ brain can deal with and even prefers to
have a small number of distinct levels rather than an arbitrary
nesting of a single kind of structure. I can easily deal with 2 or 3
levels of nesting, so if I want more structure, I can deal with 2
levels of module-level nesting, 2 levels of class-level nesting, 2
levels of function-level nesting, 2 or 3 levels of statement-level
nesting, and 2 or 3 levels of expression-level nesting. But when you
tell me they're all really the same, and give me 11 levels of
expression-level nesting, I have a much harder time.
Some restrictive structure is helpful (for me). Too much (Basic,
spreadsheets, MS-DOS batch files) or too little (pure lambda calculus,
assembly language, S & K combinators) isn't where I want to do most of
my programming.
- Amit
Andy Gaynor
[I received the quoted message by Email, also sent to the Python mailing list.]
In summary, the only criticisms that I made directly about Python were that it
suffers from the typical problems of mixfix notation, and that it didn't
appear, at my first glance, to be sufficiently novel to justify the burden of
making a new language. In contrast, I'll stipulate that Lisp/Scheme suffers
from the typical problems of prefix notation, but it certainly is different.
I wrote:
> Python folks... We're continually reinventing the wheel to make it rounder.
> As a metric, the anticipated roundness should justify the effort of
> reinvention. It doesn't appear to me that Python is round enough.
[In retrospect, I meant "sufficiently rounder", but no matter.]
Fredrik Lundh <fre...@pythonware.com> writes:
> hmm. might it be that we don't know what we're missing (1) that makes it
> possible for us python folks to write lots of cool programs in hardly any
> time at all? would using some lisp flavour instead of python help me get home by
> 3am rather than by 5am, for example?
Perhaps, and perhaps.
> what can possibly come out of a cross-posted syntax debate?
Better syntax, or better justification for existing syntax. Influencing the
opinions of those still open to influence. See "The passion of religious
disputes..." in my previous message.
> python's syntax isn't going to change much, and all attempts to change lisp's
> syntax into something more mainstream seems to have failed (a quick look at
> comp.lang.dylan revealed three posts, one of which was asking for bob's
> mailing address... (4)).
There's no reason why one couldn't utterly and completely change Lisp/Scheme
syntax, as implementations typically provide complete control over almost all
facets of its syntax. In fact, I've seen at least one package that provides
the ability to define mixfix operators in Scheme; the examples suggested that
it was pretty thorough, precedences, associativity, etc. Starting with a tool
like this, putting a convincing Python-like mask on Scheme's face would almost
certainly be a straightforward task. `Python-like' would have access to
Scheme's features; non-Scheme features could be added by the `mask'.
I suppose it's obvious that I think better syntax through symplycyty. When
extension is warranted, it should be done idiomatically. Now that I think
about it, a weak analogy could be drawn between the arguments for generally
restricting oneself to simpler syntax and the arguments for generally
restricting oneself to structured flow-of-control constructs. Comment?
> and as I just said, people from both camps are doing a lot of cool stuff with
> their favourite tools.
>
> if someone knows about any research (2) that shows that one syntax is better
> than another, please post the pointers.
Syntax should not be considered in a vacuum; it has ties to other facets of the
language, its use, and programming in general. See "Familiarity may breed
contempt, ..." in my previous message for some examples.
I haven't taken the opportunity to follow your reference. In ignorance, I'll
say that syntactic preference remains more subjective than analyitical.
Previously, I wrote:
> First, in analogy, each pro/con is a college course at our individual
> universities attended by programming languages. We individually assign
> credit hours to each course. For each language, we grade its performance in
> each course. The languages we like most are the ones with the highest GPAs.
> if not, maybe it would be better to focus on the teaching aspect of this
> thread, or move it all to some more appropriate forum.
I disagree, this forum seems appropriate enough, syntax is one of the earlier
hurdles when learning to program. Those not interested can kill the thread.
> 1) for example, could anyone tell me what exactly those much-advertised
> macros would give me, and how they would help me save, say, 10% of the
> overall development time?
Suppose you could generate almost arbitrary code inline in a clean, easy,
idiomatic fashion. What would you do with this? The most obvious answer is
simplify complicated code by factoring out common features. Doing this with a
function is sometimes inappropriate, impossible, or inefficient.
Simpler code is easier to understand and maintain, and a uniform abstraction is
easier to modify.
> 2) don't forget that python is heavily inspired by a language which was
> carefully designed to be a tool for beginners, but turned out to be useful
> for experts as well (a hallmark of truly great design, imho).
A good hallmark, but I'd say it falls short of great. It stands to reason that
may of the things that make a tool useful to beginners will also make it useful
to everyone. The converse is more significant: consider the expert tool that
is equally useful for beginners. Comment?
> and a slightly modified version of python has also been used successfully
> with true non-programmers; for more info, see Matt Conway's dissertation over
> at:
>
> http://www.research.microsoft.com/research/ui/mconway/home.html
> btw, I cannot recall seeing any HCI paper that thinks that lisp syntax is a
> good basis for future easy-to-use languages... if anyone knows about one,
> please post a reference.
Heh heh, we've yet to come to terms with existing easy-to-use languages, much
less future ones.
> 3) is it a coincidence that both lisp and perl are four-letter words?
Hmmm... "Angel" and "demon" are both five-letter words, so perhaps not.
> 4) on the other hand, I can imagine that a lot of folks might find
> www.dylan.org to be more entertaining than www.python.org.
Regards, [Ag] sil...@mail.webspan.net
Rainer Joswig
am...@Xenon.Stanford.EDU (Amit Patel) writes:
> Rainer Joswig <jos...@lavielle.com> wrote:
> |
> | How is
> |
> | sin(cos(x)) different from (sin (cos x))
> |
> | x:=pi; different from (set! x pi)
> |
> | { (begin
> | do-this(); different from (do-this)
> | do-that(); (do-that))
> | }
>
>
> It's not that column one is different from column two in length or
> structure.
>
> The main thing is that different levels of detail look different in a
> more conventional language -- expressions using "()", statements using
> ";", blocks using "{}". In column one, rows 1, 2, 3 look different
> from each other. In column two, they all use the same syntax.
which is not true. They are all surrounded by parentheses, but:
1) uses function application. the syntax is (function arg)
2) uses a special form. the syntax is (set! var value) , where the ! indicates a setter
3) uses another special form. the syntax of begin is (begin forms*)
look for example into the Common Lisp spec - the language is
full of syntax. It happens that most of the expressions are surrounded
by parentheses, that's true. Experienced Lisp programmers don't look at them
too much. They are reading programs by the symbols and by
the indentation patterns. In Scheme you group expressions
in sequences by (begin ...) in other language you might
use { ... } or similar things. Since the language
is extensible for your own program structures, in Lisp
you would end up with a version of APL with thousands of
special syntaxes for all your language constructs.
You just use words for the language constructs
in the usual case. Still there are a lot of exceptions
to this rule. You would use your own read macros to create
whatever surface syntax you like.
My Lisp machine has for example an infix expression
sublanguage.
Ori Berger
Rainer Joswig wrote:
> How is
>
> sin(cos(x)) different from (sin (cos x))
This one is OK, but ...
>
> x:=pi; different from (set! x pi)
The left one is easier to read (almost standard mathematical notation);
Python would make that x = Pi with the right definitions (from math
import Pi, or something to that effect).
> { (begin
> do-this(); different from (do-this)
> do-that(); (do-that))
> }
The left one is easier to read (scoping more visible to naked eye); And
Python is easier still as it makes sure the indentation and scoping
match, which is a BIG win over C/C++ and Scheme which leave that in the
hands of the programmer (which may or may not be equipped with a helping
editor).
And you forgot to compare
3+4*(5-6) to (+ 3 (* 4 (- 5 6)))
I think that Python is much easier to learn and program than Scheme or
C. BUT (and this is a *huge* but...) I can't recommend anyone to learn
Python as a first language if he plans to practice computing for a
living.
For people who need simple tasks, or otherwise treat computing as a
hobby, Python is definitely the way to go. But most people who intend to
be professional programmers will be spoiled by Python into thinking that
everything is damn easy and probably slow.
I have some experience with people who started programming in powerful
(?) scripting languages like Visual Basic, Perl and shell variants -
some of them were really good at it, but their conception of what was
achievable (complexity and speed wise) was limited by whatever language
they knew best; Some of them did learn C later, but as most programs
somehow handle strings, preferred using whatever slow scripting language
they did.
I think people with that background are responsible for fiascos like
Windows.
OTOH, people who start with C (not C++!) know what really is achievable
with a given machine, and how to achieve it; IMHO, it is thanks to
people like this that Linux is where it is today - fast and robust.
My 2 cents.
Ori.
Andy Gaynor
Rainer Joswig wrote:
> Experienced Lisp programmers don't look at [parens]
> too much. They are reading programs by the symbols
> and by the indentation patterns.
Good point.
With prefix notation alone, the first position on the line, the most visually
distinct, contains the primary verb, the most important piece of information.
With mixfix notation, some additional information is available because the
visual patterns tend to be more distinct. I'll concede that mixfix notation
is a little bit easier to read. My argument has always been that the slight
disadvantage in readability is more than compensated by other advantages of
the syntax, both direct and indirect, addressed in other messages.
Regards, [Ag] sil...@mail.webspan.net
Andy Gaynor
Ori Berger writes:
> Rainer Joswig writes:
>> How is
>> { (begin
>> do-this(); different from (do-this)
>> do-that(); (do-that))
>> }
First, let's fix the form on the right. Since vertical whitespace is usually
more costly than horizontal, the prevalence of the hanging indent style in
Lisp/Scheme is overwhelming. It would normally be written:
(begin (do-this)
(do-that))
The same argument applies to the form on the left,
{do-this();
do-that();}
but brace-language programmers usually balk at this. The functional
justification is strong, but it loses big on programmer acceptance and
compatibility with the existing style of most non-Lisp/Scheme code. A
discussion for another time.
> The left one is easier to read (scoping more visible to naked eye);
What, do you mean visual delimiter association? If so, who gives a Pez?
Matched delimiter association is a very prevalent feature in editors. Anyone
programming in a context where matched delimiters are significant but whose
editor doesn't indicate matches is begging for trouble. (The same goes for the
automatic default indentation.) I'd trade the visual delimiter association
(handled mechanically) for more vertical whitespace (scarce resource) from a
hanging indent any day.
> And Python is easier still as it makes sure the indentation and scoping
> match, which is a BIG win over C/C++ and Scheme which leave that in the
> hands of the programmer
Are you implying that Python's default behavior has whitespace or column
dependencies beyond token separation? The traditional arguments favoring the
placement of this functionality in the programming environment over the base
language are compelling. I'd call this a misfeature unless someone convinces
me otherwise.
> (which may or may not be equipped with a helping editor).
A programmer with a dumb editor? Mario Andretti races a Ford Granada/POS?
Btw, defining {...} -> (begin ...) in Scheme doesn't take much effort. It's
certainly never done because it's such a nit and it's rather non-idiomatic.
> And you forgot to compare
>
> 3+4*(5-6) to (+ 3 (* 4 (- 5 6)))
What the heck, let's go whole hog:
(1 + 2 + 3 + 4 + 5 + 6 + 7*(8 - 9 - 10 - 11))/(12 + 13 + 14 + 15 + 16)
vs
(/ (+ 1 2 3 4 5 6 (* 7 (- 8 9 10 11))) (+ 12 13 14 15 16))
Regardless, you're missing the point. Lisp/Scheme's notational style does not
win in every department. In my previous postings, I've tried to justify claims
that it wins overall. See my previous postings on the subject.
Back to the subject of teaching... I've never felt slighted when teaching
prefix notation; it's an early syntactic hurdle easily overcome by even the
least-competent students. The notation pays off by circumventing other
hurdles. Ymmv, see my second posting in this thread, "Familiarity may breed
contempt...", and others.
> [Several unjustified assertions favoring Python...]
| sed 's/Ori Berger/Andy Gaynor/g; s/Python/Scheme/g' | /usr/games/jive
Just me lightening up. :)
Regards, [Ag] sil...@mail.webspan.net
James Logajan
Andy Gaynor (sil...@mail.webspan.net) wrote:
: Lisp/Scheme's notational style does not win in every department. In my
: previous postings, I've tried to justify claims that it wins overall.
If it "wins overall" and given the length of time it has been around,
can you justify or even rationalize why it is not more popular than, say
C or Cobol? Particularly when one can point to the Abelson and Sussman
text as an excellent vehicle for spreading the language.
Or perhaps, just perhaps, the psycho-linguistic aspects of the Lisp/Scheme
notation are not a win for humans but only a win for compiler/interpreter
writers.
Brian Harvey
I have, for many years now, been teaching both Scheme and Logo to an assortment
of people from 8 to adult. The Logo experience is very relevant to this
discussion, because Logo's syntax is more nearly conventional than Scheme's;
it provides infix arithmetic and does not require full parenthesization. Yet
Logo is semantically a dialect of Lisp.
I believe (ymmv, etc.) that Logo learners run into many of the same problems
that Scheme learners attribute to the syntax. In the Logo case, they have to
find different reasons. The real reasons, imho, are semantic: many people
do not take naturally to the whole idea of functions. They don't like
composition of functions, and they especially don't like treating functions
as objects.
To take a simple example, some Logo learners see an instruction such as
print first butfirst [[a b c] [d e f]]
and their sequential frame of mind tells them to invoke FIRST first, so they
predict that Logo will print [b c]. The same example in Scheme would be
(car (cdr '((a b c) (d e f))))
and you'd think that, if anything, the parentheses would make it clearer
what to do first, but some Scheme beginners make the same mistake.
Mind you, people who come to computer programming from a strong math
background just jump into this stuff with no trouble, and find sequential
programming strange when they see it. But for non-mathematicians, I agree
that the sequential paradigm is more natural than the functional one.
On the other hand, there is a huge payoff in learning to think functionally!
Functions are a very powerful tool, especially when you get to recursive
functions and higher-order functions.
P.S. None of this has much to do with why Lisp hasn't taken over the world.
That's because Lisp has the reputation of being a slow language suitable only
for AI research.
P.P.S. Surely if the world can't get any other benefit from the existence
of Microsoft, at least people should stop arguing that popularity has any
connection with merit!
P.P.P.S. The difficulty that people have with functions in Lisp is exactly
the same difficulty that many people have when they study calculus. There,
too, they tend to blame the difficulty on details of the notation, but the
real difficulty is that Integral and Derivative are higher order functions.
Dirk Heise
Ori Berger wrote:
> I think that Python is much easier to learn and program than Scheme or
> C. BUT (and this is a *huge* but...) I can't recommend anyone to learn
> Python as a first language if he plans to practice computing for a
> living.
>
> For people who need simple tasks, or otherwise treat computing as a
> hobby, Python is definitely the way to go. But most people who intend to
> be professional programmers will be spoiled by Python into thinking that
> everything is damn easy and probably slow.
> I have some experience with people who started programming in powerful
> (?) scripting languages like Visual Basic, Perl and shell variants -
> some of them were really good at it, but their conception of what was
> achievable (complexity and speed wise) was limited by whatever language
> they knew best; Some of them did learn C later, but as most programs
> somehow handle strings, preferred using whatever slow scripting language
> they did.
You're wrong. My first programming experience was BASIC in school.
After some weeks, we started poking machine language code to achieve speed
we needed for games. So we created machine language - BASIC hybrids.
If you expose newbies to Python, just don't forget to tell them that there
is
SWIG and an easy way to get speed for the parts of an application that must
be fast.
Dirk Heise, Braunschweig, Germany
dhe...@metronet.de
Gary E. Bloom
In article <m33edi5...@flapdragon.dyn.ml.org>, ymi...@cs.cornell.edu
(Yaron M. Minsky) wrote:
>Anyway, I think they're both good choices...
Doesn't the *range* (rather than number) of learning texts for Scheme, from
The Little Lisper/Schemer, Schemers Guide, and Simply Scheme to SICP and
Scheme and the Art of Programming, give Scheme a large advantage over other
choices.
Regards,
Rainer Joswig
"The Schematics of Computation" from Manis/Little and there are even some other new titles
(Springer has a new one using Scheme, if I remember right).
Greg Ewing
Brian Harvey wrote:
>
> print first butfirst [[a b c] [d e f]]
>
> and their sequential frame of mind tells them to invoke FIRST first
> that the sequential paradigm is more natural than the functional one.
Hmmm... maybe for them, postfix would be better?
[[a b c] [d e f]] butfirst first print
IF in Forth, anyone? :-)
Greg Ewing
Andy Gaynor wrote:
>
> Are you implying that Python's default behavior has whitespace or column
> dependencies beyond token separation? The traditional arguments favoring the
> placement of this functionality in the programming environment over the base
> language are compelling. I'd call this a misfeature unless someone convinces
> me otherwise.
Since this is a matter of personal preference, you're
the only person who can do that. You really have to
try it yourself before making a judgement.
The Python community contains many people (myself
included) who were initially leery of the way it
uses whitespace, but after using it for a while,
found that their initial fears were ungrounded.
Of course, you might find that after using it
for a while you still hate it, in which case
I would concede that it is not for you.
All I ask is, don't knock it until you've tried it!
Rob Warnock
Dirk Heise <dhe...@metronet.de> wrote:
+---------------
| My first programming experience was BASIC in school.
As Dijkstra said in his classic 1975 diatribe "How Do We Tell Truths
That Might Hurt?":
"It is practically impossible to teach good programming to students
who have had a prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration."
Of course, he also said:
"The use of COBOL cripples the mind; its teaching should, therefore,
be regarded as a criminal offense."
and went on to slam FORTRAN, PL/I, APL, and [by implication] Ada.
[Wonder what he thinks of Scheme...?]
-Rob
-----
Rob Warnock, 7L-551 rp...@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-933-4392
Mountain View, CA 94043 PP-ASEL-IA
Will Ware
Brian Harvey (b...@anarres.CS.Berkeley.EDU) wrote:
: P.P.S. Surely if the world can't get any other benefit from the existence
: of Microsoft, at least people should stop arguing that popularity has any
: connection with merit!
Actually, I think Microsoft uses Lisp internally for work on compiler
research. But it would certainly be interesting to see what would happen
if they released Visual Lisp or Visual Scheme.
--
Will Ware email: wware[at]world[dot]std[dot]com
PGP fp (new key 07/15/97) 67683AE2 173FE781 A0D99636 0EAE6117
God: "Sum id quod sum." Descartes: "Cogito ergo sum."
Popeye: "Sum id quod sum et id totum est quod sum."
Andy Gaynor
Russ McManus <mcm...@nytrdc058.eq.gs.com> writes that mixfix is generally
favored simply because it is learned first. Alternate forms remain alien and
unnatural until familiarity is achieved.
I fully agree.
_______________________________________________________________________________
jam...@netcom.com (James Logajan) writes:
> If it "wins overall" and given the length of time it has been around, can you
> justify or even rationalize why it is not more popular than, say C or Cobol?
> Particularly when one can point to the Abelson and Sussman text as an
> excellent vehicle for spreading the language.
Yes, there are a variety of reasons for this. My knowledge of history is weak,
apologies and corrections requested for any inaccuracies. I took a look at the
Lisp FAQ, which contains a synopsis of the milestones in Lisp history. Does
this question deserve an answer in the FAQ, you think? (Aside, I was mildly
surprised to see no mention of Church and lambda calculus in the FAQ's history
section. The connection is weak, but there nonetheless.) Historical documents
are referenced in the FAQ, but the URLs are no longer valid:
http://www.cs.rochester.edu/u/miller/Lisp-History.html
ftp.cs.umbc.edu:/pub/Memoization/Misc/Evolution-of-Lisp.ps.Z.
A little searching produced this link to the latter reference above:
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/history/evo_lisp.pgz
A less verbose document:
http://www.elwood.com/alu/table/Lisp-History.html
Lisp's very name is the same as a common communication/expressive/linguistic
impediment. Anybody recall what happened when attempts were made to introduce
the Chevy Nova (an automobile) to the Spanish-speaking market? It's name, in
Spanish, means "no go", or, less idiomatically, "doesn't go". The true origin
of the name, LISt Processing language, denotes a specialization that may cause
potential users to think to themselves, "Well, I'm not doing any list
processing.". These points may seem facetious, but I think a marketeer might
lend support to their credibility.
Lisp's introductory banner was "artificial intelligence" and "symbolic
manipulation". Potential users might think to themselves, "I'm not doing
artificial intelligence or symbolic manipulation.". Of course, most
programming IS symbolic manipulation. The implication of the banner is the
symbolic manipulation of data rather than program; in Lisp, program IS data.
A most unfortunate choice of name. Had they emphasized "symbolic" over "list",
things might have been different. Perhaps something like "Symple", for
SYMbolic Processing LanguagE would have flown better.
Lisp's early implementations were an order of magnitude less efficient than
other languages of the day, making it unsuitable for many applications. Much
of the technology for implementing high-level languages efficiently were
inspired and developed by the Lisp community in large part. Nonetheless, Lisp
acquired the reputation early and it stuck despite the fact that it has been
undeserved for a long, long time.
This is an unfortunate side effect of pushing technology's edge. If another
language was used for the development of this technology, IT may well have been
the scapegoat.
The Lisp machine showed some promise, but as I recall the hardware cost was
very high and their marketing goals were severely limited. Hindsight blurred
by tears, this occurred just before the PC revolution. Makes one wonder how
the computing industry would look today if the Lisp machines had...
Regardless, they didn't, and now there's more fuel for the bad rap fire:
"Doesn't Lisp need expensive special-purpose hardware? Didn't this stuff fail
to capture a lasting market?"
Lisp was the victim of unfortunate marketing as much as the limitations in
available technology. Consider the far-sighted approach taken by the Japanese
to enter various US markets. They realized they could dump to capture a market
base. I wonder what would have happened if, at that sensitive junction in
computing history, the Lisp machine folks had the foresight and resources for a
farther-sighted approach.
While my knowledge of AI and its rate of advancement is weak (corrections
welcome!), consider AI's Promised Land, to which we are still in exodus.
Preliminary goals were too optimistic. The AI concept captured public
attention, and the AI community caught an unwarranted amout of slack for not
achieving its goals on schedule. As if innovation could be dictated. Anyway,
Lisp caught some of this slack by association.
It's unfortunate that a general-purpose language like Lisp has been so closely
associated with AI. If AI catches raves, the association between Lisp and AI,
that Lisp is AI-specific, is enforced. If AI catches flack, Lisp catches flack
by association.
The research community tends to give less credence to cosmetic issues, being
more concerned with the meat of the matter. However, trivial cosmetic issues
in Lisp remain unaddressed to this day. For example, the choice of many names
in the language is abysmal. How I tire of explaining things like "lambda",
"car", "cdr", "cons", "cond", etc., when more intuitive choices would eliminate
so much confusion to new users. Consider alternatives like "function", "1st",
"rst", "pair", "try", etc. (Incidentally, "1st" and "rst" were chosen so that
constructions like "1r1st" become analogous to "cadar".)
While many folks receive a working introduction to Lisp at some point in their
undergraduate curriculum (perhaps a programming language and paradigm survey
course), it's unfortunate that the beauty of the language is obscured by
trivial cosmetic issues only prevalent to novices. "All I remember was 'limbo'
or 'lambada' or something and a bunch of parens."
b...@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
> Surely if the world can't get any other benefit from the existence of
> Microsoft, at least people should stop arguing that popularity has any
> connection with merit!
Bravo. Allow me to fuel your fire.
Intel makes buggy, poorly-designed processors whose success seems to stem only
from brute force. Compare with a fairly nice chip like the PowerPC, which
enjoys only limited success. Hell, Intel clone manufacturers like Cyrix and
AMD produce better and cheaper Intel-compatible processors than Intel. (I
haven't priced chips in over a year, I assume this still holds.)
Microsoft produces bloated, buggy, expensive, slow, incomplete operating
systems. Compare with Unix, which needs little more than a face lift to more
than compete. And good Unixes are available as shareware. (Thanks
FSF/GNU/Debian/Linux!)
Gasoline and other petroleum-derived fuels are dirty and non-renewable, mostly
controlled by a wealthy minority. Compare with a universal, renewable, clean
alternative like alcohol.
Paper and other fiber products typically incorporate wood. Hemp, the marijuana
plant, not only produces fiber that is significantly better than wood fiber,
but grows 20 times faster. Hey, the original Levis were made from hemp.
Although industrial hemp is virtually drug-free, it was outlawed by the
lobbying and smear campaign of a newspaper/timber mogul under the guise that
hemp contained dangerous drugs. His only motivation was to eliminate the
competing product to increase demand for his timber.
Oh ho, "drugs"... Our hypocritical "War on Drugs" is popular, but loses on
virtually every issue of merit. Of particular note is its horrific impact on
our civil rights, our economy, and our justice system. And it only worsens
the drug problem (examine less anal-retentive cultures).
Criminy, I could go on all night. To pre-empt inappropriate discussion, I ask
that you refrain from responding to the examples above in these newsgroups
unless you have salient commentary on the programming language topics at hand.
There are much better forums and sources than here and me. Also, please keep
in mind that these examples are not subjective, intellectual, vaporous flights
of aesthetic fancy like the programming language debates at hand. Granite
arguments and facts support each of them, even if I haven't recalled every
detail correctly.
_______________________________________________________________________________
I wrote:
> Are you implying that Python's default behavior has whitespace or column
> dependencies beyond token separation? The traditional arguments favoring the
> placement of this functionality in the programming environment over the base
> language are compelling. I'd call this a misfeature unless someone convinces
> me otherwise.
Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
> Since this is a matter of personal preference, you're the only person who can
> do that. You really have to try it yourself before making a judgement.
I was too dismissive, apologies. Let me rephrase. I sympathise with the
rationales for making indentation significant. No hate here.
pro 1: The potential for catching some errors.
pro 2: The requirement for at least some modicum of style.
pro 3: The potential for eliminating explicit grouping constructs.
But:
con 1: Complicates mechanical generation of code.
con 2: May intrude on individual programming styles.
Can you gun down the cons or supply more pros? As far as I'm concerned, con 1
is more compelling than all of the others combined. Mechanical generation of
code simply cannot be impaired; heck, it's painful enough already.
The whole thing becomes a non-issue if the white/column dependency can be
disabled or escaped, if only for the benefit of code generators/macro
expanders. An escape construct or somesuch.
Regards, [Ag] sil...@mail.webspan.net
Terry Reedy
sil...@mail.webspan.net says...
...
>The research community tends to give less credence to cosmetic issues,
>being >more concerned with the meat of the matter. However, trivial
>cosmetic issues in Lisp remain unaddressed to this day.
>For example, the choice of many names in the language is abysmal.
>How I tire of explaining things like "lambda", "car", "cdr", "cons",
>"cond", etc., when more intuitive choices would eliminate
>so much confusion to new users. Consider alternatives like function",
>"1st", "rst", "pair", "try", etc. (Incidentally, "1st" and "rst" were
>chosen so that
>constructions like "1r1st" become analogous to "cadar".)
I have learned and forgotten at least three times which of ca/dr was
head versus tail (or 1/rst as 'silver' so nicely puts it. Continued
usage of such terms strikes me as indicative of an unfriendliness to
newcomers and a desire to remain unpopular and esoteric. This is okay
by me, and was a substantial factor in my decision to not pursue Lisp
and Scheme.
Terry Reedy
gr...@cosc.canterbury.ac.nz says...
...
>The Python community contains many people (myself
>included) who were initially leery of the way it
>uses whitespace, but after using it for a while,
>found that their initial fears were ungrounded.
It also contains people like me who always tried to write nice-looking,
visibly-structured code, even with Fortran and Basic, let alone C, and
who immediately saw on reading some Python code that indentation made
fences redundant and who were therefore happy to embrace Python
and drop the fences.
Yes, there can be problems with messed-up indentation, just as there can
be problems with mismatched and misplaced fences (and variations in
format style). But a good eye, and a good editor program, can make both
nearly non-issues.
There are lots of languages with delimiters for delimiter-minded people
to choose from and compare and debate about. There is only
onegeneral-purpose significant-indentation language that I know of. So
it puzzles me that so many fence people feel a need to criticize the
wide-open look of Python.
Terry J. Reedy
Michael Sperber [Mr. Preprocessor]
>>>>> "Terry" == Terry Reedy <tjr...@udel.edu> writes:
Terry> gr...@cosc.canterbury.ac.nz says...
Terry> ...
>> The Python community contains many people (myself [ ... ]
Terry> There are lots of languages with delimiters for delimiter-minded people
Terry> to choose from and compare and debate about. There is only
Terry> onegeneral-purpose significant-indentation language that I
Terry> know of.
Haskell.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Martin Rodgers
In article <6lot28$omg$1...@news.udel.edu>, tjr...@udel.edu says...
> I have learned and forgotten at least three times which of ca/dr was
> head versus tail (or 1/rst as 'silver' so nicely puts it. Continued
> usage of such terms strikes me as indicative of an unfriendliness to
> newcomers and a desire to remain unpopular and esoteric. This is okay
> by me, and was a substantial factor in my decision to not pursue Lisp
> and Scheme.
I'd probably be happier using destructuring. but when I want that I often
use something else, like ML, Haskell, Prolog or whatever. Somehow, when I
use Scheme or CL, I still use first and rest.
I guess my attitude is that there are too many things to "fix". At some
point I find that what I'm looking for is actually already there, in
another language. Do I really need ML with s-exprs? I'd use it if it
existed, but I've got better things to do that create it myself, esp
since it would be hard to beat the compilers for existing languages.
[looks at subject again] The real problem, which we're discussing here,
is not what _we_ might use, but the language a beginner will confront.
That'll be the language used in textbooks.
--
Please note: my email address is munged; You can never browse enough
"Ahh, aren't they cute" -- Anne Diamond describing drowning dolphins
Magnus Lyckå
/.../
> I sympathise
> with the rationales for making indentation significant. No hate
> here.
> pro 1: The potential for catching some errors.
> pro 2: The requirement for at least some modicum of style.
> pro 3: The potential for eliminating explicit grouping
> constructs.
pro 4: Reduces code size.
I certainly think it's easier to understand code if it fits on a
screen so that I don't have to scroll, or if it fits a printed
page. I guess I'm a stupid person to feel a bit lost when I have
to scroll back and forth, but I do. I don't have a photgraphic
memory. Code with many if's and for's etc with few lines of code
in each block, gets significantly smaller, and thus easier to grasp
than in C or Pascal etc. For me, that's an important pro with
Python. The lack of BEGIN/END is not the only code reducing feature.
Lack of declarations, very high level constructs etc also helps.
> But:
> con 1: Complicates mechanical generation of code.
This has already been solved with some python script, right?
You generate code with some kind of symbols for indent and
dedent and then run it through the filter. Voila! Pretty Python.
AFAIK this is in the standard distribution. I don't think it's
so well documented though. But the concept is simple, you can
wrap your own solution:
Use whatever BEGIN/END symbols you like that can't be confused
with some other part of the code. {} are probably bad, but BEGIN
and END will probably do fine. Generate your code, run it through
a filter that adds tabs in the begining of each line, starting
with zero in the beginning of the file. For each BEGIN it
increments the number tabs, and for each END it decrements it.
> con 2: May intrude on individual programming styles.
As does every other syntactic rule. I want my programs to look
exactly like Python. That's my style! Can I do that in scheme?
con 3: Problems when people have broken editors where tabstop != 8
(Even the mouldy old vi can differ between tabstop and indentation.)
con 4: Problem when code snippets are presented in HTML-ized mails
in mail archives, or in other situations where leading whitespace
gets chopped.
Magnus
Rainer Joswig
spe...@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
> >>>>> "Terry" =3D=3D Terry Reedy <tjr...@udel.edu> writes:
>
> Terry> gr...@cosc.canterbury.ac.nz says...
> Terry> ...
> >> The Python community contains many people (myself [ ... ]
>
> Terry> There are lots of languages with delimiters for delimiter-minded peo=
> ple =
>
> Terry> to choose from and compare and debate about. There is only =
>
> Terry> onegeneral-purpose significant-indentation language that I
> Terry> know of.
>
> Haskell.
Axiom.
Dirk Heise
Rob Warnock wrote:
> Dirk Heise <dhe...@metronet.de> wrote:
> +---------------
> | My first programming experience was BASIC in school.
> +---------------
>
> As Dijkstra said in his classic 1975 diatribe "How Do We Tell Truths
> That Might Hurt?":
>
> "It is practically impossible to teach good programming to students
> who have had a prior exposure to BASIC: as potential programmers
> they are mentally mutilated beyond hope of regeneration."
Didn't know it was the BASIC. I thought, maybe the drugs.
Now i know better. Thank you. (Or maybe i shouldn't have tried that
8080 assembler...)
Mark Jackson
wware-...@world.std.com (Will Ware) writes:
> Actually, I think Microsoft uses Lisp internally for work on compiler
> research. But it would certainly be interesting to see what would happen
> if they released Visual Lisp or Visual Scheme.
Each would have subtle incompatibilities, essentially invisible to
users of the Microsoft package but posing formidable problems for those
with preexisting standard tools who needed to interoperate with them.
What else do you need to know?
--
Mark Jackson - http://www.alumni.caltech.edu/~mjackson
But that's the beauty of the game. At this very moment, your
absurd vicarious defeat is being perfectly counterbalanced by
some opposing fan's absurd vicarious triumph.
- Robert Mankoff
Andy Gaynor
I wrote:
> I sympathise with the rationales for making indentation significant.
> No hate here.
> pro 1: The potential for catching some errors.
> pro 2: The requirement for at least some modicum of style.
> pro 3: The potential for eliminating explicit grouping constructs.
Magnus Lycka <magnus...@tripnet.se> writes:
> pro 4: Reduces code size.
>
> I certainly think it's easier to understand code if it fits on a screen so
> that I don't have to scroll, or if it fits a printed page. I guess I'm a
> stupid person to feel a bit lost when I have to scroll back and forth, but I
> do. I don't have a photgraphic memory. Code with many if's and for's etc
> with few lines of code in each block, gets significantly smaller, and thus
> easier to grasp than in C or Pascal etc. For me, that's an important pro
> with Python. The lack of BEGIN/END is not the only code reducing feature.
Hear hear, Magnus! Here's an excerpt from Email I sent just last week:
> First, I catch a lot of shit from the non-Lisp/Scheme camp about not
> spreading out the delimiters of compound statements such as curly braces in
> C/C++. [...] To those that blow an entire line on a brace or keyword, I
> say... Whitespace is not free. It's not even cheap. The cost is loss of
> visual continuity and mental context switches. Spreading 'em out increases
> the amount of eye movement, scrolling, window swapping, page shuffling, etc.,
> and the accompanying context readjustment. It's a subtle cost, similar in
> flavor to a cache miss, but it is just as overlooked, just as discounted, and
> just as significant. In addition, they're hardly different from parentheses
> in meaning, and very rarely do I see parentheses strewn about in the way that
> braces are often used. Regarding a reduction in ability to match delimiters
> visually, well, I care not. Most editors do that for you anyway. Good
> editors tend to match 'em up much better. On the odd occasion when an error
> is made, the default indentation of good editors reflects the error.
I tested a few samples of C/C++ in various styles. Spacey code tends to be
between 1.25 to 2 times longer, depending on style and individual fragment.
Average it out to 1.625. Holy shit, is that Phi popping up in a growth
situation or just coincidence?
(See http://www.mcs.surrey.ac.uk/Personal/R.Knott/Fibonacci if you're curious.)
In this one issue... Lisp/Scheme fares ok because its syntax lends itself to
the terser style, which is conventional usage. Python fares well because its
syntax eliminates explicit compound statement delimiters in favor of a white
dependency. Bracy languages like C/C++ could fare ok but don't by
`conventional' brace placement styles. Begin/end languages like Pascal fare
poorly.
I wrote:
> But:
> con 1: Complicates mechanical generation of code.
I gave it some thought, and wish to modify this position:
con 1a: Complicates external generation of code.
con 1b: Severly limits text-based macros.
I don't see why a white dependency would foul up _structure-based_ macros.
Macros in Lisp/Scheme are sweet because they are structure-based. The source
code itself is a parse tree, and macros generate parse trees.
In Email correspondence, I recommended similarly to Fredrik Lundh
<fre...@pythonware.com>, who was kind enough to mail me an example of code
generation with indent and dedent, an instance of con 1a. The 35?-line example
produced Python code as text and required extra effort to use. The straight
Scheme macro was 5 lines long and required no extra effort to use, 2 lines if
you keep some very straightforward utility definitions lying around.
Structure-based macros are very "round", nudge nudge wink wink.
Keeping perspective...
Whitespace, indentation, and grouping constructs are an issue with novices, and
macros usually aren't. I sympathise with the desire to improve the situation,
but I question the wisdom of complicating the language with white dependencies
when other alternatives exist. The ol' "dedicated environment" canned response
is full of worms. Distinguishing a core level (eg, post-expansion post-cpp'ed
C) from a user level (eg, pre-cpp'ed C) might have merit in this context.
Admittedly, macros aren't usually an issue with novices. However, novices
don't remain novices for long, and macros are too useful to do without.
Especially structure-based macros.
I wrote:
> con 2: May intrude on individual programming styles.
Magnus continues:
> As does every other syntactic rule. I want my programs to look exactly like
> Python. That's my style! Can I do that in scheme?
No, not with macros alone. The whitespace dependency would be lost, replaced
by some necessary grouping. I wouldn't be surprised if the correspondence was
pretty close, although it would probably take quite a bit of work.
Con 2 doesn't seem to be an issue with regard to Python. I had more things in
mind than Python when I wrote that statement, such as make's hard tabs and
newlines, Fortran's comment column, cpp's requirement for escaping newlines in
macros, things that fail for lack of a trailing newline, etc.
> con 3: Problems when people have broken editors where tabstop != 8 (Even the
> moldy old vi can differ between tabstop and indentation.)
>
> con 4: Problem when code snippets are presented in HTML-ized mails in mail
> archives, or in other situations where leading whitespace gets chopped.
Oooh, ticklers... I'll refrain from commenting on the nuisance of tabs,
mailers modifying messages in any way, or SGML/HTML in general.
Regards, [Ag] sil...@mail.webspan.net
Greg Ewing
Andy Gaynor wrote:
>
> con 1: Complicates mechanical generation of code.
Making things easy for machines is a completely
different goal than making them easy for humans,
and requires different techniques.
PostScript is an example of a language optimised
for machine-generation at the expense of readability...
> con 2: May intrude on individual programming styles.
Any decision about syntax style can do that. But in
my experience, the variations in indentation style
commonly encountered all revolve around where abouts
to put the {} or begin-end. Simply take them out of
code written in anybody's style and you end up with
the Python style.
> The whole thing becomes a non-issue if the white/column dependency can be
> disabled or escaped, if only for the benefit of code generators/macro
> expanders.
There could certainly be a compiler switch for this.
Andy Gaynor
tjr...@udel.edu (Terry Reedy) writes:
> I have learned and forgotten at least three times which of ca/dr was head
> versus tail (or 1/rst as 'silver' so nicely puts it. Continued usage of such
> terms strikes me as indicative of an unfriendliness to newcomers and a desire
> to remain unpopular and esoteric. This is okay by me, and was a substantial
> factor in my decision to not pursue Lisp and Scheme.
Russ McManus <mcm...@nytrdc058.eq.gs.com> writes:
> Continued usage of these terms may be unfriendly to newcomers, but that is
> not the motivation for keeping them. The motivation is to stay true to the
> long tradition of the Lisp community. This acknowledgement of history hardly
> implies that Scheme programmers have a desire to remain "unpopular and
> esoteric".
If a historical acknowledgement has a significant impact on usefulness, it
should be retired to the documentation. In this case, the names impact the
usefulness of the language as a teaching medium and its general popularity.
They're a major turn-off.
See below for renaming of the major offenders:
lambda -> function
cond -> try
cons -> pair
c*r -> *st, where a -> f and d -> r, up to three deep
R4RS and R5RS say that a digit can't begin an identifier,
although most implementations relax this restriction.
Regards, [Ag] sil...@mail.webspan.net
_______________________________________________________________________________
;;; Public domain.
(define-syntax function
(syntax-rules () ((function . more) (lambda . more))))
(define-syntax try
(syntax-rules () ((try . more) (cond . more))))
(define pair cons)
;; An identifier can't start with a digit, sigh.
;; Most implementations relax identifier restrictions.
;; I like the 1 much more than the f.
(define fst car)
(define rst cdr)
(define ffst caar)
(define frst cadr)
(define rfst cdar)
(define rrst cddr)
(define fffst caaar)
(define ffrst caadr)
(define frfst cadar)
(define rffst cdaar)
(define frrst caddr)
(define rfrst cdadr)
(define rrfst cddar)
(define rrrst cdddr)
Rainer Joswig
Andy Gaynor <sil...@mail.webspan.net> writes:
> If a historical acknowledgement has a significant impact on usefulness, it
> should be retired to the documentation. In this case, the names impact the
> usefulness of the language as a teaching medium and its general popularity.
> They're a major turn-off.
I'm not that sure. If people are not capable of dealing
with "COND" (from conditional), they better be careful using
a computer for programming.
>
> See below for renaming of the major offenders:
> lambda -> function
I don't know if this would clarify anything.
> cond -> try
Use other constructs: IF, CASE, ...
> cons -> pair
CONS comes from "construct", I guess.
> c*r -> *st, where a -> f and d -> r, up to three deep
Use FIRST, REST, NTH, ...
Actually I think to understand the concept of a lambda function
is **much** more difficult than to learn a new word.
If you have a mathematical background this should be easy, though.
Lambda calculus is one of the foundations of computer science.
Dima Pasechnik
mjac...@wc.eso.mc.xerox.com (Mark Jackson) writes:
>
> wware-...@world.std.com (Will Ware) writes:
>
> > Actually, I think Microsoft uses Lisp internally for work on compiler
> > research. But it would certainly be interesting to see what would happen
> > if they released Visual Lisp or Visual Scheme.
>
> Each would have subtle incompatibilities, essentially invisible to
> users of the Microsoft package but posing formidable problems for those
> with preexisting standard tools who needed to interoperate with them.
>
> What else do you need to know?
>
These incompatibilites will be upgraded every year or so (along with
some bug fixing, maybe :-)), in order
to make development and support of products as hard as possible...
And (make-list) will become (make-buck) :-)
Dmitrii.
Martin Rodgers
In article <t3lnr3g...@duti515a.twi.tudelft.nl>,
di...@duti515a.twi.tudelft.nl says...
> These incompatibilites will be upgraded every year or so (along with
> some bug fixing, maybe :-)), in order
> to make development and support of products as hard as possible...
Have they done this with VB? VC++? I've not noticed anyone hurting.
> And (make-list) will become (make-buck) :-)
And if Apple/Sun/younamethem were as successful as MS, we'd be making the
same jokes about _them_. I'm not apologing for their mistakes, just
noting that whoever is at the top gets the most flak. Currently MS.
Give me Visual Lisp and I won't have to use VC++ any more. Which is
worse? Lisp sold by MS or C++ sold by MS?
Stefan Franke
On Thu, 11 Jun 1998 14:05:57 GMT, mjac...@wc.eso.mc.xerox.com (Mark Jackson)
wrote:
>What else do you need to know
..today?
# ---------------------------------------------------------------
# stefan franke email fra...@iti.informatik.tu-darmstadt.de
# please remove the phrase "antispam." from my reply address
# bitte den text "antispam." aus der antwortadresse entfernen
# ---------------------------------------------------------------
Andy Gaynor
Rainer Joswig <jos...@lavielle.com> writes:
> If people are not capable of dealing with "COND" (from conditional), they
> better be careful using a computer for programming.
"cond" is the least confusing of the mentioned names. But it's an "ugly
truncation" which could causes a bit of confusion. More importantly, "try"
reads much more naturally than "cond". "Try this, that, and the other clause
until one succeeds." I still don't know how to literally phrase "cond".
>> lambda -> function
> I don't know if this would clarify anything.
> Actually I think to understand the concept of a lambda function
> is **much** more difficult than to learn a new word.
> If you have a mathematical background this should be easy, though.
> Lambda calculus is one of the foundations of computer science.
In my first class with Lisp, as thick as our skulls were, the association
between "lambda" and "anonymous function" always found a way to chisel its way
out and escape. "lambda" is just the name of a letter to most people; "aitch"
or "dee" would serve just as well to the novice. "function" is much more
meaningful. The conceptual leap can be shortened, albeit slightly, by
reinforcing the concept with better nomenclature.
>> cond -> try Use other constructs: IF, CASE, ...
Um, "case" doesn't really figure in here. The multiway conditional expression
reduces the amount of "if" nesting enough to justify its inclusion.
>> cons -> pair
> CONS comes from "construct", I guess.
Yes. I'd say it was the second least confusing of the mentioned names. Again,
it's an "ugly truncation". But "cons"truct what? With the addition of other
aggregate types (eg, strings and vectors), one could facetiously argue that it
is ambiguous. (Not a realistic argument, of course.) I chose "pair" to be
analogous with "vector" and "string".
>> c*r -> *st, where a -> f and d -> r, up to three deep
> Use FIRST, REST, NTH, ...
Oops, that was supposed to be four deep.
This is a tough call. Even with destructuring and pattern matching, keeping
cadar around is still convenient. I'm not married to cddaddaaadar; it's just
handy sometimes. This was the best analog I could produce. Better suggestions
for caadaddadddaadadaadaddaddddar are welcome.
Point taken though, optimize for the common case,
(define first car)
(define rest cdr)
and then do the rest in terms of f and r.
The identifier restrictions are a nuisance. No leading digit, sigh.
As far as "nth" is concerned, there's "list-ref". I don't like "-ref" much, it
falls in the "ugly truncation" category. However, it didn't seem to be a
source of confusion. I was trying to be conservative, targeting meaningless
words and ugly truncations which were fairly well-acknowledged as causing
confusion. There are a number of small inconsistencies and omissions which
should be addressed as well.
I greatly prefer "-nth" and "-get" to "-ref". "-nth" especially so for
when settable forms are considered.
Regards, [Ag] sil...@mail.webspan.net
Andrew Archibald
"Dirk Heise" <dhe...@metronet.de> writes:
You know, that assembler stays in your fat cells. You keep getting
flashbacks for years. And the instruction manuals are often doped
with strychnine.
ObScheme: Does anyone know of a scheme interpereter (er, environment)
that uses OS-level threads in a nice way? That is, will it run on all
the processors of an SMP machine without requiring me to scrifice
goats? (A friend once made a hack where [func args] did parallel
delayed evaluation...)
> Dirk Heise, Braunschweig, Germany
> dhe...@metronet.de
Alan Shutko
>>>>> "M" == Martin Rodgers <m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk> writes:
M> In article <t3lnr3g...@duti515a.twi.tudelft.nl>,
M> di...@duti515a.twi.tudelft.nl says...
>> These incompatibilites will be upgraded every year or so (along
>> with some bug fixing, maybe :-)), in order to make development and
>> support of products as hard as possible...
M> Have they done this with VB? VC++? I've not noticed anyone hurting.
You haven't been talking to the right people.
--
Alan Shutko <shu...@ugsolutions.com> - (314) 344-5214
Will Ware
: wware-...@world.std.com (Will Ware) writes:
: > [ Visual Lisp/Scheme would be interesting ]
Mark Jackson (mjac...@wc.eso.mc.xerox.com) wrote:
: Each would have subtle incompatibilities, essentially invisible to
: users of the Microsoft package but posing formidable problems for those
: with preexisting standard tools who needed to interoperate with them.
There would be some short-term damage like that. But the long-term
effect would be to acquaint millions of people with Lisp/Scheme who
would otherwise have no exposure to it at all. It would also open up
opportunities for people who have trouble selling Lisp to their boss.
Christopher Browne
On Fri, 12 Jun 1998 02:02:53 -0400, Andy Gaynor <sil...@mail.webspan.net> wrote:
>See below for renaming of the major offenders:
> lambda -> function
> cons -> pair
I'll go along with the "lambda" change, although the average person
with enough contact with computer science to have hit this can probably
understand the use of the term "lambda."
Again, "cond" is merely short for "condition", which doesn't seem to me
to be overly confusing. "try" doesn't strike me as being that much
better. There may be a better word to use here; none leaps to mind...
"cons" is short for "construct pair." I'd call "cons" better than
"pair," because it is more verbalizes the *operation*, whereas "pair"
merely describes what's being built.
I quite like "first" and "rest" as alternatives to car/cdr; it is
unfortunate that that does not nicely fit into providing a shorthand for
"composite operations" like caadr/cddr/... My inclination would be to
encourage the use of first/rest rather than car/cdr, and to leave the
others alone. If you know you need to use caadar, then you should know
what you're getting yourself into...
--
"Are [Linux users] lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?" (By Matt Welsh)
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Mark Framness
In message <6lneul$ui...@fido.engr.sgi.com> - rp...@rigden.engr.sgi.com (Rob
Warnock) writes:
>
>Dirk Heise <dhe...@metronet.de> wrote:
>+---------------
>| My first programming experience was BASIC in school.
>+---------------
>
>As Dijkstra said in his classic 1975 diatribe "How Do We Tell Truths
>That Might Hurt?":
>
> "It is practically impossible to teach good programming to students
> who have had a prior exposure to BASIC: as potential programmers
> they are mentally mutilated beyond hope of regeneration."
>
>
> "The use of COBOL cripples the mind; its teaching should, therefore,
> be regarded as a criminal offense."
>
>and went on to slam FORTRAN, PL/I, APL, and [by implication] Ada.
What, if any, language was left unflamed by Djikstra?
I would not claim that people who started with BASIC are ready for serious
computer science but then again babies who just learned to walk are not ready
for the Olympic 100 yard dash either. BASIC introduces certain broad concepts
very nicely. The simple concept of variables can be tricky for starters to
work with, let alone having to type those variables (or making them constant
or pointer variables on & on).
A HS level BASIC class should concentrate on talking to the computer and
getting the students used to the idea that computers do EXACTLY what they are
told to do. Some basic helpful algorithms might also be introduced, example
have the students do a little bit of sorting and see what they come up with,
yes we know what their solution will be, but again they are no where near
being ready to deal with all the different sorting algorithms, at least they
will have a good exposure to program flow control and when they do get to more
powerful sorts, they will see that there is indeed more than one way to skin a
cat.
Unfortunately Djikstra is right that some students are going to go to their
CompSci101 class thinking they know all and are going to shut out what their
instructor says and will try to do everything the way they learned in their HS
BASIC class. This can and does happen in every course that young minds will
take (I did this in my intro to Physics course regarding polar vector form vs.
cartesian vector form).
Also my guess is that if the comment about COBOL became widely known in
today's business environment, Djikstra would find his back "up against a
wall". I know many people have said that COBOL is an awful language to work
with, but awful or not, there is a great need for people to maintain all of
that legacy code. As I told a friend that academic types forgot about COBOL a
long time ago but business did not.
Anyway as always I welcome all helpful insights and comments. Flames will
sumarrily have their backs put up against a wall.
FROM: Mark Allen Framness
HOME: far...@netnet.net
HTTP: http://netnet.net/~farmer/index.html
URL for comp.lang.c NG: http://www.eskimo.com/~scs/C-faq/top.html
URL for comp.lang.c++ NG: http://www.cerfnet.com/~mpcline/c++-faq-lite/
FAQ archive ftp site: rtfm.mit.edu/pub/usenet
Friends don't let friends post drunk!
Martin Rodgers
In article <ydun2bi...@slosf4.ug.eds.com>, shu...@ug.eds.com
says...
> You haven't been talking to the right people.
bad does software have to be before people refuse to use it? The market
makes demands, and some people supply the goods. Let's not apply a double
standard by assuming that MS can't do this. It's possible that the market
simply demands the _wrong tools_.
Ask yourself who buys the software. Is it the people who use it? I love
the Bill Hicks rant about marketing people putting a dollar sign on
everything. The one thing that really needs counting is the cost of using
crap software, but I've never heard of that happening. (Perhaps in a year
or two...) When exactly did time and motion studies die out?
Ranting about MS on UseNet is unlikely to change anything. It's fun, tho.
Martin Rodgers
In article <EuGJD...@world.std.com>, wware-...@world.std.com says...
> There would be some short-term damage like that. But the long-term
> effect would be to acquaint millions of people with Lisp/Scheme who
> would otherwise have no exposure to it at all. It would also open up
> opportunities for people who have trouble selling Lisp to their boss.
to market it in a way that would attract new users. ISTR it was placed in
an advert on the same page as Cobol or Fortran compilers, giving the
impression that Lisp is just another old language that MS can sell.
In contrast, look at how MS launched VB. Loads of excellent PR, wads of
features heavily targetted at Windows developers, and a low price.
We live in a market driven world, and it asks us, "What does Lisp offer?"
I think we should take great care to answer that question in language
that the market can understand. In other words, in terms of money.
--
Please note: my email address is munged. You can never browse enough.
Martin Rodgers
In article <6lsm5e$14p$2...@blue.hex.net>, cbbr...@news.hex.net says...
> "cons" is short for "construct pair." I'd call "cons" better than
> "pair," because it is more verbalizes the *operation*, whereas "pair"
> merely describes what's being built.
consistancy here can easily be confusing to someone learning a language.
--
Michael Powe
>>>>> "Andy" == Andy Gaynor <sil...@mail.webspan.net> writes:
Andy> Russ McManus <mcm...@nytrdc058.eq.gs.com> writes:
>> Continued usage of these terms may be unfriendly to newcomers,
>> but that is not the motivation for keeping them. The
>> motivation is to stay true to the long tradition of the Lisp
>> community. This acknowledgement of history hardly implies that
>> Scheme programmers have a desire to remain "unpopular and
>> esoteric".
Andy> If a historical acknowledgement has a significant impact on
Andy> usefulness, it should be retired to the documentation. In
Andy> this case, the names impact the usefulness of the language
Andy> as a teaching medium and its general popularity. They're a
Andy> major turn-off.
I find these arguments unconvincing. Though I do not know much in the
way of programming languages, I do know a bit about learning spoken
languages, having learned five besides my native English. This same
argument has come up in every language course I've taken: some
students always object to the way things are done in the new language
on the grounds that "it's not natural." "Why can't it be more like
--- ?"
These arguments are essentially non sequitur. Whatever the parameters
of learning a language -- programming or spoken -- the student must
align his thinking with the process of the language. Must. If he
can't do that or won't do that, he should take up another course of
study.
mp
///////////////////////////////////////////////////////////////////////
// "Thus shines a good deed in a naughty world." //
// Michael Powe lo...@teleport.com //
/////////////// pgpk -a finger://teleport.com/looie ///////////////////
James Logajan
Michael Powe (looie...@teleport.com) wrote:
: I find these arguments unconvincing. Though I do not know much in the
: way of programming languages, I do know a bit about learning spoken
: languages, having learned five besides my native English. This same
: argument has come up in every language course I've taken: some
: students always object to the way things are done in the new language
: on the grounds that "it's not natural." "Why can't it be more like
: --- ?"
: These arguments are essentially non sequitur. Whatever the parameters
: of learning a language -- programming or spoken -- the student must
: align his thinking with the process of the language. Must. If he
: can't do that or won't do that, he should take up another course of
: study.
Artificially designed languages, are, well, NOT natural. Hence any argument
relying on the assumption that computer languages are natural is probably
incorrect. (Of course, the word "natural" is too vague; I think many people
would intend it to mean in this context a construct that is only slowly
changeable (or even unchangeable), pre-existing, and evolved over several
generations.)
In the case of computer languages, any student who objects to existing
languages is free to create their own; and many have. Python, Lisp, Fortran,
Cobol, etcetera, did not evolve in some cultural backwoods or some deep
rainforest by some stone-age culture (well, maybe some did <wink>), but
were DESIGNED whole. Shucks, I know of at LEAST two artificially designed
non-computer languages: Esperanto and Loglan.
Michael Powe
>>>>> "James" == James Logajan <jam...@netcom.com> writes:
James> Artificially designed languages, are, well, NOT
James> natural. Hence any argument relying on the assumption that
James> computer languages are natural is probably incorrect. (Of
James> course, the word "natural" is too vague; I think many
James> people would intend it to mean in this context a construct
James> that is only slowly changeable (or even unchangeable),
James> pre-existing, and evolved over several generations.)
Yes, well, you can use whatever word you want. The point remains
valid. There's too much complaining about this language doesn't do
this and that language is ugly and on and on and on. It's nonsense.
People ought to differentiate more between personal preferences and
actual usefulness. It doesn't matter two hoots what name is given to
the primitive 'car' -- all that matters is that you know how to use
it. Names are entirely arbitrary, anyway.
James> In the case of computer languages, any student who objects
James> to existing languages is free to create their own; and many
James> have. Python, Lisp, Fortran, Cobol, etcetera, did not
Actually, I'm inclined to think that new languages are invented by
those so thoroughly familiar with the old ones that they can understand
fully what's "lacking" as well as what is needed in a new one. After
all, the kind understanding of system operation necessary to write a
programming language is not trivial. Python evolved out of a
scripting language van Rossum wrote for the Amoeba OS. van Rossum was
a system programmer for Amoeba -- he knew what he was doing.
Andy Gaynor
I wrote:
> If a historical acknowledgement has a significant impact on usefulness, it
> should be retired to the documentation. In this case, the names impact the
> usefulness of the language as a teaching medium and its general popularity.
> They're a major turn-off.
Michael Powe <looie...@teleport.com> writes:
> I find these arguments unconvincing. Though I do not know much in the way of
> programming languages, I do know a bit about learning spoken languages,
> having learned five besides my native English. This same argument has come
> up in every language course I've taken: some students always object to the
> way things are done in the new language on the grounds that "it's not
> natural." "Why can't it be more like --- ?"
>
> These arguments are essentially non sequitur. Whatever the parameters of
> learning a language -- programming or spoken -- the student must align his
> thinking with the process of the language. Must. If he can't do that or
> won't do that, he should take up another course of study.
This particular subthread, choice of names, doesn't concern the language
structure (per se) or functionality, it's "process". Suppose a selection of
critical words in a natural language were particularly confusing. The words
could be changed without altering the language, a purely cosmetic operation.
For example, in English, let's consider "who", "what", "where", "when", "why",
and "how", the interrogatories, all starting with an "aitch" sound. Now,
suppose "why" was "lambda".
The point is that better nomenclature (more meaningful or consistent, for
example) can assist the student in learning the process of the language. In
the interrogatory example, there's some slight benefit in the similarity of the
names, leading-aitch. In the romantic languages, there's some slight benefit
with the kay/kwa consistency.
Your discussion is not wrong per se, but seems out of context. It would
probably apply better to a less functionally trivial topic than pure cosmetics,
like the prefix/mixfix issue. Although choice of names is trivial from a
functional standpoint, the value of aesthetic appeal cannot be ignored. This
minor problem has a trivial solution. Regardless of whether you agree with my
choices, wiser minds, survey, and debate will produce better ones.
In a later message, Michael Powe <looie...@teleport.com> writes:
> ... There's too much complaining about this language doesn't do this and
> that language is ugly and on and on and on. It's nonsense. People ought to
> differentiate more between personal preferences and actual usefulness. It
> doesn't matter two hoots what name is given to the primitive 'car' -- all
> that matters is that you know how to use it. ...
The choice of names is not an issue of personal preference; it has a measurable
impact which could be easily justified by survey. Evaluate for yourself what
the effects would be of artificially worsening the problem. Let's truncate
"call-with-current-continuation" to "cont". I see a "con." regexp surfacing;
let's make a whole bunch of names match "con.".
> [... programming language invention ...]
I'm tired of learning new languages which don't offer a fair amount of novelty
or improvement. My malcontentednessage, both learned and inherent, has
inspired an uncommonly stringent criteria for new languages. Even then, how
often have _you_ come to the conclusion that the primary motivations for a new
language could have just as easily been expressed within or as extensions to
existing languages?
In addition to malcontentednessage, I also suffer the sin of hubris. I _know_
I can Build a Better Mousetrap, or at least a Different Mousetrap. However,
despite a great deal of consideration over the years, I've yet to produce a
design that met my criteria. Something's congealing, though. I'm borrowing
as much as possible from an existing language, a very `clean' one. The mice
are doomed, bruhahahahaha!
A fairly common plight. This realization is even more justification for
restraint.
Regards, [Ag] sil...@mail.webspan.net
Martin Rodgers
In article <m3g1h9j...@localhost.localdomain>,
looie...@teleport.com says...
> If he can't do that or won't do that, he should take up another course of
> study.
Perhaps the concern here is that this is indeed what is happening. If
this is so, then it might lead to another question: Why should we care
which language(s) other people use? Turn this around and you get a
question about what other people think of what _we_ use.
While you suggest that a student should take up another course of study,
this is exactly the problem that some of us face at work. We'd like to
use X, but we're told to use Y. Meanwhile, I keep reading that students
are increasingly expected to learn CS using C++. While we may argue over
the choice between X and Y, we could find that students have no choice,
and must in fact use Z.
Is the choice of language for the student to make, or the teacher?
When we get down to issues like the naming of functions, are we
questioning the choices made by the designers of a language, the intended
users of a language, or the quality of teaching for that language?
Jochen Leidner
wware-...@world.std.com (Will Ware) writes:
> There would be some short-term damage like that. But the long-term
> effect would be to acquaint millions of people with Lisp/Scheme who
> would otherwise have no exposure to it at all. It would also open up
> opportunities for people who have trouble selling Lisp to their boss.
LISP is currently used a lot in the software industry: for prototyping,
expert system shells, even for the production-quality implementation
of games for certain consoles and circuit designs to be compiled into
VHDL. And there is a lot of legacy code to be maintained, so there is
definitely a market.
If you can't sell LISP to your boss, you're either working for the wrong
company, or LISP isn't suited for your task ;-)
But perhaps it would be much more difficult for companies selling
Common LISP implementations today if there was a commonly used,
but perhaps non-`_C_ommon' dialect called Visual L++ or the like.
And certainly would this newsgroup be flooded with questions like
`I need to open a dialog box. How can I do it in VL++?'...
Microsoft's VC++ does not even today fully implement the functionality
described in the 1990 ISO C Standard (ISO 9899:1990), so for serious
commercial development it is currently not an option; I therefore doubt
very much the company would be able (alternative reading: interested) to
conform to existing definitions of and standards for LISP ([1], [2], [3],
[4]...you name it).
So we'd better not open Pandora's box...
REFERENCES
[1] ANSI X3.226-1994. Information Technology - Programming Language -
Common Lisp.
[2] ISO/IEC 13816:1997. Information technology -- Programming languages,
their environments and system software interfaces -- Programming
language ISLISP
(Cf. <http://osiris.dkuug.dk/JTC1/SC22/WG16/open/faq.htm>)
[3] IEEE 1178-1990. IEEE Standard for the Scheme Programming Language.
[4] Kelsey, R., W. Clinger and J. Rees (eds.) (1998): Revised^5 Report
on the Programming Language Scheme. [AKA R5RS]
<http://www.linguistik.uni-erlangen.de/~leidner/pub/pdf/r5rs.pdf>
--
Jochen Leidner lei...@linguistik.uni-erlangen.de
CLUE http://www.linguistik.uni-erlangen.de/~leidner/
jrm
Martin Rodgers wrote in message ...
> I keep reading that students
>are increasingly expected to learn CS using C++.
Like learning mechanical engineering with a Dremel tool.
Michael Powe
>>>>> "Martin" == Martin Rodgers <m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk> writes:
Martin> In article <m3g1h9j...@localhost.localdomain>,
Martin> looie...@teleport.com says...
>> If he can't do that or won't do that, he should take up another
>> course of study.
Martin> While you suggest that a student should take up another
Martin> course of study, this is exactly the problem that some of
Martin> us face at work. We'd like to use X, but we're told to use
Martin> Y. Meanwhile, I keep reading that students are
Martin> increasingly expected to learn CS using C++. While we may
Martin> argue over the choice between X and Y, we could find that
Martin> students have no choice, and must in fact use Z.
Well, that is true to some extent. All the local universities and
2-year colleges around here use C++ for the basis of their
'fundamentals of programming' courses. It's a bother -- I have no
personal interest in C++.
One of the most difficult things to teach is the ability to learn.
Learning is a skill, just like reading and writing. I used to do a
lot of tutoring (mathematics and ESL, mostly) at the university level;
and the ability to 'unblock' or allow new paradigms of thinking to
emerge is really essential to grasping new ideas. I spent probably
80% of my tutoring time helping students learn to let go of
preconceived ideas in order to grasp the new ones. It can be done
... but it may be utopian to think that it will ever become
prevalent.
Martin> Is the choice of language for the student to make, or the
Martin> teacher? When we get down to issues like the naming of
Martin> functions, are we questioning the choices made by the
Martin> designers of a language, the intended users of a language,
Martin> or the quality of teaching for that language?
The problem may be less in the choice of language for basic courses
(after all, some universities use Scheme) than in the prevalent
attitudes among instructors and programmers. The C++ textbook I have
makes a number of deprecating remarks about C, which is referred to as
though it "used to be" a good language that has been "replaced by"
C++. The likelihood is that students without a prior programming
background are simply going to absorb this attitude and carry it
forward -- at least to some extent.
I inhabit several programming language newsgroups and it's actually
surprising to me the insularity of many of the posters. I suppose
this is no different, really, from any other profession. People take
up one method of doing things and begin to regard other methods as
inferior. It does seem to me that the attitudes evinced by
professionals and instructors will far outweigh in significance the
structural anomalies of the languages themselves.
Andy Gaynor
Martin Rodgers wrote:
> Why should we care which language(s) other people use?
1. A desire to have others benefit from the wisdom of our informed and
experienced recommendations.
2. A need for validation of our own preferences.
3. A concern for innovation and progress.
4. A desire to ensure the continued use of a preferred language so that we can
continue using it.
> I keep reading that students are increasingly expected to learn CS using C++.
Although it has its place in industry, I'd say it makes a bad vehicle for
teaching.
> Is the choice of language for the student to make, or the teacher?
Introductory courses require a single vehicle by necessity. Ease the burden
and use a simple, high-level language.
Beyond introduction, is it appropriate to overload a course's material with
learning a new language? Students may well find themselves saying, "I'm taking
LanguageX next semester.", taking a course only for exposure to LanguageX.
A fair amount of material must be sacrificed in order to teach LanguageX.
Do you think it would be better to provide minicourses in a variety of
individual languages, from which students can pick and choose? Students will
quickly forget the material without reinforcement. To get around this,
students should be required to use the languages from their minicourses. This
may burden the faculty.
> When we get down to issues like the naming of functions, are we questioning
> the choices made by the designers of a language, the intended users of a
> language, or the quality of teaching for that language?
Do you mean the standard names in the language? The designers, without a
doubt. Perhaps I missed your point.
Regards, [Ag] sil...@mail.webspan.net
Martin Rodgers
In article <m3lnr0h...@localhost.localdomain>,
looie...@teleport.com says...
> One of the most difficult things to teach is the ability to learn.
> Learning is a skill, just like reading and writing. I used to do a
> lot of tutoring (mathematics and ESL, mostly) at the university level;
> and the ability to 'unblock' or allow new paradigms of thinking to
> emerge is really essential to grasping new ideas. I spent probably
> 80% of my tutoring time helping students learn to let go of
> preconceived ideas in order to grasp the new ones. It can be done
> ... but it may be utopian to think that it will ever become
> prevalent.
I agree the difficulty of teaching the ability to learn. Either this is a
rare skill, or I'm just unlucky enough to keep finding people who're
happy, and don't see any need to expand their knowledge or skills. Mind
you, these people are not students, but working programmers.
Perhaps learning slows down when time is short and money is "good
enough"? I wonder. I'm shocked by the, what I consider to be, low quality
of code that I see other people writing. I'm not satisfied by simply
writing code that works. I want to write code that will be easy to
maintain, and will work even when someone else uses it. This tends to
involve simple things like writing code to handle error conditions.
Strangely, some people write code that ignores errors - even when such an
error would, just by inspecting the source code, obviously crash the
program.
This is why I don't believe that there are trivial examples of code. If
you write code for, say, students to read, your code teaches them a style
of coding. If that style tends to create bugs, then eventually somebody
will have to pay for it. Unfortunately, it might not be the teacher.
Unlearning bad habits may also be hard. It sounds like your problem is
"unteaching". I've always been open to new ideas - I've tried them
myself, evaluated them, and only then judged them - but there are those
who have closed minds. Reaching them is hard work. As I've had little
success is that area (with working programmers), I can't offer much help.
> The problem may be less in the choice of language for basic courses
> (after all, some universities use Scheme) than in the prevalent
> attitudes among instructors and programmers. The C++ textbook I have
> makes a number of deprecating remarks about C, which is referred to as
> though it "used to be" a good language that has been "replaced by"
> C++. The likelihood is that students without a prior programming
> background are simply going to absorb this attitude and carry it
> forward -- at least to some extent.
I've heard it said that there are two things wrong with the human race.
Our intelligence, and our need to organise ourselves into heirarchies.
Alas, for some programmers, this means making the tools they use look
"better" by denigrating the used by others.
> I inhabit several programming language newsgroups and it's actually
> surprising to me the insularity of many of the posters. I suppose
> this is no different, really, from any other profession. People take
> up one method of doing things and begin to regard other methods as
> inferior. It does seem to me that the attitudes evinced by
> professionals and instructors will far outweigh in significance the
> structural anomalies of the languages themselves.
I have the same experience. We live in tribes, and to suggest that some
"rival" tribe has something to offer is seen as heresy. Never mind how
pointless this is, or how much we lose as a result. To attack ideas seems
to me to be support for ignorance.
Martin Rodgers
In article <3583FA14...@mail.webspan.net>, sil...@mail.webspan.net
says...
> > Why should we care which language(s) other people use?
This was a rhetorical question, BTW. ;)
> 1. A desire to have others benefit from the wisdom of our informed and
> experienced recommendations.
Alas, we may offer it, but it may also be refused. This is often by my
experience. This doesn't stop me from offering it, but it does discourage
me from offering it to specific people.
> 2. A need for validation of our own preferences.
See above. This point is fine when our preferences match those of others.
I usually ask the question "Why should we care which language(s) other
people use?" in the context of one group of programmers imposing their
notions of "good" and "bad" tools on another group. For example, C++
programmers insisting that Lisp is slow or hard to use. I've also seen
the same kinds of arguments used against other languages, and they all
have the same flaws: ignorance of the language being attacked, and not a
little ignorance of C++.
However, I don't wish to suggest that C++ programmers are the only
culprits, nor do I wish to tar all C++ programemrs with the same brush.
> 3. A concern for innovation and progress.
I always welcome this. It makes a pleasant change from greed and an
obsession with "speed" and "efficiency". See my comments to #2.
> 4. A desire to ensure the continued use of a preferred language so that we can
> continue using it.
Again, this only applies to people who use the same tools as us. I get
blank looks from most people when I tell them which tools I use. One of
the more bizarre examples was a VB programmer looking down on Perl (which
I admit I use from time to time).
> Do you think it would be better to provide minicourses in a variety of
> individual languages, from which students can pick and choose? Students will
> quickly forget the material without reinforcement. To get around this,
> students should be required to use the languages from their minicourses. This
> may burden the faculty.
There are costs for all the choices we make. I only try to not let
fashion dictate my choices and beliefs. I don't know about students.
> > When we get down to issues like the naming of functions, are we questioning
> > the choices made by the designers of a language, the intended users of a
> > language, or the quality of teaching for that language?
>
> Do you mean the standard names in the language? The designers, without a
> doubt. Perhaps I missed your point.
I'm puzzled by some of the arguments used to justify archaic choices of
names. CAR and CDR, for example. I know why they survived, but those
reasons are not immediately apparant to somebody learning a language.
This could be a good argument for using one language for teaching and
another for the "real programming". The contexts differ, as do the
demands made by the programmers. Is there a "one size fits all" language,
as some advocates suggest?
The designers make the choices, obviously. Do they also used their
creations to teach? With some designers, at least, I think this may be
so. I began to learn programming in the late 70s, and I've been learning
ever since. So, it's hard for me to judge what it would be like learning
most of the languages I know as a first language. Or even a fourth or
fifth language! Nor can I judge how easy it might be for others to learn
a language by my own experience learning it. I seem to have an aptitude
for computer languages that is, in my experience, unusual. If you're
reading this, you may be equally exceptional.
Martin Rodgers
In article <x3ogvwm1...@clue27.linguistik.uni-erlangen.de>,
lei...@linguistik.uni-erlangen.de says...
> Microsoft's VC++ does not even today fully implement the functionality
> described in the 1990 ISO C Standard (ISO 9899:1990), so for serious
> commercial development it is currently not an option; I therefore doubt
> very much the company would be able (alternative reading: interested) to
> conform to existing definitions of and standards for LISP ([1], [2], [3],
> [4]...you name it).
I'm doubting the significance of standards, but let's not assume that
everyone feels as we do.
The _market_ may decide that VC++ is "good enough". There are other
possible reasons for the success of a non-conforming compiler. I think
that the real questions you're asking are: Does VC++ hurt C++? Would
Visual Lisp hurt Lisp? I'm asking a different question. If the choice is
between Visual C++ or Visual Lisp, which would _you_ prefer to use?
Paul F. Snively
>I would not claim that people who started with BASIC are ready for serious
>computer science but then again babies who just learned to walk are not ready
>for the Olympic 100 yard dash either. BASIC introduces certain broad concepts
>very nicely. The simple concept of variables can be tricky for starters to
>work with, let alone having to type those variables (or making them constant
>or pointer variables on & on).
The problem that I have with this point of view is that it presumes that
teaching side-effecting is a good thing, or at least a good starting point.
And worrying about variables having types presumes that variables should
have types (as opposed to data themselves having types). But of course,
when I say that, I'm also implicitly pointing up the fact that introducing
variables can't be done without introducing data and treating them as
distinct, which tends to be a side-effect of introducing side-effects...
and boom, here we are: instantly in a fairly complex conceptual spaghetti.
I think it's a much better idea to start with some variant of functional
programming, be that in Standard ML or in Scheme. Teach Computer Science
concepts. *THEN* teach about side-effects, object-oriented programming as a
mechanism for encapsulating state when doing side-effects in the large, and
so on.
>A HS level BASIC class should concentrate on talking to the computer and
>getting the students used to the idea that computers do EXACTLY what they are
>told to do.
They generally don't, though, at least in the sense that once a beginning
programmer writes more than about 100 lines, the programmer's idea of what
they told the computer to do and the computer's idea of what it's been told
to do begin to diverge. And actually, it's not just beginning programmers
who tend to be plagued by this.
>Some basic helpful algorithms might also be introduced, example
>have the students do a little bit of sorting and see what they come up with,
>yes we know what their solution will be, but again they are no where near
>being ready to deal with all the different sorting algorithms, at least they
>will have a good exposure to program flow control and when they do get to more
>powerful sorts, they will see that there is indeed more than one way to skin a
>cat.
Again, I think "flow control" is a very poor concept to try to introduce to
beginners. Start with functions. Teach inductive reasoning, mapping
induction onto recursion, solving a problem by solving progressively
simpler versions of the problem until you reach a trivial base case. Then,
later, you can explain iteration and why it's just convenient shorthand for
recursion.
>Unfortunately Djikstra is right that some students are going to go to their
>CompSci101 class thinking they know all and are going to shut out what their
>instructor says and will try to do everything the way they learned in their HS
>BASIC class. This can and does happen in every course that young minds will
>take (I did this in my intro to Physics course regarding polar vector form vs.
>cartesian vector form).
But why encourage it? In particular, why make life harder for the students
by teaching them the concepts that are difficult to reason about formally
first?
>Also my guess is that if the comment about COBOL became widely known in
>today's business environment, Djikstra would find his back "up against a
>wall". I know many people have said that COBOL is an awful language to work
>with, but awful or not, there is a great need for people to maintain all of
>that legacy code. As I told a friend that academic types forgot about COBOL a
>long time ago but business did not.
Why this isn't considered a national tragedy is utterly beyond me. In an
industry as steeped in its infancy as the computer industry is, we can't
afford for "momentum" to be the deciding factor in our choices of
technology to apply. Business has a job to do. Djikstra also has a job to
do; his job is to evaluate and guide the development of the industry that
is arguably, at least to some extent, his brain-child. Business, given its
druthers, would like nothing more than for computing technology to freeze
for all time and quit its pesky (and costly!) changing. Meanwhile, the
Wright brothers would really like to move beyond the Kitty Hawk stage...
>Anyway as always I welcome all helpful insights and comments. Flames will
>sumarrily have their backs put up against a wall.
>
>FROM: Mark Allen Framness
>HOME: far...@netnet.net
>HTTP: http://netnet.net/~farmer/index.html
>
>URL for comp.lang.c NG: http://www.eskimo.com/~scs/C-faq/top.html
>URL for comp.lang.c++ NG: http://www.cerfnet.com/~mpcline/c++-faq-lite/
>FAQ archive ftp site: rtfm.mit.edu/pub/usenet
>
>Friends don't let friends post drunk!
Paul Snively
Greg Ewing
Andy Gaynor wrote:
>
> More importantly, "try"
> reads much more naturally than "cond".
But it could be confusing, since some other languages
use it for exception-handling constructs.
How about "when"?
> "lambda" is just the name of a letter to most people
If that, even. To someone not familiar with greek
letters it sounds like a small fluffy animal.
--
Mary had a little lambda,
Its syntax white as snow,
And every program Mary wrote
She wrote in Lisp, you know.
Randy Cicale
This isn't my 9th grade Programming teacher is it? (Mrs. K) You 2 have
the same views on programming! anyway.....
My course (just last year) was Computer Literacy. We learned about the
computer for about half the year and the other half we programmed in
QBasic. A kid came into the class thinking he knew more than the
teacher and always contradicting...what did it get him? thrown out!
actually he left because his grades pulled his class rank down quite a
bit. But its good to learn what the computer is about and how it
works, not just the goodies it can do. I just can't wait until next
year when I have to take the same course over again because 9th grade
programming doesn't count!
Also, what do you feel about our programming course step:
9th- QBasic
10th- QBasic/ technical software
11th- PASCAL
12th- FINALLY! C++
we can't take C until the others are finished....stupid or what?
http://www.enter.net/~randysc
ran...@enter.net
>What, if any, language was left unflamed by Djikstra?
>
>I would not claim that people who started with BASIC are ready for serious
>computer science but then again babies who just learned to walk are not ready
>for the Olympic 100 yard dash either. BASIC introduces certain broad concepts
>very nicely. The simple concept of variables can be tricky for starters to
>work with, let alone having to type those variables (or making them constant
>or pointer variables on & on).
>
>A HS level BASIC class should concentrate on talking to the computer and
>getting the students used to the idea that computers do EXACTLY what they are
>told to do. Some basic helpful algorithms might also be introduced, example
>have the students do a little bit of sorting and see what they come up with,
>yes we know what their solution will be, but again they are no where near
>being ready to deal with all the different sorting algorithms, at least they
>will have a good exposure to program flow control and when they do get to more
>powerful sorts, they will see that there is indeed more than one way to skin a
>cat.
>
>Unfortunately Djikstra is right that some students are going to go to their
>CompSci101 class thinking they know all and are going to shut out what their
>instructor says and will try to do everything the way they learned in their HS
>BASIC class. This can and does happen in every course that young minds will
>take (I did this in my intro to Physics course regarding polar vector form vs.
>cartesian vector form).
>
>Also my guess is that if the comment about COBOL became widely known in
>today's business environment, Djikstra would find his back "up against a
>wall". I know many people have said that COBOL is an awful language to work
>with, but awful or not, there is a great need for people to maintain all of
>that legacy code. As I told a friend that academic types forgot about COBOL a
>long time ago but business did not.
>URL for comp.lang.c++ NG: http://www.cerfnet.com/~mpcline/c++-faq-lite/
thanks! I can't find any C++ sites to help me learn (I'm not going to
wait until 12th grade!)
Terry Reedy
Michael Powe:
>These arguments are essentially non sequitur. Whatever the parameters
>of learning a language -- programming or spoken -- the student must
>can't do that or won't do that, he should take up another course of
>study.
Exactly. I took up Python instead. Without a word of complaint.
>Yes, well, you can use whatever word you want. The point remains
>valid. There's too much complaining about this language doesn't do
>this and that language is ugly and on and on and on. It's nonsense.
No it isn't. I think Lisp in the abstract has a kind of austere beauty.
But 'cdr' and 'cadr' strike me as concretely ugly and illogical in a way
that really grates on me. They are unique in high-level programming
language keywords that I am familiar with (and no, I do not want to be
regaled with other examples) in having no link to common American
English that is discernable to ordinary programmers. I have no interest
in using them as homage to some ancient DEC machine that some remember
fondly but which means nothing to me and many others.
My previous post, agreeing (by personal testimony) with someone else
that their continued use is a barrier to greater popularity for Lisp
was not a complaint but a response to the people who hold on to them as
am initiation ritual while complaining when many of us turn to
alternatives.
Am I being foolish? Possibly, but no more so in my eyes than Lispers
who want the language to be more popular while maintaining its obscure
and unnecessary esotericisms. To each his or her own.
Terry J. Reedy
Neil Schemenauer
On Mon, 15 Jun 1998 02:21:44 GMT, Randy Cicale <ran...@enter.net> wrote:
>Also, what do you feel about our programming course step:
> 9th- QBasic
> 10th- QBasic/ technical software
> 11th- PASCAL
> 12th- FINALLY! C++
>we can't take C until the others are finished....stupid or what?
IMHO, C++ is a horrible language to use for teaching programming.
Pascal is okay. QBasic rots your brain. For a grade 12
programming course, I would recommend Scheme, Eiffel, possibly
Python and possibly Java.
How is this thread getting so off topic?
Neil
--
#!/usr/bin/env python
import zlib,base64;print zlib.decompress(base64.decodestring("eJzT0yUF6HDVKP\
ilZuYoBCdnpOam5iWWphYp2OQlFoO5DonJxXqlyYk56YlFlXrJiXYKNUD1zhC+\njoKjkw6Qk5eY\
kqgAA6F5mRVAQR2FgMqSjPw8sHowyCgpKbDS1y8vL0c2UL8OZhVUfw1XAknuVwcA\nips+Jg=="))
Martin Rodgers
In article <6m24fi$gs6$1...@news.udel.edu>, tjr...@udel.edu says...
> I have no interest
> in using them as homage to some ancient DEC machine that some remember
> fondly but which means nothing to me and many others.
The main counter argument to this is the contraction convention. For
programmers like myself who have no interest in contractions like CADR,
this is a weak argument. It implies an understanding of the value of
contractions, unlikely for a beginner. The result may be that only those
who are patient and determined to learn the language will get far enough
to gain an appreciation.
It could at least explain the "advocacy" style of support...
> Am I being foolish? Possibly, but no more so in my eyes than Lispers
> who want the language to be more popular while maintaining its obscure
> and unnecessary esotericisms. To each his or her own.
I agree that the historical baggage and the desire for popularity seem to
be mutually exclusive. Not all that is old is good. However, it's equally
true that not everything new is better.
Followups to comp.lang.scheme.
John Katic
Neil Schemenauer (nasc...@acs.ucalgary.ca) writes:
> On Mon, 15 Jun 1998 02:21:44 GMT, Randy Cicale <ran...@enter.net> wrote:
>>Also, what do you feel about our programming course step:
>> 9th- QBasic
>> 10th- QBasic/ technical software
>> 11th- PASCAL
>> 12th- FINALLY! C++
>>we can't take C until the others are finished....stupid or what?
>
> IMHO, C++ is a horrible language to use for teaching programming.
> Pascal is okay. QBasic rots your brain. For a grade 12
> programming course, I would recommend Scheme, Eiffel, possibly
> Python and possibly Java.
>
> How is this thread getting so off topic?
>
The original poster said he was teacher that will be teaching Comp Sci at
his high school next year on old 286 (DOS) computers and was asking what
language he should use.
Java etc... is totally out of the question since it won't run.
There is little choice: QBasic or Turbo Pascal are pretty much it.
Yes C is possible, in fact there are (were ?) C interpreters that might
be better for High School. C++ might not install on the old 286 macnines
since they probably have old 40 MB MFM drives etc...
I have enjoyed reading this thread since I teach Comp Sci to Gr 11 and Gr 12
students. We do our "algorithm" stuff in Turbo Pascal then we have fun
with Windows programming in Delphi. Delphi makes Win3.11 or Win95 programming
fun and easy. The discipline comes first with TP. Delphi handles Objects
without having to use pointers explicitly.
After a year or two we unleash a fresh batch of Windows shareware programmers!
....
Only to those who want to go back to the original thread...
--
John Katic e-mail address aq...@freenet.carleton.ca
fax number 1-613-224-0805
-----------------------------------------------------------------
Dr Richard A. O'Keefe
Christopher Lambert wrote:
> Maybe I'm missing something here, but a solid understanding of memory
> allocation/deallocation as applied to data structures and proper software
> engineering should not be avoided.
There are a great many things in CS that "should not be avoided",
but very few of them can or should be put as stumbling blocks before
beginners in a FIRST course.
There are very few people who have a solid understanding of memory
allocation and deallocation. I was shocked recently to find that a
fairly experienced C programmer thought manual allocation was always
fast. How many people _are_ there who understand the interaction
between memory allocation and caching? Between memory allocation
and paging? How to use 'zones' in Euclid or 'pools' in Ada? How
many programmers can be trusted to allocate in the right area when
you're using some private and some shared segments?
I should say that I have carefully read a great many CS1 textbooks
using C, Pascal, and Ada, all of them languages which require manual
storage management. (Ada _allows_ GC, but very very few Ada systems
support it.)
Requiring beginners to do storage management by hand is a lot like
requiring beginners to implement their own floating point arithmetic.
> As for nested classes, their a nice
> feature but not critical to learning proper OOP development.
That is true, but then neither is language support for _any_ kind of
classes 'critical'. Nested classes are what lets Java 1.1 handle
callbacks relatively cleanly.
> In fact, I would
> argue that multiple inheritance and operator overloading help challenge a
> student to apply the fundamental principles of design in a simple matter --
> lest they get lost in the forest.
Have you left out some 'not's from that sentence?
We are talking about BEGINNERS here. I personally feel that the absence
of operator overloading in Java is unjustifiable and a right pain, so
I'm
not going to argue that one either way, but *experts* are still arguing
over whether multiple inheritance should be used at all, what it means,
and what it should look like. With its support for 'interfaces',
Java has the perfect tradeoff: full support for multiple SUBTYPING
without requiring any of the extreme hair of multiple inheritance.
> IMHO one class of C++ has helped my programming skills and understanding of
> software development far more than all the other languages combined (including
> C).
I would have to know something about the former and present state of
your
programming skills and understanding before I could place any weight on
that. It's very easy to make a big difference starting from very
little.
More kindly, perhaps you had a teacher for your C++ course who realised
that with a ferociously complicated and highly variable language to deal
with, s/he would have to teach you defensive strategies.
> You have to recognize that the *details* are critical in education so
> that we are producing programmers and not IDE users.
Well, yes, I do recognise that. I also recognise that people CANNOT
learn the details in any pointful way until they have acquired a set
of conceptual categories that the details can be slotted into. What
is the point of forcing multiple inheritance onto people who don't
even know what a variable is yet?
> In business, much is
> spent to avoid the *details*
If I am not misunderstanding you, this is an equivocation on details.
As an experienced programmer in more languages than you can shake a
stick at, let me say with all the emphasis at my command that having
a lot of details you have to worry about is NOT a good thing in a
programming language. Not for beginners, not for everyone.
-- but this assumes an understanding of what your
> avoiding and why.
And by the END of their education, students should indeed understand
many such things. You *CAN'T* teach all that stuff in the FIRST course,
and your very own testimony is that you WEREN'T taught all that stuff
in the first course (or the C++ course wouldn't have helped so much).
Let me try to get my point across. This is one of the reasons why I
would very much prefer to teach programming using Scheme and SICP.
The Scum Theorem.
Let M1 be a simple minor of the simple matroid M.
Then M has a flat F of rank r(M)-r(M1)
such that there is a one-to-one order-preserving map
from L(M1) into the interval [F,E(M)] of L(M1).
This theorem appears on page 119 of "Matroid Theory" by James Oxley.
I haven't actually got that far in the book yet.
I know what a matroid is.
I know what a simple matroid is.
I know what a flat of a matroid is.
I know what the rank of a matroid is.
I know what a one-to-one order-preserving map is.
I have a pretty fair idea what an interval is.
BUT
I don't know what a minor of a matroid is.
I don't know what a simple minor is.
I don't know what L(M1) is.
I _could_ memorise the theorem, but I don't yet know what it _means_
or why anyone would _care_.
In precisely the same way, a beginner who is still struggling with
- what a variable is
- what scope is
- what a formal parameter is
- what an actual parameter is
- why formal and actual parameters don't have to have the same name
- what the difference between integers and floats is
- what an array is
- why array[array.length]/(vector-ref v (vector-length v)) is bad
- what is the difference between an index, an offset, and a count
- what initialisation is
- why it is bad to access an uninitialised variable
- how to tell whether a variable is uninitialised
- what assignment is
- why a (Java method/Scheme function) can change
(an array object/a vector or list) passed to it
even though it can't change a number, character or Boolean
- what a loop is
- how to design a loop (how _can_ you teach loops without teaching
preconditions, postconditions, loop invariants, and bounds? But
somehow people almost never do.)
- what a Boolean expression is
- what the difference between &&/AND and ||/OR is
- why "1"+2 == "12" == 1+"2" but 1+2 is different (Java)
- conversion between data types
- how to think about recursion so it's easy (as it is when you
think about it correctly)
- a hundred other things
REALLY doesn't need to be forced to worry about pointers, pointer
arithmetic, manual storage allocation, dead pointers, multiple
inheritance (in three different flavours), &c &c &c. One thing they
teach in education courses is that you should teach your students to
SUCCEED, not teach them to fail. You should ensure that they have a
deserved feeling of confidence about the basics before you move on to
the advanced topics. You provide training wheels. (Anyone who teaches
C without forcing the students to use Lint, LCLint, or PC-Lint, should
be shot.) You provide fill-in-the-blank examples to help them get
started. (Dr Alan Creak of the University of Auckland wrote a COBOL
compiler years ago for teaching COBOL to accountants. It would quite
happily invent most of the COBOLl boiler-plate for you. Amazingly
effective.)
You DON'T throw students in at the deep end and hold their heads under
a sea of details because they may need to avoid them later!
> Java is the best language out there for all purpose development (IMHO), but it
> would be better to illustrate the reasons why Java has included the features
> it has in a introductory class using a language that puts the onus on the
> programmer as opposed to skipping straight by these concepts and having
> students focusing on subjects that are not in the scope of learning
> programming (i.e. trying to memorize the ever changing AWT heirarchy, etc..).
Whoever said anything about AWT?
The AWT hierarchy (it's from 'hieros', a priest, not from 'heir') has
GROWN, but the entire JDK 1.0 AWT is still there intact.
Whoever said anything about memorising?
No sane programmer sets about memorising the AWT library or any other.
That's what we have nice printed reference manuals
and fuzzy on-line documents for.
What makes memorising the complex and ever changing iostreams library
in C++ _better_ than using Java?
Where did you get the rather libellous notion that a Java course
would "have students focus on subjects that are not in the scope of
learning programming"?
What precisely _do_ you think "the scope of learning programming" is?
We already know from your posting that you think
- manual memory management
- multiple inheritance
- operator overloading
ARE and
- graphics
ISN'T. What else?
Stephen J Bevan
Jeff Dalton <je...@gairsay.aiai.ed.ac.uk> writes:
> It seems possible that there are more implementations of Scheme
> than of any other single language. I don't know of any other
> language that even comes close, and that's one kind of popularity.
Forth.
Mark-Jason Dominus
In article <3583FA14...@mail.webspan.net>,
Andy Gaynor <sil...@mail.webspan.net> wrote:
>Do you think it would be better to provide minicourses in a variety of
>individual languages, from which students can pick and choose?
The school I went to had a course like this. It was erquired for
computer science students in their second year. The course covered
four languages for each of three weeks; at the end of three weeks you
would have done a project in the language, and your instructor moved
on to teach the language to a different section of students while you
got a new instructor with a new language.
I believe they chose the languages to be as different from one another
as possible. When I took it, the laguages were C, APL, Lisp, and
Snobol 4.
I always felt that it was a good idea and had worked well.
Rotating the instructors is essential, because with four different
instructors you can get each one in front of the class in turn to make
his own inflated claims about the One True Language. That is very
educational.
John Duncan
On 13 Jun 1998 01:54:54 GMT, cbbr...@news.hex.net (Christopher
Browne) wrote:
>I quite like "first" and "rest" as alternatives to car/cdr; it is
>unfortunate that that does not nicely fit into providing a shorthand for
>"composite operations" like caadr/cddr/... My inclination would be to
frrfrfst? I don't know. It hasn't happened to me yet,
but I just imagine sometime getting screwed by mistyping the
number of 'a's and 'd's in the shorthand, or by misreading
them in other's code.
Similarly, I get screwed in C using = and ==, & and &&, and
the like. One genuinely nice thing about Scheme is that the
semantic implications of a typo aren't quite as wild.
the most expressive method for one-word shorthands would be,
in my opinion stemming from a typographical background, a
combination of 'b' or 'd' and 'p', because the ascenders and
descenders would point out the differences. In the above
cases, caaddaddar and ffrfrrffst look too similar along a
line.
As far as generating a reusable program is concerned, I would
advocate the use of syntactically odd structures only in
code that will not be reread or rewritten very often. It's
not like it makes it faster to write, really. I don't know of
any programmer who seriously outputs a constant number of lines
per minute:) What really improves programming speed is not
having to look things up in a reference too often. (Though,
that issue is not concerned with car and cdr.)
In a class I had once, the book did not use car or cdr, but
rather it used first and rest exclusively. It was a good
book for learning the language, though.
-John
John Duncan
On 18 Jun 1998 16:07:46 -0400, m...@op.net (Mark-Jason Dominus) wrote:
>I believe they chose the languages to be as different from one another
>as possible. When I took it, the laguages were C, APL, Lisp, and
>Snobol 4.
I'm also implicitly including some of the earlier parts of this
thread.
I've noticed that there are examples of languages that work well or
would work well as general purpose tools, and other languages that
were supposed to be silver bullets, but proved not to be. (This is
actually the common case.)
A language that I have found to be particularly elegant is Modula-3.
Unfortunately, it does not work well for my job, which deals with
multiuser database applications on a win32 platform. (Doesn't
everyone's?)
For these purposes, I am restricted to using two languages: C++
and Visual Basic, following the typical model for "Enterprise"
database coding. All I have discovered is that VB is terribly
ineffective as a database tool. DAO is a terrible interface
for any serious database programmer.
Unfortunately, for this market of 90%, there is not much one can
use except the obvious tools. Every smaller language, be it m3,
scheme, etc, does not have the corporate support it needs to allow
a programmer to provide "great" applications. Such symptoms include
lack of integration with the underlying system and poorly designed
tools.
Wouldn't scheme be really good for processing a result set? Then
why is visual BASIC, and why is powerbuilder strange. I can't
understand why new scripting languages keep coming out that feel
like BASIC. Everything I do in VB feels like a hack, because
it just doesn't seem like the "right stuff." I guess I don't know
the internals of the library well enough, but the stuff I need
to do can be so much better expressed in other languages. Should
we go for a general purpose language such as PL/I tried to
be, or should we teach all the programmers about 35 different
languages for expressing them all. In three years I've learned
the syntax and part of the rtl for about 13 languages, and
they are all "good" for disjoint tasks.
Perhaps it's time to consider a truly general purpose tool, that
can provide programmers with many directions for problem solving.
-John
Andrew Archibald
jdds...@pitt.edu (John Duncan) writes:
> On 18 Jun 1998 16:07:46 -0400, m...@op.net (Mark-Jason Dominus) wrote:
>
> >I believe they chose the languages to be as different from one another
> >as possible. When I took it, the laguages were C, APL, Lisp, and
> >Snobol 4.
We have such a course in fourth-year, except they study (I think)
eight or ten different languages. And they're mostly esoteric ones
like Haskell, Porlog, ML, or Scheme (just so you know what I mean by
esoteric). A few really bright CS type friends of mine weren't
particualrly impressed with it... I think they only really had time to
look at the suprficial syntax for most of them.
> A language that I have found to be particularly elegant is Modula-3.
> Unfortunately, it does not work well for my job, which deals with
> multiuser database applications on a win32 platform. (Doesn't
> everyone's?)
We use it in a few courses. The students hate it, of course --- they
wish they were using a "real-world" language. It took me eight
months of using it before I wrote a program that compiled but didn't
work. Nice language for big projects.
<snip>
> Wouldn't scheme be really good for processing a result set? Then
> why is visual BASIC, and why is powerbuilder strange. I can't
> understand why new scripting languages keep coming out that feel
> like BASIC. Everything I do in VB feels like a hack, because
> it just doesn't seem like the "right stuff." I guess I don't know
> the internals of the library well enough, but the stuff I need
> to do can be so much better expressed in other languages. Should
> we go for a general purpose language such as PL/I tried to
> be, or should we teach all the programmers about 35 different
> languages for expressing them all. In three years I've learned
> the syntax and part of the rtl for about 13 languages, and
> they are all "good" for disjoint tasks.
>
> Perhaps it's time to consider a truly general purpose tool, that
> can provide programmers with many directions for problem solving.
I disagree. I think it's not a feature of language programmers, but
of programming tasks: for each task there is a good language for it.
For example, there are a lot of UN*X shelly tasks that I can write in
five lines of perl (and a guru could write in one) but which would
take ten or fifty of scheme. OTOH, many many tasks are nicer in
scheme. I recall somebody writing a linked-list implementation in an
old version of perl. In the end they had to stick everything in the
list into a big array so that perl wouldn't garbage-collect it. In
scheme, of course, the project was written already.
So I think that we need a way to be able to use a task-specific
language. Now, every large project includes a collection of small
tasks, so what we really need is a good general way to glue multiple
languages together.
For "small" languages, the guile project tries to do this. I think
it's a reasonable approach --- take small langauges and interpret
them, take large languages and hook them up by an FFI. If only it was
that easy....
> -John
Mike Meyer
In <uqmsol1...@calum.csclub.uwaterloo.ca>, Andrew Archibald <aarc...@calum.csclub.uwaterloo.ca> wrote:
> > Perhaps it's time to consider a truly general purpose tool, that
> > can provide programmers with many directions for problem solving.
>
> I disagree. I think it's not a feature of language programmers, but
> of programming tasks: for each task there is a good language for it.
> For example, there are a lot of UN*X shelly tasks that I can write in
> five lines of perl (and a guru could write in one) but which would
> take ten or fifty of scheme. OTOH, many many tasks are nicer in
> scheme. I recall somebody writing a linked-list implementation in an
> old version of perl. In the end they had to stick everything in the
> list into a big array so that perl wouldn't garbage-collect it. In
> scheme, of course, the project was written already.
>
> So I think that we need a way to be able to use a task-specific
> language. Now, every large project includes a collection of small
> tasks, so what we really need is a good general way to glue multiple
> languages together.
Do you konw about the "little language" school of programming (I don't
think it's ever been identified as a school or named until just now).
Basically, the idea is that you write a little language that is
application-specific, which you then use to solve the problem at hand,
and reuse for other, similar problems.
I forgot where I first saw it, but it was Unix-related, with pic and
some other unix tools being the examples.
LISP/FORTH-like languages excel at this, as user-defined functions
look like language objects, and the natural way to write a program is
to provide a set of functions that work in the problem domain, meaning
you have a little LISP/FORTH-like language for solving the problem.
Except that you have to drag along most of the LISP/FORTH system to
use it.
Rexx & tcl seem to be designed for that goal - both were designed to
be "hooked into" a larger application, and extended with commands that
control that application. An environment where every application uses
the same scripting language with native IPC capabilities, is an
*incredibly* productive environment. Not wanting to give that up is
why I've not switched to Unix.
Of course, from that perspective, Python and Perl (and similar
languages) take that approach. Modules correspond to such little
languages. The CGI module gives you a little language for dealing with
CGI applications, etc.
> For "small" languages, the guile project tries to do this. I think
> it's a reasonable approach --- take small langauges and interpret
> them, take large languages and hook them up by an FFI. If only it was
> that easy....
That would make your universal tool something like Perl/Python/TCL,
right? Except that different people want different tools - some are
turned off by lack of explicity delimeters, some are turned off by
splat-dollar-variablename type selection, etc.
<mike
--
Do NOT reply to the address in the From: header. Reply to mwm instead of
bouncenews at the same machine. Mail to bouncenews will be returned with
instructions on reaching me. Sending unsoliticed email I consider commercial
gives me permission to subscribe you to a mail list of my choice.
Andrew Kuchling
Mike Meyer writes:
>Do you konw about the "little language" school of programming (I don't
>think it's ever been identified as a school or named until just now).
>Basically, the idea is that you write a little language that is
>application-specific, which you then use to solve the problem at hand,
>and reuse for other, similar problems.
It was a good idea once, but not anymore, I think, because
environments grow more complex over it. A program starts out just
reading from standard input, then you want to iterate over multiple
files, then you want to run multiple instances and need file locking,
then you want to retrieve data via HTTP, then the users start writing
programs by copying code from each other; hey, wouldn't OO help with
that? This is happening to systems like Matlab; they started out as
just languages for math, but the users started wanting more system
interfaces and language features.
Once you open the door of programmability a crack, it's only a
matter of time before lots of complexity swarms through it. In short,
don't invent yet another lame little language that will have to be
extended later. Pick one of the big three (Python/Perl/Tcl) and use
it, instead, so you don't have to expend lots of effort on language
development.
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
The best mathematicians either don't get on boards and panels or don't do any
work if they are appointed.
-- Ralph P. Boas, Jr., quoted in _More Mathematical People_
Dirk Heise
John Duncan wrote:
> [...] In three years I've learned
> the syntax and part of the rtl for about 13 languages, and
> they are all "good" for disjoint tasks.
>
> can provide programmers with many directions for problem solving.
>
>
Did you consider Python? (http://www.python.org)
Dirk Heise, Braunschweig, Germany
dhe...@metronet.de
Andrew Archibald
bounc...@contessa.phone.net (Mike Meyer) writes:
> Do you konw about the "little language" school of programming (I don't
> think it's ever been identified as a school or named until just now).
> Basically, the idea is that you write a little language that is
> application-specific, which you then use to solve the problem at hand,
> and reuse for other, similar problems.
This was more or less what I had in mind. I was whining about the
lack of good tools to let one use one or more little languages as part
of a big project.
> I forgot where I first saw it, but it was Unix-related, with pic and
> some other unix tools being the examples.
> LISP/FORTH-like languages excel at this, as user-defined functions
> look like language objects, and the natural way to write a program is
> to provide a set of functions that work in the problem domain, meaning
> you have a little LISP/FORTH-like language for solving the problem.
> Except that you have to drag along most of the LISP/FORTH system to
> use it.
Some would argue that "most of the FORTH system" isn't very much at
all. Certainly scheme junkies would argue that scheme doesn't carry
much baggage.
> Rexx & tcl seem to be designed for that goal - both were designed to
> be "hooked into" a larger application, and extended with commands that
> control that application. An environment where every application uses
> the same scripting language with native IPC capabilities, is an
> *incredibly* productive environment. Not wanting to give that up is
> why I've not switched to Unix.
Productiuve for us, who use scripting... not everybody ever does. To
some extent, though, rexx and tcl are limited in their flexibility. A
Tcl program always looks like Tcl. (some would say, like $!&*)
Actually Tcl is one of the better ones for this --- it has very
flexible syntax.
> Of course, from that perspective, Python and Perl (and similar
> languages) take that approach. Modules correspond to such little
> languages. The CGI module gives you a little language for dealing with
> CGI applications, etc.
> > For "small" languages, the guile project tries to do this. I think
> > it's a reasonable approach --- take small langauges and interpret
> > them, take large languages and hook them up by an FFI. If only it was
> > that easy....
> That would make your universal tool something like Perl/Python/TCL,
> right? Except that different people want different tools - some are
> turned off by lack of explicity delimeters, some are turned off by
> splat-dollar-variablename type selection, etc.
What I had in mind was more than simply extending the language to deal
with, say, graphics primitives (that's not so different from a
library), but even changing the syntax of the language --- for
example, for regex-intensive tasks, you want regular expressions to
have a simple syntax. For tasks that don't use regular expressions,
you want a simple lexer, so you don't have to worry about whether
m.c.g is a structure element or a regular expression... to be able to
mix different syntaxes on the fly would make it much easier to
assemble a bunch of little languages into one big application (you
mean you want to draw pictures *and* do CGI? better pick either pic or
perl, can't have both...)
Perhaps a better example, suppose you want your CGI environment to do
some complicated logic. Aha! You're a masochist, so you write the
logic in PROLOG. Now, can your PROLOG talk to the graphics language?
There are such tools --- for example, schelog, which will run PROLOG
on top of scheme. So if your picture language also ran on top of
scheme (functional postscript, say), you might be able to make them
talk to each other nicely.
I'm not saying scheme is the solution; but I happen to know of some
highly effective language-integration stuff that has been done for
scheme.
OTOH, although multiple languages can simplify parts of the problem
greatly, they can also impose a big conceptual load on the programmer
--- If you need to know eight different languages, no matter how
little, to understand a program, it could be highly confusing. So
maybe things like Tcl, rexx and scheme aren't so bad.
Vacillating yet again, the typical UN*X programmer needs to know many
different languages )for one project) as it is: sh, c preprocessor, c,
automake, autoconf, perl, texinfo, HTML, .*rc...
> <mike
Andrew (an admitted scheme junkie)
aarc...@csclub.uwaterloo.ca
Mike Meyer
In <uqmyaut...@calum.csclub.uwaterloo.ca>, Andrew Archibald <aarc...@calum.csclub.uwaterloo.ca> wrote:
> > Rexx & tcl seem to be designed for that goal - both were designed to
> > be "hooked into" a larger application, and extended with commands that
> > control that application. An environment where every application uses
> > the same scripting language with native IPC capabilities, is an
> > *incredibly* productive environment. Not wanting to give that up is
> > why I've not switched to Unix.
>
> Productiuve for us, who use scripting... not everybody ever does. To
> some extent, though, rexx and tcl are limited in their flexibility. A
> Tcl program always looks like Tcl. (some would say, like $!&*)
> Actually Tcl is one of the better ones for this --- it has very
> flexible syntax.
Ok, now I hvae to ask: what do those who don't use scripting use
instead that's nearly as productive as scripting?
It blew me away that someone on a Windows NT workstation couldn't do
the equivalent of "awk ' { print $1 } ' < file | sort | uniq". Maybe
it's just them, but that kind of thing should be relatively easy on
*any* platform;if it ain't, it's time to get a new platform.
> > Of course, from that perspective, Python and Perl (and similar
> > languages) take that approach. Modules correspond to such little
> > languages. The CGI module gives you a little language for dealing with
> > CGI applications, etc.
>
> > > For "small" languages, the guile project tries to do this. I think
> > > it's a reasonable approach --- take small langauges and interpret
> > > them, take large languages and hook them up by an FFI. If only it was
> > > that easy....
>
> > That would make your universal tool something like Perl/Python/TCL,
> > right? Except that different people want different tools - some are
> > turned off by lack of explicity delimeters, some are turned off by
> > splat-dollar-variablename type selection, etc.
>
[Nice examples deleted]
> I'm not saying scheme is the solution; but I happen to know of some
> highly effective language-integration stuff that has been done for
> scheme.
Yup, scheme is a good solution to that - because everything looks like
an S-expression, right. But one of the things that lots of people hate
is Lots if Insipid, Stupid Parenthesis.
And I'm an ex Scheme junkie - wrote my newsreader in it. My Mail agent
is Rexx scripts driving a proprietary hypertext engine and the mail
commands. And these days, I make a living doing CGI in Python.
As I've said before, Python has 90% of the really cool features I
liked about Scheme. It's also got a smaller footprint than the Scheme
I used to use, and somebody else maintains it for this platform.
> Vacillating yet again, the typical UN*X programmer needs to know many
> different languages )for one project) as it is: sh, c preprocessor, c,
> automake, autoconf, perl, texinfo, HTML, .*rc...
You forgot the *really* little languages - the option flags for all
these commands! While keeping track of all that is a semantic load,
I'm not sure what would replace it with less load without sacrificing
productivity. Hence the question above.