Deutsch   English   Français   Italiano  
<vhitp3$214qq$1@dont-email.me>

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

Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mark Bourne <nntp.mbourne@spamgourmet.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Tue, 19 Nov 2024 20:51:47 +0000
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <vhitp3$214qq$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <b681ee05856e165c26a5c29bf42a8d9d53843d6d@i2pn2.org>
 <vg2ttn$3a4lk$1@dont-email.me> <vg33gs$3b8n5$1@dont-email.me>
 <vg358c$3bk7t$1@dont-email.me> <vg37nr$3bo0c$1@dont-email.me>
 <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me>
 <vg62vg$3uv02$1@dont-email.me> <vgd3ro$2pvl4$1@paganini.bofh.team>
 <vgdc4q$1ikja$1@dont-email.me> <vgdt36$2r682$2@paganini.bofh.team>
 <vge8un$1o57r$3@dont-email.me> <vgpi5h$6s5t$1@paganini.bofh.team>
 <vgtsli$1690f$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 19 Nov 2024 21:51:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="00403f09d4b8cbdb6daa7e6c3d2b3003";
	logging-data="2134874"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QSC2UDTDJqDmTvkUqg/mc"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 SeaMonkey/2.53.19
Cancel-Lock: sha1:O059tDgfzRbeiDuyaiKwtBo0l/M=
In-Reply-To: <vgtsli$1690f$1@dont-email.me>
Bytes: 3311

Bart wrote:
> On 10/11/2024 06:00, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>> I'd would consider a much elaborate one putting the onus on external
>>> tools, and still having an unpredictable result to be the poor of the 
>>> two.
>>>
>>> You want to create a language that is easily compilable, no matter how
>>> complex the input.
>>
>> Normally time spent _using_ compiler should be bigger than time
>> spending writing compiler.  If compiler gets enough use, it
>> justifies some complexity.
> 
> That doesn't add up: the more the compiler gets used, the slower it 
> should get?!

I may have misunderstood, but I don't think Waldek's comment was a claim 
about how long a single compilation should take / how slow the compiler 
should be made to be.  I think it was a statement about the total amount 
of time all users of a compiler can be expected to spend using it in 
comparison to the time compiler developers spend writing it.

If a compiler is used by a significant number of people, the total 
amount of time users spend using it is far larger than the total amount 
of time developers spend writing it, regardless of how long a single 
compilation takes.  So overall it's worth the compiler developers 
putting in extra effort to make the compiler more useful, provide better 
diagnostics, etc. rather than just doing whatever's easiest for them. 
That may only save each user a relatively small amount of time, but 
aggregated over all users of the compiler it adds up to a lot of time saved.

When a compiler is used by only a small number of people (or even just 
one), it's not worth the compiler developer putting a lot of effort into 
it, when it's only going to save a small number of people a small amount 
of time.

-- 
Mark.