4 ms·

I'm honored you read my post and replied to it. > I'd also argue that code size is a more meaningful measure of readability than familiarity ... but since wha

by arohner 17y ago

I'm honored you read my post and replied to it. > I'd also argue that code size is a more meaningful measure of readability than familiarity ... but since whatever notation you put in a language will eventually become familiar to its users, you should factor out familiarity when making design decisions An exaggerated, uncharitable interpretation of what you said would be "users will figure out the notation, regardless of how hard it is, so make them jump through hoops so you can get a shorter notation". How do you distinguish between shorter notation that is a net win, and shorter notation that looks like perl? My goal in using the macro was to reduce noise. Without the macro, the equivalent clojure would look like (defn entropy [x] (- (Σ #(* (p %) (log (p %)) x)) To me, the original version is easier to read because it lacks the #, % characters. Given that every call to sum would likely use an anonymous function (and therefore use #, %), it seemed worthwhile. Maybe that's an argument against clojure, but the arc version is almost as noisy, IMO.

jrockway 17y ago
If you can write something as a function, that's always a better option than making it a macro. It's clear to any clojure programmer what your entropy function does, just like it's clear to any Perl programmer what all that "line noise" is. (Arguably, there isn't much line noise in Perl, only in regular expressions, which every other language has stolen Perl's implementation of. If you want real line noise regexps, try Emacs Lisp without "rx".)
- mquander 17y ago
  I totally agree. But his article was aimed at non-Clojure (probably non-Lisp) programmers.
arb 17y ago
Perhaps it's the function shorthand syntax that resembles Perl. This is closer to your macro's surface syntax: (Σ (fn [i] (* (p i) (log (p i)))) x) The tradeoff with your macro version is that when you want to leverage Σ as a first-class function (say, with comp or partial), you will end up with #() or (fn..) in the calling code. You can't escape it -- it's a natural way to write functional Lisp code. It's no less readable than the rest of Clojure's API. You can reasonably expect a Clojure user to understand functions as arguments.
pg 17y ago
I think we should distinguish between notations that allow users to write incomprehensibly terse code and those that force them to. Only the latter are a problem, unless you're taking the protect-users-from-themselves approach to language design. It's an interesting question whether there are any existing language constructs that force one to write unreadable code. I ended http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html by asking for examples, and I don't think I ever got any.
- sayrer 17y ago
  "Are there languages that force you to write code in a way that is crabbed and incomprehensible?" How about TECO?
- eru 17y ago
  > It's an interesting question whether there are any existing language constructs that force one to write unreadable code. Depends. Suppose we added GoTo, ComeFrom, and assignment to the Haskell specification, to be implemented by all conforming implementations. The language has become strictly more powerful. But compiler writers will have a much harder time proving certain properties about your program e.g. constancy of variables. The implementation and optimisation techniques that depend on those properties no longer work. Thus the purely functional parts of your programmes will become slower, and you will be forced to switch to imperative style if you want any performance. (To make the compiler writers job even more difficult, add some of Python's dynamic capabilities that make it so hard to compile. Plus an eval that works in the current environment on strings and can change arbitrary variables or cause other side-effects.) Of course the language itself does not force you to write unreadable code. But it may make it harder for the implementors to allow you to write readable code.

by arohner 17y ago

jrockway 17y ago

If you can write something as a function, that's always a better option than making it a macro. It's clear to any clojure programmer what your entropy function does, just like it's clear to any Perl programmer what all that "line noise" is. (Arguably, there isn't much line noise in Perl, only in regular expressions, which every other language has stolen Perl's implementation of. If you want real line noise regexps, try Emacs Lisp without "rx".)

mquander 17y ago
I totally agree. But his article was aimed at non-Clojure (probably non-Lisp) programmers.

arb 17y ago

Perhaps it's the function shorthand syntax that resembles Perl. This is closer to your macro's surface syntax: (Σ (fn [i] (* (p i) (log (p i)))) x) The tradeoff with your macro version is that when you want to leverage Σ as a first-class function (say, with comp or partial), you will end up with #() or (fn..) in the calling code. You can't escape it -- it's a natural way to write functional Lisp code. It's no less readable than the rest of Clojure's API. You can reasonably expect a Clojure user to understand functions as arguments.

pg 17y ago

I think we should distinguish between notations that allow users to write incomprehensibly terse code and those that force them to. Only the latter are a problem, unless you're taking the protect-users-from-themselves approach to language design. It's an interesting question whether there are any existing language constructs that force one to write unreadable code. I ended http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html by asking for examples, and I don't think I ever got any.

sayrer 17y ago
"Are there languages that force you to write code in a way that is crabbed and incomprehensible?" How about TECO?
eru 17y ago
> It's an interesting question whether there are any existing language constructs that force one to write unreadable code. Depends. Suppose we added GoTo, ComeFrom, and assignment to the Haskell specification, to be implemented by all conforming implementations. The language has become strictly more powerful. But compiler writers will have a much harder time proving certain properties about your program e.g. constancy of variables. The implementation and optimisation techniques that depend on those properties no longer work. Thus the purely functional parts of your programmes will become slower, and you will be forced to switch to imperative style if you want any performance. (To make the compiler writers job even more difficult, add some of Python's dynamic capabilities that make it so hard to compile. Plus an eval that works in the current environment on strings and can change arbitrary variables or cause other side-effects.) Of course the language itself does not force you to write unreadable code. But it may make it harder for the implementors to allow you to write readable code.