The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 24/09/2024 23:36, Peter Flass wrote:
>> R Daneel Olivaw <Danny@hyperspace.vogon.gov> wrote:
>>> rbowman wrote:
>>>> On Tue, 24 Sep 2024 14:11:19 +0100, Sn!pe wrote:
>>>>
>>>>> No mention of ALGOL, the ALGorithmic Language? It was contemporaneous
>>>>> with both FORmula TRANslator and COmmon Business-Oriented Language.
>>>>> <https://en.wikipedia.org/wiki/ALGOL>
>>>>
>>>> ALGOL's impact on succeeding languages was much greater than its actual
>>>> use.
>>>>
>>>
>>> ALGOL60 was the language where a test of equality between two floating
>>> point numbers was actually a test of "close enough for ALGOL". If I
>>> want to test for "approximately equal" then I want a different operator.
>>> How well did it handle character strings? Any language which could not
>>> handle them was a language I wanted no part of.
>>>
>>
>> C is just pathetic at character strings.
>>
> Not really.
> They are clearly defined entities and you could construct any routines
> to manipualate them you liked
>
>

That’s like saying Assembler is great at handling strings. You cam write
routines to do whatever you want.

Another thing PL/I got from COBOL is “natural” string handling. Assign a
short string to a larger any the result is automatically blank-padded.
Assign a longer to a shorter and the longer is truncated, with or without
an error. The lengths are all handled by the compiler, so you never get
overruns. I don’t know what ALGOL does. Burroughs ALGOL-58 didn’t handle
strings well. Maybe ALGOL-60 fixed this.

--
Pete

Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
> Lawrence D'Oliveiro wrote this copyrighted missive and expects royalties:
>
>> On Tue, 24 Sep 2024 18:24:02 GMT, Charlie Gibbs wrote:
>>
>>> At the risk of planting flame bait <nudge, nudge>, here in North America
>>> Algol was generally considered the domain of computer science weenies,
>>> while FORTRAN and COBOL were used for applications in the Real World
>>> [tm] (science/engineering and business, respectively).
>>
>> It didn’t help that Algol-60 had nothing resembling standardized I/O
>> facilities, whereas these were an integral feature of both Fortran and
>> COBOL.
>>
>> This was remedied later in Algol-68, at the cost of adding a lot of
>> complexity.
>>
>> This was in the days before POSIX, of course, when every computer system
>> seemed to do I/O entirely differently. Most of those, um, idiosyncrasies,
>> have thankfully evaporated.
>>
>>> So does PL/I (or is it PL/1 this week?), which allowed data structures
>>> to be declared COBOL-style.
>>
>> PL/I was IBM’s attempt at a Grand Unification of both “business” and
>> “scientific” programming in one language. If you thought C++ programming
>> was full of surprises when your program did unexpected things, PL/I
>> invented the whole genre of “surprise-ridden programming language”.
>
> My C++ programs NEVER exhibit surprise! (Well, almost never :-D)
>
> I did a little bit of Algol the first couple years of college, using an
> acoustic modem to access some mainframe in Kansas City.
>
> Then they got a PDP machine, and I learned how to use RUNOFF. Typing in ALL
> CAPS.
>
> Did a fair amount of FORTRAN, too, include programming a lab system to run
> experiments, in grad school.
>

PL/I can surprise you because the language is so powerful. A lot of things
that other languages can’t do are handled by PL/I, but if you’re not aware
of the rules for stuff like data conversion the results might not be what
you expect. I still get bitten occasionally, and am left scratching my
head.

--
Pete

Scott Lurndal <scott@slp53.sl.home> wrote:
> Chris Ahlstrom <OFeem1987@teleworm.us> writes:
>> rbowman wrote this copyrighted missive and expects royalties:
>>
>>> On Wed, 25 Sep 2024 11:03:13 +0800, Woozy Song wrote:
>>>
>>>> When I went to uni in the 70s, the computer science lecturer had a
>>>> hard-on for Pascal, the latest and greatest. Always slipped in snide
>>>> remarks about BASIC or COBOL in most classes.
>>>
>>> Better Pascal than Modula/Modula-2. I swear as soon as anybody figured
>>> out how to do anything useful with one of his languages Wirth designed a
>>> new, more obscure version.
>>>
>>> https://www.modula2.org/tutor/chapter8.php
>>>
>>> Chapter 8 - Input/Output
>>> In preparation
>>>
>>> That sums it up. I've heard Wirth's languages described as programs that
>>> are designed to tell secrets to themselves.
>>
>> Wirth: His name is pronounced "virth" if by reference, and "worth" if by value.
>>
>> I found the original Pascal to be confining.
>>
>
> VAX-11 Pascal, on the other hand, was wonderful. Enough useful
> extensions to make it a very viable systems programming language.
>
>

