4 ms·

Yes, it is a flawed language to have a declaration and the definition are all in one place together. What other language does this aside from Ruby, Python, Perl

• fauigerzigerk 14y ago
  None of these other languages requires code to be compiled each and every time it is imported/included.
  • 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.
  • jasonzemos 14y ago
    Two words: Precompiled Headers. Once they're used programs can be designed specifically with them in mind. This gives the compiler more flexibility for code generation and inlining as well, not just for templates.
• arianvanp 14y ago
  Haskell is a great example where interface and implementation are decoupled.. typeclasses are used a lot to describe problems with similar patterns. Look at monads, monad transformers, applicatives and functors. I don't think half of them even have default implementations defined.
  • cbsmith 14y ago
    You're description of Haskell is accurate, but so often I find that encapsulation in Haskell is not all it appears to be. More often than not, you need to dig in to the implementation of the components you use.
    • arianvanp 14y ago
      I find that argument valid for functional programming languages with no type system like LISP. They promised us black box abstraction without giving us hints about what kind of data a procedure takes. but with Haskell the type system usually gives sufficient hints on what is happening within a procedure
    • deleted 14y ago
      [deleted]