Re: [racket-users] On Richard P. Gabriel’s “The Structure of a Programming Language Revolution”
> and using version control as the primary source of truth. Reproducibility is important. > 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 I want to voice what I think is agreement that reliability of the rest of the universe is important (all that is not "the code right in front of me"). Correct output is a function of correct input and the correct function that processes it. So users are intentionally guarded against and programmers are responsible for config files and source. Everything else *has* to work. It's extremely confusing (time-wasting) to debug your code only to later learn the server has the old version of code on it, for example, or that, god forbid, gcc compiles 2+3 to 2+4 on 13 Aug every year. The config file is bad enough, but I don't know a solution to that, and it's under my control in my dev environment. It can definitely get confusing when the production environment malfunctions due to a config issue. But, the more confidence the programmer has in their code and the universe as a whole, the more easily they can just declare "it's probably the config". Programming Systems introduce additional mutations of the universe beyond the source code that effectively undermine the source code. The "referential transparency" between programmer thought and users' code execution is lost, unless the programmer manages to perfectly mutate their thoughts in parallel with the changes to the runtime environment. But we make mistakes with plain old code, so I'm gonna say, "not happening". On the other hand, mutation is for efficiency. If there's a case where refreshing all deployments after a source change takes far too long, a compromise may be needed. But I don't work in a sufficiently complex product that would benefit from ditching reliability in favor of tinkerability, and if it was that complex, I'd probably prefer reliability! So, I recommend sticking with "Racket AST implies the set of program outputs". -- 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.
Re: [racket-users] On Richard P. Gabriel’s “The Structure of a Programming Language Revolution”
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
Re: [racket-users] On Richard P. Gabriel’s “The Structure of a Programming Language Revolution”
I will (probably foolishly) wade in first: TL;DR: I think there's been a change in what it means to be a "long-running system". Once upon a time, you owned a single expensive hardware box with _extremely_ limited/slow (by today's standards) RAM, CPU, I/O, and persistent storage. (Maybe you owned more than one of these boxes, and could network them, but that was relatively slow, too.) In that scenario, the "system" is a precious thing you continually mutate, tinker, and poke in-place. What else could you do? It's similar to owning a house that you maintain and extend over months and years -- and you have to live in it during the ongoing construction. These days, each computing instance has considerably more resources. And also: The instances are disposable things you can provision on-demand. And also: You can even allocate "containers" among one or more of them. Each of those containers can be immutable, reproducible, and so on. So I think the "system" is now this higher level of resource allocation. Keeping it long-running doesn't mandate the language level to be mutable and reflective and tinker-ish. Instead of one precious house that must be maintained while you live there -- it's more like you deal in blueprints or designs for a house factory. Or, maybe it's like AirBnb. Analogies are hard. :) Related: I think there's been a shift from primacy of the executable image and hardware, to primacy of source code -- and using version control as the primary source of truth. Reproducibility is important. The executable and the thing it runs on are merely discardable optimizations, like a cache. -- 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.
[racket-users] On Richard P. Gabriel’s “The Structure of a Programming Language Revolution”
Hello all, I have a rather different sort of question to ask about from my usual fare. A month or two ago, I read an essay written by Richard P. Gabriel and published at Onward! 2012 called “The Structure of a Programming Language Revolution”. The essay itself is available here to those interested in reading it: http://dreamsongs.com/Files/Incommensurability.pdf The essay covers a number of things, from CLOS and Smalltalk to the concept of incommensurability, but one of the things I found most intriguing was this thesis: > The real paradigm shift? Systems versus languages. Before 1990, a > person interested in programming could work comfortably both in > programming languages and in programming systems, but not so easily > after. To tell the truth, I never even noticed the different words — > language versus system — never attached any significance to the word > choice until this exploration. I used the phrases interchangeably for > many years: Programming System / Programming Language. Gabriel goes onto elaborate on the difference between so-called “systems thinking” and “language thinking”. From his perspective, Common Lisp sits squarely in the “systems” camp, and Scheme in the “language” camp. He makes the claim that the amount of effort Common Lisp dedicates to things like redefinition to support a running system are the effect of systems thinking, which has more or less fallen out of favor in the academic community in recent decades. This got me thinking about Racket, since much of Racket sits firmly in the language thinking camp. Racket focuses on the language being a single source of truth, on soundness, on syntactic properties and formal semantics. It discourages things like long-running systems and dynamic reflection. On the other hand, Racket is clearly made up of many systems in addition to its many languages: the macro system, the chaperone/impersonator system, and the namespace system all come to mind. (On the other hand, perhaps the line is much blurrier than Gabriel would have one believe: do contracts really belong cleanly to either philosophy?) Since then, I’ve wondered what thoughts other Racketeers would have in response to Gabriel’s essay. The ability to have a live, dynamic system akin to Common Lisp’s images is a useful feature, but it certainly requires “systems thinking”, and it is unsatisfying from a “language thinking” point of view. To pose a question to those who have been doing this longer than me, do you think this proposed philosophical binary really makes sense? Does Racket really fit in more closely with one or the other? Philosophically, does Racket reject things like CLOS and redefinition/long-running images just because they don’t work in the edge cases, or is there some bigger picture here that I’m not seeing? Thanks in advance for your thoughts, Alexis -- 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.
