4 ms·

A lot of that "baroque, redundant complexity" comes from standards committee's refusal to make things easier on programmers at the cost of any smidgen of perfor

by thras 17y ago

A lot of that "baroque, redundant complexity" comes from standards committee's refusal to make things easier on programmers at the cost of any smidgen of performance. And for certain tasks, like the highly competitive video game industry, uncompromising performance is exactly what the doctor ordered. You can always hire smarter programmers if you have to. On the other hand, it's hard to sell a game that runs or looks like crap at 60 fps.

derefr 17y ago
The complexity is "baroque" because, in modern times, we've invented ways around it. Type inference would kill half of the pain involved in C++ without sacrificing performance. Cleaning up the syntax enough that definitions could be found context-free would eliminate the need for declarations, and in most cases .h/hpp files. The complexity is redundant because they included features of C that they should have deprecated in favor of the C++ equivalents. String literals should be (const) basic_strings, and there should be no way to access stdio's horribly-easy-to-buffer-overflow machinations now that there's iostream. For that matter, boost should be adopted at a much more formal level: the default syntax for pointer variable allocation should allocate smart pointers, and one should have to go out of their way to get a dumb one. None of these things sacrifices performance; they're just artefacts of the fact that C++ wants to pretend it's still 1970 and that it's being used for systems programming in a mélange with C.
- thras 17y ago
  Type-inference is needed in C++ (and is already part of the next standard, you can enable the auto keyword with gnu gcc already). But it's needed for entirely different purposes than what scripting languages use it for: it's a feature for writing better templates. It's confusing because there are two types of type-inference (run-time and compile-time). You do lose performance with run-time type-inference, which is what most interpreted languages use. C++ already has compile-time type-inference in the form of templates. They are...complex. But they're also faster than anything similar. There's a reason that C++'s sort is usually faster than C's qsort for complex types. C++ doesn't have run-time type-inference and probably won't. The performance loss is too big to build it into the language everywhere, and unless you do that it's pretty pointless. You can tack it on with boost::any or RTTI, for example, but you'll generally find that it's not the correct decision from an engineering standpoint. Scripting languages have run-time type-inference built in everywhere -- but they do it at the cost of performance. Now, as far as the problems of C++'s dependence on C...well, you're right. It's a feature of C++'s history. If someone could come along and invest the millions of man hours required in making a performance-critical high-level language without the C-baggage (and then market it!), it would be a great thing. But that's a pipe dream. The best we're going to do on that front is Java.
  - loup-vaillant 17y ago
    Err, by "runtime type inference", you actually mean runtime type checking, right? The pipe dream you are talking about has a tiny hope of coming true here: http://www.bitc-lang.org/ http://www.bitc-lang.org/ EDIT: replying to thras, below. According to the very Wikipedia article you cited, there is no such thing as "runtime type inference". What you described as such is a way of implementing dynamic type checking: checking at runtime that the types of the various parts of an expression actually match. You should actually read your sources. So, "type checking" isn't always performed at compile time.
    - thras 17y ago
      Hmm. Check this out: http://en.wikipedia.org/wiki/Type_inference http://en.wikipedia.org/wiki/Type_inference Type checking is a little different, and refers to some safety measures done at compile time that theoretically guard against certain types of errors. Scripting languages don't do them, and don't miss out on much programming correctness as far as I can tell. Full run time type inference in C++ is about having a container of something -- let's say void pointers that just point to memory locations, and figuring out what sort of thing they're pointing at. Or similarly, you have a base-class pointer and want to figure out which derived version of the object is being pointed at.
      - lincolnq 17y ago
        I replied to you above, but I'll reply to your specific example here. Your example is really not how PL people talk about type inference. However, you're right that you wouldn't call this example type-checking either... it would probably be a fuzzier term such as "reflection" or "introspection". But certainly not type inference. Do you understand what the wikipedia article you linked is about? Because it's NOT about introspecting the type of a contained object within a container. It's about statically making proofs of the type of a variable based on its usage.
        thras 17y ago
        Sorry, but people use the term this way: http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=qrP&q=%22runtime+type+inference%22&aq=f&oq=&aqi= http://www.google.com/search?hl=en&client=firefox-a&...

