"Experts" and static typing
Managability is still fighting the good fight over static typing. Today, he's using a call to authority:
- Improves robustness through early error detection
- Increases performance by making required checks at the best times
- Supplements the weaknesses of unit testing
Hmm. Early error detection? I don't think his expert has done a lot of work in dynamic languages. The kinds of errors that static typing guard against just aren't that common. I can't recall the last time I made one, for instance. Increases performance - early optimization is always a bad strategy. If you are thinking of optimization at first, you made a mistake. Weakness of unit tests? You mean, testing the actual usage of the code is less useful than verifying that we passed an int to a method defined that way? Pardon me while I laugh. a lot.
After showing a demo of how nifty Eclipse is, he goes on to say:
I think given the arguments presented by Eric Allen, and the utility of Eclipse in doing TDD, the issue of Static vs Dynamic typing should be a closed issue.
Sure, just not the way you think. The Eclipse link argues about the lack of power in Ruby and Python development environments (is this true?). Here's a tip - grab a Smalltalk environment, and get back to us.
Comments
Eclipse for TDD
[Dave Astels] May 9, 2003 12:47:30.954
I read the post ... and laughed... probably as much as you did, Jim. I watched the viewlet. And cried. The person who did the viewlet didn't do a very good job of it.. it was really "jumpy".. they didn't take nearly enough snaps (I've been using Viewlets off & on since early 2000.. I've made quite a few of them). But worse still was statements that were made that indicate that a) he didn't *get* TDD, and b) he wasn't very familiar with what he was doing: - The TestCase wiz in Eclipse does NOT require you to give it a class being tested. I use the wiz all the time and have never filled in that field. - The debugger? What a waste of time. Sure got a poor memory.. and even so a notepad next to the keyboard would be faster to keep track of what you need to do. - There was surprize/regret/anger/confusion when the test failed the first time it was run. You *want* the test to fail.. how else do you know it's a valid test and/or that you do have to write some code? - The first thiong they did was create a fixture. How do you know what should be in the fixture before you write the test (or could it be that they were just typing in code from Beck's book). Write the test, make it work. Write another test, make it work. NOW look for common setup code and refactor it out into a fixture. - a test for addition seems to be a rather high level one to start with. Have I missed anything.. likely.. I just looked at the example/demo/post once, earlier this morning. Ah.. you're on to something here Jim.. a good rant now & then feels gooooood! Dave