Re: Baby X is bor nagain

On 18/06/2024 10:56, Michael S wrote:

On Mon, 17 Jun 2024 15:23:55 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

I use Python rather than C because for
PC code, that can often involve files, text manipulation, networking,
and various data structures, the Python code is at least an order of
magnitude shorter and faster to write.  When I see the amount of
faffing around in order to read and parse a file consisting of a list
of integers, I find it amazing that anyone would actively choose C
for the task (unless it is for the fun of it).
>

 The faffing (what does it mean, BTW ?) is caused by unrealistic
requirements. More specifically, by requirements of (A) to support
arbitrary line length (B) to process file line by line. Drop just one
of those requirements and everything become quite simple.

"Faffing around" or "faffing about" means messing around doing unimportant or unnecessary things instead of useful things.  In this case, it means writing lots of code for handling memory management to read a file instead of using a higher-level language and just reading the file.
Yes, dropping requirements might make the task easier in C.  But you still don't get close to being as easy as it is in a higher level language.  (That does not have to be Python - I simply use that as an example that I am familiar with, and many others here will also have at least some experience of it.)

 For task like that Python could indeed be several times shorter, but
only if you wrote your python script exclusively for yourself, cutting
all corners, like not providing short help for user, not testing that
input format matches expectations and most importantly not reporting
input format problems in potentially useful manner.

No, even if that were part of the specifications, it would still be far easier in Python.  The brief Python samples I have posted don't cover such user help, options, error checking, etc., but that's because they are brief samples.

OTOH, if we write our utility in more "anal" manner, as we should if
we expect it to be used by other people or by ourselves long time after
it was written (in my age, couple of months is long enough and I am not
that much older than you) then code size difference between python and
C variants will be much smaller, probably factor of 2 or so.

Unless half the code is a text string for a help page, I'd expect a bigger factor.  And I'd expect the development time difference to be an even bigger factor - with Python you avoid a number of issues that are easy to get wrong in C (such as memory management).  Of course that would require a reasonable familiarity of both languages for a fair comparison.
C and Python are both great languages, with their pros and cons and different areas where they shine.  There can be good reasons for writing a program like this in C rather than Python, but C is often used without good technical reasons.  To me, it is important to know a number of tools and pick the best one for any given job.

 W.r.t. faster to code, it very strongly depends on familiarity.
You didn't do that sort of tasks in 'C' since your school days, right?
Or ever? And you are doing them in Python quite regularly? Then that is
much bigger reason for the difference than the language itself.

Sure - familiarity with a particular tool is a big reason for choosing it.

Now, for more complicated tasks Python, as the language, and even more
importantly, Python as a massive set of useful libraries could have
very big productivity advantage over 'C'. But it does not apply to very
simple thing like reading numbers from text file.

IMHO, it does.  I have slightly lost track of which programs were being discussed in which thread, but the Python code for the task is a small fraction of the size of the C code.  I agree that if you want to add help messages and nicer error messages, the difference will go down.
Here is a simple task - take a file name as an command-line argument, then read all white-space (space, tab, newlines, mixtures) separated integers.  Add them up and print the count, sum, and average (as an integer).  Give a brief usage message if the file name is missing, and a brief error if there is something that is not an integer.  This should be a task that you see as very simple in C.
#!/usr/bin/python3
import sys
if len(sys.argv) < 2 :
print("Usage: sums.py <input-file>")
sys.exit(1)
data = list(map(int, open(sys.argv[1], "r").read().split()))
n = len(data)
s = sum(data)
print("Count: %i, sum %i, average %i" % (n, s, s // n))

 In the real world, I wrote utility akin to that less than two years ago.
It converted big matrices from space delimited text to Matlab v4 .mat
format. Why did I do it? Because while both Matlab and Gnu Octave are
capable of reading text files like those, but they are quite slow doing
so. With huge files that I was using at the moment, it became
uncomfortable.
I wrote it in 'C' (or was it C-style C++ ? I don't remember) mostly
because I knew how to produce v4 .mat files in C. If I were doing it in
Python, I'd have to learn how to do it in Python and at the end it
would have taken me more time rather than less. I didn't even came to
the point of evaluating whether speed of python's functions for parsing
text was sufficient for my needs.
 

Of course if you don't know Python, it will be slower to write it in Python!
And there are times when Python /could/ be used, but C would be better - C has faster run-time for most purposes.  In many situations you can get Python to run fast, by being careful of the code structures you use, or using JIT tools, or using toolkits like numpy.  And of course these require additional development effort and learning to use.