SICP & the Dumbing Down of American Comp Sci
bhal...@hotmail.com
I have been working in the American software industry
for 20+ years. One book I have come to admire greatly is
"The Structure and Interpretation of Computer Programs"
by Abelson, Sussman, & Sussman or better known to the
initiated simply as SICP!!! This book is like an onion.
Each time you read it you peel off another layer. This
is my third time around!!!
I think it is a great pity that the academic world seems
to have caved into the pragmatism dictated by industry and teaches
courses on C++, Java,
etc. I'm not sure how to counteract this trend. Recently I was in the
Standford U. bookstore. Maybe I wasn't in the right
place and I missed all the "neat"
SICP-like books because all I saw was the "how-to-make-better"
widgets using C++, Java etc. instead of Computer Science books.
SICP rightly makes the claim in the beginning of the
book that they will teach the reader Scheme as the book
unfolds. Could C++ be used as basis for a similar book??
I think not. I have written in ANSI C for more than 10
years. Thus I believe my point is the more poignant.
What do others think??
Regards,
Vasili N. Galchin
Sent via Deja.com http://www.deja.com/
Before you buy.
Matthias Blume
Posting this sort of thing to comp.lang.{functional,dylan,scheme} is
preaching to the converted, I think.
Matthias
--
Matthias Blume <blume@k_u_r_i_m_s.k_y_o_t_o-u.a_c.j_p>
Kyoto University, Research Institute for Mathematical Sciences
(remove underscores in mail address; they are there to fight spam)
Mike Thomas
> I think it is a great pity that the academic world seems
> to have caved into the pragmatism dictated by industry and teaches
> courses on C++, Java,
C++ and Java are OK, certainly better than Cobol, Fortran and Basic.
Java may well provide a route in for functional programming languages (MLj
and Kawa) via the Java virtual machine. It gets the compiler guru's off the
hook for writing GUI interfaces and other system specific stuff. For
example, after twelve months of intermittent attempts, I still can't make
the Win32 library for GHC work, but MLj works straight off. Other than MLj,
the closest I have gotten is to use and extend the Moscow ML Open GL
package, but I haven't been able to set up a proper mouse/keyboard event
loop yet (I'll keep trying though).
> etc. I'm not sure how to counteract this trend.
Simple - use functional programming languages in your workplace and stand up
for your beliefs where it counts. If that fails, use guerilla tactics!
I administer my workplace's contract and software licencing system (amongst
other tasks). I use SIOD (Scheme), Javascript and Access 97 VBA (about
2-3000 lines of each) on Solaris, Irix and Windows NT, to automate that
system and publish data on our intranet. I kept my use of SIOD secret for
about six months (I'm a manager who supervises the Systems Administrator so
I can get away with it - programming provides me with some light relief in
the workplace), but in the end had an argument with my boss about it. He
accused me of trying to make myself indispensible by using Scheme which he
claimed noone else knew. After we cooled off, it turned out that Lisp had
been successfully used several years before in our company to convert
Fortran into C (prior to my arrival) and he admitted that Lisp was a good
language!
I still use SIOD here, but I'm thinking of changing over to MLj, Moscow ML,
or one of the Haskell's to replace SIOD for CGI scripts and web site
maintenance. I hate ML's syntax, but MoscowML and MLj are easier to
install, recompile and use than the Haskell compilers GHC and NHC (under
Windows at least, which is my OS of choice). Harlequin's Personal Dylan,
Clean and O'Caml are all nice, but I would feel vulnerable with any of those
choices because of the vendor specific nature of those beasts.
SIOD is so small that it is great for sneaking onto your work system, by the
way.
Cheers
Mike Thomas
PS. Who cares if Comp Sci in the US dumbs down? I live elsewhere.
Mike Thomas
> preaching to the converted, I think.
Yes, but he needs political rather than religious instruction I think!
Michael David WINIKOFF
>PS. Who cares if Comp Sci in the US dumbs down? I live elsewhere.
Unfortunately most computing products come from the states.
This includes MacOS, Windows, original Unix (but not Linux), netscape, etc.
Both MacOS and Windows remained ugly kludges for so long because
the relevant companies (Apple and MS) had an anti-academic bias
and ignored existing knowledge (e.g. Unix).
Michael
Mike Thomas
Michael David WINIKOFF <wini...@cs.mu.oz.au> wrote in message
news:7splcv$nl8$1...@mulga.cs.mu.OZ.AU...
> Both MacOS and Windows remained ugly kludges for so long because
> the relevant companies (Apple and MS) had an anti-academic bias
> and ignored existing knowledge (e.g. Unix).
I had always thought that Apple took a positive approach to research and
development (I guess that's different from pure academia), witness the
pirating of the WIMP concept from PARC, and the introduction of Dylan (slyly
reintroducing some on topic subject matter). They just charge too much in
Australia for their products.
I note that Microsoft seems to be hiring some of the leading lights in the
Haskell compiler writer community.
Cheers
Mike Thomas.
Michael David WINIKOFF
>> Both MacOS and Windows remained ugly kludges for so long because
>> the relevant companies (Apple and MS) had an anti-academic bias
>> and ignored existing knowledge (e.g. Unix).
>I had always thought that Apple took a positive approach to research and
>development (I guess that's different from pure academia), witness the
That was later - and last I heard they'd closed down various research groups.
>pirating of the WIMP concept from PARC, and the introduction of Dylan (slyly
>reintroducing some on topic subject matter). They just charge too much in
>Australia for their products.
>I note that Microsoft seems to be hiring some of the leading lights in the
>Haskell compiler writer community.
Again, this is much later - I'm referring to the early days.
Unfortunately MS research seems aimed at incorporating more features
into windows. For example, in order to fix basic problems with bad user
interface design they're looking at incorporating natural language
processing technology.
With respect to Haskell (and returning to this newsgroup) it's
natural for MS to be interested in Haskell - they're probably
running out of ways to make Windows 2000 larger and slower.
Incorporating GHC ought to do the trick ... and once they've
re-written MS Word in Haskell it should slow down and bulk up enough
to force people to upgrade PCs again. Of *course* you need a
septium to do basic word processing.
Michael
PS :-)
>Cheers
>Mike Thomas.
Mike Thomas
> With respect to Haskell (and returning to this newsgroup) it's
> natural for MS to be interested in Haskell - they're probably
> running out of ways to make Windows 2000 larger and slower.
> Incorporating GHC ought to do the trick ... and once they've
> re-written MS Word in Haskell it should slow down and bulk up enough
> to force people to upgrade PCs again. Of *course* you need a
> septium to do basic word processing.
>
> Michael
> PS :-)
Actually, if you stand back a bit from a screen with a page of Haskell and a
page of VBA, they both look the same!
bhal...@hotmail.com
I have been working in the American software industry
for 20+ years. One book I have come to admire greatly is
"The Structure and Interpretation of Computer Programs"
by Abelson, Sussman, & Sussman or better known to the
initiated simply as SICP!!! This book is like an onion.
Each time you read it you peel off another layer. This
is my third time around!!!
I think it is a great pity that the academic world seems
to have caved into the pragmatism dictated by industry and teaches
courses on C++, Java,
bhal...@hotmail.com
"Mike Thomas" <mik...@ptmnet.com> wrote:
>
> Michael David WINIKOFF <wini...@cs.mu.oz.au> wrote in message
> news:7splcv$nl8$1...@mulga.cs.mu.OZ.AU...
>
> > the relevant companies (Apple and MS) had an anti-academic bias
> > and ignored existing knowledge (e.g. Unix).
>
> I had always thought that Apple took a positive approach to research
and
> development (I guess that's different from pure academia), witness the
(slyly
> reintroducing some on topic subject matter). They just charge too
much in
> Australia for their products.
>
> I note that Microsoft seems to be hiring some of the leading lights
in the
> Haskell compiler writer community.
^^^^^^^^^^^^ E.g. who???
Vasili
>
> Cheers
>
> Mike Thomas.
Matthew M. Huntbach
> Hello,
> I have been working in the American software industry
> for 20+ years. One book I have come to admire greatly is
> "The Structure and Interpretation of Computer Programs"
> by Abelson, Sussman, & Sussman or better known to the
> initiated simply as SICP!!! This book is like an onion.
> Each time you read it you peel off another layer. This
> is my third time around!!!
> I think it is a great pity that the academic world seems
> to have caved into the pragmatism dictated by industry and teaches
> courses on C++, Java, etc.
I think part of the reason for this is because students these days are a
lot less willing to take "what is good for them". Twenty years ago students
were probably less demanding and more willing to take on trust what they
were told by their professors in general. In Computer Science we have the
additional factor that twenty years ago, students coming in to do a degree
in the subject probably wouldn't have touched a computer before, and wouldn't
have had much idea about the subject. Now most potential students at least
*think* they know about the subject, and think it's all about training in
current popular systems. If you take what they will dismiss as a "too
academic" approach, you will lose the best students to a neighbouring
university which makes its selling point "we teach the language they use in
industry".
Matthew Huntbach
Bob Jarvis
>If you take what they will dismiss as a "too
>academic" approach, you will lose the best students to a neighbouring
>university which makes its selling point "we teach the language they use in
>industry".
Oh. So you teach mostly COBOL, then, right? :-)
--
Bob Jarvis
Mail address hacked to foil spammers!
Remove "ob" from address to reply
bhal...@hotmail.com
> academic" approach, you will lose the best students to a neighbouring
> university which makes its selling point "we teach the language they
use in
> industry".
>
>
Matthew,
I agree part what you say. However, I think greed plays
big part. Both on the part of industry and software engineers.
E.g. I read article in San Jose Mercury News criticising
Silicon Valley companies for only now doing E commerce and
showing lack of real innovation. They compared to a company
started by MIT student doing (I forget!) I think natural language
product. Also, American education is too pragmatic. No mathematics.
E.g. in writing in C, C++, with no garbage collection always
memory leaks! Also big correctness problem. Maintainability
(which is related to correctness) is big problem; also
managing complexity of software! All related. Sorry my English is
not so good!
Vasili
bhal...@hotmail.com
Matthias Blume <s...@my.sig> wrote:
>
> Posting this sort of thing to comp.lang.{functional,dylan,scheme} is
> preaching to the converted, I think.
>
>
> --
> Matthias Blume <blume@k_u_r_i_m_s.k_y_o_t_o-u.a_c.j_p>
> Kyoto University, Research Institute for Mathematical Sciences
> (remove underscores in mail address; they are there to fight spam)
>
Where to post??
Matthew M. Huntbach
> Matthew M. Huntbach wrote in message <7sq3dd$aal$1...@beta.qmw.ac.uk>...
> >academic" approach, you will lose the best students to a neighbouring
> >university which makes its selling point "we teach the language they use in
> >industry".
> Oh. So you teach mostly COBOL, then, right? :-)
No, but we teach mostly Java. This despite the fact that there's a lot wrong
with Java and the *ideal* language for teaching might well be something
else. At the moment, there's enough Java hype around for using it for teaching
to be a selling point. But if Java never really takes off with industry, I
can see it getting categorised as an "academic language" and a reluctant
return to teaching in (the even worse) C++.
Matthew Huntbach
Craig Dickson
>But if Java never really takes off with industry, I
>can see it getting categorised as an "academic language"
Despite, of course, its origins in "industry"...
>and a reluctant
>return to teaching in (the even worse) C++.
Oh, I don't know. It's a matter of distaste. They're both pretty vile.
Craig
Bob Jarvis
>Bob Jarvis (jarv...@timken.com) wrote:
>> Oh. So you teach mostly COBOL, then, right? :-)
>
>No, but we teach mostly Java. This despite the fact that there's a lot
wrong
>with Java and the *ideal* language for teaching might well be something
>else. At the moment, there's enough Java hype around for using it for
teaching
>can see it getting categorised as an "academic language" and a reluctant
>return to teaching in (the even worse) C++.
Perhaps a wise course would be to prepare an exit strategy in the event that
Java stumbles. Teaching in a functional language might be a departure from
the norm but would, I think, provide some long-term benefits to the students
(who, I realize, aren't interested in long-term benefits, thus leading to
the recruitment problems you mentioned originally). If you must go the
imperative route, perhaps Smalltalk? (Warning: the author of this post is a
registered pro-Smalltalk bigot :-). Maybe you could combine them (research
projects, anyone?) and produce a functional Smalltalk? Just thinking out
loud, you understand...
Patrick Logan
: ...we teach mostly Java. This despite the fact that there's a lot
: wrong with Java and the *ideal* language for teaching might well be
: something else. At the moment, there's enough Java hype around for
: using it for teaching to be a selling point. But if Java never
: really takes off with industry, I can see it getting categorised as
: an "academic language" and a reluctant return to teaching in (the
: even worse) C++.
Have you seen the book _A Little Java, A Few Patterns_ (or something
like that?)
It is by the authors of The Little Lisper, Matthias Felleisen and
Daniel P. Friedman. What a great book. You can tell it is a great book
because the Amazon reviews are split between one star ("This book is
the worst") and five stars ("This book is the best"). It is either
your cup of tea or its not, but it sure is better than any other intro
to Java I've seen.
--
Patrick Logan patric...@home.com
Thomas A. Russ
> .... If you take what they will dismiss as a "too
> academic" approach, you will lose the best students to a neighbouring
> university which makes its selling point "we teach the language they use in
> industry".
I think this is a gross overstatement, as least insofar as the "best
students" are concerned. I would expect that the best students would be
the ones receptive to a more academic approach. They should certainly
understand the argument that the fundamental ideas behind programming
are much more important than the current "langue du jour", especially if
the professors point out that five years ago nobody would have thought
of teaching Java.
In any case, I doubt that MIT has to fear losing their best students to
some nearby Java mill (Harvard? :) just because they use SICP.
--
Thomas A. Russ MIT '80, USC/Information Sciences Institute t...@isi.edu
Scott Ribe
"Thomas A. Russ" wrote:
>
> I think this is a gross overstatement, as least insofar as the "best
> students" are concerned. I would expect that the best students would be
> the ones receptive to a more academic approach. They should certainly
> understand the argument that the fundamental ideas behind programming
> are much more important than the current "langue du jour", especially if
> the professors point out that five years ago nobody would have thought
> of teaching Java.
>
> In any case, I doubt that MIT has to fear losing their best students to
> some nearby Java mill (Harvard? :) just because they use SICP.
Yes, exactly. But only the "best colleges" really attract the "best
students". Thus MIT and a small handful of select institutions can use
whatever the hell they want for pedagogic purposes, and thus pursue
their goal of turning out engineers who really understand computer
science instead of coders for some specific language/toolset. But the
other 99% of academic programs must use some other marketing technique,
since "this is MIT" only works for MIT ;-)
There's actually a broad continuum here, with SICP at the top, and going
all the way to the "Learn VBA in 21 days" kind of sludge.
Scott Ribe
6-3 '85 BTW ;-)
Barry Margolin
> What do others think??
That you already started this thread last night, and there was no need to
repost your initial message.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Jeffrey B. Siegal
> But the
> other 99% of academic programs must use some other marketing technique,
> since "this is MIT" only works for MIT ;-)
How about "This is what they use at MIT?"
Jeffrey B. Siegal
> Unfortunately MS research seems aimed at incorporating more features
> into windows.
Actually, it is pretty clear that the primary goal of MS research is building up
a patent portfolio.
Scott Ribe
"Jeffrey B. Siegal" wrote:
>
> How about "This is what they use at MIT?"
That would seem to have potential ;-)
Hamilton Richards Jr.
Russ) wrote:
> ... I would expect that the best students would be
> the ones receptive to a more academic approach. They should certainly
> understand the argument that the fundamental ideas behind programming
> are much more important than the current "langue du jour", especially if
> the professors point out that five years ago nobody would have thought
> of teaching Java.
It seems to work for us at the University of Texas @Austin.
We have a wide variety of students, of whom the best are very good indeed.
Our first course for CS majors is taught in Haskell or Scheme (depending
on the instructor). We do get some flak from students who object that
industry uses C++ or whatever, but we reply that we're attempting not to
train cannon-fodder coders but to educate computer scientists.
Since we have the luxury (?) of huge CS enrollments, we can suggest to the
unconvinced that they look elsewhere for training that's more to their
taste. It also helps that we've just inaugurated a CS course sequence for
non-majors.
--HR
--
Hamilton Richards Jr. Department of Computer Sciences
Senior Lecturer Mail Code C0500
512-471-9525 The University of Texas at Austin
SHC 434 Austin, Texas 78712-1188
Mike Thomas
<bhal...@hotmail.com> wrote in message news:7sr2c7$jdl$1...@nnrp1.deja.com...
> In article <k7ZH3.22985$1E2.1...@ozemail.com.au>,
> "Mike Thomas" <mik...@ptmnet.com> wrote:
> > I note that Microsoft seems to be hiring some of the leading lights
> in the
> > Haskell compiler writer community.
>
> ^^^^^^^^^^^^ E.g. who???
I believe that a couple of the guys involved with the GHC compiler are
employed at a Microsoft Research Centre in the UK - I can't remember their
names.
I also believe that there is at least one Haskell mailing list hosted on a
microsoft server.
Cheers
Mike Thomas.
Brian Harvey
>additional factor that twenty years ago, students coming in to do a degree
>in the subject probably wouldn't have touched a computer before, and wouldn't
>have had much idea about the subject. Now most potential students at least
>*think* they know about the subject, and think it's all about training in
>current popular systems.
I think this is all the more reason to teach SICP. These days nearly
everyone who wants to study CS has already taken a programming course
in some C-like language, so why just give them more of the same?
Also, all the people who've said things like "how many Lisp jobs are there"
are, imho, missing the point. We're not in the business of teaching
programming languages, and SICP is not a course about Scheme. We've taught
Scheme by the end of the first week; other than that, we're teaching ideas
that will be valuable no matter what language you use.
It's true that students don't always see that. Once when I was teaching
our second (data structures) course, back when it was in C, I gave this
exam question: given a binary search tree, and two numbers as lower and
upper bounds, return a linked list of all the numbers in the tree that
are between the bounds, without wasting comparisons. Nobody got it right.
So in class the next day I asked them to write it in Scheme, and about
half of them could do that. So I wrote the Scheme procedure on the board,
and next to it I wrote the same algorithm in C, and they were all amazed.
Because they were programming in C, they thought they weren't allowed to
use recursive functions -- real programmers don't etc. Sigh. But at
least that particular bunch of students ended up getting the point.
Ulf Wiger
Matthew> In Computer Science we
Matthew> have the additional factor that twenty years ago, students
Matthew> coming in to do a degree in the subject probably wouldn't
Matthew> have touched a computer before, and wouldn't have had much
Matthew> idea about the subject. Now most potential students at
Matthew> least *think* they know about the subject, and think it's
Matthew> all about training in current popular systems. If you take
Matthew> what they will dismiss as a "too academic" approach, you
Matthew> will lose the best students to a neighbouring university
Matthew> which makes its selling point "we teach the language they
Matthew> use in industry".
This is an interesting phenomenon that I used to come across when
teaching Track & Field coaching skills. We received a lot of students
who already considered themselves experts in the field -- they were
always the worst, and it normally took quite a lot of debate to get
them to realise that there was much they didn't know.
In contrast, I had the pleasure of teaching a couple of former
Olympians, who were as humble as could be. In my experience, students
who have just begun to think they know something are the most
difficult to teach; students who may even know more than yourself
are usually willing to give you a chance, knowing that there is
always so much more to learn.
When it comes to computer science, this attitude seems to be wide-
spread: everyone's an expert. I've heard horror stories about
large companies in Sweden hiring incompetent consultants because they
can't tell the difference between a good computer engineer and someone
who just took an evening class in HTML.
Perhaps that speaks to the still relative immaturity of computer
science...?
/Uffe
--
Ulf Wiger, Chief Designer AXD 301
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuvägen 9, Älvsjö mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden fax: +46 8 719 43 44
Matthew M. Huntbach
> > .... If you take what they will dismiss as a "too
> > academic" approach, you will lose the best students to a neighbouring
> > university which makes its selling point "we teach the language they use in
> > industry".
> I think this is a gross overstatement, as least insofar as the "best
> students" are concerned. I would expect that the best students would be
> the ones receptive to a more academic approach. They should certainly
> understand the argument that the fundamental ideas behind programming
> are much more important than the current "langue du jour", especially if
> the professors point out that five years ago nobody would have thought
> of teaching Java.
> In any case, I doubt that MIT has to fear losing their best students to
> some nearby Java mill (Harvard? :) just because they use SICP.
Sure. There is a small number of potential students who really do have an
intellectual interest in computer science and understand right from the start
the importance of doing more than looking at current technology. But in my
experience that number really is very small - you might get one or two,
half a dozen at the very most, in your computer science class. OK, so let's
call these the "very bext" students - we'd all like to fill our classes with
them but there aren't enough to go round.
So by "the best", I don't mean these. I mean students who are bright, have
good maths and reasoning skills, good grades at school, and probably some
experience of programming. They're going to do fine once they get to your
class, and they'll do a whole lot better than the medium-grade students
you'll have to fill up with if they go elsewhere. But they're rather naive
about what computer science actually involves, and their heads are filled
with the stuff from the glossy computer hobby or business magazines they
read. They *think* they know it all, but their judgement is superficial.
These are the sort likely to be attracted by the claims "we teach the language
they use in industry" - and remember choice of university is often made on
a very superficial basis.
I teach in London, so our local equivalent to MIT is Imperial College. That's
recognised as the to place to go, and because of that it can get away with
teaching what it thinks is best. But there's close competition amongst a
number of university institutions within a few miles of each other for the
students who haven't quite managed a place at Imperial. The language used
for initial teaching certainly *is* an issue - one I was constantly asked
by applicants, and the answer they wanted to hear was certainly not a language
used only by academics that never made an appearance in their glossy magazines.
The question "what language do you teach in?" is asked less often now, but
only because nearly everywhere seems to have settled on Java.
Matthew Huntbach
Matthew M. Huntbach
> m...@dcs.qmw.ac.uk (Matthew M. Huntbach) writes:
> > In Computer Science we have the
> >additional factor that twenty years ago, students coming in to do a degree
> >in the subject probably wouldn't have touched a computer before, and wouldn't
> >have had much idea about the subject. Now most potential students at least
> >*think* they know about the subject, and think it's all about training in
> >current popular systems.
> I think this is all the more reason to teach SICP. These days nearly
> everyone who wants to study CS has already taken a programming course
> in some C-like language, so why just give them more of the same?
Because, at least in my experience, any programming they've done before
university is likely to be very trivial - of the level we cover in the
first half of the first semester of the introductory programming course.
I find that many applicants to our CS degree claim to have extensive
programming experience, but that is not borne out by results in tests,
coursework and exams. The problem is they *think* the little bit of
programming they've done makes them experts.
> Also, all the people who've said things like "how many Lisp jobs are there"
> are, imho, missing the point. We're not in the business of teaching
> programming languages, and SICP is not a course about Scheme. We've taught
> Scheme by the end of the first week; other than that, we're teaching ideas
> that will be valuable no matter what language you use.
Sure. I always make the point that if the Computer Science degree I did
was just on what was superficially considered "relevant" then, I'd have
done nothing but Cobol on IBM mainframes.
> It's true that students don't always see that. Once when I was teaching
> our second (data structures) course, back when it was in C, I gave this
> exam question: given a binary search tree, and two numbers as lower and
> upper bounds, return a linked list of all the numbers in the tree that
> are between the bounds, without wasting comparisons. Nobody got it right.
> So in class the next day I asked them to write it in Scheme, and about
> half of them could do that. So I wrote the Scheme procedure on the board,
> and next to it I wrote the same algorithm in C, and they were all amazed.
> Because they were programming in C, they thought they weren't allowed to
> use recursive functions -- real programmers don't etc. Sigh. But at
> least that particular bunch of students ended up getting the point.
Strange - I wonder where this attitude comes from? It certainly suggests
they've been badly miseducated, and underlines the point I made first.
When I taught in C, I always made a point of introducing recursion as
early as possible, and not making a big fuss about it. Not using recursion
for anything involving trees is just being perverse.
Matthew Huntbach
Matthew M. Huntbach
> In comp.lang.functional Matthew M. Huntbach <m...@dcs.qmw.ac.uk> wrote:
> : ...we teach mostly Java. This despite the fact that there's a lot
> : wrong with Java and the *ideal* language for teaching might well be
> : something else. At the moment, there's enough Java hype around for
> : using it for teaching to be a selling point. But if Java never
> : really takes off with industry, I can see it getting categorised as
> : an "academic language" and a reluctant return to teaching in (the
> : even worse) C++.
> Have you seen the book _A Little Java, A Few Patterns_ (or something
> like that?)
Yes, I've seen it, but I think it would go over the heads of most
students just coming into a CS degree. Good "extra reading" maybe, but I
wouldn't want to use it as the class textbook.
Matthew Huntbach
Craig Dickson
>Brian Harvey (b...@anarres.CS.Berkeley.EDU) wrote:
>> It's true that students don't always see that. Once when I was teaching
>> our second (data structures) course, back when it was in C, I gave this
>> exam question: given a binary search tree, and two numbers as lower and
>> upper bounds, return a linked list of all the numbers in the tree that
>> are between the bounds, without wasting comparisons. Nobody got it right.
>> So in class the next day I asked them to write it in Scheme, and about
>> half of them could do that. So I wrote the Scheme procedure on the board,
>> and next to it I wrote the same algorithm in C, and they were all amazed.
>> Because they were programming in C, they thought they weren't allowed to
>> use recursive functions -- real programmers don't etc. Sigh. But at
>> least that particular bunch of students ended up getting the point.
>
>Strange - I wonder where this attitude comes from? It certainly suggests
>they've been badly miseducated, and underlines the point I made first.
>When I taught in C, I always made a point of introducing recursion as
>early as possible, and not making a big fuss about it. Not using recursion
>for anything involving trees is just being perverse.
I have a vague memory of reading, as a teenager (circa 1980), some
C-oriented programming text which advised that recursion should be used
with caution due to the danger of overflowing the stack. This sort of thing
is probably the origin of the "don't recurse in C" attitude.
Craig
Olof Oberg
of student that will be applying to the BSc C++ programs.
A hearty second on that motion. My class is using this
bullshit language called Haskell, and all the book or
prof can do is sing the praises of functional programming...
Phui! More like non-functional programming. My professor
got her doctorate in Math, which might explain why the
Official Coding Style Which Must Not Be Deviated From
really strikes wrong notes against my organic, perl-lovin'
hacker brain... I thought the point of programming was
solving the problem, not how you solved it or in what
language. :( Someone please firebomb the CS faculty here
and save me teh trouble.
I don't think that is a loss for computer science though.
/mill - which, ironically, happens to have to Perl as his favorite
language
PS. AFAIK no mandatory courses use C++ here. Java replaced
Pascal as the first imperative language, but I see that as
a GoodThing(tm) DS.
--
#############################################################
# mil...@SPAMludd.luth.se # http://pedgr571.sn.umu.se/~mill #
#############################################################
Jeff Dalton
> > I think it is a great pity that the academic world seems
> > to have caved into the pragmatism dictated by industry and teaches
> > courses on C++, Java, etc.
> I think part of the reason for this is because students these days are a
> lot less willing to take "what is good for them". Twenty years ago students
> were probably less demanding and more willing to take on trust what they
> were told by their professors in general. [...]
It seems to be a fairly general phenomenon these days for students
to have definite ideas of what software etc they want. For instance,
I know of places where students pretty much demand Word for document
preparation.
In a way, this is a "rational" (as in utility-maximising), pragmatic,
attitude for them to have. They may already be using Word, C++, Java,
etc, or else expect that they will be using them when they leave
university; and so using those things as students will be easier,
if they're already using them, and will save time later even if
they're not. And surely it's possible to teach good courses using
any reasonable language. So a requirement that they use some other
tools, especially unusual ones such as functional languages, may
seem objectionable on a number of grounds.
Why should students have to enter the job market with any
unnecessary disadvantages?
Moreover, it's not so easy these days to just pick up a new language
when it's needed for work or whatever, if the new language happens to
be C++ or Java, because both of those languages are, in effect, huge.
C++ is a fairly large language anyway, but to use it effectively you
also need to learn which of the very many possible ways of doing
things are good. This is a greater problem for C++ than for almost
any other language. Java is simpler as a language, but then there
are these huge libraries of classes with many things being done in
elaborate, sometimes overengineered, ways. And nowadays a competent
Java programmer may be expected to know Swing, Beans, and several
other things that didn't even exist when Java started out and whose
names I can't even remember right now.
Java and C++ aren't just languages; they're worlds. Which will seem
more important to a student who plans a career in industry: learning
and using an obscure functional language that they'll probably never
use again, or learning and using the language that will let them write
"enterprise" applications using Beans, CORBA, etc.? Time spent on
Haskell or Scheme is time not spent on exploring (or getting ready to
explore) more of the ever-growing Java world. And if the CS
fundamentals are really so fundamental, and the theory so generally
useful, then surely those things can be studied and explored using
whatever language one prefers. There can, after all, be a course on
principles of programming languages, or something along those lines,
to tell students about programming languages of other kinds.
It's easy to underestimate the current dominance of Java and C++.
Wasn't the situation the same in the past (maybe even still) with
FORTRAN and COBOL? No. C++ and Java are "colonising" areas that
FORTRAN and COBOL hardly touched. For instance, I've been able to
pretty much ignore FORTRAN and COBOL for my entire programming career,
but right now I'll find it hard to escape Java if I want to keep
programming. I know it's *possible* escape, but I'm not free to
rework my whole life (again) around which programming language I use.
Indeed, I daily thank Java for saving me from the horrors of C++.
Don't get me wrong. I hope the C++ and Java-shaped forces of darkness
can be defeated and CS rescued from their fell grasp, and I wasn't
entirely serious in making the case I presented above. But I don't
think students are all that unreasonable in wanting to use Java or
C++ in courses. There are some realities behind that desire that
only students planning an academic CS career can easily ignore.
Note that the issue should not be dismissed as one of teaching ideas
and fundamentals vs teaching particular languages and tools. If the
ideas etc are valuable no matter what language one uses, that cuts
both ways so far as language choice is concerned. If those things are
(largely) language-independent, then surely it's *other* factors,
and not the desire to teach science rather than tools, that should
determine language choice.
-- jd
bhal...@hotmail.com
Scott Ribe <sr...@miqs.com> wrote:
>
>
> "Thomas A. Russ" wrote:
> >
> > I think this is a gross overstatement, as least insofar as the "best
> > students" are concerned. I would expect that the best students
would be
> > the ones receptive to a more academic approach. They should
certainly
> > understand the argument that the fundamental ideas behind
programming
> > are much more important than the current "langue du jour",
especially if
> > the professors point out that five years ago nobody would have
thought
> > of teaching Java.
> >
> > In any case, I doubt that MIT has to fear losing their best
students to
> > some nearby Java mill (Harvard? :) just because they use SICP.
>
> students". Thus MIT and a small handful of select institutions can use
> whatever the hell they want for pedagogic purposes, and thus pursue
> their goal of turning out engineers who really understand computer
> other 99% of academic programs must use some other marketing
technique,
> since "this is MIT" only works for MIT ;-)
>
going
> all the way to the "Learn VBA in 21 days" kind of sludge.
>
Scott catches my frustration (& that is what it is!!)
very well with phrases like "Java mill" & "sludge".
Vasili
> Scott Ribe
>
> 6-3 '85 BTW ;-)
>
bhal...@hotmail.com
b...@anarres.CS.Berkeley.EDU (Brian Harvey) wrote:
> m...@dcs.qmw.ac.uk (Matthew M. Huntbach) writes:
> >additional factor that twenty years ago, students coming in to do a
degree
> >in the subject probably wouldn't have touched a computer before, and
wouldn't
> >have had much idea about the subject. Now most potential students at
least
> >*think* they know about the subject, and think it's all about
training in
> >current popular systems.
>
> I think this is all the more reason to teach SICP. These days nearly
> everyone who wants to study CS has already taken a programming course
> in some C-like language, so why just give them more of the same?
>
there"
> are, imho, missing the point. We're not in the business of teaching
> programming languages, and SICP is not a course about Scheme. We've
taught
> Scheme by the end of the first week; other than that, we're teaching
ideas
Exactly!! That is why I started this thread. Industry is very
dumbed down (I am in it!). One poplular thing with some companies
are C or C++ tests to test one's skills in these lamguages. These
will ask some very esoteric properties (which in C++ is very
easy because C++ is not very orthogonal), seldom used features,
which if one really understands the problem to be solved, you would
just look up in a manual.
Another point is just industries unwillingness to adopt different
paradigm if it requires a little work gray matter. Here FPL's
come in. Probably FPL programmer doesn't have to be well grounding
in lambda calculus or combinatory algebra to write well, e.g.
I don't believe SICP mentions neither mathematical systems.
I am sorry for English. To me lambda calculus, combinatory
algebra, mathematical logic is beatiful, but not necessary
as evidenced in SICP. But certainly some things like higher
order functions (i.e. currying) that originate because FPL's are
lambda calculus with syntax sugar are something FPL's (& hence
reader of SICP!!) get for free!! Higher-order functions is
of course very powerful feature absent from C, C++, Java.
In related area, metaobject protocol came from CLOS, yes?? No in
Java, but in limited form.
Vasili
>
> It's true that students don't always see that. Once when I was
teaching
> our second (data structures) course, back when it was in C, I gave
this
> exam question: given a binary search tree, and two numbers as lower
and
> upper bounds, return a linked list of all the numbers in the tree that
> are between the bounds, without wasting comparisons. Nobody got it
right.
> So in class the next day I asked them to write it in Scheme, and about
> half of them could do that. So I wrote the Scheme procedure on the
board,
> and next to it I wrote the same algorithm in C, and they were all
amazed.
> Because they were programming in C, they thought they weren't allowed
to
> use recursive functions -- real programmers don't etc. Sigh. But at
> least that particular bunch of students ended up getting the point.
>
bhal...@my-deja.com
c...@best.com (Craig Dickson) wrote:
> Matthew M. Huntbach <m...@dcs.qmw.ac.uk> wrote:
>
> >Brian Harvey (b...@anarres.CS.Berkeley.EDU) wrote:
>
teaching
> >> our second (data structures) course, back when it was in C, I gave
this
> >> exam question: given a binary search tree, and two numbers as
lower and
> >> upper bounds, return a linked list of all the numbers in the tree
that
> >> are between the bounds, without wasting comparisons. Nobody got
it right.
> >> So in class the next day I asked them to write it in Scheme, and
about
> >> half of them could do that. So I wrote the Scheme procedure on
the board,
> >> and next to it I wrote the same algorithm in C, and they were all
amazed.
> >> Because they were programming in C, they thought they weren't
allowed to
> >> use recursive functions -- real programmers don't etc. Sigh. But
at
> >> least that particular bunch of students ended up getting the point.
> >
suggests
> >they've been badly miseducated, and underlines the point I made
first.
> >When I taught in C, I always made a point of introducing recursion as
> >early as possible, and not making a big fuss about it. Not using
recursion
> >for anything involving trees is just being perverse.
>
> I have a vague memory of reading, as a teenager (circa 1980), some
> C-oriented programming text which advised that recursion should be
used
> with caution due to the danger of overflowing the stack. This sort of
thing
> is probably the origin of the "don't recurse in C" attitude.
But do current C compilers (e.g. gcc) support "tail recursion"
optimization like Scheme standard dictates?? I would guess so.
Hence, if someone writes in tail recusion fashion, you avoid
problema.
Vasili
>
> Craig
bhal...@my-deja.com
Olof Oberg <mil...@SPAMludd.luth.se> wrote:
> Just read this post on slashdot.org. I guess this is the kind
> of student that will be applying to the BSc C++ programs.
>
> A hearty second on that motion. My class is using this
> bullshit language called Haskell, and all the book or
> prof can do is sing the praises of functional programming...
> Phui! More like non-functional programming. My professor
> got her doctorate in Math, which might explain why the
> Official Coding Style Which Must Not Be Deviated From
> really strikes wrong notes against my organic, perl-lovin'
> hacker brain... I thought the point of programming was
> solving the problem, not how you solved it or in what
> language. :( Someone please firebomb the CS faculty here
> and save me teh trouble.
>
> I don't think that is a loss for computer science though.
Unfortunately, I have many co-workers is EXACTLY SAME MENTALITY.
I mentioned to one co-worker that I want to see garbage collection
to be more ubiquituis because I am sick and tired of memory leaks
in multi-threaded environment. (Yes I know this is only tangentially
related to SICP!!!). His response "I want to control memory
allocation explicitly as in C, C++ because them I am in
control". I felt like to say to him "You are not in control!!
Because your software is famous (infamous??) for memory leaks!!"
Personally, I welcome industrial strengthh GC because I have too
many other problems to solve already!! I already have a hard to
just to keep my head above the water.
Vasili
>
> /mill - which, ironically, happens to have to Perl as his favorite
> language
>
> PS. AFAIK no mandatory courses use C++ here. Java replaced
> Pascal as the first imperative language, but I see that as
> a GoodThing(tm) DS.
>
> --
> #############################################################
> # mil...@SPAMludd.luth.se # http://pedgr571.sn.umu.se/~mill #
> #############################################################
>
bhal...@my-deja.com
In America, this is very common also.
>
> Perhaps that speaks to the still relative immaturity of computer
> science...?
>
Uffe, I disagree with you conclusion. It is rather the level of
education of technical managers. It is very dismal. I have found
in general that very software engineer do not want to be
manager. And they definitely have not read anything approaching
SICP.
As for Sweden ( and Europe), I have been suprised that a company
like Ericsson would use (and still use??) something Erlang
to do telephony instead of jumping on C bandwagon. I must give
them credit for this!!
Vasili
> /Uffe
> --
> Ulf Wiger, Chief Designer AXD 301
> Ericsson Telecom AB tfn: +46 8 719 81 95
> Varuvägen 9, Älvsjö mob: +46 70 519 81 95
> S-126 25 Stockholm, Sweden fax: +46 8 719 43 44
>
Brian Harvey
>Note that the issue should not be dismissed as one of teaching ideas
>and fundamentals vs teaching particular languages and tools. If the
>ideas etc are valuable no matter what language one uses, that cuts
>both ways so far as language choice is concerned. If those things are
>(largely) language-independent, then surely it's *other* factors,
>and not the desire to teach science rather than tools, that should
>determine language choice.
But different languages differ in the extent to which they obscure the
big ideas with syntax and with arbitrary restrictions (by which I guess
I mostly mean type declarations for variables).
In Java it's awfully hard to write a general higher-order function like MAP.
You can write versions for particular purposes (e.g., one for lists of
integers) but a language with LAMBDA and without strong typing makes it
much easier to present the core idea. *Then* you can talk about how to
use the idea in Java.
Well, okay, maybe functional programming is arcane and irrelevant to the
real world. But in Java it's also awfully hard to introduce the ideas of
OOP, which is supposed to be Java's strong point, because those ideas are
obscured in Java by things like security concerns (all that public/private
stuff for example). *After* you've seen the presentation of OOP in SICP,
then you can learn how to do the Java incantations.
Is this worth wasting a semester that could instead be spent on Java Beans?
Well, it's my impression that even the most pragmatic of students expect to
take a "comparative programming languages" course somewhere along the line.
All we're doing, it could be argued, is moving that course to the front
where it's most helpful to a student who'll end up taking a Java-based CS 2.
And making it intellectually deep, instead of just a "If today is Tuesday
this must be Belgium" sort of tour.
en...@cstp.umkc.edu
>Jeff Dalton <jeff@todday:
>
>Well, okay, maybe functional programming is arcane and irrelevant to the
>real world. But in Java it's also awfully hard to introduce the ideas of
>OOP, which is supposed to be Java's strong point, because those ideas are
>obscured in Java by things like security concerns (all that public/private
>stuff for example). *After* you've seen the presentation of OOP in SICP,
>then you can learn how to do the Java incantations.
I wouldn't necessarily call it arcane and irrelevant. I would say functional
programming is not in as much demand by employers in the current job market
as Java and C++ .
>
>Is this worth wasting a semester that could instead be spent on Java Beans?
>Well, it's my impression that even the most pragmatic of students expect to
>take a "comparative programming languages" course somewhere along the line.
>All we're doing, it could be argued, is moving that course to the front
>where it's most helpful to a student who'll end up taking a Java-based CS 2.
But I think if you go back to first post in this thread, the poster appeared
to be advocating doing away altogether with all but the functional languages.
I'll repost that post if I can find it. My point was that, although doing
so might turn out better programmers and computer scientists, it would be a
grave disservice to the student, the consumer of the education, who would not
meet the requirements of the larger market of employers, specifically those
who insist on knowledge of the ins and outs of C++ and Java rather than
functional languages. I absolutely agree with exposing future computer science
graduates to functioanl languages, but don't hold back on C++ and Java just
because they're not functional languages.
Scott Ribe
en...@CSTP.UMKC.EDU wrote:
>
> But I think if you go back to first post in this thread, the poster appeared
> to be advocating doing away altogether with all but the functional languages.
> I'll repost that post if I can find it. My point was that, although doing
> so might turn out better programmers and computer scientists, it would be a
> grave disservice to the student, the consumer of the education, who would not
> meet the requirements of the larger market of employers, specifically those
> who insist on knowledge of the ins and outs of C++ and Java rather than
> functional languages. I absolutely agree with exposing future computer science
> graduates to functioanl languages, but don't hold back on C++ and Java just
> because they're not functional languages.
I think C++ and Java should be severely demoted, down to the level of
optional seminars. Learn the real concepts first, without arbitrary
restrictions, and later you will be able to MUCH better understand C++
and Java and use them MUCH more effectively, using that understanding of
general principles.
We do not concentrate on teaching mechanical engineers the ins and outs
of a particular CAD program do we? We teach them general engineering
principles and put the CAD program in a strictly secondary supporting
role. We teach CAD programs to drafting technicians. And we understand
the difference.
Yet in "computer science" we don't seem to understand the difference
between engineers and technicians. Perhaps this is because, as someone
else pointed out, this is a young discipline. (This is not to demean
technicians. There is a real need for the technician's skills in all
disciplines. What is insane is that the difference has been so
obscured.)
Scott Ribe
Brian Harvey wrote:
>
> But different languages differ in the extent to which they obscure the
> big ideas with syntax and with arbitrary restrictions (by which I guess
> I mostly mean type declarations for variables).
Yes. But even better than type declarations, consider C++ where one can
have dynamic dispatch based on the runtime type of one argument (virtual
functions) or static call based on the compile time type of multiple
arguments (overloading). ***BLECH*** There is no good conceptual reason
why these two concepts should be intermixed in such a disgustingly
confusing and limited way. This kind of crap is forced in C++ and Java
by the requirement for backward compatibility with C, which in turn
forces a lot of crap because of the primitive state of compiler
technology back when C was created.
There is no reason in the 90's that developers should be doing work that
could be done by the compiler and/or the runtime. (Thus Java's primary,
perhaps only real, advantage over C++--garbage collection.)
There is a book, Learn to Program: C++ that is actually pretty decent.
But it is so utterly limited by C++. The convoluted syntax and bizarre
feature interactions take so much time and effort to explain and learn
that they nearly completely push out the real ideas.
There is only so much time in a semester. When you spend most of it on
bizarro syntactical constraints, you have precious little time left to
learn the more fundamental, and vastly more important, general concepts
of program structure.
> In Java it's awfully hard to write a general higher-order function like MAP.
> You can write versions for particular purposes (e.g., one for lists of
> integers) but a language with LAMBDA and without strong typing makes it
> much easier to present the core idea. *Then* you can talk about how to
> use the idea in Java.
So well stated.
> Well, it's my impression that even the most pragmatic of students expect to
> take a "comparative programming languages" course somewhere along the line.
> All we're doing, it could be argued, is moving that course to the front
> where it's most helpful to a student who'll end up taking a Java-based CS 2.
> And making it intellectually deep, instead of just a "If today is Tuesday
> this must be Belgium" sort of tour.
A much better approach indeed. Unless one has the goal of maximizing the
output of Java hacks!
Hartmann Schaffer
en...@CSTP.UMKC.EDU writes:
> ...
> I'll repost that post if I can find it. My point was that, although doing
> so might turn out better programmers and computer scientists, it would be a
> grave disservice to the student, the consumer of the education, who would not
> meet the requirements of the larger market of employers, specifically those
> who insist on knowledge of the ins and outs of C++ and Java rather than
> functional languages. I absolutely agree with exposing future computer science
> graduates to functioanl languages, but don't hold back on C++ and Java just
> because they're not functional languages.
this is only true as long as the potential employers don't realize that
by picking people who are trained for coding in a particular language
are inferior to those who have been exposed to CS concepts
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
Lynn Winebarger
>> I have a vague memory of reading, as a teenager (circa 1980), some
>> C-oriented programming text which advised that recursion should be
>used
>> with caution due to the danger of overflowing the stack. This sort of
>thing
>> is probably the origin of the "don't recurse in C" attitude.
> But do current C compilers (e.g. gcc) support "tail recursion"
>optimization like Scheme standard dictates?? I would guess so.
>Hence, if someone writes in tail recusion fashion, you avoid
>problema.
>
gcc does optimize tail recursion. but not all algorithms that are
easy to express recursively are easy to express tail-recursively.
Though continuation passing style is an interesting topic, it's not
something I would expect beginning programmers to know.
Lynn
bhal...@my-deja.com
This reminds me other books I have and have
read besides SICP. It is "Essentials of
Scheme Programming". There are two books that
have similar covers. Anyway both I would say
(in spite of title) are somewhat like SICP in
that their goal is to teach more than Scheme,
i.e. computer science principles. E..g book
I mentiomed above teaches about CPS!!! This
book (maybe by Friedman) is meant maybe not
for freshman, but still undergraduate!
Vasili
> Lynn
bhal...@my-deja.com
Scott Ribe <sr...@miqs.com> wrote:
>
>
> en...@CSTP.UMKC.EDU wrote:
> >
> > But I think if you go back to first post in this thread, the poster
appeared
> > to be advocating doing away altogether with all but the functional
languages.
although doing
> > so might turn out better programmers and computer scientists, it
would be a
> > grave disservice to the student, the consumer of the education, who
would not
> > meet the requirements of the larger market of employers,
specifically those
> > who insist on knowledge of the ins and outs of C++ and Java rather
than
> > functional languages. I absolutely agree with exposing future
computer science
> > graduates to functioanl languages, but don't hold back on C++ and
Java just
> > because they're not functional languages.
>
> optional seminars. Learn the real concepts first, without arbitrary
> restrictions, and later you will be able to MUCH better understand C++
> and Java and use them MUCH more effectively, using that understanding
of
> general principles.
>
outs
> of a particular CAD program do we? We teach them general engineering
> principles and put the CAD program in a strictly secondary supporting
> role. We teach CAD programs to drafting technicians. And we understand
> the difference.
>
> Yet in "computer science" we don't seem to understand the difference
> between engineers and technicians. Perhaps this is because, as someone
> else pointed out, this is a young discipline. (This is not to demean
> technicians. There is a real need for the technician's skills in all
> disciplines. What is insane is that the difference has been so
> obscured.)
>
I think this wise email!
Vasili
bhal...@my-deja.com
h...@inferno.nirvananet (Hartmann Schaffer) wrote:
> In article <7stvik$886$1...@ns3.umkc.edu>,
> en...@CSTP.UMKC.EDU writes:
> > ...
although doing
> > so might turn out better programmers and computer scientists, it
would be a
> > grave disservice to the student, the consumer of the education, who
would not
> > meet the requirements of the larger market of employers,
specifically those
> > who insist on knowledge of the ins and outs of C++ and Java rather
than
> > functional languages. I absolutely agree with exposing future
computer science
> > graduates to functioanl languages, but don't hold back on C++ and
Java just
> > because they're not functional languages.
>
that
> by picking people who are trained for coding in a particular language
> are inferior to those who have been exposed to CS concepts
>
manager is idiot!!
Vasili
> --
>
> Hartmann Schaffer
>
> It is better to fill your days with life than your life with days
>
Lynn Winebarger
> This reminds me other books I have and have
> read besides SICP. It is "Essentials of
> Scheme Programming". There are two books that
"Essentials of Programming Languages" by Friedman.
> have similar covers. Anyway both I would say
> (in spite of title) are somewhat like SICP in
> that their goal is to teach more than Scheme,
> i.e. computer science principles. E..g book
> I mentiomed above teaches about CPS!!! This
> book (maybe by Friedman) is meant maybe not
> for freshman, but still undergraduate!
Yeah, actually I took intro to programming languages from Friedman
last year. A fun class. Probably the best lecturer I've had (OTOH he
seems to be a prof people either love or hate).
Lynn
Mike Thomas
> manager is idiot!!
Hey...
Mike Thomas
Administration Manager - Brisbane
Paradigm Geophysical
Fergus Henderson
>In article <7su2e4$pbb$1...@nnrp1.deja.com>, <bhal...@my-deja.com> wrote:
>>> I have a vague memory of reading, as a teenager (circa 1980), some
>>> C-oriented programming text which advised that recursion should be used
>>> with caution due to the danger of overflowing the stack. This sort of thing
>>> is probably the origin of the "don't recurse in C" attitude.
>That, and that recursion is not optimized in C.
>
>> But do current C compilers (e.g. gcc) support "tail recursion"
>>optimization like Scheme standard dictates?? I would guess so.
>>Hence, if someone writes in tail recusion fashion, you avoid
>>problema.
>
>gcc does optimize tail recursion.
In some special cases, yes, but in many cases it doesn't.
For example, as of version egcs-1.1.2, it still won't
optimize the tail recursion in either of the following functions.
void foo() {
foo();
}
int baz() {
char unused[20];
return baz();
}
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Peter Hancock
> this is only true as long as the potential employers don't realize that
> by picking people who are trained for coding in a particular language
> are inferior to those who have been exposed to CS concepts
I think something important is being overlooked in this thread. The
ability to "code" is only a part of what you need to be productive in
any real job in a computer company. Thing like business sense, a good
appreciation of customer problems, the ability to schedule, to
communicate effectively, etc etc can be just as important, as I think
most people will agree if they think about it for a momemnt. There's
something else too, more on the "technical" side, which you might call
ingenuity, or creativity. I doubt that this can be taught; but not
everything that is important can be taught, unfortunately.
--
Peter
Matthew M. Huntbach
> In Java it's awfully hard to write a general higher-order function like MAP.
> You can write versions for particular purposes (e.g., one for lists of
> integers) but a language with LAMBDA and without strong typing makes it
> much easier to present the core idea. *Then* you can talk about how to
> use the idea in Java.
I wouldn't say it's "awfully" hard. In fact, showing how you do MAP in Java
is a good exercise in demonstrating aspects of the language. But it helps
if you're demonstrating it to people who've already seen MAP in a
functional language, then what you're trying to do in Java will be easier
to grasp.
How you do it in Java involves making an interface for the type "list of
Objects" (which may be implemented by lists of more specific objects),
and an interface for an object type which has a general one-to-one
method, which again can be implemented by something more specific.
Matthew Huntbach
Matthew M. Huntbach
> > > I think it is a great pity that the academic world seems
> > > to have caved into the pragmatism dictated by industry and teaches
> > > courses on C++, Java, etc.
> > I think part of the reason for this is because students these days are a
> > lot less willing to take "what is good for them". Twenty years ago students
> > were probably less demanding and more willing to take on trust what they
> > were told by their professors in general. [...]
> It seems to be a fairly general phenomenon these days for students
> to have definite ideas of what software etc they want. For instance,
> I know of places where students pretty much demand Word for document
> preparation.
> In a way, this is a "rational" (as in utility-maximising), pragmatic,
> attitude for them to have. They may already be using Word, C++, Java,
> etc, or else expect that they will be using them when they leave
> university; and so using those things as students will be easier,
> if they're already using them, and will save time later even if
> they're not. And surely it's possible to teach good courses using
> any reasonable language. So a requirement that they use some other
> tools, especially unusual ones such as functional languages, may
> seem objectionable on a number of grounds.
Sure. I'm not myself saying we shouldn't teach in C++ or Java, though I
was replying to someone who was. Actually, I think C++ is a mess and I
wouldn't want to teach in it, but I do teach in Java and though the language
is by no means perfect, I find teaching in it works fine.
The real question here is whether the best thing is to start in an
industrial language right away, or train in some other language in which
certain important aspects of programming are made more apparent. As
I've said, you can do higher order programming in Java, but not with ease.
If you want students to see how a higher-order style can be useful,
maybe it helps first if they do a bit of programming in a language that
makes it easy.
> Why should students have to enter the job market with any
> unnecessary disadvantages?
Surely the claim is that a little experience of programming in a variety
of paradigms is an advantage rather than a disadvantage. I've found that
ways of thinking about programming in the obscure languages I research
into do actually help me when I write things in Java.
> Java is simpler as a language, but then there
> are these huge libraries of classes with many things being done in
> elaborate, sometimes overengineered, ways. And nowadays a competent
> Java programmer may be expected to know Swing, Beans, and several
> other things that didn't even exist when Java started out and whose
> names I can't even remember right now.
Sure, but maybe we should consider the ambiguity in "learning to program
in Java". We could parse it "learning to program (in Java)" or
"learning (to program in Java)". In the former, Java is incidental -
it happens to be the language we use, but our prime aim is to teach
all round programming skills. In the latter it's specifically to teach
Java skills. In the latter we might emphasise specific aspects of Java
such as Swing and Beans, but play down more general programming skills.
In the former, we're only going to use as much of the Java libraries as
we need to support general programming. When I teach in Java, I use as
little of the Java libraries as I can. The reason for this is that students
find it difficult to distinguish between important principles and
incidentals. I know if I were to make more extensive use of the Java
libraries, many of the students would think passing my course involved
knowing the names of twenty different methods in twenty different libraries,
and would probably spend their time memorising them rather than writing
programs which actually developed basic programming skills.
> Java and C++ aren't just languages; they're worlds. Which will seem
> more important to a student who plans a career in industry: learning
> and using an obscure functional language that they'll probably never
> use again, or learning and using the language that will let them write
> "enterprise" applications using Beans, CORBA, etc.?
Well, okay, but if I'd have spent my time during my CS degree doing
what was considered "industrially relevant" then, I'd be an expert on
arcane details of Cobol and IBM mainframe operating systems.
> Don't get me wrong. I hope the C++ and Java-shaped forces of darkness
> can be defeated and CS rescued from their fell grasp, and I wasn't
> entirely serious in making the case I presented above. But I don't
> think students are all that unreasonable in wanting to use Java or
> C++ in courses. There are some realities behind that desire that
> only students planning an academic CS career can easily ignore.
Agreed. But I think students can often be very naive about what is
"relevant" and too ready to dismiss as "irrelevant" foundational material
which doesn't relate to what they read in the glossy magazines.
Matthew Huntbach
George Russell
and stretch my mind. Not because I thought I might earn more money
a few years later. Will someone tell me what happened to this idea?
Lars Lundgren
>
> In Java it's awfully hard to write a general higher-order function like MAP.
> You can write versions for particular purposes (e.g., one for lists of
> integers) but a language with LAMBDA and without strong typing makes it
> much easier to present the core idea.
Why on earth do you think that 'no strong typing' makes it easier to
present an idea? I would say the opposite!
If you find a particular type system being in the way when you try to
write a program, the natural conclusion is *not* that the type system is
to strong, it is rather that the type system is not expressive enough.
IMHO anyway.
(Actually, I do not really see why lambdas are essential either).
/Lars L
Matthew M. Huntbach
Computer Science is a university subject which suffers particularly from
the phenomenon of students who only see the degree as a way to a good job
and who have no willingness to learn for learning's sake. I'd rather teach
a student with low entrance qualification grades who wants to learn for
learning's sake than one with high grades who just sees it as a means to
an end, and the chances are the former will graduate with the better class
degree.
However, we just would not fill our classes if the only students we took in
were those motivated solely by intellectual curiosity. There just aren't
enough of that sort to go round. And if we didn't fill our classes, we'd be
out of a job.
Matthew Huntbach
George Russell
>
> George Russell (g...@informatik.uni-nospam-bremen.de) wrote:
>
> > I remember I went to university because I wanted to learn new things
> > and stretch my mind. Not because I thought I might earn more money
> > a few years later. Will someone tell me what happened to this idea?
> However, we just would not fill our classes if the only students we took in
> were those motivated solely by intellectual curiosity. There just aren't
> enough of that sort to go round. And if we didn't fill our classes, we'd be
> out of a job.
I think Matthew M. Huntbach has answered my question! All the same it
seems to me that Oxbridge/Ivy League universities should not have too much
difficulty finding enough students in England/the USA who are motivated
by intellectual curiosity and who are bright enough to do difficult
computer science. I suspect that in America maybe there are such students
but they mostly can't afford to pay Ivy League fees.
Simon Helsen
>in Java". We could parse it "learning to program (in Java)" or
>"learning (to program in Java)". In the former, Java is incidental -
>it happens to be the language we use, but our prime aim is to teach
>all round programming skills. In the latter it's specifically to teach
But can you really do that? Somebody said earlier in this thread that it
was a good move to change introductory courses from Pascal to Java. I
don't buy that. Java is (some kind of) superset of C and Pascal. You need
to be able to express problems and algorithms well in C before you can do
it in Java. But there is more. Java is an OO language from the very
beginning. So, if you start students to teach Java, you either need to
explain everything about OO or say things like "ignore the phrases
public class blabla {}" all the time, which is didactically very bad.
And this is the fundamental idea behind SICP: teach fundamental concepts,
algorithms, talk about complexity (most freshers who think they are good
programmers are seldom aware that some ways of coding are inherently
slower than others because of different complexity) etc. ok, perhaps CPS
is bit much to start with, but it ought to handled later on. And since a
student need hands-on practice, use a real language available on real
platforms with the following properties: as little syntax as possible, as
powerful as possible, as orthogonal as possible. Scheme seems to meet
these goals: you can program functionally, imperatively and even OO. It's
perhaps more difficult to program logically, but that can be treated in a
later course. One more very important advantage of Scheme is that you can
be almost sure that none of your students already knows it, so they are
all put at the same level. (I think it is important to treat students
equally and if you don't require them to know a language in advance this
is a good way making them equal).
As an example, there was an into course using Java at the former univ.
where I worked. The students had as homework to write the fibonacci
function, taking as input a number and printing the result. For many of
them this was hard since they were completely confused by Java's IO and OO
features. Most of them didn't even start on the actual problem, i.e.
coding the fibonacci function, and kept asking all sort of technical stuff
about Java.
I'm not saying languages like C,C++ or Java shouldn't be treated in a CS
degree. Only, you shouldn't start with them. Personally, I beleive that
one should first learn the fundamentals of programming a la SICP or even
better : Knuth, then learn about OO in general (not tied to any language)
and actually make the students design large OO projects without coding.
And finally, you could learn them to use all this stuff together, although
I'm pretty sure that if the two first steps went well, this last step is
redundant.
Students starting a university CS degree should be made aware that they
have to learn the technicallities of programming languages by themselves
and that the courses in the degree should make it a pleasure to do so.
regards,
Simon
Matthew M. Huntbach
> "Matthew M. Huntbach" wrote:
> > George Russell (g...@informatik.uni-nospam-bremen.de) wrote:
> > > I remember I went to university because I wanted to learn new things
> > > and stretch my mind. Not because I thought I might earn more money
> > > a few years later. Will someone tell me what happened to this idea?
> > However, we just would not fill our classes if the only students we took in
> > were those motivated solely by intellectual curiosity. There just aren't
> > enough of that sort to go round. And if we didn't fill our classes, we'd be
> > out of a job.
> I think Matthew M. Huntbach has answered my question! All the same it
> seems to me that Oxbridge/Ivy League universities should not have too much
> difficulty finding enough students in England/the USA who are motivated
> by intellectual curiosity and who are bright enough to do difficult
> computer science.
The term "Oxbridge" refers to just two of England's universities, ones that
are rather atypical compared with the rest. England has something like a
hundred universities. As the admissions tutor for the Computer Science
department in one that comes somewhere around the middle in most students'
rankings (of course we believe we ought to come near the top), I assure you
it's a very great struggle to find even that small number of students motivated
by intellectual curiosity necessary to make the teaching element of academic
life more than just drudgery.
Matthew Huntbach
Andrew Cooke
bhal...@hotmail.com wrote:
[...]One book I have come to admire greatly is
> "The Structure and Interpretation of Computer Programs"
> by Abelson, Sussman, & Sussman [...] the academic world seems
> to have caved into the pragmatism dictated by industry and teaches
> courses on C++, Java,
Surely the recent the book exists is *because* of courses teaching C++
etc - with no time to teach Lisp, a cut-down version was needed, hence
Scheme and the book. Hence also students flushed with enthusiams at
finding a nice language then wasting time re-inventing Lisp by adding
features back to Scheme.... all with half a smiley: .-,
Andrew
Jeffrey B. Siegal
Sci majors, with vastly differing goals and interests.
There is a huge demand for software developers, so many students are drawn to CS
as a career choice. But many of these students have little or no interest in
Computer Science as an academic discipline. Many would likely be better served
by an engineering, pure science or liberal arts degree along with enough part
time work experience to qualify them for a programming job, if that's what they
want. The number of programming jobs which require an actual CS degree, in
addition to or instead of demonstrated ability to write code, is really quite
small.
Or maybe those few students who are really interested in CS as an academic
discipline are the ones who shouldn't be there. They might be better served by
a math or engineering degree, deferring specialized CS work until graduate
school and leaving the undergraduate CS department serve the vocational-training
desires of those who want to be programmers, not computer scientists.
The underlying problem here is that no one really knows what Computer Science,
especially at the undergraduate level, is supposed to be. Perhaps time will
sort this out.
Matthew M. Huntbach
> Matthew Huntbach wrote:
> >Sure, but maybe we should consider the ambiguity in "learning to program
> >in Java". We could parse it "learning to program (in Java)" or
> >"learning (to program in Java)". In the former, Java is incidental -
> >it happens to be the language we use, but our prime aim is to teach
> >all round programming skills. In the latter it's specifically to teach
> But can you really do that? Somebody said earlier in this thread that it
> was a good move to change introductory courses from Pascal to Java. I
> don't buy that. Java is (some kind of) superset of C and Pascal. You need
> to be able to express problems and algorithms well in C before you can do
> it in Java. But there is more. Java is an OO language from the very
> beginning. So, if you start students to teach Java, you either need to
> explain everything about OO or say things like "ignore the phrases
> public class blabla {}" all the time, which is didactically very bad.
I think objects are a fundamental enough concept that they should be there
from the start when you learn to program. So I don't see "learning to
program (in Java)" as throwing out even the OO aspects of Java. But I do
see it as Java with a minimal use of the libraries that go with it.
Certainly no mention of the GUI stuff, for example. The OO aspects of Java
force the division into use of abstract data type and implementation of
abstract data type, whereas when you taught ADTs with C or Pascal you had
constantly to to stop students from using implementation details in
application (e.g. you'd get them to write a nice List ADT, but it was the
devil of a problem to stop them from writing applications which mixed this
with direct pointer manipulation). Java interfaces are a nice way to
enforce the abstraction message, and I recommend introducing them very
early on.
> As an example, there was an into course using Java at the former univ.
> where I worked. The students had as homework to write the fibonacci
> function, taking as input a number and printing the result. For many of
> them this was hard since they were completely confused by Java's IO and OO
> features. Most of them didn't even start on the actual problem, i.e.
> coding the fibonacci function, and kept asking all sort of technical stuff
> about Java.
It can be a bit of a barrier, yes. I just show them the pattern for reading
an integer in Java and say "just use this without worrying about what the
details mean".
> I'm not saying languages like C,C++ or Java shouldn't be treated in a CS
> degree. Only, you shouldn't start with them. Personally, I beleive that
> one should first learn the fundamentals of programming a la SICP or even
> better : Knuth, then learn about OO in general (not tied to any language)
> and actually make the students design large OO projects without coding.
I feel that if you don't give them OO from the start, they find the switch
into OO difficult.
Matthew Huntbach
Rolf-Thomas Happe
> gcc does optimize tail recursion. but not all algorithms that are
I'd guess that gcc (and most other C compilers) don't reach beyond
tail *self* call merging.
rthappe
Harvey J. Stein
It doesn't even do this much in general. The problem is that
pointers might alias. I've seen simple examples continue to grow the
stack.
As for functions calling each other being made tail recursive, this is
effectively prohibited by C calling conventions - namely that the
caller pushes & pops the stack. If the caller would push the stack &
the callee would pop the stack before returning then it'd be trivial
for the compiler to recognize that it's returning the result of a
function call so it can pop it's args, push the new fcns args and jump
to the new fcn.
There's some interest in giving gcc the ability to do this, as well as
writing a scheme front end. Anyone who's interested should get in
touch with the gcc maintainers and/or Richard Stallman.
--
Harvey Stein
Bloomberg LP
hjs...@bfr.co.il
Andrew Koenig
Andrew Cooke <and...@andrewcooke.free-online.co.uk> wrote:
>In article <7sp42b$71a$1...@nnrp1.deja.com>,
> bhal...@hotmail.com wrote:
>Surely the recent the book exists is *because* of courses teaching C++
>etc - with no time to teach Lisp, a cut-down version was needed, hence
>Scheme and the book.
No -- the book is actually earlier than C++.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Michael T. Richter
> Personally, I welcome industrial strengthh GC because I have
> too many other problems to solve already!! I already have a
> hard to just to keep my head above the water.
This was one of the issues which made me look for an alternative to C++. I
had always held the opinion, based on poor implementations, that GC was
intrinsically slow and punctuated. Then I picked up a book on the subject
and found out my opinions were about 15 years out of date. I started to
look around and picked Dylan as my next language of choice -- apparently
just in time to have the only commercial provider seemingly vanish:-(.
Lately I've stopped using Dylan, not because I want to stop using it, but
rather because I'm cramming functional programming into my head. I've
temporarily switched to using Haskell until I grok FP, after which I'll
switch back to Dylan. (Why did I switch to Haskell over Dylan to learn FP?
Because the best way to learn a paradigm is to be forced to use it. It's
too easy to slip out of FP mode with Dylan. I can't slip out of FP mode in
Haskell.)
--
Michael T. Richter <m...@ottawa.com> http://www.igs.net/~mtr/
"get a life. its a plastic box with wires in it."
-- Nadia Mizner <nad...@onthenet.com.au> (in private correspondence)
Michael T. Richter
news:37F29371...@miqs.com...
> Unless one has the goal of maximizing the output of Java hacks!
Most (albeit not all) university administrations have the goal of maximizing
the number of students they get. This is because students are the basis of
university funding.
en...@cstp.umkc.edu
>m...@dcs.qmw.ac.uk (Matthew M. Huntbach) writes:
>>additional factor that twenty years ago, students coming in to do a degree
>>in the subject probably wouldn't have touched a computer before, and wouldn't
>>have had much idea about the subject. Now most potential students at least
>>*think* they know about the subject, and think it's all about training in
>>current popular systems.
>
>I think this is all the more reason to teach SICP. These days nearly
>everyone who wants to study CS has already taken a programming course
>in some C-like language, so why just give them more of the same?
But isn't that like asking why teach Calculus II, III, IV, differential
equations, complex variables, etc. when the student has already had Calc I ?
Just because a student has taken "a programming course in some C-like
language", do you mean to say there is nothing more to be learned from building
on that course?
In my first programming course at UMKC, I had to write a simple
checking account processing program, about 100 lines of Pascal including
comments. Having already studied Fortran, Basic and PL/I , I think I wrote
that program in a couple hours and had it ready to turn in. Did that make me
an expert programmer? No. Did that suffice as a comprehensive study of
Pascal? Not nearly. Was it useful to my programming education to write
increasingly difficult programs, using more and more Pascal features, in
subsequent undergrad classes? Absolutely.
>
>Also, all the people who've said things like "how many Lisp jobs are there"
>are, imho, missing the point.
Interesting. Out here in the real world, as opposed to academia, that is very
much the point. Unless one plans to remain in the academic world, where maybe
it doesn't matter if you can program in a language that is widely used,
prospective employers want to see knowledge of specific languages and tools on
your resume. I'm not saying people with functional language knowledge to the
exclusion of C++ are not better programmers and I'm not saying they won't get
jobs when they graduate. In a hiring process in which C++ and Java knowledge
is required, something which is more often true than not, lack of that
knowledge is a significant handicap.
>We're not in the business of teaching
>programming languages, and SICP is not a course about Scheme. We've taught
>Scheme by the end of the first week; other than that, we're teaching ideas
>that will be valuable no matter what language you use.
>
>It's true that students don't always see that. Once when I was teaching
>our second (data structures) course, back when it was in C, I gave this
>exam question: given a binary search tree, and two numbers as lower and
>upper bounds, return a linked list of all the numbers in the tree that
>are between the bounds, without wasting comparisons. Nobody got it right.
>So in class the next day I asked them to write it in Scheme, and about
>half of them could do that. So I wrote the Scheme procedure on the board,
>and next to it I wrote the same algorithm in C, and they were all amazed.
>Because they were programming in C, they thought they weren't allowed to
>use recursive functions -- real programmers don't etc. Sigh. But at
>least that particular bunch of students ended up getting the point.
And this is an excellent example of why it's important to get real-world
language experience in school. Suppose the shoe was on the other foot, so to
speak, and these students were taught exclusively in Scheme, and they never saw
the C language during their school tenure. Now, they graduate and out go their
resumes with no mention of C on them. Immediately, they're eliminated from
consideration for all jobs requiring C. They get a console operator job or a
tape monkey job and work their way up to a programming job. The first day, the
manager comes in and says he needs a program, written in C, to do exactly what
your exam question asked. The former student could write it in Scheme with
both hands tied behind his back, but having no experience with C, he can't even
get close to what he's been asked to do. He winds up having to go back to
junior college to take CS-101 C programming in order to advance his career.
Craig Dickson
>Surely the recent the book exists is *because* of courses teaching C++
>etc - with no time to teach Lisp, a cut-down version was needed, hence
>Scheme and the book.
Not at all. Scheme was invented in the mid-70s with the goal of reducing
Lisp to its essentials. The idea was not to make Lisp easier to learn so
much as to narrow its focus, concentrating on what we now call functional
programming.
I'm not sure exactly when the first edition of SICP came out, but I'm sure
it predates the enormous popularity of C++ and Java by several years.
Craig
Scott Ribe
en...@CSTP.UMKC.EDU wrote:
>
> Interesting. Out here in the real world, as opposed to academia, that is very
> much the point. Unless one plans to remain in the academic world, where maybe
> it doesn't matter if you can program in a language that is widely used,
> prospective employers want to see knowledge of specific languages and tools on
> your resume. I'm not saying people with functional language knowledge to the
> exclusion of C++ are not better programmers and I'm not saying they won't get
> jobs when they graduate. In a hiring process in which C++ and Java knowledge
> is required, something which is more often true than not, lack of that
> knowledge is a significant handicap.
Well, I'm not an academic and I didn't find that to be true at all.
Maybe I just sought out smarter companies ;-)
> And this is an excellent example of why it's important to get real-world
> language experience in school. Suppose the shoe was on the other foot, so to
> speak, and these students were taught exclusively in Scheme, and they never saw
> the C language during their school tenure. Now, they graduate and out go their
> resumes with no mention of C on them. Immediately, they're eliminated from
> consideration for all jobs requiring C. They get a console operator job or a
> tape monkey job and work their way up to a programming job. The first day, the
> manager comes in and says he needs a program, written in C, to do exactly what
> your exam question asked. The former student could write it in Scheme with
> both hands tied behind his back, but having no experience with C, he can't even
> get close to what he's been asked to do. He winds up having to go back to
> junior college to take CS-101 C programming in order to advance his career.
Hmm. I graduated with absolutely no C experience (was taught exclusively
in Scheme and CLU) and went straight into a very nice job developing
software in C. Spent a half day with K&R and within a week was a better
C programmer than the high-priced consultants the company had been using
previously. (I wasn't a great C programmer yet; I wasn't even the best
in that small company; but I sure as heck was better than most!)
If the student in your example had any kind of real *software
engineering* or *computer science* education, he certainly wouldn't need
to go to junior college to pick up C programming. That is the point
we're talking about, and the point that you seem to be missing or
ignoring--having well learned the principles of computer science, one is
prepared to quickly and readily (sometimes even trivially) pick up any
new language completely on one's own. This is an extraordinarily
valuable skill, as it allows one to have a *long* career that outlasts
any current hiring fad. This is a skill that "Java mills" and their ilk
absolutely do not and can not teach.
Scott Ribe
"Michael T. Richter" wrote:
>
> This was one of the issues which made me look for an alternative to C++. I
> had always held the opinion, based on poor implementations, that GC was
> intrinsically slow and punctuated. Then I picked up a book on the subject
> and found out my opinions were about 15 years out of date. I started to
> look around and picked Dylan as my next language of choice -- apparently
> just in time to have the only commercial provider seemingly vanish:-(.
I think that in addition to the fact that older gc implementations were
slower and not incremental (and running on slower hardware), there is
something else at work.
Languages that have gc also tend to have more sophisticated and
expensive method dispatch or procedure calling mechanisms, more
abstraction layers between the API you're using and the underlying data
structures, sometimes a VM instead of native code, more heap allocations
(maybe exclusively) instead of stack allocations, object or API wrappers
and supporting data added to primitive types, and at least in the case
of Java security-checking overhead. It seems that somehow gc often gets
blamed for the cumulative performance hit from all these mechanisms.
It seems to me that where performance is an issue, maybe we should add
gc and forget all the others. Because gc would give the biggest boost in
productivity of developers and in the reliability of the end product. Of
course, it would be nice to realize the Dylan goal and have all the
goodies AND good performance ;-)
Craig Dickson
>Suppose the shoe was on the other foot, so to
>speak, and these students were taught exclusively in Scheme, and they
>never saw the C language during their school tenure.
I think this is a straw man -- nobody is suggesting that students NOT be
taught C, C++, Java, or whatever language is currently flavor-of-the-month.
What some of us object to is the idea that students should be allowed to
study ONLY those languages.
Knowing the currently-popular languages is important for getting a job, but
anyone who has only (or primarily) those languages will have a narrow view
of programming as a discipline and will be less able to adapt the next time
some new language or paradigm comes of age.
Languages are incidental to programming. A language is merely a tool.
Knowing a language, even knowing it well, does not make one a good
programmer. The goal of a university should be to turn out good programmers
who, among the others skills they have learned, are fluent in the languages
currently in demand by industry. So those languages should certainly be
taught, but not necessarily in the first year of undergraduate study, and
certainly not to the exclusion of all others.
Craig
WIldHeart'99
<bhal...@my-deja.com> wrote in message news:7sug1c$316$1...@nnrp1.deja.com...
> > Yet in "computer science" we don't seem to understand the difference
> > between engineers and technicians. Perhaps this is because, as someone
> > else pointed out, this is a young discipline. (This is not to demean
> > technicians. There is a real need for the technician's skills in all
> > disciplines. What is insane is that the difference has been so
> > obscured.)
Well... I would add a third group: developers. They are not engineers, nor
technicians: they are the physicists of computer science. The people who
create and understand.
Yes, I happen to be a physicist converted to computer science. :-))
--
WildHeart'99
Homepage: http://www.insight.dk/stf/
WIldHeart'99
<bhal...@my-deja.com> wrote in message news:7sug49$31r$1...@nnrp1.deja.com...
> > this is only true as long as the potential employers don't realize
> that
> > by picking people who are trained for coding in a particular language
> > are inferior to those who have been exposed to CS concepts
This is only true as long as potential employers don't realise that by
picking people exposed to CS concepts risk to acquire useless theoreticians
who cannot complete a real project. For many many years, and probably it is
still true, anybody with a degree in computer science in Italy would not
find any real work, because his preparation made him/her completely useless
to solve any problem. I've heard students discussing for hours whether the
best way to write a program in Pascal to pick the odd numbers in a list
required a a linked list or some other inappropriate complex method of
storage. Possibly the situation is a bit better these days, yet people
trained to think (mathematicians, physicists, philosophers) are usually much
better suited to developing programs than computer scientists.
> >
> Unfortunately, this axiom is true. Always assume
> manager is idiot!!
Not if your manager (as in my case) is the best developer, by far, of the
team.
He is not particularly good at managing, but that's another matter. He
certainly knows how to distinguish a good developer from a bad one.
Simon Helsen
>speak, and these students were taught exclusively in Scheme, and they never saw
>resumes with no mention of C on them. Immediately, they're eliminated from
>consideration for all jobs requiring C. They get a console operator job or a
you beleive that yourself?
>tape monkey job and work their way up to a programming job. The first day, the
>manager comes in and says he needs a program, written in C, to do exactly what
>your exam question asked. The former student could write it in Scheme with
>both hands tied behind his back, but having no experience with C, he can't even
>get close to what he's been asked to do. He winds up having to go back to
>junior college to take CS-101 C programming in order to advance his career.
I disagree with this scenario. I think there are two points to make:
first, I simply don't beleive that industry is only seeking C/C++/VBA
programmers. Well, they might write it in their ad, but that is usually
not the only thing. More often, I read in the ads that they seek
programmers with good analytical skills (and this explains why they often
also take mathematicians and physicists). Yes, I suppose there are many
places where they want C/C++/VBA programmers, but then they give the
newbies time to get acquainted with those languages. This will be very
easy for the guy who learned solving program problems and learned about
program structures, concepts or programming languages fundamentals. If he
used incidentally Scheme for all this, he might still know how to solve
the problem conceptually as Scheme tends not to obscure the actual problem
in loads of syntax and difficult to understand concepts (Scheme was in
fact designed for this). I conjecture that the student who saw such
problems presented in C may have difficulties coding it again in C,
whereas a student using the general approach, is likely to be able to code
the problem in C, even though he may have never seen it in C before).
This is really what the SICP approach is all about: to make students less
aversive in learn new languages of any kind. And in the long term, this is
probably more productive for any company. But conservatism can be
notoriously hard to tackle...
regards,
Simon
David McClain
who has been acting as a computer scientist for nearly 20 years. But there
is much I don't know about. So could you please expand on your last comment
about not needing lambda's either?
Thanks,
David McClain
Lars Lundgren wrote in message ...
Hartmann Schaffer
hjs...@bfr.co.il (Harvey J. Stein) writes:
> ...
> As for functions calling each other being made tail recursive, this is
> effectively prohibited by C calling conventions - namely that the
> caller pushes & pops the stack. If the caller would push the stack &
this depends very much on the argument passing mechanism of the
implementation: if the compiler passes arguments in registers, the call
of most functions does not involve any stack manipulation. the only
thing that needs to be done by the caller is to release whatever stack
space it used and set things up so that the environment of the call
looks like it comes from the caller's caller (grand-caller?)
> ...
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
Hartmann Schaffer
"WIldHeart'99" <sla...@tin.it> writes:
> ...
> who cannot complete a real project. For many many years, and probably it is
> still true, anybody with a degree in computer science in Italy would not
> find any real work, because his preparation made him/her completely useless
> to solve any problem. I've heard students discussing for hours whether the
there was a period (i remember it too well) where many CS departments
taught some dogma bassed on whatever was rhe current vogue. in other
words, a degree in cs didn't guarantee knowledge of cs rather than
indoctrination in some methodology. fortunately, it never was trues for
all schools
bhal...@my-deja.com
something like SICP to teach people about computer science!
Then teach them C, C++, Java whatever for industry!
>
> In my first programming course at UMKC, I had to write a simple
> checking account processing program, about 100 lines of Pascal
including
> comments. Having already studied Fortran, Basic and PL/I , I think I
wrote
> that program in a couple hours and had it ready to turn in. Did that
make me
> an expert programmer? No. Did that suffice as a comprehensive study
of
> Pascal? Not nearly. Was it useful to my programming education to
write
> increasingly difficult programs, using more and more Pascal features,
in
> subsequent undergrad classes? Absolutely.
>
> >
> >Also, all the people who've said things like "how many Lisp jobs are
there"
> >are, imho, missing the point.
>
that is very
> much the point. Unless one plans to remain in the academic world,
where maybe
> it doesn't matter if you can program in a language that is widely
used,
> prospective employers want to see knowledge of specific languages and
tools on
> your resume. I'm not saying people with functional language
knowledge to the
> exclusion of C++ are not better programmers and I'm not saying they
won't get
> jobs when they graduate. In a hiring process in which C++ and Java
knowledge
> is required, something which is more often true than not, lack of that
> knowledge is a significant handicap.
>
See above!! And remember I have been in industry (read REAL WORLD)
for ~20 years!!! (Vasili)
^^^^ I know this is another post! You are talking about
expressibility of FPL's! I have glanced at Fielson's paper (Rice U.)
regarding an attempt to formalize the notion of expressibility!
> And this is an excellent example of why it's important to get real-
world
> language experience in school. Suppose the shoe was on the other
foot, so to
> speak, and these students were taught exclusively in Scheme, and they
never saw
> the C language during their school tenure. Now, they graduate and
out go their
^^^^^^^^^^^ I don't think anybody is suggesting teaching no
imperative languages such as C, C++! Just expose these young
innocent minds first to something like SICP. Again keep in
mind I work in industry, i.e. driver writer and multithreaded
server writer!!
Vasili
> resumes with no mention of C on them. Immediately, they're
eliminated from
> consideration for all jobs requiring C. They get a console operator
job or a
> tape monkey job and work their way up to a programming job. The
first day, the
> manager comes in and says he needs a program, written in C, to do
exactly what
> your exam question asked. The former student could write it in
Scheme with
> both hands tied behind his back, but having no experience with C, he
can't even
> get close to what he's been asked to do. He winds up having to go
back to
> junior college to take CS-101 C programming in order to advance his
career.
>
Fergus Henderson
>Lynn Winebarger:
>> gcc does optimize tail recursion. but not all algorithms that are
>
>I'd guess that gcc (and most other C compilers) don't reach beyond
>tail *self* call merging.
As the examples that I posted in another article show, gcc doesn't
even go that far. gcc doesn't do any optimization of last calls
except for directly recursive tail calls with an explicit `return'
(which is not normally there if the function return type is `void'),
and even then the optimization may be disabled if there are local
variables.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Hartmann Schaffer
Peter Hancock <p...@dcs.ed.ac.uk> writes:
> ...
> I think something important is being overlooked in this thread. The
> ability to "code" is only a part of what you need to be productive in
> any real job in a computer company. Thing like business sense, a good
> appreciation of customer problems, the ability to schedule, to
> communicate effectively, etc etc can be just as important, as I think
> most people will agree if they think about it for a momemnt. There's
> something else too, more on the "technical" side, which you might call
> ingenuity, or creativity. I doubt that this can be taught; but not
> everything that is important can be taught, unfortunately.
i would say the essential of programming is understanding problems and
the ability to come up with solutions. whether this is done directly by
the programmer or with some outside help (analyst) is immaterial.
coding is only a coincidental last step (slight overstatement)
bhal...@my-deja.com
"WIldHeart'99" <sla...@tin.it> wrote:
>
> <bhal...@my-deja.com> wrote in message news:7sug49
$31r$1...@nnrp1.deja.com...
>
> > > this is only true as long as the potential employers don't realize
> > that
> > > by picking people who are trained for coding in a particular
language
> > > are inferior to those who have been exposed to CS concepts
>
> This is only true as long as potential employers don't realise that by
> picking people exposed to CS concepts risk to acquire useless
theoreticians
it is
> still true, anybody with a degree in computer science in Italy would
not
> find any real work, because his preparation made him/her completely
useless
> to solve any problem. I've heard students discussing for hours
whether the
list
> required a a linked list or some other inappropriate complex method of
> storage. Possibly the situation is a bit better these days, yet people
> trained to think (mathematicians, physicists, philosophers) are
usually much
> better suited to developing programs than computer scientists.
>
> > >
> > Unfortunately, this axiom is true. Always assume
> > manager is idiot!!
>
> Not if your manager (as in my case) is the best developer, by far, of
the
> team.
in industry 20 years!
Vasili
> He is not particularly good at managing, but that's another matter. He
> certainly knows how to distinguish a good developer from a bad one.
>
> --
> WildHeart'99
> Homepage: http://www.insight.dk/stf/
>
>
bhal...@my-deja.com
Andrew Cooke <and...@andrewcooke.free-online.co.uk> wrote:
> In article <7sp42b$71a$1...@nnrp1.deja.com>,
> bhal...@hotmail.com wrote:
> > "The Structure and Interpretation of Computer Programs"
> > by Abelson, Sussman, & Sussman [...] the academic world seems
> > to have caved into the pragmatism dictated by industry and teaches
> > courses on C++, Java,
>
> etc - with no time to teach Lisp, a cut-down version was needed, hence
> finding a nice language then wasting time re-inventing Lisp by adding
> features back to Scheme.... all with half a smiley: .-,
>
> Andrew
Andrew,
If you consider the first edition of SICP, SICP is not
all that "recent"!! It was recent to teach principles of
comp sci., not to be a "smiley" face book! You must
also consider who the authors are.
Vasili
Brent A Ellingson
: But isn't that like asking why teach Calculus II, III, IV,
: differential equations, complex variables, etc. when the
: student has already had Calc I ?
The truth is, many of your math professors whince when they
realize that the above sequence is all most students ever
take of mathematics. There's a great deal of other mathematics
out there that isn't geared towards manipulating and solving
differential equations, and no small part of that mathematics
suddenly finds itself very, very useful since the invention
of computers.
Of course, I am certain that a discussion parallel to this
one sometimes exists on mathematics mailing lists. The
difference would be that the math professors are worried about
losing all the students who expect that diff. eq. is the only
thing to learn in mathematics (read "Electrical Engineering,
Physics, and Chemistry students").
--
Brent Ellingson (bell...@badlands.NoDak.edu)
"It is amazing how complete is the delusion that beauty is goodness."
-- Leo Tolstoy
Jeffrey B. Siegal
> Why should students have to enter the job market with any
> unnecessary disadvantages?
As I suggest elsewhere, the real question here is whether CS is supposed
to be job training. In more mature disciplines, people have a good idea
whether something is job training--it is pretty clear that a degree in
Nursing, Education, Broadcast Communications, etc. is job training, and
that a degree in mathematics, philosophy, etc. is (usually) not--in CS,
they don't.
> Note that the issue should not be dismissed as one of teaching ideas
> and fundamentals vs teaching particular languages and tools. If the
> ideas etc are valuable no matter what language one uses, that cuts
> both ways so far as language choice is concerned. If those things are
> (largely) language-independent, then surely it's *other* factors,
> and not the desire to teach science rather than tools, that should
> determine language choice.
This is a logical falacy (maybe you spent too much time in school
learning C++ :-). That it is the ideas and not the tools that are
important does not mean that all tools are equally good for conveying
the ideas.
Consider, by way of analogy, a history course conducted in a natural
language neither the teacher nor the student understand particularly
well. Surely, it is the historical facts and inferences which are the
important elements of a history course, not the lanugage of
instruction. But use the wrong language and these critical elements
will likely not be learned well, if at all.
Tony Finch
>
>I have a vague memory of reading, as a teenager (circa 1980), some
>C-oriented programming text which advised that recursion should be used
>with caution due to the danger of overflowing the stack. This sort of thing
>is probably the origin of the "don't recurse in C" attitude.
At the time of the Lions book C function calls were also absurdly
expensive compared to using a loop: apart from marshalling arguments
on the stack, there ware also a couple of machine-code subroutine
calls that bracketed each function to handle procedure call-frame
setup and teardown. This was all in the cause of compactness of object
code and the simplicity of the compiler, both of which are impossible
to avoid on a system with a 64K virtual address space.
This approach to compiling has been anachronistic for a long time now.
Tony.
--
f.a.n.finch d...@dotat.at fa...@demon.net e pluribus unix
Tony Finch
>
>Languages that have gc also tend to have more sophisticated and
>expensive method dispatch or procedure calling mechanisms, more
>abstraction layers between the API you're using and the underlying data
>structures, sometimes a VM instead of native code,
I think all of those points are wrong.
With a decent language implementation a function call should be no
less efficient than the processor's equivalent to BSR.
A decent language will alow you to construct an object no less
efficiently than writing the components into memory, and decompose it
no less efficiently than reading the components from memory.
For longer than a decade the "virtual machines" on which functional
language compilers are based have been essentially intermediate
languages. They remain in the object code as the basis for
manipulating data structures at run time, but the code iself is
machine code (or, from the point of view of the compiler writer, C
that would like to be assembly langiage).
>more heap allocations (maybe exclusively) instead of stack
>allocations,
A good heap allocator can be almost as efficient as a stack. The ML
Kit's region-based allocator basically boils down to a stack without
any additional expensive heap or GC systems.
>object or API wrappers
Languages without GC usually have these too, if you consider
real-world systems like X or MFC.
>and supporting data added to primitive types,
This can be compiled away.
>and at least in the case of Java security-checking overhead.
Has anyone worked out a good compile-time security checking system?
>It seems that somehow gc often gets blamed for the cumulative
>performance hit from all these mechanisms.
C++ has many of these problems but people still seem to think it is
efficient.
Christopher Browne
wrote:
>students were taught exclusively in Scheme, and they never saw the C
>language during their school tenure. Now, they graduate and out go
>eliminated from consideration for all jobs requiring C. They get a
>console operator job or a tape monkey job and work their way up to a
>programming job. The first day, the manager comes in and says he
>needs a program, written in C, to do exactly what your exam question
>asked. The former student could write it in Scheme with both hands
>tied behind his back, but having no experience with C, he can't even
>get close to what he's been asked to do. He winds up having to go
>back to junior college to take CS-101 C programming in order to
>advance his career.
If that student learned the principles of computer science, then
picking up a new language should merely represent a matter of picking
up a manual for this language and reading it to see how this funny new
language called C handles the abstractions that the student learned in
school.
C is a relatively simple language; it contains a relatively small
number of keywords and abstractions. Sure, there's lots of stuff in
the libraries; few people are expected to memorize that, as that's
what books and filesystems are good at holding and revealing on
demand.
ANSI C is a tad more complex than good 'ol K&R, but even so should not
present much of a challenge to a well-educated computer science major.
And if it *does,* then the poor ex-student evidently didn't learn from
his educational experiences, and is likely to be found unemployed as
soon as some new language comes out that doesn't conform exactly to
what was taught at school.
--
"I have never seen the inside of the building at Microsoft where the
top executives hang out, but I have this fantasy that in the hallways,
at regular intervals, big red alarm boxes are bolted to the wall. Each
contains a large red button protected by a windowpane. A metal hammer
dangles on a chain next to it. Above is a big sign reading: IN THE
EVENT OF A CRASH IN MARKET SHARE, BREAK GLASS." -- Neal Stephenson
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>
Tony Finch
>For example, as of version egcs-1.1.2, it still won't
>optimize the tail recursion in either of the following functions.
>
> void foo() {
> foo();
> }
>
> int baz() {
> char unused[20];
> return baz();
> }
In my IOCCC winner all functions were similar to
thing *func(some_arg) {
return foo ? 0 : structure->elem(another_arg);
}
AFAICT gcc didn't tail-call-optimise this case. I believe the Norcroft
C compiler (used for the ARM CPU) can tail-call-optimise it, but
unfortunately its register allocation algorithm cannot cope with the
750 K expression in main().
Tony Finch
>
>It seems to be a fairly general phenomenon these days for students
>to have definite ideas of what software etc they want. For instance,
>I know of places where students pretty much demand Word for document
>preparation.
>
>In a way, this is a "rational" (as in utility-maximising), pragmatic,
>attitude for them to have.
It seems excessively short-sighted to me, given the difference bettwen
successive versions of Word. The same is true for the language of the
year, which for the last decade seems to have been 10 variations on
the theme of C++ and Java.
The language is irrelevant; it is the ideas that are important, and
the lecturers should choose a language that is suited to expressing
the ideas they wish to teach.
Tony Finch
>
>I think C++ and Java should be severely demoted, down to the level of
>optional seminars. Learn the real concepts first, without arbitrary
>restrictions, and later you will be able to MUCH better understand C++
>and Java and use them MUCH more effectively, using that understanding of
>general principles.
In my degree the first year languages were ML and Modula-3. C turned
up in the second year, and it was left to the students to feed their
own curiosity about C++ and Java. I understand that Java has now
replaced Modula-3 in the curriculum.
Hartmann Schaffer
cbbr...@news.hex.net (Christopher Browne) writes:
> ...
> If that student learned the principles of computer science, then
> picking up a new language should merely represent a matter of picking
> up a manual for this language and reading it to see how this funny new
> language called C handles the abstractions that the student learned in
> school.
probably true, but it would be considerably simpler for somebody who had
been exposed to several languages
> ...
Christopher B. Browne
<h...@inferno.nirvananet> posted:
>In article <7wTI3.22672$%4.65...@news6.giganews.com>,
> cbbr...@news.hex.net (Christopher Browne) writes:
>> ...
>> If that student learned the principles of computer science, then
>> picking up a new language should merely represent a matter of picking
>> up a manual for this language and reading it to see how this funny new
>> language called C handles the abstractions that the student learned in
>> school.
>
>probably true, but it would be considerably simpler for somebody who had
>been exposed to several languages
Certainly true.
I'd hazard the guess that a student that had been exposed to Scheme,
Modula-3, and Objective CAML would have an easier time coping with C or
C++ a couple years later than a student that had only been exposed to
The Language Of The Year would have in coping with some newer Language
Of The Year.
--> All three languages would provide exposure to garbage collection,
which would provide better preparation for Java than knowing C++
would...
--> By seeing three object models, that likely provides more insight into
how profound OO is, and isn't, than merely seeing the class/subject
orientation of C++ or Java.
--> By seeing three different ways of parsing languages, the student
exposed to S/M/OC will understand the notion of parsing far better
than they would by seeing C++ and/or Java, where the compiler tools
are sufficiently complex that people only really look seriously
at how they parse them if they intend to create a new compiler
implementation, which stands well outside the scope of the typical
undergraduate degree.
--
"X is like pavement: once you figure out how to lay it on the ground
and paint yellow lines on it, there isn't much left to say about
it. The existing new developments are happening in things that run ON
TOP of the pavement, like cars, bicycles, trucks, and motorcycles."
-- Eugene O'Neil <eug...@cs.umb.edu>
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
Donald Welsh
<d95...@dtek.chalmers.se> wrote:
>On 29 Sep 1999, Brian Harvey wrote:
>
>> In Java it's awfully hard to write a general higher-order function like MAP.
>> You can write versions for particular purposes (e.g., one for lists of
>> integers) but a language with LAMBDA and without strong typing makes it
>> much easier to present the core idea.
>
>Why on earth do you think that 'no strong typing' makes it easier to
>present an idea? I would say the opposite!
Because with strong typing a higher-order function has to have types
declared for all of its parameters. With MAP, the only thing that
matters is that the type of the elements of the collection parameter
corresponds with the domain of the function parameter.
>If you find a particular type system being in the way when you try to
>write a program, the natural conclusion is *not* that the type system is
>to strong, it is rather that the type system is not expressive enough.
In Scheme, you don't have to write the lines of code specifying the
types taken by a function. (You also don't have to devise a phony
class and write an implementation separately from the interface, but
that wasn't what was asked.)
Do you want to have to write something like
map : [(t1 -> t2), list of t1] -> list of t2
as well as the definition of MAP? Would it really be clearer if you
did? Would it be easier to debug or maintain?
Aa I understand the term, strong typing also means that types t1 and
t2 above would have to be specific types; hence, the implementation of
MAP would not be the most general possible.
>(Actually, I do not really see why lambdas are essential either).
They allow creation of first-class procedures and nonce (single-use)
procedures. Very useful with higher-order functions.
David Lester
In article <37f445a1...@news.melbpc.org.au>, dwe...@nospam.melbpc.org.au
(Donald Welsh) writes:
> Do you want to have to write something like
>
> map : [(t1 -> t2), list of t1] -> list of t2
>
> as well as the definition of MAP? Would it really be clearer if you
> did? Would it be easier to debug or maintain?
Of course not.
What I want to do is type:
> map f xs = if null xs then [] else f (head xs) : tail xs
and have the compiler deduce that for all types "a" and "b", map has type:
> map :: (a -> b) -> [a] -> [b]
Which of course is exactly what happens (in the other window I have open)!
HTH
---
David Lester.
Lars Lundgren
> On Thu, 30 Sep 1999 11:50:25 +0200, Lars Lundgren
> <d95...@dtek.chalmers.se> wrote:
>
> >On 29 Sep 1999, Brian Harvey wrote:
> >
> >> In Java it's awfully hard to write a general higher-order function like MAP.
> >> You can write versions for particular purposes (e.g., one for lists of
> >> integers) but a language with LAMBDA and without strong typing makes it
> >> much easier to present the core idea.
> >
> >Why on earth do you think that 'no strong typing' makes it easier to
> >present an idea? I would say the opposite!
>
> Because with strong typing a higher-order function has to have types
> declared for all of its parameters. With MAP, the only thing that
> matters is that the type of the elements of the collection parameter
> corresponds with the domain of the function parameter.
>
If that is all that matters, then that is the only thing you should state
in the type. For example, the type of map with HM:
map :: (a -> b) -> [a] -> [b]
Please read this type carefully (I'll help you to interpret if you are
unfammiliar with the haskell syntax);
map is a function which takes a function from some type 'a' to some type
'b', and a list of a's and returns a list of b's.
Then read your own section about what
is needed from map carefully. The type says no more, and no less than your
informal statement about what matters!
> >If you find a particular type system being in the way when you try to
> >write a program, the natural conclusion is *not* that the type system is
> >to strong, it is rather that the type system is not expressive enough.
>
> In Scheme, you don't have to write the lines of code specifying the
> types taken by a function.
This is not needed in haskell (which has strong typing) either.
> (You also don't have to devise a phony
> class and write an implementation separately from the interface, but
> that wasn't what was asked.)
(And therefor I shall not comment that)
>
> Do you want to have to write something like
>
> map : [(t1 -> t2), list of t1] -> list of t2
>
> as well as the definition of MAP?
There is no need to, you can infeer the type, but it is generally good
practice to write the type.
> Would it really be clearer if you did?
Yes.
> Would it be easier to debug or maintain?
Yes.
Let me ask you a question. Do you think the the implementation of map
would be clearer and/or easier to debug or maintain if you documented
under what preconditions the function works, and what postconditions
should hold?
Writing the type is a very good way of stating the pre- and
postconditions. It is particularly good since the compiler then can
proofread your documentation automaticaly! The compiler answers questions
like: Is it really true that my stated postcondition always holds given
that the arguments satisfy the precondition?
> Aa I understand the term, strong typing also means that types t1 and
> t2 above would have to be specific types; hence, the implementation of
> MAP would not be the most general possible.
>
Then you have something to learn about the term. This is simply not true.
In a polymorphic type system t1 and t2 are specific type *variables*,
i.e. they can be instantiated to any type.
> >(Actually, I do not really see why lambdas are essential either).
>
> They allow creation of first-class procedures and nonce (single-use)
> procedures. Very useful with higher-order functions.
>
Yes, they are very useful, I agree, but I can not see why they are
essential to the problem at hand. What I think is essential is to be able
to create functions in-place. Lambdas is a good way to do that, but there
are other good ways too, like partial application and function composition
for example.
Some examples (without lambdas):
partial application:
map (*2) [1,2,3,4]
[2,4,6,8]
function composition: (.)
map (show.length) ["This","is","a","silly","sentence"]
["4","2","1","5","8"]
/Lars L
Tim Bradshaw
> Of course, I am certain that a discussion parallel to this
> one sometimes exists on mathematics mailing lists. The
> difference would be that the math professors are worried about
> losing all the students who expect that diff. eq. is the only
> thing to learn in mathematics (read "Electrical Engineering,
> Physics, and Chemistry students").
But there's an important difference: those people (of whom I was one)
are not *maths* students, they are physics/engineering students. I
was well aware that there were whole areas of maths I didn't learn at
university, but I wasn't trying to be a mathematician, I was trying to
be a physicist, and physics is very definitely not maths.
So I don't think this comparison is really fair.
--tim
Jeroen Fokker
>What I want to do is type:
>> map f xs = if null xs then [] else f (head xs) : tail xs
>and have the compiler deduce that for all types "a" and "b", map has type:
>> map :: (a -> b) -> [a] -> [b]
>Which of course is exactly what happens (in the other window I have open)!
Rather, I would like to type that for all types a and b
map :: (a->b) -> [a] -> [b]
and have the compiler suggest that it's definition is
map f xs = if null xs then [] else f (head xs) : tail xs
which -alas!- still doesn't happen in any window I have open.
--
Jeroen Fokker | jer...@cs.uu.nl
dept.of Computer Science, Utrecht University | tel.+31-30-2534118
PObox 80089, 3508TB Utrecht, the Netherlands | fax.+31-30-2513791
Lars Lundgren
> I've been reading this thread with some degree of interest. I'm a physicist
> who has been acting as a computer scientist for nearly 20 years. But there
> is much I don't know about. So could you please expand on your last comment
> about not needing lambda's either?
>
> Thanks,
>
> David McClain
>
I shall try to explain my position - I would rather say:
If you were to present the core idea of map you would benefit from:
o Writing the type of the function - since it is a good way
of stating its pre- and post conditions.
o Having ways of building functions in-place - since that would make
examples simpler (and map more useful).
The second point is not *the same* as having lambdas. Lambdas are very
useful when you want to write function-expressions but so is partial
application and function composition.
(I'm not used to meet so humble persons on usenet, I think I could learn a
lot from you)
>
> Lars Lundgren wrote in message ...
> >On 29 Sep 1999, Brian Harvey wrote:
> >
> >>
> >> In Java it's awfully hard to write a general higher-order function like
> MAP.
> >> You can write versions for particular purposes (e.g., one for lists of
> >> integers) but a language with LAMBDA and without strong typing makes it
> >> much easier to present the core idea.
> >
> >Why on earth do you think that 'no strong typing' makes it easier to
> >present an idea? I would say the opposite!
> >
> >If you find a particular type system being in the way when you try to
> >write a program, the natural conclusion is *not* that the type system is
> >to strong, it is rather that the type system is not expressive enough.
> >
> >IMHO anyway.
> >
> >
> >(Actually, I do not really see why lambdas are essential either).
> >
> >/Lars L
> >
>
/Lars L
The type system can be your friend. You don't want to develop
programs with bad company, or even worse, all alone, do you?