On Friday 22 October 2010 18:05:03 William L. Thomson Jr. wrote: > On Fri, 2010-10-22 at 17:25 -0400, Steve Litt wrote:
> > But here's the facts. There's not a typist on earth who can outrun UMENU > > on a modern computer running Linux. From the typist's view, UMENU's > > response is instantaneous. So tell me one more time just so I understand > > -- why should I make it faster? > > Does it make a user wait at all for any amount of time? None, nada, zero. Before the user's finger leaves the last key struck, the new menu is already complete on the screen and ready to receive input. > How many users > of that application are there? My guess would be hundreds > Multiply the delay by the amount of user, > and see if that maybe is justifiable for porting to a more efficient > language or recoding. 0 x anything = 0 > > > Now let me enumerate the advantages of Perl over C: > > Whats Perl written in? Yeah, the Perl tool is a great example of something better written in C. But most of the stuff I write, even when used extensively, is better written in Perl. > > One could say Perl was created so you didn't have to learn or code in C. > Or maybe to do things not possible in a shell script, not to do with C. > One could also say Windows exists do you don't have to learn the command > line, just how to move and click a mouse. > > > But in the following situations I'll use Perl over C every time: > > > > * Speed bottleneck is the user's response > > Not clear on that one, if you mean users response to Perl being a > bottleneck vs C. Well they are correct, if the bottleneck has any > noticeable effect as in a delay. Next time you use your word processor, type as fast as you can and see if you can type faster than it can show the new character and reformat. If yes, then there is a justification for speed improvement. If no, you need speed improvement like a hen needs a flag. > > > * The process is done *rarely*, and the difference is 2 seconds vs 2 > > minutes > > Times how many users losing 2 seconds? For argument's sake, say a hundred million. Each uses it rarely. If each loses 2 seconds a day, so what? Now look at the other side of the situation. If I had a hundred million users, but I could not afford the time to code in C and as a result didn't code it at all, a hundred million users would not have a program they consider very useful. If the 2 seconds a day were REALLY a problem, heck, my stuff is free software, someone would re-code it in C. > > > * A better, simpler, faster algorithm can be found > > Simpler yes, better arguable, faster maybe in some situations Faster often. True story -- I used to write conversion programs, in Turbo Pascal, for the submission of medical forms and data. The other programmer on the project was the author of a Turbo Pascal book. He and I split up the hundreds of programs needing to be done. One day the boss man asked me to fix the other programmer's program, which ran incredibly slowly. A few diagnostic prints with corresponding times pointed an accusing finger at his string shift routine. Looking at it, I saw that his algorithm shifted one character at a time, and if the incoming shift length argument was 20, it single shifted the whole string twenty times. Gee, I wonder why it was slow! I replaced his quick and dirty with the normal way to implement a string shift, and bang, the program ran lightning quick. Now here's the thing. I could have coded my algorithm in 1996 Java (remember that?) and his algorithm in assembler, and mine still would have run faster for large shift values. This happens all the time. In about 2003 I upgraded my LyX (http://www.lyx.org) and all of a sudden I was seriously out-typing the program, and I type only 50 WPM. This only happened on long documents (I think I was writing a 50K word book). So I submitted the bug, and the programmer came back with a sheepish smile (via email) noting that he'd coded one algorithm wrong, in such a way that performance depended on the document length. He fixed the algorithm and LyX was its usual lightning fast self. What he didn't do was try to code part of it in assembler -- the algorithm was defective, and you don't perfume over that with a faster box or a faster programming language. SteveT Steve Litt Recession Relief Package http://www.recession-relief.US Twitter: http://www.twitter.com/stevelitt --------------------------------------------------------------------- Archive http://marc.info/?l=jaxlug-list&r=1&w=2 RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml Unsubscribe [email protected]
