On 9/28/24 3:38 AM, Lawrence D'Oliveiro wrote:
> On Wed, 25 Sep 2024 00:52:17 GMT, Charlie Gibbs wrote:
>
>> My libraries call OpenSSL, but let me establish a connection (with or
>> without TLS) with a single call.
>
> I suppose you can do anything with a single call, if you pack enough
> arguments into it ...

Heh heh ... yea ... LOVE those compound lines with x.y.z.a.b.c() ...
SO comprehensible :-)

I've used openSSL most for encrypting individual files.
The proper params can be found, a TAD different for
Winders. Encrypt first, THEN send to the 'cloud' or
whatever. NEVER allow an unencrypted copy online
for a millisecond.

OpenSSL is good because it's FAST. GPG is good, maybe
a tad better in theory, but for individual files the
start-up time is WAY too long. GPG is best for a FEW
files, perhaps big ZIPs.

OpenSSL can also be used, is intended to be used, for
'live' connections. Depending on your needs/intent
this can be very important. I tended to avoid that,
but my needs aren't YOUR needs.

Again, as for "Rust" - it's good for what it's good for.
To ME it just looks like the umpteenth pointless re-write
of 'C' - so I'll just stick with 'C'.

If you want biz reports and checks printed - COBOL !

On Sun, 29 Sep 2024 01:11:54 -0400, 186282@ud0s4.net wrote:

> On 9/28/24 3:38 AM, Lawrence D'Oliveiro wrote:
>
>> I suppose you can do anything with a single call, if you pack enough
>> arguments into it ...
>
> Heh heh ... yea ... LOVE those compound lines with x.y.z.a.b.c() ...
> SO comprehensible :-)

I have occasionally found method-chaining to be useful, particularly with
graphics APIs, e.g.

(draw
.close_path()
.set_source_colour(bg_colour)
.fill_preserve()
.set_line_width(line_thickness)
.set_source_colour(fg_colour)
.stroke()
)

> If you want biz reports and checks printed - COBOL !

Could never handle proportional fonts and nice text layouts, though.
Python deals with those sorts of things better.

On Sun, 29 Sep 2024 04:26:08 GMT, Charlie Gibbs wrote:

> That's assuming your machine has a stack, which the IBM 360 didn't.

Presumably there was a software-defined stack in the ABI. Otherwise how
would a language like PL/I handle recursion?

On Sun, 29 Sep 2024 04:26:09 GMT, Charlie Gibbs wrote:

> On 2024-09-28, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> I think still does. You wouldn’t want to print too long a name on a
>> check, for instance, just because your system allows it and some
>> literal clerk just types in what they see.
>
> At a PPOE, my job title was "Programmer-Analyst". When squashed into
> the 15-character field allocated for it in our payroll system, it became

With proportional fonts and a decent graphics/typography API, you can
apply nonuniform scaling to the text--reduce the width without reducing
the height. This gives you some leeway to squeeze in a little bit more
text, rather than forcing hard truncation.

On 9/28/24 4:24 AM, Lawrence D'Oliveiro wrote:
> On Sat, 28 Sep 2024 09:12:02 +0100, The Natural Philosopher wrote:
>
>> COBOL was massively good at what it did, and what it still does.
>
> Too short-sighted in its design: in its focus on what passed for
> “business” needs in the early 1960s, it struggled to keep up with the
> growing popularity of relational databases in the 1970s and 1980s. To
> construct SQL queries, you really needed good dynamic string handling, and
> COBOL explicitly eschewed all that. So SQL handling was always some kind
> of bag on the side, rather than properly integrated into the language.

Ummmm ... I'd tend to say WELL-FOCUSED on its INTENDED
uses - at least as best they understood them in the
late 60s. "Net" - few even DREAMED.

And COBOL is STILL with us, just under the skin. Lots
of those 60s pgms writ by narrow-tie horn-rim-glasses
Dilberts STILL doing their thing. NOT dead at all.
I looked over the shoulder of my bank person while
they were fixing-up some shit recently - LOOK & FEEL
of a COBOL pgm, very "terminal", very biz focused.

