4 ms·

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 g

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);

jstimpfle 4y ago
Yep. There is no reuse of common patterns. Everybody is required to reinvent their own idosyncrasies.
- reikonomusha 4y ago
  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.
  - jstimpfle 4y ago
    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); }
    - lispm 4y ago
      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...
    - reikonomusha 4y ago
      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.
      - klipt 4y ago
        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.
        4y ago
  - codemac 4y ago
    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?

jstimpfle 4y ago

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

reikonomusha 4y ago
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.
- jstimpfle 4y ago
  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); }
  - lispm 4y ago
    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...
  - reikonomusha 4y ago
    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.
    - klipt 4y ago
      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.
      - 4y ago
- codemac 4y ago
  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?