Oh, look

DeepMind and OpenAI win gold at ICPC (codeforces.com)

So, a model memorized a lot more of a convoluted stuff and been able to spit out a coherent code.

While this is absolutely amazing considering that it works at the level of syntax, and that its “representation” captures only “possible relations among tokens” and posses no “understanding”, thinking leave alone reasoning capacities whatsoever. It just picks up one of the few next most probable tokens, given the previous “context” (a sequence of tokens “so far”).

Perhaps they throw a bunch of seemingly relevant tokens in the “context window”, as they do nowadays by loading verbiage from web pages – I do not follow these developments.

Those results, however, have nothing to do with programming excellency, no mater how it could appear to normies, how it can be framed and presented to them.

The very same model will fail miserably at a real programming task (as they fail at some of my “sophisticated” prompts).

Here is something to consider. We have a very few amazing, wonderful, profound [insert more adjectives here] emerged traditions, usually centered around some deep realization or discovery (LISP, ML, Erlang, and so on).

There are another two “great traditions” absolutely worth knowing, understanding, preserving and improving:

  • GNU Emacs
  • Vi (Vim/Neovim)

The beauty of the original Vi editor and some of its ancestors comes from the “deep realization” that a text and especially structured text, and a programming code, which is just a structured text, has a common underlying structure (which can be reduced to “nested DAGs”, just like almost everything else) and that this common underlying structure can be systematically observed, navigated, extended and modified (transformed).

Intuitively it has been understood that what we call BNF (a simple formalism), and what we call Regular Expressions (an advanced formal system) capture the same universal notions and that there are a correspondence between these and Vi’s “editing abstractions” over structured text. This is what the corresponding “tradition” centered around.

The implementations, however, are messy and crappy, because way to many [good] people throw low effort solutions into them, which then has to be [rightfully] preserved. Some “technical debt” has been adressed, like replacing absolutely crappy vimscript with a decent language, while keeping all the old useful scripts running, by preserving the execution engine.

The real task would be to carefully re-design and re-implement very clearly, with a super-human attention to details and reduction to the most essential and properly generalized concepts (which would be, again, just “nested DAGS”) the “base ADTs and Layers of proper abstractions " for a structured unicode encoded text, and to add the old “engines” on top of them, so the old scripts in both vimscript and Lua would still run.

The same retrofit could be done for Emacs – clarifying and debloatig Emacs Lisp DSLs and Layers of abstractions, and rewriting all the UI code (which is already a humanly-impossible task).

The key point is that properly done layers of abstractions could reduce the code size and the complexity by an order of magnitude or two, just to the size comparable to the size of a mathematical model, which captures all the structural and functional relations of arbitrary nested structured and implicitly tagged sequences and directed graphs formed from these.

Every model in existence will not only fail these tasks, they would not be able to “grasp” what needs to be done and why, simply because no one told them that this can be done.

And yes, there are “just right” representations and implementations for almost everything, because the underlying universal structures are simple and well-understood properly captured abstractions.

This is possible because mathematics itself is just a set of such properly captured abstractions (as “informally” defined ADTs) and the corresponding DSLs (particular notations).

It has been imperially demonstrated, that when a high-level language can be build around a proper data abstractions (PG’s Arc, MIT Scheme) the language can be small, expressive and high-level at the same time.

It has been shown that focusing on proper abstraction barriers can lead to smaller, decomposable, layered complex systems (MIT Scheme implementation, Erlang).

Another example of a small high-level language, built around a central abstraction (a table) is Lua, and Luajit, arguably, is an example of how a runtime can be small and less convoluted (while it can be definitely be less cryptic).

Given a proper high-level language, without a low-level type clutter, and, ideally, without such clutter at all (typeinference in Haskell), things can be orders of magnitude smaller. Sussman (the great Wizard) wrote Edwin (which is part of MIT Scheme) and it is some few hundred Kilobytes .

And no crappy imperative looping constructs are required in principle. the Layered DSLs has to be declarative – what has to be done, not how to do it. Composition of abstract interfaces (like it is currently done in decent language like Scala3) will do. This has been understood at least since CLU, and this is what classic functional languages did.

Common Lisp’s looping macros (micro DSLs) is another great example.

So, this is how.

In general, it was well-understood that having proper abstractions and staying at this level within the language and the DSLs will reduce the code size and complexity (SML/NJ Basis Library). The LIsp Machines and Smalltalk systems demonstrated, that this principle applies to the whole systems.

In summary, if there is anything AI could show us, is to rewrite from the ground up what has been discovered and realized to be “just right”, propetly captured. Usually, people who have at least intuitive understanding how this can be done have nether energy not motivation to do it, and most of people who can code simply have no understanding.

It has been understood that one should not build crappy imperative VMs, but build graphs out of expressions and use a Graph Reduction Abstract Machine to do computation. Can AI reimplement this part of Haskell cleatly, principle-guided, from the ground up, throwing away all the wrong decisions? No, it can’t.

Can it re-implement from the ground up, using all the insights and emetgent syntactic and semantic forms and “constructs” of the Vi family of editors, in a proper table-centered highlevel language specially crafted for such partocular set of data structures? No, it can’t.

How about a much smaller and cleaner set of modules which export proper layers of ADTs “emergent” after almost 50 years of a “high-level” Lisp-based Emacs, including extraction and generalization of the best parts from org-mode, which is otherwise a mess, why no?

So, if they really want to show us something remarkable their “AI” can actually do, show us something like this – something that everyone could say “Ahhh”, something that approaches the pefection (or a fixed point) “when nothing more can be taken away or removed or improved”.

Mathematicians know that such “things” do exist, and that there are actually a lot of them. Good programmers know that “ideal” implementations do exist (early attests of LISP implementations, using universal “tagged values” and whole in-memory structures made out of those). There is a vast literature on interpretens and compilers, which show the limits of what is possible.

Ok, just write a decent Vi, or a better Lua, or a better Arc, or extract the proper ADTs and Layers of abstractions emerged after decades of vi and Emacs traditions and reimplement them in a small high-level languages, crafted around this particular layer of abstraction, just like Math itself.

Yes, yes, I know. But your “AI” is an utter crap then.