SICP and the dumbing... 
Author Message
 SICP and the dumbing...

12345678901234567890123456789012345678901234567890123456789

Quote:
>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!!!

Yeah, it's great.  It's the best computer book I've ever
read.  I regret not having read it years ago.  Instead,
I was absorbed in the 3 Knuth volumes.

Quote:
>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 disagree.  As a recent Comp Sci student, I'm glad
that UMKC taught me some marketable skills, not
just academically useful skills.  I'm sure to be corrected
if I'm wrong, but the size of the market for programmers
capable of writing in Lisp dialects is surely not all that
large, especially in comparison to the market for C++ and
Java programmers.  Except for those students intending to
become employed in research or academe, a university would
be doing them a grave disservice to not teach C++ and Java,
with all their attendant over-emphasis on syntax.

Regarding pragmatism, in this case I believe it is rather
the pragmatism of today's informed education consumer which
has driven this academic trend more than industry-dictated
pragmatism.  I know I wouldn't have shelled out the big
bucks I did for my degree if I hadn't believed the
knowledge I would gain would make me more valuable
on the employment market and consequently result in some
return on the investment.

Quote:
>I'm not sure how to counteract this trend.

I'm not sure it necessarily needs to be counteracted.  If
anyone thinks industry is really causing this trend, I would
invite them to risk their own capital in starting up any type
of business they choose in which all programming is required
to be in some Lisp dialect.  Thus, the market for Lisp-dialect
programmers will expand which will tend to increase the demand
by students for such courses which will tend to lead academia
to offer more of those courses.  But I predict that a business
established with such skewed principles will quickly fail.

If I'm correct in thinking it's the pragmatism of the education
consumer driving the trend toward C++ and Java, it might work
better toward counteracting the trend to risk your own capital
starting up a learning institution in which C++ and Java are
ignored in favor of Lisp.  If you could show that the students
of your institution are better programmers (for the benefit of
prospective employers) and are more likely to become more
marketable on the employment market (for the benefit of the
students themselves), regardless of the language in which
they ultimately program, you might have a Lisp revival on
your hands.  I don't see it happening.

Lastly, I believe the only true hope of counteracting the trend,
if it needs to be counteracted, is to popularize and publicize
the usefulness of Lisp dialects in a manner similar to the way
Linux has been done.  Ask anyone who has heard of Linux to name
one application which runs under Linux, most people probably can,
if only something like X or Netscape.  On the other hand, ask
anyone who has heard of Lisp to name one application which runs
under a Lisp dialect, my guess is most cannot.  There's your
problem.  I'm sure Lisp applications are out there but compared
to Windows, C++ and Java-based applications, hardly anybody has
heard of them.

Quote:
>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.

Try putting SICP on your resume instead of C++ and Java.  Your
first job offer will be from McDonald's and I don't mean their
IT department.

Quote:
>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 think you're right.  There's too much syntax to worry about
in C++ .


Sat, 16 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:

> >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 disagree.  As a recent Comp Sci student, I'm glad
> that UMKC taught me some marketable skills, not
> just academically useful skills.  I'm sure to be corrected
> if I'm wrong, but the size of the market for programmers
> capable of writing in Lisp dialects is surely not all that
> large, especially in comparison to the market for C++ and
> Java programmers.  Except for those students intending to
> become employed in research or academe, a university would
> be doing them a grave disservice to not teach C++ and Java,
> with all their attendant over-emphasis on syntax.

As someone on the hiring end of things, one of my primary
criteria for hiring someone is "knowing how to program" as
opposed to "knowing how to write code in a particular language".
Rest assured that programming is a _very_ marketable skill.
It has been my experience that someone who is good at programming
can usually learn any new language in a few weeks.  It is also
my experience that people who have read and understood SICP
are frequently better programmers than those who have not.

While this may not be the average industry response, you have
to ask yourself "do I want an average job?"  While formulating
an answer, keep Dilbert in mind.

--
Scott Meyer                                   415 506 0987
Principal MTS                                

