
The Structure and Interpretation of the Computer Science Curriculum (2004) - tosh
http://cs.brown.edu/~sk/Publications/Papers/Published/fffk-htdp-vs-sicp-journal/
======
traderjane
[https://htdp.org/](https://htdp.org/)

~~~
neilv
More info and links...

HtDP is the textbook for the curriculum approach described in the paper. It's
supported by the student-oriented DrRacket IDE (which is included with a
normal Racket install): [https://www.racket-lang.org/](https://www.racket-
lang.org/)

Besides HtDP as an intro course for undergraduate CS majors, they also have an
interest in teaching program design as a part of basic literacy, including to
younger students.

In addition to HtDP, a lot of Racketeers also value the relatively
intimidating SICP, and DrRacket supports SICP as well: [https://docs.racket-
lang.org/sicp-manual/Installation.html](https://docs.racket-lang.org/sicp-
manual/Installation.html)

------
carapace
> The primary goal of a computing curriculum is to produce programmers and
> software engineers.

It reminds me of the old joke, "Computer Science could be called the post-
Turing decline in the study of formal systems."

~~~
nextos
Sadly, you are right. SICP has vanished from most introductory courses. CTM a
fantastic sequel, more oriented towards formal semantics, has never really
made it into mainstream.

A central topic in CS studies should be formal system semantics. These days,
students only get some computability and complexity notions. Usually embedded
in an algorithms course. At that's it.

Which is sad. You can get a lot of insights into CS, and Software Engineering
as true engineering, by going through some basic semantics notions. Take a
theorem prover, and teach students how to model different computation systems
and verify some properties on them.

If time allows, expand into more efficient but less general approaches like
abstract interpretation, static analysis, model checking and type/effect
systems.

You don't need a ton of background. Some beautiful texts cover these with just
FOPL [1,2].

[1] [http://www.concrete-semantics.org/](http://www.concrete-semantics.org/)

[2] [http://adam.chlipala.net/frap/](http://adam.chlipala.net/frap/)

~~~
jhanschoo
> CTM

Unfortunately, the accompanying Mozart 2.x interpreter/programming environment
doesn't yet support some important features of the Oz language, and the old
1.4.x implementation is so outdated the easiest platform to install it for
is... Windows. The macOS version seems oblivious to the relatively recent
tightening of app permissions, and Linux is something I have yet to figure
out.

~~~
nextos
Yes, this sucks. I have an old Ubuntu VM for running Mozart 1.4.

------
Merrill
Quote 1 "Clearly, a computer science curriculum must not, and doesn’t have to,
become a vocational training ground for the latest industrial programming
language and programming tools. Superficial aspects of industrial practice
change as fast as fashion trends. No academic department can switch its course
content fast enough and maintain a curriculum that passes on tested wisdom."

Quote 2 "Applied to the first-year courses, these suggestions say that the
year should start with a heavy emphasis on principles and should add some
industrially relevant components during the second semester. Even more
precisely, the first semester should emphasize programming principles and
habits; the second part should illustrate the use of these principles in
currently fashionable programming languages. Of course, the “principled”
semester may integrate fashionable parts where they aren’t an obstacle, and,
more importantly, the “fashionable” part of the first year must continue to
practice good design habits."

First, organizations that employ software developers don't choose programming
languages and toolchains because they are "fashionable". They choose them
because of proven utility and effectiveness, prior experience, employee
knowledge base, and inertia. Introducing the "fashionable" language to your
organization typically requires overcoming considerable resistance from both
management and peers. As a result the turnover of languages used in any
particular sector of software development is really slow. The changes in
relative frequency of use of programming languages more often reflects new
areas of application, such as mobile, bioinformatics, machine learning, etc
where early practitioners set precedents for the use of a new language.

The age of the top languages in Tiobe Index are C, 47; C++, 34; Python, 29;
Java, 24; JavaScript, 23; C#, 19; and VisualBasic.net,17.

~~~
tsss
> First, organizations that employ software developers don't choose
> programming languages and toolchains because they are "fashionable"

Citation needed

~~~
shagie
c. 2004 there wasn't as much of a chase of fashionable languages or the rapid
churn of frameworks that is seen today in some technology stacks.

~~~
Jtsummers
Yes there was. Java’s adoption itself was largely a result of corporate
fashion and was brought into university and high school curricula to meet
their needs. Fashion has always been part of the industry in some way.

~~~
neilv
Java was a very plausible language for teaching software development at the
time. It had memory safety, good multithreading support, static typing,
exceptions with some static checking, and supported OO. The sandboxing and VM
was also appealing, for tools support and research.

OO was very popular, and not just for fashion: (1) academia was concerned with
things like interacting objects as models of computation; and (2) OO
methodologies of the time were very useful tool for practical reasoning about
systems designs, and Java arguably supported mapping design models to code
better than any non-research language of the time (though there's still a
gap).

I was involved with a university CS department effort to learn about and
evaluate many OO languages, for rethinking intro CS education, and I recall
Java did very well. This was before most companies other than Sun had ever
heard of Java, so I'm not aware of any employer push at that time.

Turning exciting Java (which initially seemed targeted at the kind of
programming work then using C++, not corporate MIS programmers using 4GL
frameworks and such) into a bureaucratic enterprise language, came later.

Regarding pre-corporate university interest in Java, I can mainly tell you
what I recall, but you can still see this 1996 Emacs mode for writing in an
assembly language for the JVM (like a student might go to the trouble to spend
time on, if Java had research target appeal):
[https://www.neilvandyke.org/jasmin-
emacs/](https://www.neilvandyke.org/jasmin-emacs/)

------
blendo
Surprising quote: "Several instructors reported that female students like the
HtDP curriculum exceptionally well. In a controlled experiment, an htdp-
trained instructor taught a conventional AP curriculum and the Scheme
curriculum to the same three classes of students. Together the three classes
consisted of over 70 students. While all students preferred our approach to
programming, the preference among females was a stunning factor of four. An
independent evaluator is now investigating this aspect of the project in more
depth."

That said, what I really liked about my SICP course at Boston Univeristy in
1987 was the fact I could do all the exercises on our office PC (an 80286),
with Emacs as the IDE. Quite heady stuff back in day.

