Teaching Programming
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 ...
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/ /--------|
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
Max Hailperin
Date: 10 Jun 1998 19:33:21 GMT
From: b...@anarres.CS.Berkeley.EDU (Brian Harvey)
... 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 beginers expect functions to be
applied left to right instead of inside to outside]...
I agree 100% with this observation, speaking as another instructor and
(forthcoming) introductory textbook author. But it raises an
interesting question, one that I was hoping you or other members of
the group might have some insight into. How about beginners whose
natural language is a semitic language, Hebrew or Arabic? Do they
naturally expect right to left and so get the inside-to-outside
ordering right? This question occurred to me quite recently, as I was
writing the instructors' manual paragraph pointing out this common
learning problem. (Incidentally, my suggested solution is to be very
explicit about it being outside to inside rather than right to left,
and in particular to *write* code this way, by successive wrapping,
rather than by starting with the first character and working
sequentially until you hit the last.)
-Max Hailperin
Associate Professor of Computer Science
Gustavus Adolphus College
800 W. College Ave.
St. Peter, MN 56082
USA
http://www.gustavus.edu/~max/
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
Roberto Waltman
m...@gac.EDU (Max Hailperin) wrote:
> Date: 10 Jun 1998 19:33:21 GMT
> From: b...@anarres.CS.Berkeley.EDU (Brian Harvey)
> To take a simple example, ...[some beginers expect functions to be
> applied left to right instead of inside to outside]...
>But it raises an interesting question, one that I was hoping you or other
>members of
>the group might have some insight into. How about beginners whose
>natural language is a semitic language, Hebrew or Arabic? Do they
>naturally expect right to left and so get the inside-to-outside
>ordering right?
Anybody growing up in Israel is constantly exposed to English and
other western languages in road signs, printed matter, TV and
movies sub-titles, etc.
Mathematics is still taught in it's conventional left to right
mode, even in Hebrew textbooks.
Therefore, anybody beginning to learn computer programming , is
likely to already have years of exposure to a system that is
written 'the wrong way'.
Additionally, they would most likely use a 'regular' well known
language (C with or without the ++, Pascal, Java, etc.) and
conventional development tools and environments as the rest of
the world. By conventional I mean the same languages,
text-editors, IDEs, even if they are advanced technologically.
('Normal' word processing, commercial and private correspondence,
business databases and forms, etc. are mostly in Hebrew, of
course, but not the development tools)
Your question is still interesting, I'm only pointing to the fact
that it would be difficult to find somebody whose first
encounter with a system that must be analyzed in the opposite
direction, (relative to his language,) was in the context of
mathematics or computer programming.
RW.
PS: Unrelated but interesting problems arise when you consider
data entry and hyphenation and justification rules for mixed
text, written in both English and Hebrew.
While living in Israel I remember having to spell my name or
enter my telephone number backwards for the benefit of some
computer programs that handled only right-to-left text.
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
Andy Gaynor
m...@gac.EDU (Max Hailperin) writes:
> (Incidentally, my suggested solution is to be very explicit about it
> being outside to inside rather than right to left, and in particular
> to *write* code this way, by successive wrapping, rather than by
> starting with the first character and working sequentially until you
> hit the last.)
Sounds like the effect achieved by postfix.
Ok, you say we construct (write code) better from inside-to-outside.
Do we deconstruct (read/comprehend code) better from outside-to-inside?
Charter Member of the Peanut Gallery, [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.
--
Dirk Heise
Hi schemers!
Man! You can write in a language that requires such a twisted way of
thinking,
i never got it! But *I* can use a MAILER! Look: when you send a message
to "comp.lang.scheme,comp.lang.python" it ends up in BOTH newsgroups!
Got it? You see, i use python, and i really don't want to have to care
about
what "cddddddr" is! Could you PLEASE stop that? Thank you.
Rainer Joswig <jos...@lavielle.com> schrieb im Beitrag
<hg1rm3...@lise.lavielle.com>...
> Andy Gaynor <sil...@mail.webspan.net> writes:
>
> > If a historical acknowledgement has a significant impact on usefulness,
it
> > usefulness of the language as a teaching medium and its general
popularity.
> > They're a major turn-off.
> > should be retired to the documentation. In this case, the names impact
the
>
> I'm not that sure. If people are not capable of dealing
> I don't know if this would clarify anything.
>
> > cond -> try
> with "COND" (from conditional), they better be careful using
> a computer for programming.
>
> >
> 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.
> > See below for renaming of the major offenders:
> > lambda -> function
>
>
> 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, ...
>
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.
Rainer Joswig
Dirk Heise wrote:
Oh, another one from the thought police.
> Hi schemers!
> Man! You can write in a language that requires such a twisted way of
> thinking,
The Lisp family of language is semantically very similar to Python(according to
the language comparison by Guido van Rossum and
postings from him to comp.lang.python).
I think you just disqualified yourself.
> i never got it! But *I* can use a MAILER! Look: when you send a message
> to "comp.lang.scheme,comp.lang.python" it ends up in BOTH newsgroups!
> Got it? You see, i use python, and i really don't want to have to care
> about
> what "cddddddr" is! Could you PLEASE stop that? Thank you.
You have been cross posting yourself to comp.lang.scheme. Actually
thosepostings were not very on topic, too.
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?
Roberto Lupi
On Mon, 08 Jun 1998 06:30:41 -0400, Andy Gaynor
<sil...@mail.webspan.net> wrote:
>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.
Just an idea: matching parens coded with different colors (each pair
with their own color).
Probably an experienced elisp programmer could easily modify the
parens-highlight or the font-lock mode to implement that behaviour.
--
Roberto Lupi
Electronic Engineering Student - University of Ancona - Italy
Linux/NT System Administrator
Linux/Win32 Developer
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?
Dirk Heise
Please stop cross-posting to comp.lang.python!
Thank you.
Will Ware wrote:
> : 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.
> : What else do you need to know?
>
> 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.
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=="))
Ralf Muschall
Roberto Lupi wrote:
> >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
> Just an idea: matching parens coded with different colors (each pair
> with their own color).
After having seen how VIM5.1 highlight various stuff (IMHO far too
much and it highlights all parens in Lisp, which are IMHO rather
redundant for humans), I came up with another idea (still unrealized):
Change the highlight settings in such a way that parens become
almost (or even completely [1]) invisible, and experiment whether code
readbility improves or suffers.
(Of course i think about emacs which automatically cares about
indenting - free form code would become completely unreadable.)
[1] third variant: hide only those parens which match one of the regexps
^\s+(+
or
)+^\s+$
(i.e. not those inside a line in order to allow things like
(set! foo ((y f) 7))
to look different from
(set! foo (y (f 7)))
)
Ralf
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.
Terry Reedy
If I were trying to make Lisp/Scheme easier and more inviting for newcomers
to use and were unconcerned with homage to the past, I would replace car/cdr
with fst/rst (FirST/ReST of liST). This would continue to allow contractions
like frfst (first of rest of first of list) with a height difference (in
lower case) between the two distinguishing letters. I am presuming that
such would be easy enough for the parser to recognize.
Barry Margolin
In article <6m3iib$4v4$1...@news.udel.edu>, Terry Reedy <tjr...@udel.edu> wrote:
>If I were trying to make Lisp/Scheme easier and more inviting for newcomers
>to use and were unconcerned with homage to the past, I would replace car/cdr
>with fst/rst (FirST/ReST of liST). This would continue to allow contractions
So would you stop teaching about pairs except as used to construct lists,
and never show the (a . b) syntax?
>like frfst (first of rest of first of list) with a height difference (in
>lower case) between the two distinguishing letters. I am presuming that
>such would be easy enough for the parser to recognize.
What parser are you referring to? In most implementations, I believe the
contractions are implemented pretty much by hand:
(define (caar x)
(car (car x)))
(define (cadr x)
(car (cdr x)))
...
Perhaps an editor macro or something like that might have been used to
enter all the combinations in the first place. But there's no special
recognition of these function names by the parser; there's nothing that
says "any function name matching the regular expression c[ad]+r should be
processed by this code."
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Pierre Mai
>>>>> "TR" == Terry Reedy <tjr...@udel.edu> writes:
Having stood on the side-lines of this discussion for some time now, I
feel I must intervene, because this car/cdr vs. fst/rst confusion is
really going to far now, IMHO (and no, I don't want to be drawn into
the mainstream of the discussion, since I think that discussions on
this level about the advantages and disadvantages of languages are
really just meaningless rumblings):
TR> If I were trying to make Lisp/Scheme easier and more inviting
TR> for newcomers to use and were unconcerned with homage to the
TR> past, I would replace car/cdr with fst/rst (FirST/ReST of
TR> liST). This would continue to allow contractions like frfst
No, this _would not_ make Scheme any easier to use for anyone, because
you are now confusing car and cdr --- which are accessors to a 2-part
"`structure"' --- with first and rest, which BTW exist in Common Lisp
and are operations on _lists_, which just happen to be implemented via
cons'es (or pairs, or whatever you call them).
That car == first and cdr == rest is also just a "`coincidence"', and
this should be strictly seperated, because otherwise people get lost
fairly quickly, when trying to understand more involved operations on
lists, confusing the two slots of conses with list-elements and vice
versa.
Also calling car/cdr first/rest is wholly unnatural if you implement
binary trees or other non-list structures with conses. Compare this:
(let ((binary-tree (cons (cons a b) (cons c d))))
(first (rest binary-tree)))
for accessing the leaf node 'c, with
(let ((binary-tree (cons (cons a b) (cons c d))))
(left (right binary-tree)))
where (define (left inner-node) (car inner-node))
and (define (right inner-node) (cdr inner-node))
So we come back to the point, that car/cdr are accessors to fields of
a cons (maybe cons-left/cons-right _might_ be better names than
car/cdr), whereas first/rest are operations on lists. And here CL is
IMHO more user-friendly in providing these operations, and encouraging
there use. OTOH Scheme embraces the "small is beautiful" aspect,
and refuses to provide these operations, because they can be built-up
easily from car/cdr, and because providing them might also call for
providing similiar operations on trees, graphs, etc. which can all be
built from conses.
Coming back to the readability part, I don't consider fst or rst to be
more readable than car or cdr in any significant way. If you would be
interested in making Scheme/Lisp more "beginner-friendly", you should
IMHO provide first/rest for lists, discourage/ban c[ad]+r
concatenations, and maybe find better names for car/cdr.
OTOH many people the world over are learning programming with all those
English-based languages (be it COBOL, BASIC, Ada, C, Lisp, Python),
without knowing much, if any, English. So for them all those damn
identifiers are opaque, meaningless collections of characters anyway,
yet still they manage fairly easily to learn them, and work effectively
with them. This makes me wonder, whether this whole car/cdr-business
is not getting blown out of proportion just very slightly.
Also many languages use "graphic" characters for operators, like
e.g. ! for logical not vs. ^ for bit-not in some languages, which
IMHO are much more difficult to learn/remember, because they are not
(very) similar to the mathematical/EE operations.
Regs, Pierre.
PS: Sometimes, I have wondered, too, whether Common Lisp in
particular, couldn't/shouldn't be made more transparent via some name
changes (things like ldb&co., nconc vs. concatenate, etc. come to
mind), but car/cdr is such an easy thing to learn, because you'll use
it all the time at first, that it _never_ ever crossed my mind, that
this would be a main problem.
--
Pierre Mai <de...@cs.tu-berlin.de> http://home.pages.de/~trillian/
"Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
Martin Rodgers
In article <m3btrub...@torus.cs.tu-berlin.de>, de...@cs.tu-berlin.de
says...
> Also calling car/cdr first/rest is wholly unnatural if you implement
> binary trees or other non-list structures with conses. Compare this:
Using destructuring (not CL, BTW), we could write the following:
(destructuring-bind ((_ (left _)) (cons (cons a b) (cons c d)))
left)
I'm thinking of something like backquote, but in reverse. Unfortunately,
this exposes the implementation of data structures. If it could use the
constructor function names, it might be generalised. In the above
example, we're making the use of pairs explicit by using CONS.
Here's a cleaner form of destructuring:
(destructuring-bind ((make-tree _ (make-tree left _))
(make-tree (make-tree a b) (make-tree c d)))
left)
This assumes that the 'tree' data type has been defined, complete with
constructor and destructor functions. The define-type function and
destructuring-bind form would have to work together. I would define
destructuring-bind as a macro, rather than change Scheme!
What's missing here is any way of specifying what happens when the
destructuring fails to match the data. Another value is needed:
(destructuring-bind ((make-tree _ (make-tree left _))
(make-tree (make-tree a b) (make-tree c d))
nil)
left)
No doubt there's a much better syntax for this! My point is that we don't
necessarily need to change the language. If you don't like CAR/CDR, then
you can use FIRST/REST, some kind of destructuring like I've described
above, more general pattern matching, or something else.
The cost is that you're no longer using a language familiar to other
Scheme programmers. However, if this kind of extension to Scheme is not
used by any Scheme books, there will be little if any benefit for
teaching. It _is_ possible, but I've no idea if anyone is using this for
teaching, nor might there be much point, since it isn't stictly Scheme.
Christopher Browne
On 16 Jun 1998 02:55:01 GMT, Amit Patel <am...@Xenon.Stanford.EDU> wrote:
> Christopher Browne <cbbr...@hex.net> wrote:
>| 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."
>
>Yes, but what about the average person who isn't into computer
>science? The subject [Teaching Programming] doesn't say it's for CS
>students (although it may have been implied).
Well, once you've learned something how (lambda (x) (y)) works and is
used, then you evidently *do* know something about computer science.
"Don't talk to strangers..."
"But once I've talked to them, they're not strangers any more..."
--
"If all you can see is vast masses of end-users chewing their cud and
running Win95 on Gateways, then what good is platform independence?"
-- David LeBlanc (dleb...@mindspring.com)
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Christopher Browne
On Tue, 16 Jun 1998 16:26:20 +0100, Martin Rodgers
<m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk>
wrote:
>In article <x2d8c9q...@gairsay.aiai.ed.ac.uk>,
>je...@gairsay.aiai.ed.ac.uk says...
>
>> car and cdr need no argument. They're like words in natural
>> languages: the reasons for them are almost all historical.
>
>This is exactly why they alienate anyone learning the language. Is anyone
>learning Scheme expected to appreciate the historical origins of CAR/CDR?
Is anyone learning English expected to appreciate the historical origins
of words coming from French, Latin, German, and other places?
The point is that there is not much potential *benefit* from moving from
one cryptic representation to another.
Precisely how was (frrrfst list) better than (cadddar list)?
They both look pretty cryptic to me.
--
"...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning." (By Matt Welsh)
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
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?
Jeff Dalton
m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk (Martin Rodgers) writes:
> In article <x2d8c9q...@gairsay.aiai.ed.ac.uk>,
> je...@gairsay.aiai.ed.ac.uk says...
>
> > car and cdr need no argument. They're like words in natural
> > languages: the reasons for them are almost all historical.
>
> This is exactly why they alienate anyone learning the language. Is anyone
> learning Scheme expected to appreciate the historical origins of CAR/CDR?
No, but no one suggested that they were supposed to.
However, people put up with such stuff all the time in natural
languages, and there are plenty of terms in mathematics, CS, and
so on that have meanings that are not suggested by already-familiar
ordinary-language terms. That "and so on" is pretty extensive
(e.g. it includes philosophy, literary criticism, and discussions of
music played on MTV). There's even some overlap between some other
subjects and Lisp. For instance, lambda is used in some varieties of
formal semantics for natural language.
I don't think car and cdr are really that big a deal. If they were
eliminated, the complaints would just focus on something else.
There's a fairly general phenomenon that something strange and
unfamiliar may not be enjoyable. But that changes with exposure.
For instance, the first time I played the Psychedelic Furs 1st album,
I thought it was about the worst thing I'd ever heard. A few weeks
later, I happend to play it again and thought it was great.
> I wonder if many people who don't use Lisp feel when their hear or read
> anything about Lisp? It's important, I think, for us to show that Lisp
> has strong practical value.
One thing I rather enjoyed, when taking a course that let us use
whatever programming language we wanted for the "homework"
assignments, was being finished while other people were still
trying to get their storage management right. But maybe that's
not so convincing these days, now that garbage collection is
almost respectable.
-- jd
Jeff Dalton
Jeff Dalton <je...@gairsay.aiai.ed.ac.uk> writes:
> Jeffrey Mark Siskind <qo...@research.nj.nec.com> writes:
> > Actually, believe it or not, I once saw an early Lisp implementation that
> > handled c[ad]+r generatively. In other words, it did not define a finite
> > number as you did above but actually had a demon hanging off of the unbound
> > function cell error handler, parsed the symbol print name, and when it
> > determined that it was of the form c[ad]+r computed the desired result.
> > It did not, if I recall, actually generate or intern the function. It
> > just computed the desired result.
> > I don't remember which Lisp this was. Might have been PDP-8 Lisp,
> > some IBM-360 Lisp, or perhaps Franz Lisp.
> Franz Lisp does it. I don't remember off hand whether it interns the
> name, but I'm pretty sure it does. I can check when I go home tonight.
Yes, it creates the symbol:
-> (cadddddddddddddddddddddddr (oblist))
rplacx
-> (apropos "ddddddddddddd")
cadddddddddddddddddddddddr
function: (lambda (??) (car &))
nil
-- jeff
Christopher Browne
On Tue, 16 Jun 1998 21:12:12 +0100, Martin Rodgers
<m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk>
wrote:
>In article <CKyh1.15$ir6.2...@cam-news-reader1.bbnplanet.com>,
>bar...@bbnplanet.com says...
>> No. But do you need to appreciate the historical origins of "dog" to learn
>> English?
>
>If the meaning of the word "dog" was hard to understand or remember, then
>I'd say yes. A name can help us remember the meaning, but CAR and CDR
>fail to do this. I vaguely recall reading that some Lisps use HEAD and
>TAIL, or HD and TL. These names are rather more helpful.
>
>It's not simply that CAR and CDR are odd names, but the use of CADR to
>access the second element of a list is far less meaningful than SECOND.
>If you can remember how CADR is a contraction of (CAR (CDR ...)), it
>makes a little more sense, but nowhere near as much sense as SECOND.
Surely. And Common LISP introduced (first) and (rest), if memory
serves, which is, in many ways preferable.
>Contractions of HD and TL might be just as confusing. It's easy for us to
>remember the meanings now, and when we can't remember or don't bother, we
>can just read the function name backwards:
>
>CADR = AD = (A (D ...)) = (CAR (CDR ...))
Surely so. I think there's little value to replacing one (admittedly)
cryptic system with another cryptic system that effectively differs not
at all.
>For what seemed like a long time, I was reading Lisp code and not knowing
>what these functions did. I understood CAR and CDR fine, but the names
>made no sense. This "lack of sense" is alienating - as if a computer
>language needs anything to alienate anyone new to programming!
And, for that, (first) and (rest) would surely be more "friendly."
There is merit to the idea of creating functions to correspond to the
(ca[some number of d's]r) functions that might be called (second),
(third), (fourth), (fifth), ... Those are descriptive of the
operations, and the names are "human meaningful."
Something like (cdadr), on the other hand, is a pattern where I can't
think of a decent name. It's also a case that isn't too likely to be
used except by a program that constructs programs.
And in such cases, it may still be valuable enough to have (cdadr)
around. I would argue that it reduces the complexity of the resulting
code. That may be a scary notion; nonetheless
(cdadr list)
is still simpler to look at than
(cdr (car (cdr list)))
particularly if it occurs in the middle of an even hairier
automatically generated expression.
That is probably the *real* reason for the existence of deeply nested
combinations of these things; you won't be using (cdadr) by choice in a
well-structured program, but a program that generated some LISP code may
be made (marginally) simpler by making that sort of substitution.
Martin Rodgers
In article <6m72c1$192$7...@blue.hex.net>, cbbr...@news.hex.net says...
> The point is that there is not much potential *benefit* from moving from
> one cryptic representation to another.
We're talking about beginners, or so the thread subject suggests.
Martin Rodgers
In article <4nu35ln...@rtp.ericsson.se>, t...@rtp.ericsson.se says...
> It's part of the language. You just have to memorize that this word
> means this and that word means that.
Do the CAR/CDR names not look a little strange to you? After years of
using them, they still look odd to me. FIRST/REST at least sound like
familiar nouns. Please don't underestimate the significance of the
familiar when learning something new, esp when it's a language full of
unfamiliar ideas. It's not a question of memory, but intimidation.
When we use contractions like CADR, this naming convention gets very
silly. You and I know how it makes sense, but that's only because we
persevered. I learned the trick of reading these names backwards. I
didn't give up, but most programmers I know wouldn't get that far. They
can't even get passed the (...) syntax, and I'm not questioning that!
So what can we say? "Stuff 'em if they can't be bothered"? A lovely
attitude. That's fine if you can afford it. Just give a beginner one more
hurdle to jump over, and see if they can manage it. We could do it, so
why can't they? Possibly because they don't (yet) see why they should.
Curiously, this is the same attitude that many people have for other
languages, like C++. "Go away, you're different."
On the other hand, if Perl can succeed as well as it has, perhaps Scheme
can too. This leads me to wonder what the _real_ problem might be? The
"go away" attitude is common, in my experience. Even Perl suffers because
of it, just not enough to stop it getting a high profile.
Perhaps this is just a matter of successful marketing? Even when teaching
students, this might help. Get them motivated! My guess is that everyone
here was motivated to learn Scheme. How do most students feel about it?
--
Please note: my email address is munged; You can never browse enough
Hit the advocates three timesd over the head with the Linux Advocacy
mini-HOWTO <URL:http://sunsite.unc.edu/LDP/HOWTO/mini/Advocacy.html>
Martin Rodgers
In article <x2af7c4...@gairsay.aiai.ed.ac.uk>,
je...@gairsay.aiai.ed.ac.uk says...
> > This is exactly why they alienate anyone learning the language. Is anyone
> > learning Scheme expected to appreciate the historical origins of CAR/CDR?
>
> No, but no one suggested that they were supposed to.
Is the thread subject not "Teaching Programming"? If we're not talking
about beginners, and how they see the language, let's change the subject.
I'm not interested here in what experienced Schemers think of Scheme.
> I don't think car and cdr are really that big a deal. If they were
> eliminated, the complaints would just focus on something else.
I'm not suggesting that _anything_ be eliminated. You can _add_ to the
language - that's what we do, after all. You can also leave out certain
parts of the language when teaching, like CADR. Just write "(define
second cadr)" and perhaps later, when the student can understand it,
explain why you did this.
> There's a fairly general phenomenon that something strange and
> unfamiliar may not be enjoyable. But that changes with exposure.
_If_ you get that far. I know that many people don't. They stop when they
see the (...) syntax, and I'm not even questioning that.
> One thing I rather enjoyed, when taking a course that let us use
> whatever programming language we wanted for the "homework"
> assignments, was being finished while other people were still
> trying to get their storage management right. But maybe that's
> not so convincing these days, now that garbage collection is
> almost respectable.
Most people I know would choose Basic...YMMV.
--
Please note: my email address is munged; You can never browse enough
Martin Rodgers
In article <6m7b4h$7d9$5...@blue.hex.net>, cbbr...@news.hex.net says...
> Surely. And Common LISP introduced (first) and (rest), if memory
> serves, which is, in many ways preferable.
This is easy to do in Scheme, too.
> >CADR = AD = (A (D ...)) = (CAR (CDR ...))
>
> Surely so. I think there's little value to replacing one (admittedly)
> cryptic system with another cryptic system that effectively differs not
> at all.
I find lists used in all kinds of languages, and functions the do the
same thing as FIRST and REST. For example, Cold Fusion, which has
functions ListFirst, ListLast, ListGet, and ListAppend etc. While they
may use strings as the representation, the ideas are very much like those
of Lisp. Just more limited because of the data representation.
You can easily guess how I'd introduce Lisp to programmer familiar with
Cold Fusion. Start with the familiar concepts and eventually move on to
the less familiar.
> Something like (cdadr), on the other hand, is a pattern where I can't
> think of a decent name. It's also a case that isn't too likely to be
> used except by a program that constructs programs.
Indeed. A beginner might not yet appreciate the value of writing code
that writes code, never mind code that writes code that exploits cdadr.
It's easy to write (rest (first (rest ...))). I'v never had to do this,
probably because my code tends to have tests at each step. I can imagine
code like this used in accessor functions for data represented using
pairs, but I've always prefered using macros that define them for me.
I'm not suggesting that the contractions be removed, just that perhaps
they might be avoided when teaching beginners. A Scheme programmer should
eventually read the language spec and see for themselves. By that point
the most difficult struggle will have been passed, and they should know
enough to not to be easily scared away.
Tim Bradshaw
* Martin Rodgers wrote:
> Contractions. Which is easier to learn and use, CADR or SECOND?
Well, SECOND is only some use if you start off teaching lists and only
then tell people that lists are made of conses. I've experimented
(only once, but it worked reasonably, and it seemed to avoid the
common & awful problem of failing to understand that getting at the
nth element of a list takes O(n) time) with starting by teaching
people about conses, and doing various tree-type stuff, and only then
teaching them about lists. A language which required you to say FIRST
and REST would just cripple this way of teaching, because the
mnemonics would completely mislead people.
Conses are such a general & unspecific data type that having
meaningless words for the slots is the best way of doing it I think
(LEFT & RIGHT might be OK).
--tim
Andreas Eder
m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk (Martin Rodgers) writes:
> Do the CAR/CDR names not look a little strange to you? After years of
> using them, they still look odd to me. FIRST/REST at least sound like
> familiar nouns. Please don't underestimate the significance of the
> familiar when learning something new, esp when it's a language full of
> unfamiliar ideas. It's not a question of memory, but intimidation.
They don't look silly to me; instead theu sound more like friends.
cdr-ing along a list sounds familiar, mor so than resting along a list :-)
After all, when you learn lisp, you learn a new language, and every
language has its own new words.
> When we use contractions like CADR, this naming convention gets very
> silly. You and I know how it makes sense, but that's only because we
> persevered. I learned the trick of reading these names backwards. I
> didn't give up, but most programmers I know wouldn't get that far. They
> can't even get passed the (...) syntax, and I'm not questioning that!
I don't think so! On the contrary, it seems to be a quite logical way
to abbreviate - and you don't read it backwards; cadr is the car of the cdr.
What is backwards with that? In a large part of mathematical literature
you write f(g(x)) = (f . g) (x). This is just the same, and how youo
name your functions doesn't matter that much - if you you know what it is,
you will will remeber its name.
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.
Martin Rodgers
In article <ey3g1h4...@todday.aiai.ed.ac.uk>, t...@aiai.ed.ac.uk
says...
> Well, SECOND is only some use if you start off teaching lists and only
> then tell people that lists are made of conses.
obvious name for a function that will access the second element of a
list?
Martin Rodgers
In article <m3ium0c...@laphroig.mch.sni.de>, a...@laphroig.mch.sni.de
says...
> m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk (Martin Rodgers) writes:
>
> > Do the CAR/CDR names not look a little strange to you? After years of
> > using them, they still look odd to me. FIRST/REST at least sound like
> > familiar nouns. Please don't underestimate the significance of the
> > familiar when learning something new, esp when it's a language full of
> > unfamiliar ideas. It's not a question of memory, but intimidation.
>
> They don't look silly to me; instead theu sound more like friends.
> cdr-ing along a list sounds familiar, mor so than resting along a list :-)
How do they look to a beginner? I'll say it yet again: the subject of
this thread is "Teaching Programming".
> After all, when you learn lisp, you learn a new language, and every
> language has its own new words.
And new concepts. New hurdles. With so many languages, so many ideas, so
many advocates, is it suprising that simple languages are so popular?
Could it be that they're easier to learn than languages that demand more
from a programmer? Whether we like it or not, there are hordes of people
who want to know why they should spend so much time learning something.
We may know the answer, but how well can we communicate it?
You've only given a reason for people to avoid Scheme. I'm suggesting a
way to make learning Scheme easier, and therefore more attractive.
> > When we use contractions like CADR, this naming convention gets very
> > silly. You and I know how it makes sense, but that's only because we
> > persevered. I learned the trick of reading these names backwards. I
> > didn't give up, but most programmers I know wouldn't get that far. They
> > can't even get passed the (...) syntax, and I'm not questioning that!
>
> I don't think so! On the contrary, it seems to be a quite logical way
> to abbreviate - and you don't read it backwards; cadr is the car of the cdr.
> What is backwards with that? In a large part of mathematical literature
> you write f(g(x)) = (f . g) (x). This is just the same, and how youo
> name your functions doesn't matter that much - if you you know what it is,
> you will will remeber its name.
[sigh] It may well be quite logical way to _you_. I'm not disputing that.
I too can appreciate it. I also appreciate how much more "accessible" a
name like SECOND is. I appreciate how hostile many people are to anything
they don't know and don't understand.
I'm talking about people who are learning the language, not someone who
has already learned and accepted it. You and I have done that, possibly
because we were patient enough, or fortunate enough to have enough time
to get beyond the initial impressions. My point is that what may be a
feature to you may be a bug to others.
When I used the the "backwards" I used it _literally_, just as you do.
Not as a negative. I never do that. If I think something is shit, I say
so. I do _not_ think this feature is shit. I do, however, suggest that it
may be alienating someone learning Scheme, esp if they're not already
confortable with such conventions. I was; you may have been too.
Others are not. Is this idea too hard for you to understand, or are you
denying that anyone might have difficulty learning a new language?
--
Please note: my email address is munged; You can never browse enough
Michael Sperber [Mr. Preprocessor]
>>>>> "Martin" == Martin Rodgers <m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk> writes:
Martin> In article <ey3g1h4...@todday.aiai.ed.ac.uk>, t...@aiai.ed.ac.uk
Martin> says...
>> Well, SECOND is only some use if you start off teaching lists and only
>> then tell people that lists are made of conses.
Martin> Of course. Once you get beyond pairs, you have lists. What is the most
Martin> obvious name for a function that will access the second element of a
Martin> list?
What is the most obvious name for the second component of a pair?
SECOND, while being an appropriate name for second element of a list (CADR)
[I personally prefer (list-ref ... 1), but that's a different story],
is just as appropriate for the the second component of a pair (CDR).
If you think that's ridiculous, note that ML actually *has* snd mean
"the second component of a two-tuple".
I'd rather have non-mnemonic names that make it clear that I have to
remember precisely what they mean.
In all the years that I've been teaching Scheme, not a single student
ever complained about the names CAR and CDR.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Daniel R Barlow
In article <MPG.ff187018...@news.demon.co.uk>,
Martin Rodgers <m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk> wrote:
>Perhaps this is just a matter of successful marketing? Even when teaching
>students, this might help. Get them motivated! My guess is that everyone
>here was motivated to learn Scheme. How do most students feel about it?
Invoking the magic word "marketing" doesn't actually mean much.
The basic reason for learning Perl these days is CPAN. Whatever you
want to do, if it's related to Unix, NT, the WWW, or any popular SQL
database, there's probably a Perl module in CPAN that takes care of
most of the details. Installing these so you can use them is simply
a matter of downloading them, unpacking them, and then "perl Makefile.PL;
make ; make install". For something simple like, say, an online order
form on a web site tied to a database, it's probably simpler for a C
programmer to learn perl and use CGI.pm and DBI.pm than it is to
write it all in C.
I've not yet found a similar resource of the same size for scheme.
The good news, imo, is Kawa. Not for precisely the same application
domain, admittedly, but it's _so_ much more civilised than Java
for writing applets that I could happily never look at javac again.
With an FFI that allows you fairly painlessly to call anything you can
call in Java, you need never run up against the "oh no, you can't do
that bit in scheme yet, unless you want to write the support yourself"
barrier which you do in interfaces to C libraries.
Shame about the applet size that you'd get if you stuck the complete kawa
jar into an applet though. Maybe Mozilla could be persuaded to bundle the
kawa classes with come with Kawa pre-installed? Or I guess there might be
some way of having it download once only as a plugin.
-dan
Daniel R Barlow
In article <6m72c1$192$7...@blue.hex.net>,
>
>Precisely how was (frrrfst list) better than (cadddar list)?
>
>They both look pretty cryptic to me.
How often (would,do) you use either of them anyway?
I can't believe the fuss about this. C has "static" variables which you
can change and "auto" variables which don't vary on their own. Perl
has local variables introduced by "my" -- using "local" instead gets
you weird (dynamically scoped) variables. Constants in Java are
"final variables", which ought really to mean that they can take new
values at the end of the program.
I'm not aware of any protracted threads on any of those language's groups
which are talking about renaming those constructs to make the language more
appealing to new users. New users just see the practical benefit to
learning the language and accept a small amout of meaningless stuff
to learn as the price they have to pay.
-dan
Paul F. Snively
In article <MPG.ff09d96f...@news.demon.co.uk>,
m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk (Martin
Rodgers) wrote:
>In article <x2d8c9q...@gairsay.aiai.ed.ac.uk>,
>je...@gairsay.aiai.ed.ac.uk says...
>
>> car and cdr need no argument. They're like words in natural
>> languages: the reasons for them are almost all historical.
>
>This is exactly why they alienate anyone learning the language. Is anyone
>learning Scheme expected to appreciate the historical origins of CAR/CDR?
"Anyone" is obviously too broad; prior to encountering Lisp (of any kind) I
had not dealt with a language that had lists as a data type. "car" to grab
the first element of the list and "cdr" to present the rest (and yes, I'm
aware, as someone else pointed out, that strictly speaking "car" and "cdr"
deal with pairs, not necessarily lists) don't now, and didn't then, strike
me as any worse than 90+% of any other syntactic oddities of the other
languages I'd had exposure to. In particular, I think C exhibits much, much
worse cognitive loading.
>I'm the same, but I _know_ that I have an unusually high aptitude for
>such things. I can deal with things that seem to intimidate most other
>programmers, like writing code that writes code that writes code.
But you don't seem willing to trust other newbies to Scheme to have that
same aptitude/interest/whatever. My first exposure to Lisp (of any kind)
was via the SRI edition of "The Little Lisper," and I immediately made the
mapping from the notion of a function calling itself to the fascinating (to
me) experience of standing between two facing mirrors. It wasn't hard to
hook me on recursion, so it wasn't hard to hook me on Lisp. "car" and "cdr"
were, and are, just two (relatively straightforward, IMHO) tools to get a
particular job done in Lisp.
>Most people I meet have no interest at all in learning a new language, so
>I can't really comment on this. It's even worse online, because I can't
>see their eyes glaze over...Perhaps they've seen too many language wars,
>or received the "hard sell" treatment too many times?
It's been my experience that most people can't haul around so many
abstractions, and it's important to remember (and should be obvious to
Lispers, in particular) that a programming language is Yet Another
Abstraction. We may feel the abstraction, in the case of Scheme, is
particular lightweight, elegant, isomorphic, orthogonal, or whatever other
features make it easy for us, as individuals, to retain and apply. But for
someone who feels like it's taking all of their intellectual energy to do
the same for [Java|C++|C], it shouldn't be hard to understand why they'd be
reluctant to add anything to the list--especially if they've been led by
the likes of C++ to expect that *all* programming languages are that
byzantine!
>Not too long ago I discovered the Linux Advocacy HOWTO. If more Linux
>advocates read this and used it as their guide, I might feel less weary
>when I read almost anything online about Linux. I like Linux a lot, but I
>dislike being pressured into using it, or being told that it's wrong to
>use anything else.
I've actually found the Linux community *much* more congenial than any
language community I'm a member of. Besides, I find it relatively easy to
forgive Linux folks who overdo it: they *are*, after all, sitting on a
major success story that had been overlooked for some time simply because
it came about via means other than the usual (in a capitalist society,
anyway) corporate ones.
>I wonder if many people who don't use Lisp feel when their hear or read
>anything about Lisp? It's important, I think, for us to show that Lisp
>has strong practical value. In a tutorial, this may mean starting with
>practical examples, like solving a few everyday problems. That may mean
>initially diving in at the deep end, but it would be possible to step
>back and begin with the basics. If your students have already seen how
>useful the language can be, they could be more motivated to follow you.
>
>Actually, the Linux Advocacy HOWTO suggests this approach...
I haven't found this approach to be successful precisely because it mirrors
what *has* to be done in less clean languages and presents the students
with the sense that "if all Scheme does is what C/C++ does, but with an
even uglier syntax, why bother?" I hate to say it, but the approach that's
worked best for me is to almost take a mystical attitude toward Scheme and
sell that:
Me: "You can do very counterintuitive, weird things in Scheme, like create
the list of all integers, and from that, the list of all even numbers, or
all odd numbers, or all primes..."
Student: "Like hell. Those are infinitely-long lists."
Me: "Exactly."
Student: "Hmmm... I don't believe you. Show me."
OK, so showing them involves taking advantage of the fact that functions
are first-class and delaying evaluation and, if I want to be efficient,
memoization. These are important topics in functional programming, and they
*do* make it possible to implement various kinds of infinities--itself an
important topic in mathematics and logic. Perhaps more to the point for
teaching programming, they allow us to teach programming in a fashion that
takes advantage of things about the vehicle (in this case, functional
languages in general) that aren't available in many other vehicles, such as
[C|C++|Java].
>--
>Please note: my email address is munged; You can never browse enough
>"Ahh, aren't they cute" -- Anne Diamond describing drowning dolphins
Paul Snively
Jeff Dalton
m...@wildcard.this.email.address.intentionally.left.crap.demon.co.uk (Martin Rodgers) writes:
> In article <x2af7c4...@gairsay.aiai.ed.ac.uk>,
> je...@gairsay.aiai.ed.ac.uk says...
>
> > > Is anyone learning Scheme expected to appreciate the
> > > historical origins of CAR/CDR?
> > No, but no one suggested that they were supposed to.
> Is the thread subject not "Teaching Programming"? If we're not talking
> about beginners, and how they see the language, let's change the subject.
> I'm not interested here in what experienced Schemers think of Scheme.
I'm not changing the subject, and in any case "teaching" is not
confined to beginners to programming. Some people learning scheme
will already know a fair amount about programming and programming
languages. Besides, I was responding directly to things said
in another message. If the subject was changed, they'd already
changed it.
In any case, my point is that the explanation for car and cdr is
historical, not that anyone is supposed to *appreciate* this.
Someone suggested car and cdr were "homage to an ancient DEC [sic]
machine". But no, they're not.
It was then supposed that "contractions" such as cadr were an
argument.
I said no argument was needed. No one feels that we have to
argue that "water" is (or isn't) a *good* word for that clear,
drinkable liquid. Why "water"? It's just what history have us.
> > I don't think car and cdr are really that big a deal. If they were
> > eliminated, the complaints would just focus on something else.
>
> I'm not suggesting that _anything_ be eliminated.
Ok, then I'll put it like this: if the language provided alternatives,
the complaints would either still focus on car and cdr, because they
were still in the language, or would focus on some other "perceived"
problem. The overall degree and amount of criticism would not
significantly change.
When people complain about car and cdr, that doesn't mean car and
cdr are really the problem. They're something that people notice
and can easily formulate a complaint about.
> > There's a fairly general phenomenon that something strange and
> > unfamiliar may not be enjoyable. But that changes with exposure.
>
> _If_ you get that far. I know that many people don't. They stop when they
> see the (...) syntax, and I'm not even questioning that.
And for those people, nothing we do about car and cdr will make
any difference.
> > One thing I rather enjoyed, when taking a course that let us use
> > whatever programming language we wanted for the "homework"
> > assignments, was being finished while other people were still
> > trying to get their storage management right. But maybe that's
> > not so convincing these days, now that garbage collection is
> > almost respectable.
>
> Most people I know would choose Basic...YMMV.
The first language I learned was Basic. The second was Lisp.
(What is "YMMV"?)
-- jeff