8 ms·

Part of how C++ is successful is that it retains C compatibility, and C accurately models how the computer actually works (at least computers of the 70s and 80

• amalcon 17y ago
  C is a portable assembler. Sometimes that's exactly what you want. C++ is C, except that it doesn't completely suck for higher-level projects.
  • seiji 17y ago
    LLVM IR [1] is portable assembler. C is "portable" in the sense that: a.) you get direct access to your linear address space b.) gcc targets so many instruction sets that you don't have to worry about your backend unless you have a custom platform. C++ is the thing that screams "__gxx_personality_v0" at me because I always start off using gcc instead of g++. [1]: http://llvm.org/docs/LangRef.html http://llvm.org/docs/LangRef.html
    • jacquesm 17y ago
      Calling C portable assembler is not to be taken literally, but in context of its usage, which was for the most part systems level stuff that previously would have been written in assembler, requiring expensive ports between platforms. C changed that dramatically and helped to cut down on porting effort tremendously.
  • varjag 17y ago
    I would say C++ is somewhat less portable assembler than C, due to different linker semantics, which is not unified across platforms.
• raganwald 17y ago
  Bjarne was truly correct when he said: "there are languages people complain about, and there are languages nobody uses." I think this is very true, what it says literally is that popularity and attracting ire are correlated. However, my interpretation is that the reason why this is true is that (1) all languages involve design trade-offs, (2) every trade-off pisses someone off for at least a moment, and (3) popularity attracts eyeballs, therefore more popular languages have more people pissed off. I am not suggesting you say this, but I have heard the (strawman?) argument that it is possible to design a nice, pure language that is above reproach but that it can't be popular, and thus his quote expresses the thought that there is an inverse relationship between elegance and popularity. I don't think this is the case.
  • Periodic 17y ago
    My first impression of the quote is that any language that gains enough users will find people who complain about it. However, I agree that his main point is more that you will never be able to design a language that is useful to a large number of people without making compromises, and with any compromise there will be at least one person for which it is not the optimal solution. I don't want to say the relationship between elegance and popularity is strict though. There is simply a good correlation.
    • deleted 17y ago
      [deleted]
• slpsys 17y ago
  Siebel mentions this point, off-handedly, in covering Guy Steele's take, and yeah, I agree.
• dschobel 17y ago
  I think C models how the computer works a lot more closely than C++ (and no one would argue that C isn't carrying water out in the engineering world even today). IMO C++'s issue is precisely that it layers all of these leaky abstractions on top of the strict procedural model of C. For my money, developers are better off knowing two tools (c + some very high level language) rather than the spork which is C++.
  • jacquesm 17y ago
    I remember 'cfront', when it first came out, and to this day I haven't really changed my mind on how I felt about it, it's a much too bloated language compared to the elegance of C. If 'C' would have had a decent native string type I think C++ might not have happened ;)
    • aminuit 17y ago
      Are you suggesting that std::string, or as my not-so-friendly c++ compiler likes to call it std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>] is an improvement? :-)
      • jacquesm 17y ago
        No, not at all. I was thinking of strings the way Dennis Ritchie would have done it. I can see why they chose to omit it, but in retrospect I think it was a mistake. The problem they were faced with was that the language didn't include any 'runtime' at all the way they wrote it, a string package would have made it a must to have some runtime. Everything that is 'runtime' in C is in libraries, and everything that is 'core' is in the compiler.
      • fauigerzigerk 17y ago
        That's not what your compiler calls the string class. That's what it calls one particular constructor of the string class. This constructor lets you customize the way the string class allocates memory. Now I would like to see the equivalent constructor in your favorite language :)
• loup-vaillant 17y ago
  I totally agree. C++ main strength lies in its "portable assembler" nature. However, C++ also is [quite a behemoth][1], while Lisp, Python and Haskell aren't so. [1]: http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/ The answer then is obvious : we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized. Then, these languages are easier and more practical.
  • mahmud 17y ago
    Lisp, Python and Haskell should never ever be separated by a mere slash; they're totally different beasts.
    • loup-vaillant 17y ago
      Sorry, of course they are. I miss-phrased my sentence. I should have said "Lisp optimized, or Python optimized or Haskell optimized", or even "lovely language(s) optimized". But I didn't start this: "Lovely languages like lisp, python, haskell" (sic).
  • coliveira 17y ago
    No, C is a portable assembler. C++ was created to add "high level" OO features to C. But the success of the effort is highly controversial, because there are differences between C and the OO model that are too difficult to overcome. I think the strategy of objective-C is much cleaner, since they better separate the concerns of "writing fast code" and "writing high level OO abstractions".
    • kingkongrevenge 17y ago
      People need fast high level OO abstractions all the time: Abstract Factory, that sort of thing. C++ is still the only game in town if you need to model something complex, as in a game or a simulation, where performance matters. I don't understand why so many people toss off one liners singing the praises of C while damning C++. C's casting and general attitude to types is evil. void* must die. Do people like mysterious segfaults? Templates error output may suck right now, but it sure beats the crap out of scratching your head in front of the debugger weeks later.