Oracle - Languages & Relational Technology    standard disclaimer



Sat, 16 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:

>As someone on the hiring end of things, one of my primary
>criteria for hiring someone is "knowing how to program" as
>opposed to "knowing how to write code in a particular language".

As well it should be, but it's been my experience your criterium is
not often used.  Maybe your experience is different.  In my experience,
most employers are looking for someone with a particular basic skill
set whom they can work into a team of programmers posessing a similar
or identical skill set.  Most employers in my industry, telecom, have
no time to hire even a brilliant programmer needing a few weeks to be
brought up to speed in a particular language.

Quote:
>Rest assured that programming is a _very_ marketable skill.

I couldn't agree more.  On the other hand if you go to a shop where
programming is done in nothing but C++, if you have nothing but Lisp
experience, you're at a disadvantage to other applicants who do have
C++ experience, even if they aren't as good programmers as you.

Quote:
>It has been my experience that someone who is good at programming
>can usually learn any new language in a few weeks.  

True, but certainly you don't mean that a good programmer with no C++
experience can become as proficient at C++ in a few weeks as an equally
good programmer who has been writing C++ code for years, do you?  I'd
like to understand your reasoning if that is indeed what you mean.

Quote:
>It is also my experience that people who have read and understood SICP
>are frequently better programmers than those who have not.

I'd be interested in knowing what sort of correlation you find between
the attributes "read and understood SICP" and "better programmer" and
whether you would stake a hiring decision on the former.  If you have
any correlation statistics, I'd be interested knowing how you collected
them.

Quote:

>While this may not be the average industry response, you have
>to ask yourself "do I want an average job?"  While formulating
>an answer, keep Dilbert in mind.

I guess that would depend on the individual person and on your definition of
the average job.  I'm not sure exactly what Dilbert does and I'm definitely
unsure of how well he is compensated.  I do know that even on sensational jobs,
one is bound to lock horns with the kind of mindless passive aggression which
seems to be the bane of Dilbert's existence.  Don't try to tell us it doesn't
exist on the jobs for which you hire people.  I'm familiar with your company.
I know people who work there in programming jobs.


Sat, 16 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:


> >As someone on the hiring end of things, one of my primary
> >criteria for hiring someone is "knowing how to program" as
> >opposed to "knowing how to write code in a particular language".

> As well it should be, but it's been my experience your criterium is
> not often used.  Maybe your experience is different.

Nope.  I think your characterization of industry is correct.
Perhaps my Dilbert allusion was too oblique.  The question is:
"Does anyone really want a job with an employer who values
them only as a fleshy container of some transient bit of knowlege?"

Quote:
> >Rest assured that programming is a _very_ marketable skill.

> I couldn't agree more.  On the other hand if you go to a shop where
> programming is done in nothing but C++, if you have nothing but Lisp
> experience, you're at a disadvantage to other applicants who do have
> C++ experience, even if they aren't as good programmers as you.

That depends entirely on who is doing the hiring.  In a past
life, my group was very successful hiring ex-lispers with zero
C++ and Smalltalk experience to do some pretty sophisticated
system-level work involving both languages.

Quote:
> >It has been my experience that someone who is good at programming
> >can usually learn any new language in a few weeks.

> True, but certainly you don't mean that a good programmer with no C++
> experience can become as proficient at C++ in a few weeks as an equally
> good programmer who has been writing C++ code for years, do you?  I'd
> like to understand your reasoning if that is indeed what you mean.

That is exactly what I mean.  There's no reasoning behind it, just
anecdotal observation.  For good programmers, language is simply not
an up-to-speed issue.  The bulk of the up-to-speed overhead is
understanding what is being built in the language, and any new
programming domains, for example writing your first real (SMP)
multi-threaded code.  In the example you give, if the programmers
are truely equally good, the only difference between them is
knowlege of C++ syntax.  If you're already familiar with classes,
inheritance, encapsulation, macros, etc., mapping C++ syntax on
to your existing understanding simply isn't that hard.  If you've
never seen an isa pointer or fiddled with macro expansion, and
C++ is your first exposure to these ideas, it will indeed take
longer than a couple of weeks to learn, but then you probably aren't
a "very good programmer" yet.

