7 ms·

Paranoid Programming – Techniques for Constructing Robust Software [ps]

99 points by tjalfi 10y ago

skissane 10y ago
This sounds interesting. Alas, I cannot read it right now, since my iPhone lacks native support for viewing PostScript files (something which macOS has.) If only there was a PDF or HTML version, or if my iPhone could display .ps (there probably is some app, I haven't looked.) UPDATE: found a free web based service to convert it to PDF for me, docspal.com
- deleted 10y ago
  [deleted]
- klibertp 10y ago
  https://klibert.pl/statics/RobustProgramming.pdf https://klibert.pl/statics/RobustProgramming.pdf (Just trying to be helpful, I hope I'm not infringing anything?)
wuch 10y ago
It is quite interesting to look how some of those recommendations change in the industry over time (to a degree you can make such general statements). For example in Clean Code, Robert Martin argues against the idea of encoding type information into names (e.g., Hungarian notation suggested here) given that this can readily provided by IDE instead and enforced by strongly and static type system. Though, he _does_ recommend encoding information about arguments into function names. It seems that this recommendation to a large degree is a reflection of tools used. Nowadays it wouldn't be completely unusual for an IDE to show formal parameter name along with actual argument values passed, thus obviating the need to encode this information into the function name in the first place. Idea of robust data structures is very interesting. While storing additional information to detect potential misuse of API, like concurrent modification or iterator invalidation is common in other context, the idea of using it to correct the data structure is not the first thing that comes to mind.
- Swizec 10y ago
  And at the same time everyone in the JavaScript world is comfortable with using some hungarian-ish notation. $ is for jquery objects, Capitals are for classes, lowercase for instances, camelCase for methods and properties, UPPERCASE for constants, underscore_case for API values, snake-case for CSS classes. To name a few common conventions. None of this is enforced at the tools level.
  - dualogy 10y ago
    Hungarian notation IIRC is specifically a 1-char-prefix of an argument names indicating type, ie. `goToWork (bTrth, sTxt, iCnt)` -- ie to reinforce type expectations -- rather than such casing conventions.. http://foldoc.org/hungarian%20notation http://foldoc.org/hungarian%20notation
    - Silhouette 10y ago
      Yes, that's more-or-less correct. The prefix wouldn't necessarily be only a single character. For example, using a "p" prefix for pointer values was a common convention in Microsoft ecosystem projects where Hungarian notation was probably most popular. Thus a pointer-to-char (char*) parameter might be prefixed with "pc". But yes, the fundamental idea was to convey information about the type of the variable as part of its name. That convention has mostly died out today, probably due to a combination of IDEs being used routinely in the ecosystem where the notation was most popular, and more recently due to modern languages having better type systems that enforce the rules objectively instead of relying on a convention. Ironically, with the popularity of dynamically typed languages today, we sometimes seem to have regressed to a point where interfaces to functions aren't always clear, and lots of avoidable bugs creep in due to passing incorrect types of data around. The emphasis on rapid evolution and ad-hoc/organic design we see with a lot of "agile" development processes isn't always helpful either. Put those together, and you almost have the complete opposite of the systematic design and robust processes advocated in the slides here.
      - throwawayish 10y ago
Silhouette 10y ago
This is a fascinating set of slides, particularly when you think it was produced almost 20 years ago. A few of the ideas are slightly dated now as we've developed better tools and techniques to achieve the same ends, but most of the material is fundamentally sound and has stood the test of time. For anyone who's only ever worked on projects where the emphasis is more on shipping something fast than shipping something correct, like most of the startups and web apps we discuss here on HN, these slides give a decent overview of the "alternate reality" when you're working on projects where reliability really matters and more of an engineering mindset is needed. If nothing else, it's worth reading for the Ariane 501 case study on slides 19-22 that demonstrates just how expensive a simple programming error can be if you don't design your system defensively enough and do proper housekeeping on your code.
aruggirello 10y ago
At page 7, in the table "Causes of outages", the numbers for "Fault tolerant systems" only add up to 90%, not 100% - don't know if the source “Dependable Computing: Concepts, Limits, Challenges,” by J. C. Laprie, FTCS-25. has the same error.
JoachimSchipper 10y ago
It's funny to see how well this has stood the test of time; these concepts are still perfectly valid today (although wuch is right that Hungarian has fallen out of favour.)
- nickpsecurity 10y ago
  More than valid: much of it is implemented in both NonStop and Stratus servers with amazing levels of uptime. Been waiting forever for FOSS OS's to copy some of these techniques with a limited config of HW redundancy. Now you can even get inexpensive, PowerPC boards that support lockstep with 1+GHz processors. That's for embedded use.
  - JoachimSchipper 10y ago
    Embedded and FLOSS appear to be rather different worlds, I'm afraid. There's a gcc toolchain running through both, but...
    - nickpsecurity 10y ago
      Well, yeah, but people do a lot with old computers, Rasp Pi's, etc. I guess I was thinking those crowds. Esp if it was a monitoring, backup, or authentication solution where uptime meant more than throughput.
agumonkey 10y ago
There's also a research paradigm about mathematically derived programs.

99 points by tjalfi 10y ago

This sounds interesting. Alas, I cannot read it right now, since my iPhone lacks native support for viewing PostScript files (something which macOS has.) If only there was a PDF or HTML version, or if my iPhone could display .ps (there probably is some app, I haven't looked.) UPDATE: found a free web based service to convert it to PDF for me, docspal.com

deleted 10y ago
[deleted]
klibertp 10y ago
https://klibert.pl/statics/RobustProgramming.pdf https://klibert.pl/statics/RobustProgramming.pdf (Just trying to be helpful, I hope I'm not infringing anything?)

wuch 10y ago

It is quite interesting to look how some of those recommendations change in the industry over time (to a degree you can make such general statements). For example in Clean Code, Robert Martin argues against the idea of encoding type information into names (e.g., Hungarian notation suggested here) given that this can readily provided by IDE instead and enforced by strongly and static type system. Though, he _does_ recommend encoding information about arguments into function names. It seems that this recommendation to a large degree is a reflection of tools used. Nowadays it wouldn't be completely unusual for an IDE to show formal parameter name along with actual argument values passed, thus obviating the need to encode this information into the function name in the first place. Idea of robust data structures is very interesting. While storing additional information to detect potential misuse of API, like concurrent modification or iterator invalidation is common in other context, the idea of using it to correct the data structure is not the first thing that comes to mind.

Swizec 10y ago
And at the same time everyone in the JavaScript world is comfortable with using some hungarian-ish notation. $ is for jquery objects, Capitals are for classes, lowercase for instances, camelCase for methods and properties, UPPERCASE for constants, underscore_case for API values, snake-case for CSS classes. To name a few common conventions. None of this is enforced at the tools level.
- dualogy 10y ago
  Hungarian notation IIRC is specifically a 1-char-prefix of an argument names indicating type, ie. `goToWork (bTrth, sTxt, iCnt)` -- ie to reinforce type expectations -- rather than such casing conventions.. http://foldoc.org/hungarian%20notation http://foldoc.org/hungarian%20notation
  - Silhouette 10y ago
    Yes, that's more-or-less correct. The prefix wouldn't necessarily be only a single character. For example, using a "p" prefix for pointer values was a common convention in Microsoft ecosystem projects where Hungarian notation was probably most popular. Thus a pointer-to-char (char*) parameter might be prefixed with "pc". But yes, the fundamental idea was to convey information about the type of the variable as part of its name. That convention has mostly died out today, probably due to a combination of IDEs being used routinely in the ecosystem where the notation was most popular, and more recently due to modern languages having better type systems that enforce the rules objectively instead of relying on a convention. Ironically, with the popularity of dynamically typed languages today, we sometimes seem to have regressed to a point where interfaces to functions aren't always clear, and lots of avoidable bugs creep in due to passing incorrect types of data around. The emphasis on rapid evolution and ad-hoc/organic design we see with a lot of "agile" development processes isn't always helpful either. Put those together, and you almost have the complete opposite of the systematic design and robust processes advocated in the slides here.
    - throwawayish 10y ago

Silhouette 10y ago

This is a fascinating set of slides, particularly when you think it was produced almost 20 years ago. A few of the ideas are slightly dated now as we've developed better tools and techniques to achieve the same ends, but most of the material is fundamentally sound and has stood the test of time. For anyone who's only ever worked on projects where the emphasis is more on shipping something fast than shipping something correct, like most of the startups and web apps we discuss here on HN, these slides give a decent overview of the "alternate reality" when you're working on projects where reliability really matters and more of an engineering mindset is needed. If nothing else, it's worth reading for the Ariane 501 case study on slides 19-22 that demonstrates just how expensive a simple programming error can be if you don't design your system defensively enough and do proper housekeeping on your code.

aruggirello 10y ago

At page 7, in the table "Causes of outages", the numbers for "Fault tolerant systems" only add up to 90%, not 100% - don't know if the source “Dependable Computing: Concepts, Limits, Challenges,” by J. C. Laprie, FTCS-25. has the same error.

JoachimSchipper 10y ago

It's funny to see how well this has stood the test of time; these concepts are still perfectly valid today (although wuch is right that Hungarian has fallen out of favour.)

nickpsecurity 10y ago
More than valid: much of it is implemented in both NonStop and Stratus servers with amazing levels of uptime. Been waiting forever for FOSS OS's to copy some of these techniques with a limited config of HW redundancy. Now you can even get inexpensive, PowerPC boards that support lockstep with 1+GHz processors. That's for embedded use.
- JoachimSchipper 10y ago
  Embedded and FLOSS appear to be rather different worlds, I'm afraid. There's a gcc toolchain running through both, but...
  - nickpsecurity 10y ago
    Well, yeah, but people do a lot with old computers, Rasp Pi's, etc. I guess I was thinking those crowds. Esp if it was a monitoring, backup, or authentication solution where uptime meant more than throughput.

agumonkey 10y ago

There's also a research paradigm about mathematically derived programs.