| Potential Differences | |||||||||||||||||||||||||||||||||||||||||||
|
About dynamic languages, Agile methodologies, OS X, whatever piques my interest!
Greg Vaughn
Subscribe
|
Sat, 10 May 2003 Brian Marrick comments on Mike Clark’s blog entry Staying Fit With Learning Tests . I’m quite interested since I noticed some of my own backsliding behavior recently when I was writing code against a new API. I was writing my first JMX MBean, and had no one experienced with JMX around for guidance. I didn’t write it test first :-O I did, however, go back and give it a full unit test suite after-the-fact, and it has been rock solid in production. It did take some refactoring to get it in shape to be easy to unit test, so the late testing step did improve the design. Anyway, back on topic: I attributed my backsliding to the fact that I was exploring/learning a new API. I think there’s a well-known compromise between Brian and Mike’s approaches, and I’m waiting for a Smalltalker to go into more details — the Inspector. My first development job was for the Apple Newton PDA, which used a custom language called NewtonScript that had features from a number of languages (I’ll try really hard not to bore everyone with all the details, but suffice it to say that it was really a great language to program in, but I was too inexperienced to really realize it at the time). One of the features the NewtonScript IDE copied from Smalltalk was the Inspector. I’m sure I never used it to its full potential due to being young and dumb at the time, but it allowed the sort of interactive exploration Brian is mentioning, and stored these “lessons learned” in a file that could easily be reopened and re-executed at any time. Mike’s learning tests don’t sound like they’re going to be included in the regular source tree and build process. The only reason they would be saved is to review the lesson and copy/paste some of it into the real system. Eclipse has the concept of scrapbook pages, which are essentially renamed Inspector pages. It’s not too surprising considering Eclipse’s Visual Age roots, however, I was coding in IntelliJ IDEA so I didn’t think of a scrapbook until I read Brian’s blog. The advantage of an inspector/scrapbook page over Mike’s practice is that you don’t need the overhead of a full compilation unit. You don’t have to have a class and method in which to place executable lines of code. The ‘run’ function of the scrapbook handles that for you. I suppose I need to explore some more nooks and crannies of IntelliJ to see if scrapbooks are available, but I had looked briefly when I first switched from Eclipse and did not find them. Perhaps it is time to file a feature request. potential differences [/testing] permalink I first saw an AP story on this, but I thought it had to be a hoax until I found this on Microsoft’s own website. They’re creating an Internet connected port-a-potty! Must…….resist……..toilet…….humor……. but it’s such fertile ground.potential differences [/fun] permalink I know I gave Paul Graham a bit of a hard time earlier, but I have nothing negative to say about his latest essay, Hackers and Painters. He weighs into the dynamic vs. static languages with this great characterization:… a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.I’m seeing writings all about dynamic vs. static languages all over blogspace. In the meta-sense, it’s really interesting to see a common topic over such a wide variety of individual writers. Good writers, must first be good readers. I also was quite struck by this insightful, but disheartening observation: Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products. Big companies win by sucking less than other big companies.The only slightly contrary point I’d make about the whole essay is that experimental scientific research is a lot more like debugging than he realizes. potential differences [/lang] permalink |
||||||||||||||||||||||||||||||||||||||||||