6 ms·

I do not see a double standard. There is a fundamental difference between PHP and C++. PHP was simply a bad design, needlessly ugly. In contrast, the design of

by copx 12y ago

I do not see a double standard. There is a fundamental difference between PHP and C++. PHP was simply a bad design, needlessly ugly. In contrast, the design of C++ was constrained by the goals of - Compatibility with C (and later previous C++ standards) - Zero overhead / you do not pay for what you do not use - No GC Those constrains are responsible for most of its ugliness, not poor design.

MereInterest 12y ago
I would label your third point as a subcategory of the second, as it is impossible to have a garbage collector without having some sort of overhead.
- cbsmith 12y ago
  > I would label your third point as a subcategory of the second, as it is impossible to have a garbage collector without having some sort of overhead. It's impossible to have a heap allocator without overhead. How much overhead you have depends on the design constraints and the trade offs. Particularly if you are dealing with more sophisticated constraints like memory fragmentation and other issues, a GC might actually be an easier and lower overhead way of solving the problem. More importantly, you missed the most important aspect of the second point: "you do not pay _for what you do not use_". You and copx would be surprised to know that pretty much since the standard committee started working on it, garbage collection has been something on the table for C++, but they've never been able to get a proposal that everyone was happy with. I also think that the "No GC" category is perhaps not the right name. What C++ was really about was making UDT's first class types and therefore supporting value semantics. A side effect of that is that GC isn't nearly the priority it might otherwise be.
- klodolph 12y ago
  How about we put it this way: all forms of dynamic memory management have overhead, including malloc(). The overhead for garbage collection is different from the overhead for malloc(); GC is worse some respects (latency, space usage) but better in other respects (throughput, development time). GC can be much faster than malloc() when allocating objects, depending on the GC scheme used and the heap profile, allocation savings may outweigh the cost of collection. So "No GC" is a completely separate point.
  - detrino 12y ago
    Garbage collection does not offer better throughput than manual memory management, in fact it tends to need ~6x the memory to equal it[1]. [1] http://www.cs.umass.edu/~emery/pubs/04-17.pdf http://www.cs.umass.edu/~emery/pubs/04-17.pdf
    - loup-vaillant 12y ago
      I'd be wary of that paper: of the 5 garbage collectors they have tested, only one appears to be generational. That makes me doubt they used sufficiently state of the art garbage collection.
humanrebar 12y ago
There also isn't a real alternative to C++ for many of the things it does. If you're writing an OS, JIT compiler, or a garbage collector, you're writing it in C or C++ right now. And due to frustratingly solvable problems like symbol collision, C does a terrible job of scaling to to large code bases. In contrast, there are many languages that can do the job of PHP. To be sure, there are languages that aim to challenge C++ on its home turf, but it will take a lot of time and a lot of work before you will see a relational database written in Rust (or insert your favorite C++-killer here). EDIT: spelling and grammar
- guard-of-terra 12y ago
  "C does a terrible job of scaling to to large code bases" Linux says otherwise.
  - humanrebar 12y ago
    That's partly an exception that proves the rule and partly not a typical case. Uniquely, OSs get to reserve names for themselves (like time, syscall, reboot, etc.). Third-party libraries and other code have to do funny prefixing to avoid name collisions. OSs also have relatively few source code dependencies and, when they do, they get to dictate them. There are other reasons that C doesn't scale well to large software systems. For example, C's relatively limited compile-time error checking, which leads to using conventions (especially naming conventions) to enforce good practices where tools and good typing would do the job better.
    - guard-of-terra 12y ago
      You don't need to write large software systems in C or C++. Use Java. Or decompose it into components and employ Python. But GC, VM, OS - all those TLAs can and should be written in kosher C.
    - _kst_ 12y ago
      Exceptions don't prove rules; they refute them. The actual origin of the saying is quite different: http://en.wikipedia.org/wiki/Exception_that_proves_the_rule http://en.wikipedia.org/wiki/Exception_that_proves_the_rule
_yosefk 12y ago
1. From a user's perspective it doesn't matter if it's "constraints" or "poor design". 2. Blaming C does not explain C++'s undecidable grammar, the zillion ABI incompatibilities introduced on top of C, lack of an alternative for #include coupled with features like inlining and templates making it a disaster that it never quite was in C, or many other of C++'s faults. How is PHP's grammar a worse design than C++'s? I really want to know. I think PHP's is better. 3. Source compatibility with C does nothing for the user (who could have lived with ABI compatibility just fine) and everything for Stroustrup (who managed to make his language that much more popular by an Embrace, Extend and Exterminate approach). 4. Design goals inevitably resulting in a bad language are bad design goals. If I said that I designed an electric car that electrocutes you but that's because it's compatible with an electric chair for which there's a lot of existing demand, would you then publicly defend me? 5. PHP is a child of Perl which is a child of shell, awk, sed and C. A lot of heritage there to blame as well. So? 6. PHP doesn't byte one's behind nearly as badly as C++ and that's why the double standard exists; because only a fraction of the people who try manage to ever get anything done in C++ and a large subset of these people feel entitled to be treated as an "elite". PHP programmers cannot afford to delude themselves thusly because everyone can be productive in PHP... A funny outcome, I find, given that it "should" have actually led to PHP being praised.
- waqf 12y ago
  I don't believe that C++ would have had undecidable grammar if it hadn't aimed for source compatibility with C.
  - MaulingMonkey 12y ago
    What rubs me the wrong way is that it's not even C compatible. Trying to compile a C codebase with a C++ compiler is more likely than not going to give me hundreds or thousands of conversion errors thanks to the terser casting requirements. It's a worst of both worlds situation: Neither the ability to use C code as-is nor a clean grammar. I also believe the grammar could have been made much better while maintaining C compatibility. The language design seems more like throwing stuff at the wall and rolling with whatever kind of sticks, than fully exploring the problem space. See the export keyword: implemented once, and then removed as worthless, not even bothering with the step of deprecation, at the recommendation of said implementation.
