3 ms·

That's really an implementation issue, not a language issue. A C++ interpreter (http://root.cern.ch/drupal/content/cint http://root.cern.ch/drupal/content/cint)

by cbsmith 14y ago

That's really an implementation issue, not a language issue. A C++ interpreter (http://root.cern.ch/drupal/content/cint http://root.cern.ch/drupal/content/cint) for example, doesn't process the includes any more than most of these others. Most modern C++ compilers of course have to parse the file, but do not actually compile code unless it is used. The more sophisticated ones can usually cleverly avoid even parsing a file a second time. Technically most of those languages some degree of processing of those import/includes. Much to my chagrin Python actually evaluates the entire file, as does Perl, Ruby, PHP & JavaScript. Java, Haskell and C# (and I guess now VB) do their static type checking (often very efficiently because the type information is cached or at least already byte compiled), and Lua does a fair bit of processing as well. Smalltalk is image based, so it's kind of a very different context, but it probably could make the best case for "not having to process every time a module is imported/included", because code is loaded in to a global symbol table once, and most implementations wait until message dispatch to resolve things further. In general, I'd say the nature of your concern is more about long compile times, and C++ definitely is "impressive" in that regard. Some of that problem lies within the language's idiosyncrasies (sticking with the legacy C linker being a big one), but a lot of it is simply that it tries to resolve so much at compile time rather than run time. While not always desirable, I think there is definitely a place for tool like that.

fauigerzigerk 14y ago
Yes, compile times are my main concern. It is an implementation issue, just like the fact that humans die. It doesn't have to be that way, does it? :-) The other concern is that you have to first find and then change code in two locations most of the time. On top of that, function signatures in the header are different than those in the implementation file, so you can't just copy them. This last issue is a language issue and it is utterly ridiculous. There is no sane reason why you're not allowed to leave virtual, static or parameter default values in the code when you copy it into the implementation file. [Edit] One more thing: If a language is designed in a way that makes it practically impossible to create a fast implementation, that is a language issue in my view. Doesn't mean that such a language has no place. It does and I'm using it.

by cbsmith 14y ago

fauigerzigerk 14y ago

Yes, compile times are my main concern. It is an implementation issue, just like the fact that humans die. It doesn't have to be that way, does it? :-) The other concern is that you have to first find and then change code in two locations most of the time. On top of that, function signatures in the header are different than those in the implementation file, so you can't just copy them. This last issue is a language issue and it is utterly ridiculous. There is no sane reason why you're not allowed to leave virtual, static or parameter default values in the code when you copy it into the implementation file. [Edit] One more thing: If a language is designed in a way that makes it practically impossible to create a fast implementation, that is a language issue in my view. Doesn't mean that such a language has no place. It does and I'm using it.