[Tutor] a quick Q: how to use for loop to read a series of files with .doc end

[lina]

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
> "enough").
>
> 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
> twofold:
> 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.
>

Here is the feedback:"

He is certainly right and we are agree:
I have to choose a program language because I cannot afford to learn a lot
of them;
when I have to choose it was early age compare to today; I do not really
care about
interface (a good command line interface is enough that can use (BASH/DASH)
script and can be incorporated in (BASH/DASH) script is enough for me);
I write mainly critical speed code and large memory code that are meant to
run as hug jobs over cluster (transportability is an issue;
my C code is really faster than my Maple code; interpreter language are good
for development of algorithm in view to write a fast C code;
speed does not involved human time but machine time; I do not really care
about candy interfaces; for human interface Python and alike are recommended
but BASH (and even DASH) can do very good job; I am not sure that a
scientist is more concerned with interface than with efficient code except
for
visual stuff; being very familiar with of a given language is certainly
better than  knowing superficially a lot of languages;
as a lot of interpreter languages, Python has a huge manual; C manual is
rather small; D is both a interpreter language and a compiler language:
it is why I want to learn D: no more need to write wrapper that can be
boring and that can be bottle neck.


Last, enter in the game rather than watching. Then you can get your opinion.
According to the question in the Subject, I guess that you still have a lot
to learn before to appreciate all this subtilitises.

"

I kept the content of the email intact.

Thanks,



>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
>
> ______________________________**_________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/**mailman/listinfo/tutor<http://mail.python.org/mailman/listinfo/tutor>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20111009/7687d62e/attachment-0001.html>