10 ms·

I'm so happy to see the pendulum swing the other way, because when JavaScript was becoming popular, and Ruby and Python had a popularity renaissance (around mid

• wiremine 9y ago
  > EJB2.0 world sucked This is the #1 reason I leaned away from static typing. Typescript and Swift have changed my mind. I now see typing as a helpful tool that can solve a lot of problems.
• enraged_camel 9y ago
  >>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments. People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.
  • 201709User 9y ago
    Yes, why do something automatically when you can do manual work!
    • icebraining 9y ago
      I think the idea is that you have to write tests anyway.
      • whyever 9y ago
        No, you don't have to write tests for invariants enforced by the type system.
        • ubernostrum 9y ago
          I think the bigger idea is that people who've never actually written serious code in a dynamically-typed language assume that people who do always write a bunch of extra unit tests to assert correct types, assert behavior on incorrect types, etc. etc., and that programs crashing due to type errors is a super frequent occurrence. None of those things are true.
          • tome 9y ago
            And yet there are dynamic language proponents in this very subthread suggesting that's exactly what everyone should do.
  • andrewaylett 9y ago
    Why would I write test-cases for something the compiler can catch for me? Yes, I need to write tests for all the correctly-typed cases, but there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case.
    • enraged_camel 9y ago
      You don't write test cases specifically to check types. Your existing cases, if they are robust and thorough, will simulate your runtime and check those for you as a side effect.
      • andrewaylett 9y ago
        My existing test cases, robust and thorough though they are, only test what happens when I feed in a correctly typed object. Because I can't write a test that exercises my code on an incorrectly typed input: the type system prevents that.
    • metaphorm 9y ago
      you're already writing the test cases to ensure correct behavior with typical input, and predictable exceptional input. putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead to writing the tests you were already writing.
      • macspoofing 9y ago
        >putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead Yes. We call that 'typing'.
        • discreteevent 9y ago
          And it takes less typing (keyboard) than the assert, and you get free documentation inline with the code!
  • dep_b 9y ago
    Well if you don't need to write that particular test you have more time writing tests that are actually useful, like validating your logic (and dare I say: more fun to write).
  • rbobrowicz 9y ago
    Personal anecdote: I worked on a small Python project some years ago and we had a type error in production despite having tests. We traced it back to a call to a third party library. It was supposed to return a list of results, and all of the test cases around it worked and always got a list back. In production however we encountered an error because if there was only one value to return, the library would not return a list of one element, as we expected, but a scalar value. So the rest of the code was expecting a list and when it encountered a scalar it blew up. You can blame it on us for having insufficient test cases, or not coding defensively enough, or not reading the source code of the library we used, or the author of the library for bad design, but ultimately, this bug would not have been possible in a statically typed language. So just saying "have test cases" is not good enough. Your test cases can be not exhaustive, but a good static type system and type checker is.
    • crdoconnor 9y ago
      >or the author of the library for bad design That's the one. That's a damned stupid decision.
      • UncleMeat 9y ago
        Yeah and a static type system refuses to let you make such a stupid decision. When interoperating with code I didn't write, knowing that the code is guaranteed to conform to some specification is valuable.
    • berdario 9y ago
      I cannot reply to cdoconnor (probably some downvotes), so I'll write here: That's the whole point: as it's often said "type checking keeps you honest" I stumbled time and time again upon badly designed libraries... With a static type system, the painfulness will be obvious and felt the first time you'll try to build your code with dynamic types, the pain might not be felt at all, until a crazy bit of code will be invoked, sometimes at the most unfortunate of times
  • cm2187 9y ago
    If you have to write a test for every line of code you write, the "chatty" argument against static typing goes away.
    • senorjazz 9y ago
      and not just that, but for every possible case for the line you can think of. Like the post above, testing the results of a function returns a list for 1 item, or many items... I see all too often, java bad, just look at how many lines you need to write to get "hello world". Who cares, the IDE generates that for you, but if you don't understand static void main as a beginner... again who cares, just put it in and ignore it until you need to understand it. Also read that dynamic languages are so productive, but they never mention you need to then write tests to detect what the compiler would catch for free. Yes good code needs tests, but the compiler IMO is a damn good built in test suite for catching many classes of errors
  • Silhouette 9y ago
    Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you. What's wrong with relying on the compiler? Bugs like that will be caught immediately by a good static type system, so you don't have to rely on your test cases to catch them for you. Relying on a test suite to verify basic properties that could be enforced automatically through a type system means you're only checking some cases instead of all cases. It also means you're cluttering your test suite with boilerplate about language mechanics instead of writing high value tests that verify the real operational behaviour of your system. There are pros and cons to static vs. dynamic typing in general, but in this particular respect, static typing is strictly more powerful, less verbose and more efficient.
  • AsyncAwait 9y ago
    Having a compiler catch this for you means having to write less test cases.