Quote:
> >It is also my experience that people who have read and understood SICP
> >are frequently better programmers than those who have not.

> I'd be interested in knowing what sort of correlation you find between
> the attributes "read and understood SICP" and "better programmer" and
> whether you would stake a hiring decision on the former.  If you have
> any correlation statistics, I'd be interested knowing how you collected
> them.

Would I hire someone because they have read some particular book?
Certainly not.  Nor do I quizz people about subjects covered in SICP.
Once again, the correlation is purely anecdotal. I have seen good
programmers
who already read SICP, and I've watched good programmers who haven't
read
it read through it and understand it.  I've never met anyone who could
fake it.

Possibly, SICP is nothing more than some clubby shared vocabulary, or
the
mental equivalent of a heavy barbell, but I don't think so.  I think
that
it is simply a good exposition of a number of ideas (scope,
encapsulation,
mutability, continuations, program transformation) which turn up again
and again in CS or programming.

-Scott
--
Scott Meyer                                   415 506 0987
Principal MTS                                

Oracle - Languages & Relational Technology    standard disclaimer



Sun, 17 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

    Scott> Possibly, SICP is nothing more than some clubby shared
    Scott> vocabulary, or the mental equivalent of a heavy barbell,
    Scott> but I don't think so.  I think that it is simply a good
    Scott> exposition of a number of ideas (scope, encapsulation,
    Scott> mutability, continuations, program transformation) which
    Scott> turn up again and again in CS or programming.

I missed the part of SICP where they discuss continuations.  Could you
point me to a section number?

--
Lyn Headley
remove the word "bogus" from my address for the real one.



Sun, 17 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:
> I missed the part of SICP where they discuss continuations.  Could you
> point me to a section number?

4.3.3 (but it may not be what you were thinking of)

 -Max Hailperin
  Associate Professor of Computer Science
  Gustavus Adolphus College
  800 W. College Ave.
  St. Peter, MN 56082
  USA
  http://www.gustavus.edu/~max/

P.S.- I printed out Scott Meyer's original message for reference, if I
get quesetions about my use of a somewhat SICP-like book.  It's a gem.



Sun, 17 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:

> I missed the part of SICP where they discuss continuations.  Could you
> point me to a section number?

SICP doesn't teach Scheme explicitly.  It teaches how to think about
large systems and manage complexity by decomposing large problems into
smaller ones.

It happens to use Scheme (or a subset thereof), and as such, the
student will learn it.  It is taught implicitly, rather than
explicitly.

Thus there are many features of Scheme that may be missed.
Continuations are missing from some editions (I haven't read the
latest), but so is the full numeric tower, or everything but very
simple I/O.

SICP could be rewritten to use some other language, but other
languages would require more explicit teaching, and would obscure the
core ideas in varying levels of unneeded obfuscation.

The features of Scheme whose absence would most change the flavor of
SICP in my view are

- The typing philosophy (objects vs. variables)
- Tail recursion

I took the precursor of the course for which SICP is the text book
before it used Scheme.  Using Scheme allowed the important points to
be made more clearly.



Sun, 17 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:
>The features of Scheme whose absence would most change the flavor of
>SICP in my view are

>- The typing philosophy (objects vs. variables)
>- Tail recursion

I'm surprised you don't include first-class procedures in this list!
Certainly without that and lexical scope the approach to OOP would have
to be very different.


Tue, 19 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:


> >The features of Scheme whose absence would most change the flavor of
> >SICP in my view are

> >- The typing philosophy (objects vs. variables)
> >- Tail recursion

> I'm surprised you don't include first-class procedures in this list!
> Certainly without that and lexical scope the approach to OOP would have
> to be very different.

It's all an issue of what you compare it against.

If I remember correctly (memory is vague), the thread talked about
Common Lisp and ML.

First class procedures and lexical scope are not differentiators with
respect to those, nor with respect to gcc's dialect of C.

Of course, for other languages the issues would be different.  In
fact, I forgot to add 'eager evaluation' -- I always forget lazy
languages because I consider them toys.  That's a personal bias that I
should eliminate.

And yes, before anyone misunderstands what I'm saying, I think that
so-called strong typing is a terrible idea when dealing with
complexity at this level.  Strong typing is merely a tool that aids
some (perhaps many/most) in coding, but not much in
understanding/managing complexity.

When you do a back of the envelope design (which Scheme is great at),
you don't want to worry about that, just like when you start designing
a logic circuit at first you ignore fan-out (unless outrageous),
placement, and capacitance on the substrate.  Later, sure, but early
on, it is just distracting nonsense.  Strong typing falls in the same
category.



Tue, 19 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:



> > >It has been my experience that someone who is good at programming
> > >can usually learn any new language in a few weeks.
> > True, but certainly you don't mean that a good programmer with no C++
> > experience can become as proficient at C++ in a few weeks as an equally
> > good programmer who has been writing C++ code for years, do you?  I'd
> > like to understand your reasoning if that is indeed what you mean.
> That is exactly what I mean.

Then I think it's rather obviously false, and not only for C++.  For
instance, I don't know of anyone who after a few weeks of Common Lisp
was just as proficient as a good CL programmer with years of experience
(unless they already knew some other kind of Lisp or some other
similar language).  I'm sure there are some very exceptional people
who could manage it, but it's not the kind of thing every reasonably
good CS graduate will be able to count on being able to do.

On the other hand, moving between, say, Pascal and C isn't very had.
Some language transitions are pretty easy; others aren't.

I'd even say that it used to be true (or at least significantly closer
to true) that new languages can be picked up rather quickly.  I've
learned quite a few languages over the years (including "unusual"
languages such as SNOBOL), and until recently I'd have made the same
kind of claim that I'm disagreeing with now.  C++, and in a different
way Java, have changed the rules.

Quote:
>     There's no reasoning behind it, just
> anecdotal observation.  For good programmers, language is simply not
> an up-to-speed issue.  The bulk of the up-to-speed overhead is
> understanding what is being built in the language, and any new
> programming domains, for example writing your first real (SMP)
> multi-threaded code.  In the example you give, if the programmers
> are truely equally good, the only difference between them is
> knowlege of C++ syntax.  If you're already familiar with classes,
> inheritance, encapsulation, macros, etc., mapping C++ syntax on
> to your existing understanding simply isn't that hard. [...]

But it's not just syntax.  C++ has a *lot* of syntax, and somewhat
weird semantics, but the biggest obstacle, I would say, is that a lot
of fairly C++-specific know-how is also needed before you can use the
language effectively.  I'm sure there are some very good programmers
who can adapt to even C++ without much trouble, but it's one of the worst
languages ever for learning quickly.

-- jd



Fri, 22 Mar 2002 03:00:00 GMT  
 SICP and the dumbing...

Quote:




> > > >It has been my experience that someone who is good at programming
> > > >can usually learn any new language in a few weeks.

> > > True, but certainly you don't mean that a good programmer with no C++
> > > experience can become as proficient at C++ in a few weeks as an equally
> > > good programmer who has been writing C++ code for years, do you?  I'd
> > > like to understand your reasoning if that is indeed what you mean.

> > That is exactly what I mean.

> Then I think it's rather obviously false, and not only for C++.

Oh, well, I guess I didn't see good programmers learn C++ in
a few weeks.  Must have been a mirage.  :-)

Quote:
> For
> instance, I don't know of anyone who after a few weeks of Common Lisp
> was just as proficient as a good CL programmer with years of experience
> (unless they already knew some other kind of Lisp or some other
> similar language).

