8 ms·

Too bad C++ is the most terrible thing since forever. https://twitter.com/Cor3ntin/status/1383875999033565194?s=20 https://twitter.com/Cor3ntin/status/13838759

by jfrd 5y ago

Too bad C++ is the most terrible thing since forever. https://twitter.com/Cor3ntin/status/1383875999033565194?s=20 https://twitter.com/Cor3ntin/status/1383875999033565194?s=20

pjmlp 5y ago
Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.
- linkdd 5y ago
  This kind of comments are forgetting all the good that C did bring in the last 50 years of computer history. <sarcasm>Too bad those shitty engineers in the 70s didn't think of Rust...</sarcasm>
  - miohtama 5y ago
    They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers. Instead, the burden of ensuring correctness had to be left as the cognitive burden for the developer for decades to come.
    - MaxBarraclough 5y ago
      > They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers. That's probably true for borrower-checking specifically, but I don't think it accounts for all language-design breakthroughs. There were decades between the development of functional programming languages, and widespread hybrid languages which incorporated those ideas (e.g. modern Python and C#).
    - pjmlp 5y ago
      See Burroughs B5500, created in 1961 with ESPOL/NEWP, 10 years before C was even an idea.
  - jabl 5y ago
    > <sarcasm>Too bad those shitty engineers in the 70s didn't think of Rust...</sarcasm> True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model. OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG https://pastebin.com/UAQaWuWG
    - rualca 5y ago
      That pastebin leaves out the fact that C's spartan approach and extreme simplicity allowed C to become the most popular programming language in the world already in the time of K&R, a book still renowned for it's clarity and low mental baggage required to onboard onto a programming language. The pastebin also left out that Bjarne Stroustrup developed C with classes, and the C, as a backward compatible superset of C to take advantage of C's unrivaled popularity. We all can agree that the science and art behind programming language design progressed a lot in the four decades where we enjoyed C. However, it feels a kin to rewriting history to depict C as a subpar language that was poorly designed and had little to no redeeming qualities, when facts speak for themselves.
      - titzer 5y ago
        C was not extremely simple. Lisp was extremely simple.
        Koshkin 5y ago
        Problem was, real world programming in Lisp was not simple.
        ku-man 5y ago
        "Problem is, real world programming in Lisp is not simple" is also correct.
        pjmlp 5y ago
  - mhh__ 5y ago
    Adding slices to C would kill a lot of bugs without going all the way to rust.
  - titzer 5y ago
    No one can seriously argue that C's language design was inherently advantageous over, say, Pascal. If Lisp, ML, Simula, Algol, or Ada received the amount of optimization and porting investment that C did, history would be very different. C succeeded because a.) Unix, and b.) there were a zillion platforms with a zillion different compilers that could process something like C. They all did weird things and you couldn't actually write portable code for decades, but you could kind of fake it.
    - refenestrator 5y ago
      That portability to a zillion platforms was part of the language design, though. 'Portable assembler' and all that.
      - pjmlp 5y ago
        All high level languages are portable, and many already were before C came to be. Just marketing speak.
        refenestrator 5y ago
        Sure, with more or less effort. C's semantics seem very easy to port, with very little abstraction over the commonalities that all (most?) assemblies share: computer as a giant array with a CPU and registers. There's a gaping hole in the abstraction when it comes to word size, but that's about it, and it's obvious to diagnose at least. Compared to the list of languages above with their more advanced features, it's super easy to port a C compiler and start compiling code. Worse is better.
        pjmlp 5y ago
        So easy that to actually make C portable, UNIX had to be made into a C standard library via POSIX, otherwise portable C code is basically just logic and data structures.
        5y ago
  - agumonkey 5y ago
    Actually I'd bet a dollar or two that linear threading of resources existed even before C, it just wasn't neither a common practice nor a theoretical framework at the time.
  - pjmlp 5y ago
    Like the Go designers ignored generics, they ignored the safer systems programming languages developed as ALGOL and PL/I variants during the 60s. https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html
- xjay 5y ago
  The late pioneer in compiler optimization--Frances Allen--agrees. 2006: "..but something else had happened--and that was back in 1973--[something] which I was very, very unhappy about--and that was the advent of C! It derailed, as far as I was concerned, the advances that I foresaw in compilers. One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally." "There was an interesting debate at the SIGPLAN conference in that period--about the relative need for optimization. It was put on the table that it wasn't going to be needed anymore! So. Anyway. You can have your own opinion on that, but I know I have mine, beyond a doubt that it was a huge setback for--in my opinion--languages and compilers--and the ability to deliver performance--easily--to the user." https://en.m.wikipedia.org/wiki/Frances_Allen https://en.m.wikipedia.org/wiki/Frances_Allen https://www.youtube.com/watch?v=NjoU-MjCws4&t=2450 https://www.youtube.com/watch?v=NjoU-MjCws4&t=2450
  - titzer 5y ago
    She's exactly right. I'm really not sure how we came to accept the worse-is-better argument that high performance required exposing machine details into the source language, and letting compiler writers just "do whatever is fastest", regardless of safety. It gave rise to today's situation where none of application writers, library writers, kernel writers, or compiler writers are quite sure what will happen if a new optimization is introduced. Will it break programs? By how much? Well, let's roll the dice! This is a direct result of allowing--no, even expecting--programmers to peer behind the curtains to see machine details that they frankly, shouldn't. It's why porting programs from one machine to another is even a thing, as opposed to just selecting a different output from a compiler, or running a different VM. Proper abstractions define exactly what happens in every situation, and design unobservable details out. It is the basis for optimizations that fundamentally cannot observed (except side-channels, like timing and other resource usage). Proper abstractions is why we have fast processors. The ISA is a hard boundary.
  - flukus 5y ago
    > One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally." Well 50 years on we still haven't seen any of these "sufficiently smart compilers", at best they can outsmart C compilers in a few cases with things like generics, so the idea that higher level languages would be faster has been wrong for at least 5 decades. At least you can forgive them for thinking they would 50 years ago, but now it's just ignoring 50 years of reality.
- Koshkin 5y ago
  Have been programming in C (and then C++), like, forever. Hardly any memory corruption issues. Yes, you have to be a little more disciplined and pay attention to things. Being distracted certainly does not help.
  - MaxBarraclough 5y ago
    A significant fraction of major security vulnerabilities in C/C++ codebases relate to memory-management bugs.
    - secondcoming 5y ago
      How old is the code though? It's actually really hard to get modern C++ wrong
      - pjmlp 5y ago
        Assuming it gets used. https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary.pdf https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...
        MaxBarraclough 5y ago
        I'm less optimistic. Even major C++ projects that do everything right, still have issues that would have been prevented had they used a safe language. My go-to example is Chromium.
        pjmlp 5y ago
        Agreed, I keep reaching for C++, because of the dependency many ecosystems have. Chromium is a good example actually, I bet they would rather follow the "Custom C++ libraries" and "Hardware mitigations" than the Firefox approach. https://www.chromium.org/Home/chromium-security/memory-safety https://www.chromium.org/Home/chromium-security/memory-safet... Apple did something similar recently, their iBoot firmware uses a custom safe C dialect.
emsy 5y ago
All those "orange site bad" comments lol
- TeMPOraL 5y ago
  Yeah, "orange site" comments on Twitter are an interesting entertainment genre in general, if you're into "a visit to the bizarro world" type of humor :).
  - pwdisswordfish8 5y ago
    Blue site bad
Koshkin 5y ago
I happen to disagree, C++ is the best thing after sliced bread. (Just wanted to balance the conversation, really, with an equally meaningless, albeit honest, statement.)
jfrd 5y ago
For those who didn't click the link, this is a joke response to the author's tweet: "I am bracing for the inevitable comments about C++ being the most terrible thing since forever :("
lenkite 5y ago
C++ is amazing. Learn to Code.

by jfrd 5y ago

Too bad C++ is the most terrible thing since forever. https://twitter.com/Cor3ntin/status/1383875999033565194?s=20 https://twitter.com/Cor3ntin/status/1383875999033565194?s=20

pjmlp 5y ago

Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.

linkdd 5y ago
This kind of comments are forgetting all the good that C did bring in the last 50 years of computer history. <sarcasm>Too bad those shitty engineers in the 70s didn't think of Rust...</sarcasm>
- miohtama 5y ago
  They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers. Instead, the burden of ensuring correctness had to be left as the cognitive burden for the developer for decades to come.
  - MaxBarraclough 5y ago
    > They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers. That's probably true for borrower-checking specifically, but I don't think it accounts for all language-design breakthroughs. There were decades between the development of functional programming languages, and widespread hybrid languages which incorporated those ideas (e.g. modern Python and C#).
  - pjmlp 5y ago
    See Burroughs B5500, created in 1961 with ESPOL/NEWP, 10 years before C was even an idea.
- jabl 5y ago
  > <sarcasm>Too bad those shitty engineers in the 70s didn't think of Rust...</sarcasm> True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model. OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG https://pastebin.com/UAQaWuWG
  - rualca 5y ago
    That pastebin leaves out the fact that C's spartan approach and extreme simplicity allowed C to become the most popular programming language in the world already in the time of K&R, a book still renowned for it's clarity and low mental baggage required to onboard onto a programming language. The pastebin also left out that Bjarne Stroustrup developed C with classes, and the C, as a backward compatible superset of C to take advantage of C's unrivaled popularity. We all can agree that the science and art behind programming language design progressed a lot in the four decades where we enjoyed C. However, it feels a kin to rewriting history to depict C as a subpar language that was poorly designed and had little to no redeeming qualities, when facts speak for themselves.
    - titzer 5y ago
      C was not extremely simple. Lisp was extremely simple.
      - Koshkin 5y ago
        Problem was, real world programming in Lisp was not simple.
        ku-man 5y ago
        "Problem is, real world programming in Lisp is not simple" is also correct.
        pjmlp 5y ago
- mhh__ 5y ago
  Adding slices to C would kill a lot of bugs without going all the way to rust.
- titzer 5y ago
  No one can seriously argue that C's language design was inherently advantageous over, say, Pascal. If Lisp, ML, Simula, Algol, or Ada received the amount of optimization and porting investment that C did, history would be very different. C succeeded because a.) Unix, and b.) there were a zillion platforms with a zillion different compilers that could process something like C. They all did weird things and you couldn't actually write portable code for decades, but you could kind of fake it.
  - refenestrator 5y ago
    That portability to a zillion platforms was part of the language design, though. 'Portable assembler' and all that.
    - pjmlp 5y ago
      All high level languages are portable, and many already were before C came to be. Just marketing speak.
      - refenestrator 5y ago
        Sure, with more or less effort. C's semantics seem very easy to port, with very little abstraction over the commonalities that all (most?) assemblies share: computer as a giant array with a CPU and registers. There's a gaping hole in the abstraction when it comes to word size, but that's about it, and it's obvious to diagnose at least. Compared to the list of languages above with their more advanced features, it's super easy to port a C compiler and start compiling code. Worse is better.
        pjmlp 5y ago
        So easy that to actually make C portable, UNIX had to be made into a C standard library via POSIX, otherwise portable C code is basically just logic and data structures.
        5y ago
- agumonkey 5y ago
  Actually I'd bet a dollar or two that linear threading of resources existed even before C, it just wasn't neither a common practice nor a theoretical framework at the time.
- pjmlp 5y ago
  Like the Go designers ignored generics, they ignored the safer systems programming languages developed as ALGOL and PL/I variants during the 60s. https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html
xjay 5y ago
The late pioneer in compiler optimization--Frances Allen--agrees. 2006: "..but something else had happened--and that was back in 1973--[something] which I was very, very unhappy about--and that was the advent of C! It derailed, as far as I was concerned, the advances that I foresaw in compilers. One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally." "There was an interesting debate at the SIGPLAN conference in that period--about the relative need for optimization. It was put on the table that it wasn't going to be needed anymore! So. Anyway. You can have your own opinion on that, but I know I have mine, beyond a doubt that it was a huge setback for--in my opinion--languages and compilers--and the ability to deliver performance--easily--to the user." https://en.m.wikipedia.org/wiki/Frances_Allen https://en.m.wikipedia.org/wiki/Frances_Allen https://www.youtube.com/watch?v=NjoU-MjCws4&t=2450 https://www.youtube.com/watch?v=NjoU-MjCws4&t=2450
- titzer 5y ago
  She's exactly right. I'm really not sure how we came to accept the worse-is-better argument that high performance required exposing machine details into the source language, and letting compiler writers just "do whatever is fastest", regardless of safety. It gave rise to today's situation where none of application writers, library writers, kernel writers, or compiler writers are quite sure what will happen if a new optimization is introduced. Will it break programs? By how much? Well, let's roll the dice! This is a direct result of allowing--no, even expecting--programmers to peer behind the curtains to see machine details that they frankly, shouldn't. It's why porting programs from one machine to another is even a thing, as opposed to just selecting a different output from a compiler, or running a different VM. Proper abstractions define exactly what happens in every situation, and design unobservable details out. It is the basis for optimizations that fundamentally cannot observed (except side-channels, like timing and other resource usage). Proper abstractions is why we have fast processors. The ISA is a hard boundary.
- flukus 5y ago
  > One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally." Well 50 years on we still haven't seen any of these "sufficiently smart compilers", at best they can outsmart C compilers in a few cases with things like generics, so the idea that higher level languages would be faster has been wrong for at least 5 decades. At least you can forgive them for thinking they would 50 years ago, but now it's just ignoring 50 years of reality.
Koshkin 5y ago
Have been programming in C (and then C++), like, forever. Hardly any memory corruption issues. Yes, you have to be a little more disciplined and pay attention to things. Being distracted certainly does not help.
- MaxBarraclough 5y ago
  A significant fraction of major security vulnerabilities in C/C++ codebases relate to memory-management bugs.
  - secondcoming 5y ago
    How old is the code though? It's actually really hard to get modern C++ wrong
    - pjmlp 5y ago
      Assuming it gets used. https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary.pdf https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...
      - MaxBarraclough 5y ago
        I'm less optimistic. Even major C++ projects that do everything right, still have issues that would have been prevented had they used a safe language. My go-to example is Chromium.
        pjmlp 5y ago
        Agreed, I keep reaching for C++, because of the dependency many ecosystems have. Chromium is a good example actually, I bet they would rather follow the "Custom C++ libraries" and "Hardware mitigations" than the Firefox approach. https://www.chromium.org/Home/chromium-security/memory-safety https://www.chromium.org/Home/chromium-security/memory-safet... Apple did something similar recently, their iBoot firmware uses a custom safe C dialect.

emsy 5y ago

All those "orange site bad" comments lol

TeMPOraL 5y ago
Yeah, "orange site" comments on Twitter are an interesting entertainment genre in general, if you're into "a visit to the bizarro world" type of humor :).
- pwdisswordfish8 5y ago
  Blue site bad

Koshkin 5y ago

I happen to disagree, C++ is the best thing after sliced bread. (Just wanted to balance the conversation, really, with an equally meaningless, albeit honest, statement.)

jfrd 5y ago

For those who didn't click the link, this is a joke response to the author's tweet: "I am bracing for the inevitable comments about C++ being the most terrible thing since forever :("

lenkite 5y ago

C++ is amazing. Learn to Code.