[Tutor] a quick Q: how to use for loop to read a series of files with .doc end
lina.lastname at gmail.com
Sat Oct 8 18:51:14 CEST 2011
On Sat, Oct 8, 2011 at 11:34 PM, Alan Gauld <alan.gauld at btinternet.com>wrote:
> On 08/10/11 14:17, lina wrote:
> You will never say, "Gosh, I wish I knew FEWER programming languages!"
>> Ha Ha ...
>> regarding the python and C, I was told that python is good for interface
>> and others, but slow. and further was suggested to write the main part
>> in C and wrapped in python.
> The myth that Python (and interpreted languages in general) are too slow
> for "real programming" is common among older programmers(*) who were trained
> on old computers like the original PC and servers like the DEC PDP series.
> When I left university our office had just acquired the largest, most
> powerful VAX computer in Europe - it ran at 12MHz and had 16MB of RAM and
> supported over 100 users! Wow! However many. many, applications can now be
> written in interpreted languages and run fast enough (and the key word is
Wow .. I used to hate slow computer. Now I won't hate the retard (slow
reaction) lab computers any more. (It's a joke)
When I was in college, I needed to copy assignment to print it out.
I used floppy driver at that time, and the stores in campus put the floppy
driver near the cashier place with the gum and other candies. Now the gum
and other candies I guess are still there, but no floppy driver any more,
but probably some CDs or DVDs.
> If you really need the last bit of speed then yes, C (or even assembler)
> may be needed, but that is a tiny proportion of the code for most things. So
> to take your friends comment and turn it around:
> "... write the main part in Python (or .NET or Java or...) and write the
> speed critical parts in C."
> Because typically the Python part is likely to be 70-90% of the code
> and the C part much less.
> (*)I tend to consider myself in that group and up until about 15 years ago
> held the same view. But around then I got involved in projects using
> languages like Smalltalk, Tcl/Tk and VB. It was obvious that these languages
> were perfectly capable of producing usable apps
> on the typical hardware of the time - early Pentiums running at
> around 500MHz and with 128M RAM etc. Nowadays with most PCs having
> processors running in excess of 2GHz and over 2GB RAM there are very few
> apps that cannot be constructed using interpreted languages, and many are. I
> suspect the reason most commercial projects still use Java, C++ etc is
> 1) Magazines etc tend to review apps against their competition on speed,
> even if the real world speed measures are irrelevant. So for marketing
> purposes you must be seen to be comparable to your competitors.
> 2) Compiled code is harder for the competition to reverse engineer so
> coding secrets are 'safer'. (This is largely psychological since its the
> design concepts your competitors are more likely to steal, not the
> algorithmic details.)
> There are projects where ultimate speed is still important, indeed one of
> my current projects at work is being largely rewritten from C#.Net to
> compiled C++ for exactly that reason. (But it is a number crunching server
> app supporting around 15000 concurrent users) But the vast bulk of user
> programs could be written in interpreted languages IMHO. One of the
> interesting things about my recent conversion from Windows to Linux for my
> home PC is to see just how many of the desktop apps are written in Python,
> including games and office apps etc.
My initiative to learn python is that I noticed some (often used) apps are
written in python.
Another reason is that I want to learn (at least) one language deeper and
seriously (hopeful to have a happy ending in learning).
Thanks, I have forwarded this email to my friend.
> Alan G
> Author of the Learn to Program web site
> Tutor maillist - Tutor at python.org
> To unsubscribe or change subscription options:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tutor