And now few can AFFORD/DARE to re-write What Just
Works ... so COBOL will be around for another couple
of decades fer sure until/if "AI" gets REALLY good.

There's REALLY GOOD MONEY in maintaining/tweaking
existing COBOL apps BTW. I know a guy, kinda MADE
his retirement nest-egg that way ......

On 9/28/24 5:32 AM, Bob Eager wrote:
> On Fri, 27 Sep 2024 20:54:08 -0400, 186282@ud0s4.net wrote:
>
>> On 9/27/24 7:02 AM, Andy Walker wrote:
>>> 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.
>>
>>
>> Babbage really was a gifted engineer and maths guy, he had enough rep
>> to get the govt to front him rather a lot of money to build the
>> difference engine.
>>
>> Apparently costs-analysis was NOT one of his best skills alas. The
>> machine is devilishly complicated and was at the cutting edge of
>> mechanical techniques and precision at that time.
>>
>> I think some MIT people finally *built* one, or a substantial part of
>> one. I've seen a vid, all the brass clockwork is hypnotic to watch.
>
> See also:
>
> https://collection.sciencemuseumgroup.org.uk/objects/co62748/babbages-
> difference-engine-no-2-2002

Wonderful !

The DE's were ALMOST real computers.

The AE would have been a real computer.

Alas brass and iron were the only means back then.

Babbage was born 50 years too early.

On Sun, 29 Sep 2024 04:26:06 GMT, Charlie Gibbs wrote:

> Is that the one where dates are expressed as the number of days since
> January 1, 1900?

That was some Excel thing.

The old Macintosh counted time since 1st January 1904, which was cunningly
chosen so they didn’t have to deal with 1900 being an exception to the
rule of a leap year every four years.

I think Excel did actually consider 1900 to be a leap year at one point.

On Sun, 29 Sep 2024 04:26:10 GMT, Charlie Gibbs wrote:

> On 2024-09-27, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Fri, 27 Sep 2024 20:38:38 GMT, Charlie Gibbs wrote:
>>
>>> I was once called in to optimize a CPU-bound COBOL program.
>>> The genius who wrote it declared all subscripts as COMP-3. Changing
>>> them to COMP-4 knocked 30% off the execution time.
>>
>> Did you just change
>>
>> DEFINE TYPE COMP AS COMP-3
>>
>> to
>>
>> DEFINE TYPE COMP as COMP-4
>>
>> and that would take effect everywhere that COMP was used?
>>
>> Oh, wait, COBOL didn’t have typedefs ...
>
> I suppose I could have done the equivalent of s/COMP-3/COMP-4/ in the
> text editor of the day, but that would have also changed the fields that
> were not only legitimately COMP-3, but which could not have been held in
> a COMP-4 variable.
>
> Sometimes you just gotta Do the Right Thing, no matter how long it
> takes.

Helps if you are charging by the hour. ;)

On Sun, 29 Sep 2024 01:28:01 -0400, 186282@ud0s4.net wrote:

> And COBOL is STILL with us, just under the skin. Lots of those 60s
> pgms writ by narrow-tie horn-rim-glasses Dilberts STILL doing their
> thing.

They are disappearing, one way or the other. Companies that are still
insisting on sticking to that legacy code gradually going out of business
or being acquired, and having that technical-debt-ridden stuff superseded
by more modern stuff from the parent company ...

Do you think PayPal, Ebay or TradeMe use COBOL code to manage their
financial transactions? Of course not.

