The audience is self-selected. The ones that don't know any better see only a condescend tone instead of the material. They don't get the difference between "lines spent" and "lines produced" and they don't know that computers were used to "compute" and thus the formalism was absolutely necessary to trust the result.
What we write today is WoW and stuff we don't need formalism to prove they don't crash - because, you know, who cares about that?
Dijkstra comes from a time were you could reuse a piece of software and build upon it because you could understand it. Today nobody does it because the software is "disposable". Who cares about proving a piece of future garbage?
Agreed. In a way, it's like the "Blub paradox", only applied to formal methods instead of programming languages. Those who aren't familiar with them don't see the point and think it's merely "mathy" nonsense.
People learn differently and formalism in one approach to teaching it. It has it's purposes but complex systems require more than one way of representing it. Formalism shouldn't be the only way to represent and teach the concepts of computation and CS.
You are right in saying that formalism is required to trust the result; however, I would argue that it isn't the only way. Looking at something from a strictly mathematical approach would ignore some of the more black arts component of CS and Software development. You should be viewing a system from various angles to help convince you of it's reliability.
I think these two talks might help explain things.
Comments
The audience is self-selected. The ones that don't know any better see only a condescend tone instead of the material. They don't get the difference between "lines spent" and "lines produced" and they don't know that computers were used to "compute" and thus the formalism was absolutely necessary to trust the result.
What we write today is WoW and stuff we don't need formalism to prove they don't crash - because, you know, who cares about that?
Dijkstra comes from a time were you could reuse a piece of software and build upon it because you could understand it. Today nobody does it because the software is "disposable". Who cares about proving a piece of future garbage?
Agreed. In a way, it's like the "Blub paradox", only applied to formal methods instead of programming languages. Those who aren't familiar with them don't see the point and think it's merely "mathy" nonsense.
I think you are confusing what Stiff was saying.
People learn differently and formalism in one approach to teaching it. It has it's purposes but complex systems require more than one way of representing it. Formalism shouldn't be the only way to represent and teach the concepts of computation and CS.
You are right in saying that formalism is required to trust the result; however, I would argue that it isn't the only way. Looking at something from a strictly mathematical approach would ignore some of the more black arts component of CS and Software development. You should be viewing a system from various angles to help convince you of it's reliability.
I think these two talks might help explain things.
http://worrydream.com/MediaForThinkingTheUnthinkable/ http://www.confreaks.com/videos/282-lsrc2010-real-software-e...