19 ms·

What to Know Before Debating Type Systems (2008)

190 points by furcyd 8y ago

jononor 8y ago
Note that the original is back up again now (at new location). Linked in first paragraph.
- sctb 8y ago
  Thanks! We've updated the link from http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-before-debating-type-systems http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-b....
- saagarjha 8y ago
  It seems like the link has been silently updated. Edit: Not quite silently, it's just that I clicked it while sctb was typing out his comment.
weinzierl 8y ago
Chris Smith - who wrote the original piece years ago - added a current prologue to the text. I think part of it is an excellent summary so I quote this part here: > If pressed for an answer, though, yes I still do believe in the central conclusions of the article. Namely: > That “static typing” and “dynamic typing” are two concepts that are fundamentally unrelated to each other, and just happen to share a word. > That “static types” are, at their core a tool for writing and maintaining computer-checked proofs about code > That “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs. > That the two are related in the way I outline: that one establishes lower bounds on correctness of code, while the other establishes upper bounds, and that questions about their real world use should come down to the possibility and effectiveness of addressing certain kinds of bugs by either computer-checked proof, or testing. EDIT: When I wrote this comment the post linked to Steve Klabnik's 'reprint' of the temporary lost original article. Currently it links to the original. The 'reprint' missed the prologue.
- draw_down 8y ago
  > ... “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs. I don't think this is a good description of dynamic typing. I'd probably go with something more like, dynamic typing is a way to defer until runtime typing aspects of the program's implementation. I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that. A car is for getting one or more people from point A to B. It also has a radio, but a car is not "for" listening to the radio.
  - naasking 8y ago
    > I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that. The summary is trying to say that that's dynamic typing's primary advantage. Any other advantage you'd care to ascribe to dynamic typing is not intrinsic to dynamic typing itself.
    - ridiculous_fish 8y ago
      The whole article seems concerned with the testability and bug-finding nature of types. But the main strength of dynamic types is the ability to defer decisions until runtime. JS isn't dynamically typed to make testing easier. JS uses dynamic types because you couldn't build the web any other way.
      - naasking 8y ago
        > But the main strength of dynamic types is the ability to defer decisions until runtime. That's not a strength. Deferring until runtime only that which must be deferred is a strength, but that's not one exhibited by dynamically typed languages. It is one that's available to statically typed languages though, like C# and now even Haskell has a deferred typing mode. > JS uses dynamic types because you couldn't build the web any other way. That's patently false. The whole engine running every browser is statically typed. There are libraries for working with the full DOM in HTML documents for Java, C# and other typed languages.
_hardwaregeek 8y ago
It's quite interesting seeing the polarization of people's opinions on type systems. I have friends who adamantly argue that static types slow them down and prevent them from adapting quickly. On the flip side I have friends who claim they cannot write code without static types and that JavaScript is unusable. When really, both styles have their value. Static types are very useful and do provide some nice safety. However, static types can also be quite annoying and force you to acquiesce to the type system. You have to learn to "speak" types, which can be very tricky. There's a joy that comes with the freedom of no static types.
- maxgiraldo 8y ago
  IMHO Javascript is "unusable" because you can mutate state (among other things). Rich Hickey has a few other arguments against static typing and OO such as names dominating semantics and "types are an anti-pattern for program maintenance and extensibility because they introduce coupling. They’re also parochial." I think he said that in his talk called "Effective Programs": https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU
  - McWobbleston 8y ago
    As much as I liked Clojure when I dabbled for a few months it didn't really fix my dislike for dynamic languages, but I imagine core.typed / spec would fix that for me if I gave it another shot I loathed dynamic typing mostly because you had to jump around code to understand what the shape of anything was, and it distracted me from the problem I'm trying to solve In ML influenced languages types actively help me plan a solution, and rarely get in my way
- kraftman 8y ago
  > I have friends who claim they cannot write code without static types and that JavaScript is unusable. What are their reasons?
  - DonaldPShimoda 8y ago
    Same problem with all dynamically-typed languages, really. It's too easy to write the wrong thing and not find out about it until you've written umpteen unit tests. This can happen due to typos, refactoring, or whatever else. Only JavaScript is worse because it's weakly typed too, so it performs implicit coercions in an effort to make your code always do something (meaning your unit tests have to be very good to really ensure your functions do what you think they do). A static type system ensures that, at the very least, all the types line up at compile-time. You find type errors much faster than with a dynamically typed language, and this can guide a much less exhausting development cycle.