On 9/25/24 3:18 PM, Rich Alderson wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> John Ames <commodorejohn@gmail.com> wrote or quoted:
>>> 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 know you've
>>> found a Truly Special Genius.
>
>> Dudes, when Knuth was on the hunt for a language to whip
>> up TeX back in the day, he figured Pascal was the cream of
>> the crop among his options. You got to put that language in
>> perspective and see it through the lens of its time!
>
> Pascal was used in the rewrite (2nd version), part of his Literate Programming
> thing. The original was written in SAIL (an Algol-60 derivative created at
> SAIL, the Stanford Artificial Intelligence Laboratory). The same thing was
> true of METAFONT, first version in SAIL, second in Pascal. DEK used Pascal
> because it was spreading throughout the computing world, across tons of
> different architectures. (According to DEK, in his presentation on Literate
> Programming at SHARE in San Francisco.)
>
> The thing was, neither was written in "pure Pascal", but rather in his Literate
> Programming formulation in which actual Pascal code was intertwined with TeX
> documentation for the program being written. The resulting source was then run
> through either of two preprocessor programs, tangle (which stripped the Tex and
> wrote out a Pascal source without linebreaks or human comfortable indentation)
> and weave (which made the Pascal code acceptable to a TeX processor).
>
> Someone else very quickly created C versions of the preprocessors, and the
> modern TeX world was born.

PASCAL is STILL my language of choice, when possible.

Poetry.

I've even got early DOS and the MS/IBM multi-pass PASCAL
compiler on a VM. I do write little things for it from
time to time just for fun.

FPC/Lazarus are your modern PASCAL outlets and I STILL
write stuff for those.

Yea, yea, SOME stuff is just better in 'C' ... one of
my latter pre-retirement apps was mostly Laz/FPC, but
CALLED a 'C' app for a few special needs. Now for
like client/server stuff, 'C' is traditional and
kinda the best.

To each need .....

I just can't bring myself to TRASH computer languages
on the whole. Some are 'better', or not, but they all
were created with various uses/theologies in mind and
serve those quite well. The only ones I came to HATE
were LISP/PROLOG and ADA - the latter being SO fascist
that, well, no WONDER govt projects take 20 years ....

On 28/09/2024 22:41, geodandw wrote:
> On 9/28/24 17:20, John Levine wrote:
>> According to The Natural Philosopher  <tnp@invalid.invalid>:
>>> The need to speed up BASIC was why I learnt Assembler...
>>
>> Dartmouth BASIC on the GE 635 compiled your program into machine code
>> and then ran it, so it was pretty snappy.  The compiler was so fast that
>> it wasn't worth keeping the objsct code around.  They didn't have a
>> linker
>> until they added a PL/I compiler that was as slow as PL/I compilers are.
>>
>> All this running 100 users on a machine the size of the KA-10 PDP-10.
>>
>>> Then I moved onto C, and that was the best of both worlds really
>>
>> C was in the sweet spot of being not all that great, but better than
>> any of the
>> plausible alternatives at the time.
>>
> If you like getting security exploits due to buffer overruns.
When C was developed there was no expectation that whole generation of
crap programmers who had simple dome computer science, and therefore
didn't know what a CPU actually was, would take over and need to be
protected form their own laziness and incompetence.
If there exists a possibility of buffer overrun, check the size of what
you are putting into it.

--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."

Billy Connolly

On 29/09/2024 04:15, rbowman wrote:
> On Sat, 28 Sep 2024 15:17:12 -0700, Lars Poulsen wrote:
>
>> I was late to discovering C. In the 1970's I lived in Denmark, and our
>> terminals, printers, keyboards etc were using a national version of the
>> ISO standard interchange code that Americans kn ow as ASCII.
>> Since Danish have three unique (well sort-of shared with Swedish and
>> Norvegian) vowels at the end of the alphabet (æ ø å / Æ Ø Å), these were
>> allocated at the end of the alphabet - after z / Z. When you look at the
>> ASCII character table, you will see that each of these conflicts with
>> significant symbols of the C language ({ \ } / [ | ]). This created a
>> strong disincentive to experiment with a "fringe" programming language.
>
> Don't feel bad. I always forget what the Apple II lacked, maybe the tilde,
> but even with a Z-80 SoftCard you had to do some tweaks to write C code.

Curly braces. I had a friend who said 'you cant program in C on an Apple
because there are no curly braces'.

I think I sent him a header file with

#define BEGIN {
#define END }

In it.

--
“A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
“We did this ourselves.”

― Lao Tzu, Tao Te Ching

