Live data from Hacker News

Gradual type checking for Ruby

github.com

11–20 of 43 posts

Re: Gradual type checking for Ruby

#11

When most practitioners think of "typechecking", they typically think about proving properties about programs statically. This project seems equivalent to adding a runtime check at each call site to ensure the arguments and return values are the correct type. This is certainly useful sometimes, as it gives programs the desirable "fail fast" property. But it isn't "typechecking" as most engineers understand it. Or at…

> When most practitioners think of "typechecking", they typically think about proving properties about programs statically. This project seems equivalent to adding a runtime check at each call site to ensure the arguments and return values are the correct type.

It basically seems equivalent (albeit somewhat nicer in a few ways, ie. scalar types are supported) to PHP's "type hinting"[0]. I will say that it is useful, in combination with unit testing, as you can pick up on problems with things slightly easier than hoping for the best in production and tailing error logs, but proper static type analysis is more useful.

[0] http://php.net/manual/en/language.oop5.typehinting.php

Re: Gradual type checking for Ruby

#12

When most practitioners think of "typechecking", they typically think about proving properties about programs statically. This project seems equivalent to adding a runtime check at each call site to ensure the arguments and return values are the correct type. This is certainly useful sometimes, as it gives programs the desirable "fail fast" property. But it isn't "typechecking" as most engineers understand it. Or at…

This is kind of pedantic. What programmers think of and find useful as types and type systems is quite different from what type theorists think.

Re: Gradual type checking for Ruby

#13

When most practitioners think of "typechecking", they typically think about proving properties about programs statically. This project seems equivalent to adding a runtime check at each call site to ensure the arguments and return values are the correct type. This is certainly useful sometimes, as it gives programs the desirable "fail fast" property. But it isn't "typechecking" as most engineers understand it. Or at…

This is kind of pedantic. What programmers think of and find useful as types and type systems is quite different from what type theorists think.

I would definitely find what curryhoward described as useful, but I don't think Ruby is that language in which it should) be implemented.

That being said, sum types would be a nice addition to this library.

Re: Gradual type checking for Ruby

#14

Really cool idea! I like that you can specify a `#respond_to?` constraint instead of a class. Not sure if OP is the author, but here's some feedback: * It would be better if this didn't pollute the global namespace by defining `#typesig` in `Module` [0] -- perhaps consider refactoring that method into a module which the user may extend. Doing so would also get you out of needing to define `Module#prepend` for older v…

> Not sure if OP is the author

The OP is eduardordm, which can be found right underneath the article link. If you look on his HN profile, his GitHub name is also eduardordm.

The repo author is gogotanaka.

So, no. He's not. And the repo author is consequently unlikely to ever see your comments.

Not only are these simple checks to make, but it's extremely bad practice to scatter commentary about a project everywhere across the internet; people who only know about this project through GitHub would not see your comments either.

Re: Gradual type checking for Ruby

#15

Earlier quoted context omitted.

This is kind of pedantic. What programmers think of and find useful as types and type systems is quite different from what type theorists think.

I would definitely find what curryhoward described as useful, but I don't think Ruby is that language in which it should) be implemented. That being said, sum types would be a nice addition to this library.

> I would definitely find what curryhoward described as useful

You can get a statically-typed Ruby here: http://infraruby.com/live

It follows Java's type system (including generics with bounded wildcards) but it doesn't support Ruby reflection.

Re: Gradual type checking for Ruby

#16

When most practitioners think of "typechecking", they typically think about proving properties about programs statically. This project seems equivalent to adding a runtime check at each call site to ensure the arguments and return values are the correct type. This is certainly useful sometimes, as it gives programs the desirable "fail fast" property. But it isn't "typechecking" as most engineers understand it. Or at…

One thing we've applied on a Python(2, unfortunately, so can't go deep on the static type analysis) is enable this sort of type hinting when running our app in debug or test mode. Obviously can't catch everything, but it catches some of the sillier bugs.

Re: Gradual type checking for Ruby

#17
post #11

When most practitioners think of "typechecking", they typically think about proving properties about programs statically. This project seems equivalent to adding a runtime check at each call site to ensure the arguments and return values are the correct type. This is certainly useful sometimes, as it gives programs the desirable "fail fast" property. But it isn't "typechecking" as most engineers understand it. Or at…

> When most practitioners think of "typechecking", they typically think about proving properties about programs statically. This project seems equivalent to adding a runtime check at each call site to ensure the arguments and return values are the correct type. It basically seems equivalent (albeit somewhat nicer in a few ways, ie. scalar types are supported) to PHP's "type hinting"[0]. I will say that it is useful,…

editor support for php type hinting and phpdoc method comments goes a long way. intellij can do significant refactors and and searching. you'll get real time feedback for violating types. it's not quite the same as a explicit compile step but pretty close

Re: Gradual type checking for Ruby

#19

Why Ruby 2.0 ?

In case the question is actually "Why not 1.9.3?", it's likely because 1.9.3 is End Of Life, and doesn't even get security upgrades now:

https://www.ruby-lang.org/en/news/2014/01/10/ruby-1-9-3-will...

https://www.ruby-lang.org/en/news/2015/02/23/support-for-rub...

Post reply on HN