As Lynne will be happy to tell you, the original IBM TCP/IP implementation
was written in IBM Pascal for VM/CMS.

--
Pete

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2024-09-25, 186282@ud0s4.net <186283@ud0s4.net> wrote:
>
>> COBOL ... well ... would rather NOT use it.
>> The whole "self documenting" idea turned out
>> to be crap - COBOL is *hard* to understand
>> sometimes.
>
> Yes, the dream of a language that a manager could read
> was rather naive. As Robert L. Glass (under the pseudonym
> Miles Benson) once wrote in his column in Computerworld:
> "His programs were so readable that he once had one
> published in the _Saturday Evening Post_."
>
> But it left a lot of room for humour, e.g. "The Common
> Business-Oriented Goldilocks", which tells the story
> in COBOL.
>
> I joined a PPOE at the same time as a new department head
> who was quite a character. Our inside sales manager,
> Al Tannock, popped in and said to him: "Say something
> in COBOL." Instantly our guy shot back:
>
> EXAMINE ROOM REPLACING ALL TANNOCKS WITH SPACES.
>

I’d love to get Glass’ books, but they seem to be unobtanium.

--
Pete

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 25 Sep 2024 08:34:51 -0700, John Ames wrote:
>
>> That's a marvelous description, although it fails to really capture the
>> perversity of things like array-size-as-type-distinction; when a man
>> introduces language features that practically every single third-party
>> implementor has to provide their own workaround for ...
>
> You realize ISO Pascal provided conformant array arguments for this
> purpose?
>
> Also, you realize that Wirth did not see Pascal as the last word in
> programming languages? That he went on to create others that solved this
> and other problems in nicer ways? That the fact that the rest of the world
> remained fixated on Pascal for some reason, was not really his problem?
>

If you’re trying to write real-world production code you can’t keep chasing
the language of the week. It doesn’t matter if something great and
wonderful comes out next month if you’ve standardized on “old faithful”,
have lots of programmers fluent in it, and have lots of code written in it.

Of course this wasn’t Wirth’s objective. He was playing around with
language ideas.

--
Pete

Pancho <Pancho.Jones@proton.me> wrote:
> On 9/25/24 16:03, Scott Lurndal wrote:
>> Chris Ahlstrom <OFeem1987@teleworm.us> writes:
>>> rbowman wrote this copyrighted missive and expects royalties:
>>>
>>>> On Wed, 25 Sep 2024 11:03:13 +0800, Woozy Song wrote:
>>>>
>>>>> When I went to uni in the 70s, the computer science lecturer had a
>>>>> hard-on for Pascal, the latest and greatest. Always slipped in snide
>>>>> remarks about BASIC or COBOL in most classes.
>>>>
>>>> Better Pascal than Modula/Modula-2. I swear as soon as anybody figured
>>>> out how to do anything useful with one of his languages Wirth designed a
>>>> new, more obscure version.
>>>>
>>>> https://www.modula2.org/tutor/chapter8.php
>>>>
>>>> Chapter 8 - Input/Output
>>>> In preparation
>>>>
>>>> That sums it up. I've heard Wirth's languages described as programs that
>>>> are designed to tell secrets to themselves.
>>>
>>> Wirth: His name is pronounced "virth" if by reference, and "worth" if by value.
>>>
>>> I found the original Pascal to be confining.
>>>
>>
>> VAX-11 Pascal, on the other hand, was wonderful. Enough useful
>> extensions to make it a very viable systems programming language.
>>
>
>
> Indeed, but a bitch to work out how to call Vax C from Vax Pascal, or
> vice versa. Life was so much harder before search engines and the internet.
>
>
>

I thought that was one of the VAX’s strong points. Common runtime for all
language and calling sequences explicitly spelled out.

--
Pete

