6 ms·

> As such, we can think of these languages as type safe according to the null type system I think a term like vacuously type safe is a good description of what

by freyrs3 12y ago

> As such, we can think of these languages as type safe according to the null type system I think a term like vacuously type safe is a good description of what Python/Ruby are under this set of definitions. So as to distinguish from languages where type safety actually means something slightly stronger than "all syntactically valid programs are accepted by the null type system".

vinceguidry 12y ago
I don't think it's quite right to denigrate the actual safety you get in dynamic languages by referring to their type systems as such. They are indeed safe, you won't get undefined behavior in the vein of C/C++. In fact, if they weren't such, there wouldn't any point to using them over more performant architectures. The only time as a Ruby developer I've ever encountered a segfault is when a library calls out to a C extension, the problem is fixed by switching to a different gem. I'm safe in that whenever my program fails, the bug is in something I've written. I've never found an actual bug in Ruby. Sure, I'm giving up a hell of a lot of performance for this safety, but it's more than worth it for my company's use case. In fact, I can't even imagine a form of safety you could add to Ruby that isn't a Very Hard Problem, e.g. safety from race conditions. TDD in Ruby gives you a kind of certainty about the correctness your code that is hard to get in other languages. If something breaks, just add another test.
- dragonwriter 12y ago
  > TDD in Ruby gives you a kind of certainty about the correctness your code that is hard to get in other languages. ? TDD is pretty easy in many other languages, both dynamic and static. In some ways, static type systems can enhance TDD by making testing to validate invariants that are beyond what the type system can statically verify easier, because static types can be used to generate test data automatically, so instead of specify specific tests, you specify the universally quantified invariant that must hold and the testing framework generates numerous tests. Both Haskell and Scala (and no doubt other languages) have testing frameworks that leverage the type system to allow this.
- tel 12y ago
  freyrs3 didn't say that these languages were unsafe, he said that they were vacuously type safe. The kinds of safety you mentioned do not arise from (static) typing and so, regardless of their validity, it's just not on topic.
  - vinceguidry 12y ago
    How could it not be on topic, when the article clearly said that a type system is that which programs written using it “cannot go wrong”? He then proceeded to use as examples C's lack of memory safety. With a definition that broad, you really need to examine every extant approach to solving the problem, even if you don't want to go in that direction.
    - tel 12y ago
      He starts with an intuition-bound definition then clarifies as time goes on. Ultimately "go wrong" needs to be embedded in the type system before it applies. Other things are obviously language safety features, but just are not "types" in the sense of how some languages are "type safe".
- pmahoney 12y ago
  > Sure, I'm giving up a hell of a lot of performance for this safety, but it's more than worth it for my company's use case. Surely you're not trading performance for safety, as dozens of languages are "safe" while having much higher performance over Ruby including similarly dynamic languages JavaScript and Lua, or others such as Java, Scala, Clojure, Haskell, OCaml, and so on. There are, of course, other reasons to choose Ruby, perhaps because of Rails, large talent pool, code conciseness, etc.
- freyrs3 12y ago
  You're putting words in my mouth by implying I denigrated Ruby as unsafe using a much stronger definition of safety. Ruby is type safe under the article's definitions, but I suggest that this claim doesn't carry much information content because a conclusion about the null type system is such a weak claim, like a claim about the null set.
  - vinceguidry 12y ago
    Reducing dynamic typing's safety to a null set claim is exactly the sort of denigration I'm arguing doesn't make sense. Type doesn't disappear just because you aren't encoding it as a first-class PL design concern.
    - tel 12y ago
      As usual, when freyrs3 says "type" he means something simpler and more specific than what you appear to mean. The whole idea is that "type safety" is both specific and not sufficient to mean anything valuable.
    - freyrs3 12y ago
      This discussion is just going to reduce down to a runtime tag vs formal type definition. This particular article is using the term type to mean formal type, and my comment is also under this assumption. Under that definition Ruby does have a null type system. That's not a moral judgement of it's design, it's just a fact that follows from the definitions. Rather than debate this for the gazillionth time, I'll just point you at tel's article which breaks it down very nicely: http://tel.github.io/2014/07/08/all_you_wanted_to_know_about_types_but_were_afraid_to_ask/ http://tel.github.io/2014/07/08/all_you_wanted_to_know_about...
mnarayan01 12y ago
A substantially better description would be "dynamically type safe".
- tel 12y ago
  In the context of this article that's just confusing the issue. "Type" is both well-defined and not the same as "type" in a Ruby context.
  - ionforce 12y ago
    What is type in a Ruby context?
    - tel 12y ago
      Usually in a Ruby context you'd refer to something like Fixnum or String as types when really that's their "class" irb(main):005:0> 3.class => Fixnum Such a "type" doesn't have much to do with "types" as discussed when referring to static types. They're simply orthogonal concepts.
      - mnarayan01 12y ago
        The result of the #class method does not _fully_ encapsulate an object's type (e.g. #extend, #define_singleton_method, etc may have been used to modify the object's type) but every Ruby expression does have a type in exactly the sense as used when talking about static typing; the only difference is when you can (in general) determine that type. The #class method is not orthogonal to type, it is merely incomplete.
        tel 12y ago
        Sure, but that's not really relevant. All of your "typing" occurs at runtime and thus is entwined in the language dynamics and not its statics.

