1. 12
  1.  

  2. 11

    I’ve used Clojure professionally for about 8 years now, and have trained many people to work with it during that time. I can firmly say that s-expressions are a fine, and have many tangible advantages over other forms of syntax.

    One huge advantage of s-expression syntax is that it allows for powerful structural editors as seen here. Instead of having to work with lines of text, the editor works with the code semantically allowing you to manipulate expressions directly. Once you work this way for a bit, and it really doesn’t take long, you start thinking about code differently. You start seeing each s-expression as a lego block, and you just stick them together to build things.

    I also find that s-expressions make the code more scannable. You basically have a diagram of the relationships in your code that you can analyze at a glance. In addition, the syntax is very regular and follows a few simple rules, further adding to readability.

    Another big advantage of course is macros. When you’re using data structures to write code then you can use the language itself to manipulate the code. This is something that’s very cumbersome to do in any language that has separate syntax for logic and data.

    I think the reason why people find s-expressions difficult to read is primarily due to the fact that they don’t share roots with any mainstream languages. If you’re an English speaker, then you’ll find French, German, or Spanish syntaxes familiar. Sure, you’ll have to learn a few rules, and some new words, but a lot of ideas are directly transferrable between them. However, if you try to learn Korean most of your existing knowledge won’t be easily transferrable. That should not be confused with Korean being inherently more difficult to learn or use however.

    That said, I do think there are differences between of s-expression syntaxes that appeal to different people. Personally, I find that Clojure syntax has a number of features that greatly add readability. For example, having literal notation for data structures helps break things up visually:

    (defn foo [a b]     
      {:result (+ a b)})  
    

    When I see a list I know the first element is what’s going to be called and the rest of the items are the parameters. When I see a vector I know it’s just a data literal for the argument, and I can immediately see that the function returns a map as its result.

    Clojure also provides destructuring, where we can easily write out the parameters to a function:

    (let [[smaller bigger] (split-with #(< % 5) (range 10))]
      (println smaller bigger))
    
    
    (defn print-user [[name address phone]]
      (println name "-" address phone))
    
    (print-user ["John" "397 King street, Toronto" "416-936-3218"])
    
    (defn foo [{:keys [bar baz]}]
      (println bar baz))
    
    (foo {:bar "some value" :baz "another value"})
    

    The threading macro is also extremely helpful in flattening out nested expressions:

     (reduce + (interpose 5 (map inc (range 10))))
    
     when we use the threading macro it looks a lot more natural:
    
     (->> (range 10) (map inc) (interpose 5) (reduce +))
    

    I think little things like that really add up in terms of improving readability.

    1. 2

      It sounds like this page misuses the “straw man” -term.

      To “attack a straw man” is to refute an argument that was not made by anyone.

      There are people who have used these arguments, and they’re only strawmen in the sense that they have been disassociated from the people who made the arguments.

      1. 5

        To “attack a straw man” is to refute an argument that was not made by anyone.

        While this might be a definition, it’s most certainly not the only one peope think of when talking about “straw man” or “straw person” arguments. Another usage I have hear people use, and what I understand this page to imply, is to simplify or stupidify an opponents position, and then attack this easily attackable argument, thereby avoiding the actual issue. I belive that this is being done here, they take points raised against Lisp and lisp like languages, and show that these either miss the point or don’t really make sense anyways.

        But regardlessly, if it’s a “misuse” of the term or not, I belive everyone on this site is bright enoug to understand what is intended, regardless of this or that proposed formal definition, as well as being able to enjoy an article in it’s own merit, instead of an abstract notion of total semantical correctness in regards to each term, especially when it’s not crucial to the intend of the piece.