You can do it that fast in pascal too. Like TRon already said. It's was the approach that was wrong.
In howardpc's and your defence (probably others as well, I haven't read the whole thread), initially you people had to work with the sample data (which in hindsight wasn't a good representation of the actual situation)
@mpknap
And of course there are the exceptions. If you are going to convert a decades old database that needs an upgrade, do you prefer speed over consistency ? I don't and will choose the slower more precise solution over any speedy one that might be sloppy. Time is usually of no concern in such cases (and if there is then those that put on the time-restriction can go play with themselves, as they had decades to think about their sloppy maintenance) (*)
That's why it's important to first think of what you want, set it on paper, have a design, and then (and not sooner) go programming.
Exactly.
@mpknap
Especially if it concerns a project that is actually a little over your head (for whatever reason). I usually look at the bigger picture first, write down that flow of the program and then try to split up the big(ger) chunks of the program in parts that I am still able to take on, again on paper. In case I need to use techniques (or topics) that I have never dealt with before, I can check those first in a (small) test-program before incorporating such parts into the final program. It's a balance between keeping the bigger picture in mind while at the same time working on detailed implementations. The more work you do beforehand (on paper) the easier it becomes to actually implement the code.
(*) Therefor, also in relation to what I wrote directly above, it is also important to think about things like speed beforehand. Sometimes it matters, sometimes it won't. More is not always better