On 26/09/2024 13:43, Lawrence D'Oliveiro wrote:
> On Thu, 26 Sep 2024 11:49:37 +0100, Pancho wrote:
>
>> On 9/26/24 11:10, Lawrence D'Oliveiro wrote:
>>>
>>> On Thu, 26 Sep 2024 08:42:32 +0100, Pancho wrote:
>>>
>>>> ... a bitch to work out how to call Vax C from Vax Pascal, or vice
>>>> versa.
>>>
>>> Why would it be that hard? VAX C passed everything by value, while
>>> Pascal let you specify descriptors, references, immediate value ... all
>>> the options.
>>
>> There ware decisions to be made, like what order do you push variables
>> onto the stack, when do you push the return address, how to interpret a
>> Pascal String in C.
>
> All these things were standardized in the VAX/VMS ABI, right from the
> beginning.

IIRC, VAX C did not completely follow the standard calling conventions,
which created some issues in mixed-language applications.

On 9/26/24 20:52, Peter Flass wrote:
> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>> On 9/24/24 8:26 AM, Lars Poulsen wrote:
>>> On 23/09/2024 23:45, 186282@ud0s4.net wrote:
>>>>    Hey, want "Real Computing" ? Try FORTRAN
>>>>    or COBOL. THOSE were the foundation and
>>>>    persist to this day. Wrote a FORTRAN app
>>>>    just a couple of years ago - mostly to vex
>>>>    the New Guys. Also a short COBOL app, that
>>>>    oughtta REALLY give 'em the shits !  :-)
>>>
>>> Back in 1985, I changed jobs from a University computer center, where we
>>> did our technical documentation using Univac's @DOC processor, to a
>>> small industrial computer system integration firm, where we built
>>> real-time systems on RSX-11M. I missed the @DOC so much that I wrote a
>>> re-implementation in FORTRAN IV. Used it for years afterwards, until I
>>> landed at a larger house doing communications work on Unix, and switched
>>> to /troff/.
>>
>>
>> Hey, FORTRAN *will* Get It Done as neatly as most
>> anything else. If you need many decades worth of
>> exotic math libs, you'll find them in FORTRAN too.
>> It is NOT an obsolete language/approach.
>>
>> For the younger people, note that Python carries
>> over a lot of FORTRAN ideas, including easy
>> string-slicing.
>>
>> If you can do BASIC then you can do FORTRAN, but
>> does anybody use BASIC anymore ? Intel/IBM did
>> sell BASCOM ... a BASIC compiler ... and it DID
>> speed up yer code like by 10X :-)
>>
>> COBOL ... well ... would rather NOT use it.
>> The whole "self documenting" idea turned out
>> to be crap - COBOL is *hard* to understand
>> sometimes. That's why COBOL programmers can
>> get really high-pay jobs these days, because
>> so much of that irreplacable biz software
>> from the 60s was writ in COBOL. Nobody can
>> AFFORD to re-write it. It worked, it works,
>> it was writ by REALLY GOOD narrow-tie Dilberts,
>> so you just have to MAINTAIN it like forever.
>>
>
> For a long time, FORTRAN was the only remotely portable language, so lots
> of programs were written in it.
>
Cobol was also very portable.

On 27/09/2024 01:51, Peter Flass wrote:
> rbowman <bowman@montana.com> wrote:
>> On Tue, 24 Sep 2024 21:14:04 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>>> PL/I was IBM’s attempt at a Grand Unification of both “business” and
>>> “scientific” programming in one language. If you thought C++ programming
>>> was full of surprises when your program did unexpected things, PL/I
>>> invented the whole genre of “surprise-ridden programming language”
>>
>> IBM was always so modest. Programming Language One. A Programming
>> Language.
>>
>
> Supposed to be NPL (New Programming Language) but some wonky organization
> in the UK was already using that,
>

The "wonky" organization is the National Physical Laboratory where,
among other achievements, the world's first caesium-133 atomic clock
was created.

--
Bill F.

On Thu, 26 Sep 2024 18:01:25 -0700, Lars Poulsen wrote:

