Hacker News Reader

Comment by tacos | Hacker News Reader

"We find that Typed Racket’s cost of soundness is not tolerable. If applying our method to other gradual type system implementations yields similar results, then sound gradual typing is dead."

While some of the data is surprising (22x average slowdown for TypeScript dropping to 6.5% overhead when fully typed) the paper ignores the reason why people kicked and screamed for the functionality to begin with. It had nothing to do with run-time performance.

Obviously the tools will improve and you can always strip out the annotations if performance is an issue.

Reticulated Python is still an order of magnitude faster than Ruby, so obviously performance doesn't render a technology "dead."

View on HN

> the paper ignores the reason why people kicked and screamed for the functionality to begin with

No it doesn't. The explicitly talk about this in section 7: "The acceptance of Typed Racket in the commercial and open-source Racket community suggests that (some) programmers find a way around the performance bottlenecks of sound gradual typing."

> Reticulated Python is still an order of magnitude faster than Ruby

Are you suggesting that a slower variant of Python is ten times faster than Ruby? That doesn't match my experience. For what it's worth, Ruby outperforms Python in some benchmarks: http://benchmarksgame.alioth.debian.org/u64q/ruby.html

Looking at the first benchmark in the list you gave, just in-lining eval_A in the Python code (as the Ruby code does) makes the Python code competitive with the Ruby.

As usual, don't trust the Benchmarks Game; it's not nearly well enough controlled to be a useful data point.

(I do agree with your main point, though. CPython ain't that fast.)

As usual, don't trust Joshua Landau: without in-lining eval-A the Ruby code only slows from 102secs to 137secs.

As usual, Joshua -- Do the ordinary thing and report specific programs that you think should not be allowed.

For those not aware, igouy maintains the Benchmarks Game.

Nothing hidden about that --

http://benchmarksgame.alioth.debian.org/sometimes-people-jus...

How to report specific programs that you think should not be allowed --

http://benchmarksgame.alioth.debian.org/play.html#invalid

Are you referring to this paper? http://wphomes.soic.indiana.edu/jsiek/files/2014/08/retic-py...

As referenced in the paper itself, section 6.1.

For those who have not looked at the referenced paper, the last section is -- "6. Conclusions"

"…Reticulated programs perform far worse than their unchecked Python implementation…"

p10 "Design and Evaluation of Gradual Typing for Python"

And I would argue that _use-site checking_ is the easiest and obviously the slowest method to attain the stated goal. Python is already slow, this is just going to make things silly.

Using the same inference methods as Shedskin [0] along with type annotations, functional tests and property based testing can get both correctness and performance in a gradual layered manner.

This paper doesn't prove that gradual typing is broken, it shows that _use-site checking_ happens to be slow for the version of Python that they used (PyPy could very well elide the checks).

[0]

Shedskin Thesis http://mark.dufour.googlepages.com/shedskin.pdf

Iterative Flow Analysis by Plevyak http://plevyak.com/ifa-submit.pdf

Agesen's Cartesian Product http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88....

My point was simply that there is no section 6.1 in that paper, and what is in the paper does not support `tacos` claim ;-)

I'm referring to section 6.1 of the original paper which very much does exist (PDF page 11).

Not that the Ruby vs Python detour hasn't been amusing, but my core argument can and should have been better stated as: debug builds are slower than release builds and people still use them. Therefore this technology is not dead.

I see, by "in the paper itself" and "the original paper" you mean "Is Sound Gradual Typing Dead? [pdf] (neu.edu)" not the paper `sitkack` referenced.

Same problem in section 6.1 -- " “Reticulated programs perform far worse than their unchecked Python implementations” -- and nothing to support your claim that "Reticulated Python is still an order of magnitude faster than Ruby".

Reply on news.ycombinator.com