This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: You can have your cake
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Panopticon posted on dynamic/static issues awhile back, and I've been pondering the post. This morning, I have a few thoughts on it. The gist of his post is that he likes the immediacy of dynamic languages (which he refers to as scripting languages) - but then caveats it this way:
In the end, I think anything that helps the average programmer be more productive is a good thing. By and large, static typing satisfies this dictum: static typing enables all kinds of programmer productivity features like Intellisense, better error messages at compile time, etc. (One could argue, I suppose, that you could lose the static typing and use type inferencing instead, but I wonder whether it would be possible to build a complete enough type inferencing ruleset that: a) was implementable, b) made some kind of sense, and c) could compete with just stating the damn type of your variables.) Dynamic environments also do this: edit and continue (pace Franz et al.), continuable exceptions, being able to call functions at design time, etc. So I think marrying the two worlds has some facinating possibilities.
Well, most of those things are possible in languages like Smalltalk. Intellisense - we have code completion tools as loadable components in VisualWorks. As it happens, this isn't something most Smalltalkers seem to want... but it's there. Compile time errors - that gets into an interesting definition issue.
In languages like C#, Java (etc), compile time is a "heavier" thing than it is in Smalltalk. Sure, there's incremental compilation support in some of the IDE's out there - but in Smalltalk, there's really no difference between compile time and runtime - we compile methods one at a time as we go, and we can immediately test. Some people use agile methodologies - they write the tests fiest, and then run them. Others do workspace twiddling and then migrate to a browser (this is more in line with how I develop - it's how I learned Smalltalk). Either way, there's no gap between runtime and compile time - there's really no interval that a Smalltalker refers to as compile time.
To some extent, this gets back to what I posted yesterday - in this debate, as with debuggers, Smalltalkers and developers using the mainstream languages tend to talk right past each other - we use the same words, but we don't really mean the same thing at all. From our perspective, you really can have your cake - and eat it as well.
Previous Topic