> On 26/09/2024 13:43, Lawrence D'Oliveiro wrote:
>
>> On Thu, 26 Sep 2024 11:49:37 +0100, Pancho wrote:
>>
>>> On 9/26/24 11:10, Lawrence D'Oliveiro wrote:
>>>>
>>>> On Thu, 26 Sep 2024 08:42:32 +0100, Pancho wrote:
>>>>
>>>>> ... a bitch to work out how to call Vax C from Vax Pascal, or vice
>>>>> versa.
>>>>
>>>> Why would it be that hard? VAX C passed everything by value, while
>>>> Pascal let you specify descriptors, references, immediate value ...
>>>> all the options.
>>>
>>> There ware decisions to be made, like what order do you push variables
>>> onto the stack, when do you push the return address, how to interpret
>>> a Pascal String in C.
>>
>> All these things were standardized in the VAX/VMS ABI, right from the
>> beginning.
>
> IIRC, VAX C did not completely follow the standard calling conventions,
> which created some issues in mixed-language applications.

Being C, you had to explicitly write code to follow those conventions,
but the conventions were well-known. Looks like, unlike Pascal, DEC
did not add convenience built-in functions to help you construct the
right descriptors etc: you had to define these yourself.

See “Programming in VAX C 1.0”, chapter 9, “Mixed-Language
Programming”
<https://bitsavers.trailing-edge.com/pdf/dec/vax/lang/c/AA-L370A-TE_Programming_in_VAX_C_1.0_198205.pdf>.

On Thu, 26 Sep 2024 17:52:10 -0700, Peter Flass wrote:

> I thought that was one of the VAX’s strong points. Common runtime for
> all language and calling sequences explicitly spelled out.

Yes it was, and for languages like Fortran or Pascal, DEC added special
extensions to make it easier for them to interoperate in this way. Seems
like they didn’t bother with that for their C compiler -- I suppose they
figured C programmers didn’t need hand holding ...

On Thu, 26 Sep 2024 17:52:09 -0700, Peter Flass wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> Also, you realize that Wirth did not see Pascal as the last word in
>> programming languages? That he went on to create others that solved
>> this and other problems in nicer ways? That the fact that the rest of
>> the world remained fixated on Pascal for some reason, was not really
>> his problem?
>>
> If you’re trying to write real-world production code you can’t keep
> chasing the language of the week.

And yet you look at the major languages in use today, and they all
continue to bring out significant new revisions periodically, and
developers using those languages for real-world work do indeed adopt the
new features quite enthusiastically.

On Thu, 26 Sep 2024 17:52:04 -0700, Peter Flass wrote:

> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>> On 24/09/2024 23:36, Peter Flass wrote:
>>>
>>> C is just pathetic at character strings.
>>>
>> Not really.
>> They are clearly defined entities and you could construct any routines
>> to manipualate them you liked
>>
> That’s like saying Assembler is great at handling strings. You cam write
> routines to do whatever you want.

Yes it is exactly like that. Do you think that is somehow refuting the
point?

> Another thing PL/I got from COBOL is “natural” string handling. Assign a
> short string to a larger any the result is automatically blank-padded.

That kind of misfeature is only needed in the sad world of non-dynamic,
fixed-length strings ...

> That was one of the things holding up adoption. They fixed it with the
> “Optimizing Compiler”, but it was a bit late by then. PL/I(F) was all
> overlays. It kept the working text of the program in memory and made
> I-don’t-know how many passes thru it. Trying to make it fit in a 64K
> partition was a major problem.

Thirty-couple, iirc from looking at the source decks once.

De

On 9/26/24 12:18 PM, Charlie Gibbs wrote:
> On 2024-09-26, 186282@ud0s4.net <186283@ud0s4.net> wrote:
>
>> Hmm ... re-did a number of my fave funcs, mostly
>> for dealing with ascii-delimited strings/records,
>> in FORTRAN when I did my last little app to annoy
>> the new boyz. Gotta dig up that pgm and review.
>> PICK had "field(str,delim,fldnum)" which I always
>> found very useful, so that's usually the first thing
>> i'd move to another lang.
>
> One of the favourite functions in my library pulls the
> next token from a delimited string, but as opposed to
> strtok() it does it non-destructively and can handle
> empty strings.

NEVER liked "strtok()" ... but, with some ugliness,
it IS adaptable.

The PICK "field()" was just beautiful for picking
out exactly desired fields/subfields/sub-sub-fields
from any ascii-delimited string. Look at the docs
for Revelation/AREV to see how it works.

I always liked ascii-delimited multi-value records.
Hey, you can actually READ them. They are also VERY
easy and cheap for microcontrollers and such to
create on the fly.

