 |
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-22MDDi: Integrated Tool Chains for Software DevelopmentACM News Service: FP6 Project Aims to Increase EU Competitiveness in Software Systems Development. Uh, “programmers put on your chains and mechanize?” Maybe not. The MDDi project is making the Eclipse Model Driven Development integration (you parse that, I gave up, but I think it’s e[MDD]i sort-of—oh, it’s Eclipse MDDi). The expectation is that the open-source modeling tool will provide an integrated tool chain to help European system engineers make new software. It bugs me that this is heralded as an economic maneuver to avoid falling behind those pesky Americans and Japanese and reduce the cost of software development. That’s a peculiar motivation for wanting to improve the quality of software delivery. The 2005-06-15 CORDIS News article starts out a little more affirmatively, based on conversation with Serge Salicki: “Europe is faced with the double expectation from end-users of better, more complex and more reliable software systems, developed in an increasingly shorter time span at reduced costs.” The overall program is a European Sixth Framework Programme (FP6) project called MODELWARE. It is this effort that has the objectives of
MODELWARE (MODELing solution for softWARE systems) seems to be a two-year project and [e]MDDi is emerging about half-way through. Hmm. And we have new nomenclature: modellisation for becoming model-centric, somehow in contrast to being code- and document-centric in our development methodologies. The pilot applications (air-traffic control, for example) seem rather ambitious, too. I think my problem is with the blurb and the puffery, not the objectives of the effort. The idea is to produce open development platforms for software and services, and when we figure out what open means here, we can assess the value of the approach. One aspect of “open” is the choice of Eclipse as a development platform, although the participation of IBM in the effort is understated in the materials at the project site. I find fixing on a specific platform (in the sense Eclipse is used here) to be unsatisfying. I think it’s more than Eclipse is not my platform of choice. I’m wondering, rather, whether the methodology is abstracted enough that it can be rehosted and retargeted with the Model-Driven Development used to accomplish that. I’m curious about that. Dynamic 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.
from:
2005-06-20Rigorous Software Engineering at the Application-Domain Integration LevelACM News Service: Microsoft Research Aims to Ease Development. Early in my experience with Grace Hopper, I recall a presentation on the introduction of programming languages into IT operations. She told of the following simple way that she found to overcome the “real programmers don’t Flowmatic” (or Cobol) syndrome:
This came back to me when I noticed that the chosen venue for exploring and proving out the ideas for Rigorous Software Engineering is the new Microsoft Research India center in Bangalore. John Ribeiro’s 2005-06-13 ITworld.com article expands on a number of key ideas:
This is not unlike the Model-Driven Architecture (MDA) view, at a high-altitude of comparison. I find this appealing, although I wonder whether the rigorous codification of design rules from near-application solution space to platform-specific solution space will be too demanding. I don’t know. I am curious about that and about how performance factors enter into consideration. I do look forward to schemes of this kind for what they show us is involved in near-application modeling as well as reconciliation of problem space and solution space in ways where our clients may be able to check whether we’re building and integrating what they expect.
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |