5 ms·

This is what is plaguing the ocaml compiler and standard library. Overconservatism with respect to obscure features. For example, a patch was written to speed u

• rkangel 13y ago
  It does sound like they might have gone a bit far, but as someone who works in an industrial context, a tool that maintains backwards compatibility rigorously is of enormous benefit. The case you might have to make to upgrade the version of the tool you are using has to take into account the risks, and something that is maintaining a high level of backwards compatibility has a much lower level of risk.
  • sanderjd 13y ago
    Here are my preferences for tools, in order from most-preferred to least preferred: first, tools that have a rigorous deprecation process for breaking changes, distant second, tools that are incredibly conservative about breaking changes, pretty close third, tools that refuse to make breaking changes at all ever, astronomically distant last, tools that make breaking changes willy-nilly. I generally eventually have to re-write to use a totally different tool for either of the middle two cases, because they just can't keep up. I would much rather make changes to my use of them based on deprecations than be forced to ditch them entirely. (This is more a general statement - obviously refusing to make this datetime change isn't realistically going to push anybody away from Python.)
• throwaway7808 13y ago
  Type-safe format strings should never be mixed with plain strings, constant strings, byte strings, unicode strings, batteries strings, byte array strings, char array strings, string buffers or any other type of string supported by ocaml. Keep your types pure and never mix them with any other types. Never. And you will never have any problem. And these python developers are lunatics. It is preposterous to use 'if' condition on a Date object and expect anything good. Idiots. They should have at least written a type-safe wrapper.
  • acchow 13y ago
    I can't tell if this is sarcasm.
  • icarus127 13y ago
    Indeed, the first thing that came into my mind when reading this was "You wouldn't have this problem if the only valid type in a conditional was boolean."
    • throwaway7808 13y ago
      The first thing that came into my mind when reading this was "You are a fool of a great intelligence."
      • icarus127 13y ago
        That latter's debatable but probably not the former unfortunately.
    • frou_dh 13y ago
      It's against the grain to think this way in dynamic languages because variables don't have types, only individual values do. Ill-thought truthiness rules are the real problem. IMO every value except boolean false (and, if you insist, nil/null) should be truthy in a dynamic language.
      • dragonwriter 13y ago
        > It's against the grain to think this way in dynamic languages because variables don't have types, only individual values do. So? "The only valid type for a conditional is boolean" still works if types only apply to values. Under that principle, anything but True or False value encountered in evaluating the condition of an if statement ought to throw a TypeError, not be evaluated for truthiness. If you are expecting something else, call an explicit, use-case-appropriate function to get the right in-context truth value. (Note, I'm not saying Python should do this, I'm explaining how the logic applies to Python without any contradiction to the "variables don't have types, values do" principle.) > IMO every value except boolean false (and, if you insist, nil/null) should be truthy in a dynamic language. I think that's better than what Python does (Ruby does that by default, with nil included as false, though it is IIRC possible-but-extremely-strongly-discouraged to override the default truthiness of objects so you could have classes with falsey values), and I lean toward preferring that approach, but the idea that a dynamic language would do well to just allow True and False as the only valid (non-error-producing) values for an "if" statement is not, IMO, without some merit.
• koenigdavidmj 13y ago
  Python, to its credit, has been making changes of that level. First, True and False were just the integers 1 and 0. Then they were given special values that numerically evaluated to 1 and 0, but __str__ now emitted 'True' or 'False'. They were still global variables, though, so they could be reassigned ('True, False = False, True') and cost a dictionary lookup to use. Finally, with Python 3, they (along with None) were made keywords so that such shenanigans could be stopped.
• robinh 13y ago
  Similar issues plague Haskell. A bunch of functions have illogical names, just because that's how they've always been used. And, there's the annoying matter of Applicative not being a superclass of Monad in the language, when it mathematically should be. This should be fixed in Haskell 2014, though.