On 29/09/2024 04:11, rbowman wrote:
> On Sat, 28 Sep 2024 22:28:46 +0100, The Natural Philosopher wrote:
>
>> I started out on BDS C which had sever limitations, not the least was
>> promoting everything 8 bit to 16 bit to do comparisons etc.
>
> For what it was Zolman's Brain Dead Software was great. Even after the the
> repackaged Lattice C Microsoft first used had limitations.
Looking back nearly all the C compilers I used in the 80s were crap.
There was BDS C for the Z80
Introl C for 6809
Digital Research C for 8066/8
Lattice C for the same
Microsoft C

Then along came Gnu C and everyone wanted to fix its bugs and they
could, so it just took over.

I think the worst thing was Turbo Pascal, which convinced huge numbers
of amateurs that they could actually write code.

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

On 29/09/2024 05:26, Charlie Gibbs wrote:
> On 2024-09-28, The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 28/09/2024 22:20, John Levine wrote:
>>
>>> C was in the sweet spot of being not all that great, but better than
>>> any of the plausible alternatives at the time.
>>>
>> As far as I was concerned it was heaven. Assembler but 10x faster to
>> actually write.
>> And the way it used local variables was magic. Very hard to use the
>> stack as a scractc pad in assembler - you have to keep track of so many
>> offsets
>
> That's assuming your machine has a stack, which the IBM 360 didn't.
>

Well there are probably other ways to implement a stack than having it
built into a computer.
Like a having a general purpose register reserved for a stack pointer
and manually creating push pop call and return as macros

I don't see how you can run any code that needs to do subroutines
without some form of stack.

--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

On 29/09/2024 05:26, Charlie Gibbs wrote:
> On 2024-09-28, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>
>>> On 2024-09-27, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> On Thu, 26 Sep 2024 17:52:04 -0700, Peter Flass wrote:
>>>>
>>>>> 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 ...
>>>
>>> Which for many of us was the only world that existed at the time.
>>
>> I think still does. You wouldn’t want to print too long a name on a check,
>> for instance, just because your system allows it and some literal clerk
>> just types in what they see.
>
> At a PPOE, my job title was "Programmer-Analyst". When squashed into
> the 15-character field allocated for it in our payroll system, it became
> PROGRAMMER-ANAL.
>
> I always felt this was appropriate.
>
We always called them ANAL PROGS

--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels

On 29/09/2024 06:44, 186282@ud0s4.net wrote:
The only ones I came to HATE
>   were LISP/PROLOG and ADA - the latter being SO fascist
>   that, well, no WONDER govt projects take 20 years ....
Well yes, that what happens when you let computer scientists take over.

I knew someone who ran a small company doing low level programming fir
their custome hardware.
One day one of the coders said 'lets do the next one in C++'
So they did, and a year later realised that before you wrote C++ you
have to sit down and write some or of spec to show what objects you are
going to need to create etc etc.
In the same way I always write down a crude 'data dictionary' whenever I
am implementing any sort of file based data system. And especially an
SQL based one

But they didn't. They tried to hack it and it was a disaster.
I hate OO.

It is a compsci invention that doesn't map well onto an actually CPU
which is a procedural beast.

Most of its vaunted advantages can be attained by writing C in a
structured way and others like operator overloading are just damned
confusing.

I don't WANT to use the same syntax to add two strings together as to
add two numbers.

I found that out in JavaScript where a comparison between a string "1"
and a number 1 failed on IE but worked on Firefox.

I had found an 'undefined' gap in the language.

In C you are absolutely aware at all times what type of object you are
dealing with and if you move to another one it's via an explicit cast.
Or if implicit, you normally get a compiler warning.

In C if you want to deallocate RAM you say so. It doesn't silently
collect garbage under your feet and take a millisecond to do it

Javascript silently just does what it *thinks* you meant. And gets it wrong.

In short there is a layer of uncertainty built into modern languages
that attempt to map abstract compsci concepts into actual procedural code.

Which is why C is probably still the most popular language.

--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels

