Introducing Clochure: a better Clojure | Hacker News Reader

Introducing Clochure: a better Clojure

clochure.org

138 pointsold_sound71 comments

> The [] keys are closer to the central row of your keyboard than the less comfortable ().

> You don't need to hold the shift key to type [] therefore you can code faster.

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 ?

Why don't you give up and map your keyboard to US for programming, like all the rest of us? :-)

(It is not so bad to hit both shift keys to get back åäö.)

Edit: mpyne -- good thought, but we international users have our national keyboards in the fingertips, it is imho generally easier to switch layouts.

Edit 2: dkersten -- my productivity-porn time wasting is used up by browsing Emacs packages. :-) I'll check it out if I get wrist problems.

Pfft, why don't you give up and map your keyboard to Colemak for programming (and everything else), like.. well.. the few people like me.. ;-)

Did you completely lose your ability to use non-colemak layouts after switching, as I recently have?

I can use it, but I can't touchtype it, so I do feel a little stupid sometimes typing on qwerty and probably couldn't do it without at least glancing at my hands. Its worth it for me though because I spend so much more typing on my own colemak keyboard than I type on qwerty.

The standard recommendation is to type Sholes 5-10 minutes a day to maintain your ability to hurt your wrists. I haven't bothered to do that and it's a good thing I leave my keycaps alone for the few times I run a VM that is stuck in US layout. I've lost the rolls and fingerings as I've gained them with Colemak.

It's really sad when I have to use someone else's computer, but then I remember that my emails were never longer than a tweet when I first started with Colemak.

US-intl (w/ dead key) is actually surprisingly useful for accented characters, from what I could tell on the infrequent occasion I have to try it out.

Yep, US-international works better for me than the french azerty layout for typing french: the latter has no dedicated key for characters like Ç or É.

I've always found () to be easier to type on a qwerty keyboard. I can reach straight up with my middle and ring fingers, without moving my hands.

For [], I have to move my hand to the right, away from home position.

Strange. I type [] with my right pinky finger. I find it a lot easier than () which requires the shift key.

April fools...?

> And if there are such blatant omissions on their front page, who knows what's lurking in the code ?

There probably are bugs but not because they're unaware of every keyboard layout. It's far easier to accommodate different languages, currencies, number formats, etc than it is to accommodate every keyboard layout.

English and US keyboard layouts (or its close relatives), for better or worse, dominate the programming world.

I don't think the conclusion you've drawn, that there must be issues with the code because your local keyboard layout hasn't been thought of, is logical. That's like saying that because the language keywords and standard library aren't in your native language, there must be dragons lurking in the code.

Having said all this, Clochure does appear to be a nice little April 1st joke and should be flagged with prejudice!

Even for US keyboards, the obviously better step is to replace "(" and ")" with "9" and "0" -- familiar key location but without the shift key. Plus you avoid using the pinky finger which is an ergonomic win.

Edit: note that there might be a small tradeoff in readability.

I know some lisp programmers who uses this[1] to code. The left foot pedal open a parenthesis, the right one close all parenthesis. I find that's quite clever, though, considering the use of theses two characters.

[1]: http://img2.generation-nt.com/xbox-360-pedalier_090320025800...

With a s-expr edit tool like Paredit, you never have to write closing delimiters.

Is the code still readable ?

The code comes out looking the same; Paredit helps manage the parentheses for you (especially the closing ones, which it inserts automatically).

Some might even call it "electric!"

I've said it before: j and k are the obvious replacements if you want to ruthlessly Huffman-code your Lisp-typing experience. I, mean how often do you really see j or k inside the text of an atom? Not very often.

> how often do you really see j or k inside the text of an atom?

Just enclose j and k in parentheses on those rare occasions. Problem solved.

I got really excited for a second, and then I realized it was April 1st.

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.)

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]

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]

[1]: http://en.wikipedia.org/wiki/M-expression [2]: http://reference.wolfram.com/mathematica/tutorial/GettingUse...

I'll cop to it: this had me going for a couple hundred milliseconds.

It took me about 5 seconds. One of the few April fool's day web-jokes that's both plausible + hilarious. :)