>> Oh, one lang I can't stomach - ADA.
>
> What does the Americans with Disabilities Act have to do with
> programming? (Hint: "Ada" is not an acronym; the language is
> named after Ada Lovelace, reputedly the first programmer.)

:-)

As for lady Ada - apparently she was kinda
unbearable ... SUCH an egomaniac, SO assured of
her own math/IQ superiority and EAGER to rub
it in ........

However I will give her credit for seeing the
"wider view" of what the Babbage machine/approach
could deliver. Babbage only saw boring math - SHE
saw word-processing/analysis and beyond.

Ah, poor Babbage ... ENLIGHTENED vision, but only
GEARS AND COGS to work with ! 50+ years before
his ideal time .......

On Fri, 27 Sep 2024 02:45:23 -0400, 186282@ud0s4.net wrote:

> As for lady Ada ...

She saw further than anybody else what software would be about.

Now, imagine an alternate universe where she hadn’t died young. Imagine
that Charles Babbage hadn’t completely failed at building his Analytical
Engine. (Only it was called the “Difference Engine”, for some inexplicable
reason.)

Now imagine that the two of them get together to fight crime...

<https://sydneypadua.com/2dgoggles/>

On 9/27/24 02:36, Lawrence D'Oliveiro wrote:
> On Thu, 26 Sep 2024 18:01:25 -0700, Lars Poulsen wrote:
>
>> On 26/09/2024 13:43, Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 26 Sep 2024 11:49:37 +0100, Pancho wrote:
>>>
>>>> On 9/26/24 11:10, Lawrence D'Oliveiro wrote:
>>>>>
>>>>> On Thu, 26 Sep 2024 08:42:32 +0100, Pancho wrote:
>>>>>
>>>>>> ... a bitch to work out how to call Vax C from Vax Pascal, or vice
>>>>>> versa.
>>>>>
>>>>> Why would it be that hard? VAX C passed everything by value, while
>>>>> Pascal let you specify descriptors, references, immediate value ...
>>>>> all the options.
>>>>
>>>> There ware decisions to be made, like what order do you push variables
>>>> onto the stack, when do you push the return address, how to interpret
>>>> a Pascal String in C.
>>>
>>> All these things were standardized in the VAX/VMS ABI, right from the
>>> beginning.
>>
>> IIRC, VAX C did not completely follow the standard calling conventions,
>> which created some issues in mixed-language applications.
>
> Being C, you had to explicitly write code to follow those conventions,
> but the conventions were well-known. Looks like, unlike Pascal, DEC
> did not add convenience built-in functions to help you construct the
> right descriptors etc: you had to define these yourself.
>
> See “Programming in VAX C 1.0”, chapter 9, “Mixed-Language
> Programming”
> <https://bitsavers.trailing-edge.com/pdf/dec/vax/lang/c/AA-L370A-TE_Programming_in_VAX_C_1.0_198205.pdf>.

Ah! there we have the Internet and a Search engine. :-)

I'm not sure if I had that book or not. It looks like it is heavily
orientated to calling VMS system services from C. I think my problem was
calling C from Pascal. The application was Pascal based.

Reading this thread reminds me of that period. Everything was "simple"
if you were an expert in the byzantine system you were working on. Older
staff determined what was right and wrong, their knowledge of the system
was the supreme measure of competence. Knocking out working, useful,
applications was a secondary concern.

That company went bust. Tried to develop an SQL based system, the
hardware was nowhere near powerful enough.

On Thu, 26 Sep 2024 20:51:25 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Thu, 26 Sep 2024 16:18:01 GMT, Charlie Gibbs wrote:
>
> > One of the favourite functions in my library pulls the next token from a
> > delimited string, but as opposed to strtok() it does it
> > non-destructively and can handle empty strings.
>
> Use a high-level language which has all this and more:
>
> for item in "the,quick,brown,fox".split(",") :
> print(item)
> #end for
>
> Output:
>
> the
> quick
> brown
> fox
>
> In Python, strings are objects, and that applies to string expressions
> (including string literals) as well.

You need Rexx

--
Bah, and indeed Humbug.

On 27/09/2024 07:52, Lawrence D'Oliveiro wrote:
> [...] Imagine
> that Charles Babbage hadn’t completely failed at building his Analytical
> Engine. (Only it was called the “Difference Engine”, for some inexplicable
> reason.)

