Does anyone know of any empirical evidence for the value of types? Or is it a myth that we invented to rationalize the typing needed to improve the compiler's performance?
Peter Norvig's book "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp", 1992, Morgan Kaufman Publishers Inc. comes out strongly in favour of type-declarations, citing a case on page 318 where various hints to the compiler give a 40x speedup, so I see no need to rationalize.
I do believe that types lead to better compiler output -- I agree, no need to rationalize that. The "value" that I'm questioning is that types lead to more bug-free code, that types "catch errors at compile time." That claim seems untested yet, and I'm not even sure where it came from. Is it a rationalization, e.g., "Well, we have to have types to make the code better -- let's claim that it's good for the programmer to use types! Improves their thinking, let's say!" Well, maybe...
Mark
-------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
On Fri, 28 Jan 2000, Mark Guzdial wrote:
I do believe that types lead to better compiler output -- I agree, no need to rationalize that. The "value" that I'm questioning is that types lead to more bug-free code, that types "catch errors at compile time." That claim seems untested yet, and I'm not even sure where it came from. Is it a rationalization, e.g., "Well, we have to have types to make the code better -- let's claim that it's good for the programmer to use types! Improves their thinking, let's say!" Well, maybe...
I was just thinking about this today while talking to someone about Squeak (something I mentioned I was excited about) and Eiffel (something he was excited about). That discussion reminded me of Dylan, which I hadn't thought about in months. I pulled up the website for Gwydion Dylan (a free implementation originally from CMU) and found this:
http://www.gwydiondylan.org/about-dylan.phtml
"...Efficiency and flexibility. Dylan can be used as a dynamic prototyping language (like SmallTalk) or an efficient compiled language. Functional Developer, Functional Objects' Dylan compiler generates code as good as that of most C compilers, but still provides an interactive prototyping environment like those found in SmallTalk or Tcl/Tk..."
The rest of the page is also worth reading if you're at all interested in hearing about a language which tried to one-up Smalltalk (and might have succeeded if it hadn't come so late to the game and been abandoned by its original inventor, Apple [ironic, considering Squeak's origins!]). But the reason I mention it here is the idea that you can run Dylan in two modes: a dynamic, interactive, prototyping mode for development, and an efficiently compiled, static mode for delivery. Now for the $400,000 question: how difficult would it be to add that sort of capability to Squeak? :)
-Jake
At 8:59 -0500 1/28/2000, Mark Guzdial wrote:
Does anyone know of any empirical evidence for the value of types? Or is it a myth that we invented to rationalize the typing needed to improve the compiler's performance?
Peter Norvig's book "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp", 1992, Morgan Kaufman Publishers Inc. comes out strongly in favour of type-declarations, citing a case on page 318 where various hints to the compiler give a 40x speedup, so I see no need to rationalize.
I do believe that types lead to better compiler output -- I agree, no need to rationalize that. The "value" that I'm questioning is that types lead to more bug-free code, that types "catch errors at compile time." That claim seems untested yet, and I'm not even sure where it came from. Is it a rationalization, e.g., "Well, we have to have types to make the code better -- let's claim that it's good for the programmer to use types! Improves their thinking, let's say!" Well, maybe...
Mark
Mark (and others):
I agree that types lead to better compiler output, but SELF showed that that doesn't mean the programmer has to *write* those types (nor actually write those classes either).
I believe that types came from having to know what went into a memory slot, just like in assembler. Early languages, like FORTRAN for which the first real compiler was built, concentrated on making it simpler to write logic. Obviously, a memory location had to have a 'type' since the compiler had to know what instructions to generate to implement the logic.
Most everyone since has grown up with languages that have types, and consider them how god intended programs to be. (This list is populated by a fair number of exceptions!) Certainly languages that interface more directly with hardware (like C) need types, but languages where we want to get some real work done (like in Squeak) don't need types.
(Jean Sammet's 1969 book Programming Languages surveys virtually all high level languages prior to 1969; it's quite interesting to read about those early languages and how hard it was for the authors to get even simple things right.)
However, programs don't just sit there statically. Programs run. Type checking is static.
Smalltalk doesn't even have types if one uses the standard dictionary definition of type; Smalltalk has classes which are quite a different thing. But Smalltalk does not require that an instance of a specific class be passed or assigned, nor does it require an instance of one of its subclasses be used as the only alternatives.
Smalltalk allows, and programmers pass, any kind of instance which has enough of the right protocol that it won't fail. If a passed object is sent #nextPut:, #nextPutAll:, and #cr, then anything that responds to these three messages is OK to pass.
This isn't some kind of evil to be eradicated, but a true language feature unavailable in most other languages. Look around in Squeak; how often is, say, a stream passed and how often are these streams related only by their protocol?
So is this set of messages the 'type' of the parameter? It seems to me that it's these messages sent to an object in a context that matter. What do we gain by specifying them?
Dave
"Types are static; programs are dynamic." _______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.
"David N. Smith (IBM)" wrote:
However, programs don't just sit there statically. Programs run. Type checking is static.
Smalltalk doesn't even have types if one uses the standard dictionary definition of type; Smalltalk has classes which are quite a different thing. But Smalltalk does not require that an instance of a specific class be passed or assigned, nor does it require an instance of one of its subclasses be used as the only alternatives.
Smalltalk allows, and programmers pass, any kind of instance which has enough of the right protocol that it won't fail. If a passed object is sent #nextPut:, #nextPutAll:, and #cr, then anything that responds to these three messages is OK to pass.
This isn't some kind of evil to be eradicated, but a true language feature unavailable in most other languages. Look around in Squeak; how often is, say, a stream passed and how often are these streams related only by their protocol?
So is this set of messages the 'type' of the parameter? It seems to me that it's these messages sent to an object in a context that matter. What do we gain by specifying them?
I'm not sure yet about what is gained, but I have been building a system that extracts information about inter-object interfaces.
The primary objective I had was to enhance programmer understanding. I think it has some value along those lines. Basically, its another view of the code which has it's own properties, values, and drawbacks. If a compiler can also make use of this information, great. Same goes for a testing framework, or perhaps for distributed systems that need IDL-like information, or systems that need access to capability-like information ( I'm not very familiar with capabilities, so perhaps not ).
One early observation: "typeless" Smalltalk quite often seems to be remarkably well typed- it's just that we haven't had the mechanisms available to prove it.
I would agree with you that these things are not types, and we should be careful in talking about them to avoid confusing them with types. For instance, what I'm doing would be better described as an attempt at "interface extraction", and almost certainly is not "type inference".
-les
On Sat, Jan 29, 2000 at 02:21:04PM -0500, David N. Smith IBM" wrote: [deletia]
Mark (and others):
I agree that types lead to better compiler output, but SELF showed that that doesn't mean the programmer has to *write* those types (nor actually write those classes either).
Hmmm. I somewhat disagree with your assertion that types lead to better compiled code. It may be true in object-oriented languages but with low-level procedural languages (e.g. C), types mean that the compiler often has to generate extra code to preserve the type restrictions. For example, if a processor has 32-bit registers and a the compiler implements a 16-bit short type, the compiler has to make sure that the results of short arithmetic are truncated down to 16 bits after each arithmetic operation. If C didn't have types--just had register-sized variables that you could treat however you wanted--the code generated would be more efficient, at least on a mediocre compiler.
Types are a big win in C because they help the compiler catch stupid but fatal errors (e.g. "foo = NULL;" vs. "*foo=NULL;").
Errors like the above are quite serious in C and tend to either a) crash the program or machine, b) alter some arbitrary piece of memory that causes a crash later or produces incorrect results or c) work fine until you make an innocuous change elsewhere.
In contrast, a similar sort of error in Smalltalk brings up the debugger and it's almost always blazingly obvious what the problem is.
That is, the consequence of typing violations are far less severe in Smalltalk (and presumably other safe, dynamic languages) than in C, assembly language or other low-level languages.
I don't think strong typing should be evaluated in a vacuum.
However, programs don't just sit there statically. Programs run. Type checking is static.
Smalltalk doesn't even have types if one uses the standard dictionary definition of type; Smalltalk has classes which are quite a different thing. But Smalltalk does not require that an instance of a specific class be passed or assigned, nor does it require an instance of one of its subclasses be used as the only alternatives.
Smalltalk allows, and programmers pass, any kind of instance which has enough of the right protocol that it won't fail. If a passed object is sent #nextPut:, #nextPutAll:, and #cr, then anything that responds to these three messages is OK to pass.
In other words, Smalltalk objects have types but the variables don't.
For a good example of a safe but truly typeless language, try Tcl. In Tcl, everything is a string. This is flexible but the language doesn't "know" the type of anything and so rarely is able to do any of those automatic type-specific things most other languages do (e.g. automatically formatting output in a "correct" manner).
This isn't some kind of evil to be eradicated, but a true language feature unavailable in most other languages. Look around in Squeak; how often is, say, a stream passed and how often are these streams related only by their protocol?
The proof of this can be seen in how strongly-typed languages try to implement this sort of behaviour. (Templates, anyone?)
--Chris
Does anyone know of any empirical evidence for the value of types? Or is it a myth that we invented to rationalize the typing needed to improve the compiler's performance?
My problem with static type checking is that the types in most languages are not first class. You cannot store them in datatypes or pass them as arguments to functions, for example. Type signature information that could potentially be useful to a programmer is thrown away by the compiler.
I also do not like inputting code that doesn't *DO* anything.
Static type-checking is not good for rapid prototyping of applications. It is more suitable for problem domains where the problem is well understood. I like the idea that Dylan and Cecil have of making static type-checking optional.
I grew up programming in Algol-W on old IBM Mainframes in college. I hated Algol. All the type-checking seemed to do was make programming more of a chore.
In Smalltalk, at least, types are first class and can be computed with.
I hope that the type-specifying language eventually employed in Squeak will also be expressive and that abstract type-relations will be supported.
==Joe Blask==
squeak-dev@lists.squeakfoundation.org
-
Chris Reuter -
David N. Smith (IBM) -
Jake Hamby -
Joe Blask -
Les Tyrrell -
Mark Guzdial