[HN Gopher] The Evolution of Lisp (1993) [pdf]
___________________________________________________________________
The Evolution of Lisp (1993) [pdf]
Author : swatson741
Score : 85 points
Date : 2024-05-26 17:48 UTC (5 hours ago)
(HTM) web link (redirect.cs.umbc.edu)
(TXT) w3m dump (redirect.cs.umbc.edu)
| dang wrote:
| Related:
|
| _The Evolution of Lisp (1993) [pdf]_ -
| https://news.ycombinator.com/item?id=14937424 - Aug 2017 (17
| comments)
|
| _The Evolution of Lisp_ -
| https://news.ycombinator.com/item?id=3528694 - Jan 2012 (4
| comments and a video re-enactment from 2008:
| https://www.infoq.com/presentations/Lisp-Guy-Steele-Richard-...)
|
| _The Evolution of Lisp [pdf]_ -
| https://news.ycombinator.com/item?id=2082417 - Jan 2011 (1
| comment)
| behnamoh wrote:
| People should clarify what they mean by "Lisp". It's not a
| programming language or even a family of languages, it's a whole
| different computing system which just happens to have a
| programming language syntax on top. To get the most out of it and
| benefit from the powerful CL REPL, one needs to use Emacs (also
| written in Lisp).
|
| Some variants just drop that part and focus on the language only.
| Clojure and Racket are in that category. They lack the full power
| of CL; so they're just Lisp-syntax languages, not an actual Lisp.
|
| Maybe this high barrier to entry is why Lisp hasn't caught on
| even after 30 years of CL standardization. People often don't
| want to learn a new IDE to get the most out of Lisp. And if they
| stick to their current IDEs, they only get a glimpse of Lisp
| through its syntax (and much limited macro system). At that
| point, it's questionable whether whatever remains of Lisp does
| indeed provide any advantage over more mainstream languages
| (e.g., instead of learning Clojure, why not just learn a
| functional language like Elixir or Haskell? It's not like Clojure
| gives you the full Lisp power anyway.)
|
| Addendum: As one of the comments below mentioned (thank you
| @lispm), what I meant by "dropping the full power of Lisp" is the
| ability to modify a running program (continuation/restart
| system). Does Clojure REPL drop you in a new REPL in case of
| errors so you can literally change the running code or enter
| value for a missing variable?
| tvink wrote:
| Why do you say that one needs to use Emacs? Like, I love using
| Emacs for the elisp and having the power of a full lisp
| machine, but for CL I didn't find sly-mode/slime to offer
| anything particular paradigm-shiftingly more powerful than the
| vim/nvim adaptions?
|
| This very side is written in CL in vi, if I'm not mistaken?
| kagevf wrote:
| It's written in arc, a lisp language Paul Graham created. I
| think you're right about vi, though.
| bmitc wrote:
| The site is written in Arc, which is a language written in an
| older version of Racket.
| jay-barronville wrote:
| Clojure isn't an "actual" Lisp because it's not Common Lisp?
| Are you serious? Purity spiral much?
| tmtvl wrote:
| Parent stated that some variations drop the 'whole different
| computing system' part of Lisp; which makes them Lisp-syntax
| languages rather than actual Lisps. I believe he means things
| like modifying a class and updating all existing instances
| without having to restart the application, the
| continuation/restart system, and so on.
|
| As an aside, please remember the guidelines: 'Please respond
| to the strongest plausible interpretation of what someone
| says, not a weaker one that's easier to criticize. Assume
| good faith.'
| bmitc wrote:
| The comment was well within the guidelines and is a viable
| point. When people make broad statements on Lisp like the
| original great-grandparent comment, they really need to
| clarify whether they're talking about Common Lisp or Lisp-
| likes. The original LISP doesn't have the features that
| Common Lisp has, so it'd be weird indeed to say that LISP
| wasn't an actual Lisp.
|
| In retrospect, the comment was talking about Common Lisp
| and not just Lisp-likes and tried to make the distinction
| but did a poor job of it with comments like:
|
| > Clojure and Racket are in that category. They lack the
| full power of CL; so they're just Lisp-syntax languages,
| not an actual Lisp.
| lispm wrote:
| Common Lisp and/or its implementations (and a bunch of
| other dialects) have most most of the features of the
| original LISP directly, often with minor changes, like
| many of its operators and data structures (like the
| linked list). It was designed to be largely backwards
| compatible with earlier LISP. Original LISP
| implementation features like the self hosting machine
| code compiler, loading of natively compiled code and the
| ability to save/restore images of the Lisp heap (which
| really was already in the 1960s LISP) are also provided
| by various later Lisp implementations, incl. several CL
| implementations.
| dimitar wrote:
| Clojure also has a powerful REPL allowing you to interact with
| running processes in Emacs and in other editors and IDEa
| amszmidt wrote:
| Alas there are two schools -- those that consider Lisp to be a
| language with its cradle defined by JMC's "Recursive Functions
| of Symbolic Expressions and Their Computation by Machine" and
| descendants thereof (Lisp1.5, MACLISP, Lisp Machine Lisp,
| Common Lisp, Emacs Lisp, ...). Sort of like with C, where
| Objective-C is clearly a "C", similar with C++.
|
| Then there is another school which considers the meta
| programability, REPL, syntax, ... the more philosophical notion
| of Lisp (Scheme, Clojure, Racket, Arc, ...). Some have no
| similarity with Lisp 1.5 descendants, and only share a
| superficial similarity.
|
| Lisp seems to be the only language where people really want to
| argue that they are a Lisp, nobody tries to argue that
| Javascript, Java, PHP etc are "a C" (similar syntax?
| semantics?). Does it even matter what is "a Lisp"?
|
| The barrier for Lisp (be it one school or the other) is about
| as high as Python, you type the name of the implementation and
| do stuff. CL specifically doesn't say anything interesting
| about the REPL (e.g., SBCL doesn't even allow by default to
| navigate forms on the command line), so to say that it is
| "powerful" is very misleading. Similar about the requirement of
| Emacs, you can use anything you like.
| samatman wrote:
| > _Lisp seems to be the only language where people really
| want to argue that they are a Lisp, nobody tries to argue
| that Javascript, Java, PHP etc are "a C" (similar syntax?
| semantics?). Does it even matter what is "a Lisp"?_
|
| Lisp is far from being the only family of languages. There's
| the APL family, with k, j, q. There are the many Forths, to
| the point where it's been quipped that the language has more
| implementations than users. The C family rather clearly
| includes C++, Objective C, and D, as well as C itself (Swift
| and Rust are arguable here).
|
| I wouldn't put the three languages you named in the C family,
| but they're all Algols in a manner of speaking. At least, I
| routinely describe them that way, and people tend to
| understand what I mean. The reason no one argues that those
| languages are in the C family is just the broad and informal
| consensus that ABI compatibility is the most important
| feature, rather than syntax.
|
| Any time there's taxonomy going on, you'll have lumpers and
| splitters. I'm a lumper where Lisps are concerned. I would
| call Dylan and Julia Lisps, and have done so.
|
| If anything, what makes Lisp unique here is a faction of
| Common Lisp users who feel strongly that the only Lisp is
| Common, and historical variants which lead up to the
| Hyperspec (elisp being grandfathered in on that basis). I've
| never entirely understood this, but I don't let it bother me.
| That appears to be the source of the argument you reference
| in the section of your post I've quoted.
| bmitc wrote:
| > Clojure and Racket are in that category. They lack the full
| power of CL; so they're just Lisp-syntax languages, not an
| actual Lisp.
|
| That's pretty debatable that Clojure and Racket lack the "full
| power of Common Lisp". For one, they're all three different
| languages, each one having something the other doesn't. And
| another is that Racket is not a Lisp and doesn't purport to be.
| It's very much in the Scheme camp, but even then it is clearly
| it's own thing.
| bitwize wrote:
| You don't need to use Emacs to write Lisp, just like you don't
| need to use the ISPF dataset editor to write COBOL.
|
| That said, unlike COBOL, most of whose programmers these days
| use Visual Studio Code or a modern IDE, Emacs is still the best
| readily available support one can get for Lisp programming --
| and that's kind of a black mark against Lisp. I really wish
| Allegro or somebody would deliver a modern IDE for an
| affordable price, or at least good VSCode plugin support.
| massysett wrote:
| Some folks prefer the LispWorks IDE.
| lispm wrote:
| Uncut version: https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf
|
| A Pattern of Language Evolution, Gabriel/Steele 2008,
| https://www.dreamsongs.com/Files/PatternOfLanguageEvolution....
| aj7 wrote:
| Lisp is far and away the best of the nonreadable programming
| languages.
| Zambyte wrote:
| It's all the way up at the best readable ones instead :)
| marcosdumay wrote:
| It takes getting used to it, just like every other programming
| language syntax.
|
| If you are comparing it to the ones you are used to, of course
| you'll find it harder.
|
| (IMO, I don't like the Lisp syntax, but it's really not "non-
| readable".)
| 7373737373 wrote:
| It is hard to read though. As a beginner or someone
| unfamiliar with a new codebase you never know whether you are
| recursing into a special form or not. If you are, the
| semantics and order in which you ought to read and understand
| and further recurse into the argument list changes
| completely.
|
| How other programming languages limit the depth of this
| recursion and the variation/complexity of a code block, by
| splitting the semantics into a limited set of reusable
| syntactic constructs is very powerful. It is sad that most
| aren't homoiconic though.
| iLemming wrote:
| > It is hard to read though.
|
| What isn't? Java or C# with deep hierarchies of nested
| classes and tons of boilerplate, extensive use of
| interfaces or overuse of exception checking?
|
| Python with its magic methods and decorators and
| misindentation?
|
| Javascript with the callback hell, inconsistent type
| coersion and sometimes tricky async code?
|
| Ruby with its weird metaprogramming and monkey patching?
|
| C with the pointers mental acrobatics and pre-processor
| macros?
|
| Perl with weird default vars like $_ and tons of regexps?
|
| Haskell with its monadic structures and heavy use of weird
| symbols and operators?
|
| PHP with the crapload of its historical baggage, global
| vars and inconsistent, non-standardized function naming?
|
| Any programming language can be considered hard to read,
| quirky, slow, inconsistent, or lacking some feature.
| Everyone knows there are only three God-given, bullet-
| proof, guaranteed ways to write robust, fast, consistent,
| bug-free and scalable software. Three... Humankind has yet
| to discover those.
| iLemming wrote:
| Pfff... The Lisp syntax is one of the simplest, comprehensible,
| readable, no-BS sugar things. People with shallow experience
| often say it looks weird, but with some hands-on experience,
| you soon appreciate its elegance and power. The consistent,
| minimalist syntax becomes second nature and reveals its true
| beauty and functionality.
|
| You can easily read Lisp code off your phone screen - it wraps
| around, but retains the structure. Try that trick with pretty
| much any non-lispy language - even "the most elegant Python"
| fails there, face flat.
|
| EDN & Transit is far better than JSON - EDN is more flexible
| and expressive than JSON, making it a superior choice for data
| serialization. It's also more than two times smaller and
| cleaner, commas are completely optional.
|
| Hiccup is better than JSX & HTML - far more easier, cleaner,
| shorter and nicer to work with.
|
| similarly,
|
| s-expressions are better that XML & Yaml;
|
| CL's PLISTs and ALISTs & Clojure maps are better than
| Dicts/Hashes in other languages.
|
| Basically, you can leverage the expressiveness and simplicity
| of Lisp-like syntax to offer structured, readable, and powerful
| data representations. Add to that the ability to evaluate any
| given form on the fly through a connected REPL, basically
| "trying things while you read them," and that changes
| everything you thought you knew about the readability of code.
|
| Those who call Lisp "non-readable" I suppose, in fact, never
| tried to actually read it. Of course, if you never learn a
| language, it would remain incomprehensible.
| aj7 wrote:
| Paul Graham felt all development should be in Lisp. Problem is
| readability by maintainers in the future. To facilitate that, the
| number of characters in the comments would have to exceed that in
| the code.
| barrell wrote:
| Even with all those comments, it still ends up being less
| characters than other languages :D
| CaptainOfCoit wrote:
| > Problem is readability by maintainers in the future
|
| Sounds like a problem that exists in every single programming
| language to date. And the reason that problem appears is not
| because of the languages themselves.
| giovannibonetti wrote:
| Some languages are designed with a strong focus in simplicity
| and great compiler errors to overcome that issue as much as
| possible. Gleam and Elm are some of them.
| theodpHN wrote:
| Got a link to fairly simple examples comparing Lisp solutions to
| those in another more 'mainstream' language (e.g., C, Python,
| BASIC, Java) that illustrate the benefits of using Lisp over
| another language for a 'practical' application? Thanks!
| Jtsummers wrote:
| https://rosettacode.org
|
| https://rosettacode.org/wiki/Category:Common_Lisp
|
| This has a lot of problems solved in multiple languages.
| theodpHN wrote:
| Thanks, that is a great site! Will have to look at more, but
| looking at examples like the following, I'm not having a Lisp
| Aha! moment when I compare the Lisp and Julia/Python
| implementations, e.g.,
|
| Cheryl's birthday
| https://rosettacode.org/wiki/Cheryl%27s_birthday
|
| Seems like part of the problem is that Lisp is often
| demonstrated with examples that your average programmer can
| turn to 'black box' pre-built functions/packages/software
| for. That Lisp can help one extend a programming language to
| add a CASE statement, for example, is not going to win the
| hearts and minds of those who are already using a programming
| language with a built-in CASE statement. It may be neat from
| an intellectual standpoint, but not from a practical one.
|
| And the merits of the example linked to below of how Lisp can
| be used to implement an in-memory database will surely be
| completely lost on anyone with access to in-memory database
| software like DuckDB.
|
| Practical Common Lisp: An MP3 Database
| https://gigamonkeys.com/book/practical-an-mp3-database
|
| DuckDB: SQL Introduction
| https://duckdb.org/docs/archive/0.8/sql/introduction.html
| Jtsummers wrote:
| I don't think anyone should expect to get an "Aha! moment"
| from looking at algorithmic code. That's going to be the
| same in most languages.
|
| If you want a "Lisp Aha! moment" you'd probably be better
| off looking at something that's actually Lisp-centric like
| _Paradigms of AI Programming_ by Norvig
| (https://github.com/norvig/paip-lisp). You eventually build
| up to a Prolog to CL compiler written in CL.
| 7373737373 wrote:
| Is there any old or new Lisp variant with excellent, beginner
| friendly (or even loving) documentation?
| pgt wrote:
| Clojure: http://clojurescriptkoans.com/
| swatson741 wrote:
| R6RS has a book that describes everything simply except for
| setting up the interpreter. [1]
|
| Racket has all of that and everything else you need to get
| started like tooling and modules. [2]
|
| Both lisps are no nonsense scheme variants.
|
| [1](https://www.scheme.com/tspl4/) [2](https://racket-lang.org)
| sourcepluck wrote:
| https://janet.guide/ this document can definitely be described
| as loving.
| gjvc wrote:
| anyone got the .tex source for this?
| kazinator wrote:
| Please link to uncut version on Gabriel's own site.
|
| See https://news.ycombinator.com/item?id=40484444
___________________________________________________________________
(page generated 2024-05-26 23:00 UTC)