From: Austin Ziegler Date: 2005-05-31T23:01:10+09:00 Subject: Re: Intellisense and the psychology of typing On 5/31/05, Lothar Scholz wrote: > Hello Austin, >>> reading the code (perhaps in the form of facilitating IDE >>> annotations), and helping the compiler. Some RubyDocs seem to >>> have type declairations, e.g. RMagick, does anyone know off hand >>> how these come about? >> These are probably noted by hand. > Yes and a standart how these are annotated by hand is missing, so > no tool can get help from it. By the way FXRuby also has type > hints, but also with its own notation. Then perhaps one of the things you can suggest, Lothar, is what such a standard might look like, and perhaps even add some stuff to rdoc to complement this. Maybe: # :parameter bar: aString # :parameter baz: anArray or +nil+ # :returns: true if aString ... def foo(bar, baz = nil) : end This would give potential type hints to various tools. This would be complicated, of course, by the fact that what we really need to know is >> No, thank you. This is Not Ruby. This is precisely why I don't >> *want* type declarations in Ruby; it's ugly and stupid. >> Type *hints* are something else, but should be applied >> indepenently of the method declaration. > In lisp you can put a (the 'Integer 'method-argument-one) > whereever you want. Also in Python you give type hints with > statements independent of the method declaration. Right. What I want is type hints independent of the method declaration. Emphasis there: I *WANT* type hints. I have believed that they are useful for things like SOAP from the beginning. I don't, however, want anything that looks like type declarations in the method declaration. That, to me, is a step down the path toward static typing -- and that's precisely what we don't need in Ruby. That step is an important one, conceptually. If you provide people the ability to do something, they will do it. Thus, if we allow people to do: def foo(bar: String, baz: [ NilClass, Array ] = nil) : end They will. And all of the clean, easy-to-read-and-use Ruby code that we've come to love will go away. Especially the -use part, because if I want to use a StringIO object now, I'll either need to modify the library, or get the String out of the StringIO before I can use it. >> No, that's why I document what the method is supposed to do, and >> what the user is to expect. The rest of the paragraph is nonsense >> once you get to the point where you understand that this is the >> responsibility of documentation, not excessively strict type >> notations. If I have type notations, then I run into the problem >> that I have restricted users of my class and methods. If someone >> else makes something that acts just the way that I want it to, >> why shouldn't they be able to use my methods just because I was >> arrogant (stupid?) enough to restrict the method in the first >> place. > Because you want to keep a garantee about what works with with > what types. Sorry but i don't see restriction as a bad thing. It has been conclusively shown that type restrictions based on class names precisely do NOT do that in Ruby. Those restrictions, in fact, do NOT make the code more robust, and are therefore bad things. >> And who needs that explicit interface? I sure as hell don't need >> to say: >> class Foo implements EnumerableInterface; ...; end >> Sorry, but that's not Ruby. > Yes thats not ruby 1.X, not sure if it shouldn't be ruby 2.0 If > benefits outweight the problems we should try this. But i also > would like to support another syntax and something optional like > the protocol notation from SmallTalk. Then we use tools to verify > that the implements relationships are right. I am absolutely positive that this should not be Ruby 2.0. It complicates things unnecessarily. I think that we can agree that Java-style Interfaces are poor substitutes for mixins; the proposal for interfaces in Ruby are equally poor. >>> On to my second point: a little type information helps the >>> compiler. When skimming articles about optimising compilers for >>> smalltalk I keep seeing comments like: such and such an >>> optimiser couldn't infer that the inner loop operates over >>> floats, so it ran 10 times slower than the equivalent C program. >> When were these articles written? Frankly, modern compiler >> technology -- and type inferencing -- will help far more than >> type specification. > Type Inferencing is still almost impossible for far to many > situations and this will not change because it is fundamental > problem. Mmm. I'm not sure that I agree. Part of what I'm thinking here has to do with what Microsoft has done with the .NET platform and Java has done with Hotspot compiling. Programs are shipped as MSIL. There is then an initial compile phase of the MSIL to processor-specific *optimized* instructions. An implementation of Ruby 2.0 could do something similar, where long-running programs, or programs that are run often, have cached compiled versions of code that are based on type inferencing. This might be something that uses a binary other than "ruby" to run these programs, as you don't necessarily want cached compiles littering your hard drive, but these could be used to gain the benefits of type inferencing. In the use of one-off scripts, this will obviously be of no benefit, but type hints would be of little benefit in any case. Rails, Nitro, and other programs (including PDF::Writer) would benefit greatly. I've applied a similar concept in one of my demo programs for PDF::Writer. Because the hardest work is generating the PDF structure in memory, I have made it so that the TechBook interpreter can *cache* the generated structure. Once cached, the resulting PDF can be generated in an almost immeasurably short time. I won't pretend that I know how to do what I've written about above, but given that type inferencing exists and that MSIL-to-binary compiles exist, we aren't talking about something radically new. We're just talking about a natural evolution, which uses multiple runs (or long-term runs) of a program to provide continuous optimisation to the execution of a program. >>> There are times when you want to restrict the types to make the >>> program run faster, e.g. programming an FFT, but who wants to >>> leave the nice Ruby landscape and muck about in the C/C++ or >>> Java dirt? >> Those who want to make the program run faster. > I've never seen any ruby program where i didn't wished that it > would run faster. But have you wanted that at the cost of restricting its utility? If you have, then I wonder if you've really wanted that in Ruby. I'll be honest -- there are some things in PDF::Writer that would benefit from a bit of type restriction. But they are few and far between. My biggest computing cost in generating PDF documents with PDF::Writer is on the need to have transactional object support for tables and similar objects. That said, I generate the manual (which is growing toward 75+ pages with at least two dozen tables and lots of live code examples) in about 2 1/2 minutes on my 3Ghz P4. It takes about 6 minutes on my 1Ghz Transmeta CPU. Average one or two page reports that I expect people will generate take consistently fifteen seconds or less. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca