5 ms·
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 th
by 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 agoI 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 agoIt'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 agoFor 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 agoBut 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 agoSure 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 agoHere (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...