There are definitely tradeoffs between ease of coding and speed of execution.

I started with Sinclair & Commodore Basics. Both very easy to code, both very slow comapred to the same programs coded in Z80 or 6502. The main difference was that a complex program written in 3 or 4 days in Basic might take 3 or 4 weeks to complete in assembly. An extreme example is an assembler intended for the unexpanded VIC-20. The basic version took a couple of weeks to complete, the final assembly version which offered symbolic assembly with module loading from tape or disk took a couple of years, but was 100x faster and used 1683 bytes of program code. A bloated version was completed in a couple of months but since that version used 3700+ bytes on a machine that had less than 3500 bytes available I did not consider it to be a usable application :D

Later when I managed a DEC MicroVAX I wrote a report generator. It was a very simple problem, generate 2 standard reports from the vendor supplied system and extract the information needed by production in the form of a third report. First version written in DCL took 15 minutes to digest the 2 reports, the second version written in C did the job in 10 secs. The first version was written in an afternoon. The second version took much longer as I needed to learn a new language to finish it. Still don't use C very much, perl is much easier and does an adequate job for my needs.

In general programs written in DCL take much less time to write, but much more time to execute. So for a one off that won't be used much write it in the slow easy to code language. For the program that won't be needed for a couple of years, but will be used hundreds of times a day assign a team of assembly programmers to code the program and pay for ongoing maintenance to make sure that the code is updated and ported to each new machine purchased. I still remember the mention of the retirement of the maintenance contract for last 2 DEC computers using TOPS-20 OS. One of them was being retired, so it was decided that since only 1 machine would still operate (legacy code :P ) It was in the best interests of DEC to transfer maintenance responsibility to the enduser. Someone earlier mentioned Boeing has this problem with solutions written in a manner that requires MS-DOS support. High level *slow* languages are usually much easier to port than are low level code highly optimized for that powerful machine purchased 30 yrs ago :D

Also beware of commercial off the shelf solutions. If you didn't buy the source code in a portable language, you'll be paying later to port all your data and procedures to the next "solution". Of course it is a 5 minute "programming" solution to most problems to check the software listings at NewEgg, but is a real headache when you find that the wonderful tool will no longer work with the new version of Windows/*nix/MacOS etc.

This problem is exacerbated by tweaking the source to run fastest on the hardware that was available at the time of creation. Get it running at an acceptable speed when written in a slower general purpose portable language and ongoing maintenance costs go through the floor. Get the source, train your coders to avoid fancy tricks and keep the optimizing compilers for your CURRENT hardware and OS up to date. No longer any need to rewrite the entire software library every few years. You won't have the fastest execution, but most businesses care more about the cost per transaction and are willing to buy more powerful hardware if the the total cost per transaction is lower than it would be if the money was invested in a programming team that would rewrite the code base and then tweak it every time the hardware changed.

JasonB (no@spam.com) on 2/20/08 wrote:
---------------------------
>Ray (a@b.c) on 2/20/08 wrote:
>---------------------------
>>I have no stake in the current thread, but I think it worth pointing out that the
>>"python is 50x slower than C" argument is somewhat misleading, as it is only true
>>for first-cut solutions to a problem.
>
>I actually quite like Python and I'm thinking of using it as an end-user macro language for our software.
>
>However, did say "an average of 50x slower", and not "python is 50x slower
>than C". If you look at the link I provided you can see cases where it was just
>as fast as C (regex-dna) and others where it is very close (pidigits, thread-ring).
>There are also others where it is nearly 300 times slower (recursive). You
>need to be careful with averages; my statement was intended to encourage the reader
>to look deeper and see the actual results. There is no question that it is less
>efficient in general, however, and as soon as programmers have to start putting
>in effort to improve the runtime efficiency, the purported "programmer productivity"
>benefits and the ease-of-use that David was talking about start to decline.
>
>>(Who has written more lines of C in his life than in any other language, regrettably)
>
>For me it's C++, but I think programmer productivity differences are overstated
>(probably a bit like the "50x slower than C" statement) -- either that, or I'm unusually
>fast at C++ or incredibly slow at Python. My main motive for wanting to use it for
>end users is that it is easier to teach them how to use it, since they aren't programmers,
>and I don't expect runtime efficiency to matter for the majority of their uses.