From: Richard Cole Date: 2005-05-31T01:30:15+09:00 Subject: Re: Intellisense and the psychology of typing Lothar Scholz wrote: >Hello Thomas, > >TA> On Fri, May 27, 2005 at 01:35:19AM +0900, andrew.queisser@hp.com wrote: > > >>>1) Intellisense is really just another crutch that does more harm than >>>good? There were a few hardcore defenders of this position but not >>>many. >>> >>> > >TA> I'm indifferent. It depends what mood I'm in as to whether it is useful >TA> or not -- and invariably I tend not to use it, if only because, being >TA> the author, I know what formal parameters most methods expect. > >Intellisense is most useful for the case where you use libraries or >modify/extend code that you don't have written (aka multi person >projects). > >Sometimes i think that the missing typeing eats up very much of the >time that is saved by being typeless as Code is much harder to read >and understand. That's why i simply can't understand people who are >against "optional" type declarations. > > Me too. Ruby is a great language and it has given birth to a really great collection of libraries, but I think that a little type information goes a long way; both in helping people who are 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? In this thread someone mentioned an example of some code containing a function that takes either an int, or a hash of strings to ints. That sounds like a case for function overloading to me, aka def do_something(a: Int): String ... def do_something(a: (String, Int) Hash): Int ... Of course everyones favorite trick it to stick Ints and Strings into the same array, which, in my book, leaves you with an Unknown Array, Unknown being the type of your good old dynamic language object on which you can call any method (possibly getting a method not defined exception). Yes, type systems and type inference is a can of worms. One argument against a little type information is that: Oh, it's too restrictive, I wrote that function to work on Ints or Strings or whatever has a plus. But beware, just because the function has apparently correct behaviour for Ints and Strings doesn't mean that it correct (or expected) behaviour for Matricies's or Hash Tables or Proxies. That's where interfaces that embody some notion of semantics come in. An interface for example might be able to make explicit what it is that is in common between a String and an Int. Crystaline program structures can take a while to form and so an advantage of allowing part of the program to go untyped is that it makes the type system more fluid in that the interfaces are implicit, and they don't get locked in due to the man hours required to create them. The other advantage of implicit interfaces is that, since they're an automatic product of what you and others have constructed, you don't miss out on them just cause they're not explicit as you would in a language like Java --- If the join of Integer and String in Java is Object, too bad, no amount of wishing is going to make it ObjectWithPlus, or if the join of HashSet and TreeSet is Set then you can't come along later and say, hey it should be CloneableSet, where as in Ruby you get all these joins (most specific generalisations) for free because they are implicit. No-one had to write them, and no-ones failure to write them makes them disappear. An example of an implicit interface is that String and Array both provide an "each" function, but there is no explicit interface in Ruby that defines this shared property. Just some documentation (and a few language shortcuts the like the for loop). 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. 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? regards, Richard. PS: Are there any Ruby to Common Lisp bridges? Just out of curiosity.