Deutsch   English   Français   Italiano  
<v5rumo$j4ru$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!3.eu.feeder.erje.net!feeder.erje.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: Sun, 30 Jun 2024 17:47:35 +0200
Organization: A noiseless patient Spider
Lines: 92
Message-ID: <v5rumo$j4ru$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me> <v53i4s$33k73$2@dont-email.me>
 <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me>
 <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com>
 <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com>
 <v5c86d$11ac7$1@dont-email.me> <JEheO.108086$ED9b.74955@fx11.iad>
 <v5cblg$11q0j$1@dont-email.me> <gEieO.108089$ED9b.25598@fx11.iad>
 <20240625113616.000075e0@yahoo.com> <mUzeO.141609$Cqra.55051@fx10.iad>
 <v5elql$1jmii$1@dont-email.me> <m3BeO.24907$Gurd.16179@fx34.iad>
 <v5empd$1jndv$2@dont-email.me> <v5eph4$1k6a9$1@dont-email.me>
 <87ed8jnbmf.fsf@bsb.me.uk> <v5jhls$2m7np$1@dont-email.me>
 <v5jm32$2nqvp$1@dont-email.me> <v5k3v2$2qllm$1@dont-email.me>
 <v5kfst$2svt3$1@dont-email.me> <v5kmlm$2u918$1@dont-email.me>
 <20240627201830.854@kylheku.com> <v5m2nl$39qob$3@dont-email.me>
 <v5ohno$3rjfp$1@dont-email.me> <v5oq5o$3srp8$1@dont-email.me>
 <v5r75b$es9v$1@dont-email.me> <v5rd69$g046$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 30 Jun 2024 17:47:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a67f68932af5dd7fc1572c8c71e0fe76";
	logging-data="627582"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19G1v0msa9QNoWv26LYoyEBwi/8GQPqCPc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
Cancel-Lock: sha1:goHAtYV/ZyudFTtoDzn84nEmsgE=
Content-Language: en-GB
In-Reply-To: <v5rd69$g046$1@dont-email.me>
Bytes: 5906

On 30/06/2024 12:48, bart wrote:
> On 30/06/2024 10:05, David Brown wrote:
>> On 29/06/2024 13:11, bart wrote:
> 
>>
>>> If there was some elaborate checker for Python code, or you had an 
>>> extensive test suite that executed all lines of the program to check 
>>> you hadn't mispelled anything, I expect you wouldn't to run those 
>>> after every minor edit.
>>>
>>
>> No, not after every edit.  But then, I don't compile my C code after 
>> every edit.  It depends on the size and type of the edit.  Some checks 
>> - such as for misspelling - /are/ done continuously during editing, at 
>> least to some extent.  A decent IDE or editor will help there.
> 
> 
> An IDE or editor which presumably uses some fast aspects of fast 
> compilation to give you real-time feedback.
> 

There's no compilation involved - there is some code analysis for syntax 
highlighting, identifying types (and therefore things like struct 
members), structure analysis, and so on.

> I don't use such smart tools and so rely on such feedback from the 
> compiler.
> 

I prefer to use the best tools available.  I might use a simple editor 
for remote (ssh) work for minor tasks, but editors which do reasonable 
highlighting are common and easily available.

> Many edits to my source code (I realised this last night) consist of 
> commenting or uncommenting one line of code, eg. that may call or not 
> call some routine, or changing some internal flag to enable something or 
> other, eg. to show extra diagnostics. Or inserting or removing an early 
> return. Or adding or removing or commenting out some diagnostic print 
> statements.
> 
> This is not working on the logic of some complex algorithm. It's 
> changing something on a whim (maybe calling that fixup routine or not) 
> and needing instant feedback. Here I don't need any deep analysis!
> 
> If compilation took a minute, then I might have to use command-line 
> options instead of editing an internal flag or using commenting. I might 
> need to use (or develop) a debugger to avoid recompiling. I'd have to 
> revert (in my language) to independent compilation so I'd only need to 
> compile a small part after any change.
> 
> I'd have to use some smart editor to tell me things quicker than a 
> compiler would (if such an editor understood my language).
> 
> This does not sound appealing. More like going back decades.
> 

I really think you have everything backwards.  Decades ago, I used the 
kind of editors you say you use, before I had access to better choices. 
(At one time, I paid quite a bit of money for a good editor.)

> Perhaps you can understand better why more-or-less instant compilation 
> can be a useful thing, it eliminates the need for those cumbersome 
> external solutions, and it keeps my own tools simple.
> 

No, I can't.

> It opens up possibilities.
> 

It opens possibilities for doing lots more manual work, making more 
mistakes, finding those mistakes later, and generally working in a way 
most people were glad to move away from a generation ago.

Fast compilation is fine and good in itself.  And I can understand 
feeling that giant IDE's like Eclipse or MS Code are bigger than you 
want, and take time to learn.  But it is incomprehensible to me that 
you'd /want/ to use such limited tools as you do.

> 
>>> That is what gcc is like to me. There is no fluency. YMMV.
>>
>> It is possible to have your cake and eat it.  You think this is all a 
>> binary choice - it is not.  You can have smooth and fluent development 
>> /and/ powerful checking /and/ efficient generated code /and/ 
>> full-featured tools.
> 
> And you could have C development that works just like Python (well, 
> minus its bundled libraries).

I would prefer Python development that worked as well as my C development.