"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.
Friday, February 01, 2008
Wednesday, January 30, 2008
Tuesday, January 29, 2008
Reaching back a year or so ago to a point Ralph Johnson made about practicing test-driven development. The big lesson: every little bit helps. You don't have to be perfect by any stretch, just stretch yourself more than where you are currently, and then a bit more...
For some years, I've taught a software engineering course that used both XP and RUP. Students had group projects, and half were XP and half were RUP. The projects are not run in as controlled a fashion as those in the paper, so perhaps I am missing something. However, in general I have not seen a big difference in results between the two. The main indicator of success is previous experience. Groups that have a couple of experienced people do better than those without.I'd take a reasonable, automated test suite over a great design any day. The one can lead to the other more easily. I'm not sure I'd recognize a "perfect" test suite if it hit me in the face, but a team that tries to improve it's testing has the best chance of success.
However, one group of people consistently did better with XP than with RUP. This is a group with little programming experience. RUP did not work for them because they had nobody who could act like an architect. They would produce UML diagrams, but they were always wrong, so it was a waste of time. However, when they followed XP, they produced (usually poor) working code that had regression tests. Eventually they started to refactor it. Because they always kept their tests working, they always made progress, even if it was slow. XP worked much better for these groups than it did for average groups.
Monday, January 28, 2008
I can go along with the HTML and SVG parts too. But the Lively Kernel part has a way to go. Too bad it's built on the browser, which is a much worse medium than the Smalltalk image. Hopefully that will improve, but browser progress as an application development medium is depressing.
The web makes a helluva "image file". Morphic is a great UI approach, but the browser is not ready to fully realize it.
The current browser is not even up to the level of Smalltalk-72 running on a DG Nova, pushing that analogy a little over the top. It's kind of sad to see Dan Ingalls mucking around with LivelyKernel when he could be working on such a better medium. It's kind of like when Ward Cunningham was at Microsoft and they just couldn't figure out what a creative mind they had available to tap.
Sunday, January 27, 2008
Steve Dekorte on another of my favorite subjects...
If you're looking languages or concurrency tools that will scale to the high core count desktop machines of the near future, I wouldn't put stock in MISD oriented solutions such as transactional memory or fancy functional programming compiler techniques. Shared memory systems simply won't survive the exponential rise in core counts.
Oh dear. This can't go on for long. I've been in the middle of these muddles before. Say something like, "Dynamic languages have great tools and can be used to build large, long-lived systems." And you will find yourself on the receiving end of questions like the following which someone just sent me.
I can indulge these for a minute or two. The problem is they are rarely asked by open-minded people. Usually they come from the statically convinced, who just need to find a way to catch you, to allow themselves the comfort that their static languages and their tools could be the only possible methods for large systems. They need to assure themselves of being on the righteous path, and you, poor fellow, are one step away drowning in Styx.
Before I proceed let me state: I know large systems can be built statically. I've done it in more than one language. I've also done it dynamically in more than one dynamic language. Have you? Have you been part of failures in each? Yes, I have. They almost never have anything to do with the languages and the tools themselves.
That said, I prefer dynamic languages because they ease the pain when used well. On the other hand nothing eases the pain of bad projects.
"What happens in Smalltalk projects where you grow larger? Where you want to divide a system up into components, and some of those components don't exist yet?"
Well, what happens in other projects? You have a need; you have an idea to meet the need; you try it; you grow it. I guess I don't understand the question.
"How are interfaces between library and user code specified?"
Interface notations have been attempted for various dynamic languages, including Smalltalk and Lisp. There is a reason they've not really caught on, yet large systems are still developed in these languages.
Semi-formal notations, tests and other examples, documentation, good tools -- these all contribute to success. But if you are looking for some kind of a "static declaration" as they saving mechanism for large systems -- it may work for you, but I doubt you can prove they are necessary and sufficient. I have counter-examples.
"Can such interfaces be browsed in the same way if the code can't be called?"
Your question betrays your bias. "There must be some such mechanism as the one I am used to," he thinks.
Most large systems developed with dynamic languages have not used the kind of mechanism you seek. Look elsewhere.
Can we go back to arguing over WSDL vs. REST now? Face it. The history of programming is one of gradual adoption of dynamic mechanisms.
- ► 2011 (19)
- ► 2009 (40)
- ▼ 01/27 - 02/03 (8)
- ► 2007 (388)
- ► 2006 (261)
- ► 2005 (335)
- ► 2004 (534)
- ► 2003 (286)
- Patrick Logan
- Portland, Oregon, United States
- I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.