On Sat, Apr 18, 2015 at 5:46 PM, Dave Angel <da...@davea.name> wrote:
> I'd still point out that eventually people will presumably get to believing > in your program. They'll subconsciously assume that if they mess up, the > program will notice, so they don't have to be as careful as they otherwise > would. Well understood! I have observed this in other things I have done that are being used, including the ancestor of this current project. I do not believe I have spoken much of it. It had been in use for approximately one year when I first discovered python and this mailing list. It is similarly a plan evaluation program, except it is used for the evaluation of our SBRT (stereotactic body radiation therapy) plans, whereas this project in development will be used -- at least initially-- to evaluate *normal* treatment plans. I think it has been in continuous use for going on four years now. It has never given an incorrect result. It has never failed its monthly constancy checks. It has rarely had a bug arise. When it has happened, it has been for something a user tried to do that I never imagined happening. But in each such instance (Keep fingers crossed, etc.) it has either crashed or displayed an error message describing the error, stopped program execution, and to contact me. The problem with this program is at the time of creating it, I knew its design was bad, but I did not have any options at the time. I needed the ability to display a graphical display of the plan analysis, but the only option our castrated work stations provided was to use the planning system's ability to create and display GUI elements. All of our workstations had Perl installed, but were missing dependencies (Which I was not allowed to correct.) to allow for GUI generation. I could have investigated the early versions of Java installed, but I wasn't prepared to go that route then. I tentatively looked into C/C++, but initial investigations revealed missing libraries, etc. there as well. So in the end I developed this hybrid of Perl code and planning system scripting language. You would not like the structure of the scripting language! I could go on quite a while, but I'll just mention that ALL variables are essentially both global and persistent. The variables and what they store do not go away until you exit the plan or purposefully destroy them. If I run one script, finish it and run a totally unrelated script it will have access to all variables and their last contents from the previous script unless the programmer explicitly destroyed those variables prior to that script's termination. Talk about potentially clashing namespaces! Because of these and other limitations that I had to work with, I was forced to have some program logic and substantial portions of the constraint data integrated with the GUI generation code. This led to maintenance hell the one time the constraint data had changed almost a couple of years ago. Steven's analogy of hammering nails with a paint brush comes to mind! But I got it to work and to work well. And this is much better than planners repeatedly doing by-hand calculations over and over and ... and over while they are trying to develop a viable plan. Which process is more likely to develop a patient critical error? Especially as the planner becomes fatigued under potentially heavy patient loads, where he must develop plans under time pressures? So I provided a solution that works. The planner uses it as a tool while developing his plans, undoubtedly *not* checking *any* of the calculations he used to do by hand. SUBSTANTIAL amounts of human labor are saved. When the planner feels he has a good plan, THEN he checks all of the program's calculations. If this is satisfactory, then he proceeds to getting the physician, etc. I believe that I come across on this list as much more ignorant and perhaps even much stupider than I actually am. This is because I am the sort of person who is unafraid to ask questions, no matter how trivial or how stupid I might make myself look by doing the asking. I would rather be absolutely certain that I understand what I am trying to do and the implications of what I am trying to do, then not ask due to potential embarrassment. At the very least, I want to identify the boundaries of my ignorance and incompetence. And after further pondering, if I feel I am still missing the boat on something, I'll have a go at asking again until I am satisfied with my comprehension. That is why I am so grateful to have access to your willing help and expertise! Anyway, back to the current project: The moment that they upgraded our systems, so that not only did I have full access to Python, no matter how old, but also that Tkinter was fully installed, was the moment I started designing a complete rewrite of the above-mentioned program. No matter how well working the program currently is, I *must* correct its major design flaws now that I have the tools available to do so. And I much prefer editing data files to editing programs into which data is embedded!! And my intent is to make everything even safer by interacting with the underlying planning software as minimally as possible. I want this new program to be as close to a strict reader of planning system output as I can make it and do ALL processing and display of the data external to the planning system. Especially as every time the planning system software is upgraded it seems to come with a new set of its own bugs. And if it comforts anyone, if anyone asked me to write software that would directly control, interact with or potentially alter a patient's *actual* treatment, I would refuse point blank--even if it cost me my job-- because I know that my current knowledge and skill sets could not safely accomplish such a project. I do not know if I actually needed to say any of the above, but I feel better for having said it! ~(:>)) > There's nothing you can do about this; it's human nature. So I claim that > making sure the advice your program offers has > 1) few bugs. And what it has should be crashes, not just getting the > wrong result. > 2) Careful wording of the messages to indicate the confidence level of the > conclusion it's relating. Trying to do my very, very best! -- boB _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