by thras 17y ago

derefr 17y ago

The complexity is "baroque" because, in modern times, we've invented ways around it. Type inference would kill half of the pain involved in C++ without sacrificing performance. Cleaning up the syntax enough that definitions could be found context-free would eliminate the need for declarations, and in most cases .h/hpp files. The complexity is redundant because they included features of C that they should have deprecated in favor of the C++ equivalents. String literals should be (const) basic_strings, and there should be no way to access stdio's horribly-easy-to-buffer-overflow machinations now that there's iostream. For that matter, boost should be adopted at a much more formal level: the default syntax for pointer variable allocation should allocate smart pointers, and one should have to go out of their way to get a dumb one. None of these things sacrifices performance; they're just artefacts of the fact that C++ wants to pretend it's still 1970 and that it's being used for systems programming in a mélange with C.

thras 17y ago
Type-inference is needed in C++ (and is already part of the next standard, you can enable the auto keyword with gnu gcc already). But it's needed for entirely different purposes than what scripting languages use it for: it's a feature for writing better templates. It's confusing because there are two types of type-inference (run-time and compile-time). You do lose performance with run-time type-inference, which is what most interpreted languages use. C++ already has compile-time type-inference in the form of templates. They are...complex. But they're also faster than anything similar. There's a reason that C++'s sort is usually faster than C's qsort for complex types. C++ doesn't have run-time type-inference and probably won't. The performance loss is too big to build it into the language everywhere, and unless you do that it's pretty pointless. You can tack it on with boost::any or RTTI, for example, but you'll generally find that it's not the correct decision from an engineering standpoint. Scripting languages have run-time type-inference built in everywhere -- but they do it at the cost of performance. Now, as far as the problems of C++'s dependence on C...well, you're right. It's a feature of C++'s history. If someone could come along and invest the millions of man hours required in making a performance-critical high-level language without the C-baggage (and then market it!), it would be a great thing. But that's a pipe dream. The best we're going to do on that front is Java.
- loup-vaillant 17y ago
  Err, by "runtime type inference", you actually mean runtime type checking, right? The pipe dream you are talking about has a tiny hope of coming true here: http://www.bitc-lang.org/ http://www.bitc-lang.org/ EDIT: replying to thras, below. According to the very Wikipedia article you cited, there is no such thing as "runtime type inference". What you described as such is a way of implementing dynamic type checking: checking at runtime that the types of the various parts of an expression actually match. You should actually read your sources. So, "type checking" isn't always performed at compile time.
  - thras 17y ago
    Hmm. Check this out: http://en.wikipedia.org/wiki/Type_inference http://en.wikipedia.org/wiki/Type_inference Type checking is a little different, and refers to some safety measures done at compile time that theoretically guard against certain types of errors. Scripting languages don't do them, and don't miss out on much programming correctness as far as I can tell. Full run time type inference in C++ is about having a container of something -- let's say void pointers that just point to memory locations, and figuring out what sort of thing they're pointing at. Or similarly, you have a base-class pointer and want to figure out which derived version of the object is being pointed at.
    - lincolnq 17y ago
      I replied to you above, but I'll reply to your specific example here. Your example is really not how PL people talk about type inference. However, you're right that you wouldn't call this example type-checking either... it would probably be a fuzzier term such as "reflection" or "introspection". But certainly not type inference. Do you understand what the wikipedia article you linked is about? Because it's NOT about introspecting the type of a contained object within a container. It's about statically making proofs of the type of a variable based on its usage.
      - thras 17y ago
        Sorry, but people use the term this way: http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=qrP&q=%22runtime+type+inference%22&aq=f&oq=&aqi= http://www.google.com/search?hl=en&client=firefox-a&...