mercer 8y ago
My background is php and then javascript. My first experience with 'types' was learning that apparently javascript's implicit type conversion was not normal and actually pretty bad. That made sense to me. Then I learned about explicit types via TypeScript, and that made sense to me too, although I could imagine how this could explicit typing could get in the way of my prototyping, small projects, or REPL-driven development. Now, a few years later, and having learned a bunch of new languages, both explicitly and implicitly typed, I'm mostly wondering why I'd go for anything that isn't gradually typed as an ideal approach. I get the impression that the core discussion is explicit vs implicit (correct me if I'm wrong), and I can see how in some cases enforcing explicit typing is worthwhile, but for most of the work I actually do, it seems like the best solution is something gradual and flexible. Typescript, or perhaps some (improved) version of Elixir/Erlang's Dialyzer, or Clojure's spec: flexible enough to allow for said prototyping, small projects, and REPL-driven development, but gradually rigid enough to be useful when things grow larger and more solidified.
- munificent 8y ago
  > I'm mostly wondering why I'd go for anything that isn't gradually typed as an ideal approach. In some ways, gradual or optional types give you the best of both worlds. You aren't obligated to submit to the whims of the type checker when you don't want to, but you can elect to get the safety of types where it matters. You can get the brevity of dynamic typing and the safety of static types. But, in other ways, they give you the worst of both worlds. If you have any sufficient fraction of typed code in your program, then you will feel pressure to structure even the untyped parts of your program in ways that play nice with static typing. Some API design choices are more "typable" than others, and having static types at all discourages you from some interesting API choices. In order to play nice with untyped code, most gradual and optionally typed languages are deliberately unsound. There are holes in the type system that can't be closed. That means compilers cannot rely on types for optimization purposes. You end up with the rigidity of static types and the performance of dynamic types.
  - bjourne 8y ago
    If you haven't already, you should see this paper from 2017 about sound gradual typing: https://www.cs.cornell.edu/~ross/publications/nomalive/nomalive-oopsla17-tr.pdf https://www.cs.cornell.edu/~ross/publications/nomalive/nomal... The performance and rigidity issues you mention are solvable. Although the research is pretty cutting-edge and not implemented in many programming languages yet.
ergothus 8y ago
As someone working in dynamic languages for years, I've noticed a certain trend in arguing about type systems. People will ARGUE about the benefits of compile-time checking. However, when people point to concrete benefits, they tend to point to TOOLING communication. (e.g. IDEs supplying functions/variables that provide the necessary type) during writing. Rarely do they notice these two are not the same thing. I'm not in a place to say which is objectively correct (I'm both biased and without the right kind of data), but I've seen this distinction come up time and time again. I think it's the most interesting part (also the only part that is interesting) about typing disputes.
- naasking 8y ago
  > Rarely do they notice these two are not the same thing. Types enable better tooling. That's why people mention tooling when types come up.
  - munificent 8y ago
    Static types enable better static tooling. Dynamic types enable better dynamic tooling. :) These days, most programmers are very familiar with high quality static tooling (IDEs) but less familiar with high quality dynamic tooling.
    - ridiculous_fish 8y ago
      Right on. Here's an amazing example. Pharo Smalltalk has a feature where you can find methods by giving an example of the input and output you expect. Forget how to uppercase a string? Just write: 'eureka' . 'EUREKA' and the IDE will suggest the method asUppercase. It does this by dynamically invoking all of string's methods until it finds one whose output matches!
      - naasking 8y ago
        Neat, but not generalizable because methods often have side effects. You could easily know when this search is safe in a language that types side-effects, like Haskell. So types can enhance this feature too.
dang 8y ago
Posted at least 20 times but here are the discussions: 2015: https://news.ycombinator.com/item?id=9777485 https://news.ycombinator.com/item?id=9777485 2011: https://news.ycombinator.com/item?id=2093926 https://news.ycombinator.com/item?id=2093926 2009: https://news.ycombinator.com/item?id=849726 https://news.ycombinator.com/item?id=849726 As for year, 2008 is an upper bound (https://web.archive.org/web/20080802234250/http://www.pphsg.org/cdsmith/types.html https://web.archive.org/web/20080802234250/http://www.pphsg....), so we'll put that above unless someone finds it earlier.
- ryandvm 8y ago
  Super offtopic, but I'm curious why y'all haven't taken the dev time to implement even primitive dupe detection/reposting/re-linking on HN. Writing scripts to do repetitive human tasks is sort of hacker 101 isn't it?
  - ginnungagap 8y ago
    I suppose it's because reposting is not considered an issue if some time has passed since the last submission
    - twic 8y ago
      Given that the same articles come up over and over again, and attract upvotes and comments, it seems clear that the userbase gets value out of reposts. Perhaps the HN software should turn the knob the other way, and automatically repost old links which got a lot of attention previous times.
      - platz 8y ago
        I think I'm comfortable with the minimal amount of algorithm in my news feed, and let humans drive the rest.
    - JMTQp8lwXL 8y ago
      I wonder how many of Hacker News' current users were around in pre-2012. This sort of post could be "new to them"-- they may never have thought to search for the topic, and the repost could bring new perspectives.
codr7 8y ago
I recently implemented a simple object system [0] using only closures and macros in a Lisp-dialect [1] I'm working on. One thing that struck me is how little it bothers me that objects look like functions from the outside, and that any callable value could be used in their place. It helps that the whole thing is quarantined in a separate library and that objects live in a separate namespace. And that it rests on top of a strongly typed environment. Judging a type system outside of its context based on some arbitrary check list is pretty useless from my experience. [0] https://github.com/codr7/g-fu/blob/master/v1/doc/functional_objects.md https://github.com/codr7/g-fu/blob/master/v1/doc/functional_... [1] https://github.com/codr7/g-fu/tree/master/v1 https://github.com/codr7/g-fu/tree/master/v1
apo 8y ago
> Fallacy: Dynamically typed languages provide no way to find bugs > >A common argument leveled at dynamically typed languages is that failures will occur for the customer, rather than the developer. The problem with this argument is that it very rarely occurs in reality, so it’s not very convincing. Programs written in dynamically typed languages don’t have far higher defect rates than programs written in languages like C++ and Java. Having written software for paid work in both Java (static typing) and JavaScript (dynamic typing), I agree. A statically typed language does not improve the quality of the software that gets written, assuming equal skill in both languages. The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written before the production code that makes it pass. The article doesn't mention refactoring, but this is where a static type system really shines. The ability to refactor an entire code base with confidence at the click of a button is extremely useful and the thing I miss most when using dynamically typed languages. You can get some of that with modern editors, but it's just a pale shadow of what you get with static typing.
- viraptor 8y ago
  > The kinds of bugs that get caught by a static type system are also caught by a good suite of automated This is correct in theory, but to get the same benefit you'll need to write all the tests that the static language would guarantee. That's both relying on the programmer being always correct and that they think the time writing those tests is worth it.
  - arwhatever 8y ago
    Stating typing you have to explicitly opt out of, and automated tests you have to go to quite some effort to explicitly opt into, and most teams I've been on have been quite poor at this opting in.
- duiker101 8y ago
  >The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written before the production code that makes it pass. That's not a small thing though. It's one extra thing that you just have with static typing. Not that you don't need tests but at least you will have already some bases covered. For me a big reason of why I like static types it's the ease of reading even if a developer was sloppy. I have read dynamically typed code where the same parameter can be a string or an array or an object depending on what's the weather like outside when a dev needs to call a function. This sort of confusion makes it exponentially harder to read and understand code IMHO.
jolmg 8y ago
> I give the following general definitions for strong and weak typing, at least when used as absolutes: > Strong typing: A type system that I like and feel comfortable with > Weak typing: A type system that worries me, or makes me feel uncomfortable What is he talking about? Is he trying to make a point? I always understood the difference to be mostly about implicit type conversions. I think weak-typing is also likeable.
- dllthomas 8y ago
  I think he's trying to say that "strong-typing", in practice, as used by some speakers implies a static type system. And when used by other speakers does not imply a static type system.
bartimus 8y ago
For some languages it's more about providing features for the IDE and less about providing features for the language itself. It's probably the main reason Microsoft started working on TypeScript for example.
neilwilson 8y ago
There is an argument that a static type system is a set of built in unit tests, that you can activate by adding a command word in a particular position. And that the test harness on code in a dynamic languages is a domain specific compiler. The problems come when you want to turn off specific type tests for a particular bit of code because it is deliberately bending the rules (I see this a lot in Go), or the domain specific compiler you've built isn't comprehensive in its coverage not just of lines of code, but the structural complexity of the code.

190 points by furcyd 8y ago

jononor 8y ago

Note that the original is back up again now (at new location). Linked in first paragraph.

sctb 8y ago
Thanks! We've updated the link from http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-before-debating-type-systems http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-b....
saagarjha 8y ago
It seems like the link has been silently updated. Edit: Not quite silently, it's just that I clicked it while sctb was typing out his comment.

weinzierl 8y ago

Chris Smith - who wrote the original piece years ago - added a current prologue to the text. I think part of it is an excellent summary so I quote this part here: > If pressed for an answer, though, yes I still do believe in the central conclusions of the article. Namely: > That “static typing” and “dynamic typing” are two concepts that are fundamentally unrelated to each other, and just happen to share a word. > That “static types” are, at their core a tool for writing and maintaining computer-checked proofs about code > That “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs. > That the two are related in the way I outline: that one establishes lower bounds on correctness of code, while the other establishes upper bounds, and that questions about their real world use should come down to the possibility and effectiveness of addressing certain kinds of bugs by either computer-checked proof, or testing. EDIT: When I wrote this comment the post linked to Steve Klabnik's 'reprint' of the temporary lost original article. Currently it links to the original. The 'reprint' missed the prologue.

draw_down 8y ago
> ... “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs. I don't think this is a good description of dynamic typing. I'd probably go with something more like, dynamic typing is a way to defer until runtime typing aspects of the program's implementation. I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that. A car is for getting one or more people from point A to B. It also has a radio, but a car is not "for" listening to the radio.
- naasking 8y ago
  > I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that. The summary is trying to say that that's dynamic typing's primary advantage. Any other advantage you'd care to ascribe to dynamic typing is not intrinsic to dynamic typing itself.
  - ridiculous_fish 8y ago
    The whole article seems concerned with the testability and bug-finding nature of types. But the main strength of dynamic types is the ability to defer decisions until runtime. JS isn't dynamically typed to make testing easier. JS uses dynamic types because you couldn't build the web any other way.
    - naasking 8y ago
      > But the main strength of dynamic types is the ability to defer decisions until runtime. That's not a strength. Deferring until runtime only that which must be deferred is a strength, but that's not one exhibited by dynamically typed languages. It is one that's available to statically typed languages though, like C# and now even Haskell has a deferred typing mode. > JS uses dynamic types because you couldn't build the web any other way. That's patently false. The whole engine running every browser is statically typed. There are libraries for working with the full DOM in HTML documents for Java, C# and other typed languages.

_hardwaregeek 8y ago

It's quite interesting seeing the polarization of people's opinions on type systems. I have friends who adamantly argue that static types slow them down and prevent them from adapting quickly. On the flip side I have friends who claim they cannot write code without static types and that JavaScript is unusable. When really, both styles have their value. Static types are very useful and do provide some nice safety. However, static types can also be quite annoying and force you to acquiesce to the type system. You have to learn to "speak" types, which can be very tricky. There's a joy that comes with the freedom of no static types.

maxgiraldo 8y ago
IMHO Javascript is "unusable" because you can mutate state (among other things). Rich Hickey has a few other arguments against static typing and OO such as names dominating semantics and "types are an anti-pattern for program maintenance and extensibility because they introduce coupling. They’re also parochial." I think he said that in his talk called "Effective Programs": https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU
- McWobbleston 8y ago
  As much as I liked Clojure when I dabbled for a few months it didn't really fix my dislike for dynamic languages, but I imagine core.typed / spec would fix that for me if I gave it another shot I loathed dynamic typing mostly because you had to jump around code to understand what the shape of anything was, and it distracted me from the problem I'm trying to solve In ML influenced languages types actively help me plan a solution, and rarely get in my way
kraftman 8y ago
> I have friends who claim they cannot write code without static types and that JavaScript is unusable. What are their reasons?
- DonaldPShimoda 8y ago
  Same problem with all dynamically-typed languages, really. It's too easy to write the wrong thing and not find out about it until you've written umpteen unit tests. This can happen due to typos, refactoring, or whatever else. Only JavaScript is worse because it's weakly typed too, so it performs implicit coercions in an effort to make your code always do something (meaning your unit tests have to be very good to really ensure your functions do what you think they do). A static type system ensures that, at the very least, all the types line up at compile-time. You find type errors much faster than with a dynamically typed language, and this can guide a much less exhausting development cycle.

mercer 8y ago

My background is php and then javascript. My first experience with 'types' was learning that apparently javascript's implicit type conversion was not normal and actually pretty bad. That made sense to me. Then I learned about explicit types via TypeScript, and that made sense to me too, although I could imagine how this could explicit typing could get in the way of my prototyping, small projects, or REPL-driven development. Now, a few years later, and having learned a bunch of new languages, both explicitly and implicitly typed, I'm mostly wondering why I'd go for anything that isn't gradually typed as an ideal approach. I get the impression that the core discussion is explicit vs implicit (correct me if I'm wrong), and I can see how in some cases enforcing explicit typing is worthwhile, but for most of the work I actually do, it seems like the best solution is something gradual and flexible. Typescript, or perhaps some (improved) version of Elixir/Erlang's Dialyzer, or Clojure's spec: flexible enough to allow for said prototyping, small projects, and REPL-driven development, but gradually rigid enough to be useful when things grow larger and more solidified.

munificent 8y ago
> I'm mostly wondering why I'd go for anything that isn't gradually typed as an ideal approach. In some ways, gradual or optional types give you the best of both worlds. You aren't obligated to submit to the whims of the type checker when you don't want to, but you can elect to get the safety of types where it matters. You can get the brevity of dynamic typing and the safety of static types. But, in other ways, they give you the worst of both worlds. If you have any sufficient fraction of typed code in your program, then you will feel pressure to structure even the untyped parts of your program in ways that play nice with static typing. Some API design choices are more "typable" than others, and having static types at all discourages you from some interesting API choices. In order to play nice with untyped code, most gradual and optionally typed languages are deliberately unsound. There are holes in the type system that can't be closed. That means compilers cannot rely on types for optimization purposes. You end up with the rigidity of static types and the performance of dynamic types.
- bjourne 8y ago
  If you haven't already, you should see this paper from 2017 about sound gradual typing: https://www.cs.cornell.edu/~ross/publications/nomalive/nomalive-oopsla17-tr.pdf https://www.cs.cornell.edu/~ross/publications/nomalive/nomal... The performance and rigidity issues you mention are solvable. Although the research is pretty cutting-edge and not implemented in many programming languages yet.

ergothus 8y ago

As someone working in dynamic languages for years, I've noticed a certain trend in arguing about type systems. People will ARGUE about the benefits of compile-time checking. However, when people point to concrete benefits, they tend to point to TOOLING communication. (e.g. IDEs supplying functions/variables that provide the necessary type) during writing. Rarely do they notice these two are not the same thing. I'm not in a place to say which is objectively correct (I'm both biased and without the right kind of data), but I've seen this distinction come up time and time again. I think it's the most interesting part (also the only part that is interesting) about typing disputes.

naasking 8y ago
> Rarely do they notice these two are not the same thing. Types enable better tooling. That's why people mention tooling when types come up.
- munificent 8y ago
  Static types enable better static tooling. Dynamic types enable better dynamic tooling. :) These days, most programmers are very familiar with high quality static tooling (IDEs) but less familiar with high quality dynamic tooling.
  - ridiculous_fish 8y ago
    Right on. Here's an amazing example. Pharo Smalltalk has a feature where you can find methods by giving an example of the input and output you expect. Forget how to uppercase a string? Just write: 'eureka' . 'EUREKA' and the IDE will suggest the method asUppercase. It does this by dynamically invoking all of string's methods until it finds one whose output matches!
    - naasking 8y ago
      Neat, but not generalizable because methods often have side effects. You could easily know when this search is safe in a language that types side-effects, like Haskell. So types can enhance this feature too.

dang 8y ago

Posted at least 20 times but here are the discussions: 2015: https://news.ycombinator.com/item?id=9777485 https://news.ycombinator.com/item?id=9777485 2011: https://news.ycombinator.com/item?id=2093926 https://news.ycombinator.com/item?id=2093926 2009: https://news.ycombinator.com/item?id=849726 https://news.ycombinator.com/item?id=849726 As for year, 2008 is an upper bound (https://web.archive.org/web/20080802234250/http://www.pphsg.org/cdsmith/types.html https://web.archive.org/web/20080802234250/http://www.pphsg....), so we'll put that above unless someone finds it earlier.

ryandvm 8y ago
Super offtopic, but I'm curious why y'all haven't taken the dev time to implement even primitive dupe detection/reposting/re-linking on HN. Writing scripts to do repetitive human tasks is sort of hacker 101 isn't it?
- ginnungagap 8y ago
  I suppose it's because reposting is not considered an issue if some time has passed since the last submission
  - twic 8y ago
    Given that the same articles come up over and over again, and attract upvotes and comments, it seems clear that the userbase gets value out of reposts. Perhaps the HN software should turn the knob the other way, and automatically repost old links which got a lot of attention previous times.
    - platz 8y ago
      I think I'm comfortable with the minimal amount of algorithm in my news feed, and let humans drive the rest.
  - JMTQp8lwXL 8y ago
    I wonder how many of Hacker News' current users were around in pre-2012. This sort of post could be "new to them"-- they may never have thought to search for the topic, and the repost could bring new perspectives.

codr7 8y ago

I recently implemented a simple object system [0] using only closures and macros in a Lisp-dialect [1] I'm working on. One thing that struck me is how little it bothers me that objects look like functions from the outside, and that any callable value could be used in their place. It helps that the whole thing is quarantined in a separate library and that objects live in a separate namespace. And that it rests on top of a strongly typed environment. Judging a type system outside of its context based on some arbitrary check list is pretty useless from my experience. [0] https://github.com/codr7/g-fu/blob/master/v1/doc/functional_objects.md https://github.com/codr7/g-fu/blob/master/v1/doc/functional_... [1] https://github.com/codr7/g-fu/tree/master/v1 https://github.com/codr7/g-fu/tree/master/v1

apo 8y ago

> Fallacy: Dynamically typed languages provide no way to find bugs > >A common argument leveled at dynamically typed languages is that failures will occur for the customer, rather than the developer. The problem with this argument is that it very rarely occurs in reality, so it’s not very convincing. Programs written in dynamically typed languages don’t have far higher defect rates than programs written in languages like C++ and Java. Having written software for paid work in both Java (static typing) and JavaScript (dynamic typing), I agree. A statically typed language does not improve the quality of the software that gets written, assuming equal skill in both languages. The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written before the production code that makes it pass. The article doesn't mention refactoring, but this is where a static type system really shines. The ability to refactor an entire code base with confidence at the click of a button is extremely useful and the thing I miss most when using dynamically typed languages. You can get some of that with modern editors, but it's just a pale shadow of what you get with static typing.

viraptor 8y ago
> The kinds of bugs that get caught by a static type system are also caught by a good suite of automated This is correct in theory, but to get the same benefit you'll need to write all the tests that the static language would guarantee. That's both relying on the programmer being always correct and that they think the time writing those tests is worth it.
- arwhatever 8y ago
  Stating typing you have to explicitly opt out of, and automated tests you have to go to quite some effort to explicitly opt into, and most teams I've been on have been quite poor at this opting in.
duiker101 8y ago
>The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written before the production code that makes it pass. That's not a small thing though. It's one extra thing that you just have with static typing. Not that you don't need tests but at least you will have already some bases covered. For me a big reason of why I like static types it's the ease of reading even if a developer was sloppy. I have read dynamically typed code where the same parameter can be a string or an array or an object depending on what's the weather like outside when a dev needs to call a function. This sort of confusion makes it exponentially harder to read and understand code IMHO.

jolmg 8y ago

> I give the following general definitions for strong and weak typing, at least when used as absolutes: > Strong typing: A type system that I like and feel comfortable with > Weak typing: A type system that worries me, or makes me feel uncomfortable What is he talking about? Is he trying to make a point? I always understood the difference to be mostly about implicit type conversions. I think weak-typing is also likeable.

dllthomas 8y ago
I think he's trying to say that "strong-typing", in practice, as used by some speakers implies a static type system. And when used by other speakers does not imply a static type system.

bartimus 8y ago

For some languages it's more about providing features for the IDE and less about providing features for the language itself. It's probably the main reason Microsoft started working on TypeScript for example.

neilwilson 8y ago

There is an argument that a static type system is a set of built in unit tests, that you can activate by adding a command word in a particular position. And that the test harness on code in a dynamic languages is a domain specific compiler. The problems come when you want to turn off specific type tests for a particular bit of code because it is deliberately bending the rules (I see this a lot in Go), or the domain specific compiler you've built isn't comprehensive in its coverage not just of lines of code, but the structural complexity of the code.