Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do We Create Type Systems In Dynamic Languages?

codethinked.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Do We Create Type Systems In Dynamic Languages?

#11

Post by rjurney »

You mean there's something wrong with writing this many times a day in Perl?

if (defined($foo) and $foo->can('bar') and $foo->bar ne '')

I really relate to the article, because I deal with Perl 5 sucking all day long. Perl 6 has types. Moose has types. I can't use either, and so I end up writing really lengthy code doing ad hoc type checks all over the place.

Types are important to have when you need them, and you would move to using more and more of them on a more mature system like twitter at this point, but I prefer that they be optional. Moose objects and Perl 6 give me that option but don't require it, and thats nice.

Does Ruby do anything like that? Thinking about Ruby for my next project.

Re: Do We Create Type Systems In Dynamic Languages?

#12

Post by martincmartin »

Groovy allows you to specify types of method parameters, return values, fields and local variables. This was needed for Java integration, but has the benefit that you get runtime checks for types. So in Ruby you might do:

def foo(mystring): assert mystring type_of? String mystring.length end

In Groovy you could just do:

def foo(String mystring) { mystring.length }

Re: Do We Create Type Systems In Dynamic Languages?

#13

Post by blasdel »

What To Know Before Debating Type Systems: http://www.pphsg.org/cdsmith/types.html

Something about type systems just inspires people to use imprecise nomenclature and logical fallacies -- If people just referred to "Type-Checking" when that's what they mean instead of using "Typing" to describe everything, they wouldn't ask stupid questions like the title of this link.

Of course dynamically type-checked languages have a type system -- you're using it every time you do any operation in the language!

Re: Do We Create Type Systems In Dynamic Languages?

#15

Post by jpedrosa »

Confusion wrote: post #10
jpedrosa wrote: post #5

I think it's just wrong to test for the type of the variable, unless it's really needed. Such checking detracts from what you are trying to accomplish and from relying on the exception backtrace to give you a clue of what went wrong when an error occurred. Also relevant is that if you are trying to pass in a new object that should work despite not being a direct descendent of a certain object, by checking for a certa…

Functions only work for a very specific set of input types. On all other inputs, something goes wrong, but that 'something' can take quite a bit of investigating to figure out. Therefore, an assertion that verifies that the input is indeed part of that specific set of input types is valuable: it catches the problem at the earliest possible moment and it pinpoints the exact problem.

For every other type of error, hah, rely on what I said then?

Re: Do We Create Type Systems In Dynamic Languages?

#16

Post by kscaldef »

> We are all fully aware that if you are doing “kind_of?” checks all over the place then you are doing it wrong.

I think the author missed the point of what Alex Payne wrote:

> There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.”

They aren't checking types because they don't understand how to write polymorphic code or something along those lines. They are checking types as runtime assertions against programming errors; precisely the set of programming errors that static types prevent.

I've done this myself, when I found that parts of our code dealing with finances was mixing exact and floating point arithmetic, leading to occasional rounding errors. I built a simple DbC system for Ruby, and added type checks going in and out of various methods. With the contracts in place, it was easy to track down the location of the errors, and they stay in place as documention / protection for the future.

Re: Do We Create Type Systems In Dynamic Languages?

#17

Post by jpedrosa »

kscaldef wrote: post #16

> We are all fully aware that if you are doing “kind_of?” checks all over the place then you are doing it wrong. I think the author missed the point of what Alex Payne wrote: > There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” They aren't checking types because they don't understand how to…

So, do you use this "DbC" in all of your Ruby code nowadays, like 95% of it, or in just where you think it's really important? And with this "DbC" do you think you could grow the Ruby code to 500,000 lines of code or more?

Re: Do We Create Type Systems In Dynamic Languages?

#18

Post by ankhmoop »

jauco wrote: post #14

Maybe. I tend to put it the other way around. Why would you need static typing if you're going to write unittests anyway.

A well-designed type system reduces the number of tests needed by allowing the programmer to enforce correctness through the type system itself.

Re: Do We Create Type Systems In Dynamic Languages?

#19

Post by jeremymcanally »

kscaldef wrote: post #16

> We are all fully aware that if you are doing “kind_of?” checks all over the place then you are doing it wrong. I think the author missed the point of what Alex Payne wrote: > There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” They aren't checking types because they don't understand how to…

If you don't know what kind of object you're receiving and how it behaves, then there's something far worse going on than a runtime check.

Even if you do those checks temporarily, I don't think they should remain there, especially in production code.

Re: Do We Create Type Systems In Dynamic Languages?

#20

Post by silentbicycle »

jeremymcanally wrote: post #19
kscaldef wrote: post #16

> We are all fully aware that if you are doing “kind_of?” checks all over the place then you are doing it wrong. I think the author missed the point of what Alex Payne wrote: > There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” They aren't checking types because they don't understand how to…

If you don't know what kind of object you're receiving and how it behaves, then there's something far worse going on than a runtime check. Even if you do those checks temporarily, I don't think they should remain there, especially in production code.

It's easy to get cocky about this if you've only worked on relatively small projects in languages like Ruby, but being so cavalier with larger codebases will blow up in your face. Yes, code should be well-factored, but it isn't, so be careful.

I think type checks should absolutely remain in production code. (If you're considering removing them for efficiency purposes, measure if it matters.) The ambiguity that tends to creep in and cause nasty bugs isn't "is this a polygon or a string?" (I mean, duh), but rather, stuff like, "is this measurement currently in meters or millimeters?". Working in a dynamic language and putting checks in the few places where it really matters is good enough, but it really matters. It may help to think of type assertions as comments about expectations and intent that are automatically checked.

Also, languages with type inference can be a good compromise. You get the consistency checking of static typing without having to constantly remind the compiler that it's still dealing with an int or whatever. (I like OCaml, but it's not without its flaws. It takes a while to get the hang of working with, rather than against, its incredibly thorough type checking.)

Post reply on HN