Hacker News Reader

Comment by kbp | Hacker News Reader

> I don't disagree that if all you have is parens, then you want something like paredit. But for a C programmer there is no need for such a thing.

If that's a good selection of tools for editing code, then why would Lisp programmers need Paredit? Most of those commands work just as well for editing Lisp. The advantages that Paredit gives over that model are semantic commands rather than character based ones, things like easily slurping and splicing things into parent lists (a block, the arguments to a function call, whatever) without having to think about the syntax needed for that transformation.

There's nothing about Lisp that makes the vi commands you use for editing C less useful for editing Lisp; people use things like Paredit because they allow for a much more semantic style of editing.

View on HN

But there is no such thing as "parent lists" in C. There are much less parentheses. You don't make nested functions or data. You write simple, procedural code, and therefore you simply move lines up or down, and at most change the indentation level. (To fix indentation in vim, select a block of lines and use =. To shift left or right, use << or >>).

Sure there is. Imagine you had this function:

    int f(void) {
        int x = 1;
        return x * 2;
    }

Then pretend that later you wanted to call f and provide your own value of x for it to transform, but you realise that f doesn't take a parameter, so you go to move the x declaration in f into its parameter list. What you really want to do here is delete the first element of the parameter list, and then move the first expression in its next sibling list (the function body) to the end of it. C syntax doesn't make this easy for editors to do, but the operations can still be thought of in terms of lists.

You get nested expressions whenever you use if or a loop or call a function. C programs might be flatter on average than Lisp programs, but there's still plenty of structural editing you could do. Another example is moving an expression out of or into a loop, without concern for how many lines it takes up, whether it's a function call or a loop or anything.

The difficulty that C syntax creates for editing operations like this isn't C not having the need for Paredit-style editing, it's C not having good support for it.

Tooling is getting better for non-Lisp languages. In C#, with Visual Studio and ReSharper, for example, you could highlight the "int x = 1;" line, and hit your keyboard shortcut for ReSharper:Introduce_Parameter, which would do pretty much exactly what you're saying. Same for turning a chunk of code into a method, etc.

The tooling is there, it's not bad, and it is constantly getting better.

I use Cursive in IntelliJ to do all my Clojure programming. A lot of others also use Emacs but Cursive is an amazing plugin imho. It does the vast majority of things I want from an IDE, like jumping to definitions, some refactorings, switching easily to relevant test files. Paredit took a while to get used to but I immediately miss it when programming anything else.

Regarding the loop: that's exactly what I described, you just move lines and fix the indentation. It's super quick. There just isn't significant nesting in good code. It's almost always bad style to nest function calls. In statement-blocks you don't have the "trailing parentheses" problem that you have in LISP, since the closing brace is on its own line - so it really boils down to cutting and pasting lines >90% of the time.

Aside: in original C, this is how you wrote functions:

  int f(x, y)
          int x;
          int y;
  {
          int z;
          ...
  }

> Regarding the loop: that's exactly what I described, you just move lines and fix the indentation.

The experience you get with Paredit is not the same experience you get with C and vi, because you have to be concerned with things at the character level to make the transformation. What single command do you use to move the function call, for loop, label, or do-while loop after the closing brace of the current block into this block, whether it's 1 line or 100? What if you have something like f(x, y * 2) and you decide that you want to put y * 2 into a variable instead? Do you write every argument to every function on its own line?

Again, if you want to do things the C way in Lisp, it's not like Lisp makes it hard to do those kinds of edits. Things like Paredit are popular because people find them more efficient to use. Editors can support Paredit-like editing in C, but it's much more difficult to accomplish because of limitations with C's syntax.

So instead of lots of parens, you get lots of {}, [], and () spread across more lines, and curly braced blocks are often nested.

Reply on news.ycombinator.com