Lambda the Ultimate

Sorry I got snagged before polymorphic typing was redefined.
This seems to be a pretty good justification for using scripting languages
What does?
The anecdotal generalization that "No matter the type of application it is, you can count on finding 30 bugs per 1,000 lines of code on average."
Huh?

I prefer to spend a rainy afternoon reading this An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl

In terms of programmer productivity measured in lines of code per unit of time as well as bugs per line of code have, in practice, been more positively influenced by Test Driven Development (TDD) than they have by static type systems.

I am a fan of advanced static type systems, but I do not believe they are yet at a stage where they are ready to help the average programmer as much as a decent dynamic language + TDD has been already demonstrated.

At this point, the future seems to me to belong to dynamic languages and TDD.

BTW Isaac, have you read the Lisp follow-up to the Prechelt study by Erann Gatt? It's good reading, and is available at:

http://www.flownet.com/gat/papers/lisp-java.pdf

Personally, I like both dynamic and static languages. I'm a fan of ways that let different kinds of languages cooperate smoothly to solve problems, so that you can choose the language that best suits the problem domain and the performance constraints.

I completely agree.

I also think that not enough attention has been paid towards providing a best-of-both worlds, although some languages have tried (Curl is apparently one recent example, but I haven't used it). The ability to prototype in a dynamically typed way and gradually migrate to a more strictly-typed program, in the same language, could be very useful. I say "could" because I've not yet used a language (with a worthwhile type system) that comes close to achieving this.

Now, I think that there is some scepticism (sometimes healthy) towards these kind of empirical studies, but I for one believe that they are The Way to increase knowledge on these issues. It's just not easiest or fastest way: it's much easier just to wave one's hands vigorously. ;-)

OTOH the choice between a modern dynamic language and a modern or even advanced static type language is not nearly as clear cut. Modern dynamic languages have strong type checking on objects at run-time. The errors are caught near the lexical mistake and the system integrity is maintained.

Combine dynamic types with a Test Driven Development method and the result is a fast, felxible, and safe development technique.

I do have a feeling that one often hears people claiming something like "static typing reduces bugs". That kind of claim is far from anything that is known to be true, not least because it is a rather ambiguous claim.

One thing that's become apparent from doing TDD with Java is that refactoring of systems which are statically typed can be more efficient than doing the same with a dynamically typed system, since (a) many necessary changes throughout a system can be made automatically, with refactoring IDEs like Eclipse and IDEA; and (b) those changes that can't be made automatically, or made based on additional info supplied by the developer, are nevertheless caught early, by the compiler.

TDD with a dynamic language can't quite match this capability.

That's not to say that I think Java is a more productive language than something like, say, Python. I'm just pointing out that even with TDD, there are some benefits to static typing. I don't think I can agree that "the future ... belongs to dynamic languages and TDD".

Aside from any benefit static typing may have in reducing bugs in the final code, there's the benefit it has during development. There's a nice description of how static typing "feels" in Pierce's textbook, "Types and Programming Languages":

"In practice, static typechecking exposes a surprisingly broad range of errors. Programmers working in richly typed languages often tend to remark that their programs tend to "just work" once they pass the typechecker, much more often than they feel they have a right to expect. One possible explanation for this is that not only trivial mental slips ... but also deeper conceptual errors ... will often manifest as inconsistencies at the level of types."

Not true at all. The first and arguably still best refactoring tool is the Smalltalk Refactoring Browser from John Brant and others at UIUC.

I think that one area where scripting languages are strong is removing barriers to programming for the individual - however removing these same barriers makes it too easy to be slipshod when programming in a team because the interfaces can be treated in a gung-ho manner.

Reliable team development requires more care with module interfaces, where you have to call another programmer's code. I don't think we all know the best solutions yet (otherwise there would be no fun in talking about this issue), but stricter type-checking for public interfaces might be the solution. This can be done by enforcement at the language level, or programming by contract.

I guess this was just a confused way of saying that dynamically typed languages get parametric polymorphism "for free", which of course is true.

It's pretty meaningless to say that any kind of typing is the future.. they all have their applications.

TDD with a dynamic language can't quite match this [refactoring] capability.

Not true at all. The first and arguably still best refactoring tool is the Smalltalk Refactoring Browser from John Brant and others at UIUC.

You may well be right that the best refactoring tool in existence is one for a dynamically typed language, but Anton is certainly right in principle. Think about it: by definition, more information is statically known about statically typed programs than about dynamically typed ones. It follows that more refactoring is possible for statically typed programs.

The bottom line is that statically typed languages let the programmer express more information about a program in a form that the computer can use. It is like the case with markup languages: there is more extractable value in a marked up document than in a plain text one.

Reminds me of an old Yogi Berra saying:

• In theory there is no difference between theory and practice. In practice there is.

I am assuming that "programming for the individual" means non-CS individuals. I agree with this, although there is a big gap in languages that could maintain enough expressiveness yet tighten up the leaks that allow slipshod work.

Scheme, Smalltalk, and Ruby for example are all excellent dynamic languages. But yet they are not end-user languages. End-user languages should be more domain specific. Still there are good ways to build end-user languages using more general dynamic or static languages.

"IntelliJ have developed IDEA, which is a complete Java IDE. Actually the capabilities of this IDE go far beyond refactoring - I think they have succeeded in really moving forward the state of the art for IDEs. Suffice to say that when I use IntelliJ I almost don't miss Smalltalk any more :-)"

The presentation Eclipse for Smalltalkers gives a comparison which shows that Eclipse's refactorings are mostly a subset of Refactory's, but it has some advantages. The presentation might be interesting for anyone who wants an overview of a modern Java development tool (who hasn't already see one). The presentation closes with the following points:

• High quality semantic searching and refactoring capabilities are no longer unique to the Smalltalk world
• Smalltalk vendors should not rest on their laurels and assume that Smalltalk IDEs will always be better...

I'm not the biggest fan of Java, but I'm just pointing out that there are advantages to be had with static typing. John Lim made the important point, also borne out by the corporate success of Java, that "Reliable team development requires more care with module interfaces". I agree with his conclusion: "I don't think we all know the best solutions yet (otherwise there would be no fun in talking about this issue), but stricter type-checking for public interfaces might be the solution."

When I'm playing around with code, I almost always use a dynamically typed language as first choice, but I can't count the number of times I've wished I could annotate the code with type information that would be understood by the compiler and development tools. I think there's a lot of potential in the area of dynamically-typed languages which have type annotations, and tools that have more awareness and ability to deal with type information.

Put it this way: in many respects, the statically-typed languages have gone about as far as they can go in terms of strictness. Making them more dynamic is likely to be a challenge, since it goes against their fundamental philosophy. The dynamic languages, OTOH, have a lot of room for growth in the area of types, but done differently from the static languages. The static languages can provide some pointers, examples of things that might be useful to have, or to avoid. One of the nice-to-haves is the potential for better refactoring capabilities. Automated refactoring is very useful, better automated refactoring should be even more useful.

The last decade of research in functional language type systems can be seen as making them more dynamic. I think they're heading in the right direction. I don't know if they'll ever matter in wide-spread practice, except...

I think there's a lot of potential in the area of dynamically-typed languages which have type annotations...

This is where the money is.

I think there's a lot of potential in the area of dynamically-typed languages which have type annotations...

This is where the money is.

If so, then send your checks to the Dylan and GOO folks. They're both nice languages.

Personally, I'm more interested at the moment in statically typed languages and how we can extend them to be more expressive (MetaML, Template Haskell, etc.) while still maintaining guarantees of type safety.

If you are coding a quick hack in python/perl/etc and take 2 days to do it, and the equivalent code would take 4 days in java, then it is possible that the python/etc version is less reliable.

However if you spend 2 days coding in python, and 2 days integration/requirements testing, i think it would be more reliable than the java version, which would probably only have had some basic unit testing done on it.

So given that all other inputs are equal, it is seems reasonable that the scripting language version would be more reliable compared to a 4GL version.

Of course there is a tradeoff in ease of abstraction vs performance also.

Regards, John

All these issues, of course, are much more important for large scale programming projects than for quick hacks.

You may well be right that the best refactoring tool in existence is one for a dynamically typed language, but Anton is certainly right in principle.

Reminds me of an old Yogi Berra saying:

In theory there is no difference between theory and practice. In practice there is.

The theory in question is already used successfully in practice, though it is not called "refactoring"; instead it is called program transformation, and is at the heart of optimization passes in compilers like GHC and SML/NJ.

Anton wrote:

Put it this way: in many respects, the statically-typed languages have gone about as far as they can go in terms of strictness. Making them more dynamic is likely to be a challenge, since it goes against their fundamental philosophy.

I wonder what you mean by "strictness". If you ask me, there will always be room (and demand) for making type systems more closely approximate specifications.

Patrick wrote:

The last decade of research in functional language type systems can be seen as making them more dynamic. I think they're heading in the right direction. I don't know if they'll ever matter in wide-spread practice, except...

I wonder what you mean by `dynamic'.

The past decade has seen notably the development of higher-order functors in ML, higher-order polymorphism in Haskell, higher-rank polymorphism, typed call/cc, typed reflection and generic programming (as in Generic Haskell). These features all increase the expressiveness of statically enforceable guarantees. Only call/cc increases the dynamic expressiveness.

Maybe the problem is that you associate `dynamic' with `expressive' rather than seeing them as independent quantities.

Here is how I measure static and dynamic expressiveness. Consider a translation F of a typed FP language X into an untyped FP language Y, which simply erases the types.

• An extension to X increases static expressiveness if the image of F gets larger (more programs can be typed).

• An extension to X increases dynamic expressiveness if it necessitates an extension to Y.

Take for example call/cc. If you extend X with call/cc but Y has no call/cc, then there will be some new X-programs which are typeable but cannot be translated to Y by simple type erasure. So adding call/cc increases both static and dynamic expressiveness. (You can simulate call/cc by CPS translation, but then F is doing more than type erasure.)

OTOH, if you extend X with higher-rank polymorphism, then you will not need to extend Y, since that only makes more Y-programs typeable in X.

We're talking about refactoring tools for end users, though.

I have no doubt that static type information is useful. The surprising success of the Smalltalk Refactoring Browser is evidence of actually how little static information is needed in practice.

Patrick wrote:

The last decade of research in functional language type systems can be seen as making them more dynamic. I think they're heading in the right direction. I don't know if they'll ever matter in wide-spread practice, except...

I wonder what you mean by `dynamic'.

What I mean is that type systems have been able to prove more theorems of runtime (i.e. dynamic) behavior. Monads, linear types, various forms of polymorphism, etc. As you indicate, maybe this should be "more expressive".

If you ask me, there will always be room (and demand) for making type systems more closely approximate specifications.

I agree. The question is, when, if ever, in practice will they be more widely used than untyped dynamic languages? I suppose there will be a time when that is the case, but I do not see a positive return on investment yet as compared to the apparently more lowly writing of tests in nUnit fashion.

This is true, of course. The question is in practice is static checking + testing more or less productive than just testing alone?

So far I remain in the dynamic camp, while following the improvements in static typing.

All these issues, of course, are much more important for large scale programming projects than for quick hacks.

This paragraph comes across as an ad hominem attack like "anyone not doing what I prefer is a hacker" which of course ignores the fact that Test Driven Development is having great success with large scale programming projects.

Yep, "more expressive" would be a better term

Some of the confusion can be avoided by following Cardelli and using the terms "statically checked" and "dynamically checked" languages/type systems.

Oh, you are dead wrong in your interpretation. "Hacking" is not a derogatory term.

My statement reflected my opinion about an important software engineering issue (problems of scale).

I had a great ad hominem attack, which you richly deserved for that accusation of yours, but I decided that LtU is not the right place for it

From the paper Jarno referenced: "One must be careful generalizing the results of this study to other situations... Nevertheless, the experiment suggests that for many realistic programming tasks, type checking of interfaces improves both productivity and program quality."

And we're going to run all those xUnit test-cases whether the development language is statically-typed or dynamically-typed, aren't we?
Will static type checking find problems closer to the time we introduced the problem into the code base?

return on investment
The costs of using the old static checking (Modula, Java) as-opposed-to the old runtime checking (Smalltalk, Python) seem to outweigh the benefits for many situations. Situations where reliability isn't the priority.
(Much hand-waving to cover the many differences between specific languages and development environments)

With the new static typing (Ocaml, Nice, ...) and the new soft-typing the cost/benefit changes. I don't have the kind of visceral understanding of the new static typing that would come from months of development on real projects. My impression is that the development cost of static typing is falling. My guess is that it will continue to fall, and at some point I will start to think of it as a-really-useful-tool rather than as a-burdensome-tariff.

In fact Test Driven Development is at least as much about design as it is about testing.

I would like to see the static type community address this point, in fact. Because to some extent designing "types first" is like designing "tests first".

Situations where reliability isn't the priority.

This statement ignores all the financial, insurance, medical, manufacturing, electronics, and other situations where very safe languages like Smalltalk and Lisp have been used successfully.

My impression is that the development cost of static typing is falling. My guess is that it will continue to fall, and at some point I will start to think of it as a-really-useful-tool rather than as a-burdensome-tariff.

I agree. I have not seen that on the horizon for a large number of programmers yet. It could be out there. Meanwhile the "software crisis" seems to be getting resolved in other ways.

Gutman: 300/10KLOC
Huckle: from <1/10KLOC to 250/10KLOC

Seems that the "Space Shuttle Software" project were doing something that gave them a two-orders-of-magnitude improvement in their defect rates. Language or Process or... ?

It's almost always *people* (who use languages and processes) that make the difference.

Of course another part of the total equation is cost. Very few IT or start-up companies can afford the $/kloc spent on shuttle software.

To be fair, I said it "comes across" as ad hominem, so I was speaking directly about how I interpreted it, not about how you intended it.

I wrote the distributed run-time of a Smalltalk system that ended up being used for equipment dispatching in the southeastern US. At the time it was the most scalable Smalltalk system in the number of concurrent users (by an order of magnitude over any other known use of a distributed Smalltalk). It was based on Gemstone Smalltalk, but it multi-plexed hot-fixable, resumable runtimes through a servlet-like interface (although the term servlet had not been invented yet).

There was a point during the aftermath of a hurricane that the system was loaded and slowed to a crawl, but did not crash. Field engineers were debugging the system live, and the customer was sure it was in the Smalltalk system.

It turned out to be a bug in IBM's TCP/IP stack on System 370 which was communicating with the Smalltalk system (on Solaris I think). IBM patched the TCP/IP stack, and soon after data resumed flowing at full speed. The part of the Smalltalk system that had "paused" on the formerly trickle of data just picked right up to full speed.

Seems that the "Space Shuttle Software" project were doing something that gave them a two-orders-of-magnitude improvement in their defect rates. Language or Process or... ?

Here's the Nasa Software Engineering Lab methodology.

See http://sel.gsfc.nasa.gov/website/documents/online-doc.htm

From the docs they seem to be using mostly C and Ada. I also don't believe that scripting languages can be used currently for embedded systems such as in the Space Shuttle due to guaranteed response times (ie. performance) and low memory requirements.

Patrick said: It's almost always *people* (who use languages and processes) that make the difference.

I agree 100%. If you see NASA's project timetimes, coding is just 20% of the project time. Design is 40% and testing is 40%. Reliability is hard work!

This is a good point. After all, types entail tests. These tests are executed by the compiler/run time system.

XP calls this TDD. The static typing community calls this typeful programming.

Probably true, but we always have to watch our assumptions, even NASA. Tektronix, IBM, and others have had real-time systems running Smalltalk for over ten years.

From Computing Japan in 1997...

OTI's Smalltalk can run on a number of ROMmable microkernel real-time operating systems (OSes), such as QNX and VxWorks, as well as on mainstream desktop OSes (Unix, Windows, etc.). But it can also be configured to run "on the metal" -- that is, with no operating system. While the theoretical minimum size for a Smalltalk application is about 10K, such an "application" can't do anything useful. The entire code for the athlete's personal trainer mentioned above, however, fits into just over 200K of ROM (read-only memory).

My understanding was that OTI Smalltalk has always been strictly internal, for OTI use on consulting projects. Is it still used for new projects?

XP calls this TDD. The static typing community calls this typeful programming.
Reminder to myself: for TDD the value matters as-well-as the type.

Obviously. TDD is not the same as typeful programming, but the analogy seems apt.

Remember that types reflect variable values. Some type systems more than others, of course. Think predicate types, dependent types, algebraic data types and even conventional Ada subtype declarations (e.g., quite easy to ensure that a test is done to check that the result of a size() function is non-negative).

I equate "scripting language" with "dynamic language". There is very little difference between Python, Ruby, Smalltalk, and Scheme. I have done far more "scripting" in Emacs Lisp, Smalltalk, and Scheme than any other language.Some scripting languages are more oriented toward "scripting" but they can be seen as subsets of these more general dynamic languages.

My understanding was that OTI Smalltalk has always been strictly internal, for OTI use on consulting projects. Is it still used for new projects?

IBM Canada bought OTI some years ago. OTI Smalltalk became the core of IBM's VisualAge Smalltalk. It is still used for new projects, but Java obviously stole a large part of the customer base.

The same is true for Gemstone Smalltalk and Gemstone Java. The core money maker is still GS/S. A number of new Smalltalk-based Internet services have come out over the last few years in spite of Java's popularity. Paul Graham wrote about this same philosophy, re: using Lisp for what became Yahoo Stores. When you develop and run on your own servers, you don't care what the average programmer is doing down the street for the average start-up.

There is very little difference between Python, Ruby, Smalltalk, and Scheme
Really?
Can you hot-fix and resume Python, Ruby, ...
Would it be reasonable to attempt the "equipment dispatching" system you mentioned using Python, Ruby, ...
For both good and bad, ST image-based development seems very different from file-based development.

Rather than thinking of Smalltalk and Scheme as scripting languages (although I can understand the desire to share in the current popularity of scripting languages) should we acknowledge that some "scripting languages" have grown to be more than that?

in spite of Java's popularity
I'm trying to stay somewhat on "Reliable Software with Scripting Languages" there's plenty of the other stuff on comp.lang.smalltalk

I don't know about specific implementations of Python or Ruby. I was referring to the essential semantics of the languages when I claimed "very little difference".

Of course there will be significant differences in specific implementations, just as there are real-time Smalltalks, desktop GUI Smalltalks, server Smalltalks. The language semantics are essentially the same.

Again, "image-based development" is specific to most, but not all, Smalltalk implementations. The realization, even the concept, of an image is not central to the definition of Smalltalk the language.

Likewise, "file-based development" seems to be central to Java, yet Gemstone Java is more "image-based development" where the image is really a multi-user object-oriented database. Yet the essential semantics of Java do not change for Gemstone Java.

I think we should acknowledge the popular scripting languages have grown to be more than that. And so my preference for "dynamic languages" as comnpared to "static languages". Others have pointed out that this distinction is blurring too with newer type systems and optional type systems.

We're not in Kansas anymore.

I'm increasingly unsure how to characterize programming languages in a meaningful yet manageable way.

We're not in Kansas anymore
Just don't call me Toto ;-)

We're talking about refactoring tools for end users, though.

Yes, and my point is that that program transformation technology could be repackaged as a tool for end users. Indeed, I think it would be even easier to do than for Smalltalk, seeing as how FP (= equational) languages are defined in terms of program transformations. That's what an equation is, after all.

I have no doubt that static type information is useful. The surprising success of the Smalltalk Refactoring Browser is evidence of actually how little static information is needed in practice.

I'm sure the SRB is a useful tool. I don't think I said otherwise.

The question was, would a refactoring tool for a statically typed language allow more kinds of refactorings? And my answer was, it would.

Now you are questioning whether those additional refactorings are actually necessary, based on the fact that the SRB is useful without them. That doesn't make much sense to me.

I'm not saying that Smalltalk should be statically typed in order to allow more refactorings or something. What I'm saying is that a refactoring tool for a statically typed language allows more kinds of refactorings. (We could argue about what I mean by "more".) What you make of that depends on how much you value the ability to refactor.

The question is, when, if ever, in practice will they [statically typed languages] be more widely used than untyped dynamic languages? I suppose there will be a time when that is the case, but I do not see a positive return on investment yet as compared to the apparently more lowly writing of tests in nUnit fashion.

Surely this is a loaded question. How can there be a return on an investment which is never made? If you don't use a statically typed language, you will not get the advantages.

Anyway, it's not an either-or thing; even users of ST languages need to write tests, and perhaps the value of testing is greater for those users than the value of the static typing. But observe that 1) ST language users need to write fewer tests because there are fewer possibilities at run-time, i.e., ST supports testing, and 2) we should be comparing the contribution toward correctness/efficiency of testing in a DT language with the sum of the contributions of both static typing and testing in an ST language.

Exactly. In spite of their theoretical value, and their value in relatively limited use, their value over alternatives in widespread use will remain in doubt.

This is not saying they are good or bad, or better or worse, it is only stating the observation that they are not used widely. The current success of Test Driven Development with various dynamic and older-style static languages only puts widespread use of advanced functional languages further out on the horizon.

Surely this is a loaded question. How can there be a return on an investment which is never made? If you don't use a statically typed language, you will not get the advantages.

Exactly. In spite of their theoretical value, and their value in relatively limited use, their value over alternatives in widespread use will remain in doubt.

So, "all" the languages with advanced typesystems have to do is demonstrate their practical advantages over C, C++, Java, Ada, Visual BASIC etc. Actually, I think what's more likely to happen is that you'll see mainstream statically-typed languages start to adopt more advanced typesystem features, including inference, although I confess it's hard to see how Java's typesystem might morph into something closer to ML. Still, we've already seen this kind of thing with features like parametric polymorphism in C++ and in experimental versions of Java.

The end result is that the language we'll be arguing about in 10 years time will look like a genetic accident that occurred in a lab where someone accidentally mixed the C# and OCaml genomes - and it'll ship with every version of Windows 2010 by U.S. federal decree.

This conversation began with the (my?) observation that the popular static languages have become more like dynamic languages over time. i.e. they are evolving towards Lisp and Smalltalk.

To some degree, but a lesser degree, they are evolving towards static typed functional languages. But at the same time more people are jumping right to dynamic languages like Perl, Python, Ruby, even Smalltalk, and Scheme.

Demonstrating value and demonstrating acceptance are two different thigs. If dynamic languages are sufficient and widely accepted but static functional languages are superior and widely unaccepted, my point is made. I think that is where we're at now and may remain for the foreseeable future.

I don't agree that...

it's up to dynamically-typed languages to show that they can compete in similar environments

Dynamic languages are competing and winning already in acceptance, which is my point. Superiority is arguable. Acceptance and acceptability have been demonstrated. People are not losing when they adopt dynamic languages and Test Driven Development. In fact they are winning better than ever.

Actually, I think what's more likely to happen is that you'll see mainstream statically-typed languages start to adopt more advanced typesystems features, including inference

Clearly we are seeing this evolution already with Pizza, Generic Java, the functional C++ stuff, etc. The test will be how many go this way vs. go the dynamic language route.

I'm a little lost here. Statically-typed languages in generally are more widely used for commercial application development, than dynamically typed languages. If we're talking only about the functional statically-typed languages with mathematically-derived typesystems, it's hardly necessary for them to demonstrate the value of static typing in practice - that's been done

Indeed, Anton, you're right. I was thinking of the web programming arena, where Java is the only widespread ST language. Frankly, I will freely admit that I would rather program in Scheme than in an ST language like C, C++ or Java, if you were to limit me to those choices only, but that has more to do with the aspects of those languages which do not relate to typing.

OTOH, if you give me even a monomorphic ST variant of Scheme, I would prefer it to Scheme since I know I can always emulate dynamic typing by injecting everything into a `universal' type. There is simply more done for you in an ST language than in a DT language so, all other things being equal, you lose nothing and stand only to gain.

Patrick will rightly reply that "all other things are not equal", and indeed I am not sure you could support call/cc and macros in a monomorphic setting (though I suspect one could). So perhaps someone (surely not me? :) should demonstrate that it is possible.

Demonstrating value and demonstrating acceptance are two different thigs. If dynamic languages are sufficient and widely accepted but static functional languages are superior and widely unaccepted, my point is made.

OK, if we are going to wrangle about language popularity again, I will beg your pardon and bow out of that discussion.

Well I was trying wrangle about sufficiency and momentum, which I saw as more than just popularity. But the conversation has twisted around too many corners to be useful anymore, you are right.