The thing about both Lisp and Smalltalk that keeps making me feel alienated is that their power seems much weaker beyond their kingdom. The outside world does not have an object browser, nor is it made of s-expressions.<p>Tcl occupies a very nice place in this regard: its homoiconicity and symmetry (and late binding) come from text. The outside world, to a very close approximation, is also made of text. Subprocesses, sockets, FFI, files and user interaction just feel more native - in the image-oriented languages, I always find myself fighting the ambassador who imperfectly represents these things in forms the kingdom understands.<p>Just a feeling. They're all wonderful languages, and this article speaks well to some of the "why".
Wonderful article! "Smalltalk, like Lisp, runs in the same context it’s written in."<p>I have been programming professionally in Common Lisp (off and on) since the 1980s but there is something equally magical about Smalltalk. I have often thought that Smalltalk could be the language I use after I retire (I am in my 60s and I will probably stop working in about ten years).
Indeed, homoiconicity is a very powerful thing. It doesn't have to be core to the nature of the language, though; as far as I know, any Turing-equivalent language readily admits a metacircular interpreter, and so really a homoiconic language is a language with a compiler in the standard library.<p>As a thought experiment, imagine Lisp without macros. It's not hard; after all, "The Little Schemer" covers metacircular interpretation without ever mentioning macros. So what's going on? Apparently we don't need macros! But, we could add macros to a Lisp by <i>reifying</i> them in the metacircular interpreter. There's actually a feature in plain sight which makes this possible, and it's the humble (quote) special form. <i>This</i> is what makes code and data intermix so cleanly in Lisp.<p>This is why languages like Julia and Monte are not shy about using "homoiconic" to describe their language design; a standard library compiler is just as good as a compiler in the core semantics, as long as it's easy to use and meshes well with the rest of the language.
> Smalltalk is powerful because all Smalltalk data are programs–all information is embodied by running, living objects.<p>That's what Lisp systems do too. Program elements like classes, functions, methods, symbols, ... are first class objects. With something like CLOS you have a similar level of object-oriented meta-programming capabilities.<p>Many Lisp systems offer additionally to execute Lisp data using a Lisp interpreter and Lisp has a simple data representation for Lisp programs: Lisp data.<p>Smalltalk OTOH uses text as source code and usually a compiler to byte-code.<p>> because Lisp source code is expressed in the same form as running Lisp code<p>Only if you use a Lisp interpreter. Otherwise the running Lisp code might be machine code or some byte code.<p>> Smalltalk goes one further than Lisp: it’s not that Smalltalk’s source code has no syntax so much as Smalltalk has no source code.<p>That's a misconception. Smalltalk has source code. As text. It's just typically managed by the integrated development environment.<p>It's actually Lisp which goes further than Smalltalk, because Lisp has source as data and can use that in Lisp interpreters directly for execution.
> Smalltalk doesn’t need macros because it has classes instead.<p>I'm not sure this is true. Surely any programming language that lacks macros would be more powerful with them.
I find symmetries a very necessary concept. It's a complexity divider. A bit like self similarity or inductive reasoning, it turns chaos into cosmos.
> What most of these languages seem to miss is that Smalltalk’s class system, like Lisp’s macro system, is a symptom of the power already available in the language, not its cause. If it didn’t already have it, it wouldn’t really be that hard to add it in yourself.<p>What most of these articles seem to miss is that that Java's designers were themselves expert Lispers and Smalltalkers, and they most certainly realized all that, and that Java's success is a consequence of them understanding exactly why <i>not</i> to repeat the same design. Design doesn't live in a vacuum. Design is shaping a product not just to fit some platonic ideal, but reality, with all its annoying constraints.<p>To understand why Lispers and Smalltalkers designed Java the way they did, I recommend watching James Gosling's talk, How The JVM Spec Came To Be[1], and the first 20 minutes or so of Brian Goetz's talk, Java: Past, Present, and Future[2].<p>[1]: <a href="https://www.infoq.com/presentations/gosling-jvm-lang-summit-keynote" rel="nofollow">https://www.infoq.com/presentations/gosling-jvm-lang-summit-...</a><p>[2]: <a href="https://www.youtube.com/watch?v=Dq2WQuWVrgQ" rel="nofollow">https://www.youtube.com/watch?v=Dq2WQuWVrgQ</a>
Lisp and Smalltalk actually suffer from the same problem: late-binding sucks. When I was in college a professor once pointed out to me that he didn't know of an LL(1) parser for Smalltalk. There's a reason for that: Smalltalk's syntax is late-bound! It's almost like Forth's syntax: the reader consumes words and decides what to do with them on the spot, whether they represent variables, operators, constants, or parts of a message send and once it has a subject, verb, and objects, dispatches the message also on the spot.<p>This plays havoc with your ability to do static analysis, and languages that hinder static analysis should not be used in real-world systems. If the earliest you find out about errors is in a running system, it's far too late and you are hosed.<p>This is why the Lisp and Smalltalk Evangelism Strikeforces have been met with decades of failure, while the Rust Evanglism Strikeforce is getting on with a massive project of digital <i>tikkun olam</i>.