Thread

1. whartung · 1790613563 · focus · HN ↗

   The parentheses are large glyphs that distract the eye, and do not stand out (to the untrained eye) as delimiters.

   Consider:

     (defun split-line (line)
       (remove-if #'(lambda (word) (string= word ""))
                  (split-sequence:split-sequence #\Space line)))
   

   Now imagine if we had some "lower weight" glyph besides the paren.

     .defun split-line .line,
       .remove-if #'.lambda .word, .string= word "",,
                  .split-sequence:split-sequence #\Space line,,,
   

   Obviously a contrived example replacing () with ., but you can see how "heavy" the parens and how they can dominate what the eye sees.

   With experience, the parens vanish. The parens being large and common take control of the conversation more than they should.

   1. Avshalom · 1790617248 · focus · HN ↗

      this actually gets at the real problem. Lisps are wordy as hell. like jesus

        (split-sequence:split-sequence #\Space line)
      

      now imagine if that was

        (split-string " " line)
      

      image if the whole function was

        (defun split (line)
          (remove [\(word) (= "" word)] [split-string " " line]))
      

      or even

        (defun split (line)
          (remove "" [split-string " " line]))
      
      

      *using [] in place of rainbow parens for clarity of sub arguments

      1. Jtsummers · 1790618038 · focus · HN ↗

           (split-sequence:split-sequence #\Space line)
         

         Why would you do that? You could just use `uiop:split-string` and import the function symbol into your current namespace so you can call it as `split-string`.

           (split-string "a b c")

         1. Avshalom · 1790619381 · focus · HN ↗

            I mean ask OP, I don't know what's what in the Scheme rXrs or Common Lisp standard libraries.

            Although my general stance remains, most lisp code bases I've seen are remarkably verbose which leads to a glazing over far more than the lack of distinct symbols or prefix notation

      2. fweimer · 1790621660 · focus · HN ↗

         I think with CLOS, you can go back to using single verbs for function names. However, this has a performance cost. Encoding the receiver type in the function names makes the call much easier to optimize.

         What remains is field access. Curiously, first-edition K&R C actually required similar type-encoding in field names because field names were global:

         <a href="https:&#x2F;&#x2F;usenet.trashworldnews.com&#x2F;?thread=288637" rel="nofollow">https:&#x2F;&#x2F;usenet.trashworldnews.com&#x2F;?thread=288637

         Same for ML, which is roughly of the same age, except that it took much longer for ML-derived languages to lift this restriction.

         On the other hand, every time I wrote down examples that I think should look really bad in prefix notation, like this one:

             p3.x := (p1.x + p2.x) / 2;
         

         It is actually not so terrible with a sufficiently streamlined prefix syntax:

             (setf x p3 (/ (+ (. x p1) (. x p2)) 2))
         

         But maybe there should be a mechanism that the reader transforms p1.x to (. x p1), in the same way that it transforms &#x27;s into (quote s). Then we get this:

             (setf x p3 (/ (+ p1.x p2.x 2)))
         

         Or if there is a concept of a place:

             (set p3.x (/ (+ p1.x p2.x 2)))
         

         But that probably needs static typing for an efficient implementation (or set needs to deconstruct its first argument during compilation).

Unofficial Hacker News client; not affiliated with Y Combinator.