 |
privacy |
||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2005-06-22Dynamic Languages Improve Software Quality?ACM News Service: Testing, Testing, One to Three, Testing. There’s something about this blurb that sets my teeth on edge. Not all the teeth, just the ones at the back. Let’s see if I can figure out what’s off for me, since so much of the full article is just fine. From the blurb we get that
It’s the last two that leave me at “Huh?” I don’t doubt that there is growing and welcome use of dynamic languages, like original Basic in its day but with much greater scope of application. The Python (and EcmaScript) languages have great appeal for certain kinds of utility computing. The ease of integration with components created elsewhere is no small part of the charm, and the increased ability to produce components and applications usable elsewhere is completing the circle. This ease of testing is in the hands of developers during development and when the developer is the user. This works in the small (look at the popularity of Perl) but I don’t think it is exactly enterprise-ready. And for me, modification after deployment strikes me as about as smart as instructing people to modify the Windows registry. It’s one of those “all warranties are voided and remember to sign your life-insurance waiver before getting on this ride” moments. I’m sure the IT department will be thrilled to start getting calls from executives who’ve been hacking the business-intelligence application. The part that throws me has to do with deployment of solutions with languages that, as the result of dangerous design cleverness, are inherently insecure and exploitable. I think the comparision with C++ and other production languages (including Java and the .NET family as well) is awkward in that regard. Sean McGrath’s 2005-06-10 ITworld.com article takes a more leisurely pace. There is an important progression of levels of software correctness:
What I find interesting about this is that when you get to formal mathematical methods, unless the proof mechanism jumps in your face when an alteration breaks the proof, this is all for a very static world, and mucking with code after the proof of function (not bug-freeness) is a serious no-no. For one thing, one may need to ship the proof with the software, and it passing a verification may be a condition on acceptance for installation. At the heart of this nice little progression is a misunderstanding about what one can prove. One cannot prove that a program is bug-free either. Proving a program correct is not the same as proving a program to be free of bugs. I know that sounds strange, so I will leave that to be mulled over and argued with. There seems to be confusion of the programmer’s desire to increase the efficiency of code-and-fix development cycling and with the desire to produce correct code. It is great to shorten the code-test-repair-rinse-repeat toil of developers, but that is a bit like saying all we need is to do what we already do more, better, and faster. It certainly fits the programming by trial-and-error-discovery-of-a-program approach to producing software. What has us think that will do much to increase the correctness and reliability of the result? There’s interesting linkage to Bruce Ekel and Tim Bray on this matter, and I find Tim’s appraisal not so decontextualized as Ekel’s (and McGrath’s). I don’t think the availability of strong typing and of exception mechanisms are the problems. It’s really about handling failure modes. That dynamic languages have different failure modes is fine, but I wouldn’t want an end-user to see the failure modes, and that’s what happens in those models (as you’ll notice when a web page vomits an EcmaScript or other exception at you). There are a lot of ways to deal with failure modes in a disciplined way, and no dynamic language of the kind we have right now will save us from failure modes that pertain to the application, not the programming model.
Orcmid, good points here. Especially your two "huhs?" Those dots don't connect for me either. And while test driven development can turn into trial and error it doesnt' have to. I generally applaud the development of unit testing and test driven coding, but when coding this way then the construction of the tests really matters. But thanks for the good points on testing for bugs and proving programs correct. It's also not clear to me that a correct program necessarily has the best quality. Remind me, what exactly is quality without context? "but I wouldn’t want an end-user to see the failure modes, and that’s what happens in those models" No, that's what happens in those models by default. "no dynamic language of the kind we have right now will save us from failure modes that pertain to the application" Erlang is a dynamically type checked language designed for building fault tolerant systems. Here's a good overview Making reliable distributed systems in the presence of software errors Here's an industry example Four-fold Increase in Productivity and Quality Isaac, thanks for your comments. Two things. Yes, it is the default behavior, but I think that play's into Ted's argument that these are dangerous tools for non-experts if put into production settings. With regard to Erlang, I don't think that fits on the roster of what people are promoting as dynamic languages for easy software rolling. But I think the bigger disconnect is that you and I might not mean the same thing by "application." Is there a better place we could discuss considerations like that? "these are dangerous tools for non-experts if put into production settings" LOL! If we cannot assume basic competence there was a hiring mistake. "I don't think that fits on the roster of what people are promoting as dynamic languages" Why not? "a better place" Such as? Well, the languages that were mentioned in the article that led to my post are Python, Jython, Smalltalk and Scheme. The other examples that spring to people's lips are Ruby and Perl. Sometimes PHP too. (ECMAscript doesn't receive many mentions, which is interesting since it's so ubiquitous.) Erlang is not a household name, as you know. With regard to hiring decisions, I think a lot of these choices are made by self-hired developers and people making web sites and so on. And in a very many places, I am not sure the maturity of the organization and the hiring managers would be one where this discussion made any sense. By another venue, I was wondering if you had a blog and we could cross link our thoughts rather than hiding out down here in the comments of a rarely-read blog. Oh, and I suppose we could go over to Lambda the Ultimate. That would be an interesting place. They have a wiki, as I recall. Erlang is not a household name, as you know afaict Erlang has the characteristics ascribed to "dynamic languages" so generalizations about "dynamic languages" need to take Erlang into account (or be more specific). maturity of the organization and the hiring managers If both the managers and developers are incompetent then I don't think we need to worry to much about the development tools ;-) I can't argue with any of that. In your honor I went and read through my stack of LtU RSS clippings and resubscribed to their RSS. I don't think it is worth moving this discussion to there. They seem to have beaten it to death already.
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |