GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-09-06) - page 1 of 10
 
___________________________________________________________________
Lisp Machine Manual (1984)
81 points by sillysaurus3
https://hanshuebner.github.io/lmman/title.xml
___________________________________________________________________
 
SirFatty - 2 hours ago
"Those not on the Arpanet may send U.S. mail to.."Ah.. nostalgia.
 
fusiongyro - 4 hours ago
The classic joke in here is that if you look up "fascism" in the
index, it goes to the section about logging in. User authentication
wasn't part of the dream, so having been forced to build it, they
embedded a dig on it right in the
manual.https://hanshuebner.github.io/lmman/files.xml#fascismI think
there are a few other jokes in the index but I don't recall what
they are.
 
  mtreis86 - 2 hours ago
  "Once a password is recorded for one host, the system uses that
  password as the guess if you connect to a file server on another
  host."
 
  Animats - 3 hours ago
  That was probably Stallman's doing. He wrote most of the LISP
  machine code.
 
    adrianm - 2 hours ago
    The other side of the argument.https://danluu.com/symbolics-
    lisp-machines/Also interesting bits about the fall of
    Symbolics, the AI winter, and why Lisp adoption waned as a
    result.
 
    lispm - 2 hours ago
    > He wrote most of the LISP machine code.That's nonsense. The
    Lisp Machine code was written by several people, some which had
    significant contributions.
 
      ScottBurson - 2 hours ago
      Indeed.  Before they left to found Symbolics, David Moon,
      Howard Cannon, Dan Weinreb, and others (I'm sure I'm
      forgetting at least one name) wrote the vast bulk of the
      system.  I think Richard Greenblatt wrote most of the
      microcode (he also did most of the hardware design and
      construction).After Symbolics formed, RMS did an amazing job
      at reimplementing many of the new features Moon and company
      were adding, so as to keep the MIT version of the system at
      rough parity with the Symbolics version.  So his name belongs
      in the story, but not first.
 
  cat199 - 2 hours ago
  not surprising since many of the early lisp people grew up on ITS
  which had a built in 'crash' command available to all users which
  crashed the system..https://en.wikipedia.org/wiki/Incompatible_Ti
  mesharing_Syste...
 
Chaebixi - 3 hours ago
If you have NoScript and Firefox, you have to enable JS on the
domain for the stylesheet to render the documents.
 
