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 17:07:29 +0200
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <v51gjh$2k86b$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 20 Jun 2024 17:07:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="658fd1c388c737e8ccffa21e0a91fad6";
	logging-data="2760907"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+HibYksNFWbt2EOsb44FniFHlnbDIH3EI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:JF5DbRVPttA4eB1rjbTeXT7Zeew=
In-Reply-To: <v51bb8$2jhji$1@dont-email.me>
Content-Language: en-GB
Bytes: 6911

On 20/06/2024 15:37, bart wrote:
> On 20/06/2024 11:34, David Brown wrote:
>> On 19/06/2024 23:51, bart wrote:
> 
> [Discussing Python]
> 
>>> Pretty much everything can be assigned to (the only exception is 
>>> reserved words). Because every user identifer (even if declared with 
>>> def or class or module) is a variable.
>>
>> The concept of "variable" in Python is quite different from that of C. 
>> You can pretend they are similar for very simple Python snippets, but 
>> then you will end up thinking there are lots of arbitrary rules for 
>> when assignment and function parameters are by value or by reference.  
>> It is better to think that all "things" in Python are anonymous 
>> reference-counted objects on the heap.  When it looks like you have a 
>> variable, you actually just have a named reference to such objects. 
>> Imagine it more like your "variables" are all "void *" pointers or 
>> references, while all other types and structures are malloc'd.  These 
>> references have no type information - but the objects they point to 
>> are all strongly typed.  And the objects have reference-counted 
>> garbage collection.
> 
> You haven't given an opinion. I think this is an unnecessary aspect of 
> it, which also makes it harder to optimise, and to reason about.
> 

I haven't given an opinion, no - I am trying primarily to give facts 
here.  This is simply the way Python works, and if it did things 
differently, it would be a very different language.  So I am not sure it 
makes sense to give an opinion on this aspect of Python alone.

I quite like Python, and find it a useful language.  I have used it for 
some large gui programs, some backend server systems, some web server 
code, and countless small programs (or scripts, if you prefer the term) 
in test systems and utilities.  It is also my go-to language for 
single-use code.

Naturally, there are lots of things about it that I /don't/ like, as is 
always the case for any language.  And there will be some overlap with 
the things /you/ don't like about Python, as one would expect for such 
subjective opinions.  I don't, however, feel any need to list my 
dislikes of Python here in comp.lang.c, or even in comp.lang.python. 
I've only been discussing Python as an example of how many programming 
tasks are easier in high-level languages than in C.  I hadn't expected 
to have to justify that blindingly obvious fact to someone (not you) who 
has no idea about Python, nor to be giving tutorials to you to counter 
your pet peeves about the language.  I suppose I should not be 
surprised, however.



> My languages have perhaps a dozen categories of identifiers, known at 
> compile-time, which include variable names. Python has only one, a 
> 'variable'. It mean this is possible:
> 
>      def F(n): return n + 1
>      ...
>      F = 42
>      ....
>      F(x)                # will not work when F is 42

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

Some languages have a syntax and restrictions that lets them keep 
identifier namesspaces more separate, others can't.  Functions in Python 
are objects, as are types - so they cannot be a different category of 
identifier.  That's a language design choice with its pros and cons - it 
is not some sort of flaw, as you seem to imagine.

>>
>> Neither Python nor C++ throws in "every feature they can think of" - 
>> for both languages, there is a long process of proposals, discussions, 
>> testing, and consideration of the impact on the rest of the language, 
>> existing code, and possible future language features, before a feature 
>> is included.
> 
> And /then/ they include the feature! I've long given up keeping track.

They include the features they think will be useful and will fit well 
with the language, yes.  Surely that's not surprising?

> 
> 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.

> 
> 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.