Re: Baby X is bor nagain

On 20/06/2024 18:58, bart wrote:

On 20/06/2024 16:07, David Brown wrote:

On 20/06/2024 15:37, bart wrote:

On 20/06/2024 11:34, David Brown wrote:

 

I've only been discussing Python as an example of how many programming tasks are easier in high-level languages than in C.

 A lot of it seems to be incantations that you can only come up as an expert user. I wouldn't have been able to come up with even basic file-reading; I'd have to go and look up examples, every time.

I am not a Python expert.  I am experienced, yes, but I would not call myself an expert.  But sure, look things up - it's quite easy to do these days.

 

I seem to remember you getting really worked up about C programmers using the same identifier for structs and variables!

 Yes, you can have both 'struct T' and a type, variable etc called 'T'; or a type 'T' and, due to case sensitivity, a variable or function called 't'.
 But those identifiers in C are still fixed at compile-time. You can't so this:
      printf = sqrt;
 In Python (not 2.x where 'print' was a reserved word), you can:
      print = math.sqrt
 

Yes.
Sometimes that kind of thing is extremely useful, especially during testing or debugging.  Suppose you've got the function sqrt, and it is causing you trouble.  Let's get the function from:
from math import sqrt
(It doesn't matter if it is a library function, a built-in function, or your own function.)
We want to trace when it is called:
def debug_wrapper(f) :
    def wrapped(x) :
         print("Trying value ", x)
        return f(x)
    return wrapped
Now we can write :
sqrt = debug_wrapper(sqrt)
And every time the "sqrt" function is called after that, it is traced.
There's lots of things in Python that can be useful to some people at some time, even if /you/ can't see the use for them.  (There are no doubt lots of things that I can't see the use for either.  I'm reasonably confident, however, that either /someone/ sees them as useful, or they are a side-effect of other useful features.  Contrary to your firmly held beliefs, people do not design programming languages solely with the aim of annoying you personally.)

 

Both have mutable elements. Neither allow arbitrary attributes (so impossible to misspell member names). And if the FFI demands it, pointers to structs or ints can be passed.

>
You can do all this with Python.  I showed you how to have structures with mutable elements - and immutable structures, and structures with or without the ability to add new fields.

 I mentioned 5 ways of doing it, you added one or two more. That is my point: when a simple feature isn't built in, solutions have to be provided in lots of disparate ways.

I mentioned several ways, each with their advantages and disadvantages, and they each have their use in different situations.  You don't like choice?  Okay, don't use a language that has choices.

 I think your last one corresponded most to what I already have in my language, but it needed 3 special features to do it, plus maybe one more to hide some of those workings.
 Python is supposed to a good beginner's language not a DIY one.

Python has /never/ been a beginner's language.  It has always been a language that is relatively easy to use quickly - there's a very big difference there.  A beginner needing a structure type can google and get a quick answer on how to make such a type, and use it.  Or they can just make a class and get around the issue of being able to assign to new fields like "p.z" by simply not doing that.  Later, as they learn more, they can learn new techniques to fine-tune what they are trying to do.

 

>
But Python even then completely disregarded performance. In the 1990s, if you wrote a loop like this:
>
     for i in range(1000000):
         ....
>
it would actually create an object with a million elements so that you could iterate along it. It sounds absolutely crazy, and it was.
>
Later they added xrange() which didn't do that, and later on 'xrange' morphed into 'range'.
>

>
So your complaint now is that newer versions of Python have made some common tasks more efficient?  There's no pleasing some people.

  No, the complaint was getting it so wrong in the first place, then taking too long to fix it. (I think it was in Python 3 that you could type 'range' instead of 'xrange'.)
 

s = 0
for i in range(10000000) :
s = s + i
print(s)
(I made it 10 million, not 1 million, because I have such a vastly faster computer than everyone else.)
$ time python2 sum.py
49999995000000
real 0m0,820s
user 0m0,632s
sys 0m0,179s
$ time python3 sum.py
49999995000000
real 0m0,868s
user 0m0,854s
sys 0m0,004s
Python is not a racehorse, and never has been - that was never the point of the language.  You make less slow Python code by being more pythonic, such as "s = sum(range(10000000))" rather than using a loop.  And you make fast Python code by making sure the hard work is done by optimised low-level libraries (usually, but not always, written in C) while the Python code is for controlling it and gluing things together.