All Turing-complete languages are pretty similar.  They differ only
in the handy conventions (jump tables, Horn clauses, closures, etc.)
that the language designers decided to canonize in the grammar.  If
you are familiar with, say, Horn clauses, you'll have no trouble
moving from Scheme to Prolog or vice-versa.  If you don't understand
Horn clauses, it is going to be hard to learn Prolog and when you're
done, if you still haven't learned about Horn clauses, you may wind
up being "a Prolog coder" instead of "a programmer who knows about
resolution theorem proving."

Separate CL into two components:

1. A very small language (not that different from Scheme)

and

2. A very large library

With the possible exception of the MOP, which is a little baroque,
the language part is pretty straightforward.  There's a nice book
about the MOP which will help with the bits that are unique to CL.
The library, is much bigger, but there's no need to learn it all at
once, just know roughly what it can do (does it have hash tables,
b-trees, etc.) and where to find the reference manual.

Of course, you're going to be a little slow for a while because
you'll be hitting the reference manual when more experienced CL
hackers will just know what to type but that might not be as bad
as you think.  I once categorized all the bugs I made for a year
(motivated by Knuth's "Errors of TeX" paper) and discovered that
many of the mistakes I made were due to "failure to read the
man page."  Since bugs take much longer to find and fix than the
5 minutes it takes to read the man page, you may not loose as
much productivity as you might think.  Of course, this fallibility
may have been unique to me...

Quote:
>I'm sure there are some very exceptional people
> who could manage it, but it's not the kind of thing every reasonably
> good CS graduate will be able to count on being able to do.

Right, but I said "good programmer" not "reasonably good CS graduate".
A "reasonably good CS graduate" is (somewhat) knowledgeable, but
unskilled.
With 5 or 6 years of effort a "reasonably good CS graduate" might
transform himself into a "good programmer" - one who is more
knowledgeable and most importantly, very skilled.  The knowledge is
knowledge of all those "handy conventions" that people like put
into languages, and the skill is "knowing" when and how to use them.
As a practical matter, I think that a "reasonably good CS graduate"
should know all of the "handy conventions" embodied in C++, but
they're not going to instantly become as good a programmer as someone
more experienced because the skill half of the equation is still going
to
be missing.  In my experience, the "handy convention" missed by most
"almost reasonably good CS graduates" is code generation (macros,
program transformation, call it what you will).  Moving away from
Scheme/Lisp as a teaching environment is only going to make this
shortcoming worse.

Ok, continuing in the grand tradition of discussing C++ in
comp.lang.scheme...

Quote:
> But it's not just syntax.  C++ has a *lot* of syntax, and somewhat
> weird semantics, but the biggest obstacle, I would say, is that a lot
> of fairly C++-specific know-how is also needed before you can use the
> language effectively.

If we were talking about one person writing a single program ex-nihil
I might buy this argument.  I say "might" because some would say that
effective use of C++ demands that one avoid crufty syntax and weird
semantics.  As a practical matter, this scenario just never happens.
There is always a lot of example code around, and furthermore, you're
usually working in the context of some larger system which, for better
or
worse, has already come to grips with most of the language pitfalls.
You spend more time learning the system than trying to find that
"operator whitespace" overload that somebody told you about.

-Scott

--
Scott Meyer                                   415 506 0987
Principal MTS                                

Oracle - Languages & Relational Technology    standard disclaimer



Fri, 22 Mar 2002 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. SICP & the Dumbing Down of American Comp Sci

2. SICP & the Dumbing Down of American Comp Sci

3. SICP & Dumbing Down Part II (was God CS Books)

4. SICP & the Dumbing Down of American Comp Sci

5. SICP & the Dumbing Down of American Comp Sci

6. SICP & the Dumbing Down of American Comp Sci

7. SICP & the Dumbing Down of American Comp Sci

8. Dumbing down...

9. Dumbing down....

10. Dumbing Down Scripts to Remove TclX

11. SICP for the US & Canada

12. SICP for the US & Canada

 

 
Powered by phpBB® Forum Software