On 9/29/24 02:06, The Natural Philosopher wrote:
> On 28/09/2024 22:41, geodandw wrote:
>> On 9/28/24 17:20, John Levine wrote:
>>> According to The Natural Philosopher  <tnp@invalid.invalid>:
>>>> The need to speed up BASIC was why I learnt Assembler...
>>>
>>> Dartmouth BASIC on the GE 635 compiled your program into machine code
>>> and then ran it, so it was pretty snappy.  The compiler was so fast that
>>> it wasn't worth keeping the objsct code around.  They didn't have a
>>> linker
>>> until they added a PL/I compiler that was as slow as PL/I compilers are.
>>>
>>> All this running 100 users on a machine the size of the KA-10 PDP-10.
>>>
>>>> Then I moved onto C, and that was the best of both worlds really
>>>
>>> C was in the sweet spot of being not all that great, but better than
>>> any of the
>>> plausible alternatives at the time.
>>>
>> If you like getting security exploits due to buffer overruns.
> When C was developed there was no expectation that whole generation of
> crap programmers who had simple dome computer science, and therefore
> didn't know what a CPU actually was, would take over and need to be
> protected form their own laziness and incompetence.
> If there exists a possibility of buffer overrun, check the size of what
> you are putting into it.
>
And of course careful programmers never make mistakes or overlook anything.

On Sun, 29 Sep 2024 07:50:14 +0100, The Natural Philosopher wrote:

> But they didn't. They tried to hack it and it was a disaster.
> I hate OO.

But C++ isn’t really OO. It’s a kind of frankenmix of some OO-like
features in with a bunch of other random things.

> It is a compsci invention that doesn't map well onto an actually CPU
> which is a procedural beast.

All OO languages are in fact procedural.

The opposite of “procedural” is “functional”, not “OO”.

> Most of its vaunted advantages can be attained by writing C in a
> structured way and others like operator overloading are just damned
> confusing.

Operator overloading is in fact very useful. It allows you to build what’s
called “Domain-Specific Languages”, to allow you to express the concepts
of the problem you’re solving more naturally.

For example, being able to overload arithmetic operators to work on
vectors and matrices, which is useful for computer graphics work.

> I don't WANT to use the same syntax to add two strings together as to
> add two numbers.

So what syntax *do* you want to use to join strings?

> I found that out in JavaScript where a comparison between a string "1"
> and a number 1 failed on IE but worked on Firefox.

That’s a misfeature of JavaScript, not a fault of OO generally. For
example, Python doesn’t have that misfeature. And neither does C++, while
we’re at it.

On 29/09/2024 07:57, geodandw wrote:
> On 9/29/24 02:06, The Natural Philosopher wrote:
>> On 28/09/2024 22:41, geodandw wrote:
>>> On 9/28/24 17:20, John Levine wrote:
>>>> According to The Natural Philosopher  <tnp@invalid.invalid>:
>>>>> The need to speed up BASIC was why I learnt Assembler...
>>>>
>>>> Dartmouth BASIC on the GE 635 compiled your program into machine code
>>>> and then ran it, so it was pretty snappy.  The compiler was so fast
>>>> that
>>>> it wasn't worth keeping the objsct code around.  They didn't have a
>>>> linker
>>>> until they added a PL/I compiler that was as slow as PL/I compilers
>>>> are.
>>>>
>>>> All this running 100 users on a machine the size of the KA-10 PDP-10.
>>>>
>>>>> Then I moved onto C, and that was the best of both worlds really
>>>>
>>>> C was in the sweet spot of being not all that great, but better than
>>>> any of the
>>>> plausible alternatives at the time.
>>>>
>>> If you like getting security exploits due to buffer overruns.
>> When C was developed there was no expectation that whole generation of
>> crap programmers who had simple dome computer science, and therefore
>> didn't know what a CPU actually was, would take over and need to be
>> protected form their own laziness and incompetence.
>> If there exists a possibility of buffer overrun, check the size of
>> what you are putting into it.
>>
> And of course careful programmers never make mistakes or overlook anything.

Only once.

And careful programmers test everything with unlikely data too.
I remember code I wrote being passed to a selection of 6th form 'holiday
job' nerds to try and break it.
And they did.

But my main point is that code designed to 'protect' crap programmers
introduces its own set of vulnerabilities at a different level.

Everyone in major engineering knows that no one ever get it right all
the time and that is why instead of trying, they implement quality
procedures.
Test it as far as possible.
If it's wrong:

