Hacker News Reader

Comment by codemac | Hacker News Reader

Realistically, people would probably make this some weird macro that is:

    (peopler-simplifier well people 2 are likely to like this better)

This is where generally macros & helper functions in lisp actually produce a new "syntax", rather than leverage a large language provided one.

This to me is actually the crisis for lisp. Any codebase requires you to learn all the various macros that do:

   peopler-simplifier == $1->$2[$3].$4($5, $6 $7 $8 $9);

View on HN

Yep. There is no reuse of common patterns. Everybody is required to reinvent their own idosyncrasies.

I program in Common Lisp professionally and this is baloney. People do use common patterns, offered by the language and open-source libraries.

What is being discussed in this sub-thread is an oft-cited criticism of Lisp's "power" being too much for its own good, but rarely (if ever) a reflection of idiomatic practice.

Ok, you can use libraries, of course - so shouldn't say that there is no reuse. But libraries are not the same as built-in syntax. Built-in syntax for the basic things, as in the Algol-family is a) standard so everybody uses it. b) optimized for the right mix of efficiency as well as redundancy (error detection, skimmability by humans). Talk about "oatmeal with fingerclippings mixed in" - more parens don't add useful redundancy, but keywords and delimiter tokens do.

Too much power for its own good is one thing, but being just not optimized for the common thing is another. How would the following function, randomly picked from what I have open on github right now, look in "Common" Lisp? And if I ask 3 persons to do it, what is the likelyhood that they would pick more-or-less the same approach?

  Edit_Array buffer_batch_array_from_linked_list(Arena *arena, Batch_Edit *batch, i32 count){
      Edit_Array result = {};
      result.count = count;
      result.vals = push_array(arena, Edit, count);
      i32 counter = 0;
      for (Batch_Edit *node = batch;
           counter < count && node != 0;
           node = node->next){
          result.vals[counter] = node->edit;
          counter += 1;
      }
      return(result);
  }

As the sibling commenter said, that code admits a relatively standard translation. Without understanding the nuance of your code, and assuming you've made your own data structures and didn't use Lisp's standard ones (e.g., Lisp's native lists for the `batch` object), the translation would be this:

    (defun buffer-batch-array-from-linked-list (arena batch count)
      (let ((result (make-edit-array
                     :count count
                     :vals (push-array arena edit count))))
        (loop :for counter :below count
              :for node := batch :then (next node)
              :for vals := (vals result)
              :until (null node)
                :do (setf (aref vals counter)
                          (edit node)))
         result))

This is very typical Lisp code.

Could you adorn this code with type declarations? Yes, and you'd get speed and/or safety benefits by doing so. Depends how much this function "matters" in the larger context.

One difference that stands out here is that in the original code, the methods "node->next" and "node->edit" both belong to a "node" namespace, so you could have other objects with the same method name, e.g. perhaps "document->edit(patch)", and there would be no collision since they're in different namespaces.

But in your lisp version "next" and "edit" appear to be global methods. That seems like it could lead to a lot of naming collisions. Could you still have a document type that you can call "(edit document patch)" on? A preliminary Google search suggests that CLOS methods can't have definitions with a different number of parameters, so now you're stuck with a global "edit" method that can only ever take one parameter.

Common Lisp has generic functions, as you saw. Readers, writers, and/or accessors to classes are generic. So no issue with naming collisions.

    (defclass a ()
      ((value :reader value)
       (next  :reader next)))

    (defclass b ()
      ((value :reader value)
       (next  :reader next)))

This is totally valid; I can call VALUE and NEXT on instances of both A and B just fine.

But, if generic functions aren't your thing, you can skip calling the functions even and just do

    (slot-value x 'next)

if you really want. This is basically

    x->next

Again, works for any object with a field named by the symbol "next". But it's idiomatic to just call the reader function you defined, since getters can be instrumented, debugged, traced, etc. Some people prefer to call the reader A-NEXT or B-NEXT, but it's not necessary.

Regardless of all of that, symbols themselves belong to a namespace, called the "package". So your "edit" and my "edit" methods can have a different number of arguments without issue. (If they do have different arguments, they must mean different things.)

In Lisp this is solved with some combination of better names and symbol packages.

E.g. you might have some doc-model:edit symbol and file-utils:edit or whatever. The symbols have the same name, but are different objects in different packages.

The generic function doc-model:edit is therefore unrelated to file:edit.

Packaging at the symbol level means that the package system is relevant to anything whatsoever that is named by a symbol. If you have some logic programming system where you declare some named rules or facts, they can easily go into a package. Symbols which are quoted individually or in a larger literal are in the package system all the same; it's an independent layer.

Firstly, that needs a rewrite in some non-sucky curly brace with pointers:

  Edit_Array buffer_batch_array_from_linked_list(Arena *arena, Batch_Edit *batch, i32 count)
  {
      Edit_Array result(arena, count);  // Edit_Array has this thingy called a constructor
 
      foreach (node in batch)      // Batch_Edit * is somewhere/somehow declared iterable
      {
         if (result.full())        // Edit_Array has internal fill index, checked against count
           break;
         result.add(batch->edit);  // Edit_Array has method to add and increment fill index.
      }

      return result;  // not a function, drop the parens
  }

The Edit_Array class in the original is of no help whatsoever. Like this coder or language aren't even up to abstract data types with Modula-2.

CL has built in syntax for function definitions, local variable definitions, type declarations, function calls, loops, assignments, increments, value returning and a lot more.

It just uses names operators in prefix position. foo += 1 then is (incf foo). for (...) { ... } is then (loop for ... do ...). ...i32 counter = 0;... is then (let ((counter 0)) (declare (type i32 counter)) ...)

and so on...

To me this code just looks like a lot of boilerplate to just say:

    (replace (make-array count) batch)

I've been thinking about this thread a lot, because I did not agree with you at all based on my experience with CL.

After a while I realized it - I may have programmed in Common Lisp but never professionally... on a professional code base. Only ever on open source thingies, and small side projects. Paid or unpaid.

I've never seen industrial common lisp code. My last job had some but I never got to work on that project, and no longer can see it :(

Is there an example somewhere of this? C++ examples would be things like Chrome, C would be lots of open source OS's and kernel drivers. Is there something equivalent for CL?

Reply on news.ycombinator.com