Compile time - a nuisance
Darren Hobbs points out that having an artificial divide between compile time and runtime just makes life harder:
It gets more interesting when you get errors that aren't caught by the compiler (eg. calling a method on a null reference). In Java or C# the defect is already ossified in the compiled bytecode, and to fix it I have to change the source and recompile it plus everything that depends on it. On a big project this can be a time consuming process. On the other hand, in Smalltalk the error would be 'UndefinedObject doesNotUnderstand:someMethod'. And it would be as easy to correct as the mispelled method name from the previous example.
Seems to me that compile time checking is only important when you have the inconvenience of compile time in the first place.
Having to compile up front is like airport security - it gives you the illusion of safety with none of the actual benefits - and it makes the whole process slower as well...
Comments
[Steve Wart] March 31, 2005 14:17:41.132
Well compiling "up front" is fine. Like when I save a method. Not 1/2 hour later when I decide to save a file and run the compiler to see if I forgot to do something.
And testing "up front" is better yet. Why aren't compilers running Unit Tests instead of enforcing some Fortran-era compiler technology's concept of "STRONG TYPING"?
Let's do a survey of which compilers can be modified to run unit tests . . .
[Vincent Foley] March 31, 2005 15:53:08.488
More and more people seem to notice that instant compilation à -la Smalltalk is a Good Thing(tm), I blogged about a comment I caught on Slashdot recently.
The Dark Side is not as bad as you think
[Alex] March 31, 2005 18:06:23.141
Actually the Dark Side has moved on a bit! Nowadays much of your developed code resides in already tested Assemblies (or Modules or Class Files or whatever your language calls them). So typically you are only working on a small piece at a time (sound a bit Smalltalk-ish?).
With modern Type Inference, many of the problems of invalid method calls go away. Modern environments can just "run" the code in the current buffer, discover problems before you would in Smalltalk, and if no problems occur you are up and running just as quickly as Smalltalk.
You are comparing Smalltalk to the "old world".
Another Advantage of Compile Time
[Alex] March 31, 2005 18:23:04.282
It is worth considering the practice of doing computations at compile time when possible to relieve the load on run time performance. We do this quite extensively.
And of course Smalltalk does have a compile time, but it is a method or Class definition at a time, so relatively innocuous.
Type Inference?
[ James Robertson] March 31, 2005 19:40:15.359
Comment by James Robertson
Alex,
IIRC, VisualStudio does not have type inference. There are systems that do - many Lisp systems, for instance, and many of the other functional languages, for instance. What I suspect you are talking about is text completion - which is something that VW has add-ons for anyway
VisualStudio does not have type inference?
[Alex] March 31, 2005 21:38:34.196
It is the language that has Type Inference under Visual Studio, not VS itself.
Code Completion works best when it is contextual and that usually means with Static Typing. It is tough to figure out what list of methods/signatures to show if you do not know the type!
And as I like to point out, Type Inference allows one to (generally) not declare types and yet get the benefits of Static Typing (which includes, but is by no means dominated by, contextual Code Completion). Compile time type checking is significant, for example
Re: Compile time - a nuisance
[ James Robertson] March 31, 2005 22:17:39.306
Comment by James Robertson
Type Inference is not the same thing as code completion.
Vincent and Alex are right, the gap is closing ...
[ Troy Brumley] March 31, 2005 22:22:55.786
Comment by Troy Brumley
As I've mentioned on my blog, I've been working with Eclipse and Java. The compile is about as transparent as it is in Smalltalk. Really.
I admit that I'm still doing relatively small projects (less than 10 classes) but when I save a method, it compiles the .java file to a .class file. My code is always ready to run. Thanks to the dreaded strong typing, the IDE also helps me when I make an error. It warns me before I save things, and even offers helpful (really) suggestions for changes, and automatically makes the one that I pick.
I've had jar deployment problems, but I have had less trouble than I had with the run time packager.
Smalltalk may have done it first, or at least before Java, but good ideas can be implemented in other environments.
Type Inference is not the same thing as code completion.
[Alex] March 31, 2005 22:45:19.394
I do not believe I said that.
Code completion is something that is easier with a Statically Typed language.
Separate topic - Type Inference gives many of the benefits of Dynamic Typing (not having to decalre variable types) and Static Typing (catching type errors at compilations time, making code completion easier...)
Re: automatic unit testing?
[tbrumley@fuse.net] April 1, 2005 10:19:20.676
Trackback from: The Doctor is in Link: automatic unit testing? by tbrumley@fuse.net
1989 ObjectWorks for C++
[Isaac Gouy] April 1, 2005 13:37:35.409
"Tools such as an incremental compiler and linker, and file and program structure browsers, will deliver the benefits of object-oriented technology to the C++ programmer."
Re: Compile time - a nuisance
[ James Robertson] April 1, 2005 14:15:13.121
Comment by James Robertson
Isaac,
We delivered that (we being ParcPlace, where I worked at the time). The market yawned - Circa 1993, C++ programmers didn't want productivity. If it wasn't hard, they saw no benefit...
Implementation not Language
[Isaac Gouy] April 1, 2005 14:53:20.483
Mostly, incremental compilation is specific to a language toolset implementation, not to the language itself. iirc #Smalltalk doesn't provide incremental compilation.