(Also, maybe I'm insane, but I think I do find the square brackets a bit easier to read...)

I was actually totally surprised I find it waaay easier to read. I'd never have guessed.

Something about vertical lines being easier to "separate out", while parentheses, being curved, blend in more with the letters. Who'd have thought?

Yeah ... I was caught too. "Why on Earth would .... ohhhh".

Yeah, good gracious, how many better Clojures do we need?

This is an example of Poe's law in action.

http://en.wikipedia.org/wiki/Poes_law

This actually makes a certain sense. Especially the whole "no need to use shift to type the single most common character in your code" thing.

k and REBOL do this, actually.

Now you've got me thinking. The brackets still require a pinky stretch. But suppose you start with a TrulyErgonomic keyboard: http://www.trulyergonomic.com/store/index.php?route=product/...

Map the end key to (, and the left arrow to ), and you're hitting both characters with your thumbs.

Then maybe map brackets to PageDown and the down arrow, and braces to PageUp and up arrow for an easy reach with the ring finger. Or those big delete/backspace keys in the middle could be useful.

No self-respecting vim user needs any of these keys.

Even with a standard keyboard you can use left and right ALT, which would be the same sort of thumb action.

Reclaim thousands of lost microseconds with Clofjure:

    fdef x 6j
    -> #'user/x
    fdef y 36j
    -> #'user/y
    f+ x yj
    -> 42

From the logo I was expecting Japanese brackets:

    「「MyObject alloc」init」

For the vacillating, have the best of both worlds:

    〔〔MyObject alloc〕init〕

I'd like to see a lisp that allows all the kinds of different brackets. ( 〖〗〘〙〚〛〈〉() [] <> and maybe more.) I think i can make the code easier to read. All we would need was a emacs script. When the cursor is on the closing bracket there could be a drop down menu. But aside from Haskell Language creators seem to be god dammed afraid of unicode in the language.

Racket allows for (), [] or {} in code and it seems that in practice [] is used to distinguish some syntactic forms that have nested parens from normal function calls such as the let and cond forms. So instead of

  (cond ((...) (...))
        ((...) (...)) 
        (else ...))

you get

  (cond [(...) (...)]
        [(...) (...)]
        [else ...])

which seems to me to be more readable. See here for an example http://docs.racket-lang.org/reference/if.html?q=cond#%28form...

First of April is such a pain.

Funny thing... is that the discussion is actually turning serious... so my new guilty pleasure is to read serious discussions about April fools' jokes

> Easier to read, compare: (+ (expt 2 30) 2) with [+ [expt 2 30] 2].

Really? So now... in place of "lots of irritating superfluous parentheses" you get "lots of irritating superfluous square brackets"?

meh

Note the date.

Beware fellows... This is the best discussion to tell who is a skimmer and who is a reader in HN :)

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.

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.

We have the technology and (computer) science (more the mathematics really) to build such systems, why don't we!?

/rant

P.S. This is actually what I am working on... When I'm not busy... which is never.

    > 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.

Aren't languages stuck on syntax because syntax is what's standard? It's the terms in which a language is defined and it's what we must agree upon before we can even start building our own abstractions or swappable gylphs for the parts we don't like.

Fortunately you can use technology to compile your personalized syntax to the standard syntax.

We already do that. In fact, entire communities are built around custom syntax layers.

I imagine someone would only map "()" to "[]" because "()" is either unfamiliar or harder to type.

The superior solution is to learn "()" so that it becomes familiar or map "[]" to "()" respectively.

In both solutions you have an end result that does not distance the source code in the editor from the source code you're pushing to your repository, and that's the kind of thing we seem to optimize for as developers.

Obviously I have no idea what you actually had in mind, this is just what came to mind when I read that bit.

It's a great start, but I think <> would have been more appropriate, you could call it clomuretext.

Of course, PG covered this in the Arc FAQ

Why not use some other delimiter than parentheses?

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.

http://www.paulgraham.com/arcfaq.html

Everybody check the calendar.

April 2 in Japan. (Yet another i18n problem to consider.)

They totally had me with this.

"So on the eve of April 1st we sat down in a brainstorm session with a team of PLT experts."

What a missed opportunity. Reverse polish notation doesn't need any parentheses and it works well for Forth. Why do all Lisps make the same mistake?

I most comfortable programming in Morse code and this doesn't have anything that might tempt me to switch.

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

> 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

so... maybe it will be a project that has legs, after the holiday has passed!

Had me going for a while. In all seriousness, you can type clojure with square brackets, no? IIRC in Racket they are transferable.

No, square brackets in Clojure are vector literals. They are equivalent in Racket, though.

April Fool's ruins the internet for a day.

I honestly think if they replaced the parenthesis with indentation they might actually be onto something

there actually is a concrete language where this (from clochure ex.)

  (+ (power 2 30) 2)

and this

  + power 2 30 2

both work and mean absolutely the same. so if parens are the problem ...

Or in forth, which uses reverse polish notation:

  30 2 power 2 +

(a constant gets pushed onto the stack. functions like "power" and "+" operate on the stack)

So this also works:

  2 30 2 power +

Although I don't really use it anymore, my calculator (an HP scientific calculator) also uses reverse polish notation, so you can keep intermediate values on the stack, and do complex calculations without using parentheses at all. This is also good for keeping people from asking to borrow your calculator in math class. :)

What is the syntax that you posted? It looks just like RPN in reverse. Ok, that was a stupid question. I just figured out that is just "polish notation." It must keep a stack of operations that don't have their operands yet.

Indeed, Gregory Chaitin uses a Lisp without parentheses. It just requires that every function must have a predetermined and fixed arity.

I really just need to turn the computer off on April 1 every year. Argh!

Check out clojure source in the git repository...

Well `[]` _is_ easier to type than `()`.

[] is harder for me to read than ()

This is a fine self-parody

OK you got me with this :)

April Fool's?

The next logical step is replacing all the square brackets with accolades (same time next year).

lmao

Reply on news.ycombinator.com