
A Parable by Dijkstra (1973) - fpvsoop
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD594.html
======
jancsika
When the shunting person persuaded everyone to imagine the two-car units as if
they were symmetrical, the passengers still complained. Toilets can break, and
when they did the doubly unlucky passenger would be forced to walk _four car
lengths_ to get to the nearest toilet.

Also, those helpful arrows would be guiding the passenger the wrong direction
for two of those car lengths.

So we have comments that go out of sync with the running program, a spec that
lies about reality, and an implementation that doesn't match the spec. Yep,
that sounds like programmers to me.

Legit parable.

Edit: just realized the least lucky passenger would have to walk _six_ car
lengths. If the passenger is already at the wrong end of the "symmetrical"
two-car unit with a broken toilet, the arrow will point them in the direction
of the broken toilet. If the broken toilet is the last car, then they must
walk back two car lengths to get where they started. Now if the next two-car
unit is turned the wrong direction they must walk two more car lengths.

So add to this a spec that's difficult to reason about.

Again, legit programmer parable.

~~~
mikorym
> the least lucky passenger would have to walk six car lengths

I just want to elaborate on this to show which assumptions you are making.
There are two ways to make a paired unit: \--+ and -+-.

In your scenario I think you assume the first. The end of the train is thus
...+----+, since you mention the second last car's orientation being reversed.
The +'s represent toilets. Then, what you are saying is to consider a
passenger located at the ^ symbol: ...+--^--+. In this configuration, your
observation makes sense.

I do think that a more practical solution is to work only with (-+,-) pairs.
The symmetry that Dijkstra talks of is then that (-+,-) and (-,+-) are
equivalent for the purposes of the problem. Then an end of a train would be:
...-+-+-. This is then the "extra few feet" that he talks of.

~~~
mcguire
Indeed. Dijkstra specifies two cars joined with the toilet in the middle:

" _When each car with a toilet was coupled, from now until eternity, at its
toileted end with a car without a toilet, from then onwards the shunting yard,
instead of dealing with N directed cars of two types, could deal with N /2
identical units that, to all intents and purposes, could be regarded as
symmetrical._"

~~~
jancsika
I think what bothers me about this is that it's an analogy which crosses the
digital divide.

On the physical "train" side of the analogy, we've got a believable scheme to
save money by only having a toilet in every other car. Given the constraints,
it is indeed clever to make these two-car atomic units and reimagine them as
symmetrical. All the fixes in the story taken together could pale in
comparison to the cost of putting a toilets all the cars.

But when we cross the digital divide we get a completely different set of
constraints. Even if dealing with 100 million train cars it may be cheaper to
just fork the entire train yard and add a toilet object to each car.

------
bmer
For those who want to see Dijkstra's mathematics of programs in action:

1) basic (great for kids, math novices, whatever):
[https://www.amazon.com/gp/product/0470684534/ref=dbs_a_def_r...](https://www.amazon.com/gp/product/0470684534/ref=dbs_a_def_rwt_bibl_vppi_i0)
(ignore the two star review, this book would get 5 stars from me)

2) advanced (free, complete with videos):
[http://www.cs.toronto.edu/~hehner/aPToP/](http://www.cs.toronto.edu/~hehner/aPToP/)

3) advanced:
[https://www.amazon.com/gp/product/0470848820/ref=dbs_a_def_r...](https://www.amazon.com/gp/product/0470848820/ref=dbs_a_def_rwt_bibl_vppi_i1)

4) advanced, theoretical, from the man himself:
[https://www.springer.com/gp/book/9781461279242](https://www.springer.com/gp/book/9781461279242)

~~~
mcguire
Also, slightly less advanced:

 _A Discipline of Programming_

[https://www.amazon.com/Discipline-Programming-Edsger-W-
Dijks...](https://www.amazon.com/Discipline-Programming-Edsger-W-
Dijkstra/dp/013215871X)

For more practical fun, consider Frama-C, SPARK, and Dafny.

------
simplecomplex
Moral: The engineer who conceived of the innovation was forgotten and not
compensated for it, and the train owners made the bulk of the money.

Sounds like software engineering to me!

~~~
DaveInTucson
I feel like the actual moral of the story should be "don't underestimate how
trying to scrimp on a vital resource can result in horrible logistical
complexities and a nightmare UX".

~~~
rossdavidh
All true, but I would add that "in order to get back to the previous system
that actually worked, you may have to provide a fig leaf for management, so
that they can pretend no such thing is happening." We are back to one toilet
per car, but we have to use cars of twice the size (with superfluous coupling
in the middle that is never uncoupled) in order to pretend that we did not go
back to the original system.

------
xamuel
The final paragraph is my favorite. I have a PhD in mathematics but I've since
realized I'm not a mathematician, I'm more of a logician/philosopher. I find
the parable very interesting, but I can totally believe a lot of real
mathematicians don't. Too many mathematicians, if you crack open a random page
of their work, you'll see lots of opaque integrals and calculations. None of
that ever appealed to me. Even when I was the top of the class among
undergraduate mathematics majors, I was basically doing the bare minimum I
could get away with of that kind of "grind", and focusing all my time and
passion on things more closely resembling this kind of "parable".

~~~
contravariant
I don't think he was saying mathematicians don't find it interesting because
it lacks sufficiently convoluted mathematics.

Rather a 'true mathematician' (who by definition ignores all practical
considerations) would find it unsatisfactory because the problem of finding a
way of allowing toilet-less carriages is solved by not allowing toilet-less
carriages.

Frankly I think they should have just put the toilet in the middle of the
toilet-carrying carriages, but maybe I'm weird.

------
epx
So in the end the permanently coupled tuple of cars is handled as a single
car, it kind of proves that every car must have a toilet? Or perhaps the next
manager reiterates the rationale and decides to put just one toilet every two
car tuples...

~~~
mcguire
But twice as long and articulated.

~~~
epx
Yes, the articulation is the only difference from a span-bolstered car with
8/12 axles.

------
praptak
The director got fired for causing actual losses and the shunting yard workers
got huge bonuses and promotions for saving the company, right? Right?!

~~~
sanbor
Almost. The director got the bonus and the yard workers got more work.

------
contingencies
For me, one moral of the story is when approaching any issue in a live system,
it often pays to go back to modeling the actual problem instead of iterating
on broken assumptions. Good solutions should have documentation which explains
their take on the problem and the reason the solution in particular was chosen
versus other potential designs.

Of course, outsourcing, interdepartmental or interpersonal politics can create
commercial misincentives to remove such time and money saving features...

------
oblib
The greater point I took away was that sometimes someone who's not involved in
solving a problem can see a solution while those who are do not.

In that respect programming is often as much an art as it is a practice.

------
forapurpose
I thought the moral was going to be that accommodating toiletless cars cost
more than simply building all cars with toilets.

~~~
squirrelicus
I feel like that's still the point irrespective of Dijkstra's apparent view on
the parable. Creating exceptional cases is the best way to increase costs.

------
sus_007
Is Haskell still a preferred introductory language to enter the Functional
Paradigm with? Or do you think other alternatives do a better job at that than
Haskell ? I'm learning Scheme with the SICP Book ATM, and am confused where to
go next to get better at Functional thinking(and programming).

~~~
simplecomplex
Haskell. If programming languages were mountains, Haskell is Everest. Conquer
it and other languages can be mastered in your sleep.

Go further.

~~~
frabert
I never did alpinism, I guess Everest would be a good place to start with...

~~~
TremendousJudge
it's not even in the Alps!

~~~
n4r9
[https://en.wikipedia.org/wiki/Mountaineering](https://en.wikipedia.org/wiki/Mountaineering)

"Mountaineering is often called Alpinism, especially in European languages"

~~~
mcguire
"Alpinism" sounds like a disease.

------
tzs
Note that the arrow solution failed because to the shunting yard the cars were
immutable objects. They could only control the direction of the arrows in the
non-toilet cars by how they oriented the whole car when they composed it into
the train they were building.

If the non-toilet cars were made mutable, specifically if they were made so
the arrows could be reversed, then the shunting yard could compose the cars
without regard for the orientation of the non-toilet cars, and someone later
could go through and set the arrow directions. I'd guess there is some sort of
preload inspection done by the crew, which might be a good place to handle
setting the arrows.

------
ggchappell
> I have told the above story to different audiences. Programmers, as a rule,
> are delighted by it, and managers, invariably, get more and more annoyed as
> the story progresses; true mathematicians, however, fail to see the point.

I see the point. In fact I'd go so far as to call myself "delighted". But I
thought I was a _true mathematician_.

'Scuse me while I go have a little existential crisis.

------
konschubert
I'll bite. What's the morale that he's implying?

That algorithms can be simplified by slightly lifting the constraints?

~~~
B1FF_PSUVM
That some problems can be solved more easily with a different data structure.

I think it was Robert Tarjan that wrote a book on that topic, but I can't find
it.

------
CamTin
I guess the ultimate solution assumes that all the turntables are long enough
to deal with at least two-car consists? Seems strange that the company would
cheap out on a little bit of porcelain in each car and then overprovision its
turntables in such an extravagant way.

~~~
mannykannot
With the toilet at the end of the carriage that is connected to its
corresponding non-toilet carriage, and consequently approximately in the
middle (the offset is the "last three feet" that Dijkstra mentions), there is
no longer a need to reverse any two-carriage set.

~~~
mayoff
Turntables are not just for reversing. A turntable also moves cars (and
engines) between multiple tracks and storage facilities. Two-car sets need to
be moved even if not reversed.

~~~
mannykannot
You can do that with tracks and switches - in fact, you can also reverse
rolling stock with a 'Wye'. I believe turntables were mostly used to reverse
steam locomotive - tender sets, and to build engine sheds in constricted urban
areas where there wasn't a lot of room for a switch network.

------
victorNicollet
TGV trains in France have a very strict structure. For the TGV atlantique
lines, for example, "short" trains contain exactly 10 cars (and "long" trains
are composed of two "short" trains), with the following distribution:

\- Car 1 and 10 are engines, and include some second class seats. \- Cars 2
and 3 are first class. \- Car 4 is the bar-restaurant. \- Car 5 is first
class. \- Cars 6, 7, 8 and 9 are second class.

All the infrastructure is designed to treat the train as a single unit, during
all operations at the shunting yard, in repair workshops, and son on.

And the position of toilets (including special toilets for nappy changes) is
fixed.

------
Finster
This seems like it has potential for being the core of an interesting
interview question. Maybe something along the lines of "You are hired as the
Chief Shunter (lol) of a new rail company and the CEO, to cut costs, has
stated that only half of all cars will have toilets. What instructions will
you give the shunters? What complications could arise? What is the optimal
solution and how would it impact UX?" etc. etc.

~~~
sanbor
Often people is nervious at job interviews. It might not be the best place for
this sort of creative problems.

------
TheOtherHobbes
This solution is wrong.

Rolling stock needs maintenance, and if you keep units permanently paired you
can easily run out of units.

In fact there is no easy solution given realistic business constraints. You
can either put toilets in every car, which has a cost because it reduces
available seating. In the best case you’ll lose money because of the lost
seats. In the worst case overcrowding will make the toilets ineffective.

Or you can buy enough spare units to allow for maintenance, which has a larger
up front cost, and continuing costs in terms of stabling, and possible issues
with shunting yard size.

Working out the most efficient answer given real trains, real passenger loads,
likely future passenger loads, and shunting yard constraints, is not a trivial
problem.

Unlike Dijkstra, some of the managers in his audiences will have understood
this. It’s no wonder they found his glib hand-waving annoying.

The actual lesson of the parable is the opposite of the one Dijkstra is
making: the real world is hard, and if you think a solution fits neatly into a
trivial software construct, _you’re almost certainly wrong._

~~~
zaphar
It's a parable which means it is fiction that that ignores details to make a
point. As such it does it's job quite well unless you yet to read more into it
than the author intended.

~~~
sethrin
To me this says that parables are fairly useless: with enough padding any
trivial insight may seem wise. I can't at the moment imagine something that I
would think important to communicate which would be made more clear by a
parable. I would also be concerned about being patronizing. I'm sure this
makes good fodder for academic quibbling, but I am beginning to doubt whether
Dijkstra was more insightful than arrogant.

------
pr_millipede
I don't quite understand why 'true mathematicians' fail to get the point. Any
ideas?

~~~
Sniffnoy
Because you get to the solution and you say, "But that's just the same
thing..."

~~~
djsumdog
It's like the joke with boiling the pot of water and just dumping out the
water; reducing it to the previous problem with a known solution ... or
something like that...

------
dacracot
The math is simple. This did not require a mathematician, just an cost benefit
analysis.

($ * toilet each car) < shunting{($ * action * yard) + ($ * training *
employee)} + ($ * accident cleanup) + ($ * customer bad will)

~~~
ufo
Read until the end again. The solution they came up with still only put
toilets in 50% of the cars.

~~~
dacracot
And from a system perspective, I would wager that the cost is still higher
given the complexity of their final solution.

------
JacKTrocinskI
KISS - Keep It Simple Stupid and put a toilet in each car of the train.

~~~
mcguire
Because it is cheaper than the cost of figuring out how to do it the other
way?

------
tw1010
I don't get it. (And I don't think it's because I'm a "true mathematician".)

------
coldtea
> _With growing size or sophistication of the program, the operational
> argument quickly becomes impossible to carry through, and the general
> adherence to operational reasoning has to be considered one of the main
> causes of the persistence of the software crisis._

What "software crisis"? Since its inception in the 50s or so, software has
only gone from strength to strength.

~~~
brazzy
[https://en.wikipedia.org/wiki/Software_crisis](https://en.wikipedia.org/wiki/Software_crisis)

~~~
mcguire
Projects running over-budget

Projects running over-time

Software was very inefficient

Software was of low quality

Software often did not meet requirements

Projects were unmanageable and code difficult to maintain

Software was never delivered

Yeah, that one.

~~~
coldtea
A "crisis" would imply that:

1) we don't get increasingly bigger and more powerful systems

2) we're behind some previously existing "no crisis" state

