Am 10.03.2017 um 08:19 schrieb Geraldus:

"It is more important to have the right problem done the wrong way, than to have the wrong problem done the right way."

Sounds like a nonsense. Does "problem done the wrong way" implies the problem indeed isn't solved at all, doesn't it?

No, in that context, "done the wrong way" meant that Spaghetti code and similar abominations are okay if the program delivers. For which even today a case can be made if the program is just a one-shot explorative thing where nobody will ever spend a second look at the results or at the program code. Scientific computing often means fiddling with code to fiddle with data; you do dozens of throwaway programs, and if something of interest comes out, you can still write a reviewable one. Or not release the code at all because anybody in the community will write his/her own data validation code anyway.

On 10/03/2017, at 8:19 PM, Geraldus <heraldhoi@gmail.com> wrote:

"It is more important to have the right problem done the wrong way, than to have the wrong problem done the right way."

Sounds like a nonsense. Does "problem done the wrong way" implies the problem indeed isn't solved at all, doesn't it?

Absolutely not. I remember back in about 1979 reading a procedure published in an engineering journal and noticing at once that it took O(n**5) time when simple manipulations familiar to any good programmer would have made it O(n**2). To my way of thought that was "done the wrong way", but the engineers who wrote it were happy with what it did for them and the reviewers are apparently happy that it gave the right answers. Similarly, a program that needs 2MB of temporary data and opens a connection to Oracle, stuffs the data into a scratch table, and pulls it back later (without needing ACID and without using anything more than SELECT * FROM TABLE) is again to my mind doing it the wrong way, but if it gives the right answers fast enough, the goal donor may not care. The classic example from Java, bringing us back to the topic of lists and strings, is String dumpMap(HashMap<String,Thing> map) { String s = ""; for (Map.Entry<String,Thing> e : map.entrySet()) { s += "\t" + e.getKey() + "='" + e.getValue().toString() + "'\n"; } return s; } which takes quadratic time -- assuming Thing::toString() is cheap -- when using a StringBuilder would make it linear. This is taken from a real program I have been trying to clean up to make Java 1.8 stop complaining about it. Not my code, I hasten to add. The result is the result that the author intended -- at least that's true of the original rather messier code -- but it is done the wrong way. I have known something not unlike this make the difference between a program taking 0.5 seconds and the same program taking 5 minutes, so "done the wrong way" but not "wrong answers". At 5 minutes, the program was still in fact useful. This happened just last week and that one *was* my code. (Not in Java, and not string concatenation. Failing to purge useless but logically harmless data from a collection.)