Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Thu, 20 Jun 2024 22:16:22 +0200
Organization: A noiseless patient Spider
Lines: 155
Message-ID: <v522mm$2nkhu$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me>
 <v49seg$14cva$1@raubtier-asyl.eternal-september.org>
 <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me>
 <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com>
 <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
 <v4okn9$flpo$2@dont-email.me> <20240617002924.597@kylheku.com>
 <v4pddb$m5th$1@dont-email.me> <20240618115650.00006e3f@yahoo.com>
 <v4rv0o$1b7h1$1@dont-email.me> <20240618184026.000046e1@yahoo.com>
 <v4sd75$1ed31$1@dont-email.me> <877celzx14.fsf@nosuchdomain.example.com>
 <v4u85k$1t2pu$2@dont-email.me> <v4ucmn$1u14i$1@dont-email.me>
 <v4v2br$22c0m$1@dont-email.me> <v4v5nu$230rh$2@dont-email.me>
 <v4vfrn$24rv6$1@dont-email.me> <v4vjs4$25vmc$1@dont-email.me>
 <v510k3$2hhli$1@dont-email.me> <v51bb8$2jhji$1@dont-email.me>
 <v51gjh$2k86b$1@dont-email.me> <v51n3h$2lmvr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 20 Jun 2024 22:16:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9d7749f7e81c9e7d460e8bf3b8cdae91";
	logging-data="2871870"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/mJaGfFvJSOHC+LHmehbD2cgrLNM4sQ2Y="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:eOE2rMCHzBk41PjhymlIGxtzOCY=
In-Reply-To: <v51n3h$2lmvr$1@dont-email.me>
Content-Language: en-GB
Bytes: 7397

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.