12 ms·

And, as I wrote in another thread yesterday, it allows you to work with your text editor at a higher level of abstraction than non-lisp-coding people may have s

And, as I wrote in another thread yesterday, it allows you to work with your text editor at a higher level of abstraction than non-lisp-coding people may have seen before (https://news.ycombinator.com/item?id=16386380 https://news.ycombinator.com/item?id=16386380). Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. I find this really hard to give up after lispy sessions.

jstimpfle 9y ago
I really value C syntax. I'm convinced it's much easier to navigate with the eyes than "oatmeal with fingerclips mixed in" (quoting Larry Wall). And >90% of the time the relevant syntactic unit is on its own line or ranges of lines, and that's really super easy to handle in vim. I don't think there is much to improve by building more complex abstractions on top. If you use vim as a C programmer, you should know the basic line operations like dd, p, and Shift+V (line range select). Also, I often use just { and } to navigate to the next/previous empty line. These keyboard shortcuts get those >90% covered. Beyond that, you can use Control+V (block select), and XaY where X can be c (change) or d (delete) or v (visual select), and Y can be things like " (string literals), w (identifier), { (braced block) or ( (parenthesized expression). 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.
- peatmoss 9y ago
  I find C syntax awkward, bloated, inconsistent, and gross compared to lisp syntax, but that’s an aesthetic preference. Beyond the personal preferences of individuals (individuals who probably started with one kind of syntax or another) there are characteristics that have some objective utility. I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’ve never heard anything that demonstrated an intrinsic benefit of C syntax.
  - jstimpfle 9y ago
    It's obviously a lot shorter and more distinctive. It's highly optimized for assignments, pointer and array dereferences, address-of operations and data definitions. If that's what you do most of the day, you want C syntax.
  - nickpsecurity 9y ago
    "I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’ve never heard anything that demonstrated an intrinsic benefit of C syntax." Short stuff is easier to type and maybe to read. There's that. Far as its "design," it was made by tweaking BCPL to make it run on a PDP-7 and then PDP-11. The assignment change was admitted as personal preference. BCPL itself was an ALGOL with LISP features that had every feature for safety, maintainability, etc chopped off to compile on a terrible piece of hardware they were stuck with. There was little to no design: can't overemphasize they literally just kept what that one machine could compile. Far as C, even structs originally weren't in it but got added after their failed attempts to port UNIX from assembly. Presentation below has proof from historical papers written by BCPL and C inventors. https://vimeo.com/132192250 https://vimeo.com/132192250 People just assume there was sensible design because of all the C code out there (argument from popularity). The brain then starts rationalizing attributes about it that were designed or hacked in for totally different reasons in a past of constrained hardware lacking knowledge or tools of modern, language design. That context no longer applies to most users of C. It's just myth-making by users reinforcing use of it.
    - jstimpfle 9y ago
      > The brain then starts rationalizing attributes about it that were designed or hacked in for totally different reasons in a past of constrained hardware lacking knowledge or tools of modern, language design. That context no longer applies to most users of C. It's just myth-making by users reinforcing use of it. That's just _your_ rationalization. I don't think it's commonly claimed that all was set in stone from the beginning. The history is there for everyone to read. Another possible explanation is that C is so minimal (in spirit) and doesn't get in the way, people are able to pull of impressive things, which makes them love C. And now why exactly isn't (the gist of) C sensible design? I fail to see your argument. By the way, please enjoy this cool video: https://www.youtube.com/watch?v=khmFGThc5TI https://www.youtube.com/watch?v=khmFGThc5TI
- arethuza 9y ago
  For a while in early 90's I was paid to mainly write Lisp (along with C and PostScript) having previously mostly done C. My initial reaction to Lisp syntax was pretty much exactly what you describe. However, within a few months I was preferring Lisp over C. It's really just what you are used to - both C and Lisp are great designs. Edit: More recently when I started using Python I thought the significant whitespace thing was awful - I went on to completely change my mind (a bit like drinking G&T).
- kbp 9y ago
  > 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.
  - jstimpfle 9y ago
    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 >>).
    - kbp 9y ago
      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.
- dwc 9y ago
  > "oatmeal with fingerclips mixed in" (quoting Larry Wall) I still chuckle at that quote and Larry Wall is great, but given the look of traditional Perl I wouldn't put much stock in Wall's language syntax aesthetic ;-)
  - kamaal 9y ago
    >>I still chuckle at that quote That quote isn't one statement. Its basically a part of talk/essay and he actually says a lot of nice things about Lisp in that essay, and then mentions this as a joke to close it all.