DonHopkins - 2 hours ago
The cover of the Lisp Machine Manual had the title printed  in all
caps diagonally wrapped around the spine, so on the front you could
only read "LISP CHINE NUAL". So the title was phonetically
pronounced: "Lisp Sheen Nual".My friend Nick made a run of custom
silkscreened orange LISP CHINE NUAL t-shirts (most places won't
print around the side like that).https://www.facebook.com/photo.php
?fbid=74206161754&l=54ec4e...I was wearing mine in Amsterdam at
Dappermarkt on Queen's Day (when everyone's supposed to wear
orange, so I didn't stand out), and some random hacker (who turned
out to be a university grad student) came up to me at random and
said he recognized my
t-shirt!http://www.textfiles.com/hacking/hakdic.txtCHINE NUAL
(sheen'yu-:l) noun.The reference manual for the Lisp Machine, a
computer designed at MIT especially for running the LISP language.
It is called this because the title, LISP MACHINE MANUAL, appears
in big block letters -- wrapped around the cover in such a way that
you have to open the cover out flat to see the whole thing. If you
look at just the front cover, you see only part of the title, and
it reads "LISP CHINE NUAL"
 
feelin_googley - 1 hours ago
"I believe the commercialization of software has harmed the spirit
that enabled such systems to be developed."
 
hoodoof - 4 hours ago
There seems to be plenty of people who think Lisp is awesome.If so,
then why hasn't it become "mainstream"?
 
  patrickmay - 3 hours ago
  Because Brendan Eich's management lied to him about allowing him
  to do Scheme in the browser:
  https://brendaneich.com/2008/04/popularity/When I think of what
  web programming could have been like, it makes me want to weep.
 
    willismichael - 2 hours ago
    I also dream of what it would be like if lisp in the browser
    had become mainstream, but it's possible that if he had
    implemented it like he wanted to, it wouldn't have received
    such wide spread adoption like javascript did.
 
      patrickmay - 2 hours ago
      True.  My optimistic/pessimistic daydream is that, as the
      only game in town for some period of time, it would have
      introduced enough developers to the language to really give
      it traction.  We'd now be seeing people asking "Why can't I
      run the same language on the server as in the browser?"  It
      would be the second renaissance!
 
      zeveb - 1 hours ago
      > it's possible that if he had implemented it like he wanted
      to, it wouldn't have received such wide spread adoption like
      javascript did.I don't care for Scheme, but I'd be very, very
      surprised if it'd have failed in such a situation.  If a
      terrible train wreck of a language like JavaScript can
      succeed, pretty much anything better than INTERCAL can.
      People wanted to extend browsers; had Scheme been the only
      way to do that, Scheme is what they'd have used.
 
  setzer22 - 4 hours ago
  I don't see why language quality should have anything to do at
  all with mainstream usage.PHP can be considered a mainstream
  language today. Even COBOL in some parts of the industry. Are
  they any better because of that?
 
    AnimalMuppet - 2 hours ago
    Well... for a language to succeed long-term, it needs to be
    either significantly better than the alternatives (at some
    particular kind of use), or else it needs to be entrenched in
    existing code.When C began to spread, it was significantly
    better than alternatives for writing operating systems and
    associated tools on commodity hardware.  Part of that "better"
    was cost - cost of the machines it ran on, cost of buying a
    compiler, and cost of implementing a compiler.  (The mistake
    the anti-C people make in saying "but other languages were so
    much better!" is that they forget that cost was part of
    "better".)C became entrenched in Unix and, later, Windows.  But
    it didn't start entrenched.  It started by being better.If Lisp
    were significantly better, with everything considered, it
    should have won by now.  I mean, yes, there are a lot of people
    chasing the current hotness.  But the programming profession is
    not made up entirely of fools and sheep.  Better languages get
    noticed, get used, acquire momentum.  (Note well, however, that
    "better" again is "better with all things considered" - it
    doesn't equate to "better" as defined by theorists who about
    how much better their language is, even though it's a little-
    used language.)
 
      [deleted]
 
    criddell - 2 hours ago
    According to TIOBE, in 1987 only C was more popular than Lisp.
    Thirty years later, C is #2 and Lisp is #31. Lisp was
    mainstream and for some reason other languages overtook it. I
    think it's a good question.
 
  _sdegutis - 4 hours ago
  Most of Lisps novel features have been incorporated into the
  mainstream high-level languages of today: Python, Ruby,
  JavaScript, C#, Objective-C. The one that's still relatively
  unique to lisp is homoiconicity-based macros, but some
  non-s-expression languages like Nim and Elixir are able to
  accomplish them. And then there's languages like Clojure and Hy
  which are gaining mainstream status slowly through over-zealous
  adoption by disgruntled Rubyists and Pythonistas.
 
  pjmlp - 4 hours ago
  Lisp workstations were quite expensive with proprietary source
  code, while UNIX workstation were built on source code available
  almost for free (AT&T could not sell it so they licensed it for a
  symbolic price), which made them cheaper to sell.Also the
  companies involved in selling Lisp machines did quite a few
  management errors.
 
    Animats - 2 hours ago
    Ask anyone who owned a Symbolics 3600, a single-user machine
    the size of a refrigerator.   Overpriced hardware. Poor
    maintenance service and low hardware reliability. A level of
    company arrogance seldom seen in a small company. (They thought
    they were going to rule AI. Didn't happen.) And, originally,
    45-minute garbage collections.  (Virtual memory plus slow disk
    plus naive garbage collection.)What really killed them was
    decent LISP compilers for mainstream CPUs.  LISP doesn't really
    need special hardware with tag bits.
 
      lispm - 2 hours ago
      When the machine appeared there was nothing like it. Later
      machines were more robust and also smaller using
      microprocessors, downto Lisp Machines on Nubus cards for
      Macs.> a small companyAt max they had 1000 employees.> And,
      originally, 45-minute garbage collectionsThen they invented
      and commercialized better GCs.
 
      pjmlp - 2 hours ago
      Yes, that is what I meant with management errors.
 
  progman - 2 hours ago
  Excellent languages like Lisp, Haskell, Ada, etc., maybe also
  Rust and Nim, will likely never be mainstream since they offer a
  lot of features which require a lot of discipline by the
  programmer.Companies want mediocre developers for mediocre
  languages (Java, C++, C#, etc.) because mediocre developers can
  be replaced easily, and because they get lower salary due to
  great competition.Mediocre languages are just good enough to
  implement the things which need to be done. All their features
  are comprehensible by mediocre developers. That's another reason
  why only mediocre languages become mainstream.
 
  fusiongyro - 3 hours ago
  A more powerful language is not enough of an advantage to defeat
  entrenched alternatives with strong network effects. There isn't
  a reason why language X is not entrenched, but there are
  historical reasons why C, C++ and Java are entrenched. Lisp just
  isn't enough more powerful than them to beat their home-court
  advantage. I guess I'd say, Lisp might be 10x better, but the
  network effects are orders of magnitude more meaningful than that
  intrinsic benefit.It's not a very meaningful answer to the
  question, but it's a bit like asking why Todd isn't rich when we
  all know Todd is a smart guy. It's because getting rich takes
  more than raw intelligence.Suppose you have a wildly evolving
  field where nobody can really predict what technologies are going
  to be successful in the market beyond the next five years or so.
  Suppose you have no internet. Suppose there are thousands of
  programmers with the ability to invent a language. Wouldn't you
  expect that some of them will, by happenstance, wind up on
  successful products and become successful while others stay
  relatively unknown? That's the birth of the mainstream
  programming languages and their antecedents in the 70s and early
  80s.
 
    AnimalMuppet - 2 hours ago
    > Lisp just isn't enough more powerful than them to beat their
    home-court advantage.Note, however, that Lisp had a 10 year
    head start on C.  Lisp had the home-court advantage, and C ate
    its lunch anyway.
 
      fusiongyro - 2 hours ago
      Lisp had a 10 year head start on expensive academic machines
      that were low on industry uses. C had a head start on high-
      end mainframes for actual work. Then the main contenders on
      the nascent PC were assembly, C and Pascal. P-code based
      compilers arrived quickly and were faster to develop with,
      but the resulting code was inefficient?and early PCs were
      sufficiently resource-constrained that inefficient code was
      very noticeable. So C obtained the territory that mattered:
      high-end business machines and the low-end machines that
      would spark the computing revolution, and just had to grow
      the two together.Lisp had a head start, but wasn't on the
      track that mattered.
 
        AnimalMuppet - 2 hours ago
        > C had a head start on high-end mainframes for actual
        work.No.  C started on low-end minicomputers, not high-end
        mainframes.And why didn't Lisp take over the low-end
        minicomputers?  Because Lisp was too resource-hungry, and
        those low-end minicomputers didn't have the muscle to run
        Lisp well.  They ran C just fine, though.
 
          fusiongyro - 2 hours ago
          So how did Lisp have the home court advantage then? :)
 
          AnimalMuppet - 1 hours ago
          Because it existed, and C didn't.  Because it had a
          decade of code already written, and C didn't.  Because it
          ran on many machines, and C initially ran on one.
 
          [deleted]
 
          fusiongyro - 1 hours ago
          It ran on several machines, but not the ones that
          mattered. The existing code was irrelevant and not
          portable.I'm not denigrating Lisp. I'm saying the network
          effects favored C because the PC happened to take off.
 
          AnimalMuppet - 55 minutes ago
          > It ran on several machines, but not the ones that
          mattered.And why wasn't it ported to the ones that
          mattered?  I keep hearing about how easy it is to build a
          (simple) Lisp compiler.  Why wasn't it ported, or a fresh
          one built?> The existing code was irrelevant and not
          portable.Why was the existing code irrelevant?  In ten
          years, nobody wrote anything in Lisp that mattered to
          anyone?In fact, there were Lisp compilers for the PDP-10,
          which (I presume) could run on the PDP-11, where C began
          to take over the world.  Why didn't those Lisps take over
          the world?  You can't explain it just by C existing on
          the right machines at the right time.  (There wouldn't
          have been C on the PC if it hadn't taken off - at least
          to some degree - on the PDP-11 a decade earlier.)
 
          sedachv - 20 minutes ago
          > Why wasn't it ported, or a fresh one built?... In fact,
          there were Lisp compilers for the PDP-10, which (I
          presume) could run on the PDP-11The PDP-11 was in no way
          compatible with the PDP-10, and there was no way a PDP-10
          Lisp implementation like Maclisp or Interlisp would fit
          on a PDP-11. All you have to do is Google "PDP-11 Lisp"
          to see that there were many different Lisp interpreters
          and at least one compiler implemented for the PDP-11
          throughout the 1970s. Likewise Intel processors - the
          first implementation of Lisp on the 8080 was done by
          Takashi Chikayama
          (http://www.logos.ic.i.u-tokyo.ac.jp/~chik/) in 1976 (htt
          p://www.softwarepreservation.org/projects/LISP/utilisp/ut
          ...)
 
          fusiongyro - 30 minutes ago
          I don't have to explain why Lisp failed to take off. I
          just have to explain why C did, because network effects
          are more significant than language advantages. This is my
          central thesis.I don't think awareness of Lisp was evenly
          distributed among people developing on PCs in the time
          period when the network advantage was obtained. Even if
          it was, if there were already a decent C compiler, I
          don't think most practical engineers would immediately
          embark on a compiler development project. During this
          era, those who did know about Lisp certainly would have
          regarded it as being too resource-intensive for work in a
          resource-constrained environment like the PC.I think it's
          specious to say it's easy to develop a simple Lisp
          compiler, so why didn't anything get ported. The code you
          may have wanted to port would not have been written in
          some minimalist dialect of Lisp, it would have been
          written in ZetaLisp. So there would be assumptions about
          resources and the underlying system that you would have
          to fake. And again, we're talking about porting from a
          resource-rich environment to a resource-scarce
          environment.It was probably a reach for me to say there
          wasn't anything to port. But what would someone have
          wanted to port? A graphical application that ran on a
          Lisp machine would have made assumptions about the
          display that aren't true about a PC. An academic AI
          program would have been too short on resources to be much
          use.What wound up selling the PCs in the early days was
          business applications. Were there an assortment of useful
          business applications on Lisp machines that there was
          commercial demand for? WordStar and Visicalc invented
          that territory and were first released in the late
          70s?does anyone remember programs for the Lisp machine
          that businesses were clamoring for? And really, software
          churn has always meant there are more new programs in use
          than old ones.What I don't have an explanation for is why
          the C compilers produced better code than the Pascal
          compilers. Partly, I know p-code made it faster to build
          a Pascal compiler but I don't know why it inhibited
          development of more performant ones. Turbo Pascal's speed
          of compilation was a result of not having an AST, which
          probably inhibited performance optimizations, but that
          may have been too late in the story to explain anything.
          And I don't have an explanation for why nobody developed
          a Lisp-like language that had explicit allocation. My
          best guess would be simply that their attention was
          elsewhere, probably working on AI, which wouldn't bottom
          out until after the winners were already entrenched.By
          the way, in case it isn't clear, I am really enjoying
          this conversation. I'm very interested in this window of
          time in computing and if I have a wrong idea about
          something, I do want to know. The only way to preserve
          this history is to talk about it and keep the memory
          alive.
 
    [deleted]
 
  dleslie - 3 hours ago
  Clojure isn't mainstream?
 
  davexunit - 3 hours ago
  It all comes back to the "worse is better" thing.  Frequently
  enough the technologies in mainstream usage are not the best,
  technically speaking. Mainstream programming languages are still
  playing catch up on the features that the Lisp family of
  languages has had for decades.  UNIX succeeded not because it was
  the best OS of the time (it wasn't, MIT made much better systems)
  but it had a killer feature: it ran on commodity hardware, the
  PDP-11.
 
    e40 - 3 hours ago
    but it had a killer feature: it ran on commodity hardware, the
    PDP-11That is not the essence of worse is better.  UNIX won
    over the others because it was simple and regular, and was
    built from components that could be reassembled into more
    complex things.  Pipes were a big part of that.
 
      davexunit - 2 hours ago
      UNIX had a weak design.  It won not because it was good, but
      because it ran on more computers.  There are many other OSes
      of that time period that had superior designs.The Lisp
      Machine had way better composition primitives than UNIX's
      pipes passing plain text around.
 
        xfer - 1 hours ago
        The part of the problem they were hard to implement
        efficiently back then.
 
  middleorigin - 2 hours ago
  There's not much money in getting people to use it?it's rarely
  required and can be expensive to train for (as opposed to java,
  say).
 
  Jtsummers - 3 hours ago
  What does mainstream have to do with quality? There's a lot of
  crap that's mainstream in most industries. I don't see why ours
  would be any different (especially as fad-driven as programming
  tends to be).
 
  dwheeler - 3 hours ago
  Asbestos suit on.There are many positive things you can say about
  Lisp.However, many day-to-day developers, and their managers,
  believe that Lisp's syntax creates nigh-unreadable programs. For
  example, there's no built-in infix syntax, as opposed to
  practically all other programming languages, and many modern
  programmers today expect infix as minimum table stakes for a
  language.  Lisp syntax is extremely simple, but that doesn't mean
  the resulting code is easily read.  Very smart people will
  disagree with that opinion - especially a number of people on
  Hacker News!! However, just look up phrases like "lots of
  irritating silly parentheses" and you'll see that this opinion is
  extremely widespread.  Many people here will disagree with the
  sentiment, and that's fine, but it's a fact many people believe
  programs in Lisp syntax are hard to read.A lot of people will
  reply that Lisp's syntax is simple, that real programs have been
  written in Lisp, that it has a kind of simplicity/elegance, and
  that Lisp syntax enables powerful facilities like Lisp macro
  processing.  All of that is absolutely true.  Lisp is quite
  powerful.  But trying to convince people that Lisp is "advanced",
  even though it doesn't support basic capabilities like infix out
  of the box, is a losing battle.  Forth is one of the few other
  languages that has an odd syntax and lacks support for infix, and
  it is also rarely used today.Feel free to reply, but thoughtful
  responses preferred :-).
 
    kazinator - 1 hours ago
    Here is the thing about infix: the lack of infix probably does
    hurt, but not lack of the arithmetic infix.  There is various
    syntactic sugar used in programming languages that is front-
    and-centre, expressing program and data structure, used
    everywhere.I believe that most programmers won't have that much
    problem with (+ (* x x) (* y y)), but even those who don't will
    balk at cruft like (aref a 3), and (slot-value obj 'foo).In the
    TXR Lisp language, I provide a set of well-targeted syntactic
    sugars for things like this; sugars which do not disturb the
    surrounding Lisp expressions and don't introduce ambiguities
    (precedence and associativity).
 
    AdeptusAquinas - 2 hours ago
    As a day-to-day developer, but one who wants to learn as much
    as I can outside of my domain, you are spot on.I generally work
    in an OO language (C# specifically) and have long wanted to get
    into functional programming. I am finally making headway, but
    after false starts in lisp (racket, clojure) ultimately I am
    using F#. Partially, admittedly, due to the .NET aspect (its
    even shipped as part of default dotnet core) but also because
    of the lack of parenthesis.One of the reasons to go functional
    was to get away from the excessive syntax and formality of a
    C-based language, and replacing every curly bracket with 20
    parenthesis (minor hyperbole) doesn't achieve that for me.
 
      nocman - 1 hours ago
      "replacing every curly bracket with 20 parenthesis (minor
      hyperbole)"It isn't even minor hyperbole, it's just plain
      false.It has been my experience that, generally speaking, the
      combination of curly brackets { }, square brackets [ ], and
      parens ( ) in languages with C-like syntax is at worst
      roughly equivalent to the number of parens in most lisp
      dialects.Some people freak out because they see a function in
      a lisp that ends with:  some-final-expression)))))  But they
      think that it is totally fine when a C-like langauge ends
      with:          some_statement_or_expression         }       }
      }   } }If the stacks of parens at the end bother you so much,
      there is nothing in most lisps preventing you from indenting
      them on lines too:  some-final-expression         )       )
      )   ) )I wouldn't advise it, but you can do it.I think more
      than anything, people are just unwilling to accept that lisps
      look different than the X number of curly-bracket-style
      languages they are used to.  It looks weird to them at first,
      because of past experience, so to some degree they are
      looking for a reason to write them off from the
      beginning.When I was in college, I had this initial reaction,
      and didn't even consider anything lisp-like for many years.
      It was only my frustration with the limitations of C-like
      langauges that led me to reconsider lisps years later, and
      man am I ever glad I did.[EDIT for additional comment]:and
      btw, I'm a "day-to-day developer" also.
 
        AdeptusAquinas - 1 hours ago
        You might be right in aggregate counts, but the difference
        is that in a C-style language you have different types of
        fluff: curly braces, parenthesis, semi colons etc. So the
        count of any one type is not overwhelming (unless you let
        your cyclomatic complexity get away from you). In Lisp its
        almost all parenthesis, so yes it is more.Besides which my
        point is more that why have any of this at all? Only the
        insane write code without tab or space indentation, and if
        you are doing that anyway then an OCaml-esque language like
        F# where that serves as your grouping syntax is the saner
        option.
 
          sedachv - 53 minutes ago
          > Only the insane write code without tab or space
          indentation, and if you are doing that anyway then an
          OCaml-esque language like F# where that serves as your
          grouping syntax is the saner option.Instead of making
          disparaging remarks about people's mental health, learn
          some basic parsing theory:https://en.wikipedia.org/wiki
          /Context-sensitive_grammar
 
        craigsmansion - 1 hours ago
        > I wouldn't advise it, but you can do it.That's basically
        how I write functions in Lisp, with indentation levels and
        every closing parenthesis on a separate line.The thing is,
        when you're done writing a (leaf)function in Lisp, you're
        done: it works. Since you won't need to revisit it (unless
        the functional design changes), you clean it up for
        compactness by grouping all closing parenthesis together.I
        could be the only one, but I've always found it normal and
        practical to develop with indentation, and regroup when I'm
        done.
 
    shawn - 2 hours ago
    For example, lisp has no built-in infix syntaxI wrote one: http
    s://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1d...http
    s://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1d...It's
    an experimental feature, but it seems to work fine with no
    ambiguities. It also has "x = 42" for implicit local variables,
    rather than "(let x 42 ...)"What do you think of it? Is it much
    more readable? I'm still debating whether to keep it.
 
    nickpsecurity - 6 minutes ago
    The fact that huge number of people couldnt get past the syntax
    is why I liked efforts such as Dylan:https://en.m.wikipedia.org
    /wiki/Dylan_(programming_language)A bit better. Then, the
    approach closest to mine of mixing 3GL syntax with LISP was
    Julia language. It was femtolisp underneath with a syntax more
    like a traditional language. You get the power without the
    ugliness. Dylan I havent seen in a long time but Julia is
    taking off. Look into it if you havent.https://julialang.org
 
    kazinator - 2 hours ago
    If we randomly sample no-longer-used languages, I suspect we
    will see infix support more often than not. Infix won't save a
    language.> fact many people believe programs in Lisp syntax are
    hard to read.It's not a fact; it's just a couple of trolls,
    plus people just repeating what they have heard. People who
    reply to "lisp" with "lots of irritating silly parentheses"
    haven't necessarily even tried to read any examples of Lisp;
    they are just repeating a joke they heard.Just like how people
    who say "fix it again, Tony" when they hear "Fiat", who have
    never driven a Fiat, and have no idea about the statistics of
    Fiat reliability relative to other makes of car.
 
    avodonosov - 2 hours ago
    You just haven't tried.
 
    [deleted]
 
    Jach - 2 hours ago
    Lacking infix syntax out of the box is a problem, though not
    hard to add as a sibling mentioned; for those curious I like
    linking to this gem dating back to '93 since it's part of
    quicklisp now https://github.com/rigetticomputing/cmu-infix The
    rest of the syntax being somewhat alien-ish is also a problem,
    but it goes away with practice.
    (https://www.thejach.com/imgs/lisp_parens.png)But I don't think
    syntax alone is enough to explain Lisp's apparent languishing
    (though only apparent since it seems to be on the rise again),
    because we have Clojure. Clojure has the same syntax issues as
    Lisp (ok a bit fewer because of no reader macros and there's an
    argument that bracket variety is more pleasant to read) yet
    it's very popular all things considered. And because Clojure
    has a BDFL, if lacking infix OOTB was really an issue (I don't
    think it's come up in any of the annual surveys), RH could just
    include one of the libraries for it out of the box. SBCL could
    do that for Lisp, but it would be non-standard.To me there are
    several stronger drivers for language adoption than anything
    the language itself offers. Here are three: having a BDFL
    (Python, Perl, PHP, Clojure... not Lisp), having big corporate
    backing (Swift, Objective C, C#, Go, arguably Java but driven
    by more than 1 megacorp... not Lisp), being the lingua franca
    of a very widespread platform (Javascript (web), PHP (shared
    web hosts), Bash, C/C++ (unix, windows), Java (android)... not
    Lisp, maybe if the Lisp Machine had won but it didn't).
 
      [deleted]
 
    progman - 2 hours ago
    Your perception confirms my previous post that mediocre
    developers have a hard time to think in different ways, even to
    code in non-infix notation. Linux suffers a similar problem.
    Many people are so used to Windows desktops that they have a
    hard time to think in different ways, and to appreciate the
    Linux way which provides not one common desktop but many ones
    which can freely be chosen.It reminds me of the quote "Who
    knows only hammers as a tool considers every problem a
    nail".Also the typical claim that LISP just means "lot of silly
    parentheses" points out that those critics have never tried to
    develop in the Lisp way. Ironically, as time goes on and
    complexity rises, more and more developers appreciate new
    features which have been available in Lisp for more then 50
    years -- lambda expressions, maps, and macros for instance.
    Lisp was so far ahead of its time that people today still have
    problems to realize what is so fascinating about Lisp, and why
    Lisp machines are so awesome. They should take a look at the
    graphical shell [1] of McCLIM [2] (a revival of the famous CLIM
    GUI) to see that powerful desktop computing can be very
    different.[1] https://common-
    lisp.net/project/mcclim/static/media/screensh...[2] https
    ://common-lisp.net/project/mcclim/excite.html
 
    xfer - 1 hours ago
    No infix operators is an advantage. I don't like memorizing
    precedence tables; most of the time people use parens just to
    be on safe-side anyways. It's even considered good practice in
    most cases.I can see how lots of parentheses can look
    irritating (particularly at the end of expressions). But once
    you are familiar with it(it's not that hard) you can just read
    between parens and you don't see them anymore(most lisp code is
    well-indented). There is also a thing called sweet-exp that is
    supported by some popular lisps.
 
    hood_syntax - 2 hours ago
    I understand where you're coming from and agree to a large
    extent, but I think your hypothetical person's characterization
    of infix as a "basic capability" is a bit off. It's
    antithetical to Lisp's design to make use of infix notation. As
    far as Forth goes, I would say the same thing.
 
    ScottBurson - 1 hours ago
    The odd thing about the fully parenthesized syntax is that it's
    offputting at first, but once you've been doing it for a little
    while, in an editor that does parenthesis matching and auto-
    indentation, it gets to be just as easy and pleasant to work
    with as more common languages, or even more so.  (Packages like
    Emacs 'paredit' make it even better.  (I haven't tried
    'parinfer'.))I understand this is hard to believe if you
    haven't tried it, and it certainly does take some getting used
    to.    Lisp is, in short, an acquired taste.  Think of it like
    very spicy food: many people avoid it, but those of us who like
    it, like it a lot.
 
    taeric - 2 hours ago
    I don't even disagree on the infix math point, really.  I do
    find it awkward that it makes up a small fraction of what you
    actually do in most programs.  Seems odd that such a minorly
    applicable point holds such high regard.Sadly, I assert that
    this being the main irritation of LISP is one more of fashion
    than it is of actual applicability.  Sad, because I do have
    pride in our communities to want them to be above fashion.
    Most people that "hate" LISP have never written a single line
    of it, ever.  Nor will they ever do so.
 
      [deleted]
 
      peatmoss - 25 minutes ago
      On lisp hate: back in the mid-/late-90s on Slashdot it was en
      vogue to make jokes about lisp. I'm fairly certain it
      originated in the spirit of the Unix haters handbook, in that
      it was in-group therapy for the initiated. But then I think
      it just became a thing that won karma points, and thus was
      repeated as a truism.I remember working the university
      computer helldesk in the late nineties and repeating such a
      joke to the smartest white-bearded Unix wizard I've ever met.
      He rattled off five or six more jokes about lisp, and then
      proceeded to explain the AI systems he used to work on, and
      why it was his favorite language.Having never really coded in
      lisp myself, I was immediately ashamed of the fact that I had
      been thoughtlessly making light of a thing that others
      valued. And years later, I'm atoning by trying to use Racket
      (sometimes Clojure) whenever I can.
 
  agumonkey - 3 hours ago
  Lisp genes are all over the place. Wait for 20 years and you'll
  even more of them.
 
  hcarvalhoalves - 4 hours ago
  "Lisp is a minimal fixed point amongst programming languages.
  It's not an invention, but a discovery. That's why it won't just
  go away." - Brian Beckman [1]That said, LISP machines are quite
  interesting on their own, because they follow a different
  architecture compared to (mainly) register-based x86 and
  similar.[1]
  https://twitter.com/lorentzframe/status/821001730938654724
 
  jandrese - 4 hours ago
  A big part, especially back in 1984 was that LISP tended to be
  slow on traditional PC hardware.  Also somewhat memory hungry,
  which was a definite problem back in the 80s when memory was
  expensive.
 
  yung_endian - 4 hours ago
  You are commenting on a site run by Lisp
 
    hoodoof - 4 hours ago
    Are you saying that makes Lisp mainstream?
 
      fao_ - 4 hours ago
      It's more mainstream than the $NEW-AWESOME-JAVASCRIPT-
      FRAMEWORK. Not being mainstream doesn't mean that something
      isn't awesome. There are lots of awesome discoveries trapped
      in research/academia because the overton window of the
      current technology community is shifted too far to "What I am
      used to", or because nobody cares to look.Eventually some of
      these ideas will get dislodged and fall down to us, but you
      can't rely on that. If you read about Lisp's history it's
      very obvious why it is rejected by people at the moment.
 
        hoodoof - 2 hours ago
        >>> It's more mainstream than the $NEW-AWESOME-JAVASCRIPT-
        FRAMEWORK.This sentence doesn't make any sense."Mainstream"
        means used alot - widespread acceptance.Lisp is #33 on
        Tiobe after Cobol, Foxpro, Fortran and Ada.  How you can
        compare that to the takeup of the latest JS nframeworks I
        don't really understand.https://www.tiobe.com/tiobe-
        index/21    SAS     1.372%22        Dart    1.306%23
        D       1.103%24        Transact-SQL    1.075%25
        ABAP    1.065%26        COBOL   1.055%27        (Visual)
        FoxPro 0.932%28        Scala   0.923%29        Fortran
        0.879%30        Ada     0.787%31        Crystal 0.756%32
        Erlang  0.733%33        Lisp    0.690%34        Awk
        0.662%35        Lua     0.648%
 
          criddell - 2 hours ago
          I was just looking at that same list. I'm surprised Lua
          is that low considering how many applications embed it.
 
          [deleted]
 
          Jtsummers - 2 hours ago
          https://www.tiobe.com/tiobe-index/programming-languages-
          defi...The reason those rankings are (mostly) useless is
          that it's based on search engine hits. An active,
          effective community that for whatever reason doesn't
          generate a million and one blog entries a month will not
          perform as well on the index. This makes it very useful
          for indicating fads in programming, but not reality.
 
  shawn - 2 hours ago
  The future is long. Computers will be around for thousands of
  years. They've only been useful for the last ~60 years.A
  programming language needs at least two things to succeed: a
  niche, and corporate backing. Almost every successful language
  has had both.Lisp's benefit is that it is discoverable.
  Programmers hundreds of years from now will continue to stumble
  across the roots of lisp: http://www.paulgraham.com/rootsoflisp.h
  tmlhttp://ep.yimg.com/ty/cdn/paulgraham/jmc.lispThe axioms are
  too simple not to discover by accident.What are some promising
  niches for Lisp?I think gamedev is a likely candidate. The whole
  gamedev industry still uses C++ / C#. But Lisp can be just as
  fast -- you can even make a statically-typed Lisp, which avoids
  any possibility that Lisp's performance will bite you.The
  benefits for gamedev in particular are immense: http://all-
  things-andy-gavin.com/2011/03/12/making-crash-ban...The reason
  this hasn't happened is because it takes a certain personality
  type to write languages. In 99% of cases, your language will
  fail. Meaning, if you spend 3 years on it, that's 3 years you
  didn't spend learning React or Vue or %salary-du-jour. You have
  to love it.That love is quite the feeling. When you design your
  own language from the ground up, and break down all barriers of
  complexity, it stops mattering whether anyone else ever uses your
  language. Making it was reward enough.In concrete terms, I think
  self-hosted Lisps are a promising way forward. It's simple to
  bootstrap a Lisp in almost any language: JS, Lua, Python, Ruby.
  Write a reader (you can use JSON to start), then write a compiler
  that steps through the tree of expressions and spits out the
  native language constructs. E.g.  (%while true     (print "she
  sells C shells by the C store"))  becomes C#:  while (true) {
  Console.WriteLine("she sells C shells by the C store");   }  or
  Python:  while True:     print("she sells C shells by the C
  store")  etc.Then you can save the output code to disk and run
  it.At this point you've written your compiler in Python, Ruby, or
  whatever. Now the trick:Create a file "compiler.l" that sits
  alongside your "compiler.py" file. For each function in
  compiler.py, translate it into your Lisp language and save it
  into compiler.l.E.g. if your compiler.py file has:  def
  compile(x):     if atom(x): return compile_atom(x)     if
  special(x): return compile_special(x)     return compile_call(x)
  then in your compiler.l file, you should write:  (define compile
  (x)     (if (atom x) (return (compile_atom x)))     (if (special
  x) (return (compile_special x)))     (return (compile_call x)))
  And hey presto -- your compiler.py file is now capable of reading
  in compiler.l and generating the exact same code. Meaning you no
  longer have to program in Python! (Or whatever language you're
  targeting.) At that point your language is fully self-hosted, and
  you can extend it however you like.It's so incredibly easy to set
  up a self-hosted Lisp that it almost seems like a toy. But it's
  incredibly powerful. E.g. I'm currently building one on top of
  Racket so that I can write traditional unhygenic macros,
  completely sidestepping Racket's syntax transformer system.You
  could imagine doing something similar for React, letting you
  write programs to generate React components -- a step toward the
  ultimate templating system.Once you've done this, you'll notice
  that the entire language is extremely small. It's a thin wrapper
  around the host language. But that's the value -- that's why it's
  useful. E.g. in many Lisps, it's common to use the symbol 't for
  True and an empty list for False. In those systems, there is no
  such thing as a "boolean" type. Everything is either an empty
  list or not-an-empty-list. You could do that, which demonstrates
  just how powerful this technique is. Just modify the way you
  compile IF statements:  (define compile_if (cond a b)     (+ "if
  (" (compile cond) ") { "            (compile a)        " } else {
  "            (compile b)        " }\n"))  to  (define compile_if
  (cond a b)     (+ "if (yes(" (compile cond) ")) { "
  (compile a)        " } else { "            (compile b)        "
  }\n"))  (i.e. wrap COND in a call to a YES function.)Then you can
  define YES as:  (define yes (x)     (return (not (or (== x false)
  (empty_list x)))))   Now your compiler spits out "if (yes(x)) { a
  } else { b }" everywhere, and your YES function is your
  definition of truthiness.So, you can do that, and it works, but
  at that point you'll discover that you start wrestling with the
  underlying language. If you change how IF behaves, then you'll
  need to change how AND and OR behave, too. Stuff like that.I've
  found the best strategy is to make your Lisp as close to the
  target language's semantics as possible. When you do that, you
  end up with a tiny runtime. Clojure's runtime is gargantuan
  because it has to define in Java all of Clojure's semantics. But
  here, you're using the host language's semantics directly.Now it
  might seem that this "isn't really a Lisp". But it turns out that
  it's just as powerful as any other Lisp. All you have to do is
  change your compiler from:  (define compile-file (src)
  (compile (read-file src)))  to  (define compile-file (src)
  (compile (expand (read-file src))))  Then define an EXPAND
  function that performs macroexpansion on the expressions you got
  from the reader.At that point it's straightforward to introduce:
  (define-macro when (cond . body)     (return `(if ,cond (do
  ,@body))))  which compiles to:  def when_macro (cond, *body):
  return ["if", cond, ["do"] + body]
  environment["when"]["macro"] = when_macro  Your EXPAND function
  becomes dead simple:  def expand(form):     if atom(form): return
  form     mac = environment[form[0]]["macro"]     if mac: return
  apply(mac, form)     return map(expand, form)  Finish it off by
  defining DEFINE-MACRO:  def define_macro_macro(name, args,
  *body):     f = eval(compile(["fn", args] + body))
  environment[name]["macro"] = f    environment["define-
  macro"]["macro"] = define_macro_macro  Presto, now you can write
  (define-macro add1 (x) (return (list "+" x 1)))    (print (add1
  41))  and it compiles to print(41+1).Scott Bell and Daniel Gackle
  pioneered the above technique, and I've spent the last couple of
  years implementing it across different languages, including
  Python, elisp, ruby, and racket.You can try it out
  here:https://github.com/sctb/lumenThat's Lumen, a Lisp for JS and
  Lua. One of the coolest aspects is that it compiles to both JS
  and Lua simultaneously, and runs in both.If you want one for
  Python, you can try out my
  branch:https://github.com/shawwn/lumen/tree/features/pythonIt
  compiles to JS, Lua, and Python simultaneously. So the same
  codebase runs on node, lua, luajit, torch, python2.7, python3,
  and pypy.LuaJIT has a fantastic FFI library -- and since our lisp
  runs in Lua, that means we automatically get a fantastic FFI:
  https://github.com/sctb/motor/blob/master/pq.lImagine how much
  work it would be to write your own FFI! I think it's one of the
  best FFI's of any Lisp implementation.So that's a rough outline
  of Lisp's unique power. It's so versatile that it feels like just
  a matter of time until someone decides to embed it in some
  popular system, like a game engine or an online store builder.
  Clojure might get some serious competition within the next
  decade.
 
  [deleted]