• icebraining 9y ago
  Typing in Java could be better, sure, but even with its quirks it's way better than the nothing you get with dynamic languages. I disagree; that Java was the standard example of statically typed languages is what convinced me for a long time that I didn't want anything to do with it. Having to pollute my code with all that crap, deal with a lot of dumb restrictions and still have NPEs left me with a sour taste. Only after I discovered Haskell (and more recently Idris), did I realize that static typing can actually be worthwhile.
  • mattnewton 9y ago
    Agreed, every time I had to patiently explain to javac that shockingly, my new ArrayList<T> was a List<T>, my new FooBar was a FooBar, and always would be, it drove me slowly mad. Still, I was thankful for the static types when trying to understand where this strange object came from and what it was supposed to do. I’m glad we have modern languages that have the potential to do an even better job of that without a lot of the verbosity.
    • macspoofing 9y ago
      Generics in Java have well known limitations stemming from type erasure (a design decision made to preserve backwards compatibility). Things aren't quite as dire as you made them out to be and in the general case, they work quite well.
    • nradov 9y ago
      While it may be frustrating to novice programmers, the distinction between interfaces (List) and implementation classes (ArrayList) is quite valuable, especially when dealing with huge code bases that have to be maintained over decades. Those declarations help to establish an internal design contract and clarify the developer's intent. In this particular case, a future maintenance programmer could switch from ArrayList to any other class which implements the List interface without breaking the program.
      • mattnewton 9y ago
• metaphorm 9y ago
  The type systems of Java and C/C++ are the most commonly encountered ones and by far the most widespread in industry programming (as opposed to academia/research) and they are actually awful and really add a lot of friction and inertia to developing. Being free of that kind of type system when using a language like Python really does feel like a big upgrade. There is a different problem with the more powerful and useful type systems in more modern statically typed languages though: learning curve. Haskell is dysfunctionally hard to learn and other languages do a little bit better but there's still friction in the learning curve that gets in the way of widespread adoption in projects that want to be able to hire rapidly.
  • breatheoften 9y ago
    I think Typescript is significantly easier to learn than JavaScript.
• hellofunk 9y ago
  > Thank God people are coming to their senses. There are no senses to come to. Static and dynamic typing each have their own benefits, and there are genuine tradeoffs to choosing one over the other. That we are even having this debate in 2017 shows that the world of typing is not a "solved problem" and there are still good reasons to use one over the other for various reasons.
  • macspoofing 9y ago
    >Static and dynamic typing each have their own benefits, I struggle to think of any benefits of dynamic typing on a reasonably sized code-base (e.g. 50k+ LOC).
    • hellofunk 9y ago
      > I struggle to think of any benefits of dynamic typing on a reasonably sized code-base (e.g. 50k+ LOC). And yet, it's done all the time with great results.
    • lordCarbonFiber 9y ago
      Cheap and plentiful dev talent. Grab any random guy (and at these shops it's always guys) off the street and bang you've got a python dev. There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.
      • macspoofing 9y ago
        >Grab any random guy (and at these shops it's always guys) off the street and bang you've got a python dev. I expect any programmer to be able to transfer their skillet to a new programming language - especially when we're talking about mainstream languages with a GC. >There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product. What kind of agility multiplier? Maybe it makes a difference during a hackathon where you have 24 hours to put something together or maybe if you're putting together shell scripts ... but taking something to MVP takes weeks or months - mainstream dynamic languages simply don't have any edge in development speed in those instances.
• KMag 9y ago
  I've worked with, statically typed languages, dynamically typed languages, and my day job involves a dynamically typed language with optional annotations (dynamically enforced) and static analysis tools. In my experience, the cost of static typing feels roughly constant per line of code, while the benefits of static typing feel roughly O(N log N) in lines of code or O(N) in number of cross-type interactions. These are just wild guesses based on gut feelings, but they feel about right. The constant factors are affected by individual coder preference, experience, and ability, but also specifics of thy type systems involved and the strength of type inference in the tools being used. In any case, I think often times dynamic typing proponents and static typing proponents have vastly different notions of what a large code base is, or at least the size code bases they typically use. One problem is that many code bases start out where the advantages of static typing aren't readily apparent, but re-factoring into a statically typed language is often not realistic, even/especially when a project starts groaning under its own weight. I'd love to see more mainstream use of gradual typing/optional typing/hybrid typing languages, especially something like a statically typed compiled subset of a dynamically typed interpreted language, where people could re-factor portions of their quick-and-dirty prototypes into nice statically typed libraries.
  • andybak 9y ago
    There are no large codebases - just insufficiently modular ones. :-)