Hacker News Reader

Comment by NickNaraghi | Hacker News Reader

The fundamentals of CS courses in my undergrad program were taught in Racket (with HTDP). At the time this seemed very impractical, because I already knew Java and just wanted to write useful apps.

But as I've progressed in my career, I've come to appreciate how it helped me develop a strong foundation for reasoning about programs and their underlying logic (in any language) that continues to serve me to this day.

If I was approaching this outside of a structured curriculum, it would be hard for me to justify this long-term intangible benefit relative to being able to move quickly to write something interesting and useful. And I think writing interesting and useful programs is the best way to motivate oneself to keep programming. So I can't strongly advocate for this approach. But I do think there are some worthwhile benefits.

View on HN

I think it could be argued that the language used in universities is unlikely to be the one used professionally. I remember when the derogatory term "Java school" was commonly used for schools that shoehorned Java in all courses just to try to match the language of the day in enterprises. It really should be about what is the best pedagogical tool to teach the concepts the student is expected to understand irrespective of future professional tools used. If racket exposes those concepts better without making it onerous on students to learn that's great.

When MIT switched from scheme to python for their undergrad classes there was a big debate here aboutit. I think the argument was that python won't make learning the concepts any harder but is less of an issue for students to learn and has some long term value professionally so win-win. I don't fully agree but I can see the logic.

It's not (just) that python is "easier" to learn than python (which I dispute - lisp is as easy to learn as a first language as any other. Depending on the language it may be a difficult second language though). The world had also changed radically since it was introduced into the curriculum:

"Costanza asked Sussman why MIT had switched away from Scheme for their introductory programming course, 6.001. This was a gem. He said that the reason that happened was because engineering in 1980 was not what it was in the mid-90s or in 2000. In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme — it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that’s all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want. But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course. So the good thing about the new 6.001 was that it was robot-centered — you had to program a little robot to move around. And robots are not like resistors, behaving according to ideal functions. Wheels slip, the environment changes, etc — you have to build in robustness to the system, in a different way than the one SICP discusses. And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all."

https://www.wisdomandwonder.com/link/2110/why-mit-switched-f...

> It's not (just) that python is "easier" to learn than python (which I dispute - lisp is as easy to learn as a first language as any other. Depending on the language it may be a difficult second language though). The world had also changed radically since it was introduced into the curriculum:

A lot of texts will use pseudo-code and it is (from my experience) easier for beginner programmers to see the relation between pseudo-code and Python than for many other languages.

> python is "easier" to learn than python

(?)

That was quoted from GP; presumably they meant "easier to learn than scheme"

Aha, ISWYM. Thanks.

yes, this actually is the most important advantage of python: python can equal to pseudo code. but new function of python reduced this advantage.

I'm still surprised Sussman describes the 2000s as a "new" job whereas to me it's just mediocre soil from an unstable industry. Mucking around is not engineering.. it's alchemy.

The logical culmination is modern ML, where no engineering is involved. "If the thing fails on some case and kills somebody, train it more." This is voodoo, not engineering.

Given Sussman's aversion to mysterious black-box AI, that's an interesting observation. The curriculum change brings everyone one step closer to not really understanding how things work.

Of course, it's often pointed out, "Well, if you write in Scheme (or C or Java or whatever) then you're not writing in assembly language, much less machine language, so you already don't understand everything." There's certainly truth there, but, to me, going from, expertise writing code in a high-level programming language to, gluing together libraries that you kinda-sorta understand, feels like a bigger leap in what you do or do not understand than going from assembly language to Python.

I suppose it depends on what issues we should consider to be introductory. Maybe the older theoretical approach was more fundamental then than it is now. Like, maybe that was effectively more practical given the old hardware performance constraints and likely having more control of the entire program stack.

It's interesting that Sussman kind of lumps together "uncertain software libraries" into the same category as machine control robustness (e.g. hysteresis). I never thought of it that way but I guess in practice it's all just "stuff", those libraries are just another piece of your program's environment like any other.

Maybe MIT approaches post 2000 engineering with a solid foundation of analysis that creates both a beautiful creation process and reliable beautiful software artefacts. But what I observe is a never ending stream of partial doc reading, partially out of date, with random attempts until it looks it won't fail it left running for a few minutes.

Ability to deal / reflect with unknowns for engineering is of great value, but so far I've never seen that in office.

I see this as the distinction between computer programming and software engineering.

> It's not (just) that python is "easier" to learn than python

(?)

He meant "python is easier to learn than scheme/racket".

> It really should be about what is the best pedagogical tool to teach the concepts the student is expected to understand irrespective of future professional tools used. If racket exposes those concepts better without making it onerous on students to learn that's great.

One of the challenges with an approach which doesn't concern itself with "industrial grade" or "production ready" languages is getting buy in from student. Even if there were a perfect language for teaching, if students don't see the applicability of that language they aren't going to learn enough of the concepts to move to such a language later.

