> The [] keys are closer to the central row of your keyboard than the less comfortable ().<p>> You don't need to hold the shift key to type [] therefore you can code faster.<p>That's true only for a standard US-qwerty keyboard layout. My [] are located at altGr + (). These guys clearly haven't though i18n through. And if there are such blatant omissions on their front page, who knows what's lurking in the code ?
I got really excited for a second, and then I realized it was April 1st.<p>Clojure is a language I absolutely love, but have abandoned for practical reasons. (Debugging Clojure is an absolute nightmare, and the tooling doesn't quite agree with me. The JVM is the biggest hurdle in making Clojure useful for me: it causes slow startups times, a bloated environment, and makes it hard to deploy in our production environment.)<p>So my immediate though when I read "a better Clojure" was: somebody wrote an LLVM front-end for Clojure and turned it into a fast language compiled to native code.
The post is meant to be a joke, and isn't a bad one as such things go, but its fun to note that square brackets and Lisp go back quite a ways, and were a feature of M-expression syntax. [1]<p>It is also interesting to note the reasons why Mathematica's syntax, which shares some similarities to Lisp, uses square brackets instead of parenthesis, specifically to avoid ambiguity when using parenthesis to denote grouping terms. [2]<p>[1]: <a href="http://en.wikipedia.org/wiki/M-expression" rel="nofollow">http://en.wikipedia.org/wiki/M-expression</a>
[2]: <a href="http://reference.wolfram.com/mathematica/tutorial/GettingUsedToMathematica.html" rel="nofollow">http://reference.wolfram.com/mathematica/tutorial/GettingUse...</a>
From the logo I was expecting Japanese brackets:<p><pre><code> 「「MyObject alloc」init」
</code></pre>
For the vacillating, have the best of both worlds:<p><pre><code> 〔〔MyObject alloc〕init〕</code></pre>
> Easier to read, compare: (+ (expt 2 30) 2) with [+ [expt 2 30] 2].<p>Really? So now... in place of "lots of irritating superfluous parentheses" you get "lots of irritating superfluous square brackets"?<p>meh
I know it's a joke, but why are languages so damn stuck on syntax. Why can't it be a one line change for person A to have () and person B to have [] (and person C have <>, or {}), and then have tools which automatically translate between them.<p>The same goes for every other syntax problem out there. Python and choosing between tabs, spaces, and smart tabs. The C family and choosing between where the damn braces go. Different keyword symbols (to support different languages!). Different symbol naming styles. All at the whim of personal preference.<p>We have the technology and (computer) science (more the mathematics really) to build such systems, why don't we!?<p>/rant<p>P.S. This is actually what I am working on... When I'm not busy... which is never.
Of course, PG covered this in the Arc FAQ<p><i>Why not use some other delimiter than parentheses?</i><p><i>We tried various possibilities. Square and curly brackets lose because they are less directional than parens (left and right differ in fewer pixels); < and > lose because they don't wrap around enough to enclose expressions longer than tokens.</i><p><a href="http://www.paulgraham.com/arcfaq.html" rel="nofollow">http://www.paulgraham.com/arcfaq.html</a>
One thing to add is that [] is much closer to the right pinky finger, which immensely boost the typing speed comparing to ().
Now that's what I call a true re-thinking in code productivity.
If we go another step further we might consider using ;
;+ 1;- 3 2;;
I am liking it already.
Finally a language I can get behind. I was never able to get into closure, but couldn't put my finger on the reason why. If only more languages could redefine themselves to be more usable and admit they have been outdated for years.
After using TCL for several years and actually liking it, I have to admit the brackets look better. Plus lately I'm all about anti-rsi and shift parens is getting to be a major hassle.
This is one of the better pranks I've seen today, this bit especially made me chuckle<p>> It compiles faster, since the compiler don't need to differentiate Java parentheses from Clojure ones.
even knowing it's April fools, I wanted to believe this.
even with some of the crazy reasonings<p>so... maybe it will be a project that has legs, after the holiday has passed!
there actually is a concrete language where this (from clochure ex.)<p><pre><code> (+ (power 2 30) 2)
</code></pre>
and this<p><pre><code> + power 2 30 2
</code></pre>
both work and mean absolutely the same. so if parens are the problem ...