Path: ...!news.nobody.at!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: Mon, 17 Jun 2024 18:38:40 +0200
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <v4poqg$o4fs$2@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> <v4pcia$lhgk$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 17 Jun 2024 18:38:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6eee6dfb82180fb756db1a7758fc4b5a";
	logging-data="791036"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/SJchgVo6+kq6D8nA8mvEtUapoAuYt4a0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:lOz/g67/vKc3ZEek/CAr33e2Nr0=
Content-Language: en-GB
In-Reply-To: <v4pcia$lhgk$2@dont-email.me>
Bytes: 5023

On 17/06/2024 15:09, Malcolm McLean wrote:
> On 17/06/2024 07:22, James Kuyper wrote:
>> On 6/13/24 10:43, Michael S wrote:
>>> On Thu, 13 Jun 2024 13:53:54 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>> ...
>>>> I know more than most C programmers about how certain C compilers
>>>> work, and what works well with them, and what is relevant for them -
>>>> though I certainly don't claim to know everything. Obviously Bart
>>>> knows vastly more about how /his/ compiler works. He also tends to
>>>> do testing with several small and odd C compilers, which can give
>>>> interesting results even though they are of little practical
>>>> relevance for real-world C development work.
>>>>
>>>
>>> Since he do compilers himself, he has much better feeling [that you
>>> or me] of what is hard and what is easy, what is small and what is big,
>>> what is fast and what is slow. That applies to all compilers except
>>> those that are very unusual. "Major" compiler are not unusual at all.
>>
>> The problem is that Bart's compiler is VERY unusual. It's customized for
>> his use, and he has lots of quirks in the way he thinks compilers should
>> work, which are very different from those of most other programmers. In
>> particular, compilation speed is very important to him, while execution
>> speed is almost completely unimportant, which is pretty much the
>> opposite of the way most programmers prioritize those things.
>>
>>
>>
> Yes, but that's probably what you want. 

Who is "you" here?  Possibly "you" is Bart, but it is certainly not /me/.

> As a one man band, bart can't 
> bear Aple and Microsoft in priiducing a compiler which creates highly 
> optimised code that executes quickly. And that's what the vast majority 
> of customers want.

I believe I can figure out the words you used, despite the spelling 
mistakes, but I can't figure out what you are trying to say.  One man 
band developers generally want the best tools they can get hold of, 
within the limits of their budgets - home-made tools can be part of 
that, but not for something like a C compiler.

> But say that 0.1% of customers are more interested in compilation speed. 
> Now, Apple and Microsoft might not even bother catering to, what is to 
> them, just a tiny market and a disraction for the development team. So 
> bart can plausibly produce a compiler which does compile code correctly, 
> and much faster than the big boys. And there are about 28 million pepole 
> in the world who derive thetr living as computer programmers. 0.1% of 
> that is 28,000, Charge 10 dollars each, and that's a nice little 
> business for one person.
> 

Your connection with reality is tenuous at best.

People /do/ like faster compilation speed, though it is rarely a problem 
in practice for C.  But no one who has used a real C compiler would want 
to step down to Bart's tool just to shave a second off their build times.

It is quite believable that some people will find big tools intimidating 
and want something that they view as smaller and simpler, but not for 
compiler speed.  And that market is already saturated by things like 
lcc-win and tcc.  (These are, unlike Bart's tool, compilers that make a 
significant effort to be correct for standard C.  Bart's compiler is 
made for his own use only, and is only likely to be correct for the 
subset of C that he wants to use.  There's absolutely nothing wrong with 
that, but his tool is far from being ready to sell to others as a C 
compiler.)