5 ms·

You are far from the first. Many, many years ago, I made a more embarrassing mistake. I insisted in a job interview that OCaml was dynamically typed because it

You are far from the first. Many, many years ago, I made a more embarrassing mistake. I insisted in a job interview that OCaml was dynamically typed because it didn't require explicit typing. (To my naive eye, it "looked" like a dynlang). When I realized that I was interviewing with an expert, I backed off and admitted that I was wrong, not entirely sure why but not about to argue with someone who knew the language in depth. (And, of course, I was wrong.) I still got the job. I'd actually argue that strong vs. weak is a continuum and somewhat subjective. One of my gripes with Scala is that the type system (as used in the field) isn't strong enough. It will implicitly auto-promote types in ways you might not want (i.e. List[Int] :+ String = List[Any]). It can be a strong type system, but the quality of programmers has a huge influence on your experience with Scala. If you have bad programmers who do things the Enterprise Java Way, you can quickly end up with compile-speed issues. But that's another rant. Scala's great for mid-sized projects or when the developers are strong.

xwowsersx 12y ago
Hehe, fun story. Totally agree with you about Scala. I'm hoping to do all future development in Haskell.
jimbokun 12y ago
"It will implicitly auto-promote types in ways you might not want (i.e. List[Int] :+ String = List[Any])." Wow, that seems to totally miss the point of using types to help you catch errors.
- kod 12y ago
  No, because if you then try to call an Int-specific method on an item from that List[Any], you will still get a compile time error.
  - HolyHaddock 12y ago
    Silently inferring List[Any] is like a null reference. The error that you get told about is in a different place to where the problem that you need to fix is. In this case, the static type system could have been more helpful. There have been attempts to fix this - WartRemover specifically has a Wart for any uses of Any for example.
    - kod 12y ago
      No, a compile time error is nothing at all like a runtime null pointer exception. Given that the language supports subtype polymorphism, this is exactly how the type inference should work. Any is the narrowest available supertype. If you don't like it, there's a pretty simple fix: add an explicit type ascription, which you should be doing for the return values of any methods anyway.
      - dllthomas 12y ago
        It's like a null reference in that both increase the distance between the error and the report of failure, and both have a way of working correctly. The distinction between compile time failure and runtime failure is an important one, but not the only thing going on.

xwowsersx 12y ago

Hehe, fun story. Totally agree with you about Scala. I'm hoping to do all future development in Haskell.

jimbokun 12y ago

"It will implicitly auto-promote types in ways you might not want (i.e. List[Int] :+ String = List[Any])." Wow, that seems to totally miss the point of using types to help you catch errors.

kod 12y ago
No, because if you then try to call an Int-specific method on an item from that List[Any], you will still get a compile time error.
- HolyHaddock 12y ago
  Silently inferring List[Any] is like a null reference. The error that you get told about is in a different place to where the problem that you need to fix is. In this case, the static type system could have been more helpful. There have been attempts to fix this - WartRemover specifically has a Wart for any uses of Any for example.
  - kod 12y ago
    No, a compile time error is nothing at all like a runtime null pointer exception. Given that the language supports subtype polymorphism, this is exactly how the type inference should work. Any is the narrowest available supertype. If you don't like it, there's a pretty simple fix: add an explicit type ascription, which you should be doing for the return values of any methods anyway.
    - dllthomas 12y ago
      It's like a null reference in that both increase the distance between the error and the report of failure, and both have a way of working correctly. The distinction between compile time failure and runtime failure is an important one, but not the only thing going on.