I think it's very easy for us (and other technically competent folks) to see value in learning how computers work for the sake of that knowledge; however, students, as an over generalization, don't. The fact that relevance and motivation are some of the hardest hurdles to overcome in early computing classes is a perfect example of this. Using languages with a professional pedigree is important because it increases student buy in to what they're being taught.

An analogy I like is that you wouldn't give someone new to woodworking a toy hammer and hand saw because they need to learn fundamentals like striking and cutting before they can start using "real" tools, you would provide them with capable, but beginner friendly, tools that allow them to build those skills as they learn.

I still haven’t tried Racket, but I did dive into Clojure. It was on the job, not a structured curriculum by any stretch. But I can say the same:

> …it helped me develop a strong foundation for reasoning about programs and their underlying logic (in any language) that continues to serve me to this day.

I went on to use Clojure and ClojureScript for several years. Now I primarily work in JavaScript and (preferably) TypeScript, but I can’t say a day has gone by where what I learned working in Clojure hasn’t been applicable and valuable.

Just one more anecdata point, but I would advocate learning a lisp—maybe even any lisp. In fact, it’s usually one of my first recommendations when juniors/mentees ask me for advice in any kind of broad strokes.

When I read things like the second paragraph above, I start to wonder if maybe I am actually a terrible programmer because I only ever learned what you might generously call “applied computer science” aka only the languages commonly used in typical workplaces (Java, PHP, Ruby, JS) and none of the CS classics. Does anyone else without the so-called ‘academic’ languages foundation ever feel this way when you see people on HN always writing about Lisp and its peers?

You're probably not. Programming in lisp,back in my college days, felt enlightening. I remember flying through quiet complex projects with a clarity that I've rarely experienced in my professional career. I do yearn for those days when I'm deep within a nonsensical "enterprise" Java codebase or a messy frontend codebase but I don't think Lisp made me an objectively "better" programmer. There is enough imposter syndrome in this industry as it is. If you ever want to, pick up SICP or "How to design programs", you'll probably find them interesting but don't expect to find programming nirvana.

I think I had the inverse experience. I started with Lisp because I was customizing and extending Emacs. As I self-taught programming from that point forward, most other languages have sooner or later frustrated me with inexplicable inconsistencies with the syntax and data model. Lisp, Tcl, and Prolog all clicked into place quickly and easily, and for everything else, I'm constantly referring to a guide to the syntax. Not that big a deal, but feels internally like at best sort of a head-scratcher.

None of this has anything to do with academic computer science. I think I'm just unusually bad at memorizing syntax.

I had the same prof for several courses. His exams were pretty straight forward, but always contained a "tough question".

In order to get that tough question, you could carefully read the book, read his assignment solutions, and pay close attention to his caveat warnings in lectures... One of the three would typically contain the tough question.

Or, you could just read the book, do the assignments, and accept ~95% on the final exam as a maximum grade.

A ~95% cap, for a lot less work, is a good deal. Taking the deal is probably the right call for most people.

That being said, the thing I wish someone explained well is how amazing lambdas can be. I understood the benefits of list/array/stream processing on first glance, but it took a few years before I really understood the practical application of lambdas.

Well you had a nice professor. Mine would have a few "tough questions" that accounted for 50% of your grade. It forced you to know everything inside and out if you hoped to pass.

Chapter 1 of the SICP book says that the main reason it uses Lisp is its convenience in manipulating procedures as data.

There is a "JavaScript Edition" of SICP. The preface says ECMAScript 2015 enabled a close match by adding lambda expressions, tail recursion, and block-scoped variables and constants.

It doesn't mention much downside except that JavaScript's "rigid syntactic structure complicated the implementation" of some programming language design book material.

No, I say you won't get too much by learning LISP. I was attracted to LISP-related topic by similar arguments; looking back now, I found those argument at least not true for me.

You WILL get very interesting ideas and concepts, it's fun, basically, that's it.

+ You won't solve problem faster than your colleges with solid competitive programming background;

+ you won't be able to optimize the code and cut 30% of your company's server cost,

+ you won't feel comfortable to read real-world complex project code,

+ you won't get some domain-specific knowledge to solve problems you previously can't solve.

+ .....

It won't make you a better problem solver; at least its impact is way smaller than pick up go/rust/cpp/java and carefully try implement challenge like: https://github.com/codecrafters-io/build-your-own-x

I also wish I would have studied classical CS in college. However, I was sick most of the time, and there were half a dozen weed-out classes, so the computer science courses I did take were non-major courses to supplement a GIS degree.

GIS is certainly interesting in its own ways, and it taught me some visualization and design skills, but I wish it would have been possible for me to learn more of what's going on under the hood of the massive libraries and high-level languages I use every day as a professional "software engineer"

Me too.

So I decided to learn SICP on my own. I already have the book, so I'll watch the MIT lectures of the original authors available online, and try to make progress.

I'm not in any hurry to complete it anytime soon.

Reply on news.ycombinator.com