11–20 of 174 posts
Better question: why not Lisp?
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.
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…
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…
Better question: why not Lisp?
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.
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"]}
2> (typeof '#J{"foo":[1,2,3,"bar"]})
cons
3> (car '#J{"foo":[1,2,3,"bar"]})
json
4> (cadr '#J{"foo":[1,2,3,"bar"]})
quote
5> (caddr '#J{"foo":[1,2,3,"bar"]})
#H(() ("foo" #(1.0 2.0 3.0 "bar")))
6> (vec-list '#J{"foo":[1,2,3,"bar"]})
#(json quote #H(() ("foo" #(1.0 2.0 3.0 "bar"))))
7> #J{"foo":[1,2,3,"bar"]}
#H(() ("foo" #(1.0 2.0 3.0 "bar")))
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]
3> (match ^#J[~x, ~y] #(1.0 "foo") (list x y))
(1.0 "foo")
4> (match ^#J[~x, ~y] #J[1.0, "foo"] (list x y))
(1.0 "foo")Better question: why not Lisp?
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…
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.
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…
Now maybe there are better notations though. I'm all ears.
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…
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.
The advantage [of the prefix notation for algebraic expressions in LISP] is like that of binary computers over decimal - but larger.
Better question: why not Lisp?
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…
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.
Better question: why not Lisp?
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…
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/...