On Thu, 08 Aug 2013, Sam Aaron wrote:
> Haha, I come back to this list after a good few months of not being able
> to keep up with the volume to find a rant about paredit - priceless!
>
> Seriously though, these things are all personal and as such clearly get
> people's backs up. So for what it's worth, let me throw my thoughts in...
I'm very much of the "can't we all just get along?" school, too.
One of my biggest resistance-points to paredit was that I hated the idea of
the editor producing syntactically correct structures even though the
partially written logic behind them was incomplete and broken. Unclosed
parentheses were a visible marker of unfinished thoughts, and having them
automatically closed was like chopping down signposts I was relying on.
The switch from this mindset wasn't easy, and didn't happen until I'd been
editing paredit-only for a good while. It still makes me nervous. One
result is that I actively try to write shorter functions (which is good
practice, anyway). I also more frequently put mental state that might be
lost into FIXME comments or logging statements, so there is a visual (and,
better, searchable) reminder of incompleteness if I switch contexts.
A second stumbling-block was paredit's occasional tendency just to get
something wrong and make it obnoxiously hard to fix. Being unable to
delete a bad parenthesis or switch the nesting level of a square bracket is
utterly rage-inducing. My early experiences with this were quite
aggravating. Who would want to use a mode that breaks the backspace key?
The realization that I could manually fix problems by killing/cutting the
bad bits (C-SPACE at one end, positioning the cursor at the other, then C-w
to kill the region) and, if necessary, yanking/pasting them to an
appropriate location (C-y) meant that I could jump outside of paredit's
straightjacket when the annoyance factor started rising, without losing
ground by disabling it completely. I'd long before rebound C-q to something
else so I never relied on the ability to C-q <delimiter> to force an
insertion, but that option is there, too.
> I wouldn't go so far as to say that not using paredit (or an equivalent)
> is "the wrong way" (although I probably would in the pub after a couple
> of pints). However, it *definitely* feels to me that using an editor that
> doesn't support paredit feels broken - and I always wind up writing
> broken code with missing parenthesis because my mind is used to not
> worrying about them. Also, moving forms around manually is pretty
> dreadful and syntax-error prone - paredit massively improves this.
I'd probably agree with you over those beers to the extent that trying to go
non-paredit is deeply suboptimal if you're live-coding!
There's a deeper issue that gets back to Lee's comment about thinking of
code as text. If that is the mental model one is using, paredit's approach
is almost offensive. That's the way I felt for quite a while, and I am
deeply sympathetic to this perspective.
When paredit finally started clicking with me, I realized that I was
thinking about programming as "editing and manipulating S-expressions"
rather than as "editing text". I now find that this jump to a higher level
of abstraction has reduced a certain level of friction between the code
in my brain and the code that needs to appear on the screen.
Tools are important, and the match between tools and mental models is
critical. One of the marvelous things about Emacs is how easily you
can adapt the tool to fit the shape of your mind (even though with paredit
you might have to meet it halfway).
What actually let me get paredit embedded into my work habits
was that I changed my approach to keybindings. Rather than blithely
learning and accepting the defaults, I began to optimize my entire
environment.
The best enabler for this was binding Hyper to the Caps Lock key.
This has been absolutely brilliant. Hyper is a green field. You don't
interfere with any existing bindings, and you can still rely on the normal
keystroke documentation for any packages you might have installed. So, for
example, I could never recall how barfage and slurpage were supposed to
work but using
H-M-n paredit-backward-slurp-sexp
H-M-m paredit-backward-barf-sexp
H-M-, paredit-forward-barf-sexp
H-M-. paredit-forward-slurp-sexp
feels completely natural. I also bind commonly used keys like delimiters to
the Hyper plane, such as H-l for '(', H-; for ')'.
> The analogy I think about is touch typing. People might also make a claim
> that programmers that don't touch type are doing it "the wrong way". I
> personally definitely find that touch typing improves my ability to
> program as it frees my mind from having to worry about my finger
> placement and looking at the keyboard. Also, I can do an awful lot with
> key combos which all serves to improve my bandwidth of communication to
> the computer. However, this isn't an experience you can explain to
> someone - you have to be a touch typer to appreciate these benefits.
> Similarly, you have to be fluent with paredit to appreciate the benefits.
> With both, you have to go through a pretty dreadful learning curve where
> your productivity is reduced.
Everytime I try to use the command-line REPL, now, I feel like I'm walking
up to an automatic door that just sits there, closed, and there's a mild
surprise that I have to put physical effort into pushing it. Or like the
stumble that comes from stepping onto an escalator that's not
moving....it's a violation of an expectation.
Is paredit essential? No, you can always just go around and take the
stairs. You might get there a bit more slowly, but you'll be getting a
little more exercise in the process.
Paul
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
