4 ms·
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
by susam 4y ago
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!
- aap_ 4y agoThis 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.
- PaulHoule 4y agoThere 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.)
- taeric 4y agoAs a sibling post said, code is data is a different thing. https://taeric.github.io/CodeAsData.html https://taeric.github.io/CodeAsData.html is a fun blog I wrote on this once.
- JonChesterfield 4y agoCode 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.
- zozbot234 4y agoEven "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".
- thweoru23432 4y ago"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.).
- PaulHoule 4y agoThere is this project https://github.com/paulhoule/ferocity/ 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.
- jacquesm 4y agoProlog and Clojure (effectively a LISP dialect) probably also qualify, and more modern: I think that in a way JSON also qualifies.
- mauriciolange 4y agoForth is the exact same thing.
- jshaqaw 4y agoI’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.
- mgdlbp 4y agoNo one's said the magic word yet: homoiconicity
- abecedarius 4y agoI 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.
- rbanffy 4y agoHistorical 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.
- coreload 4y agoI 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.
- rbanffy 4y agoIt'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.
- nextstepguy 4y agoThe first Scratch applet was a LISP runtime implemented in Java.
- thweoru23432 4y agoActually SBCL (and other CL impls) still follow this tradition; cf. https://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/ 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.
- sriku 4y agoWould 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.