• monos 17y ago
  > C accurately models how the computer actually works i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me. so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)
  • psranga 17y ago
    The comment was probably referring to things like "copying stuff is expensive" or "function calls are expensive", not more specific details of the machine you run on. In C++ you use pointers/references to solve the first problem, and define header-only classes for the latter. Even if you weren't aware, basic use of the the standard library will clue you in.
  • jacquesm 17y ago
    But I can safely say that it is a machine that the C language models fairly precisely and that python, lisp etc will use in ways that will make it harder to predict how their constructs will interact with the machine. That's exactly the point, if your machine is anywhere near 'standard' (as in not a SIMD or something exotic) then C is as close as you can get to it without going to assembler.
    • scott_s 17y ago
      I characterize C as a portable assembly language.
      • ajross 17y ago
        Sure, portable assembly language. With, you know, named variables, type abstraction, recursive function decomposition, infix expression grammar, heirarchical flow control constructs... just a bunch of silly tricks. :) Modern developers have gotten so used to the fact that C is "low level" that they tend to forget how low really low level coding is. There's a ton of "high level" language features in every 3GL, and that includes C. The abstractive distance from machine code to a language like C or Pascal is far, far higher than it is between C and Python.
• jimbokun 17y ago
  "Part of how C++ is successful is that it retains C compatibility" I think Objective C is a better object oriented C than C++. It's simpler, makes a syntactic distinction between message passing and "traditional" C, and has a more dynamic run time. I'm surprised no one else has brought up Objective C as a better solution to the "make C object oriented" problem.
  • ilyak 17y ago
    It looks like the only platform that had production-level ObjC library was NeXT/OS X.
  • joe_the_user 17y ago
    Recently, I went from Ruby on Rails web programming to C++ w/Qt GUI programming. Using the C++ features that I choose, C++ is actually pretty fast to develop on... (I did MFC years ago and that was nasty but Rails internal code is also awful, with fifty-million separate classes just for exceptions). Aside from C compatibility, C++ also allows one to create simple structures and procedures when such simple beasts are appropriate. I currently suspect one should have either "full" object orientation plus weak typing OR weak object orientation plus strong typing. Strong typing plus full OO = Bondage and Discipline language, where the size of the code itself starts to really drag your development and debugging time down. While Ruby or Python allows compact but slow code, Java and C#, among other excesses, force one to create a full class for every two-field data-structure. Thus C++ is more compact than C# and Java and faster than Python and Ruby, winning for race for a desktop application language (oddly enough, desktop apps need a fast language because they must compensate for desktop windowing systems being more bloated and users expect more from their machine each). I'm sure Haskell or Lisp are excellent for some things but I don't think their paradigm is very compatible with GUI programming - I'd be interested if someone has a counter-example.
    • Tuna-Fish 17y ago
      I just have to nitpick here: Strong typing is always a good feature, and weak typing is always a bad one. Now, whether the types should be dynamic or static, is entirely up to the situation and what kind of system you are building.
• barrkel 17y ago
  The computer is actually has a von Neumann architecture, that is, they have code and data in the same address space. To the degree that C represents this reality, it is through exploits: e.g. buffer overflows, overwriting the stack and return address, and executing arbitrary code supplied by attackers. C itself does not represent the reality very well, since it does not lend itself to writing code that writes code at runtime.
  • jacquesm 17y ago
    > The computer is actually has a von Neumann architecture, that is, they have code and data in the same address space. The ones that do not are actually pretty rare. Most of those use the 'harvard architecture' and are DSP style machines. And then there are vector processors and SIMDs, but even those can be seen as many von Neumann machines running in lock-step.
    • barrkel 17y ago
      The (vast) majority of programmers are not programming DSP-style machines, so like I said, and I still stand by it, C doesn't map well to the full functionality of the von Neumann architecture.
• gchpaco 17y ago
  The chief problem with the idea that C "accurately models how the computer actually works", as you allude to but don't go into detail, is that modern CPUs work nothing like the CPUs that C is accustomed to. Between out of order execution, hyperthreading, caches, prefetching, pretending-to-be-uniform-memory-access-but-not-actually-being-it and concurrency the degree to which C's computer model is relevant is rapidly shrinking. We don't really have a good model for this, but that's not really a good excuse to keep writing new languages based on C.