It has been discussed many times already. Projects like this don't produce a Lisp. It's a toy, Lisp-like language at best. Calling it a Lisp does a disservice to the proper languages in the family.
Bullshit. "Lisp" is completely adequate description of a specific succint, elegant and infinitely portable formalism to describe programs - even without the ecosystem.
It is compact and elegant. The concepts within a Lisp like system can be expanded to help in myriad programming tasks.
It's like a koan that cannot be repeated enough until every programmer has implemented a lisp interpreted at least once.
I refer to the "Roots of Lisp".
JMC's first Lisp paper had goto in it[0] and was described in terms of the hardware it ran on, is this part of the compact and elegant formalism which you are thinking of?
If you want a compact and elegant formalism then grab the untyped lambda calculus. If you want a Lisp, then at least make something with a GC and macro system.
[0] https://web.archive.org/web/20130319041509/http://www-formal...
I don't see why the other would invalidate the other.
Tiny lisp interpreters cherish Lisp as a small formalism that for some people help understand computing on a deeper theoretical level.
It can also be jury rigged on top of any substrate to implement various ad-hoc systems (Greenspuns tenth rule very much applies here).
The fact that we use Lisp in Greenspun 10th form or as a syntax to think about programs does not mean it would be nice to have Lisp production systems.
I don't see how small lisp interpreters would be offensive to anyone. They are pure joy in my opinion, expressing neatly how a topic that sound fairly complex (interpreters) is actually expressible in elegant and succint form.
On public: "more ignorance in the general public"
I don't know how much public sentiment matters in deep professional fields. I don't need to know how neurosurgeons think about their craft - why should a neurosurgeon know what Lisp is?
SICP is such a legendary book that it should hold Lisp's flag high enough in my opinion.
So at very least it would be helpful to make a distiction between those two parentheses views of the world.
Rather, it's an attempt to judge the verbosity of various languages by writing the same small interpreter in each of those languages. I'm not entirely convinced that this is a definitive way of doing this, but that's what the author is trying to do. It says as much on the project page.
Given that all the implementations were around 10% of each other it doesn't seem like a particularly conclusive result (as far as line count goes, which looks like it was the main metric). At that point minor things like code formatting will make a lot of difference (for example the C# solution is the shortest, but they're using a more concise brace style than the standard one for C#).
Which is why the benchmarks game does this —
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...