Both (1) and (2) are factually wrong.

Projects running over-budge, over-time, often not meet requirements etc, are
not a crisis in the actual meaning of the world.

It's just a normal state of affairs.

And despite that we have got from the laughingly primitive software in the 50s
and 60s, to the software "eating the world" today, and have systems with 10 to
100 or 1000 more lines of code, and way more functionality -- even in our
pockets.

If only "crisis" looked that way in other domains too.

It's not a crisis, it's just unrealistic expectations.

Even if we could do 100x better in the _future_, it wouldn't justify the term
crisis for the state we're in, and have been for decades.

~~~
brazzy
> Both (1) and (2) are factually wrong.

 _You_ are factually wrong because you know only the status quo that _emerged_
from that crisis.

> Projects running over-budge, over-time, often not meet requirements etc, are
> not a crisis in the actual meaning of the world.

> It's just a normal state of affairs.

To _you_ it is.

To the people in the 1960s, it wasn't.

Because they had previously experienced a state where the hardware imposed
such drastical limits on the possible size and complexity of software that
each programmer working on a project could intimately know and understand
every piece of code in it and the requirements that influenced it.

The change from that to one where programmers understand only part of a
project is absolutely fundamental and completely changes the way you have to
work to achieve your goals. Now your project _will_ fail if you cannot manage
and divide-and-conquer its complexity in some way.

