3 ms·
This naturally leads to the idea of non-textual presentation of program code. A major benefit of this approach is that it eliminates the need for code parsing.
by agentultra 15y ago
This naturally leads to the idea of non-textual presentation of program code. A major benefit of this approach is that it eliminates the need for code parsing. Our solution is to have code always maintained in an Abstract Syntax Tree (AST), which consists of nodes with properties, children and references, and fully describes the program code.
So.. Common Lisp? I just read the article about the stupidity in file systems. In it the author laments the old adage about history repeating itself. He coins the anecdote, there are no new engineering problems, just new engineers solving old problems.
I can imagine this MPS product being incredibly useful... but we have had this technology for nearly 40 years in some for another of Lisp. And most Lispers would agree that extending the program language and semantics to the domain is a very productive way of writing reliable and maintainable software.
I am curious though what makes MPS superior exactly? Seems more complicated than Lisp, but I'm no MPS expert. Can anyone enlighten us?
- cyrus_ 15y agoIn what way is Common Lisp using "non-textual presentation of program code"? S-expressions are still textual. For example, you can't associate information with S-expressions that is not visible on the screen. And you can use much more natural syntax in MPS than in Lisp (not trying to start a tired old flame war.)
- agentultra 15y agoS-Expression are in many regards the AST of a Lisp program. Macros create the high-level domain-specific semantics. If textual representation is important as well, you can write reader-macros. Lisp is really good at this sort of "meta-language programming." It still seems to me that everyone, eventually, implements Lisp in one way or another (or at least some small part of it). edit: grammar corrections