Hacker News new | comments | show | ask | jobs | submit login

What is so unreadable about '#(+ %1 (* 2 %2))'? Can Scala use arguments in an order other than the order in which they're given? If not, then Scala's simplicity is at the cost of less flexibility.

If you find that too hairy, just write '(fn [a b] (+ a (* 2 b)))'. The shortcut syntax is intended for simple cases.

This kind of attitude is what frustrates me.

The clojure version is obviously more noisy. Your argument is that the #() syntax is more robust (i.e., allowing multiple references to a single argument, and repeats of an argument). While strictly true, you then go on to invalidate it by saying, "The shortcut syntax is intended for simple cases." I feel like this is a resistance to change that is more a product of the rivalry between Scala and Clojure than anything else (and please forgive me if I am projecting onto you, but that's how arguing on the internet goes).

Additional complexity or capability at the cost of a perlesque show should not be the mission of a convenience syntax. Scala has taken a lot of good ideas from Clojure, it seems only fair that Clojure pull back a little. What's more, it's not very hard to write a macro that does most of what the wildcard syntax does... but without access to the reader's symbol macros it's very difficult to make that kind of change grow into the community.

I don't see any resistance to change; it's more like Clojure folks are generally going to demand that changes be unequivocally positive. I remember the fixed-position args in Scala function literals being particularly irritating in certain circumstances; whatever one's gripe about the chosen sigils, being able to write #(%2 %) is damn handy.

This widespread Scala/Clojure rift is a myth AFAICT, outside of various spitball fights on Twitter.

Oh, and if you want to have userland reader macros in Clojure, have at it: http://briancarper.net/blog/449/clojure-reader-macros ;-)

I've been learning Scala and after being initially excited by Scala's _ notation, I'm disappointed by how often I end up resorting to the long form for expressions that feel simple.

Also, I think Clojure's syntax for the 1st argument, 2nd argument, etc. is more intuitive. I mean, the second _ doesn't refer to the same argument as the first _? That violates all my instincts as a programmer. I was completely baffled by it until it was explained to me, and it still seems very clunky, because it forces me to declare names for arguments more often than I would like to. In my opinion, the Clojure way is immediately obvious and more concise (because it can be used in many cases where Scala requires named arguments.) It's just better all around, for any expression more complicated than { _ + _ }.

I am not an accredited Clojure style expert, but I wouldn't (defensibly) use the shortcut syntax in an any more complicated way than calling a function, providing missing arguments and rearranging those that have been passed. So, something like this:

    (frob #(mumble :foo %2 %1) bar)
Anything more complicated, I'd either use `fn' or define a free-standing function.

I'm not disputing that the Clojure community has assholes, though I've hung out on #clojure a fair amount and no one springs to mind. But the `fn' shortcut sugar seems like a completely reasonable design. The design choice, however, does encourage the adoption of certain conventions.

your frustrated by people who have different priorities than you do? Who values you things differently?

when you start using words like 'obviously', it really doesn't speak well of the comments to follow. noisy? beautiful? elegant? these are all aesthetic judgements. for you to say something is obviously more noisy is to place your judgement about others and to discount the validity of their view- that kind of attitude frustrates me.

> someNumbers.reduceLeft( _ + _ )

> (reduce #(+ %1 %2) someNumbers)

In math, you can write:

  f(x,y)= x+2y
  A= {1,2,3}
  reduce(f, A)
A more readable syntax for people who did math at school could be:

  reduce(x+2y, SomeNumbers)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact