Matthias Felleisen

Oh, you think there should be an actual counterargument to the proposition that Scheme is "not a Lisp"? Well, okay.

This is of course a purely semantic discussion, about the meaning of the word "Lisp" (and "Scheme", if you like). Words are defined by their community of users, and you are of course free to use them however you like, at the risk of talking nonsense and tricking yourself into logical fallacies if you adopt an inconsistent meaning, or failing to communicate if you adopt a non-mainstream meaning. So let's consider whether the mainstream meaning of the word "Lisp", that is, the usage of the word among Lisp experts, includes or excludes Scheme.

This runs into the difficulty of determining who "Lisp experts" are, since that depends on what "Lisp" means; we could run into a schism like the Protestant/Catholic schism, in which each side considered themselves to be the guardians of, and experts on, the true meaning of Christianity. To avoid this problem, presumably we can all agree that at least the people who wrote the Common Lisp specification or major contributions to it, who are credited as major contributors to "Lisp" in the Common Lisp standard, and who have published well-regarded books about Common Lisp, are "Lisp experts", independent of the results of our inquiry about Scheme. (I am taking the liberty of supposing that your comment above implies that Common Lisp is a Lisp, despite its departure from traditional Lisp features such as fexprs, fsubrs, and…

> I don't care about "power" for a language construct. I need guarantees a lot more. Does using this construct allow me to put some things in the "that doesn't matter here" bin, so I can focus on some things without worrying about everything at once?

Conditions and restarts aren’t much better or worse than standard exceptions in that[1] respect.

You can basically implement them[2] on top of those + dynamic scope: the gist is that when an exceptional condition happens, instead of destructively unwinding the stack immediately the code only invokes a callback (selected by condition type, installed by some dynamically enclosing code), which then can choose one of the available handling strategies and unwind the stack to the requisite point (using try / throw if implementing on top of that). The fun part is that it can unwind less than to the point where the callback was installed: e.g. a REPL installs a handler that, on an undefined variable error, asks the user interactively for the value to use instead, invokes the language-provided USE-VALUE restart and proceeds; no debugger-level carnal knowledge of the language runtime is necessary at any point. (Compare also the DOS abort/retry/ignore prompt. Win32 SEH is also capable of expressing a certain degree of resumable exceptions not exposed by C++ runtime, as seen in classic VB’s On Error Resume Next—though that is admittedly a bad idea.)

The advantage[3] of this construct is that it enables you to structure APIs differently,…

IMO a couple of cool aspects of Racket that aren't called out in beginner guides, but I think are really useful in real programs:

1. The use of custodians on a per-(green-)thread basis that brings "oh yes, if the thread crashes or is shutdown, racket guarantees that all open files/sockets/resources will be shut down". For example you can use this to ensure that a timed out client doesn't cause unnecessary resource usage. https://docs.racket-lang.org/more/index.html#%28part._.Terminating_.Connections%29

2. Events and composable concurrency from Concurrent ML - Unlike Go's channels, concurrent ML events are composable up the stack, and have some nice things built in like "NACK events" (allowing cancellation down the stack). Unfortunately there aren't great primers about using this that I know of apart from the Kill Safe Synchronization Abstractions paper. https://users.cs.utah.edu/plt/kill-safe/

3. Sandboxing - https://docs.racket-lang.org/reference/Sandboxed_Evaluation.html

Some of these were added to make it easier for the IDE to manage errant programs that could be written by beginners, but it is also a very "applicable to production" set of tools.
Racket internalizes Extra-linguistic mechanisms https://felleisen.org/matthias/manifesto/sec_intern.html

Also the fact that various DSLs can inter-op with each other directly, so that you can use something like a binary parser description, as if it was just another Racket library. For example this description of the format…

I know Shriram very well, he and Kathi do excellent work and as I said they are focused on more valuable projects than trying to prove one language is superior to another for CS1. They are building tools and curricula, and have done some research that sheds some light on the tradeoffs in using certain languages like Racket. Kathi's "Rainfall Accumulates" paper is one of the few papers that gets close to work in the space I am talking about. Shriram's analyses often leave me stunned at just how sharp that guy is, and helps remind me that CS Ed really needs to level up its game.

That said, the HtDP curriculum that they were involved in, and led to Bootstrap and a host of their other projects, was not grounded in any kind of data collection or treated as an empirical research project. Smart people with good intentions built something and threw it into a classroom. Intentionally so, by design [1].

Their subsequent work with Pyret is much better grounded and well-informed, and I've been absolutely fascinated by it. Their data science curriculum delights me, and I have often thought that if I had more time I'd translate it to Python. I think their more recent proposal about a Table Abstract Data Type is just inspired. But we are still VERY far from ever proving things like, "Racket is easier for students to learn". I'm fairly sure it's not even worth doing.

I appreciate the original article was just one student's perspective. It's a perspective I don't entirely disagree with.…

I have found that the best way of learning the HtDP approach to program design, at least for me (I find the book itself a bit dry), are the EdX "How to Code" free moocs [1] [2]. The instructor is fantastic. It completely changed the way I program and design.

If you like the approach and want to learn more, like, for instance, how to extend it to OO design, I list below links to several courses (most, except for the last one, offer enough material to complete them on your own, but I couldn't find any videos) at the university where HtDP's main author, Matthias Felleisen, is tenured (North Eastern). The courses are listed in the order in which they should be taken, and the rationale is explained by the professor in the paper "Developing Developers" [3]:

* CS 2500 - Fundamentals I [https://course.ccs.neu.edu/cs2500/]

* CS 2510 - Fundamentals II - Introduction to Class-based Program Design
[https://course.ccs.neu.edu/cs2510/index.html]

* CS 2800 - Logic and Computation
[https://course.ccs.neu.edu/cs2800/index.html]

* CS 3500 - Object Oriented Design - Spring 2018 (scaling up the 3 previous courses) [https://course.ccs.neu.edu/cs3500/]

* CS 4500 - Software Development [http://www.ccs.neu.edu/home/matthias/4500-f18/index.html]

[1] https://www.edx.org/course/how-code-simple-data-ubcx-htc1x

[2] https://www.edx.org/course/how-code-complex-data-ubcx-htc2x

[3] http://felleisen.org/matthias/Thoughts/Developing_Developers.html

Julia combines the following:

- multiple dispatch

- parametricity

- lightweight subtyping

- staged programming

In interesting ways.

felleisen's class talks
(partially) about it here: https://felleisen.org/matthias/4400-s20/lecture15.html

I guess the best way to put it is that Julia encourages a style where 90%+ of code can go through paths that are static.

Personally, I think Julia starts off as easy as python, but to get C++ or Fortran speed, you can't just code naively. Things go into a steep learning curve at that point, but perhaps there isn't yet as much know how about how to code "professional Julia" yet. There needs to be a book like Fluent Python or Effective C++ for Julia, or perhaps a condensed version of the Julia manual (see the 1 page zig manual for inspiration).

The other problem I have with Julia right now is lack of static type checkers. "modern python" (e.g, python in production in the last 5 years) tends to leverage the large ecosystem of things that hook into mypy (I'm taking about tools like pydantic) to reduce the inherent brittleness of the language. Ruby, php, and every other dynamic language has also seen that trend.

Right now, I've barely seen that with Julia, and it needs this badly for higher uptake in industry. It's why for example, perhaps you see a lot of Julia packages written for people's phds right now.