Lecture 1A | MIT 6.001 Structure and Interpretation, 1986

Reminds me of the MIT SICP lecture videos from the 80s. The concepts of black box abstraction and the simplicity of using LISP like lego building blocks blew my mind and made me switch from being a UX designer dabbling in Rails to a full blown programmer. It was still entirely relevant to today even though it was a few decades old as the fundamentals of computer science are still fundamental. [this video] Hearing that intro music still brings a smile to my face. I just happen to be relearning math right now as I dive deeper into data science and this is perfect timing. Going to watch this series once I get through my math proofs book ("Book of Proof" by Richard Hammack which I recommend to people getting into math [link] ).

I took 6.001 in 1999 (I think). Hal Abelson taught it along with a professor who took off his sweatshirt to reveal a Microsoft tee at his final lecture (he went to Microsoft). What was great about Scheme (Lisp) is that most programs are basically words from your vocabulary, parentheses, and cars and cdrs. With procedural languages, there is always a sense that the language provides all the tools, and the magic happens somewhere underneath the hood. But with Scheme it feels as if it's happening right before you. It makes you feel like a wizard, and not a monkey. And it requires knowing all the spells. It requires knowing how to make magic happen. Or not. Once you know none of it's magic. But that's the point! Python is arguably easier and more practical for both science and work. It's already popular on the web server, and is used everywhere else -- unlike Scheme. But the recent resurgence of functional programming is super exciting with Elixir and Elm and the like. I'm looking forward to building my next project using Elixir. Here is the classic course: [link] Original video lecture on YouTube (linked from above): [this video]

Little schemer is good, some people hate it some people love it. But it is a fairly light read the slowly teaches some syntax at a time, questions you about assumptions then revels the information as it goes on. It would be the least dry read. There is also sketchy scheme for a more thorough text, or even the rs7s standard, which are both pretty dry but short. What made me appreciate scheme was watching some of the SICP lectures ( [this video] ) and the little schemer to learn more. I also read some of the SICP along with it, though I put it down due to not having the time to work through it. Scheme is interesting and toying with recursion is fun, but the path a mentioned above is only really enjoyable if you are looking to toy around with CS concepts and recursion. You can do a lot more in modern scheme as well, and you can build anything out of CL. But learning the basics of scheme/lisp is can be pretty dry if you are just looking to build something right away like you already can in a traditional imperative language. But it is interesting if you are interested in a different perspective. But even RS7S scheme is still far from the batteries included you get with CL. I personal found the most enjoyment using Kawa scheme, which is jvm based and using it for scripting with java programs as it has great interop. I used it some for a game back end in the event system to be able to emit events while developing and script behaviors, I've also used it for configurations as well with a g

> Interesting. Maybe we should compare notes sometimes. I have a bit of a story with finding alternative-type stuff. I really like the theory of programming, and am constantly looking for languages that are a) easier to write b) amazingly expressive Its always finding what's out there. > - I've been contemplating tackling Python, in spite of the 2.x/3.x thing. There's the perfect vacuum where versioning shouldn't be a problem, and the practical real world where knowing Python and the differences between the two will let me actually do interesting things. Thankfully, that's mostly gone now. Few enterprises still holding out, but most of the big libraries are 2/3 or 3 only. And 3 is a lot more thought-out. Most of the warts are gone. > - I completely forgot to mention Awk (!) mostly because I have no idea at what point I began to pick it up, but I did get a basic idea of how it works a while ago, and I've been factoring it into shell pipelines more frequently lately. It's great for when I need to do something that sed can't express well (and I just properly read about how match() a) returns the index and b) also works apropos to grep recently, which is great) Awk is different, but great. I had a boss at a previous job who'd used it for at least a decade for everything, so I had to learn the nitty-gritty. I ended up building a CGI application that basically ran the entire website in Awk. Big learning experience, but rather cool. > (As an aside, Lua is ~200K and awk is ~632K. Tha

I think the underlying cause of this over abstraction is largely a result of abstraction being excessively glorified (mostly) by academics and formal CS curricula. In some ways, it's similar to the OOP overuse that has thankfully decreased somewhat recently but was extremely prevalent throughout the 90s. In software engineering, we're constantly subjected to messages like: Abstraction is good. Abstraction is powerful. Abstraction is the way to solve problems. More abstraction is better. Even in the famously acclaimed SICP lecture series [1] there is this quote: "So in that sense computer science is like an abstract form of engineering. It's the kind of engineering where you ignore the constraints that are imposed by reality." There is an implication that we should be building more complex software just because we can , since that is somehow "better". Efficiency is only thought of in strictly algorithmic terms, constants are ignored, and we're almost taught that thinking about efficiency should be discouraged unless absolutely necessary because it's "premature optimisation". The (rapidly coming to an end) exponential growth of hardware power made this attitude acceptable, and lower-level knowledge of hardware (or just simple things like binary/bit fields) is undervalued "because we have these layers of abstraction" - often leading to adding another layer on top just to reinvent things that could be easily accomplished at a lower level. The fact that many of those in the demosc