4 ms·

Without a doubt, C programmers have different styles. And there's disagreement about what to do when an expression gets too long. However, almost no C program

by xscott 4y ago

Without a doubt, C programmers have different styles. And there's disagreement about what to do when an expression gets too long. However, almost no C programmer would stack and hang their closing curly braces the way Lisp programmers do with closing parens. And for the few exceptions you'll find, they're almost certainly Lisp programmers making a point about not doing what the Romans do when they're in Rome. > In short, there is almost nothing arbitrary about the way I'm formatting anything. Heh, I didn't mean it as an attack on you. I meant it how the rest of us perceive it. Forgive me :-) I guess it's only natural that you should defend your own style. I'm just curious if maybe part of the reason Lisp is so objectionable to most programmers is because that style is so different from block structured languages. Many people here seem to like Python. So they think this is fine: def doit(n): for i in range(n): print(i) Many fewer people seem to like Lisp. So maybe this is less likeable for some reason: (def (doit n) (for i in (range n) (print i))) Ok, so is this more likeable? (def (doit n) (for i in (range n) (print i) ) ) Just curious. > Even if I wanted to experiment with four space indents in Lisp, the editor I use wouldn't support it. That's pretty circular though... Lisp programmers expect a certain indentation, so editors provide it.

kazinator 4y ago
> I guess it's only natural that you should defend your own style. I have reasons for writing things that way, that can be documented, if necessary. The style is not my own, though. > However, almost no C programmer would stack and hang their closing curly braces the way Lisp programmers do with closing parens. But they do it all the time with parentheses, which is the normal thing to do. By the way: spotted lots of this in the Zstandard compression code base a few days ago: void fun() { if (...) { for (...) { ... } } } Yikes; the closes braces line up with the opening ones, but not their corresponding matching ones. I hope that wasn't a Lisp coder (and don't suspect it). > I'm just curious if maybe part of the reason Lisp is so objectionable to most programmers is because that style is so different from block structured languages. But it isn't. Almost all the indentation and alignment strategies you see in canonically formatted Lisp code have counterparts in everyday code in mainstream languages. Found this in Linux's kernel/sched/core.c: WARN_ON_ONCE(debug_locks && !(lockdep_is_held(&p->pi_lock) || lockdep_is_held(__rq_lockp(task_rq(p))))); ^ Lisp disease? ^ gee what is this "arbitrary" alignment? Would C be more popular if it was more typically like this? WARN_ON_ONCE( debug_locks && !( lockdep_is_held( &p->pi_lock ) || lockdep_is_held( __rq_lockp( task_rq(p) ) ) ) ); In fair.c file in the same directory: if ((ns->nr_running < ns->weight) || (((ns->compute_capacity * 100) > (ns->util * imbalance_pct)) && ((ns->compute_capacity * imbalance_pct) > (ns->runnable * 100)))) return node_has_spare; in drivers/md/raid5.c: if (s.written && (s.p_failed || ((test_bit(R5_Insync, &pdev->flags) && !test_bit(R5_LOCKED, &pdev->flags) && (test_bit(R5_UPTODATE, &pdev->flags) || test_bit(R5_Discard, &pdev->flags))))) && (s.q_failed || ((test_bit(R5_Insync, &qdev->flags) && !test_bit(R5_LOCKED, &qdev->flags) && (test_bit(R5_UPTODATE, &qdev->flags) || test_bit(R5_Discard, &qdev->flags)))))) handle_stripe_clean_event(conf, sh, disks); All of these examples use pretty much identical formatting logic as what I'm following when I'm coding in Lisp; except that a more pure version of it occurs.
- xscott 4y ago
  Well, you've successfully found examples of C code that I hate to look at. Those are all various shades of awful in my opinion. And again, I'm not attacking you or your style. I'm sure all 6 or 7 of you from comp.lang.lisp agree it's wonderful. :-)
  - kazinator 4y ago
    This is a predominant style used in writing "curly-braced C-likes"; you see it everywhere and examples can be found readily. You simply don't seem familiar with this subject area.
    - xscott 4y ago
      Heh. I see we've gotten to the point where you switch from arguing the point to questioning my qualifications. Gross. I guess that means I should return the insult: Showing a few examples of ugly formatting doesn't prove that curly-braced languages are that way "everywhere". And besides, other than the one silly example from Zstandard, which many people would agree is unusual, you didn't even show examples of curly braces. Even with all the different styles of C people use, the block structure is pretty consistent. You're either being deceptive or you need work on your logic skills. Go ahead and grab the last word if you want it, but I think we've gotten away from anything good in this discussion.
