alecui, 10 months ago

Number three: #lisp. This is spicy enough, so:

1. Lisp syntax is painful (and the classical Lots of Irritating Small Parentheses stab). For those who don’t know (and why I put this at #0), what other languages might write as 5*a+3 is (+ (* 5 a) 3). However, in spite of the fact that it may look initially a little funny to the unaccustomed, there are some sound technical reasons why Lisp syntax exists:
   • Easy to teach: grouping of operators and associativity is obvious. 5 * a + 3 is (+ (* 5 a) 3), while 5 * (a + 3) is (* 5 (+ a 3));
   • Easy to parse: you don’t have to bend the language to understand your new function, everything works the same;
   • Maps nicely to an underlying data structure: Lisp is a living and breathing AST. Having this syntax makes macros possible. When you teach someone about macros, it’s obvious what the internal representation of a Lisp expression is because it looks just like Lisp program data. You can thus fit Lisp to anything you want. Lisp programmers focus on the content, Lisp haters focus on the parentheses.
2. Lisp is old. No? There are modern dialects of Lisp such as #Clojure, #Racket and the myriad of R{5,6,7}RS #scheme implementations. We’re still going strong, thank you. If anything else, #AutoCAD is still a thing and that has AutoLISP, so it definitely lives on.
3. Lisp is slow. I have actually heard this from a teacher live (along with the Lots of Irritating Small Parentheses stab). I asked them when was the last time they’ve tried Lisp. He tried it 30 years ago. Before doing his PhD in #Haskell 98 (which was fresh in #Romania, nobody has heard of it, I still have great respect for him). When all datatypes are appropriately declared, a typical commercial (and even some non-commercial) Lisp compilers produce native machine code on par with C++. It was true back when Lisp ran on the IBM 704 because they could barely handle the GC, but over times the compilers improved a lot. To equate 1960s (or even 1980s) Lisps to modern Lisp compilers is like claiming C is slow because the only time you’ve tried it is with a C compiler on the PDP-11.
4. Lisp is big. First of all, I find this really funny because Scheme (a branch of the Lisp family) is minimalist yet powerful in its nature. This myth started around the 1980s when Lisp was indeed big (because it packed a lot of useful functionality and there was a limit to how small that functionality could be made). Lisp vendors noticed that and nowadays Lisp is one of the few programming languages in recent years that has not been allowed to grow in size by leaps and bounds with every release. At this point, this point is (excuse my Chinese) fucking bullshit, people are happily running Electron-apps and they don’t care at all about resource usages because they’re all running the latest and greatest hardware anyway. Languages are getting more and more bloated (ahemc++ahem) and so Lisp actually ends up looking like a compact alternative.
5. Lisp has no arrays. This is also BS, we’ve had an array datatype for at least 30 years. Even though the Lis of Lisp is from, shocking, List, it doesn’t mean that it’s the only data type. Lisp offers powerful support for single and multi-dimensional arrays, arrays of varying element type, and array access that provides transparent access to fixed size arrays, arrays displaced to other arrays, and arrays whose size is expected to dynamically grow and shrink.
6. Lisp has no compiler. It… does? Since its earliest days Lisp implementations have been variously interpreted or compiled, and often both. Much important work in the theory of program compilation has been done using Lisp and so Lisp benefited from that. All modern Lisps have a compiler (and also a REPL which allows for interactive debugging, thank us for that and much more at the end of this post).
7. Lisp is not standard. Let me present ANSI X3.226/1994 (first ANSI standard for any OO language btw) and RnRS (5 <= n <= 7 nowadays). The Common Lisp HyperSpec (CLHS) is a webbed adaptation of the ANSI Common Lisp standard made by LispWorks, heavily cross-indexed with a lot of indices.
8. Lisp doesn’t talk to other programs… Um, most serious Lisp dialects and implementations definitely have FFI, most even have easy access to TCP, CORBA, COM, databases etc. This is a really weird point that I’ve actually heard, people think Lisp is isolated from everything.
9. Lisp GC is slow. It may have been true in the past when computers could barely handle GC, but a lot of progress has been made since then and it’s now on par with other popular GC languages.

Lisp haters should give Lisp more credit. It pioneered a lot of features that people take for granted such as REPLs (which are trivial in Lisp, literally (loop (print (eval (read)))) (in Lisp-ish pseudocode), GC with mark-and-sweep, AST as a tree structure, if (yes, not even FORTRAN had conditionals), a function type, recursion, programs composed of expressions, a symbol type, a notation for code using trees of symbols and constants, and the concept of having the whole language there all the time. What I mean by the last point is that there’s no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime). This lets you reprogram Lisp’s syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp’s use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea reinvented as XML.

Lisp is pretty nifty after all, huh?