Everything Is Just Functions: 1 week with David Beazley and SICP

I've watched the actual SICP lectures before (the 1986 recordings on MIT OCW). They're often praised for the information density, but it actually still wastes a lot of time listening to students' Q&A, the lecturers drawing the class' attention to various attempts at "multimedia" presentation in the classroom, simply not having the entire lesson plan worked out in advance (i.e., not being able to preempt the Q&A) etc. For that matter, the sheer amount of time spent on writing things on a chalkboard really adds up.

And of course the order of the material could be debated and rearranged countless ways. One of my future planned projects is to do my own video series presenting the material according to my own sensibilities.

It's nice to hear that the course apparently still stays true to its roots while using more current languages like Python. Python is designed as a pragmatic, multi-paradigm language and I think people often don't give it enough credit for its expressive power using FP idioms (if not with complete purity).

The course is using Python to implement a Scheme, then uses Scheme to implement a Scheme. Python could and should be removed from the course.

Python has very poor support for functional programming. Lists are not cons based, lambdas are crippled, pattern matching is horrible and not even expression based, namespaces are weird.

Python is not even a current language, it is stuck in the 1990s and happens to have a decent C-API that unfortunately fueled its growth at the expense of better languages.

Interesting, I think this is the first time I have seen anyone bash Python this hard.

Why would a decent C-API fuel its growth? Also can you give me some examples of better languages?

Am no senior developer but I find python very elegant and easy to get started with.

Not very Schemey, but at least modern Python has basically full-on algebraic data types thanks to type hints, immutable dataclasses and structural pattern matching.

It's still not great for functional programming, but far, far better than it used to be.

I’m not the parent poster, but I’ve seen two major spurts of Python’s popularity: (1) the mid-2000s when Python became a popular scripting language, displacing Perl, and (2) beginning in the first half of the 2010s when an entire ecosystem of Python APIs backed by code written in C, C++, and even Fortran made up the infrastructure for machine learning code (e.g., NumPy, SciPy, scikit-learn, Pandas, etc.). If Python didn’t have a good way of interfacing with code written in languages like C, then it might not have been as popular among machine learning researchers and practitioners, who needed the performance of C/C++/Fortran for numerical computing but wanted to work with higher levels of abstraction than what is provided in those languages.

What drew me to Python back in 2006 as a CS student who knew C and Java was its feeling like executable pseudocode compared to languages that required more “boilerplate.” Python’s more expressive syntax, combined with its extensive “batteries included” standard library, meant I could get more done in less time. Thus, for a time in my career Python was my go-to language for short- and medium-sized programs. To this day I often write pseudocode in a Python-like syntax.

Since then I have discovered functional programming languages. I’m more likely to grab something like Common Lisp or Haskell these days; I find Lisps to be more expressive and more flexible than Python, and I also find static typing to be very helpful in larger programs. But I think Python is still a good choice for small- and medium-sized programs.

Ah thanks, that makes sense!

I try to avoid python in production code bases as much as possible: dependency management issues alone are a good reason to do so for anything that will last longer than a year or two.

It was relatively easy to lash Python as a higher-level orchestration layer to popular number crunching libraries, yielding NumPy and similar, which made Python popular for machine learning applications.

If you're used to Scheme, Common Lisp, or Haskell, Python's arbitrary decisions about e.g. lambda or how scopes work may be grating. But Python is the BASIC of the modern day, and people laughed at BASIC in the 80s too... except businesses ran on BASIC code and fortunes had been made from it.

There is also the course from ArsDigita University. The site is offline now but the courses are available on archive.org.

https://en.m.wikipedia.org/wiki/ArsDigita#ArsDigita_Foundati...

https://archive.org/details/arsdigita_01_sicp/

They were selling USB keys with the entire curriculum, if someone could upload an iso, that would be amazing. https://web.archive.org/web/20190222145553/aduni.org/drives/

I'm convinced python's main asset for its growth was how ubiquitous it was. It was basically pre installed everywhere. With the batteries included idea, you were mostly good with basics, too.

This changed with heavy use, of course. Such that now packaging is a main reason to hate python. Comically so.

IMHO the main problem is the fact that lambda expressions have been deliberately crippled. Ruby is often described as a good-enough Lisp despite it is not homoiconic. That's because, like all modern Lisps, it makes pervasive use of blocks, procs and lambdas. Python could have been a very similar language, but Guido held a vocal anti-FP stance. Perhaps this can be addressed now, as other interesting features like the ones you outlined have been added to the language, but it'd have a very deep impact on nearly every API.

While I am a huge lisp fan, oh...the irony of saying that python is struck in the 1990's when CONS, CAR and CDR are artifacts from the IBM 704 and Fortran :)

While I do find it annoying that python used 'list' to mean 'dynamic array', it is a lot better than a ton of church encoding in the other common teaching language, Java.

Linked lists may not be native in python but it is trivial to implement them.

FP in Python is rather weak. Even JS does a better job there. Some of the code exercises will need completely different solutions than in Scheme, due to not having TCO. What do instructors do, when their 1 to 1 translated code fails? Tell the students, that due to the choice of language it does not work that way, and that they simply need to believe it? Or do they treat it all as externalize the stack problems and solve it that way?

It seems rather silly to force SICP into Python.

Pyret would be a good alternative. It's designed for education by racketeers.

https://pyret.org/

CPython doesn't do TCO, but you can implement it yourself in Python.

This version is one of my all-time favorite StackOverflow answers: https://stackoverflow.com/questions/13591970/does-python-opt...

Back in the day I used to jokingly describe Perl5 as a "lisp-5ish." Lisp-1s like Scheme have a single namespace for all functions and values. Lisp-2s like Common Lisp allow a symbol to have separate bindings for functions and values. Perl symbols on the other hand have at least: scalar, array, hash, and code (it's been a long time since I did XS). I'm fairly confident I'm forgetting at least one or two on top of that.

If you avoided the many footguns the language offered, you could actually write pretty clean functional code. Of course you had to be extremely diligent with your testing because the interpreter did not provide much help even with warnings and strict enabled.

Absolutely, Higher-Order Perl was quite famous back in the day: https://hop.perl.plover.com

Most of those Ruby capabilities are already present in Smalltalk, but unfortunately the only thing many know from Smalltalk is it gave birth to OOP and GUIs.

In the 2000's you had to install it in most UNIXes still.

Forgetting about Zope.

That may be. I recall perl being bigger back then. I mainly consider python to have grown around the 2010s. And it was basically already on most machines.

It is only in the later versions where they have pushed compatibility boundaries that this has gotten obnoxious.

Looks like trampolines inside Y combinator. Interesting approach. Still of course with its own costs. I think some of the Scheme in JS implementation(s?) use trampolines as well, or at least considered doing that.

The issue with Python and most other non-LISP family programming languages is that they don't allow you to easily treat programs as data. Things that are simple to express with Scheme become complicated exercises when using mot another languages. Instead of focusing on the underlaying concept students end up having to focus on the implementation language's details in a way that they don't with Scheme.

Calling Python old in the same comment talking about a lisp dialect is funny.

Anyway, Python is intentionally not functional because Guido dislikes functional programming