lispm 4y ago
The Lisp version looks similar to the Python code, plus parentheses. As a Lisp user I would read the Lisp code just like the Python code, by largely ignoring the parentheses, looking at the indentation and blocks of code. As a Lisp user working with code manipulation I then profit from that Lisp can be pretty printed by a tool, since the indentation is not The dangling parentheses then don't add any value. Actually they waste space and are getting in the way when typing to a read-eval-print-loop (REPL). I haven't seen anyone typing to a REPL dangling parentheses. CL-USER 23 > (defun foo (a) (list (list a b c ) ) ) FOO What I always see is compact code like this: CL-USER 24 > (defun foo (a) (list (list a b c)))

by xscott 4y ago

kazinator 4y ago

> I guess it's only natural that you should defend your own style. I have reasons for writing things that way, that can be documented, if necessary. The style is not my own, though. > However, almost no C programmer would stack and hang their closing curly braces the way Lisp programmers do with closing parens. But they do it all the time with parentheses, which is the normal thing to do. By the way: spotted lots of this in the Zstandard compression code base a few days ago: void fun() { if (...) { for (...) { ... } } } Yikes; the closes braces line up with the opening ones, but not their corresponding matching ones. I hope that wasn't a Lisp coder (and don't suspect it). > I'm just curious if maybe part of the reason Lisp is so objectionable to most programmers is because that style is so different from block structured languages. But it isn't. Almost all the indentation and alignment strategies you see in canonically formatted Lisp code have counterparts in everyday code in mainstream languages. Found this in Linux's kernel/sched/core.c: WARN_ON_ONCE(debug_locks && !(lockdep_is_held(&p->pi_lock) || lockdep_is_held(__rq_lockp(task_rq(p))))); ^ Lisp disease? ^ gee what is this "arbitrary" alignment? Would C be more popular if it was more typically like this? WARN_ON_ONCE( debug_locks && !( lockdep_is_held( &p->pi_lock ) || lockdep_is_held( __rq_lockp( task_rq(p) ) ) ) ); In fair.c file in the same directory: if ((ns->nr_running < ns->weight) || (((ns->compute_capacity * 100) > (ns->util * imbalance_pct)) && ((ns->compute_capacity * imbalance_pct) > (ns->runnable * 100)))) return node_has_spare; in drivers/md/raid5.c: if (s.written && (s.p_failed || ((test_bit(R5_Insync, &pdev->flags) && !test_bit(R5_LOCKED, &pdev->flags) && (test_bit(R5_UPTODATE, &pdev->flags) || test_bit(R5_Discard, &pdev->flags))))) && (s.q_failed || ((test_bit(R5_Insync, &qdev->flags) && !test_bit(R5_LOCKED, &qdev->flags) && (test_bit(R5_UPTODATE, &qdev->flags) || test_bit(R5_Discard, &qdev->flags)))))) handle_stripe_clean_event(conf, sh, disks); All of these examples use pretty much identical formatting logic as what I'm following when I'm coding in Lisp; except that a more pure version of it occurs.

xscott 4y ago
Well, you've successfully found examples of C code that I hate to look at. Those are all various shades of awful in my opinion. And again, I'm not attacking you or your style. I'm sure all 6 or 7 of you from comp.lang.lisp agree it's wonderful. :-)
- kazinator 4y ago
  This is a predominant style used in writing "curly-braced C-likes"; you see it everywhere and examples can be found readily. You simply don't seem familiar with this subject area.
  - xscott 4y ago
    Heh. I see we've gotten to the point where you switch from arguing the point to questioning my qualifications. Gross. I guess that means I should return the insult: Showing a few examples of ugly formatting doesn't prove that curly-braced languages are that way "everywhere". And besides, other than the one silly example from Zstandard, which many people would agree is unusual, you didn't even show examples of curly braces. Even with all the different styles of C people use, the block structure is pretty consistent. You're either being deceptive or you need work on your logic skills. Go ahead and grab the last word if you want it, but I think we've gotten away from anything good in this discussion.

lispm 4y ago

The Lisp version looks similar to the Python code, plus parentheses. As a Lisp user I would read the Lisp code just like the Python code, by largely ignoring the parentheses, looking at the indentation and blocks of code. As a Lisp user working with code manipulation I then profit from that Lisp can be pretty printed by a tool, since the indentation is not The dangling parentheses then don't add any value. Actually they waste space and are getting in the way when typing to a read-eval-print-loop (REPL). I haven't seen anyone typing to a REPL dangling parentheses. CL-USER 23 > (defun foo (a) (list (list a b c ) ) ) FOO What I always see is compact code like this: CL-USER 24 > (defun foo (a) (list (list a b c)))