1. 48
  1. 5

    This seems portable to emacs-lisp judging from the ClojureScript that is powering the Atom plugin and the .cljc running the site. An existing alternative for Emacs is mastery of paredit and use of aggressive-indent-mode.

    I think this is nicer for newbies than getting the three-key chords required for good paredit use ingrained in muscle memory. I think it’s wonderful that the lisp indentation conventions benefit improve developer productivity, not just code readability.

    EDIT: Added link to the site’s source.

    1. 4

      And alternative syntaxes (Lisps without parens) have faltered since they sacrifice some of Lisp’s power that seasoned users aren’t willing to part with.

      The syntax sweet-expressions does not sacrifice any of Lisp’s power. I’m surprised at this inaccuracy, since the authors even mentioned sweet-expressions in the Acknowledgements section. Sweet-expressions have indeed faltered, but not because they lack homoiconicity or the other benefits of Lisp syntax.

      I think these are the reasons for sweet-expressions’ unpopularity compared to editor tools like Paredit:

      • It is harder to collaborate on a project that uses sweet-expressions in its build system. Newcomers must run whatever build system you set up, and spend a little time learning how to write sweet-expressions. Editor tools like Paredit, on the other hand, allow other developers to use the tool of their choice.
      • There are no editor plugins for sweet-expressions. So syntax highlighting of function names, which are usually identified by having a ( before them, may look broken.
      • There is no implementation for Clojure, because the design is ill-suited for Clojure’s syntax. For example, the design does not support treating (), [], and {} differently – it already defines custom semantics for {}. The design also favors wrapping of individual lines in (), which means that writing multi-line Clojure constructs that don’t wrap pairs in anything, such as {:key "value"} maps, requires escaping.
      • Some people confuse sweet-expressions with previous syntax suggestions that actually do sacrifice homoiconicity, such as Scheme i-expressions. They then dismiss sweet-expressions based on this misconception.
      1. 2

        The build problem at least in Common Lisp with the typical build setup (ASDF, possibly with Quicklisp) seems like it should be solvable. I’m not a Lisp reader or packaging guru, but if you write a package in sweet-expressions, shouldn’t it be possible to set up ASDF so it’s loadable as a regular Lisp package without the user needing to know the difference? It seems like the package should be able to handle that internally, loading the sweet-expressions readtables as a dependency. Of course, to modify the package’s source, other people would need to buy into sweet-expressions (learn how to read/write them, get their editors set up appropriately, etc.), but users who just want to build and use the package should be able to ignore it.

        To add one more hypothesis to the list, though: People who use Lisp are generally used to the syntax and don’t really want to change to a new one, while people who strongly dislike the Lisp syntax just don’t use Lisps and therefore aren’t in the market for a new Lisp syntax either. There’s a potential group of people who might use Lisp except that they dislike the syntax, but there’s not a lot pushing these people towards Lisp. Unlike say Javascript, where a lot of people feel they have to use it, and are therefore open to things like Coffeescript to make their lives easier, the number of people who have to write in Lisp today contrary to their wishes is pretty small. Possible exceptions are Emacs Lisp and, recently, Clojure.

      2. 3

        Really would like this for Emacs, also, such good documentation in both form and content.

        1. 2

          This looks game changing. Might be worth switching to Atom for, at least temporarily.

          1. 1

            Wowza. Eagerly awaiting the LightTable plugin!