- fix it
- document the fix
- document why it went wrong
- document ways to avoid getting it wrong in future.
- implement standards to stop it happening again.

Go back and test it all again,.

That's the heart of ISO 9000

In software terms that means don't try to fix the language*, fix the
procedures under which the language is used, and tested...

I love those air accident reports that say instead of 'the pilot was
crap ' that
'the procedures and standards for pilot selection, training and
certification failed and need to be modified'.
In other words the system was at fault for failing to adequately
train, hire or even certify such a crap pilot in the first place.

The system acknowledges that there are people who want to be pilots, who
aren't fit to be.

If only we could do the same with coders...

*unless there are important undefined behaviours in it
--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

On Sat, Sep 28 2024, Pancho <Pancho.Jones@proton.me> wrote:

> On 9/28/24 00:29, Lawrence D'Oliveiro wrote:
>> My knowledge of those documents comes from having actual paper
>> copies
>> while using actual physical machines, back in the day when these systems
>> were new.
>>
>
> Well, ok, 40 years on I can't remember every manual I read. Especially
> given the size of the VMS collection.
>
> <https://upload.wikimedia.org/wikipedia/commons/8/80/Vax-vms-grey-wall.jpg>
>
> I do have a vague memory the Vax C manual you mention was an orange
> one, and smaller than the rest, no idea if it is a correct memory. I
> can't even remember much of K&R now.
>

I can't remember any Vax manuals being grey just orange like on the rhs
of your picture. Did it depend on the date or the country they were
distributed from?

Robert
--
Robert Marshall he/him twiX:@rajm https://mastodon.world/@rajm

On Sun, 29 Sep 2024 08:35:28 +0100, Robert Marshall wrote:

>> I do have a vague memory the Vax C manual you mention was an orange
>> one, and smaller than the rest, no idea if it is a correct memory. I
>> can't even remember much of K&R now.
>>
>>
> I can't remember any Vax manuals being grey just orange like on the rhs
> of your picture. Did it depend on the date or the country they were
> distributed from?

In the UK, version 4 manuals were orange. Those for V5 were grey.

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

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

On Sat, 28 Sep 2024 22:04:31 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote in <vd9r10$1d6gq$4@dont-email.me>:

> On 28/09/2024 20:36, rbowman wrote:
>> On Sat, 28 Sep 2024 07:07:40 -0400, Chris Ahlstrom wrote:
>>
>>> I got my start in high school with BASIC, keyed into a teletype and
>>> saved to paper tape. (Later, I learned how to toggle code into the
>>> front panel of the PDP-8.)
>>
>> I had a couple of brushes with BASIC. The IBM 5120 offered a choice of
>> BASIC or APL so that was a no-brainer. Later I did a follow-up with an
>> environmental test system. I had originally done the software for the
>> AT which was the master controller of a number of slaved XTs. (Sorry
>> DEI). The XTs had been programmed in BASIC by someone else. About 8
>> months after I left I cog a phone call asking if I could return to sort
>> the XTs out so it was back to Ft. Wayne.
>>
>> I also wrote a preprocessor to convert BASIC to sort of an IL and the
>> necessary run time but I was working in assembler rather than BASIC.
>> Interpreted BASIC wasn't exactly speedy. Not being a 'computer
>> scientist' I was fairly naive at the time and was working from a
>> directive 'speed this stuff up'.
>
> The need to speed up BASIC was why I learnt Assembler...
>
> Then I moved onto C, and that was the best of both worlds really

