On 11.11.2024 11:06, Muttley@DastartdlyHQ.org wrote:
>
> Yes, Python does have a lot of cons as a language. But its syntax lets
> newbies get up to speed quickly

and to abruptly get stopped again due to obscure, misleading, or
(at best), non-informative error messages

> and there are a lot of libraries. However its
> dog slow and inefficient and I'm amazed its used as a key language for AI

(and not only there; it's ubiquitous, it seems)

> development - not traditionally a newbie coder area - when in that application
> speed really is essential. Yes it generally calls libraries written in C/C++
> but then why not just write the higher level code in C++ too?

Because of its simpler syntax and less syntactical ballast compared
to C++?

Janis

On Tue, 12 Nov 2024 10:14:20 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>On 11.11.2024 11:06, Muttley@DastartdlyHQ.org wrote:
>> and there are a lot of libraries. However its
>> dog slow and inefficient and I'm amazed its used as a key language for AI
>
>(and not only there; it's ubiquitous, it seems)

Yes, certainly seems to be the case now.

>> development - not traditionally a newbie coder area - when in that
>application
>> speed really is essential. Yes it generally calls libraries written in C/C++
>> but then why not just write the higher level code in C++ too?
>
>Because of its simpler syntax and less syntactical ballast compared
>to C++?

When you're dealing with something as complicated and frankly ineffable as
an AI model I doubt syntactic quirks of the programming language matter that
much in comparison. Surely you'd want the fastest implementation possible and
in this case it would be C++.

On 11.11.2024 22:24, Lawrence D'Oliveiro wrote:
> On Mon, 11 Nov 2024 07:31:13 -0000 (UTC), Sebastian wrote:
>
>> In comp.unix.programmer Muttley@dastartdlyhq.org wrote:
>>
>>> [Perl’s] syntax is also a horrific mess. Larry took the worst parts of
>>> C and shell syntax and mashed them together.
>>
>> I think you've identified the one language that Python is better than.
>
> In terms of the modern era of high-level programming, Perl was the
> breakthrough language. Before Perl, BASIC was considered to be an example
> of a language with “good” string handling. After Perl, BASIC looked old
> and clunky indeed.

I'm not, erm.., a fan of Perl or anything, but comparing it to BASIC
is way off; Perl is not *that* bad. - N.B.: Of course no one can say
what "BASIC" actually is given the many variants and dialects. - I'm
sure you must have some modern variant in mind that might have little
to do with the various former BASIC dialects (that I happened to use
in the 1970's; e.g., Wang, Olivetti, Commodore, and a mainframe that
I don't recall).

It's more interesting what Perl added compared to BRE/ERE, what Unix
provided since its beginning (and long before Perl).

>
> Perl was the language that made regular expressions sexy. Because it made
> them easy to use.

For those of us who used regexps in Unix from the beginning it's not
that shiny as you want us to buy it; Unix was supporting Chomsky-3
Regular Expressions with a syntax that is still used in contemporary
languages. Perl supports some nice syntactic shortcuts, but also
patterns that exceed Chomsky-3's; too bad if one doesn't know these
differences and any complexity degradation that may be bought with it.

More interesting to me is the fascinating fact that on some non-Unix
platforms it took decades before regexps got (slooooowly) introduced
(even in its simplest form).

Janis

On 12.11.2024 10:21, Muttley@DastartdlyHQ.org wrote:
> On Tue, 12 Nov 2024 10:14:20 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>> On 11.11.2024 11:06, Muttley@DastartdlyHQ.org wrote:
>>> [ Q: why some prefer Python over C++ ]
>>
>> Because of its simpler syntax and less syntactical ballast compared
>> to C++?
>
> When you're dealing with something as complicated and frankly ineffable as
> an AI model I doubt syntactic quirks of the programming language matter that
> much in comparison.

Oh, I would look at it differently; in whatever application domain I
program I want a syntactic clear and well defined language.

> Surely you'd want the fastest implementation possible and
> in this case it would be C++.

Speed is one factor (to me), and expressiveness or "modeling power"
(OO) is another one. I also appreciate consistently defined languages
and quality of error catching and usefulness of diagnostic messages.
(There's some more factors, but...)

Janis

On Tue, 12 Nov 2024 10:31:58 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>On 12.11.2024 10:21, Muttley@DastartdlyHQ.org wrote:
>> On Tue, 12 Nov 2024 10:14:20 +0100
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>>> On 11.11.2024 11:06, Muttley@DastartdlyHQ.org wrote:
>>>> [ Q: why some prefer Python over C++ ]
>>>
>>> Because of its simpler syntax and less syntactical ballast compared
>>> to C++?
>>
>> When you're dealing with something as complicated and frankly ineffable as
>> an AI model I doubt syntactic quirks of the programming language matter that
>> much in comparison.
>
>Oh, I would look at it differently; in whatever application domain I
>program I want a syntactic clear and well defined language.

In which case I'd go with a statically typed language like C++ every time
ahead of a dynamic one like python.

>> Surely you'd want the fastest implementation possible and
>> in this case it would be C++.
>
>Speed is one factor (to me), and expressiveness or "modeling power"
>(OO) is another one. I also appreciate consistently defined languages
>and quality of error catching and usefulness of diagnostic messages.
>(There's some more factors, but...)

C++ is undeniably powerful, but I think the majority would agree now that
its syntax has become an unwieldy mess.

On 12.11.2024 10:53, Muttley@DastartdlyHQ.org wrote:
>
> In which case I'd go with a statically typed language like C++ every time
> ahead of a dynamic one like python.

Definitely!

I'm using untyped languages (like Awk) for scripting, though, but
not for code of considerable scale.

Incidentally, on of my children recently spoke about their setups;
they use Fortran with old libraries (hydrodynamic earth processes),
have the higher level tasks implemented in C++, and they do the
"job control" of the simulation tasks with Python. - A multi-tier
architecture. - That sounds not unreasonable to me. (But they had
built their system based on existing software, so it might have
been a different decision if they'd have built it from scratch.)

>
> C++ is undeniably powerful, but I think the majority would agree now that
> its syntax has become an unwieldy mess.

Yes. And recent standards made it yet worse - When I saw it the
first time I couldn't believe that this would be possible. ;-)

Janis

On 12/11/2024 14:05, Janis Papanagnou wrote:
> On 12.11.2024 10:53, Muttley@DastartdlyHQ.org wrote:
>>
>> In which case I'd go with a statically typed language like C++ every time
>> ahead of a dynamic one like python.
>
> Definitely!
>
> I'm using untyped languages (like Awk) for scripting, though, but
> not for code of considerable scale.
>
> Incidentally, on of my children recently spoke about their setups;
> they use Fortran with old libraries (hydrodynamic earth processes),
> have the higher level tasks implemented in C++, and they do the
> "job control" of the simulation tasks with Python. - A multi-tier
> architecture. - That sounds not unreasonable to me. (But they had
> built their system based on existing software, so it might have
> been a different decision if they'd have built it from scratch.)
>

My last major app (now over 20 years ago), had such a 2-language solution.

It was a GUI-based low-end 2D/3D CAD app, written in my lower level
systems language.

But the app also had an embedded scripting language, which had access to
the app's environment and users' data.

That was partly so that users (both OEMs and end-users) could write
their own scripts. To this end it was moderately successful as OEMs
could write their own add-on applications (for example, to help design
lighting rigs).

But I also used it exclusively for the GUI side of the application:
menus, dialogs, cursor control, layouts, the simpler file conversions
(eg. export my data models to 3DS format) while the native code parts
dealt with the critical parts: the 3D maths, managing the 3D models the
display drivers, etc.

The whole thing was perhaps 150-200Kloc (not including OEM or user
programs), which was about half static/compiled code and half
dynamic/interpreted.

(One of the original motivations, when it had to run on constrained
systems, was to allow a lot of the code to exist as standalone scripts,
which resided on floppy disks, and which ere only loaded as needed.)

On Tue, 12 Nov 2024 15:05:00 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>On 12.11.2024 10:53, Muttley@DastartdlyHQ.org wrote:
>> C++ is undeniably powerful, but I think the majority would agree now that
>> its syntax has become an unwieldy mess.
>
>Yes. And recent standards made it yet worse - When I saw it the
>first time I couldn't believe that this would be possible. ;-)

Unfortunately these days the C++ steering committee (or whatever its called)
simply seem to be using the language to justify their positions and keep
chucking in "features" that no one asked for or care about, with the end
result of the language becoming a huge mess that no single person could
ever learn (or at least remember if they tried).

Muttley@DastartdlyHQ.org writes:

> On Tue, 12 Nov 2024 10:14:20 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:

[...]

>>Because of its simpler syntax and less syntactical ballast compared
>>to C++?
>
> When you're dealing with something as complicated and frankly ineffable as
> an AI model I doubt syntactic quirks of the programming language matter that
> much in comparison. Surely you'd want the fastest implementation possible and
> in this case it would be C++.

I really wouldn't be so sure. :)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

[...]

>> Perl was the language that made regular expressions sexy. Because it made
>> them easy to use.
>
> For those of us who used regexps in Unix from the beginning it's not
> that shiny as you want us to buy it; Unix was supporting Chomsky-3
> Regular Expressions with a syntax that is still used in contemporary
> languages. Perl supports some nice syntactic shortcuts, but also
> patterns that exceed Chomsky-3's; too bad if one doesn't know these
> differences and any complexity degradation that may be bought with it.

By Chomsky-3 you mean a grammar of type 3 in the Chomsky hierarchy? And
that would be ``regular'' language, recognizable by a finite-state
automaton? If not, could you elaborate on the terminology?

> More interesting to me is the fascinating fact that on some non-Unix
> platforms it took decades before regexps got (slooooowly) introduced
> (even in its simplest form).

Such as which platform?

On Tue, 12 Nov 2024 10:23:38 +0100, Janis Papanagnou wrote:

> On 11.11.2024 22:24, Lawrence D'Oliveiro wrote:
>
>> Perl was the language that made regular expressions sexy. Because it
>> made them easy to use.
>
> ... Unix was supporting Chomsky-3
> Regular Expressions with a syntax that is still used in contemporary
> languages.

Not in anything resembling a general-purpose high-level language. That’s
what Perl pioneered.

On Tue, 12 Nov 2024 14:50:26 +0000, Bart wrote:

> But the app also had an embedded scripting language, which had access to
> the app's environment and users' data.

Did you invent your own scripting language? Nowadays you would use
something ready-made, like Lua, Guile or even Python.

On 12/11/2024 20:35, Lawrence D'Oliveiro wrote:
> On Tue, 12 Nov 2024 14:50:26 +0000, Bart wrote:
>
>> But the app also had an embedded scripting language, which had access to
>> the app's environment and users' data.
>
> Did you invent your own scripting language? Nowadays you would use
> something ready-made, like Lua, Guile or even Python.

At that (late 80s) I had to invent pretty much everything.

I still do, language-wise.

On 12.11.2024 17:50, Wolfgang Agnes wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>
> By Chomsky-3 you mean a grammar of type 3 in the Chomsky hierarchy? And
> that would be ``regular'' language, recognizable by a finite-state
> automaton? If not, could you elaborate on the terminology?

Yes. I hoped the term was clear enough. If I had used too sloppy
wording in my ad hoc writing I apologize for the inconvenience.

My point was about runtime guarantees and complexities (O(N)) of
Regexp processing, which are also reflected by the FSA model.

Janis

>>>>> "Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Lawrence> Perl was the language that made regular expressions
Lawrence> sexy. Because it made them easy to use.

I'm often reminded of this as I've been coding very little in Perl these
days, and a lot more in languages like Dart, where the regex feels like
a clumsy bolt-on rather than a proper first-class citizen.

There are times I miss Perl. But not too often any more. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

On Tue, 19 Nov 2024 18:43:48 -0800, Randal L. Schwartz wrote:

>>>>>> "Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> Lawrence> Perl was the language that made regular expressions
> Lawrence> sexy. Because it made them easy to use.
>
> I'm often reminded of this as I've been coding very little in Perl these
> days, and a lot more in languages like Dart, where the regex feels like
> a clumsy bolt-on rather than a proper first-class citizen.

Python has regexes as a bolt-on -- a library module, not a core part of
the language. But I think the way it leverages the core language -- e.g.
being able to iterate over pattern matches, and collecting information
about matches in a “Match” object -- keeps it quite useful in a nicely
functional way.

On Tue, 19 Nov 2024 18:43:48 -0800
merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
>>>>>> "Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>Lawrence> Perl was the language that made regular expressions
>Lawrence> sexy. Because it made them easy to use.
>
>I'm often reminded of this as I've been coding very little in Perl these
>days, and a lot more in languages like Dart, where the regex feels like
>a clumsy bolt-on rather than a proper first-class citizen.

Regex itself is clumsy beyond simple search and replace patterns. A lot of
stuff I've seen done in regex would have better done procedurally at the
expense of slightly more code but a LOT more readability. Also given its
effectively a compact language with its own grammar and syntax IMO it should
not be the core part of any language as it can lead to a syntatic mess, which
is what often happens with Perl.

On 20.11.2024 09:21, Muttley@DastartdlyHQ.org wrote:
> On Tue, 19 Nov 2024 18:43:48 -0800
> merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
>>
>> I'm often reminded of this as I've been coding very little in Perl these
>> days, and a lot more in languages like Dart, where the regex feels like
>> a clumsy bolt-on rather than a proper first-class citizen.
>
> Regex itself is clumsy beyond simple search and replace patterns. A lot of
> stuff I've seen done in regex would have better done procedurally at the
> expense of slightly more code but a LOT more readability. Also given its
> effectively a compact language with its own grammar and syntax IMO it should
> not be the core part of any language as it can lead to a syntatic mess, which
> is what often happens with Perl.

I wouldn't look at it that way. I've seen Regexps as part of languages
usually in well defined syntactical contexts. For example, like strings
are enclosed in "...", Regexps could be seen within /.../ delimiters.
GNU Awk (in recent versions) went towards first class "strongly typed"
Regexps which are then denoted by the @/.../ syntax.

I'm curious what you mean by Regexps presented in a "procedural" form.
Can you give some examples?

Personally I'm fine with the typical lexical meta-symbols in Regexps
which resembles the FSA and allows a simple transformation forth/back.

In practice, given that a Regexp conforms to a FSA, any Regexp can be
precompiled and used multiple times. The thing I had used in Java - it
was a library from Apache, IIRC, not the bulky thing that got included
later - was easily usable; create a Regexp object by a RE expression,
then operate on that same object. (Since there's still typical Regexp
syntax involved I suppose that is not what you meant by "procedural"?)

Janis

On Wed, 20 Nov 2024 11:51:11 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>On 20.11.2024 09:21, Muttley@DastartdlyHQ.org wrote:
>> On Tue, 19 Nov 2024 18:43:48 -0800
>> merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
>>>
>>> I'm often reminded of this as I've been coding very little in Perl these
>>> days, and a lot more in languages like Dart, where the regex feels like
>>> a clumsy bolt-on rather than a proper first-class citizen.
>>
>> Regex itself is clumsy beyond simple search and replace patterns. A lot of
>> stuff I've seen done in regex would have better done procedurally at the
>> expense of slightly more code but a LOT more readability. Also given its
>> effectively a compact language with its own grammar and syntax IMO it should
>> not be the core part of any language as it can lead to a syntatic mess,
>which
>> is what often happens with Perl.
>
>I wouldn't look at it that way. I've seen Regexps as part of languages
>usually in well defined syntactical contexts. For example, like strings
>are enclosed in "...", Regexps could be seen within /.../ delimiters.
>GNU Awk (in recent versions) went towards first class "strongly typed"
>Regexps which are then denoted by the @/.../ syntax.
>
>I'm curious what you mean by Regexps presented in a "procedural" form.
>Can you give some examples?

Anything that can be done in regex can obviously also be done procedurally.
At the point regex expression become unwieldy - usually when substitution
variables raise their heads - I prefer procedural code as its also often
easier to debug.

>In practice, given that a Regexp conforms to a FSA, any Regexp can be
>precompiled and used multiple times. The thing I had used in Java - it

Precompiled regex is no more efficient than precompiled anything , its all
just assembler at the bottom.

>then operate on that same object. (Since there's still typical Regexp
>syntax involved I suppose that is not what you meant by "procedural"?)

If you don't know the different between declarative syntax like regex and
procedural syntax then there's not much point continuing this discussion.

On 11/20/2024 2:21 AM, Muttley@DastartdlyHQ.org wrote:
> On Tue, 19 Nov 2024 18:43:48 -0800
> merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
>>>>>>> "Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> Lawrence> Perl was the language that made regular expressions
>> Lawrence> sexy. Because it made them easy to use.
>>
>> I'm often reminded of this as I've been coding very little in Perl these
>> days, and a lot more in languages like Dart, where the regex feels like
>> a clumsy bolt-on rather than a proper first-class citizen.
>
> Regex itself is clumsy beyond simple search and replace patterns. A lot of
> stuff I've seen done in regex would have better done procedurally at the
> expense of slightly more code but a LOT more readability.

Definitely. The most relevant statement about regexps is this:

> Some people, when confronted with a problem, think "I know, I'll use
> regular expressions." Now they have two problems.

attributed to Jamie Zawinski, see
https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/.

Obviously regexps are very useful and commonplace but if you find you
have to use some online site or other tools to help you write/understand
one or just generally need more than a couple of minutes to
write/understand it then it's time to back off and figure out a better
way to write your code for the sake of whoever has to read it 6 months
later (and usually for robustness too as it's hard to be sure all rainy
day cases are handled correctly in a lengthy and/or complicated regexp).

Ed.

Muttley@DastartdlyHQ.org writes:
> merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
>>>>>>> "Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>Lawrence> Perl was the language that made regular expressions
>>Lawrence> sexy. Because it made them easy to use.
>>
>>I'm often reminded of this as I've been coding very little in Perl these
>>days, and a lot more in languages like Dart, where the regex feels like
>>a clumsy bolt-on rather than a proper first-class citizen.
>
> Regex itself is clumsy beyond simple search and replace patterns. A lot of
> stuff I've seen done in regex would have better done procedurally at the
> expense of slightly more code but a LOT more readability. Also given its
> effectively a compact language with its own grammar and syntax IMO it should
> not be the core part of any language as it can lead to a syntatic mess, which
> is what often happens with Perl.

A mess is something which often happens when people who can't organize
their thoughts just trudge on nevertheless. They're perfectly capable of
accomplishing that in any programming language.

A real problem with regexes in Perl is that they're pretty slow for simple
use cases (like lexical analysis) and thus, not suitable for volume data
processing outside of throwaway code¹.

¹ I used to use a JSON parser written in OO-Perl which made extensive
use of regexes for that. I've recently replaced that with a C/XS version
which - while slightly larger (617 vs 410 lines of text) - is over a
hundred times faster and conceptually simpler at the same time.

On Wed, 20 Nov 2024 05:46:49 -0600
Ed Morton <mortonspam@gmail.com> boring babbled:
>On 11/20/2024 2:21 AM, Muttley@DastartdlyHQ.org wrote:
>> On Tue, 19 Nov 2024 18:43:48 -0800
>> merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
>>>>>>>> "Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>> Lawrence> Perl was the language that made regular expressions
>>> Lawrence> sexy. Because it made them easy to use.
>>>
>>> I'm often reminded of this as I've been coding very little in Perl these
>>> days, and a lot more in languages like Dart, where the regex feels like
>>> a clumsy bolt-on rather than a proper first-class citizen.
>>
>> Regex itself is clumsy beyond simple search and replace patterns. A lot of
>> stuff I've seen done in regex would have better done procedurally at the
>> expense of slightly more code but a LOT more readability.
>
>Definitely. The most relevant statement about regexps is this:
>
> > Some people, when confronted with a problem, think "I know, I'll use
> > regular expressions." Now they have two problems.

Very true!

>Obviously regexps are very useful and commonplace but if you find you
>have to use some online site or other tools to help you write/understand
>one or just generally need more than a couple of minutes to
>write/understand it then it's time to back off and figure out a better
>way to write your code for the sake of whoever has to read it 6 months
>later (and usually for robustness too as it's hard to be sure all rainy
>day cases are handled correctly in a lengthy and/or complicated regexp).

Edge cases are regex achilles heal, eg an expression that only accounted
for 1 -> N chars, not 0 -> N, or matches in the middle but not at the ends.

On 20.11.2024 12:30, Muttley@DastartdlyHQ.org wrote:
> On Wed, 20 Nov 2024 11:51:11 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>> On 20.11.2024 09:21, Muttley@DastartdlyHQ.org wrote:
>>> On Tue, 19 Nov 2024 18:43:48 -0800
>>> merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
>>>>
>>>> I'm often reminded of this as I've been coding very little in Perl these
>>>> days, and a lot more in languages like Dart, where the regex feels like
>>>> a clumsy bolt-on rather than a proper first-class citizen.
>>>
>>> Regex itself is clumsy beyond simple search and replace patterns. A lot of
>>> stuff I've seen done in regex would have better done procedurally at the
>>> expense of slightly more code but a LOT more readability. Also given its
>>> effectively a compact language with its own grammar and syntax IMO it should
>>> not be the core part of any language as it can lead to a syntatic mess,
>> which
>>> is what often happens with Perl.
>>
>> I wouldn't look at it that way. I've seen Regexps as part of languages
>> usually in well defined syntactical contexts. For example, like strings
>> are enclosed in "...", Regexps could be seen within /.../ delimiters.
>> GNU Awk (in recent versions) went towards first class "strongly typed"
>> Regexps which are then denoted by the @/.../ syntax.
>>
>> I'm curious what you mean by Regexps presented in a "procedural" form.
>> Can you give some examples?
>
> Anything that can be done in regex can obviously also be done procedurally.
> At the point regex expression become unwieldy - usually when substitution
> variables raise their heads - I prefer procedural code as its also often
> easier to debug.

You haven't even tried to honestly answer my (serious) question.
With your statement above and your hostility below, it rather seems
you have no clue of what I am talking about.

>
>> In practice, given that a Regexp conforms to a FSA, any Regexp can be
>> precompiled and used multiple times. The thing I had used in Java - it
>
> Precompiled regex is no more efficient than precompiled anything , its all
> just assembler at the bottom.

The Regexps are a way to specify the words of a regular language;
for pattern matching the expression gets interpreted or compiled; you
specify it, e.g., using strings of characters and meta-characters.
If you have a programming language where that string gets repeatedly
interpreted then it's slower than a precompiled Regexp expression.

I give you examples...

(1) DES encryption function

(1a) ciphertext = des_encode (key, plaintext)

(1b) cipher = des (key)
ciphertext = cipher.encode (plaintext)

In case (1) you can either call the des encription (decription) for
any (key, plaintext)-pair in a procedural function as in (1a), or
you can create the key-specific encryption once and encode various
texts with the same cipher object as in (1b).

(2) regexp matching

(2a) location = regexp (pattern, string)

(2b) fsm = rexexp (pattern)
location = fsm.match (string)

In case (2) you can either do the match in a string with a pattern
in a procedural form as in (2a) or you can create the FSM for the
given Regexp just once and apply it on various strings as in (2b).

That's what I was talking about.

Only if key (in (1)) or pattern (in (2)) are static or "constant"
that compilation could (but only theoretically) be done in advance
and optimizing system may (or may not) precompile it (both) to
[similar] assembler code. How should that work with regexps or DES?
The optimizing system would need knowledge how to use the library
code (DES, Regexps, ...) to create binary structures based on the
algorithms (key-initialization in DES, FSM-generation in Regexps).
This is [statically] not done.

Otherwise - i.e. the normal, expected case - there's an efficiency
difference to observe between the respective cases of (a) and (b).

>
>> then operate on that same object. (Since there's still typical Regexp
>> syntax involved I suppose that is not what you meant by "procedural"?)
>
> If you don't know the different between declarative syntax like regex and
> procedural syntax then there's not much point continuing this discussion.

Why do you think so, and why are you saying that? - That wasn't and
still isn't the point. - You said upthread

"A lot of stuff I've seen done in regex would have better done
procedurally at the expense of slightly more code but a LOT more
readability."

and I asked

"I'm curious what you mean by Regexps presented in a "procedural"
form.
Can you give some examples?"

What you wanted to say wasn't clear to me, since you were complaining
about the _Regexp syntax_. So it couldn't be meant to just write
regexp (pattern, string) instead of pattern ~ string
but to somehow(!) transform "pattern", say, like /[0-9]+(ABC)?x*foo/,
to something syntactically "better".
I was interested in that "somehow" (that I emphasized), and in an
example how that would look like in your opinion.
If you're unable to answer that simple question then just take that
simple regexp /[0-9]+(ABC)?x*foo/ example and show us your preferred
procedural variant.

But my expectation is that you cannot provide any reasonable example
anyway.

Personally I think that writing bulky procedural stuff for something
like [0-9]+ can only be much worse, and that further abbreviations
like \d+ are the better direction to go if targeting a good interface.
YMMV.

Janis

On 20.11.2024 12:46, Ed Morton wrote:
>
> Definitely. The most relevant statement about regexps is this:
>
>> Some people, when confronted with a problem, think "I know, I'll use
>> regular expressions." Now they have two problems.

(Worth a scribbling on a WC wall.)

>
> Obviously regexps are very useful and commonplace but if you find you
> have to use some online site or other tools to help you write/understand
> one or just generally need more than a couple of minutes to
> write/understand it then it's time to back off and figure out a better
> way to write your code for the sake of whoever has to read it 6 months
> later (and usually for robustness too as it's hard to be sure all rainy
> day cases are handled correctly in a lengthy and/or complicated regexp).

Regexps are nothing for newbies.

The inherent fine thing with Regexps is that you can incrementally
compose them[*].[**]

It seems you haven't found a sensible way to work with them?
(And I'm really astonished about that since I know you worked with
Regexps for years if not decades.)

In those cases where Regexps *are* the tool for a specific task -
I don't expect you to use them where they are inappropriate?! -
what would be the better solution[***] then?

Janis

[*] Like the corresponding FSMs.

[**] And you can also decompose them if they are merged in a huge
expression, too large for you to grasp it. (BTW, I'm doing such
decompositions also with other expressions in program code that
are too bulky.)

[***] Can you answer the question that another poster failed to do?

On Wed, 20 Nov 2024 16:38:24 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>On 20.11.2024 12:30, Muttley@DastartdlyHQ.org wrote:
>> Anything that can be done in regex can obviously also be done procedurally.
>> At the point regex expression become unwieldy - usually when substitution
>> variables raise their heads - I prefer procedural code as its also often
>> easier to debug.
>
>You haven't even tried to honestly answer my (serious) question.

You mean you can't figure out how to do something like string search and replace
procedurally? I'm not going to show you, ask a kid who knows Python or Basic.

>With your statement above and your hostility below, it rather seems

If you think my reply was hostile then I suggest you go find a safe space
and cuddle your teddy bear snowflake.