------
Cieplak
Since we're talking about Dijkstra, thought I'd bring up the letter he wrote
to the University of Texas when they replaced Haskell with Java in their
introductory programming course:

[https://chrisdone.com/posts/dijkstra-haskell-
java](https://chrisdone.com/posts/dijkstra-haskell-java)

[https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Bud...](https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf)

~~~
rcdmd
Great letter (2001). It predictably focuses on language quality and side-steps
practicality-- the assumption being practicality isn't as important as
learning a high-quality language in an introductory course.

~~~
AnimalMuppet
Depends on what you think you're teaching. Are you teaching computer science,
or are you teaching software engineering?

Hint: Of your graduates, probably 95% will work as software engineers, and
only 5% will be computer scientists. But CS departments think they're
_computer science_ departments, even though they mostly are located in the
college of engineering. (I accidentally typed "enginerring", which I thought
was amusing...)

~~~
TeMPOraL
> _Depends on what you think you 're teaching. Are you teaching computer
> science, or are you teaching software engineering?_

> _But CS departments think they 're computer science departments, even though
> they mostly are located in the college of engineering._

I used to think this is true in the form you presented, but now I feel it's
really a more relaxed form that's true - CS departments in universities think
they're still in universities, not in glorified vocational schools. They try
to teach you more than the immediate needs of your likely job, so that you
understand the context of what you're working with, and are exposed to more
powerful ways of thinking.

(I mean, 99% of the time, your typical JavaScript-slinger doesn't need to know
what an "algorithm" is and what can be solved with one. These days, a popular
language, StackOverflow and open-source libraries are enough to do acceptable
levels of work. However, some extra theoretical knowledge will help tackle
more complicated problems, solve them better, and will enable one to do
something more challenging if they want to leave the web/CRUDsphere.)

Related: we now have "vocational schools" for programming too. They're called
"bootcamps", for some reason.

Tangential: there's a feedback loop between workers, universities and
employees in every industry. Progress of the "industry standard" must come
from somewhere. If all the new people are being exposed to is Java(Script),
the industry will forever keep being stuck on Java(Script). So I feel it's
good that at least some people in some universities try to teach above the
level required by the industry.

~~~
majewsky
> Related: we now have "vocational schools" for programming too. They're
> called "bootcamps", for some reason.

Bootcamps are a joke. Germany has had proper vocational schools for
programmers for decades. After high school, you can spend three years to
become a Fachinformatiker (it's difficult to translate, but basically means
"applied computer specialist"). There are two subflavors,
Anwendungsentwicklung (application developer) and Systemintegration (systems
integrator, this curriculum combines sysadmin and development tasks).

All that is entirely separate from CS courses at university, which is an
alternate path that one can take (and one that has a higher entry barrier
since you need to have at least 8 years in secondary education, i.e. until
12th or 13th grade). In the vocational training, you alternate between weeks
at school and weeks at your employer where you work on actual projects under
supervision of a qualified mentor.

~~~
Sharlin
In Finland we have three tiers of formal programming education. There's
vocational secondary school awarding "technician" level degrees, an
alternative to more academic _Gymnasium_ type secondary education (grades 10
to 12). The learning is very hands-on and practicality oriented.

Then there's "vocational" or "applied science" colleges you can enrol in after
either vocational or academic secondary school. They offer four-year bachelor-
level degree programs in various fields from healthcare to engineering. The
education attempts to mix theory and practice (with varying success).

Finally there's the "real" universities, offering primarily five-to-seven-year
BSc+MSc programs (before the Bologna Process you used to go straight to
master's; these days the steps are somewhat more discrete), and of course PhD
programs for those wishing to pursue an even higher level of education.

~~~
majewsky
Ah yes, we have "applied science" colleges as well. What you describe sounds
pretty much identical to the German system.

