Re: Command Languages Versus Programming Languages

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

[...]