10 ms·

"Refactoring a statically typed language is easier than refactoring an interpreted one; modifying existing PHP, and even Python, is a difficult chore that engin

• NickPollard 13y ago
  > The biggest thing that contributes to refactorability has nothing to do with type safety. Instead unit test coverage, by a mile, is the thing that makes code easy to refactor Type Safety is Unit Test Coverage. Typing is a statically checked test of correctness of your program. Languages like C give static typing a bad name. Types are not things like 'float', 'int', 'double'. Types are 'degrees', or 'radians'. Types are 'buy', or 'sell', 'price' or 'yield'. Types guarantee that your code executes as you expect, and prevent you from writing incorrect code in the first place. Is it 100% effective? No. But there's a reason that high level statically typed languages (Scala, Haskell, OCaml) usually work correctly after they compile.
  • brandonbloom 13y ago
    > usually work correctly after they compile I still don't buy in to this trope. Q: What is true of every single bug in production? A: It passed both your type checker and your tests.
    • NickPollard 13y ago
      That's a tautology. By that reasoning, don't bother writing any tests, because all your bugs in production will get past them anyway! My bugs got past my type-checker, but only 100 of them. You have 1000 because the 900 my type checker caught, your dynamic language didn't. Then you go and write unit tests for them, and spend a day writing code that my compiler generated automatically for me.
      • grey-area 13y ago
        If you can provide statistics on bugs being an order of magnitude higher in dynamic languages to back up your figures here, it would be a far more convincing argument. I'm sure type safety catches a few bugs and prevent some from being made, but does it catch as many as you think?
      • brandonbloom 13y ago
        > By that reasoning ... My reasoning in no way implies that. I simply said that I'm sick of this argument that "if it compiles, it works!" Nobody who knows what they are talking about actually believes that, especially not people who design and build statically typed languages!
    • chimeracoder 13y ago
      Look at it the other way. In fact, you can do a blind test. Try writing in a strongly, (well[0]) statically-typed language for a while, and count the number of times your code fails to compile due to a type error. Each of those would likely have been a runtime error in a language like Python. Just earlier today, I had to write a short Python script (I normally write Go), and I was bitten by this. I'm used to the compiler telling me up-front when I try to concatenate a string and an integer, or when I misspell a variable name. Yes, there are other ways around this (and proofreading your code before you write it is a good practice, in addition to tests). But static typing can make development much faster[1]. Even if you claim that you would have caught all of those bugs in unit/integration/system tests (which I simply don't believe - no real-world project has test coverage that's that good), it's much better to catch bugs at compile-time, because (unless you're writing C++) your tests take much longer to run than your code does to compile. [0] I qualify this to rule out C, which has weak typing as well as memory management issues to complicate things, and Java, which just has a terrible type system period. [1] In some sense this is all a moot point, because any difference in development speed and/or code correctness between statically-typed and dynamically-typed languages is dwarfed by one's familiarity with the languages in question. The only real way to test this directly would be to use a statically-typed language that allows disabling of all compile-time type checks as a compiler flag or pragma, but few languages do this in a way that'd be straightforward to do a meaningful blind test.
  • klibertp 13y ago
    > Types guarantee that your code executes as you expect, and prevent you from writing incorrect code in the first place. If you write a Rational class and implement it's + method as def +(other: Rational):Rational = new Rational(0) then no amount of static typing will save you. At least without dependent types. Static typing gives you a knowledge about what kind of object you're dealing with without the need to run the code. It's almost completely useless if the "kinds" supported in type system are as broad as 'int', but it does help quite a lot if the type system let's you differentiate between cm and inches. It still won't help you at all if you have a logic error - and this is where unit tests are valuable. Personally I find a mixture of Typed Racket and Racket with contracts and unit tests to be the right thing when it comes to producing as error-free programs as possible. I was also pleasantly surprised with Smalltalk, which has no static typing, but because it runs all the time and every piece of code becomes "live" the moment it's written you can use introspection in place of static typing with very similar benefits. Anyway, static typing is a valuable tool and one way of making software less wrong but it's important to know there are other tools and to use them all when it makes sense.
    • mercurial 13y ago
      > then no amount of static typing will save you. At least without dependent types. Sure. Static typing also doesn't help with misunderstanding requirements, or a faulty test in a recursive function. But strong typing, especially in languages where there is no such thing as a NullPointerException, does eliminate entire class of problems. On the other hand, with dynamic languages, you are often a typo away from a runtime error.
• spo81rty 13y ago
  I've only used static languages and therefore never had to make unit tests. Unit tests should exists for certain business rules, not every line of code.
  • nnq 13y ago
    ...sorry to have to ask, but this was sarcasm, right?
  • m_gol 13y ago
    Lol, never? Types won't check your whole business logic, it's irresponsible to nog write them (unless you're doing something really small).
• kasey_junk 13y ago
  Not to start a needless back and forth, but I've worked in both static and dynamic languages on projects large and small as well. I do believe that unit tests are the biggest improvement by a long stretch for re-factorability, but a good type system simply eliminates whole swaths of error cases, and modern systems don't require a lot of overhead either. Another advantage for some strongly typed languages are the complex, yet safe refactorings they enable automatically by a good IDE. This is not universal though, and is a serious downside to picking Scala over Java.
• ChikkaChiChi 13y ago
  Am I missing a big problem with dynamic typing? Wouldn't clearly defined naming conventions solve part of the problem?
  • okaram 13y ago
    They't need to be not just clearly defined but enforced; wouldn't it be cool if we could write a tool that automatically enforces them ? hmmm ... :)
• crystaln 13y ago
  Type safety dramatically reduces the number of unit tests required. Since unit tests often depend on the structure of code, that reduces the amount of rewritten and modified test code and the stability of the tests over refactors, which in turn must make refactoring easier.
  • lbarrow 13y ago
    If you write unit tests that make assertions that would be caught by a type checker, you're writing bad tests.
    • cia_plant 13y ago
      All unit test assertions can be caught by a type checker.
      • crystaln 13y ago
        Assuming you are sarcastically dismissing typed language defenses, as if people promoting typed languages have the position that tests are not necessary.
        • cia_plant 13y ago
          No, I'm simply stating the fact that there are type systems capable of encoding assertions.
      • basman 13y ago
        Your type checker catches array indexing bugs? Impressive.
        • virtualwhys 13y ago
          No, but Scala encourages FP, so when you: val fooList = List(1,2,3) fooList.map(...) you'll _never_ hit the types of bugs you're referring to. If you fooList(3), then of course you're hosed, but that's not the type checker's fault ;-)
• michaelochurch 13y ago
  My preferred language these days is Clojure, which is dynamic, but I don't agree that most errors have nothing to do with type safety. Most errors are fairly random. There isn't a pattern to them. Misspellings, misconceptions. Whether your type system catches them depends on the strength of your type system in addition to how you represent things. (Hashmaps vs. records, whether the get call on a Hashmap returns a nil value or an error when the key's not found.) A strong type system makes it likelier that errors are caught earlier. This may or may not be justified, depending on the application. For some problems, the reduced error-to-failure distance is considerable and it's a huge win.
• cgrubb 13y ago
  To put some meat on the discussion, what would be an example of a logic error which would be introduced by a refactoring?
• kailuowang 13y ago
  I worked deeply with both static and dynamic languages as well. I do feel that it's easier to refactor in scala than ruby, especially in large projects. In ruby, you have to have close to 100% test coverage because if you don't you can't have any confidence when you refactor. For example, in ruby project, even a simple delegation call needs to be tested, otherwise you may break it without knowing it when you rename the method delegated to. You don't need to write such test in a Scala project because there is no business logic in a simple delegation and the compiler will check the rename for you, actually the IDE will do the rename refactor perfectly for you. In general, some of the unit tests devs wrote in Ruby projects are not to test against business logic but to test type matching. For type related refactoring, they actually have to refactor both the code and unit tests. The dilemma here is that if you are changing your unit tests, how confident you are that they are still covering your refactor?
• frowaway001 13y ago
  > Logic errors are generally independent of type issues Eh ... what?! Is that some kind of joke? https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspon...
• nousernamesleft 13y ago
  >Over the years I've worked pretty deeply with both static (C++/Java/Scala) and dynamic languages (Python/Ruby). I simply don't agree. How did you use scala? Did you write java code in scala as most people with a C++/C#/java background do? Because that would completely explain the rest of your post. In particular, this statement: >In my experience issues of type safety are rare I've been doing pretty exploratory, "refactor the hell out of it every other day" kind of coding lately. I would literally rather not program than have had to do it in a language other than haskell. If I were to record this process, I am sure I would come up with several hundred type errors being caught over the course of a week. >The same types of bugs are going to crop up in Scala, Python, Java, or even Fortran unless you have tests to help you discover those issues. The obvious example of that being a bad assumption is that static type systems can completely eliminate unexpected NULL errors. It can eliminate "oops I used the count as the X co-ord by mistake" style errors. It can eliminate a huge class of errors that java programmers don't recognize are in fact type errors. >Logic errors are generally independent of type issues Which is why it is so nice to let the computer deal with type errors and be able to concentrate on logic errors instead of constantly having to worry about type errors manually.
  • enjo 13y ago
    >How did you use scala? Did you write java code in scala as most people with a C++/C#/java background do? Because that would completely explain the rest of your post. Nope. My issue here is that types, once defined, rarely change in any significant fashion. Refactoring is (generally) an exercise in mutation of logic, not so much the underlying types. When types do change the code that operates on them drastically changes as well. We're no longer refactoring at that point, we're re-writing and then the issues more or less disappear. >The obvious example of that being a bad assumption is that static type systems can completely eliminate unexpected NULL errors. What? In Scala it is perfectly possible to pass an uninitialized reference to a piece of code. The type checker most definitely isn't going to catch that. It can merely verify that the reference itself is of the right type. This is actually a common runtime error in those languages. >It can eliminate "oops I used the count as the X co-ord by mistake" style errors. Just as long as the count and the X co-ord are of different types. Which I'd guess isn't always the case. > It can eliminate a huge class of errors that java programmers don't recognize are in fact type errors. I will concede that static type systems do catch some errors that aren't caught by dynamic languages. My belief is that the class of errors they catch are among the most trivial, and most easily caught in testing (unit-testing or otherwise). Thus I simply don't see big gains in either runtime correctness or refactorability. Maybe slight ones, but nothing worth the loss of expression provided by more dynamic languages. This is true of even softer type systems such as Hindler-Milner (although type inference continues to improve, there might be some middle ground here to explore in the future). There is no doubt some philosophy at play here. The discussion here is much broader than refactoring alone. I for one find that giving up some formal proof about the correctness of the program is worth the freedom dynamic languages provide. I'll leave my favorite quote on the subject: "Static type checking limits programs to only expressing things that the static type system can prove are OK, as opposed to expressing things that the human programmer believes are OK. That's the source of both the expressiveness loss with statically checked languages, and the class of runtime type errors which are unique to dynamically checked languages." - Anton van Straaten
• nathanvanfleet 13y ago
  > I've long felt that type safety is largely a solution to a problem that doesn't really exist. Sure, assuming you never have to evaluate, convert, merge or do anything with that data. Then you might have some issues when you have expectations on the behaviours of those actions.