Clochure — A Better Clojure | Hacker News Reader

Clochure — A Better Clojure

clochure.org

25 pointslelf28 comments

WAT. Replace () with []. Seriously? This is the same sort of whinging that curly-bracket vs. significant whitespace folks go on about versus each other.

How about y'all just programmer-up, admit that your visual recognition skills are trainable, and just get used to the syntax? Work on this a little bit, you'll just stop noticing language transitions. Yeah, there'll be a bit of standard library and language recalibration, but those become minor speed bumps. And the win in versatility is awesome.

A Tale: back in grad school the folks in the AI lab were heavy-duty Lispers. One of them was also the department's Emacs maintainer and made significant contributions upstream IIRC. You could flash a paragraph-sized chunk of Lisp their way and they'd immediately tell you whether and where any mismatched parens were. Having the editor do paren matching was nice but largely optional for this crowd.

tl;dr: you get good at what you do, and doing is often easier than you think.

https://github.com/videlalvaro/clochure/#clochure---a-better...

It's not serious: this was an april fools' day joke from earlier this year.

(Did you not catch that this was not just clearly a joke from the wording, but that they explicitly bolded the "April 1st" to make it more obvious?)

Sigh. Obviously not. I'll just go step away from the computer and come back some time next... decade.

Did you note the April 1st date. This might be an elaborate prank

It's very clearly a joke.

[] being easier to type than () is a decent point, though. I wonder if it'd be worth remapping your keyboard to swap them if you write a lot of lisp.

I have (, [, and { on regular keys on my keyboard. Shifting the key yields the other pair: ), ], }. But since Emacs autocloses parens I rarely need to do this.

edit: and it's excellent, I recommend it to all

What keys did you swap if you don't mind me asking? I've been planning on doing this, but just haven't figured out the optimal location, especially for a laptop.

http://lib.store.yahoo.net/lib/thehumansolution/kinesis-adva...

- the | \ key next to ~ and left arrow is (

- { [ becomes [

- } ] becomes {

I completely agree... I think it's ridiculous that it hasn't been switched in an implementation

I have

    function LispOpts()
        inoremap [ (
        inoremap ] )
        inoremap ( [
        inoremap ) ]
    endfunction
    autocmd FileType scheme call LispOpts()
    autocmd FileType lisp call LispOpts()

in my vimrc, which gains me all the ease-of-typing I really want. I don't think it'd really be worth anything as drastic as actually creating a new keyboard layout.

Then again, I don't use lisp all that often, so YMMV on that point.

I drafted a long comment with examples of how you could, perhaps, seriously make s-expressions more readable by not using nested parens.. but decided to see if anyone else had given it a go, and found this: http://readable.sourceforge.net/

It includes both significant whitespace and a special in-fix notation so a factorial function could look like:

    define factorial(n)
      if {n <= 1}
        1
        {n * factorial{n - 1}}

While I suspect most Lispers are shaking their heads and muttering, I actually like this. Seems to preserve the benefits of homoiconicity while reading more like natural language.

I would try it if there were a Clojure-compatible flavor (the {} conflicts with hashmap syntax) with a Leiningen plugin to convert it to regular Clojure when building. Kind of a CoffeeScript to Clojure's JS.

Edit:

Wait a sec, how does it know to prepend an open paren to the second line (the if) but not to the third line (body of the if)? Each one is indented. Does it have special, hardcoded knowledge of the 'if' form?

This looks a little problematic to me because the preprocessing isn't following an obvious rule. It brings to mind the big downside of CoffeeScript — the cleverness required to allow such natural-looking code can also lead to unexpected results in edge cases.

Rule is straightforward – if there is stuff one indentation level deeper, prepend parens.

That doesn't explain the third line. Your rule would result in

    (if condition
      (1)
      (else-clause))

trying to call 1 as a function, which is an error.

No, there is nothing one indentation level deeper than 1, so it should have no parens according to the rule.

Ah, your wording was ambiguous. I thought you meant, in this situation:

    ...
      X
        Y
    ...

since Y is one indentation level deeper than X, prepend parens to Y. But you meant "since there exists Y such that Y is one indentation level deeper than X, prepend parens to X".

I think everyone comes up with some sort of alternative whitespace syntax when they first see a Lisp. I know I did. Unfortunately, you lose Lisp's most powerful property--homoiconicity.

This was an April Fools joke.

Previous Discussion: https://news.ycombinator.com/item?id=5473135

> Since 2008 one programming language has seen an unprecedented growth in popularity despite its weird syntax: Objective-C. Why? Because to create applications for the App Store you have to code in Objective-C. Over 800.000 apps in the App Store are a testimony of the popularity of this language.

I laughed so hard

I thought Clojure's biggest problem was barfing giant Java-flavored stacktraces on simple errors?

I greatly prefer {brochure};

The lisp's main problem isn't the correct kind of brackets. It's more complicated than that.

this is the best kind of april fools joke. i not only found myself believing it was real, but actually started to devil's advocate myself into thinking it was a good idea. weirder things have happened.

Well, it actually works ;)

This is a bad idea - that might actually be a good idea...

This is still awesome.

This is a repost, no?

Reply on news.ycombinator.com