Live data from Hacker News

Why Lisp? (2015)

blog.rongarret.info

21–30 of 174 posts

Re: Why Lisp? (2015)

#21

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…

> 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.

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)

Re: Why Lisp? (2015)

#22

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.

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.

Re: Why Lisp? (2015)

#23

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…

Roman numerals were based on lines and slashes? I mean, for one, five, and ten, sure. Fifty? Maybe. Beyond that? Not so much.

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

Re: Why Lisp? (2015)

#24
post #3

Better question: why not Lisp?

Can I be extremely shallow? Because the language feels like it's from the 60s. Like writing Fortran or Ada or Algol in 2021. C is timeless, it doesn't count.

I love lisps, but Racket, for example, feels more modern than Common Lisp to me. And for shallow people like me, feel and ergonomics are very important when writing code.

Re: Why Lisp? (2015)

#25

Earlier quoted context omitted.

> 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.

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)

Shouldn't the structure of the expression tree correspond to the structure of the document macros? i.e. (begin document ...)

Re: Why Lisp? (2015)

#26
What's a good Lisp dialect to write small programs in? I have some Emacs Lisp experience but I wouldn't use it to automate small tasks. For that, I typically use Python.

Re: Why Lisp? (2015)

#27
post #26

What's a good Lisp dialect to write small programs in? I have some Emacs Lisp experience but I wouldn't use it to automate small tasks. For that, I typically use Python.

[deleted]

Re: Why Lisp? (2015)

#28
post #11

Earlier quoted context omitted.

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 ad…

> 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…

> Finding solid libraries is tricky since it's not very popular professionally.

If we're considering Clojure, then I would argue this point isn't true. Java interoperability in Clojure is really well supported and easy to accomplish, so leaning on the massive Java library ecosystem is possible. Also, anecdotally, a lot of Clojure libraries appear to be defunct, but just actually haven't been updated in so long because of the strong backward compatibility across Clojure versions.

Re: Why Lisp? (2015)

#29
post #28

Earlier quoted context omitted.

> 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…

> Finding solid libraries is tricky since it's not very popular professionally. If we're considering Clojure, then I would argue this point isn't true. Java interoperability in Clojure is really well supported and easy to accomplish, so leaning on the massive Java library ecosystem is possible. Also, anecdotally, a lot of Clojure libraries appear to be defunct, but just actually haven't been updated in so long becaus…

Well, if we're going to venture that far into excuse land Common Lisp has access to every C library in the world through CFFI.

Look, I love Lisp, but reality isn't going anywhere.

Re: Why Lisp? (2015)

#30
That article partially validates my idea on why some people think that Lisp is such a force multiplier. The idea would be that compilers are one of the most important tool productivity-wise, and that Lisp allows you write your compilers yourself.

That would also explain why not Lisp: First, libaries are the new important tool for productivity, and any language can have that. Second, a shared understanding is very important, either for building programs, or building the libraries. Writing your own compilers may reduce that shared understanding. You can see this in some ecosystems where there is a split between people using the language in different ways (OCaml with Async and Lwt, the few alternative standard libraries; Scala with Zio, Cats, the base language; C++ with C with classes, the standard library and probably a lot of other styles that I haven't met yet; JS with the "classic JS", the frontend framework people, the functional/immutable people; many language with the FRP). Shared understanding is important for building and maintaining software. You could also argue that it's important to make programmers more replacable.

Another interesting thing is that some ecosystems are getting their macros: JavaScript has Babel, Coffeescript, Typescript.

Post reply on HN