A Review of the Art of the Metaobject Protocol (2010) [pdf]

I think Go's context objects serve a similar purpose to dynamic scope?

https://pkg.go.dev/context

It seems like pretty much anything that lets you pass in an environment as a function parameter would work.

Implicit parameters seems to be the principled dynamic scoping for statically typed languages.

Implicit parameters are in the list of must-have features for the programming language I'll never get around to implement.

This is effectively how globals are handled in Lua: they are first-class environments, ordinary tables which can be assigned to a function (5.1/LuaJIT) or upvalue (5.2+) to resolve globals.

I like it a lot, it's a supplement to lexical scope: like ordinary globals it's a flat namespace 'behind' the locals, unlike many implementations of globals these environments are replaceable and (mostly) fungible.

The Smalltalk of 1972 is not the Smalltalk of 1980.

I have only a passing interest but Rust is based on ideas in the late '80s concerning linear logic and affine logic and their relationship to PLT. Monadic programming and its applications to for instance parser combinators is from the early '90s.

> ... it doesn’t really look original, but more like a polishing of Perl.

Sure, Raku has its roots in Perl. But if multiple dispatch is the big thing for Julia, why wouldn't it be for Raku?

Other things Raku has that Perl doesn't have: - grammars built in, in fact Raku itself uses a Raku grammar to parse itself - a sane and genuine async / multi-thread / event model - Rational arithmetic, big integers and complex numbers by default - lazy lists: say (1..Inf)[42] won't hang - Junctions; a == 42 | 666 | 314 - Gradual typing and coercions

> I am not familiar with Raku, but

Perhaps it's time to familiarize yourself a bit more with Raku :-)

> Mathematica dates to the late 80s

It's pretty similar to Wolfram's early-80s math language which he abandoned after a rights dispute with Caltech, where he'd been employed at the time.

As with all arguments about "not really innovation", the problem seems to be in drawing boundaries around ideas. If people in the 1980s and the 1990s were all really reinventing Kay and Mccarthy, then why weren't Kay and Mccarthy reinventing Turing and Church? Why weren't Turing and Church reinventing Russell and Frege? Are we going, like 1 philosopher called the entirety of philosophy and its history as a "series of footnotes to Plato", to call the entirety of CS and its history as a series of footnotes to Leibnitz ?

In some sense of the words, all of this is true. The human brain is just a finite configuration of 100 billion object after all, and as you zoom out to more meaningful levels of abstractions the set of distinguishable states only get smaller. Shoulders Of Giants, etc etc etc. So, off course whatever you have thought of is not original if you zoom out far enough. My only question : why stop zooming out at the arbitrary cutoff of the early 1980s? Lisp dates back from 1958, Algol from 1960, Simula from 1962, APL from 1964; those 4 together are essentially all of programming language design summarized into 4 specimen in the same way that [bird, fish, ape, virus] are essentially all of life summarized into 4 specimen, don't you agree? so 'essentially' all programing languages were invented before 1965, even more essentially before 1970. What makes this 'essentially' more false than your essentially, which just moves the cutoff 20 years later? Types are just fancy sets right? Sets are ancient, all of type theory is 'essentially' reinventing Russell and Whitehead.

In essence, Computer Science was invented before it was born, and that's literally true in a very peculiar sense : CS is an outgrowth of a delightfully bizarre intersection between Math, Logic, Physics, Information Theory, etc... that was always there as long as those fields existed by any name or the other, it was just recognized as special in the 1940s-1960s and given a name.

So, before I push back on your particular claims, I will grant you that there is indeed a very particular sense in which you're completely correct, but I don't find that sense convincing enough. You can always find the very special and peculiar way\interpretation\precondition in which any statement can be true if you're patient enough, there is a glimmer of truth in every statement no matter how bizarre. I don't mean to say your claim is bizarre or obviously false, it's not, but it's not obviously plausible or even a useful way to view things either in my view.

--------

>> 1980 is the debut of Smalltalk.

>1972, actually!

I should have clarified that by 'debut' I mean the general release of the Smalltalk VM to non-XeroxParc audience. This is an important milestone because what followed was a 2 decades (smalltalk fans would say 4 decades and counting :)) of research and enhancement of all ideas surrounding the language and the paradigm. One particularly beautiful direction is Self, which invented prototypical OO, and was the first to articulate and implement the idea of "Extremely Smart Runtime-Adaptive Compiler" publicly as far as I know. Isn't this another hole in your claim?

>Finished in the mid 90s. But Lisp was around well before the 80s, and CL was in a lot of ways a standardisation of the practices developed in the 70s & 80s.

What I'm saying is, why bother stopping at 1970s? When you can just as easily say that Lisp was largely finished by 1965 ? You wouldn't be qualitatively more wrong, only very incrementally.

>Python is just an unacceptable Lisp (1958), and Ruby is by analogy an unacceptable Smalltalk (1972).

Lisp is just an unacceptable Lambda Calculus (1935).

>The JVM is just refinement of ideas dating back to UCSD Pascal (1977), and the CLR is just an embraced and extended JVM.