I grew up with BASIC, but played with 6502 assembler on
Apple ][+'s...

Once in high school -- armed with a copy of _Beneath Apple DOS_ -- I
patched the Corvus-enhanced DOS 3.3 to disallow changing volumes
with the "CATALOG" command. (Previously, someone could type
something like "CATALOG V43", and end up in a different student's
volume.)

I used BASIC and assembler on 80186 processors in the Coast Guard,
which were Convergent Technologies CTOS machines, later "BTOS" when
Burroughs bought them.

Didn't learn C until I went back to school, starting on my own with
Microsoft's _Learn C Now_ -- it would let you write and execute programs,
but you couldn't save the compiled executables.

Then I dove into Unix (HPUX), downloaded Linux, built a
student-access Unix host with gcc -- oh, I knew enough
to be dangerous. But we managed to navigate the troubled
waters of the early 1990's Internet, and managed to build
useful systems with sh, C, awk, and perl.

Technology transfer: my business partner and I took what
we learned setting up and running the student-access Linux host,
and built a dialup shell provider. We became an ISP, which has
now been a CLEC for many years. We sell 10 Gigabit fiber-to-the-home
now...it's a living.

--
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
OS: Linux 6.11.0 Release: Mint 21.3 Mem: 258G
"(A)bort, (R)etry, (T)ake down entire network?"

On 29/09/2024 00:06, Lawrence D'Oliveiro wrote:
> All OO languages are in fact procedural.
> The opposite of “procedural” is “functional”, not “OO”.

I need to do some reading. My understanding of the difference is clouded
by the fact that a subroutine is a procedure, but becomes a function if
it delivers a return value. (Yes I am that old).

> So what syntax *do* you want to use to join strings?

S3 = string_join(S1, S2) .. or .. S3 = S1.S2 .. or even S1 .= S2
... although the latter probably is hiding some ugly copying and
reallocation behind the scenes.

On Sun, 29 Sep 2024 07:50:14 +0100, The Natural Philosopher wrote:
>> I found that out in JavaScript where a comparison between a string "1"
>> and a number 1 failed on IE but worked on Firefox.

> That’s a misfeature of JavaScript, not a fault of OO generally. For
> example, Python doesn’t have that misfeature. And neither does C++, while
> we’re at it

Yeah, I like PERL a whole lot better than JavaScript. PERL has different
operators for string compare and numeric compare. So if $S1 is "1" and
$I1 is the number 1, you can test $I1 == $S1 (which casts the numeric
string into a number) or $I1 eq $S1 (which casts the string into a
number). If $S1 = " 1", the numeric compare is true, but the string
compare fails.

On 29/09/2024 00:58, vallor wrote:
> Technology transfer: my business partner and I took what
> we learned setting up and running the student-access Linux host,
> and built a dialup shell provider. We became an ISP, which has
> now been a CLEC for many years. We sell 10 Gigabit fiber-to-the-home
> now...it's a living.

Congratulations on following an actual PATH of a career.
Where were you located, and how did you avoid being squished when "the
big ones" decided they needed to be ISPs?
Not many survived the two big jumps from dial-up to renting circuits
from the ILEC and then again laying down fiber.

On 29/09/2024 06:55, Lars Poulsen wrote:
> On 29/09/2024 00:06, Lawrence D'Oliveiro wrote:
>> All OO languages are in fact procedural.
>> The opposite of “procedural” is “functional”, not “OO”.
>
> I need to do some reading. My understanding of the difference is clouded
> by the fact that a subroutine is a procedure, but becomes a function if
> it delivers a return value. (Yes I am that old).
>
>> So what syntax *do* you want to use to join strings?
>
> S3 = string_join(S1, S2) .. or .. S3 = S1.S2 .. or even S1 .= S2
> .. although the latter probably is hiding some ugly copying and
> reallocation behind the scenes.
>
> On Sun, 29 Sep 2024 07:50:14 +0100, The Natural Philosopher wrote:
>>> I found that out in JavaScript where a comparison between a string  "1"
>>> and a number 1 failed on IE but worked on Firefox.
>
>> That’s a misfeature of JavaScript, not a fault of OO generally. For
>> example, Python doesn’t have that misfeature. And neither does C++, while
>> we’re at it
>
> Yeah, I like PERL a whole lot better than JavaScript. PERL has different
> operators for string compare and numeric compare. So if $S1 is "1" and
> $I1 is the number 1, you can test $I1 == $S1 (which casts the numeric
> string into a number) or
> $I1 eq $S1 (which casts the string into a number).

Of course I meant to type "which casts the number into a string".

> If $S1 = " 1", the numeric compare is true, but the string
> compare fails.