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.