
Paranoid Programming – Techniques for Constructing Robust Software [ps] - tjalfi
http://ftp.stratus.com/vos/doc/papers/RobustProgramming.ps
======
skissane
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

~~~
klibertp
[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
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
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
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
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
> But yes, the fundamental idea was to convey information about the type of
> the variable as part of its name.

No.

There are two types of Hungarian Notation.

The original one ("apps hungarian"), which _made sense_ and sometimes still
makes sense. Here you would assign a meaning to a prefix. For example, if
you're writing MS Word a variable named "sWidth" might be the width of
something in pixels on the screen (s), while "pWidth" might be the same width,
but in logical units (say pt) on the page. Then you could have a function
ptos, and it's easy to see whether variables were used correctly in
computations - you can't mix screen-space and page-space coordinates without
conversion.

This made a lot of sense, because either variable would likely just be an
"int".

Similarly in a Python Webapp one might write "us_name" where us means
UnSanitized. So before passing that anywhere else you know you need to
sanitize it. See a "us_" variable somewhere that isn't a call to a sanitizer?
Probably a bug!

Then there's that other one, "system hungarian", which is the stupid thing
everyone knows with stuff like lpcstrWindowName.

~~~
Silhouette
All of your examples are still type information. They are more specific than
the types provided by a basic C-style type system, but that's the point.

~~~
temac
We can easily distinguish between the two by calling them units.

~~~
Silhouette
It's not necessarily just units, though that's one useful example. Types could
also include things like whether a text string has been escaped in a certain
way, whether data has come from a trusted or untrusted source, and countless
other reasons you might want to ensure you don't use a value with a certain
property in the wrong way.

In modern languages where defining custom types and enforcing their use is
easier, there is less need to distinguish these properties by convention.
Twenty years ago, when we were doing more development with languages in the C
family that don't have very powerful systems, it was a different story, and so
naming conventions went some way to helping keep track of what data you were
really passing around beyond just "It's an int" and the like.

~~~
jschwartzi
I would also add that even in modern C++ it's possible to have the compiler
check your usage of page and screen widths by creating separate types,
ScreenWidth and PageWidth. You would then generate compiler errors on
assignment, or provide single-argument constructors for implicit conversion.

It's just that nobody ever actually does that in C++.

~~~
fiddlerwoaroof
The people that want to do this just use Haskell :)

------
Silhouette
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
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
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
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
Embedded and FLOSS appear to be rather different worlds, I'm afraid. There's a
gcc toolchain running through both, but...

~~~
nickpsecurity
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
There's also a research paradigm about mathematically derived programs.

