This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: More on Dynamic Typing
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.
In response to Darren's comment on this post, I responded with a comment. However, the comment went long enough that I figured I should post it more prominently - here it is:
You say: "edit time checking is superior to compile time checking is superior to runtime checking"
Well, yeah. And in Smalltalk, edit time = compile time. And using SUnit, edit time = compile time = test time. So if there's a problem, we catch it when we write the code (assuming we are doing TDD). This is sooner than you'll catch it in any of the popular static languages. So if this is your premise, you want to do TDD in Smalltalk.
You then say: "I don't know about you, but I am a senior architect / developer in the real world. Many of the programmers I work with wouldn't be able to spell encapsulation, let alone explain what it means. If, when I build the core libraries people use, I give someone a way of doing something stupid... rest assured - they will."
Ok, I'll be blunt - you are working with the wrong people. Static typing won't save you if your staff doesn't understand basic development. They'll be making algorithmic errors abd worse. If this is the problem you have, then you are chasing the wrong problem.
As to your train example - Ariane V. Type checking doesn't solve your problem. If you have bad/non careful developers who use the wrong module - even though said module males the compiler happy - you still end up with an exploding rocket. Ditto your train. You have to run tests. Static typing verifies nothing of real interest for you in this case; testing will. If you rely on static checks, you'll end up very, very sad
Then you say: "You are not daily dealing with people who's entire programming experience is that 4 day introduction to VB course.. But that's the sort of person who ends up using my libraries, and I need every bit of safety I can get my hands on."
If you are happy with false safety, sure. What you've actually done is tied the hands of the end developers in the name of protecting them - and the worst part is, you haven't actually accomplished anything. If your developers make algorithmic errors (the most common and worst kind) - compiler checks won't help you.
Ultimately, you are worried about the most irrelevant problems, and pretending that it solves the big issues.
Previous Topic
