On Wednesday 21 April 2004 10:53, Thomas Beale wrote: > ... anyone who does not see the inherent problems of using > Perl for build large software that is maintainable and re-usable after > 15 minutes of reading the manual probably doesn't have that much > experience in large systems. Not that I am condemning perl or its > programmers - not at all - I use it for what it's good for - writing > scripts that last until they break. Just an observation...
The largest system I know of that uses Perl is the UK's telescopes. The control software I am told is large monolithic blocks of Fortran, and those are manipulated, and the results are handled, by significant amounts of Perl, written nowadays in an object-oriented fashion. I suppose astronomers are good at picking sense out of noise<g> but they do seem to be maintaining it. > .... In the future, if not already, the correctness of the > prescription would be guaranteed by a drug knowledge-base which knows > about drugs and their correct/allowable routes. This kind of error isn't > stopped by compile-time type checking at all, of course, compile-time > checking is at a lower level - it helps to guarantee that the software's > model of the interface to the drug knowledge-base (for example) is > correct, e.g. it should be able to correctly discover that vincristine > should _never_ be given intrathecally, and represent that fact correctly > on the screen or wherever. I don't think that this does it. I envisage something that prevents the packaging and workflow system in the hospital Pharmacy from packaging the Vincristine for intrathecal use, and indeed prevents these specific two drugs from going up to the ward at the same time. Somewhere there has to be a link from the system that presents knowledge to systems that do things through interaction with the physical elements of the world, and I do not think that all of that can be mediated through people. > you just wouldn't do that (although lots of green programmers do) - > knowledge should reside in knowledge bases, not in compiled software. I suspect that there are a few particular drugs or pairs of drugs, and a few circumstances, which are more easily handled by specific program code written to do so than by system design, and that the total volume of such exceptions is small enough to avoid a combinatorial explosion. > >Given that new drugs are being added all the time, and indications etc > >for existing drugs are constantly changing, I suspect that you would > >need to re-compile such a system at least once a day to gain any benefit > >from compile-time checking of static typing. The typing discussion is going a bit above me, but I always assumed the reason I call an integer variable "intPatientCount was not so the computer knew anything about it, but so that I remembered not to compare it to a string (strPatCode). I am aware of having been corrupted away from Fortran by Basic and worse, VB, which is designed to slop, but Python seems quite helpful on such things. The Place of Python (etc) in GP Medicine in the UK --------------------------------------------------------------------------- The rest of you can decide how alike GP-UK is unto your own situations. The UK has several fairly evolved GP systems which have what I regard as essential - a scripting facility. One of them has a visual approach to it - like Visio - and I know not what underlying that. The others have abstruse complex specific mini-languages for preparing scripts. These antedate Python, and probably antedate Perl on any system on which they run, so it is not surprising they are awkward. The role of the scripting language (very high level language VHL or whatever you like to call it) here is to be an improved, more reliably maintained and persistent replacement for such existing or underlying scripting systems. IMHO. -- Adrian Midgley (Linux desktop) GP, Exeter http://www.defoam.net/
