Niklaus Wirth: CS ideas that seemed good at the time(inf.ethz.ch)
inf.ethz.ch
Niklaus Wirth: CS ideas that seemed good at the time
http://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas_origFig.pdf
5 comments
I particularly liked this passage from Wirth's essay:
A notorious example for a bad idea was the choice of the equal sign to denote assignment. It goes back to Fortran in 1957 and has blindly been copied by armies of language designers. Why is it a bad idea? Because it overthrows a century old tradition to let "=" denote a comparison for equality, a predicate which is either true or false. But Fortran made it to mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand (a variable) is to be made equal to the right operand (an expression). x = y does not mean the same thing as y = x. Algol corrected this mistake by the simple solution: Let assignment be denoted by ":=".
Perhaps this may appear as nitpicking to programmers who got used to the equal sign meaning assignment. But mixing up assignment and comparison is a truly bad idea, because it requires that another symbol be used for what traditionally was expressed by the equal sign. Comparison for equality became denoted by the two characters "==" (first in C). This is a consequence of the ugly kind, and it gave rise to similar bad ideas using "++", "--", "&&" etc."
I agree with this, and have never understood why languages perpetuate this practice of using the equal sign to denote something other than its meaning in mathematics.
A notorious example for a bad idea was the choice of the equal sign to denote assignment. It goes back to Fortran in 1957 and has blindly been copied by armies of language designers. Why is it a bad idea? Because it overthrows a century old tradition to let "=" denote a comparison for equality, a predicate which is either true or false. But Fortran made it to mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand (a variable) is to be made equal to the right operand (an expression). x = y does not mean the same thing as y = x. Algol corrected this mistake by the simple solution: Let assignment be denoted by ":=".
Perhaps this may appear as nitpicking to programmers who got used to the equal sign meaning assignment. But mixing up assignment and comparison is a truly bad idea, because it requires that another symbol be used for what traditionally was expressed by the equal sign. Comparison for equality became denoted by the two characters "==" (first in C). This is a consequence of the ugly kind, and it gave rise to similar bad ideas using "++", "--", "&&" etc."
I agree with this, and have never understood why languages perpetuate this practice of using the equal sign to denote something other than its meaning in mathematics.
Meh. This is one of those things that people have been railing about for decades, and I think as "language issues" go, it's pretty minor.
It's one of those things that quickly simply ceases to be a real issue once you're past the "my first program" stage. Humans are flexible, they don't really have a huge problem adapting to disparate usages in disparate situations (mathematics vs. programming).
IOW, it's bikeshedding. Yeah, even Wirth can bikeshed.
[Note that I actually prefer Pascal-style ":=" for assignment and "=" for equality; I just think it's nicer (Wirth gave some examples as to why). However, it's clear that the C-style syntax has the momentum these days, and it just doesn't seem to be much of a problem.]
It's one of those things that quickly simply ceases to be a real issue once you're past the "my first program" stage. Humans are flexible, they don't really have a huge problem adapting to disparate usages in disparate situations (mathematics vs. programming).
IOW, it's bikeshedding. Yeah, even Wirth can bikeshed.
[Note that I actually prefer Pascal-style ":=" for assignment and "=" for equality; I just think it's nicer (Wirth gave some examples as to why). However, it's clear that the C-style syntax has the momentum these days, and it just doesn't seem to be much of a problem.]
I'm a little disappointed that Wirth doesn't mention one of the key reasons that financial institutions use decimal floating point: that binary floating point can't produce exact representations of powers of 10, such as 0.1, and you may want to produce exact results for these situations, because fractions of a cent can really add up over time (see e.g. http://en.wikipedia.org/wiki/Salami_slicing).
All in all - most of the bad ideas seems to be things that struck the wrong balance between being fast/cheap to do in hardware and being a clean design. Either some feature went so far with making things easy for programmer, that it was too expansive to implement or too slow, or it went too far the other way - making it too easy to mess things up in the pursue of fast execution/cheap implementation.