One of the bad ideas discussed is functional programming (particulary the side-effect free aspect of it), another one is "passing parameters by name" which was proposed as one of the possible semantic for passing parameters in Algol. And which works like ruby blocks, IIUC. Seems funny that now those are mostly considered good ideas.
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.
Secrets of computing. Switch statements, hash tables, profiling. The CIA makes them not teach these.
A thousand line switch statement is not a thousand if-then-elses. It is not a binary-search of 10 if-then-elses. It is a single jump indexing a table of code addresses. A thousand-case switch statement is one instruction.
Take a 1024 sized array of link lists. Add the letters of words bitshifting by one each letter to make a hash function. Now, populate the array and push onto the link-list if collisions. To look-up a key word, you add the letters and look in the array. You will have just one word waiting for you, possibly two.
Each jiffy, record the location of code that was running. Now, make a chart so you see what code is taking the most time. You will see that most of the time is in a certain spot. Nothing else matters!
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.
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.]
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).
5 comments
[ 2.6 ms ] story [ 20.0 ms ] threadAll 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.
A thousand line switch statement is not a thousand if-then-elses. It is not a binary-search of 10 if-then-elses. It is a single jump indexing a table of code addresses. A thousand-case switch statement is one instruction.
Take a 1024 sized array of link lists. Add the letters of words bitshifting by one each letter to make a hash function. Now, populate the array and push onto the link-list if collisions. To look-up a key word, you add the letters and look in the array. You will have just one word waiting for you, possibly two.
Each jiffy, record the location of code that was running. Now, make a chart so you see what code is taking the most time. You will see that most of the time is in a certain spot. Nothing else matters!
----
You india niggers are painfully obtuse.
In the Bible, forgive your brother 7 times.
Moses was in the desert 40 years.
Jesus was in the desert 40 days.
Jews were slaves 400 years.
Noah was on the boat 40 days.
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.
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.]