Comment by susam | Hacker News Reader

Comment by susam | Hacker News Reader

The first article in this issue of BYTE has a very interesting characterization of Lisp that I have not come across before. I mean, famous quotes like "Lisp is a programmable programming language" by John Foderaro and "The greatest single programming language ever designed" by Alan Kay are often mentioned in articles about Lisp. But in this issue of BYTE, the article "An Overview of LISP" by John Allen at page 10 has something very interesting to say. Excerpt from the article:

"The best description of the LISP programming language is that it is a high level machine language. That is, it shares many of the facets of contemporary machine language --the necessity for attention to detail and the freedom to manipulate the machine's data and programs without restriction-- yet LISP is high level in that the language contains the expressive power and convenience of traditional high level languages. The contradiction is resolvable: a LISP machine is just a higher level machine whose data items are organized differently from the binary bit patterns of most machines, and the LISP programming language is the assembly language for this machine."

Consider the Emacs Lisp (Elisp) interpreter for example. Elisp interpreter is the Lisp machine. It understands Elisp symbolic expressions, the language of this machine. With enough code written in this machine's language, we get this fine editing and productivity software known as Emacs!

This exactly matches my thoughts. It seems that machine language and LISP are the only two languages (that i know anyway) where code and data are fundamentally the same kind of thing.

There are many languages that are dynamic and let you generate code and run it inside the program. For instance in Java you can generate bytecode for a class and run one of the methods. In FORTH you can write new "words" (roughly functions) that are the same as the built-in words.

It is mainly languages built around AOT compilation like C, Pascal, FORTRAN and such that completely separate code and data. (I guess though you can make a C program that writes a C program, runs "cc" on it, makes a shared object file, loads the library dynamically, and calls a function from it.)

Code is data isn't just about emitting and running code. It's also traversing your code as the data structure it is and changing it as you see fit.

Even "languages built around AOT compilation" are increasingly blurring the phase distinction between "ahead-of-time" and "at runtime", via increased use of metaprogramming and constant evaluation facilities. We may end up with a state of things where even some "AOT-language" programs are written to do much of their work at compile time, perhaps adding more and more of those facilities that were formerly allowed only at "runtime".

"Metaprogramming" is a very broad term. Templates etc. might be nice, but it's hardly anything compared to what you can do with Lisp macros (there's an orthogonal issue that this power leads to unreadable code; see "Lisp Curse", but ignore it for now.).

There is this project

https://github.com/paulhoule/ferocity/

which I might finish up when I'm done with the report I'm writing. It is possible to create Java expression trees with trees of static method calls that look a lot like S-expressions and stick them together into statements, methods and classes.

You should be able to do the same tricks people do with LISP macros and it could work code generation miracles but it would have that "LISP curse" problem in spades.

The plan is to generate a code generator that is sufficient to generate the full DSL implementation (ferocity0) and use that to generate the full implementation (ferocity.)

I have some tests for ferocity0 writing .java files to get fed to javac and for ferocity0 running expression trees with a primitive interpreter. Already the type system is enriched over the type system because interpreted ferocity0 can handle Java expressions as a type at run time so you get issues like quoting and unquoting in LISP.

How does this compare to Common Lisp or Scheme macros in in terms of amount of code needed to generate things? How does it compare in terms of what kind of functions and instructions are used? Can one use standard Java language to use it? Could one for example throw a for loop in there or directly write something like "class Point { ..."?

As a sibling post said, code is data is a different thing. https://taeric.github.io/CodeAsData.html is a fun blog I wrote on this once.

I'm aware of a discussion about what homoiconicity should be defined as after Julia claimed to be a homoiconic language. It (and many others) have ways to manipulate the AST with its own language, but requires basically a different set of functions and tools to manipulate it that is different from those that manipulate the data, so that claim was eventually withdrawn.

Prolog and Clojure (effectively a LISP dialect) probably also qualify, and more modern: I think that in a way JSON also qualifies.

JSON is not a programming language.

And would have been way cleaner had they just left it as sexprs.

Forth is the exact same thing.

I’m a Lisper but I love Forth and Forth people. The only computer subculture as devoted to their weird little secret ancient Jedi art as we parenthesis shufflers.

No one's said the magic word yet: homoiconicity

I have fond memories of Allen's book Anatomy of Lisp. I guess there are only historical reasons to read it now, but at the time it felt like an introduction to wizardry.

Historical reasons for reading are always good. We gain much insight from time travel and, until we invent actual time machines so we can get our IBM 5100's and go ourselves to Woodstock, books are the next best thing.

I have IBM 5100 nostalgia. I wrote a lot of software for that 40 years ago. Speaking of Lisp Machines, the 5100 was basically an APL machine: BASIC and APL in microcode.

It's a pretty computer. I'd love if we did replicas of it the way a company did with the C64 maxi.

Would also make the lives of time travelers much easier.

Actually SBCL (and other CL impls) still follow this tradition; cf.

https://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-co...

You can also use the new sb-simd to play around with vectorization in the interpreter. Okay you'll break something, but it's such joy while you do it. C/C++ and other "strictly-separated compilation" languages OTOH seem so dogmatic and stupid now. It's no surprise why development is no painful in the latter. Also not surprising that the world prefers them.

The first Scratch applet was a LISP runtime implemented in Java.

Would that description have been influenced by symbolics and such systems? It is pretty spot on but perhaps more true of those systems than of today's lisps.

Reply on news.ycombinator.com