screwlisp proposes kittens

More on LISP of the TIOBE index’s top 25 languages in 2025 being the only choice for developer and compiler maturity

The graph of Wikipedia’s given current-release age for TIOBE’s top 25 programming languages of 2025:

following up comments from the previous TIOBE LISP article.

Question: Why Not Include FORTRAN-77 and K&R C along with fortran current and C current?

Since, I guess, Fortran-77 would be 48 years old, K&R C would be 47 years old, and LISP (MacLISP, 1966) would be 59 years old since code from those is well supported by the more recent standards. From what I am told, the compatibility to F77 and C78 is deliberate backwards compatibility; I think MACLISP’s general compatibility with ANSI Common Lisp more resembles forwards compatibility that presaged the eternal status ANSI common lisp since attained.

The reason to not choose ages like this that favour enduring early languages like lisp is that my source was the 25 hot computer languages of 2025. It would be possible for MACLISP, K&R C, and FORTRAN-77 to have appeared in these top 25 hot languages, as we see with Visual Basic and Visual Basic '98 cohabitating in the list. It would also complicate my deliberately simple it-is-as-old-as-wikipedia-says-the-tiobe-language-name-current-release-is.

Comment: All the scheme revisions are done sufficiently compatibly that they would count as one continuous language

Allowing that this is the same point as for Fortran-77 and K&R C, someone else pointed out that r7rs specifically says r7rs should not be construed as a following on from r6rs.

On the other hand scheme is a great example and has a reasonable (though not primary) claim to the name Lisp: in context, schemers also often say lisp for their language in their writing.

The reason is that if scheme were in the 25 hot programming languages of 2025, it would be 12 years old (r7rs-small being the current-release), about two fifths the age of lisp-current, ANSI common lisp 1994, which makes it five times older than the popular, constantly morphing languages in TIOBE’s top 25 2025. So it might hint if some of ANSI common lisp’s observed properties are general traits of mature (more than a decade old) popularly used languages. Like we saw with ANSI Common Lisp, Scheme has lots of implementations, though that wikipedia category page needs to be picked through a little bit to find ones that are r7rs (current).

So languages that are not having their definitions changed every 1-3 years seem to get lots of separate conforming implementations of the same standard, not just one as appears common in the baby-languages of the top 25.

How does Visual Basic 98 (discontinued) compare to Lisp?

Since they are both in the TIOBE top 25 for 2025, and both more than a decade old. However, Visual Basic '98 was a product discontinued by Microsoft in 1998, whereas Lisp got an ANSI standard in 1994 which ended up “owned by the community who created it”, appearing to have experienced The Quickening and become The Highlander.

It is worth noting that a language that Micro$oft lost control of when they discontinued it in 1998 but are still obliged to support on their operating system, has stayed in the top 25 TIOBE language ranking despite Microsoft promoting its successor Visual Basic which they constantly change, which is also in TIOBE’s top 25 2025.

Lisp and Visual Basic '98 are candidates for being top languages this year precisely because they became immutable while also staying dependable back in the 90s, even if Lisp’s Untold Story is aesthetically cooler than Visual Basic '98’s Micro$oft-discontinued-it-but-got-stuck-still-supporting-it-for-decades. This is the opposite to essentially all the language companies that got their languages in TIOBE’s top 25 2025, which are repetitively changing their language every year, constantly reseting the clock on their compiler writers and programming language users who adopted their products back to zero.

Does lisp still change?

The language implementations (~compilers in other languages) keep improving as implementations conforming to the same ANSI common lisp.

There is a formula for (allowed by the standard) genuinely new things. Their addition as compiler extensions basically has not been seen to rock the boat.

An article is published presenting a new thing (weak hash-tables here). All the compilers add support for it in their (allowed) compiler extensions. A compatibility package is made that correctly calls the compiler extension for the lisp it finds itself being used in while providing a uniform experience across all Lisp’s well-known/participating current compilers. Then if you are writing an algorithm that needs weak hash-tables you just (require :trivial-garbage) and away you go, whatever implementation you are on.

An important and oft-missed point about the standard is that the standard also specifies what you must not or should not do. If the standard does not contain not to do something, there is no instruction not to have it as an extension, you can do it and in fact probably at the time many of the people and companies present in the standard committee were using and developing implementation bits that were not in the standard because they were not amenable to the standardization. For example, what would it mean to “quit” a lisp machine? Do you mean turn it off? But in a compiler running on a unix, quitting would be an ordinary thing to do in response to a sig-quit. So the standard deliberately left disagreements or we-don’t-knows like this to the implementors to decide in their own contexts.

You see beginners trying to use ANSI Common Lisp’s debugging protocol by hand sometimes, which you certainly can do (and I have met people who prefer to- like how you meet people who use ed(1) for writing code). Certainly the well known lisp environments from lisp’s whole history had special debugging lisp software that modernly use the debugging protocol in the standard. Slime, sly and Clouseau to name three current/semi-historical ones for ANSI common lisp.

Particularly I got some comments about multiprocessing/multithreading. The famous “trivial” style one is bordeaux-threads, the gist of which is a compatibility package that works on all the well-known compilers, and when given a function of no arguements to make-thread, runs that function in a new thread with an optional name, with special integration with garbage collection so you do not necessarily have to clean a finished thread up yourself (as well as providing the usual stuff like joining, stopping, interrupting, terminating…). But the standards committee rightly did not try to say how multiprocessing should specifically be done. The answer I gave in the thread is that it is also basically farmed out to the other, multiprocessing focused standards like the well-known cl-mpi package. But there are lots of answers as to what the right multiprocessing would be. So the standard did not seek to define it.

Conclusions

I concluded that my simple visualization of just the TIOBE top 25 programming languages in 2025 and the age of their current release, from plugging the name into wikipedia was a reasonable approach rather than trying to choose important historic programming languages myself.

We saw that twelve-year-old-scheme, as a middle-aged current-release language somewhere between lisp and baby languages in the top 25, also has many implementations of its current standard, similar to 31-year-old lisp.

We also saw that a discontinued-but-stuck-being-continuously-supported Micro$oft product, Visual Basic '98 has stayed in the top 25, possibly surviving because it was a static target with reliable support, similar to lisp (Visual Basic '98 is 27 right now).

Then, I gave specific examples of how lisp could be said to have continued growing: The always-conforming language implementations continue to improve as language implementations of the immutable language target: When an important academic paper is introduced, it is done as allowed compiler extensions, and a lisp compatibility package is done to unify its use across the compilers. TRIVIAL-GARBAGE and BORDEAUX-THREADS being examples.

We noted that lisp did not attempt to standardize context-dependent or unforeseeable activities, like the-right-debugging-software-to-use, “quitting”, multiprocessing but that there were and are good support for those in lisp.

Fin.

See you on this mastodon thread as always. The one from the original article yesterday.

Hope to see you at the two weekly shows (Sunday morning in Europe and Tuesday evening in the Americas)! Archives: https://communitymedia.video/c/screwtape_channel/videos https://toobnix.org/a/screwtape/videos

screwlisp proposes kittens