>Lisp at core is based on functional programing on lists.

Lisp is not, nor has it ever been, a functional programming language. It had lambda decades before other languages figured out it was a good idea, but it had set! for just as long.

It is also not a list based language, but a tree based one. The fundamental point of lisps is that you can manipulate the abstract syntax tree directly since it's pretty much the same thing as the parse tree.

>Deep Nesting is Rare

>The lisp's cons [...] works just fine when data structure used is simple. [...] vast majority of list usage is just simple flat list, sometimes 2 level of nesting [...] 3 levels of nesting is seldom used [...] Greater than 3 level is rarely seen. Systematic manipulation and exploitation of nested list, such as mapping to leafs, to particular level, transposition by permutation on level, or list structure pattern matching in today's functional langs, etc is hardly ever to be seen.

I guess the author has never used lisp to implement a DSL in lisp. Writing a lisp interpreted in lisp is the first real program you write if you take a lisp course at university and you need to handle arbitrarily nested expressions.

Real world usage also involves writing a specialist language to solve your problem for anything more complex than a utility script, e.g. Emacs is a text editing DSL implemented in elisp.

This author [1] has a fundamental misunderstanding of cons cells and what their purpose is. Cons cells are a primitive. They are best understood in contrast to the C model where memory is an array, i.e. an associative map from integers (or at least some abstract data type with a total ordering) onto values which are also integers (or at least sets of objects that can be mapped into finite sets of integers).

The key difference between the C primitive and the Lisp primitive is that the Lisp primitive does not require anything to be mapped onto integers whereas C does. You have to be able to increment and decrement pointers in C. You can have a fully functional Lisp with no numbers at all. In fact, this was the whole point of Lisp when it was invented: providing a model for computing on symbolic expressions rather than numbers. There is a reason that the original Lisp paper was called, "Recursive functions of symbolic expressions and their computation by machine" rather than "Cons cells: a new computational primitive".

All of the "problems" with cons cells are not problems with cons cells at all, they are problems with punning cons cells, i.e. using cons cells to implement higher-level abstractions without properly hiding the fact that the underlying implementation is a cons cell. The exact same thing happens in C when you run off the end of an array or cast a pointer to (void *). These are not problems with pointers per se, they are problems with using pointers to implement higher level abstractions (like finite arrays) without properly hiding the underlying implementation.

Punning cons cells and abusing pointers have similar consequences: segfaults in the case of C, and (typically) "NIL is not a valid argument to..." errors in Lisp. Both of these are the result of bad abstraction discipline, not a problem with the primitives.

---

[1] The author is Xah Lee, who is pretty well known in the Lisp community. He is widely considered a troll, an opinion which I personally share. I've tried to make my assessment of this post as dispassionate as I can, but I thought I should disclose the fact that I have a pretty strong bias.

The cons is integral to Lisp, and is used to construct the list, which is a purely functional data structure. Other languages also have lists, e.g. Prolog and Haskell (as well as similar pure functional languages).

Saying that they're a fundamental problem in Lisp is like saying that objects are a fundamental problem in Smalltalk or that arrays are a fundamental problem in APL.

If Xah doesn't like cons cells, there are other languages he can use instead. Lisp (as well as Prolog, Haskell, ML, etc.) programmers won't be persuaded to abandon cons cells or lists as they find them extremely useful.

One Lisp that doesn't have this con (pun intended!) is Janet. I really like the language, but the documentation is lacking. Otherwise, it's a nice little language which compiles to small binaries we can share. It's image-based (!) which is refreshing given how Racket, Clojure, etc. don't support images (at least not that I'm aware of).

Cons, car, cdr are fine for putting things together and breaking them apart.

The problem is everything is boxed, and the indirection mechanism is conflated with the concatenation mechanism. What you really want is the ability to compose a value (concatenate 2 things together), but store it contiguously in memory. If cons did that then you could create true products of values, without any indirection.

Then you need a different method for creating indirection. A function for each of C's malloc and '*' respectively. That would give you the control needed to create trees with arbitrary branching factors.

Wait, what's the problem with Cons?

This seems to just complain that cons is hard to understand or something, without actually saying what makes it hard or unintuitive.

--------

Cons is fundamentally a linked list. The "pair" is a (value+pointer), and sometimes "value" can itself be a pointer. So when you have (pointer, pointer), you now can create trees.

As such, "Cons" is a powerful abstraction for trees, pairs, and linked lists. That's all it is. If you need "more" than this (ie: graphs), then perhaps its insufficient.

---------

"Cons" itself is a malloc(sizeof(pair)) operation. While car/cdr depend on whatever you're doing or however you've designed the program.

If I were to criticize "Cons", its that high performance modern programming needs to use arrays because the cost of pointers has grown. Latency of memory lookups is relatively slower on modern machines (or really, latency hasn't improved in like 20 years), so you need to consolidate more members together.

But in terms of a "simple" data-structure, "cons" cells and list-programming is a thing for a reason.

Why not Clojure? It's based on immutable maps and vectors, so I feel like cons should be used much less in idiomatic Clojure code

Pretty sure this is not 2024.

Oh look, it says so right near the top: 2008.

In TXR Lisp, I abstracted car/cdr to work with non-conses.

  $ txr
  This is the TXR Lisp interactive listener of TXR 300.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  TXR is written, directed and produced by, not to mention starring, Kaz.
  1> [mapcar chr-toupper "abc"]
  "ABC"

  2> (nullify "")
  nil

  3> (cdr "a")
  nil
  4> (car "abc")
  #\a
  5> (car "a")
  #\a
  6> (cdr "a")
  nil

  7> (car "ab")
  #\a
  8> (cadr "ab")
  #\b
  9> (cddr "ab")
  nil

  10> (defstruct kons ()
        bling blong
        (:method car (me) me.bling)
        (:method cdr (me) me.blong)
        (:method rplaca (me splat) (set me.bling splat))
        (:method rplacd (me plonk) (set me.blong plonk)))
  #<struct-type kons>
  11> (new kons bling 1 blong 2)
  #S(kons bling 1 blong 2)
  12> (car *11)
  1
  13> (cdr *11)
  2
  14> (rplaca *11 42)
  #S(kons bling 42 blong 2)

This is not the only way to make an object which serves as a sequence; you can instead (or in addition!) implement array-like indexing via the lambda and lambda-set methods to have it vector-like rather than list-like.

The empty function and nullify are almost inverses; anyway they are implemented in the same spot of a 16000+ line file. The difference is that empty errors out on objects that are not iterable, whereas nullify takes objects of all types:

  val nullify(val obj)
  {
    val self = lit("nullify");
    seq_info_t si = seq_info(obj);

    if (seq_iterable(si))
    {
      seq_iter_t iter;
      val elem;
      seq_iter_init_with_info(self, &iter, si);
      return if2(seq_peek(&iter, &elem), obj);
    }

    return si.obj;
  }

  val empty(val seq)
  {
    val self = lit("empty");
    val elem;
    seq_iter_t iter;
    seq_iter_init(self, &iter, seq);

    return tnil(!seq_peek(&iter, &elem));
  }