Machines don't make decisions; software does: ... Consider for example, the old electromechanical phone switches....
The only decision being made there is by the human being that dials the numbers. They dial 9; nine pulses are generated by the dial; those nine pulses cause the switch to rotate 9 places.
Machines do not adapt to their inputs; software does: Again I am not sure what this means.
If the pilot of a pre-fly-by-wire airliner dies at the stick and slumps forward on that stick, the plane will inevitably nosedive.
With fly-by-wire airliners, the flight control software can and does intervene and disregard pilot inputs that take the aircraft outside of its safe flight envelope.
Machines do not prioritise their responses to inputs; software does: Why not? Certainly I could imagine a machine which would prioritize processing of inputs.
Then I invite you to publish your imaginings of a purely mechanical system for applying the brakes on a car if it detects a human being in the vehicles path.
Machines have physical limitations; software has only logical limitations: I think I get what you are saying here but I am not sure what relevance it has.
From Nancy G. Leveson. Aeronautics and Astronautics.MIT:
Software is pure design without any physical realization and therefore “fails” only by containing systematic design defects. In fact, software can be thought of as design abstracted away from its physical representation, that is, software (when separated from the hardware on which it is executed) is pure design without any physical realization of that design. While this abstraction reduces many physical limits in design and thus allows exciting new features and functions to be incorporated into spacecraft that could not be achieved using hardware alone, it also greatly increases potential complexity and changes the types of failure modes. With respect to fault tolerance, potentially unsafe software behavior always stems from pure design defects so redundancy—which simply duplicates the design errors—is not effective. While computer hardware reliability can depend on redundancy, dealing with software errors must be accomplished in other ways.
The recent SpaceX Falcon 9 mid-air explosion was caused by the failure of 2ft long, 1" diameter steel strut. Rated for 10,000lbs, it failed at 2,000lbs. The fix is relatively simple; redesign the strut to increase its strength and test each one individually before flight. It took them 3 weeks to find that physical error.
Contrast with the life, path and root cause of a software error:
There was, however, a potentially serious software error that occurred in April 2009, just two years before the Shuttle’s retirement. The error manifested itself in flight STS-126 a few minutes after Endeavor reached orbit. Mission Control noticed that the Shuttle did not automatically transfer two communication processes from launch to orbit configuration mode. Mission Control could not fix the problem during the flight so they manually operated necessary transfers for the remainder of the flight. The pathway for this bug had been introduced originally in a change made in 1989 with a warning inserted in the code about the potential for that change to lead to misalignment of code in the COMPOOL. As more changes were made, the warning got moved to a place where it was unlikely to be seen by programmers changing the code. The original change violated the programming standards, but that standard was unclear and nobody checked that it was enforced in that case. Avoiding the specific error that was made was considered “good practice,” but it was not formally documented and there were no items in the review checklist to detect it. The SPF did not identify the problem either—testers would have needed to take extra steps to detect it. The SAIL could have tested the communication switch but it was not identified as an essential test for that launch. Testing at the SAIL did uncover what hindsight indicated were clear problems of the communication handover problem, but the test team misinterpreted what happened during test—they thought it was an artifact of lab setup issues—and no error reports were filed.
Comparing software to a machine at anything more than a totally superficial level, completely misrepresents the nature and complexity of software.
This is a complex machine, but it is roughly equivalent to 10 lines of Perl.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||