7 ms·

D-Expressions: Lisp power, Dylan style [pdf]

89 points by fanf2 2y ago

timonoko 2y ago
From 1999. How many times you are going to do same sheiße over again? I am telling you, Mulisp (1978) solved all problems, because everything could be pretty-printed either in Algol-style or Lisp-style.
- ssivark 2y ago
  +1, I guess. Computers are capable enough that the representation in which code is viewed/edited need not be the same as it is canonically stored in, so long as one can unambiguously transform back & forth. We could potentially get over the bikeshedding by letting everyone configure their IDEs per their own taste for syntax.
  - cb321 2y ago
    Nim (https://nim-lang.org/ https://nim-lang.org/) originally had "syntax skins" with thoughts like these in mind.. e.g. braces vs. indent for block structure as per user-preference. The particular feature was unused enough to be dropped as not worth maintenance, though. Also, Mathematica since forever (maybe version 1.0 in 1988) has had things like `CForm` and `FortranForm`.
    - DonHopkins 2y ago
      Kaleida Labs (a joint venture of Apple and IBM) developed ScriptX, which was a cousin of Dylan: a lisp-like language with a "normal" syntax without all the parens, with a CLOS-like (without all the MOOP stuff) object system with generic dispatch, multiple inheritance, proxies, and a "Bento" persistence system (from OpenDoc), and container and multimedia libraries that leaned heavily into multiple inheritance. (You'd typically mix arrays or dicts into your collections of other kinds of objects. So you could directly loop over, filter, and collect your custom classes.) Its parser was a separate layer from its compiler, so Dan Bornstein (one of the ScriptX designers who later made Dalvik for Android) write a Scheme parser front end for it. ScriptX influenced MaxScript, the scripting language in 3D Studio Max, which was written by one of the ScriptX designers, John Wainwright. Other Kaleidan Lisp hackers include Shell Kaplan (Employee #1 at Amazon) and Eric Benson (who worked on Lucid Emacs), both went to Amazon and did a lot of Lisp and Lisp inspired stuff there. https://en.wikipedia.org/wiki/ScriptX https://en.wikipedia.org/wiki/ScriptX Shel and others wrote about Lisp at Amazon and their Lisp-inspired templating notation here: https://news.ycombinator.com/item?id=12437483 https://news.ycombinator.com/item?id=12437483 Kaleida's ScriptX training classes were lots of fun: taught by Randy Nelson, who is a professional juggler and former member of The Flying Karamazov Brothers, who Steve Jobs hired to teach developers at NeXT and Apple: https://web.archive.org/web/20190310081302/https://www.cake.co/conversations/w3j7jDp/that-time-steve-jobs-hired-a-career-juggler-to-teach-programming-to-developers https://web.archive.org/web/20190310081302/https://www.cake.... https://news.ycombinator.com/item?id=18772263 https://news.ycombinator.com/item?id=18772263 I used John Wainwright's MaxScript plugin API to integrate the C++ character animation system code I wrote for The Sims into 3D Studio Max, to make an animation content management system and exporter in MaxScript, which is like Lisp without parens for 3D: https://web.archive.org/web/20080224054735/http://www.donhopkins.com/drupal/node/30 https://web.archive.org/web/20080224054735/http://www.donhop... Dan Ingals's work on Fabrik inspired a lot of the stuff I did with ScriptX at Kaleida: https://news.ycombinator.com/item?id=29094633 https://news.ycombinator.com/item?id=29094633 Apple also developed Sk8, which was a lot like Dylan and ScriptX, i.e. Lisp without all the parens, plus objects. https://news.ycombinator.com/item?id=38768635 https://news.ycombinator.com/item?id=38768635 Mike Levins explained Coral Common Lisp and Dylan and Newton and Sk8 and HyperCard in the broader context and palace intrigue of Apple: https://news.ycombinator.com/item?id=21846706 https://news.ycombinator.com/item?id=21846706 mikelevins on Dec 20, 2019 | parent | context | favorite | on: Interface Builder's Alternative Lisp Timeline (201... Dylan (originally called Ralph) was basically Scheme plus a subset of CLOS. It also had some features meant to make it easier to generate small, fast artifacts--for example, it had a module system, and separately-compiled libraries, and a concept of "sealing" by which you could promise the compiler that certain things in the library would not change at runtime, so that certain kinds of optimizations could safely be performed. Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements. It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral. Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years. Alan Kay was around Apple then, and seemed to be interested in pretty much everything. Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered. Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS. Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.
  - stcredzero 2y ago
    We could potentially get over the bikeshedding by letting everyone configure their IDEs per their own taste for syntax. We Smalltalkers were discussing doing this at Camp Smalltalks in the 2000's. I'm currently working in golang, and I've noticed that Goland IDE expends quite a bit of compute indexing and parsing source files. Not only that, but, a significant portion of the bug fixes have to do with this, and the primary motivation for restarting Goland has to do with stale indexing. Wouldn't tools like git simply work better, if they were working off of some kind of direct representation of the semantic programming language structures? Merging could become 100% accurate, for one thing. (It's not for some edge cases, though many might mistakenly think otherwise.)
    - guenthert 2y ago
      > Merging could become 100% accurate, for one thing. How so? Merge conflicts don't arise from the inability to locate the proper change, but from the inability to decide, which of the change, if any, would be proper.
- mepian 2y ago
  How does Mulisp know how to print an arbitrary Lisp-style macro in Algol style?
  - timonoko 2y ago
    Obviously such Algol program produces Lisp-code and looks incomprehensible. But when Mulisp finally conquers the world, we can make backquote-style macro for Algol, where special characters indicate that following stuff needs to evaluated and inserted to the code.
    - AnimalMuppet 2y ago
      > But when Mulisp finally conquers the world... That will be never. If Mulisp hasn't done so in the last 46 years, it never will.
      - r8533292 2y ago
        it was finnish deadpan humor
        banish-m4 2y ago
        I asked an LLM and it suggested humor is forbidden here on English days ending in "y" because of Poe's law. This is why we can't we have nice things.
  - mietek 2y ago
    I don’t know, but I found the muLISP/muSTAR-80 Artificial Intelligence Development System Reference Manual on the Wayback Machine. https://web.archive.org/web/20140530042250/http://maben.homeip.net/static/s100/software/microsoft/LISP/MuLisp.pdf https://web.archive.org/web/20140530042250/http://maben.home...
- deleted 2y ago
  [deleted]
- kazinator 2y ago
  Before that, MacCarthy's own Lisp 2 added Algol syntax (1965-ish?), and then Vaughan Pratt (of "Pratt parser" fame) came up with CGOL in 1973.
  - pfdietz 2y ago
    There's a long tradition of people asserting Lisp's problem was the lack of infix syntax, then discovering this was not in a fact a problem of Lisp.
netbioserror 2y ago
Seems like Nim is the living embodiment of this paper. Similar expression-based syntactic concepts, similar AST dumps.
rayiner 2y ago
I’ve had a change of heart over the years regarding macros. Prefix syntax, as in Common Lisp, makes it really easy to write macros without understanding how programming language syntax and grammars really work. As more of a “computer” person than a “computer science” person, that was super appealing. But that’s probably optimizing for the wrong case. Macros are used much more often than they are written, and the person writing the macro should probably understand syntax and grammar. Moreover, as soon as you add guardrails like hygiene (like Scheme does), the inherent conceptual simplicity of Common Lisp style macros is greatly reduced. Too bad Dylan never took off. I think it would have been a better language than Java for enterprise software. Ironically, it was a create of the time insofar as it focused on something (trying to match C for performance) that ultimately didn’t end up mattering so much. We now write everything in one of the worst and least optimizable languages this side of TCL, and that doesn’t hold back deployment.
- pjmlp 2y ago
  Actually it was my experience with Tcl back at our 2000's startup, continuously porting modules from Tcl down into C, that formed my opinion that languages without either JIT or AOT on their reference implementation, as mostly suitable for scripting and teaching purposes.
  - rayiner 2y ago
    Haha—sorry, I didn’t mean to shit on TCL. It’s got no pretension of pretending to be something it’s not.
  - lproven 2y ago
    Er. You don't specify what the opinion you formed is. Should that have been: "... languages without either JIT or AOT on their reference implementation, are mostly [only?] suitable for scripting and teaching purposes." ... ?
    - DonHopkins 2y ago
      Not necessarily in the reference implementation, but quite early: Adam Sah, UCB: An Efficient Implementation of the Tcl Language (1994, UCB Masters Degree Thesis for Professor John Ousterhout): https://www2.eecs.berkeley.edu/Pubs/TechRpts/1994/CSD-94-812.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/1994/CSD-94-812... After Ousterhout and his team went to Sun, but before the Java Juggernaut made its debut, Sun was positioning TCL to be the "Official Scripting Language of the World Wide Web". Brian T. Lewis, Sun Microsystems Labs: An On-the-fly Bytecode Compiler for Tcl (1996, Usenix TCL/Tk Workshop): https://www.usenix.org/legacy/publications/library/proceedings/tcl96/full_papers/lewis/lewis.html https://www.usenix.org/legacy/publications/library/proceedin... I wonder what would have happened if John Oosterhout's TCL team had applied Dave Ungar's Self team's JIT tech to TCL, before the Self team left Sun and made HotSpot (who Sun then hired back to apply to Java). Anyone know if / how those two teams at Sun overlapped / interacted at Sun Labs? Then "The TCL War" happened, which didn't help TCL's world domination plans either: https://vanderburg.org/old_pages/Tcl/war/ https://vanderburg.org/old_pages/Tcl/war/ https://news.ycombinator.com/item?id=12025218 https://news.ycombinator.com/item?id=12025218 Slightly Skeptical View on John K. Ousterhout and Tcl: https://softpanorama.org/People/Ousterhout/index.shtml https://softpanorama.org/People/Ousterhout/index.shtml >There was some concerns about TK future. See for example the following message from [Python-Dev] >FYI ajuba solutions (formerly scriptics) acquired by interwoven On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote: >I'm waiting for the Tcl/Tk developers to grow up -- they still >fear that any attempt to make it easier to use Tk from other >languages would be to "give up the crown jewels" :-( >In the long run this has probably harmed Tk seriously. If Tk was just a widget set divorced from Tcl, then it might have been chosen as the underlying widget set for GNOME or KDE, and then have benefited from the development work done for those projects, such as the GNOME canvas enhancements, which now can't be absorbed back into Tk without a lot of effort to merge the two sets of code. The genius of TCL/Tk: https://news.ycombinator.com/item?id=22709478 https://news.ycombinator.com/item?id=22709478 DonHopkins on March 28, 2020 | parent | context | favorite | on: Is there any code in Firefox (as of 2020) that com... The genius of TCL/Tk, and the reason I believe Tk was so incredibly successful despite the flaws and shortcomings of TCL, is that toolkits like Motif, based on the X Toolkit Intrinsics, that aren't written AROUND an existing extension language, end up getting fucked by Greenspun's Tenth Rule: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule >"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -Philip Greenspun's Tenth Rule The X Toolkit ends up needing to do all of these dynamic-scripting-language-like things, like resolving names and paths, binding events to handlers, calculating expressions, and instantiating objects based on resource data. So if it doesn't already start out with a standardized scripting language to use for that, it has to duplicate all that dynamic almost-but-not-quite-entirely-unlike-half-of-Common-Lisp stuff itself. Case in point: Motif's infamous UIL (because X resource files weren't half-assed enough). https://www.donhopkins.com/home/catalog/unix-haters/hpox/uil-sux.html https://www.donhopkins.com/home/catalog/unix-haters/hpox/uil... And then when you do get around to plugging that toolkit into some other scripting language (the way WINTERP plugged Motif/Xt into XLisp, or GTK/GObject plugs into Python for that matter), now you have two or more fat bloated complex buggy poorly documented incompatible impedance-mismatched half-assed competing layers of middleware and object models tripping over each other's feet and spraying each other with seltzer bottles like the Three Stooges. https://www.youtube.com/watch?v=VO9RP4QEZKU https://www.youtube.com/watch?v=VO9RP4QEZKU https://news.ycombinator.com/item?id=22610342 https://news.ycombinator.com/item?id=22610342 >Speaking of the plague, does it support UIL? ;) >Neils Mayer described WINTERP (XLisp + Motif) as: You might think of such functionality as "client-side NeWS without the postscript imaging model". http://nielsmayer.com/winterp/ http://nielsmayer.com/winterp/ >Don Hopkins wrote to a comp.human-factors discussion about "Info on UIL (User Interface Language)" on January 22, 1993: https://groups.google.com/d/msg/comp.human-factors/R3wfh90HMss/WR1-qmjnNJIJ https://groups.google.com/d/msg/comp.human-factors/R3wfh90HM... >Here are some classic messages about UIL. Avoid it like the plague. [...]
samatman 2y ago
Julia is the spiritual successor to Dylan in many ways: multiple dispatch, Lisp heritage, and a full-power macro system with gensyms and local capture. It's a bit type-cast as a language for numerics and scientific programming, a niche where it's enjoying robust success. But as a language, it's fully suited to general purpose programming, providing an excellent experience in fact. The ecosystem for most applications which aren't in the existing niche is somewhat thin, but that's a chicken-and-egg problem. It has solid package management, a good concurrency story, well-designed FFI, and performance-sensitive parts of a program can be honed to native speed by making them type-stable. Slept on imho.
r8533292 2y ago
i'll add to general discussion about syntaxes and infix notation, i'm not sure where to attach this point to existing threads. genera had infix mode, that was enabled on a reader macro. you could write something like (defun bresenham (a x0 y0 x1 y1 &aux dx dy d y) #◇dx:x1-x0, dy:y1-y0, d:2*dy-dx, y=y0◇ (loop for x from x0 to x1 do #◇a[x,y]:1, if d>0 then (y:y+1, d:d-2*dx), d:d+2*dy◇)) you can make the code above fully operational in common lisp using dispatch macro on a unicode character, so i've been experimenting with such infix mode in my private code. i'll leave the judgement over whether or not this increases readibility.
mattgreenrocks 2y ago
I have a special fondness for this paper. This was my first real paper I digested successfully. It is easy to read, posits a cool idea, and shows some of what makes it tick. My one qualm is that it does not elaborate on implementation as much as I'd like.
malodyets 2y ago
This desperately needs a date `[1999]`

89 points by fanf2 2y ago

From 1999. How many times you are going to do same sheiße over again? I am telling you, Mulisp (1978) solved all problems, because everything could be pretty-printed either in Algol-style or Lisp-style.

ssivark 2y ago
+1, I guess. Computers are capable enough that the representation in which code is viewed/edited need not be the same as it is canonically stored in, so long as one can unambiguously transform back & forth. We could potentially get over the bikeshedding by letting everyone configure their IDEs per their own taste for syntax.
- cb321 2y ago
  Nim (https://nim-lang.org/ https://nim-lang.org/) originally had "syntax skins" with thoughts like these in mind.. e.g. braces vs. indent for block structure as per user-preference. The particular feature was unused enough to be dropped as not worth maintenance, though. Also, Mathematica since forever (maybe version 1.0 in 1988) has had things like `CForm` and `FortranForm`.
  - DonHopkins 2y ago
    Kaleida Labs (a joint venture of Apple and IBM) developed ScriptX, which was a cousin of Dylan: a lisp-like language with a "normal" syntax without all the parens, with a CLOS-like (without all the MOOP stuff) object system with generic dispatch, multiple inheritance, proxies, and a "Bento" persistence system (from OpenDoc), and container and multimedia libraries that leaned heavily into multiple inheritance. (You'd typically mix arrays or dicts into your collections of other kinds of objects. So you could directly loop over, filter, and collect your custom classes.) Its parser was a separate layer from its compiler, so Dan Bornstein (one of the ScriptX designers who later made Dalvik for Android) write a Scheme parser front end for it. ScriptX influenced MaxScript, the scripting language in 3D Studio Max, which was written by one of the ScriptX designers, John Wainwright. Other Kaleidan Lisp hackers include Shell Kaplan (Employee #1 at Amazon) and Eric Benson (who worked on Lucid Emacs), both went to Amazon and did a lot of Lisp and Lisp inspired stuff there. https://en.wikipedia.org/wiki/ScriptX https://en.wikipedia.org/wiki/ScriptX Shel and others wrote about Lisp at Amazon and their Lisp-inspired templating notation here: https://news.ycombinator.com/item?id=12437483 https://news.ycombinator.com/item?id=12437483 Kaleida's ScriptX training classes were lots of fun: taught by Randy Nelson, who is a professional juggler and former member of The Flying Karamazov Brothers, who Steve Jobs hired to teach developers at NeXT and Apple: https://web.archive.org/web/20190310081302/https://www.cake.co/conversations/w3j7jDp/that-time-steve-jobs-hired-a-career-juggler-to-teach-programming-to-developers https://web.archive.org/web/20190310081302/https://www.cake.... https://news.ycombinator.com/item?id=18772263 https://news.ycombinator.com/item?id=18772263 I used John Wainwright's MaxScript plugin API to integrate the C++ character animation system code I wrote for The Sims into 3D Studio Max, to make an animation content management system and exporter in MaxScript, which is like Lisp without parens for 3D: https://web.archive.org/web/20080224054735/http://www.donhopkins.com/drupal/node/30 https://web.archive.org/web/20080224054735/http://www.donhop... Dan Ingals's work on Fabrik inspired a lot of the stuff I did with ScriptX at Kaleida: https://news.ycombinator.com/item?id=29094633 https://news.ycombinator.com/item?id=29094633 Apple also developed Sk8, which was a lot like Dylan and ScriptX, i.e. Lisp without all the parens, plus objects. https://news.ycombinator.com/item?id=38768635 https://news.ycombinator.com/item?id=38768635 Mike Levins explained Coral Common Lisp and Dylan and Newton and Sk8 and HyperCard in the broader context and palace intrigue of Apple: https://news.ycombinator.com/item?id=21846706 https://news.ycombinator.com/item?id=21846706 mikelevins on Dec 20, 2019 | parent | context | favorite | on: Interface Builder's Alternative Lisp Timeline (201... Dylan (originally called Ralph) was basically Scheme plus a subset of CLOS. It also had some features meant to make it easier to generate small, fast artifacts--for example, it had a module system, and separately-compiled libraries, and a concept of "sealing" by which you could promise the compiler that certain things in the library would not change at runtime, so that certain kinds of optimizations could safely be performed. Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements. It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral. Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years. Alan Kay was around Apple then, and seemed to be interested in pretty much everything. Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered. Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS. Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.
- stcredzero 2y ago
  We could potentially get over the bikeshedding by letting everyone configure their IDEs per their own taste for syntax. We Smalltalkers were discussing doing this at Camp Smalltalks in the 2000's. I'm currently working in golang, and I've noticed that Goland IDE expends quite a bit of compute indexing and parsing source files. Not only that, but, a significant portion of the bug fixes have to do with this, and the primary motivation for restarting Goland has to do with stale indexing. Wouldn't tools like git simply work better, if they were working off of some kind of direct representation of the semantic programming language structures? Merging could become 100% accurate, for one thing. (It's not for some edge cases, though many might mistakenly think otherwise.)
  - guenthert 2y ago
    > Merging could become 100% accurate, for one thing. How so? Merge conflicts don't arise from the inability to locate the proper change, but from the inability to decide, which of the change, if any, would be proper.
mepian 2y ago
How does Mulisp know how to print an arbitrary Lisp-style macro in Algol style?
- timonoko 2y ago
  Obviously such Algol program produces Lisp-code and looks incomprehensible. But when Mulisp finally conquers the world, we can make backquote-style macro for Algol, where special characters indicate that following stuff needs to evaluated and inserted to the code.
  - AnimalMuppet 2y ago
    > But when Mulisp finally conquers the world... That will be never. If Mulisp hasn't done so in the last 46 years, it never will.
    - r8533292 2y ago
      it was finnish deadpan humor
      - banish-m4 2y ago
        I asked an LLM and it suggested humor is forbidden here on English days ending in "y" because of Poe's law. This is why we can't we have nice things.
- mietek 2y ago
  I don’t know, but I found the muLISP/muSTAR-80 Artificial Intelligence Development System Reference Manual on the Wayback Machine. https://web.archive.org/web/20140530042250/http://maben.homeip.net/static/s100/software/microsoft/LISP/MuLisp.pdf https://web.archive.org/web/20140530042250/http://maben.home...
deleted 2y ago
[deleted]
kazinator 2y ago
Before that, MacCarthy's own Lisp 2 added Algol syntax (1965-ish?), and then Vaughan Pratt (of "Pratt parser" fame) came up with CGOL in 1973.
- pfdietz 2y ago
  There's a long tradition of people asserting Lisp's problem was the lack of infix syntax, then discovering this was not in a fact a problem of Lisp.

netbioserror 2y ago

Seems like Nim is the living embodiment of this paper. Similar expression-based syntactic concepts, similar AST dumps.

rayiner 2y ago

I’ve had a change of heart over the years regarding macros. Prefix syntax, as in Common Lisp, makes it really easy to write macros without understanding how programming language syntax and grammars really work. As more of a “computer” person than a “computer science” person, that was super appealing. But that’s probably optimizing for the wrong case. Macros are used much more often than they are written, and the person writing the macro should probably understand syntax and grammar. Moreover, as soon as you add guardrails like hygiene (like Scheme does), the inherent conceptual simplicity of Common Lisp style macros is greatly reduced. Too bad Dylan never took off. I think it would have been a better language than Java for enterprise software. Ironically, it was a create of the time insofar as it focused on something (trying to match C for performance) that ultimately didn’t end up mattering so much. We now write everything in one of the worst and least optimizable languages this side of TCL, and that doesn’t hold back deployment.

pjmlp 2y ago
Actually it was my experience with Tcl back at our 2000's startup, continuously porting modules from Tcl down into C, that formed my opinion that languages without either JIT or AOT on their reference implementation, as mostly suitable for scripting and teaching purposes.
- rayiner 2y ago
  Haha—sorry, I didn’t mean to shit on TCL. It’s got no pretension of pretending to be something it’s not.
- lproven 2y ago
  Er. You don't specify what the opinion you formed is. Should that have been: "... languages without either JIT or AOT on their reference implementation, are mostly [only?] suitable for scripting and teaching purposes." ... ?
  - DonHopkins 2y ago
    Not necessarily in the reference implementation, but quite early: Adam Sah, UCB: An Efficient Implementation of the Tcl Language (1994, UCB Masters Degree Thesis for Professor John Ousterhout): https://www2.eecs.berkeley.edu/Pubs/TechRpts/1994/CSD-94-812.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/1994/CSD-94-812... After Ousterhout and his team went to Sun, but before the Java Juggernaut made its debut, Sun was positioning TCL to be the "Official Scripting Language of the World Wide Web". Brian T. Lewis, Sun Microsystems Labs: An On-the-fly Bytecode Compiler for Tcl (1996, Usenix TCL/Tk Workshop): https://www.usenix.org/legacy/publications/library/proceedings/tcl96/full_papers/lewis/lewis.html https://www.usenix.org/legacy/publications/library/proceedin... I wonder what would have happened if John Oosterhout's TCL team had applied Dave Ungar's Self team's JIT tech to TCL, before the Self team left Sun and made HotSpot (who Sun then hired back to apply to Java). Anyone know if / how those two teams at Sun overlapped / interacted at Sun Labs? Then "The TCL War" happened, which didn't help TCL's world domination plans either: https://vanderburg.org/old_pages/Tcl/war/ https://vanderburg.org/old_pages/Tcl/war/ https://news.ycombinator.com/item?id=12025218 https://news.ycombinator.com/item?id=12025218 Slightly Skeptical View on John K. Ousterhout and Tcl: https://softpanorama.org/People/Ousterhout/index.shtml https://softpanorama.org/People/Ousterhout/index.shtml >There was some concerns about TK future. See for example the following message from [Python-Dev] >FYI ajuba solutions (formerly scriptics) acquired by interwoven On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote: >I'm waiting for the Tcl/Tk developers to grow up -- they still >fear that any attempt to make it easier to use Tk from other >languages would be to "give up the crown jewels" :-( >In the long run this has probably harmed Tk seriously. If Tk was just a widget set divorced from Tcl, then it might have been chosen as the underlying widget set for GNOME or KDE, and then have benefited from the development work done for those projects, such as the GNOME canvas enhancements, which now can't be absorbed back into Tk without a lot of effort to merge the two sets of code. The genius of TCL/Tk: https://news.ycombinator.com/item?id=22709478 https://news.ycombinator.com/item?id=22709478 DonHopkins on March 28, 2020 | parent | context | favorite | on: Is there any code in Firefox (as of 2020) that com... The genius of TCL/Tk, and the reason I believe Tk was so incredibly successful despite the flaws and shortcomings of TCL, is that toolkits like Motif, based on the X Toolkit Intrinsics, that aren't written AROUND an existing extension language, end up getting fucked by Greenspun's Tenth Rule: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule >"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -Philip Greenspun's Tenth Rule The X Toolkit ends up needing to do all of these dynamic-scripting-language-like things, like resolving names and paths, binding events to handlers, calculating expressions, and instantiating objects based on resource data. So if it doesn't already start out with a standardized scripting language to use for that, it has to duplicate all that dynamic almost-but-not-quite-entirely-unlike-half-of-Common-Lisp stuff itself. Case in point: Motif's infamous UIL (because X resource files weren't half-assed enough). https://www.donhopkins.com/home/catalog/unix-haters/hpox/uil-sux.html https://www.donhopkins.com/home/catalog/unix-haters/hpox/uil... And then when you do get around to plugging that toolkit into some other scripting language (the way WINTERP plugged Motif/Xt into XLisp, or GTK/GObject plugs into Python for that matter), now you have two or more fat bloated complex buggy poorly documented incompatible impedance-mismatched half-assed competing layers of middleware and object models tripping over each other's feet and spraying each other with seltzer bottles like the Three Stooges. https://www.youtube.com/watch?v=VO9RP4QEZKU https://www.youtube.com/watch?v=VO9RP4QEZKU https://news.ycombinator.com/item?id=22610342 https://news.ycombinator.com/item?id=22610342 >Speaking of the plague, does it support UIL? ;) >Neils Mayer described WINTERP (XLisp + Motif) as: You might think of such functionality as "client-side NeWS without the postscript imaging model". http://nielsmayer.com/winterp/ http://nielsmayer.com/winterp/ >Don Hopkins wrote to a comp.human-factors discussion about "Info on UIL (User Interface Language)" on January 22, 1993: https://groups.google.com/d/msg/comp.human-factors/R3wfh90HMss/WR1-qmjnNJIJ https://groups.google.com/d/msg/comp.human-factors/R3wfh90HM... >Here are some classic messages about UIL. Avoid it like the plague. [...]

samatman 2y ago

Julia is the spiritual successor to Dylan in many ways: multiple dispatch, Lisp heritage, and a full-power macro system with gensyms and local capture. It's a bit type-cast as a language for numerics and scientific programming, a niche where it's enjoying robust success. But as a language, it's fully suited to general purpose programming, providing an excellent experience in fact. The ecosystem for most applications which aren't in the existing niche is somewhat thin, but that's a chicken-and-egg problem. It has solid package management, a good concurrency story, well-designed FFI, and performance-sensitive parts of a program can be honed to native speed by making them type-stable. Slept on imho.

r8533292 2y ago

i'll add to general discussion about syntaxes and infix notation, i'm not sure where to attach this point to existing threads. genera had infix mode, that was enabled on a reader macro. you could write something like (defun bresenham (a x0 y0 x1 y1 &aux dx dy d y) #◇dx:x1-x0, dy:y1-y0, d:2*dy-dx, y=y0◇ (loop for x from x0 to x1 do #◇a[x,y]:1, if d>0 then (y:y+1, d:d-2*dx), d:d+2*dy◇)) you can make the code above fully operational in common lisp using dispatch macro on a unicode character, so i've been experimenting with such infix mode in my private code. i'll leave the judgement over whether or not this increases readibility.

mattgreenrocks 2y ago

I have a special fondness for this paper. This was my first real paper I digested successfully. It is easy to read, posits a cool idea, and shows some of what makes it tick. My one qualm is that it does not elaborate on implementation as much as I'd like.

malodyets 2y ago

This desperately needs a date `[1999]`