by freyrs3 12y ago

vinceguidry 12y ago

I don't think it's quite right to denigrate the actual safety you get in dynamic languages by referring to their type systems as such. They are indeed safe, you won't get undefined behavior in the vein of C/C++. In fact, if they weren't such, there wouldn't any point to using them over more performant architectures. The only time as a Ruby developer I've ever encountered a segfault is when a library calls out to a C extension, the problem is fixed by switching to a different gem. I'm safe in that whenever my program fails, the bug is in something I've written. I've never found an actual bug in Ruby. Sure, I'm giving up a hell of a lot of performance for this safety, but it's more than worth it for my company's use case. In fact, I can't even imagine a form of safety you could add to Ruby that isn't a Very Hard Problem, e.g. safety from race conditions. TDD in Ruby gives you a kind of certainty about the correctness your code that is hard to get in other languages. If something breaks, just add another test.

dragonwriter 12y ago
> TDD in Ruby gives you a kind of certainty about the correctness your code that is hard to get in other languages. ? TDD is pretty easy in many other languages, both dynamic and static. In some ways, static type systems can enhance TDD by making testing to validate invariants that are beyond what the type system can statically verify easier, because static types can be used to generate test data automatically, so instead of specify specific tests, you specify the universally quantified invariant that must hold and the testing framework generates numerous tests. Both Haskell and Scala (and no doubt other languages) have testing frameworks that leverage the type system to allow this.
tel 12y ago
freyrs3 didn't say that these languages were unsafe, he said that they were vacuously type safe. The kinds of safety you mentioned do not arise from (static) typing and so, regardless of their validity, it's just not on topic.
- vinceguidry 12y ago
  How could it not be on topic, when the article clearly said that a type system is that which programs written using it “cannot go wrong”? He then proceeded to use as examples C's lack of memory safety. With a definition that broad, you really need to examine every extant approach to solving the problem, even if you don't want to go in that direction.
  - tel 12y ago
    He starts with an intuition-bound definition then clarifies as time goes on. Ultimately "go wrong" needs to be embedded in the type system before it applies. Other things are obviously language safety features, but just are not "types" in the sense of how some languages are "type safe".
pmahoney 12y ago
> Sure, I'm giving up a hell of a lot of performance for this safety, but it's more than worth it for my company's use case. Surely you're not trading performance for safety, as dozens of languages are "safe" while having much higher performance over Ruby including similarly dynamic languages JavaScript and Lua, or others such as Java, Scala, Clojure, Haskell, OCaml, and so on. There are, of course, other reasons to choose Ruby, perhaps because of Rails, large talent pool, code conciseness, etc.
freyrs3 12y ago
You're putting words in my mouth by implying I denigrated Ruby as unsafe using a much stronger definition of safety. Ruby is type safe under the article's definitions, but I suggest that this claim doesn't carry much information content because a conclusion about the null type system is such a weak claim, like a claim about the null set.
- vinceguidry 12y ago
  Reducing dynamic typing's safety to a null set claim is exactly the sort of denigration I'm arguing doesn't make sense. Type doesn't disappear just because you aren't encoding it as a first-class PL design concern.
  - tel 12y ago
    As usual, when freyrs3 says "type" he means something simpler and more specific than what you appear to mean. The whole idea is that "type safety" is both specific and not sufficient to mean anything valuable.
  - freyrs3 12y ago
    This discussion is just going to reduce down to a runtime tag vs formal type definition. This particular article is using the term type to mean formal type, and my comment is also under this assumption. Under that definition Ruby does have a null type system. That's not a moral judgement of it's design, it's just a fact that follows from the definitions. Rather than debate this for the gazillionth time, I'll just point you at tel's article which breaks it down very nicely: http://tel.github.io/2014/07/08/all_you_wanted_to_know_about_types_but_were_afraid_to_ask/ http://tel.github.io/2014/07/08/all_you_wanted_to_know_about...

mnarayan01 12y ago

A substantially better description would be "dynamically type safe".

tel 12y ago
In the context of this article that's just confusing the issue. "Type" is both well-defined and not the same as "type" in a Ruby context.
- ionforce 12y ago
  What is type in a Ruby context?
  - tel 12y ago
    Usually in a Ruby context you'd refer to something like Fixnum or String as types when really that's their "class" irb(main):005:0> 3.class => Fixnum Such a "type" doesn't have much to do with "types" as discussed when referring to static types. They're simply orthogonal concepts.
    - mnarayan01 12y ago
      The result of the #class method does not _fully_ encapsulate an object's type (e.g. #extend, #define_singleton_method, etc may have been used to modify the object's type) but every Ruby expression does have a type in exactly the sense as used when talking about static typing; the only difference is when you can (in general) determine that type. The #class method is not orthogonal to type, it is merely incomplete.
      - tel 12y ago
        Sure, but that's not really relevant. All of your "typing" occurs at runtime and thus is entwined in the language dynamics and not its statics.