- khedoros1 9y ago
  > oatmeal with fingerclips mixed in" (quoting Larry Wall). That exact phrasing only seems to show up in 2 places: this comment, and a comment of yours from about a year ago. So I suspect you're paraphrasing...but my purpose for looking was to find that talk/essay/whatever. Would you happen to have a link?
  - dictum 9y ago
    Here (is the (source)): https://groups.google.com/d/msg/comp.lang.clos/edcyFOBLMeo/MgB1ogL7AHcJ https://groups.google.com/d/msg/comp.lang.clos/edcyFOBLMeo/M...
dmitriid 9y ago
> Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. Is there a single programmer on this planet who thinks about code in terms of letters, words, lines, or paragraphs? Newsflash: it's 2018, not 1960, and code editors are capable of things most lisp "editor modes" can only dream about.
- dmitriid 9y ago
  I wish people who downvote my comment would explain what they disagree with. The entire discussion in this subtree centers around paredit (oooh, it can slice and slurp lists!) and vi commands. Have you ever ever seen and experienced an actual modern coding environment? IntelliJ IDEA? Visual Studio? Hell, even Visual Studio Code. The full power of those tools put both vi and paredit to shame when it comes to actually working with code.
  - didibus 9y ago
    You were downvoted because what you said shows that you do not understand what paredit is. I'd recommend you read https://en.m.wikipedia.org/wiki/Structure_editor https://en.m.wikipedia.org/wiki/Structure_editor to better grasp the concept. If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea. In contrast to its source tab.
    - dmitriid 9y ago
      Let's see. Here's the original text: > Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code So. My question is: which modern programmer thinks in terms of thinks about code in terms of letters, words, lines, or paragraphs? The truly antiquated tools (like vi and emacs) may still handle code as if it was just text. The actual code editing tools have long been able to deal with the structure of the code. And in ways that paredit may only dream of. > If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea. Erm. The only "think semantically" that paredit pretends it does happens only because Lisp has a rather regular syntax. It doesn't take much thinking or work to move parts of code in and out of parenthesis, or to be able to close a matching bracket. Actual modern tools know the structure of the code and offer much greater editing and code handling capabilities than that. Edit: As a trivial example. Here's IntelliJ and PHP code (yes, PHP). It understands the code, it's structure, and offers context based editing help based code structure and semantics: https://dmitriid.com/i/gm2tmnztha4tenjq.png https://dmitriid.com/i/gm2tmnztha4tenjq.png Speaking of semantics. Unlike the dumb "move things in out of brackets" the actual tools understand semantics of code. Once again, this is PHP (!), and the tool knows about the semantics of code: https://dmitriid.com/i/gm2tmnbtga4tanjs.png https://dmitriid.com/i/gm2tmnbtga4tanjs.png Editing capabilities available to some other languages would blow your mind.

jstimpfle 9y ago

I really value C syntax. I'm convinced it's much easier to navigate with the eyes than "oatmeal with fingerclips mixed in" (quoting Larry Wall). And >90% of the time the relevant syntactic unit is on its own line or ranges of lines, and that's really super easy to handle in vim. I don't think there is much to improve by building more complex abstractions on top. If you use vim as a C programmer, you should know the basic line operations like dd, p, and Shift+V (line range select). Also, I often use just { and } to navigate to the next/previous empty line. These keyboard shortcuts get those >90% covered. Beyond that, you can use Control+V (block select), and XaY where X can be c (change) or d (delete) or v (visual select), and Y can be things like " (string literals), w (identifier), { (braced block) or ( (parenthesized expression). 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.

peatmoss 9y ago
I find C syntax awkward, bloated, inconsistent, and gross compared to lisp syntax, but that’s an aesthetic preference. Beyond the personal preferences of individuals (individuals who probably started with one kind of syntax or another) there are characteristics that have some objective utility. I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’ve never heard anything that demonstrated an intrinsic benefit of C syntax.
- jstimpfle 9y ago
  It's obviously a lot shorter and more distinctive. It's highly optimized for assignments, pointer and array dereferences, address-of operations and data definitions. If that's what you do most of the day, you want C syntax.
