Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: Software Design Resources

by graff (Chancellor)
on Aug 22, 2003 at 03:27 UTC ( #285648=note: print w/replies, xml ) Need Help??


in reply to Software Design Resources

allow software to be used in applications where any failure is simply not acceptable

That's a helluva concept... I would take the condition "failure is not acceptable" to mean something like "completion/closure of the software project is not expected within your lifetime". ;^) Keep in mind that the "final release" of an application is not when all the bugs are fixed. It's when people stop using the application (so the remaining bugs that surely still exist will never be found, let alone fixed).

The causes of software failure constitute an open set. They include not only things that are arguably wrong in the code design, but also varieties of data or operating conditions that no programmer could anticipate, no matter how careful or thorough the design and testing.

Apart from that, the evolutionary facts of life, as applied to hardware, OS's, programming languages and user needs, preclude the possibility of stasis in any application. Code quality is like internet security -- an ongoing process rather than a finite state to be acheived.

Your complaints about metaphors and lack of substance are well founded, I'm sure. But how can you expect substance, "working code", stuff that can be "directly applied", etc, in the context of talking about programming in general? Either you spout generalities or you delve into the details of a specific app (where the app usually requires some amount of app-specific QA/QC) -- or else you try to make some general point using some particular example,which turns out to be irrelevant to the majority of readers, so they can't "directly apply" it.

In order to learn the best way to write code, and in order to improve your skill as a programmer, you have to write code, fix code, review and critique code, and be involved enough in each particular application domain to know what the code should be doing -- i.e. to know what users of the code need to get done. This is not a matter of having a formula or cookbook for writing code that can't break; it's a matter of being able to figure out what to do when it does break. Because it will break.

(I know, I'm ignoring some areas of "general" software design where it really pays to learn from books, documentation, release notes, etc -- things like "how to write C code so that you don't allow input buffer overflows", "how to write cgi code so that you don't expose your server to malicious or accidental damage", and so on. But I would argue that these should be addressed in an application-specific way -- it seems unproductive to try speaking or learning about them "in general theory".)

Replies are listed 'Best First'.
Re: Re: Software Design Resources
by Anonymous Monk on Aug 22, 2003 at 04:01 UTC

    Thank you for your reply.

    where any failure is simply not acceptable
    ...
    That's a helluva concept

    Yes it is. However, many such situations exist today where a single bug will completely destroy a company's reputation and open them up to severe liability. A single bug in certain medical systems could easily cause many deaths. A bug in flight control software can cause (and has caused) a hundred million+ dollar mission to end in failure.

    But how can you expect substance, "working code", stuff that can be "directly applied", etc, in the context of talking about programming in general?

    You'll have to obviously narrow the field a bit to get to the level I'm requesting, but narrowing out brainfuck doesn't exactly eliminate a good portion of your audience. Pseudo-code, class diagrams, etc can be equally applied to Perl, Java, Python, Ruby, C++, and almost any language in popular use today.

    The causes of software failure constitute an open set. They include not only things that are arguably wrong in the code design, but also varieties of data or operating conditions that no programmer could anticipate, no matter how careful or thorough the design and testing.

    Actually, I disagree. Provided that the supporting systems interfaces are accurately and fully specificed and that they do not fail, the responsibility rests entirely on your code. If everyone follows that strategy then you will have a flawless system (this is obviously a lot harder at the hardware level). The task is not to complete the entire product perfectly, but to complete your software's functionality perfectly.

    In order to learn the best way to write code, and in order to improve your skill as a programmer, you have to write code, fix code, review and critique code, and be involved enough in each particular application domain to know what the code should be doing

    Yes, but after that what happens? To continue simply learning a simple fix here and there will not result in the reliability required for such systems.

      Pseudo-code, class diagrams, etc can be equally applied to Perl, Java, Python, Ruby, C++, and almost any language in popular use today.

      ... The task is not to complete the entire product perfectly, but to complete your software's functionality perfectly.

      Good points -- but it actually looks to me like the thrust here should be how to write specifications that are appropriate, adequate, bullet-proof and idiot-proof, and also make sure that these specs are readily translatable into the chosen programming language, complete with all necessary testing protocols -- i.e. given that the spec says "input comes from X, consisting of N bytes, etc" the test has to say "here's what is supposed to happen when input comes from anything other than X, and/or does not consist of N bytes, and/or etc."

      Most of the perl core documentation (and much of the extra module documentation) that I've seen has a lot of the properties that one would want for proper/robust software specifications -- the reader is told what inputs are needed or allowable for a given function/method, what it returns when used properly, and what happens when not used properly. And this is typically done using clear, simple language, not overburdened with nonce acronyms, jargon or "technical legalese", and yet not at all vague, either. I would hope that critical-impact projects would model the development of specs on such examples.

      Admittedly, the theory (or practice) of robust software design in critical-impact apps is not an area where I should try to assert any sort of personal expertise. I'll shut up now.

        Admittedly, the theory (or practice) of robust software design in critical-impact apps is not an area where I should try to assert any sort of personal expertise. I'll shut up now.

        You're doing at least as good as the "experts." Besides, as my good friend Francis always said truth comes sooner out of error than confusion :).

        You raise a good point about the specifications as well. Perhaps a problem well stated is indeed a problem half solved here. It appears to me that a proper tool for such a job would have to effectively generate tests to cover each set of possible errors introduced by the source code. It would not be possible to create all the tests by hand, that would only transfer the problem from the instructions to the tests.

        Anyone have any thoughts/information on self-verifying languages? Is there a different term for them I'm missing? ("self-verifying programming language" turns up nothing in google).

      I think that learning Perl, besides reading some books is not so difficult since the code is nearly always open to read it.

      If I were you, I would choose a subject that you have worked on it for a long time (expert by direct experience) and after finding the best script of this kind develloped by someone that you respect, try to modify it and improve it.

      That is an active way of developing skills and style.

      You won't like to change the author's style. And since the concept comes from another mind you are going to be forced to understand the way of thinking of this author.

      That is a universe to disconver for your improving. And it is free. Just try to improve the code and then publish it, mentioning the improvements and the original author.

      Finally, if you didn't learn a lot by re-writing the code you are going to learn a lot by the critics or by the people that love your improvements :)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://285648]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (6)
As of 2021-06-20 07:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)












    Results (94 votes). Check out past polls.

    Notices?