4 ms·

What's with the people who still use the term C/C++? C++ and C are separate languages. I'd be grateful for the author to reflect it in the Readme. Further, Br

What's with the people who still use the term C/C++? C++ and C are separate languages. I'd be grateful for the author to reflect it in the Readme. Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. "C/C++ - a mythical language referred to by people who cannot or do not want to recognize the magnitude of differences between the facilities offered by C and C++" -- Stroustrup

fioawjpoifajio 5y ago
Concretely, rr uses both C and C++, so the term is perfectly valid, given that the two languages interoperate just fine.
smoldesu 5y ago
> C++ and C are separate languages. I'd be grateful for the author to reflect it in the Readme. I agree, but we could honestly be as granular as we want here. We could ask the author to delineate between C99 and C11, but it ultimately doesn't really matter. The point of referring to "C/C++" is to cast a blanket statement over the traditional compiled mainstays and use them as a point of reference. While they are indeed different, they're more alike then they are dissimilar. I think the author is perfectly justified here. > Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. Rust is a language that is extremely verbose, and properly formatted Rust code often uses more lines than necessary to improve readability (expanding match arms, removing inlined if-statements, etc.). Hell, if you look at the repo, it looks almost identical to a default Rust project: src is clearly exposed at the root, and everything else is pretty well organized into distinct folders. I disagree with the first part of your statement ("Bragging about LoC is bad") but agree with the second part ("LoC is a poor measure of both quality and functionality.") Honestly, I think LoC-shaming originated in languages like Java and Python, where more lines of code almost guaranteed more complexity. Rust's focus on zero cost abstraction ultimately means that even massive programs can run with minimal overhead. I'm not here to parade Rust's achievements in front of you, but I figured it was worth pointing out at least here.
- lmilcin 5y ago
  > Honestly, I think LoC-shaming originated in languages like Java and Python, where more lines of code almost guaranteed more complexity. Rust's focus on zero cost abstraction ultimately means that even massive programs can run with minimal overhead. Zero-cost abstractions are meant to be zero physical cost, not zero mental cost. LoC still translate to mental overhead and "LoC shaming" is appropriate for any language, not just verbose like Java or Python.
  - v8dev123 5y ago
    C++ also happen to use the term zero-cost abstractions along with RAII since 2011 but Chandler Carruth “There Are No Zero-cost Abstractions” You can watch and see what they really are. I bet this is true for Rust as-well.
    - lmilcin 5y ago
      Well... the only language with true zero-cost abstractions is Lisp (assuming you call it a language, which it strictly isn't, but let's not go there right now). The reason Lisp is zero cost is because what you write as data structure (the program IS a data structure) can be interpreted however you decide it to be interpreted. You can design any kind of abstraction you like and then separately completely control how that code is translated to binary. For example, when you write a function call like printf("%d", 7) in C (forgetting built in optimization for printf...), the resulting binary has no other choice than to call printf function, parse "%d" and then conditionally read in argument and create a string. On the other hand if C was Lisp it could, at the time of compilation, translate this code to invocation of putc('7') so that during normal execution the parsing of "%d" would never happen. In C this requires compiler support. In Lisp you are compiler -- you decide what code is going to be generated.
      - ithkuil 5y ago
        "Zero cost abstraction, for some definition of cost" :-)
lmilcin 5y ago
> Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. It is not a measure of quality but rather size of the project.
- SquibblesRedux 5y ago
  It's not the size of the project, it's how you use it.
- baby 5y ago
  Was he bragging about it? I think it was more about the amount of work accomplished. It’s not a 1k LOC project.
jeff-davis 5y ago
There aren't many pairs of mainstream languages that really interoperate well together. C and C++ do, which can blur the lines a bit. Not sure if this is what the author meant. With rust growing in popularity and good interoperability, I suspect we'll see the rise of projects written in C/Rust and C++/Rust, and maybe even C/C++/Rust. The line will obviously be more clear because of dramatically different syntax, packaging, build system, etc.
- v8dev123 5y ago
  My issue was "/" and I'd be fine if he had used "C, C++" or "C & C++"
  - jeff-davis 5y ago
    Does "/" have a concrete meaning? I vaguely think it means "with" or "and" or "or", but it seems more ambiguous.
    - v8dev123 5y ago
      It's ambiguous and not clear to reader!

fioawjpoifajio 5y ago

Concretely, rr uses both C and C++, so the term is perfectly valid, given that the two languages interoperate just fine.

smoldesu 5y ago

> C++ and C are separate languages. I'd be grateful for the author to reflect it in the Readme. I agree, but we could honestly be as granular as we want here. We could ask the author to delineate between C99 and C11, but it ultimately doesn't really matter. The point of referring to "C/C++" is to cast a blanket statement over the traditional compiled mainstays and use them as a point of reference. While they are indeed different, they're more alike then they are dissimilar. I think the author is perfectly justified here. > Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. Rust is a language that is extremely verbose, and properly formatted Rust code often uses more lines than necessary to improve readability (expanding match arms, removing inlined if-statements, etc.). Hell, if you look at the repo, it looks almost identical to a default Rust project: src is clearly exposed at the root, and everything else is pretty well organized into distinct folders. I disagree with the first part of your statement ("Bragging about LoC is bad") but agree with the second part ("LoC is a poor measure of both quality and functionality.") Honestly, I think LoC-shaming originated in languages like Java and Python, where more lines of code almost guaranteed more complexity. Rust's focus on zero cost abstraction ultimately means that even massive programs can run with minimal overhead. I'm not here to parade Rust's achievements in front of you, but I figured it was worth pointing out at least here.

lmilcin 5y ago
> Honestly, I think LoC-shaming originated in languages like Java and Python, where more lines of code almost guaranteed more complexity. Rust's focus on zero cost abstraction ultimately means that even massive programs can run with minimal overhead. Zero-cost abstractions are meant to be zero physical cost, not zero mental cost. LoC still translate to mental overhead and "LoC shaming" is appropriate for any language, not just verbose like Java or Python.
- v8dev123 5y ago
  C++ also happen to use the term zero-cost abstractions along with RAII since 2011 but Chandler Carruth “There Are No Zero-cost Abstractions” You can watch and see what they really are. I bet this is true for Rust as-well.
  - lmilcin 5y ago
    Well... the only language with true zero-cost abstractions is Lisp (assuming you call it a language, which it strictly isn't, but let's not go there right now). The reason Lisp is zero cost is because what you write as data structure (the program IS a data structure) can be interpreted however you decide it to be interpreted. You can design any kind of abstraction you like and then separately completely control how that code is translated to binary. For example, when you write a function call like printf("%d", 7) in C (forgetting built in optimization for printf...), the resulting binary has no other choice than to call printf function, parse "%d" and then conditionally read in argument and create a string. On the other hand if C was Lisp it could, at the time of compilation, translate this code to invocation of putc('7') so that during normal execution the parsing of "%d" would never happen. In C this requires compiler support. In Lisp you are compiler -- you decide what code is going to be generated.
    - ithkuil 5y ago
      "Zero cost abstraction, for some definition of cost" :-)

lmilcin 5y ago

> Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. It is not a measure of quality but rather size of the project.

SquibblesRedux 5y ago
It's not the size of the project, it's how you use it.
baby 5y ago
Was he bragging about it? I think it was more about the amount of work accomplished. It’s not a 1k LOC project.

jeff-davis 5y ago

There aren't many pairs of mainstream languages that really interoperate well together. C and C++ do, which can blur the lines a bit. Not sure if this is what the author meant. With rust growing in popularity and good interoperability, I suspect we'll see the rise of projects written in C/Rust and C++/Rust, and maybe even C/C++/Rust. The line will obviously be more clear because of dramatically different syntax, packaging, build system, etc.

v8dev123 5y ago
My issue was "/" and I'd be fine if he had used "C, C++" or "C & C++"
- jeff-davis 5y ago
  Does "/" have a concrete meaning? I vaguely think it means "with" or "and" or "or", but it seems more ambiguous.
  - v8dev123 5y ago
    It's ambiguous and not clear to reader!