[HN Gopher] Why Lisp? (2015)
___________________________________________________________________
Why Lisp? (2015)
Author : oumua_don17
Score : 36 points
Date : 2021-10-26 20:58 UTC (2 hours ago)
(HTM) web link (blog.rongarret.info)
(TXT) w3m dump (blog.rongarret.info)
| AnimalMuppet wrote:
| TL;DR: Because it uses a minimal representation for data (S
| expressions). This makes it much easier to write representations
| of data (compared to XML, or even JSON). This makes it easier to
| represent _code_ as data, and that opens up the whole world.
| chmaynard wrote:
| Yes, but read the post anyway.
| AnimalMuppet wrote:
| Agreed. It's worth reading. My TL;DR was not meant to imply
| that it wasn't.
| kazinator wrote:
| Plus, that can be in addition to having JSON too.
| This is the TXR Lisp interactive listener of TXR 271.
| Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for
| cheatsheet. 1> '#J{"foo":[1,2,3,"bar"]}
| #J{"foo":[1,2,3,"bar"]}
|
| What is that literal syntax? 2> (typeof
| '#J{"foo":[1,2,3,"bar"]}) cons
|
| cons-cell based object under the hood. 3> (car
| '#J{"foo":[1,2,3,"bar"]}) json 4> (cadr
| '#J{"foo":[1,2,3,"bar"]}) quote
|
| It has a (json quote ...) structure. 5> (caddr
| '#J{"foo":[1,2,3,"bar"]}) #H(() ("foo" #(1.0 2.0 3.0
| "bar")))
|
| Followed by a hash table object. We can convert that to a
| vector to see it all: 6> (vec-list
| '#J{"foo":[1,2,3,"bar"]}) #(json quote #H(() ("foo" #(1.0
| 2.0 3.0 "bar"))))
|
| Now actually eval it instead of quoting 7>
| #J{"foo":[1,2,3,"bar"]} #H(() ("foo" #(1.0 2.0 3.0
| "bar")))
|
| The embedded hash table denoted by the literal is regurgitated.
|
| We can quasiquote JSON: ;; ^ is quasiquote in
| this dialect not ` 1> ^(,(+ 2 2) ,(list 1 2 3)) (4
| (1 2 3)) ;; cannot use , in JSON for unquoting, so ~
| is used: 2> ^#J["foo", ~(+ 2 2.0)] #J["foo",4]
|
| The quasiquote can be pattern-matched: 3>
| (match ^#J[~x, ~y] #(1.0 "foo") (list x y)) (1.0 "foo")
|
| Or, using JSON syntax on the right side, which produces the
| same vector: 4> (match ^#J[~x, ~y] #J[1.0,
| "foo"] (list x y)) (1.0 "foo")
| throw10920 wrote:
| Exactly - it's not about whether it's _possible_ to represent
| code as data (gcc is written in C, after all), it 's about how
| _easy_ it is. That 's why Rust macros still don't come close to
| Lisp ones.
| firebaze wrote:
| Better question: why _not_ Lisp?
| codr7 wrote:
| Performance:
|
| Getting Lisp to run as fast as C takes major effort when at all
| possible.
|
| Resources:
|
| Lisp needs a lot of space to do it's thing; and while it's
| certainly possible to downsize it, you're left with something
| that's not really Lisp anymore.
|
| Ecosystem:
|
| Finding solid libraries is tricky since it's not very popular
| professionally.
|
| Power:
|
| Unleashing the full power of Lisp in a diverse team is a recipe
| for an adventure, if not disaster.
| agumonkey wrote:
| If performance was such a problem python wouldn't have a
| subreddit.
|
| I think a lot of lispers like handling various paradigms in
| their head and start with basic lisp, and resort to edsl to
| reach more appropriate semantics/mechanical sympathy. Just
| like people call out to C wrappers mostly.
|
| The social side of lisp I can't say for sure but I'm sure
| it's fuzzier than it seems. I've just talked to a dude saying
| his new guy was a clojurist and his thinking is way finer
| than the current team.
| Mikeb85 wrote:
| > Getting Lisp to run as fast as C takes major effort when at
| all possible.
|
| But Lisp is faster than almost every widely used language
| that's not C/C++/Rust, around Java speed.
|
| > Lisp needs a lot of space to do it's thing; and while it's
| certainly possible to downsize it, you're left with something
| that's not really Lisp anymore
|
| Dunno, by modern standards it seems pretty small.
|
| > Finding solid libraries is tricky since it's not very
| popular professionally.
|
| Ish. Because it's so mature, lots of code works even it it's
| not updated constantly. There's code out there for most use
| cases, at least for back-end-y things.
|
| > Unleashing the full power of Lisp in a diverse team is a
| recipe for an adventure, if not disaster
|
| So enforce coding standards. This isn't a negative and lots
| of us work alone or in small teams.
|
| Honestly, the only reason I don't mainly use Lisp is because
| I use an even slower/easier language because I don't really
| need a performant language. But if I find a problem where I
| want more performance Lisp is probably the next stop.
| throw10920 wrote:
| > Getting Lisp to run as fast as C takes major effort when at
| all possible.
|
| The Computer Language Benchmarks Game shows Lisp Code as
| generally being between 2x and 10x slower than C++[1]. As
| fast as C? No. Way faster than Python, and more than fast
| enough to be used in almost every single application, modulo
| hard-real-time systems and AAA video games? Yes.
|
| > Lisp needs a lot of space to do it's thing; and while it's
| certainly possible to downsize it, you're left with something
| that's not really Lisp anymore.
|
| Again, while a 13MB SBCL image might be significantly larger
| than a 100KB C program, given that that's the entire compiler
| and runtime bundled in, and the size of additional code
| scales also like C/C++, that still makes it viable for almost
| every kind of program (and still an order of magnitude
| smaller than Electron). Same deal with memory usage.
|
| > Finding solid libraries is tricky since it's not very
| popular professionally.
|
| This one is so true it's not even funny. (although there are
| C, C++, and Python FFI's that cover most of the stuff that
| you want, although that's kind of cheating)
|
| > Unleashing the full power of Lisp in a diverse team is a
| recipe for an adventure, if not disaster.
|
| The list of companies using Clojure[2], in addition to the
| commonly-cited Viaweb/Orbitz/Grammarly, beg to differ.
| Anecdotally, most Lisps have _less_ footguns than C++ - if
| people can figure out how to use Stroustrup 's monster in
| massive video games, Lisp is easy.
|
| [1] https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| [2] https://clojure.org/community/companies
| Scarbutt wrote:
| https://groups.google.com/g/comp.lang.lisp/c/L5dZ-j6Id-s/m/9...
| leishulang wrote:
| no popularity, no money.
| diskzero wrote:
| Please write that article! I keep trying condense my reasons
| but end up with a sprawling document.
| hasmanean wrote:
| Lisp probably was invented in the age of the typewriter.
|
| If you look at mathematical notation, written with quill pens and
| paper...it's even more concise. Functions are like lisp, f(x).
| Vectors are laid out on the page in an array and surrounded by
| two strokes. Matrices are a 2d array surrounded by two straight
| lines.
|
| This whole approach seems as archaic as Roman numerals is for
| representing numbers (they were based on lines and slashes like a
| tally system).
|
| Maybe there is an even better notation for representing code
| which will be as much a leap forward as the positional number
| system (which represents every number as a power series with base
| 10) was to numbers.
| TeMPOraL wrote:
| I disagree. I think a way to summarize this article is that the
| popular languages (Algol/C family) are like Roman numerals, and
| Lisp is like Arabic: _it composes better_. It 's a powerful,
| qualitative difference.
| kazinator wrote:
| John McCarthy, _History of Lisp_ :
|
| _The advantage [of the prefix notation for algebraic
| expressions in LISP] is like that of binary computers over
| decimal - but larger._
| AnimalMuppet wrote:
| Roman numerals were based on lines and slashes? I mean, for
| one, five, and ten, sure. Fifty? Maybe. Beyond that? Not so
| much.
| jazzyjackson wrote:
| I have a wonderful book in front of me called "From One to
| Zero: a universal history of numbers" by georges ifrah.
|
| chapter 9, _roman numerals: a vestige of primitive origins?_
| starts like this:
|
| -------------------- I V X L C D M
|
| They are obviously letters of the roman alphabet, but this
| does not mean they have an alphabetic origin. The signs L, C,
| D, and M are not the original forms of the numerals 50, 100,
| 500, and 1000; they are altered forms of much older numerals.
| known instances of the use of L, D, and M as numerals do not
| go back much farther the the first century AD [...]
|
| ------------------
|
| The chapter goes on to illustrate the resemblence with
| etruscan numerals and the tally marks of ancient shepards
| counting sheep, see the "tally marks" section of the
| wikipedia page, or borrow the book from archive.org, page 131
| to 146 or so.
|
| https://en.m.wikipedia.org/wiki/Etruscan_numerals#Tally%20Ma.
| ..
|
| https://archive.org/details/lish00geor
| agumonkey wrote:
| It's funny because I consider other languages like roman
| numerals, unhomogeneous bunch of constructs that don't work
| well with themselves, meanwhile lisp is an infinite tower.
|
| Now maybe there are better notations though. I'm all ears.
| kazinator wrote:
| > _If you look at mathematical notation, written with quill
| pens and paper...it's even more concise._
|
| Yes, but now mathematics publishing predominantly uses a
| typewriter-era language for achieving it:
| \documentclass{article} \usepackage{amsmath}
| \begin{document} \[ M= \begin{bmatrix}
| 1 & 2 & 3 & 4 & 5 \\ 3 & 4 & 5 & 6 & 7
| \end{bmatrix} \] \end{document}
|
| Most programming takes place with what is more or less
| typewriting.
| kazinator wrote:
| Now imagine having that as: (documentclass
| article) (usepackage amsmath) (begin
| document) ;; [...] read syntax for displayed math
| [(= M (bmat (1 2 3 4 5) ;; case-sensitive treatment: M
| (3 4 5 6 7))] (end document)
| codr7 wrote:
| Writing code that generates and compiles code in Lisp is just
| like writing any other kind of code.
|
| Writing a C program that generates and compiles C code is a major
| pita in comparison, same goes for most other languages.
|
| Even if you slap a different syntax on top, it's still a Sunday
| walk in the park to write a custom compiler.
|
| https://github.com/codr7/snabl
___________________________________________________________________
(page generated 2021-10-26 23:00 UTC)