Back in ’12, Dick sent out the essay for early comments to a bunch of us. I replied to him personally with some longish emails and I am excerpting two relevant pieces below. I have erased my response to Dick’s comments on Mixins and his conclusion visa some “revolution” from this single paper. In my mind, he fails to see how academic PL researchers work, how conferences evolved and ‘killed’ PS publications, why this was easy for them (and remains easy). What you see below is a rationale why this may not even be a bad thing.
;; - - - Here is a direct response to this thread. ~~ The PL vs PS distinction is also one of “static” vs “dynamic”. As far as I am concerned, this isn’t binary at all. It’s a spectrum, and as always, both ends are problematic and the true solution sits in the middle. Lisp and, with it, Scheme definitely started out in the “systems” camp. Lips machines made this totally clear (we owned two, and Shriram still has one of them in its office) but even the way I grew up on the Scheme REPL was “systemish.” As Dan Friedman and I worked in the REPL though (for the books), we got ourselves confused on occasion and the more it happened, the more it became clear to me that we needed to shift to a more static view. What I wanted from a static view as the unencumbered freedom to work with an untyped language — not just with a “universal type” in a statically typed language, which is NOT the same as what we do but I don’t know how to tell “adults” — and to gradually shift to a more static program. The first thing was the REPL. Dan and I would still use the REPL on rare occasions as the thing where you can patch a closure, go back into the top level REPL, and resume the computation. Is this useful? Of course, every long-running or slow program needs this. The faster we got, the less important this was. BECAUSE when you did this, you easily confused yourself. So we re-started the REPL almost every time and experimented there. See where the Dr repl comes from? Here is a simple inside-the-PL example. Imagine a world where everything is encoded as a list, a world w/o records. As Perlis says, you’re better off with a data type and a 100 functions than 10 data types with 10 functions each. Nice, so all data is represented with lists. You cannot imagine how easy it is to confuse one form (“type”) of data with another one in such a program. It’s like in ASM. As long as there’s a bit pattern, the CPU will process it until the hardware crashes. Same for Scheme programs that use lists for everything. We introduced structures and life got infinitely better. Can you imagine living without structs? At the ’86 Scheme workshop, I proposed a separation of data cons from syntax cons. People laughed at me. Can you imagine programming with plain S-expressions when you deal with syntax? So yes, Racket shifted from a PS to more of a PL and my philosophy is visible. We are in the middle now. As always, it is hard to defend the middle because nuance is hard to defend. And with the creation of the ‘Web, we finally have a place where nuance got totally buried. ;; - - - Email excerpts from my 2012 response to Dick’s “early warning” > Your essay points to 'programming systems' as one possibility, which to me > means "MIT/Stanford/Lisp machine companies" and "Smalltalk". From what I > understand 'MIT' Lispers thought of Lisp programming as walking up to a Lisp > machine and adding more material to the always-running REPL. As Carolyn put > it one day, "push the ball of mud a bit further through the mud" and she said > she was quoting John. . . . [ Carolyn ~ Carolyn Talcott, John ~ John McCarty; Carolyn was John’s second wife ] . . . > let me add a piece that I pruned from the original message. The piece > concerns the difference between programming systems and programming languages > and why work on the latter is so appealing when you assume 'average' > programmer. [I personally consider this word meaningless because I think bad > programmers _subtract_ from projects, so I don't even know what it means to > calculate 'average'.] > > At any point in time, a programming system is in a state. To program the > system means your contributions change this state and make the system act > differently. One of the insights from my dissertation is that it is (almost > always) possible to reify this state as a program. [This was later turned > into the standard method for stating and proving well-definedness for a PL or > as they say "type soundness" except that you can state/prove such theorems > for untyped PLs too.] In that light, programming a system isn't all that > different from working with "just" a programming language. > > When you work in a programming language, the illusion of conference papers is > that you write a program P, which is a well-formed element of some grammar G > and has some semantics S -- and that is it. But this isn't true at all. Even > in a modest PL, you 'link' P with the run-time system that goes with your PL > and the semantics S of P is really determined as a function of both. Acting > as if the run-time system didn't exist or is just some ignorable piece of > program P' in the same grammar G is a bad idea. It leads to misleading > simplifications. For example, I consider my recent work on gradual typing > (with Sam Tobin-Hochstadt) as the first real type-soundness theorem. In a > sense Milner ignored that even ML programs are linked with run-time libraries > that contain untyped ASM and he never considered the question of what this > linking means. Once we raised this question, answering it revealed several > interesting insights and showed us that old proof-techniques just don't work > and that the results aren't truly interesting in a sense. The ML engineer in > Milner understood this intuitively and therefore restricted the interface > between ML and ASM to simple exchanges so that it mostly made sense. > > Now let's put those two ideas together. If you can reify the state of a > programming system as T and add a piece of code P you are looking at > programming in a PL where every P is linked to T -- which is kind of like a > very complicated run-time system. In a sense, the two things don't really > differ! > > BUT they do differ in that the run-time system of a PL is usually simple (see > above, Milner) and the interface between the run-time system and the programs > in PL is highly constrained. In a programming systems world, the run-time > system is a ___different___ one every time you program and the interface is > ___wide open___. Which brings me to the technical conclusion: > > for programs created in a program LANGUAGE, it is much easier to predict > their meaning than for programs create in programming SYSTEM > because the (connection to the) run-time system of the former is fixed, > known, and predictable for the former and > variable, unknown, and unpredictable for the latter. > > This is what semanticists mean when they say "we want programs that carry > their complete semantics on their sleeves." And they believe that such > programs are easier to understand for 'average programmers' and I tend to > agree with them. > > Where you and I agree is that PSs make certain kinds of great programmers > much more productive than PLs. But it is an argument based on select elites > and it comes without measurable evidence (as far as I know). My advisor (Dan > Friedman) used to express it like this in the 1980s: "Software crisis? What > software crisis? Just put all programmers in front of a Lisp machine and your > crisis is over." But given the vast number of people who practice what they > call programming this approach failed, just like the Lisp machine > architecture failed given the vast number of fast off-the-rack hardware you > could use to build alternative workstations. My replies were temporarily deleted due to some . . systems problem during Dick’s move to IBM . . and when he found them, it was too late to affect the essay. — Matthias, radical centrist possibly the last one -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
