Fascinating. Does it help their understanding of programming as much as one would hope? Offhand I imagine it would be much less transferable to their everyday work life than Java or Python. And did you try Visual Basic?
From my experience people who start with Java or Python have problems understanding programming. They learn the syntax and tools.
Programming is (my definition, everyone has a different one) breaking down problems in different layers until you know how to write that as code and then abstracting up.
E.g. in LOGO:
Drawing a house breaks down to: draw the rectangle for the building, draw the rectangle for the door, draw the triangle for the roof.
The abstracting up: Write a procedure that can draw triangles and rectangles and replace the code with that.
It's not learning syntax, but programming. I wrote code in 30+ languages and was paid for code in 20+ languages, I think it is more imporant to understand programming than language syntax, which is easy to pick up.
(As a counter example to myself, I've learned programming with VIC-20 BASIC)
Counterintuitive to me! I would imagine that while people might get stuck with Java syntax, Python would make it easier, and that Logo would just make it harder when they found out most languages aren't like it...
Having taught BASIC and COBOL to young adults at a trade school and C/C++ and Lisp to adults in a professional development program, my experience is:
a. BASIC is a great language to introduce imperative programming. It's even better if you can teach Dartmouth BASIC, which is more feature-rich than any of the smaller BASICs that came with micros in the late 70s / early 80s. Microsoft BASIC is great if you're processing a sequence of data inputs, which sort of makes sense as this the type of "computing" people had in mind in the late-60s / early-70s. Visual BASIC came along much later and (not surprisingly) had features intended to make larger programs easier to maintain (local variable, named subroutines, etc.) though later versions of Dartmouth BASIC had similar features. We couldn't use it 'cause it was a single-source language and honestly, from a professional perspective, people were MUCH more interested in C/C++ at the time.
b. COBOL is great because it forces you to put your data structures up at the top of the program. Peter Naur has a quote "Show me your data structures and I can intuit your functions. Show me your functions and I'll spend all afternoon intuiting your data structures." And there's something to that. So sure... laugh about COBOL all you want, but from a pedagogical perspective, it had several advantages.
c. C/C++ benefited from the "I want to learn a language that will lead to a better job" syndrome in the 90s. If you picked up a copy of Dr. Dobbs in 1992, it was all about C++. My personal opinion is C++ is only now starting to be ready for prime time with recent language changes. It's hard to teach. It's hard-ish to learn. It's hard to debug unless you have the specifics of core concepts down (similar to JavaScript). I taught an intro course in C/C++ and counted it a victory if I got students to the point that they understood how stack frames were related to function calls and where static, global and local variables were allocated from.
d. I love Lisp because it was effectively my first language. There's a lot to digest with Lisp. It's as hard as C++ to teach, but for different reasons. There area lot of concepts you have to master to get good at it: recursion, macros, what the heck it means to evaluate something, what that single quote thing means. And it's far from obvious why you're doing what you're doing. I think you have to show learners A LOT of idiomatic Lisp code to get them to understand how the code maps over to language concepts. Or at least that's how I did it. Introduce a concept, then some code demonstrating the concept, then some code demonstrating the concept and how it relates to other concepts introduced previously. The thing I like about Lisp is it seems to have fewer, but more powerful high-level abstractions. And I think as an industry we could do a LOT better at tailoring courses on analysis and design for non-OO or non-imperative environments.
> Show me your functions and I'll spend all afternoon intuiting your data structures
Modern update:
- Show me your functions with pattern matching, and I can understand your functions and intuit your data structures, even if they are written down somewhere.
Show me your function bodies and conceal your types, and I shall continue to be mystified. Show me your types, and I won’t usually need your function bodies; they’ll be obvious.
I'm not sure that's true. But I'm not sure it's wrong. The only experience I really have with that is Haskell, which is a write-only programming language for other reasons.