I will just play my same old unimaginative game and ask you : why stop at UCSD Pascal? Search for "Virtual Machines" on the ACM repository, you will find hits from the early 1960s. Bytecode is an idea that falls extremely naturally out of the idea of pseudo code, which assembly programmers were using extensively since the early 1950s, indeed the first proto-languages (Pre-Fortran!) were just bytecode interpreters (except the bytecode was written directly by the programmers, and that was a improvement over hardware assembly). Fortran compilers for the IBM 1401, to give a specific and far-from-the-only example, consisted of about 60 or so passes that began with human readable text and ended with machine executable bytes, every IR in between is just begging you to discover the idea of a formalized bytecode format and, from there, the Entire Thing of VMs. The Apollo project (1969 launch, software developed from 1965 to 1969) software engineers explicitly embedded a VM for vector math inside the code, and wrote a big part of the vector-heavy navigation code in its bytecode. An honest-to-God VM, that interpreted its bytecode at runtime. People Knew The Stuff.

What did Pascal VMs do? they were the first to, publicly and popularly and with extensible implementations, evangelize and elaborate on the ideas known for 20+ years. In other words, Not Really Progress (^TM).

>partial evaluation in Lisp in their 1980 paper On compiling embedded languages in LISP

And the entire idea dates back to Futamora projections from the 1970s,that's not the point, the point is the vast amount of learning and research and development that happened since then. Like I said above, if you're only concerned with the raw beginnings of the idea, then types are just a trivial footnote to Sets and (more generally) Category Theory, both extensively elaborated on from the 1900s to 1950s. Sets, in particular, are "just" a kinky way of denoting natural numbers, sooo... Do you see where this one is going?

>Haskell was strongly influenced by Miranda

I think you're familiar enough with my "But Why Stop There?" game that you can play it yourself here, but I will just note that Haskell's incorporation of Lazy Eval into the entirety of the language was something unprecedented as far as I know, so there's that, 1 ground-shaking idea and all of its myriad consequences on the language and its design.

>F# is another member of the ML (1973) family. ‘Something old, but this time on a new VM!’ isn’t really progress, is it?

>Scala is OO (60s) plus functional programming (50s)

><other languages>

All of those have a ton of new things to offer. As examples, F# is far from a generic ML clone, just look at active patterns and type providers. Scala gives people who venture too deep inside it ptsd, although I haven't experienced it myself. Julia and Mathematica have macros without being as braindead as Lisp on syntax, which is a massive improvement and refutes a point that Lisp fans love repeating till today. They aren't the only ones, Elixir (which wouldn't have been possible without Erlang) is another, among many others. Perl and Mathematica's legacy is Extreme Syntactic Flexibility, Mathematics goes as far as making diagrams and images first-class-syntax, all the while representing Syntax as nested lists underneath. Raku is the first general purpose language to give BNF grammars full first class's citizen status.

Like I said, it really seems to me you're doing "All of life is just birds, viruses, fishes and mammals, what's new here? Biology is done".

> The industrial policy of the United States is that critical bottlenecks in software progress, foundational for the economy and societal progress, are best pursued by individuals doing hobby projects in their spare time, and by research slow-mo stretched across decades.

Meanwhile VC pours funds into 'no-code' tools that represent unprincipled grasping in this critical problem space. Of course at some level of software sophistication you are going to need 'code', that is a medium of programming, and there isn't any real reason that a programming language in the tradition of Lisp or Smalltalk could provide those same end-user facilities, just stymied progress from lack of DARPA level follow ups and rapidly shifting business models. I blame, in equal parts, Java, the Web, and Ronald Reagan for where we are today, though that is no excuse for us hobbyists to keep trying to solve critical software bottlenecks. Who knows, maybe the next Big Thing in programming languages won't be yet another weekend project gone supercritical with a cranky BDFL, last second design, and toxic community - maybe it will get out of its own way and help people build the software that they need.

I feel compelled to note that I was cribbing my observation from a similar one made by Guy Steele, who ran into similar trouble finding a non-trivial example to justify the necessity of tail calls in an object oriented language [1]:

> (someone's criticism): The objection to TCO that you're trying to answer is that it's rarely helpful in the real world. So you have to find real-world examples to refute that. An impractically-slow set isn't a real-world example.

> (GLS response): I wish I could fit a real-world example onto a blog page. The best I can do is to exhibit a "toy" example that illustrates the basic idea.

[1] https://web.archive.org/web/20110716163344/http://projectfor...

Well I did it in Scheme, but there's no reason it wouldn't have worked in Julia. If you're interested in this, the relatively recent Software Design for Flexibility by Chris Hanson and GJS [1] has a pretty good couple of chapters on creating a generic procedure system (and a lot of other really cool things). Edit: In fact, it has an example doing just this example: symbolic alternative evaluation. Where they get the closed form solution from a simple differential equation solver without changing any code in the solver.

Now that I think about it, this idea is pretty much how automatic differentiation works in Julia. (Really everything in Julia.) You can look at the libraries Flux.jl and Zygote.jl. There are probably more now, I've been out of the Julia ecosystem for about a year or so.

[1] https://mitpress.mit.edu/9780262045490/