The Difference Engine was a completely different project. It was
called the Difference Engine because it was meant to calculate differences*,
which were the principal tools in numerical mathematics for the calculation
of values of functions [sine, cosine, sqrt, log, ...]. In the days before
computers, tables of such values were an essential part of the engineer's
[or physicist's or statistician's] toolkit and was what mathematicians often
spent their entire careers providing and checking. It was tedious work, so
was ripe for automation.

Babbage is remembered today for little more than these projects, but
he did much more than that. His Wiki article is worth reading, if only to
learn the breadth of his interests and contributions.
____
* Of course ...!

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Ganz

On 27/09/2024 11:32, Kerr-Mudd, John wrote:
> On Thu, 26 Sep 2024 20:51:25 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Thu, 26 Sep 2024 16:18:01 GMT, Charlie Gibbs wrote:
>>
>>> One of the favourite functions in my library pulls the next token from a
>>> delimited string, but as opposed to strtok() it does it
>>> non-destructively and can handle empty strings.
>>
>> Use a high-level language which has all this and more:
>>
>> for item in "the,quick,brown,fox".split(",") :
>> print(item)
>> #end for
>>
>> Output:
>>
>> the
>> quick
>> brown
>> fox
>>
>> In Python, strings are objects, and that applies to string expressions
>> (including string literals) as well.
>
> You need Rexx
>
NOBODY needs REGEX!

--
Renewable energy: Expensive solutions that don't work to a problem that
doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.

On Fri, 27 Sep 2024 11:32:05 +0100, Kerr-Mudd, John wrote:

> On Thu, 26 Sep 2024 20:51:25 -0000 (UTC) Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
>
>> On Thu, 26 Sep 2024 16:18:01 GMT, Charlie Gibbs wrote:
>>
>> > One of the favourite functions in my library pulls the next token
>> > from a delimited string, but as opposed to strtok() it does it
>> > non-destructively and can handle empty strings.
>>
>> Use a high-level language which has all this and more:
>>
>> for item in "the,quick,brown,fox".split(",") :
>> print(item)
>> #end for
>>
>> Output:
>>
>> the quick brown fox
>>
>> In Python, strings are objects, and that applies to string expressions
>> (including string literals) as well.
>
> You need Rexx

Hear, hear. Still use it.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Fri, 27 Sep 2024 12:10:37 +0100, The Natural Philosopher wrote:

> On 27/09/2024 11:32, Kerr-Mudd, John wrote:
>> On Thu, 26 Sep 2024 20:51:25 -0000 (UTC) Lawrence D'Oliveiro
>> <ldo@nz.invalid> wrote:
>>
>>> On Thu, 26 Sep 2024 16:18:01 GMT, Charlie Gibbs wrote:
>>>
>>>> One of the favourite functions in my library pulls the next token
>>>> from a delimited string, but as opposed to strtok() it does it
>>>> non-destructively and can handle empty strings.
>>>
>>> Use a high-level language which has all this and more:
>>>
>>> for item in "the,quick,brown,fox".split(",") :
>>> print(item)
>>> #end for
>>>
>>> Output:
>>>
>>> the quick brown fox
>>>
>>> In Python, strings are objects, and that applies to string expressions
>>> (including string literals) as well.
>>
>> You need Rexx
>>
> NOBODY needs REGEX!

Eyesight failing again?

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Thu, 26 Sep 2024 17:52:07 -0700, Peter Flass wrote:

>> VAX-11 Pascal, on the other hand, was wonderful. Enough useful
>> extensions to make it a very viable systems programming language.
>>
>>
>>
> As Lynne will be happy to tell you, the original IBM TCP/IP
> implementation was written in IBM Pascal for VM/CMS.

Who remembers PMDF on the VAX?

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Fri, 27 Sep 2024 02:45:23 -0400
"186282@ud0s4.net" <186283@ud0s4.net> wrote:

> As for lady Ada - apparently she was kinda unbearable ... SUCH an
> egomaniac, SO assured of her own math/IQ superiority and EAGER to rub
> it in ........

She really *was* the first programmer...!

In <20240927075959.00005b7b@gmail.com> John Ames:

> She really *was* the first programmer...!

+1

Dibs on the sig line ...

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).