Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 22 Nov 2024 20:33:24 +0100
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <vhqma5$1adbr$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
 <0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
 <uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
 <87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
 <ve83q2$33dfe$1@dont-email.me> <vgsbrv$sko5$1@dont-email.me>
 <vgtslt$16754$1@dont-email.me> <86frnmmxp7.fsf@red.stonehenge.com>
 <vhk65t$o5i$1@dont-email.me> <vhkev7$29sc$1@dont-email.me>
 <vhkh94$2oi3$1@dont-email.me> <vhkvpi$5h8v$1@dont-email.me>
 <875xohbxre.fsf@doppelsaurus.mobileactivedefense.com>
 <vhpp2q$15aen$1@dont-email.me>
 <87wmgvzdlh.fsf@doppelsaurus.mobileactivedefense.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 22 Nov 2024 20:33:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a15370d329738e752ba59c760f877a0e";
	logging-data="1389947"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/pFwURTbMTeciZpoWWvCj/"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:juEqifc6lyiqSRWM505ya3hpEOY=
In-Reply-To: <87wmgvzdlh.fsf@doppelsaurus.mobileactivedefense.com>
X-Enigmail-Draft-Status: N1110
Bytes: 4286

On 22.11.2024 12:56, Rainer Weikusat wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 20.11.2024 18:50, Rainer Weikusat wrote:
>>>[...]
>>> while (p < e && *p - '0' < 10) ++p;
>>>
>>> That's not too bad. And it's really a hell lot faster than a
>>> general-purpose automaton programmed to recognize the same pattern
>>> (which might not matter most of the time, but sometimes, it does).
>>
>> Okay, I see where you're coming from (and especially in that simple
>> case).
>>
>> Personally (and YMMV), even here in this simple case I think that
>> using pointers is not better but worse - and anyway isn't [in this
>> form] available in most languages;
> 
> That's a question of using the proper tool for the job. In C, that's
> pointer and pointer arithmetic because it's the simplest way to express
> something like this.

Yes, in "C" you'd use that primitive (error-prone) pointer feature.
That's what I said. And that in other languages it's less terse than
in "C" but equally error-prone if you have to create all the parsing
code yourself (without an existing engine and in a non-standard way).
And if you extend the expression to parse it's IME much simpler done
in Regex than adjusting the algorithm of the ad hoc procedural code.

> 
>> in other cases (and languages)
>> such constructs get yet more clumsy, and for my not very complex
>> example - /[0-9]+(ABC)?x*foo/ - even a "catastrophe" concerning
>> readability, error-proneness, and maintainability.
> 
> Procedural code for matching strings constructed in this way is
> certainly much simpler¹ than the equally procedural code for a
> programmable automaton capable of interpreting regexes.

The point is that Regexps and the equivalence to FSA (with guaranteed
runtime complexity) is an [efficient] abstraction with a formalized
syntax; that are huge advantages compared to ad hoc parsing code in C
(or in any other language).

> Your statement
> is basically "If we assume that the code interpreting regexes doesn't
> exist, regexes need much less code than something equivalent which does
> exist." Without this assumption, the picture becomes a different one
> altogether.

I don't speak of assumptions. I speak about the fact that there's a
well-understood model with existing [parsing-]implementations already
available to handle a huge class of algorithms in a standardized way
with a guaranteed runtime-efficiency and in an error-resilient way.

Janis

> [...]