- nickpsecurity 9y ago
  "I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’ve never heard anything that demonstrated an intrinsic benefit of C syntax." Short stuff is easier to type and maybe to read. There's that. Far as its "design," it was made by tweaking BCPL to make it run on a PDP-7 and then PDP-11. The assignment change was admitted as personal preference. BCPL itself was an ALGOL with LISP features that had every feature for safety, maintainability, etc chopped off to compile on a terrible piece of hardware they were stuck with. There was little to no design: can't overemphasize they literally just kept what that one machine could compile. Far as C, even structs originally weren't in it but got added after their failed attempts to port UNIX from assembly. Presentation below has proof from historical papers written by BCPL and C inventors. https://vimeo.com/132192250 https://vimeo.com/132192250 People just assume there was sensible design because of all the C code out there (argument from popularity). The brain then starts rationalizing attributes about it that were designed or hacked in for totally different reasons in a past of constrained hardware lacking knowledge or tools of modern, language design. That context no longer applies to most users of C. It's just myth-making by users reinforcing use of it.
  - jstimpfle 9y ago
    > The brain then starts rationalizing attributes about it that were designed or hacked in for totally different reasons in a past of constrained hardware lacking knowledge or tools of modern, language design. That context no longer applies to most users of C. It's just myth-making by users reinforcing use of it. That's just _your_ rationalization. I don't think it's commonly claimed that all was set in stone from the beginning. The history is there for everyone to read. Another possible explanation is that C is so minimal (in spirit) and doesn't get in the way, people are able to pull of impressive things, which makes them love C. And now why exactly isn't (the gist of) C sensible design? I fail to see your argument. By the way, please enjoy this cool video: https://www.youtube.com/watch?v=khmFGThc5TI https://www.youtube.com/watch?v=khmFGThc5TI
arethuza 9y ago
For a while in early 90's I was paid to mainly write Lisp (along with C and PostScript) having previously mostly done C. My initial reaction to Lisp syntax was pretty much exactly what you describe. However, within a few months I was preferring Lisp over C. It's really just what you are used to - both C and Lisp are great designs. Edit: More recently when I started using Python I thought the significant whitespace thing was awful - I went on to completely change my mind (a bit like drinking G&T).
kbp 9y ago
> 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.
- jstimpfle 9y ago
  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 >>).
  - kbp 9y ago
    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.
dwc 9y ago
> "oatmeal with fingerclips mixed in" (quoting Larry Wall) I still chuckle at that quote and Larry Wall is great, but given the look of traditional Perl I wouldn't put much stock in Wall's language syntax aesthetic ;-)
- kamaal 9y ago
  >>I still chuckle at that quote That quote isn't one statement. Its basically a part of talk/essay and he actually says a lot of nice things about Lisp in that essay, and then mentions this as a joke to close it all.
khedoros1 9y ago
> oatmeal with fingerclips mixed in" (quoting Larry Wall). That exact phrasing only seems to show up in 2 places: this comment, and a comment of yours from about a year ago. So I suspect you're paraphrasing...but my purpose for looking was to find that talk/essay/whatever. Would you happen to have a link?
- dictum 9y ago
  Here (is the (source)): https://groups.google.com/d/msg/comp.lang.clos/edcyFOBLMeo/MgB1ogL7AHcJ https://groups.google.com/d/msg/comp.lang.clos/edcyFOBLMeo/M...

dmitriid 9y ago

> Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. Is there a single programmer on this planet who thinks about code in terms of letters, words, lines, or paragraphs? Newsflash: it's 2018, not 1960, and code editors are capable of things most lisp "editor modes" can only dream about.

dmitriid 9y ago
I wish people who downvote my comment would explain what they disagree with. The entire discussion in this subtree centers around paredit (oooh, it can slice and slurp lists!) and vi commands. Have you ever ever seen and experienced an actual modern coding environment? IntelliJ IDEA? Visual Studio? Hell, even Visual Studio Code. The full power of those tools put both vi and paredit to shame when it comes to actually working with code.
- didibus 9y ago
  You were downvoted because what you said shows that you do not understand what paredit is. I'd recommend you read https://en.m.wikipedia.org/wiki/Structure_editor https://en.m.wikipedia.org/wiki/Structure_editor to better grasp the concept. If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea. In contrast to its source tab.
  - dmitriid 9y ago
    Let's see. Here's the original text: > Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code So. My question is: which modern programmer thinks in terms of thinks about code in terms of letters, words, lines, or paragraphs? The truly antiquated tools (like vi and emacs) may still handle code as if it was just text. The actual code editing tools have long been able to deal with the structure of the code. And in ways that paredit may only dream of. > If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea. Erm. The only "think semantically" that paredit pretends it does happens only because Lisp has a rather regular syntax. It doesn't take much thinking or work to move parts of code in and out of parenthesis, or to be able to close a matching bracket. Actual modern tools know the structure of the code and offer much greater editing and code handling capabilities than that. Edit: As a trivial example. Here's IntelliJ and PHP code (yes, PHP). It understands the code, it's structure, and offers context based editing help based code structure and semantics: https://dmitriid.com/i/gm2tmnztha4tenjq.png https://dmitriid.com/i/gm2tmnztha4tenjq.png Speaking of semantics. Unlike the dumb "move things in out of brackets" the actual tools understand semantics of code. Once again, this is PHP (!), and the tool knows about the semantics of code: https://dmitriid.com/i/gm2tmnbtga4tanjs.png https://dmitriid.com/i/gm2tmnbtga4tanjs.png Editing capabilities available to some other languages would blow your mind.