Future of Coding History
Visual interface for building streaming data pipelines natively on Apache Kafka
Rapidly build, test, and deploy pipelines using a visual canvas extensible with SQL
confluent.io/blog/building-streaming-data-pipelines-visually
I really appreciated the latest FoC ep about "The Structure of a Programming Language Revolution". I'm in The Academy, and I'm perpetually fascinated by what's happened to academic PL. This essay provided some missing links. Thanks Ivan Reese & Jimmy Miller!
One fun aha I had afterwards: The systems vs. languages distinction helps clear up something I've always wondered about prototypal object-oriented programming. Namely, why use prototypes at all? Rather than writing:
// Version A
function Dog () { }
Dog.prototype = {
bark: function () { ... },
fetch: function () { ... },
}you could just write:
// Version B
function bark () { ... }
function fetch () { ... }
function Dog () {
this.bark = bark;
this.fetch = fetch;
}Sure, maybe that's a hair less ergonomic. There's a (extremely tiny bit) more memory used to store the slots. But that hardly seems worth inventing a whole new language feature and making such a big deal about it.
I think part of the answer is that prototypal inheritance was born in Self, a programming system . If you want to modify a "prototype" in a programming language , the two approaches above are equivalent. You modify the (literal) prototype in version A, or you modify the constructor in version B, and then you re-run your code. But if you want to modify a "prototype" in a programming system , you'll discover you already have a bunch of instances of the class running around. Version B doesn't work, because it only changes how new instances are constructed, not how existing instances behave. A live connection between the instance and its prototype is required to enable live development in a living system.
I feel like Dan Brown over here, finding secret traces of the past in the present.
(Ominous hole in my theory: This doesn't explain why prototypes were brought into Javascript, where they ostensibly no longer had much use.)
Allow me to try to add some more context...
[tl;dr]
[background]
In the beginning there was assembler.
There are 2 types of assembler
Assembler is characterized by
Line-oriented assembler is what we call âassemblerâ.
Tree-oriented assembler is what we call âlispâ.
Assembler gives you a toolbox of functionality, but, if you want to structure your data you have to do it manually.
In assembler, nothing stops you from re-structuring your data on the fly.
The result, though, can be hard to understand. This is part of what we call âreadabilityâ. The term âreadabilityâ is usually used to mean human readability (aside: but, thereâs also machine readability ; note that textual âreadabilityâ does not mean the use of general English prose, but, only a well-defined, restricted subset of English)
One of the tennets of Computer Science is Donât Repeat Yourself (DRY).
Inheritance is simply a way of structuring data in a DRY way. If youâve structured your data, donât do it again, copy the template.
So-called âprototypal inheritanceâ is a way of structuring data that can allow changes to the structure at runtime.
âClass-based inheritanceâ is an optimization of prototypal inheritance. In class-based inheritance, you separate your Red Smarties from the rest (a Smartie is an M&M, a âred Smartieâ tastes âbetterâ). If you apply the class-based optimization, then, you can compile-out data structuring. The compiler can help make your resulting code tighter and more check-able, but, you are allowed to structure your data ONLY at compile-time. And, the result is less-confusing. Nothing should change at runtime. Dynamic-anything is âbadâ (aside: this is a fundamental problem with pub/sub).
Optimization culls creativity, but, results in a notation that has certain âhuman readabilityâ properties. Optimization is âbadâ during Design (âpremature optimizationâ), but Optimization is âgoodâ during Production Engineering (what we mistakenly call âprogrammingâ).
Self and Smalltalk are syntaxes draped over assembler. Self does not insist that you pre-define all data structures, Smalltalk does insist on pre-definition. The tools for inheritance always existed, but Self coined the phrase âprototypeâ and Smalltalk coined the phrase âclassâ (actually, Smalltalk borrowed the concept from a previous language, but we wonât go there now).
JavaScript was originally based on Lisp. In trying to keep the flavour of a âdynamic languageâ, JS does not insist on pre-defining all data structures before runtime. IMO, JS does this better than the Common Lisp, the Scheme, the Racket, the Clojure variants of Lisp. In Common Lisp, the designers chose to jump directly to premature-optimization using classes and built that concept in as syntactic baubles (âdefclassâ), that cause programmers to think in a Certain Way, even though the tools for less-calcified data structuring are still present (but, generally ignored by class-indoctrinated programmers).
Ideas calcified by compile-time optimizations cause programmers to think in Certain Ways and disallow other interesting forms of Creativity.
There IS another way to optimize - as seen in JIT and 1970's compiler technologies (e.g. gcc, OCG) and linking loaders. Optimize at runtime. Treat optimizers as barnacles attacking only already-working programs. Premature optimization has led us to building and using compiler-appeasement languages and has snipped off other creative avenues of thought.
Or, we could more simply divide programming into 2 camps (aka âdivide and conquerâ): (1) Design (2) Optimize. This division happens all of the time in more mature industries - products are released, and, only later, the products are cost-optimized. In fact, this division is so severe that it is given the name âProduction Engineeringâ. In contrast, Software uses the single term âEngineeringâ to mean âArchitectureâ and âEngineeringâ and âProduction Engineeringâ and âTest Engineeringâ and âDeployment Engineeringâ, and ...)
If you Design and Optimize all in one go, you are involved in a Cottage Industry. In a Cottage Industry, the same person, or a group, wears all of the hats.
Class-based inheritance is Waterfall Design. You must know everything about the data before you can write correct classes. Prototype inheritance can be iterative, you can change your mind later, you can incrementally alter the templates as you learn more about the problem space.
Compilers can be built to compile programs if the programs obey the rules of class-based inheritance. Compilers cannot, in general, compile programs that do not follow the rules of class-based inheritance, e.g. compilers cannot compile prototype-based inheritance, but, can compile class-based inheritance.
[conclusions]
I would argue that Self did not invent prototypal inheritance, but corralled the ideas and created the name. Selfâs contribution is the exploration of the space of data structuring and of making optimization be a continuum that can be applied at different times - not just at compile-time. This exploration ultimately led to the concept of JIT.
JavaScript was designed to allow âdynamicâ programming (whether it succeeded, can be argued) and was originally based on Lisp. Prototypal inheritance is less constraining than class-based inheritance, therefore, was made a part of the design of JavaScript.
To me âsystemâ means âdynamic languageâ. And âgeneral purpose programming languageâ means âstatic languageâ. Each kind is âgoodâ and each kind is âbadâ.
IMO, all big inventions in programming stem from the use of dynamic languages, and, ultimately from the use of assembler. GC, first-class-functions, Haskell, REPLs, etc., etc.
The only difference between class-based inheritance and prototype-based inheritance is when it happens. Both, class-based and prototype-based inheritance can structure data at compile time. In prototype inheritance, though, data can, also, be structured and re-structured at runtime. Runtime restructuring is not allowed in class-based inheritance.
Class-based inheritance is Waterfall Design. Protoype inheritance allows iterative design.
miscellaneous:
3 OO-ish data structuring techniques
2 is like 1, with some of the compile-time-only restrictions removed. The mixin idea, 3, looks like OOP, but is very different. In class-oriented OOP, you have a vector of operations associated with each class. In mixins, the reverse is true - you have a class without operations. Operations âdecideâ on-the-fly if they can be applied to a cross-product of parameters. All three methods get rid of explicit âif-then-elseâ based on type (which is the really big win - âif-then-elseâ is just bad). Mixins go beyond simple class-based inheritance - you can specialize operations on /value/ instead of type, you can create :before and :after methods. Capability depends on the method (âoperationâ) and not on the class. For a simple, nonsensical example, you can write a âplusâ method that works on {int x int} and another âplusâ method that works on {int x string} and another âplusâ method that works only on {nil x int}
An Incremental Approach to Compiler Construction by Abdulaziz Ghuloum - scheme2006.cs.uchicago.edu/11-ghuloum.pdf
"Programmable Ink" by Szymon Kaliski (Strange Loop 2022)
Sketching with pen & paper is a powerful way to think through ideas, but ink on paper is static. Dynamic behavior, on the other hand, requires programming -- which lacks the immediacy of the canvas: it's indirect, abstract, symbolic, and full of bureaucracy. What if we could harness the power of modern tablet computers to combine the intimacy of ink with the power of computation?
Note: Ivan Reese @Szymon Kaliski and Marcel Goethals were involved in this project and a new iteration has started with @Patrick Dubroy
Joshua Horowitz was also involved, and a ton of other people who are not (afaik) in this Slack; thanks everyone! đ
Yeah, untangle overlaps considerably with the constrained, multiple-world tools I'm using, but with a much more human visual interface. What tool are you using under the hood to do the model finding and indicate if the constraints hold?
I love that if they don't hold, it tells you which don't, instead of telling you nothing.
Wondering.. the presentation of those three tools suggests that some common underlying technology is a commodity not worth discussing any more: the recognition of hand-drawn objects and their subsequent manipulation by code. Is that true? Are there well-understood algorithms for this? Maybe even ready-made implementations?
What tool are you using under the hood to do the model finding and indicate if the constraints hold?
this is built using a very small part of z3; if we hit unsat we permute the set of constraints progressively removing more and more of them until we hit some results -- is that what you were asking?
the presentation of those three tools suggests that some common underlying technology is a commodity not worth discussing any more: the recognition of hand-drawn objects and their subsequent manipulation by code. Is that true? Are there well-understood algorithms for this? Maybe even ready-made implementations?
to the contrary; there's pretty much no "recognition" happening in any of the demos (the very small exception is the delta symbol and star symbol recognition in the "sketchy charts" part) -- everything else happens by spatial relations from known objects -- this is definitely a big technical challenge, especially since "AI" doesn't vibe well with what we're after (it's an unpredictable black-box)
I was thinking of recognition at a lower level of abstraction. Such as recognizing a box or a tick mark as an object distinct from the other pen strokes on the page, and then moving it around.
Unrelated thought: these tools explore two roughly orthogonal aspects of computing: visual vs. symbolic, and formal/rigid vs. informal/fuzzy. I love the expression "tyranny of formalisms". I'll use it next time I talk to a static type system missionary đ
Such as recognizing a box or a tick mark as an object distinct from the other pen strokes on the page, and then moving it around.
yes, this is what I was trying to answer; we don't do that, and I don't think this is really possible to be 100% perfect -- for example a box can be drawn in 1,2,3,4 strokes (or more if you're sloppy), and then it's easy to make one that's slightly rotated, or skewed, or.... - I don't believe there's a heuristic that can cover all of that, and work out all the time -> so one direction from here is to do the best we can and accept that there can be errors/miscategorizations (which I think is not great -- because then you have to adjust how you draw things to make the computer understand you, and you're one step closer to just filling forms again), and another direction (that I'm more interested in) is to figure out different systemic approach to the problem so 'recognition' is not needed
Notes on this talk in my digital garden (on computer-aided research): science-in-the-digital-era.khinsen.net/#Programmable%20ink
Yeah, z3, plus permutations on constraints was the answer I was looking for, thanks!
In the early to mid-1990âs, I was composing a document and needed to find and insert some information from another program. To do this, I had to leave my text editor, search for and launch another application, browse for the information I was looking for, format it appropriately for my source needs, and then switch back to where I was in my original text editor. All of this took minutes, and more importantly, took me out of the flow of what I was writing. There had to be a better way, I thought.
As a result, I devised what I called âThe Invisible Interfaceâ. The idea was to use the computerâs clipboard as an interpretable information bus for retrieving information I wanted without ever having to leave the application, or even the very text line, I was working on. As an example, I would type something like, âPlease send the package to my sisterâs addressâ. I would then select and copy to the clipboard the phrase âmy sisterâs addressâ, hit a function key to request processing, and I would instantly hear an audio cue: âbingâ if successful, âbongâ if the system was not able to resolve the phrase to more specific information. If I heard a âbingâ, I would hit the paste command in my editor, and it would replace the selected text âmy sisterâs addressâ with âSara Cheyer, 123 Main St. Town, State, 91101â. I connected a myriad of databases and information sources, and could instantly and painlessly retrieve all sorts of information by a concise, direct phrase inserted in-line in the context of what I was doing: âpopulation of South Americaâs largest countryâ, âemail for my bossâ, âfree time on Thursdayâ, âflower in Frenchâ, etc.
-- Adam Cheyer, "Interpretable and Executable text", in The Future of Text (futuretextpublishing.com/future-of-text-2020-download)
sounds kind of like what google/amazon/apple/everybody is trying to do with an âassistantâ, but they have pretty bad incentives compared to what they were trying to build in this snippet
Maybe closer to the way that andoid/ios parse text messages to look for address, phone numbers etc and attach actions to them.
This sparked a loosely related idea. The clipboard could have worked the other way around - you "paste" into the location, then go and look for the thing to "copy" there. This would allow the computer to know the destination context during the search, which might be helpful.
That sounds vaguely like how Plan 9 UIs work.
This approach has been speaking more to me since I declared bankruptcy on the Unix terminal and wrote off all my accumulated expertise there as a sunk cost. When I switch to a canvas of pixels as a more timeless foundation I find myself building little keyboard shortcuts into the desktop environment that put things on the clipboard that I can paste into my canvas. For example I have a shortcut that copies the current timestamp into the clipboard, and another shortcut that prepends the current timestamp to clipboard contents.
This approach has been speaking more to me since I declared bankruptcy on the Unix terminal and wrote off all my accumulated expertise there as a sunk cost.
Do tell
It'll take a while, but basically there's an emergent story arc in the updates I have not been shy about sharing here over the last 4 years.
Reminds me of the idea in The Humane Interface to use selections as arguments to programs. I like that approach better. I definitely don't love the idea of combining "copying" something we're never going to paste with a subsequent operation explicitly designed to work on invisible arguments with maybe-invisible results (please never make anything dependent on audio cues, btw, personally I want my computers to be absolutely silent unless I'm specifically listening to media).
Increased visibility and selections are honking great ideas, let's do more of those.
Chris Knott I like this idea a lot, but not the "copy-paste" terminology attached to it :D. I might like it even better than the Raskin/Humane Interface idea of polluting your content with command arguments (I guess that made more sense when we didn't expect version history everywhere?).