guard-of-terra 12y ago
"Compatibility with C" This is not a feature for a programmer to use to make their work easier, rather this is a hook to infect the code, spread the disease and live where other nicer things wither. C++ is like mold. Yes it is ugly, and you don't want it, precisely because this is the most efficient life form compatible with your stale food, whether you want it or not. Mold is the most popular pet people have, because it is so hard to avoid. Lice (PHP) were too, but today it was mostly eradicad thanks to better hygiene.
- detrino 12y ago
  > C++ is like mold. Yes it is ugly, and you don't want it, precisely because this is the most efficient form for it to be able to colonize your food. Why does any mention of C++ bring out these silly metaphors that contribute nothing to the conversation?
- sjolsen 12y ago
  >This is not a feature for a programmer to use to make their work easier It makes it possible to use C definitions directly and inline with no conversion overhead or indirection. When your work is writing fast code, the ability to leverage existing fast code damned well is a feature. >C++ is like mold >you don't want it, precisely because this is the most efficient life form compatible with your stale food You don't want mold because it causes respiratory and neurological problems. C++ does not cause respiratory or neurological problems, unless you count the insanity it inherited from C like, "A character is the same thing as a byte," "A pointer is the same thing as an array" (which isn't even actually true within the language, unless you count parameter declarations), and my personal favourite, "The mathematical value of false, the cardinality of the empty set, and the identity of nothing are all the same thing. After all, they have the same representation!"
  - loup-vaillant 12y ago
    > [Compatibility with C] makes it possible to use C definitions directly and inline with no conversion overhead or indirection. When your work is writing fast code, the ability to leverage existing fast code damned well is a feature. That is achieved with ABI compatibility. You don't need source compatibility however. At worst, you'd have to re-write the prototype of the C function in your own syntax-incompatible language. Think of it as a zero-overhead FFI.

by copx 12y ago

MereInterest 12y ago

I would label your third point as a subcategory of the second, as it is impossible to have a garbage collector without having some sort of overhead.

cbsmith 12y ago
> I would label your third point as a subcategory of the second, as it is impossible to have a garbage collector without having some sort of overhead. It's impossible to have a heap allocator without overhead. How much overhead you have depends on the design constraints and the trade offs. Particularly if you are dealing with more sophisticated constraints like memory fragmentation and other issues, a GC might actually be an easier and lower overhead way of solving the problem. More importantly, you missed the most important aspect of the second point: "you do not pay _for what you do not use_". You and copx would be surprised to know that pretty much since the standard committee started working on it, garbage collection has been something on the table for C++, but they've never been able to get a proposal that everyone was happy with. I also think that the "No GC" category is perhaps not the right name. What C++ was really about was making UDT's first class types and therefore supporting value semantics. A side effect of that is that GC isn't nearly the priority it might otherwise be.
klodolph 12y ago
How about we put it this way: all forms of dynamic memory management have overhead, including malloc(). The overhead for garbage collection is different from the overhead for malloc(); GC is worse some respects (latency, space usage) but better in other respects (throughput, development time). GC can be much faster than malloc() when allocating objects, depending on the GC scheme used and the heap profile, allocation savings may outweigh the cost of collection. So "No GC" is a completely separate point.
- detrino 12y ago
  Garbage collection does not offer better throughput than manual memory management, in fact it tends to need ~6x the memory to equal it[1]. [1] http://www.cs.umass.edu/~emery/pubs/04-17.pdf http://www.cs.umass.edu/~emery/pubs/04-17.pdf
  - loup-vaillant 12y ago
    I'd be wary of that paper: of the 5 garbage collectors they have tested, only one appears to be generational. That makes me doubt they used sufficiently state of the art garbage collection.

humanrebar 12y ago

There also isn't a real alternative to C++ for many of the things it does. If you're writing an OS, JIT compiler, or a garbage collector, you're writing it in C or C++ right now. And due to frustratingly solvable problems like symbol collision, C does a terrible job of scaling to to large code bases. In contrast, there are many languages that can do the job of PHP. To be sure, there are languages that aim to challenge C++ on its home turf, but it will take a lot of time and a lot of work before you will see a relational database written in Rust (or insert your favorite C++-killer here). EDIT: spelling and grammar

guard-of-terra 12y ago
"C does a terrible job of scaling to to large code bases" Linux says otherwise.
- humanrebar 12y ago
  That's partly an exception that proves the rule and partly not a typical case. Uniquely, OSs get to reserve names for themselves (like time, syscall, reboot, etc.). Third-party libraries and other code have to do funny prefixing to avoid name collisions. OSs also have relatively few source code dependencies and, when they do, they get to dictate them. There are other reasons that C doesn't scale well to large software systems. For example, C's relatively limited compile-time error checking, which leads to using conventions (especially naming conventions) to enforce good practices where tools and good typing would do the job better.
  - guard-of-terra 12y ago
    You don't need to write large software systems in C or C++. Use Java. Or decompose it into components and employ Python. But GC, VM, OS - all those TLAs can and should be written in kosher C.
  - _kst_ 12y ago
    Exceptions don't prove rules; they refute them. The actual origin of the saying is quite different: http://en.wikipedia.org/wiki/Exception_that_proves_the_rule http://en.wikipedia.org/wiki/Exception_that_proves_the_rule

_yosefk 12y ago

1. From a user's perspective it doesn't matter if it's "constraints" or "poor design". 2. Blaming C does not explain C++'s undecidable grammar, the zillion ABI incompatibilities introduced on top of C, lack of an alternative for #include coupled with features like inlining and templates making it a disaster that it never quite was in C, or many other of C++'s faults. How is PHP's grammar a worse design than C++'s? I really want to know. I think PHP's is better. 3. Source compatibility with C does nothing for the user (who could have lived with ABI compatibility just fine) and everything for Stroustrup (who managed to make his language that much more popular by an Embrace, Extend and Exterminate approach). 4. Design goals inevitably resulting in a bad language are bad design goals. If I said that I designed an electric car that electrocutes you but that's because it's compatible with an electric chair for which there's a lot of existing demand, would you then publicly defend me? 5. PHP is a child of Perl which is a child of shell, awk, sed and C. A lot of heritage there to blame as well. So? 6. PHP doesn't byte one's behind nearly as badly as C++ and that's why the double standard exists; because only a fraction of the people who try manage to ever get anything done in C++ and a large subset of these people feel entitled to be treated as an "elite". PHP programmers cannot afford to delude themselves thusly because everyone can be productive in PHP... A funny outcome, I find, given that it "should" have actually led to PHP being praised.

waqf 12y ago
I don't believe that C++ would have had undecidable grammar if it hadn't aimed for source compatibility with C.
- MaulingMonkey 12y ago
  What rubs me the wrong way is that it's not even C compatible. Trying to compile a C codebase with a C++ compiler is more likely than not going to give me hundreds or thousands of conversion errors thanks to the terser casting requirements. It's a worst of both worlds situation: Neither the ability to use C code as-is nor a clean grammar. I also believe the grammar could have been made much better while maintaining C compatibility. The language design seems more like throwing stuff at the wall and rolling with whatever kind of sticks, than fully exploring the problem space. See the export keyword: implemented once, and then removed as worthless, not even bothering with the step of deprecation, at the recommendation of said implementation.

guard-of-terra 12y ago

"Compatibility with C" This is not a feature for a programmer to use to make their work easier, rather this is a hook to infect the code, spread the disease and live where other nicer things wither. C++ is like mold. Yes it is ugly, and you don't want it, precisely because this is the most efficient life form compatible with your stale food, whether you want it or not. Mold is the most popular pet people have, because it is so hard to avoid. Lice (PHP) were too, but today it was mostly eradicad thanks to better hygiene.

detrino 12y ago
> C++ is like mold. Yes it is ugly, and you don't want it, precisely because this is the most efficient form for it to be able to colonize your food. Why does any mention of C++ bring out these silly metaphors that contribute nothing to the conversation?
sjolsen 12y ago
>This is not a feature for a programmer to use to make their work easier It makes it possible to use C definitions directly and inline with no conversion overhead or indirection. When your work is writing fast code, the ability to leverage existing fast code damned well is a feature. >C++ is like mold >you don't want it, precisely because this is the most efficient life form compatible with your stale food You don't want mold because it causes respiratory and neurological problems. C++ does not cause respiratory or neurological problems, unless you count the insanity it inherited from C like, "A character is the same thing as a byte," "A pointer is the same thing as an array" (which isn't even actually true within the language, unless you count parameter declarations), and my personal favourite, "The mathematical value of false, the cardinality of the empty set, and the identity of nothing are all the same thing. After all, they have the same representation!"
- loup-vaillant 12y ago
  > [Compatibility with C] makes it possible to use C definitions directly and inline with no conversion overhead or indirection. When your work is writing fast code, the ability to leverage existing fast code damned well is a feature. That is achieved with ABI compatibility. You don't need source compatibility however. At worst, you'd have to re-write the prototype of the C function in your own syntax-incompatible language. Think of it as a zero-overhead FFI.