186282@ud0s4.net <186283@ud0s4.net> wrote:
> On 9/27/24 4:38 PM, Charlie Gibbs wrote:
>> On 2024-09-27, geodandw <geodandw@gmail.com> wrote:
>>
>>> On 9/27/24 13:43, Charlie Gibbs wrote:
>>>
>>>> On 2024-09-27, geodandw <geodandw@gmail.com> wrote:
>>>>
>>>>> Cobol was also very portable.
>>>>
>>>> As long as your destination compiler supports COMP-3. :-)
>>>
>>> Or your source computer didn't have COMP-3, or if you didn't use it.
>>
>> 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 COBOL even HAVE real "types" ???
>
> It was not really a "sophisticated" language.
> It was MEANT mostly for biz/commercial apps,
> esp financial and scheduling. It was GOOD at
> that - except for being TOO ugly/confusing in
> the chase to be "simple/self-documenting".
>
> I don't hate COBOL - it HAD/HAS its place.
> However the real-world implementation could
> never live-up to "The Vision".
>
> COBOL could/can be "improved" - made more
> efficient. But NOBODY is gonna DO that
> these days. As such COBOL kinda becomes
> like 'Latin' - an unchanging 'dead' lang.
> This MAY be a good thing.
>
>

I think they’ve added a lot to COBOL over the years - real subroutines with
parameters instead pf just PERFORM.

--
Pete

Gordon Henderson <gordon+usenet@drogon.net> wrote:
> In article <gJEJO.198174$kxD8.85229@fx11.iad>,
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2024-09-27, R Daneel Olivaw <Danny@hyperspace.vogon.gov> wrote:
>>
>>> Charlie Gibbs wrote:
>>>
>>>> And on the operating system side, I know of
>>>> OS/2, OS/3, OS/4, OS/7, and OS/9.
>>>
>>> OS1100 bzw. OS2200.
>>
>> Right, forgot about them. Univac was a big contributor to
>> OS/<number>; in addition to 3, 4, and 7 above, they also
>> had OS-100 and OS-500 for variations of their 9300 operating
>> system that hung a Unicscope 100 or a DCT-500 terminal
>> onto the machine. These were seldom used - we didn't need
>> much help filling out the 32K of memory available to us.
>>
>> Is there an OS/5 or an OS/6 so we can complete the set
>> of one-digit numbers?
>
> c1792 on the Modular One computer:
>
>
> OS6
>
> An Operating Systems for a small computing system
>
> Joseph Stoy and Christopher Strachey
>
> ABSTRACT
> Part I is a general description of a simple operatirg
> system, which runs in a virtual machine (implemented on a real
> machine by an interpreter). OS6 copes with only one user at a
> time, and is not a multiprogramming system: many major problews
> associated with large operating systems have therefore been avoided
> or considerably simplified. It nevertheless has several features
> of interest, including the fact that it is written almost entirely in
> the high-level language BCPL. The most important single feature,
> however, is the hierarchical nature of its control structure, which
> avoids the need for a special job-control language.
>
> Part II covers the facilities for input/output, and the
> handling of files on the disc. The input/output system uses a very
> general form of stream; the filing system is designed to have a clear
> and logical structure.
>
>

I think what was stuck in my mind was IBM OS/6 (Office System/6), a word
processor.

--
Pete

On 9/28/24 00:29, Lawrence D'Oliveiro wrote:
> On Fri, 27 Sep 2024 10:43:13 +0100, Pancho wrote:
>
>> Ah! there we have the Internet and a Search engine. :-)
>
> 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'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.
>
> Pascal should have been easier. VAX Pascal (V2 and later) had all kinds of
> elaborate facilities (nonstandard, of course) for low-level interfacing to
> the system and to other languages, controlling storage layout in the
> linker etc. It was a full-on systems programming language and no mistake.
>
> Again, I know all this from first-hand experience.

As I recall Vax Pascal was fine, Vax C was fine. Both had adequate
coverage of calling system services, it was just the interlanguage
calling that was poorly documented.

The VMS book I really enjoyed, but had stolen twice, was Kenah:
∗vax/vms∗ Internals & Data Structures.

On 26/09/2024 18:01, 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.

In retrospect, I think the problems in mixing C with other languages
came down to this:

For a C routine to be callable from another language, I suspect that the
C routine would have to declare each and every argument as a descriptor
structure, the use the descriptor to find the data.
And for a C routine to call a subroutine in another language, it would
have to build a descriptor structure for that argument.

More trouble than anyone would want if they were used to C on any other
platform. Was that the right or the wrong choice?
An extension with a keyword like "descriptor" attached to a procedure
prototype could have made that much easier to work with!

Newsgroups: alt.folklore.computers,comp.os.linux.misc
Subject: Re: The joy of FORTRAN
Date: 28 Sep 2024 19:36:45 GMT
Lines: 19
Message-ID: <llr46dFmeudU2@mid.individual.net>
References: <pan$96411$d204da43$cc34bb91$1fe98651@linux.rocks>
<5mqdnZuGq4lgwm_7nZ2dnZfqnPSdnZ2d@earthlink.com>
<vcub5c$36h63$1@dont-email.me> <1r0e6u9.1tubjrt1kapeluN%snipeco.2@gmail.com>
<llgckbF2sq0U3@mid.individual.net> <vcuupr$2pg09$1@paganini.bofh.team>
<156256844.748909906.434683.peter_flass-yahoo.com@news.eternal-september.org>
<vd0p06$3knoh$6@dont-email.me>
<1696219735.749088927.121438.peter_flass-yahoo.com@news.eternal-september.org>
<vd52jb$i6sg$7@dont-email.me> <99CJO.19678$MoU3.7045@fx36.iad>
<vd7f76$tdq8$8@dont-email.me> <llp7ftFdihoU4@mid.individual.net>
<vd8o1s$178gk$5@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net yx1BHdQ1NtRgyp43yrQk0w16hhcMIiK12ebq75vTn3Tb8yBkDg
Cancel-Lock: sha1:gEwph8wVgWqmaqDyR4JHX3oH7II= sha256:vSHHVGuyZbB/VXiCJDXppJzWP6uwyvEROD3zjEYXJ7g=
User-Agent: Pan/0.149 (Bellevue; 4c157ba)
Xref: unconfigured alt.folklore.computers:702 comp.os.linux.misc:2618

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'.

On Sat, 28 Sep 2024 11:35:33 +0000, Gordon Henderson wrote:

> In article <gJEJO.198174$kxD8.85229@fx11.iad>, Charlie Gibbs
> <cgibbs@kltpzyxm.invalid> wrote:
>>On 2024-09-27, R Daneel Olivaw <Danny@hyperspace.vogon.gov> wrote:
>>
>>> Charlie Gibbs wrote:
>>>
>>>> And on the operating system side, I know of OS/2, OS/3, OS/4, OS/7,
>>>> and OS/9.
>>>
>>> OS1100 bzw. OS2200.
>>
>>Right, forgot about them. Univac was a big contributor to OS/<number>;
>>in addition to 3, 4, and 7 above, they also had OS-100 and OS-500 for
>>variations of their 9300 operating system that hung a Unicscope 100 or a
>>DCT-500 terminal onto the machine. These were seldom used - we didn't
>>need much help filling out the 32K of memory available to us.
>>
>>Is there an OS/5 or an OS/6 so we can complete the set of one-digit
>>numbers?
>
> c1792 on the Modular One computer:
>
>
> OS6
>
> An Operating Systems for a small computing system
>
> Joseph Stoy and Christopher Strachey
>
> ABSTRACT
> Part I is a general description of a simple operatirg
> system, which runs in a virtual machine (implemented on a real
> machine by an interpreter). OS6 copes with only one user at a
> time, and is not a multiprogramming system: many major problews
> associated with large operating systems have therefore been avoided
> or considerably simplified. It nevertheless has several features of
> interest, including the fact that it is written almost entirely in
> the high-level language BCPL. The most important single feature,
> however, is the hierarchical nature of its control structure, which
> avoids the need for a special job-control language.
>
> Part II covers the facilities for input/output, and the
> handling of files on the disc. The input/output system uses a
> very general form of stream; the filing system is designed to have a
> clear and logical structure.

Be warned that there are two parts to that publication. Oxford only
digitised one part until I advised them. Even now, the link to the other
part isn't clear.

I have both parts in my possession (both physical and digital). and a PDF
of the related paper.

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

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

On Sat, 28 Sep 2024 10:29:02 -0700, Peter Flass wrote:

> Kerr-Mudd, John <admin@127.0.0.1> 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
>>
>>
> +1

+1

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

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

On 28/09/2024 20:27, Lars Poulsen wrote:
>
>
> On 26/09/2024 18:01, 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.
>
> In retrospect, I think the problems in mixing C with other languages
> came down to this:
>
> For a C routine to be callable from another language, I suspect that the
> C routine would have to declare each and every argument as a descriptor
> structure, the use the descriptor to find the data.

Depends on the language. I had no problem in calling C and being called
by C from assembler.

But that's on bare metal, not on a VAX...

> And for a C routine to call a subroutine in another language, it would
> have to build a descriptor structure for that argument.
>
> More trouble than anyone would want if they were used to C on any other
> platform. Was that the right or the wrong choice?
> An extension with a keyword like "descriptor" attached to a procedure
> prototype could have made that much easier to work with!

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

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 was brought up to believe that you should never give offence if you
can avoid it; the new culture tells us you should always take offence if
you can. There are now experts in the art of taking offence, indeed
whole academic subjects, such as 'gender studies', devoted to it.

Sir Roger Scruton

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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 28/09/2024 22: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.
>
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

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.

And simply 'compiler confused - giving up' on many more advanced
declarations.

But I wrote quite a bit in that.

Then I moved on to PCS and C on an IBM PC was way faster.

--
“it should be clear by now to everyone that activist environmentalism
(or environmental activism) is becoming a general ideology about humans,
about their freedom, about the relationship between the individual and
the state, and about the manipulation of people under the guise of a
'noble' idea. It is not an honest pursuit of 'sustainable development,'
a matter of elementary environmental protection, or a search for
rational mechanisms designed to achieve a healthy environment. Yet
things do occur that make you shake your head and remind yourself that
you live neither in Joseph Stalin’s Communist era, nor in the Orwellian
utopia of 1984.”

Vaclav Klaus

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.

On Sat, 28 Sep 2024 10:29:04 -0700, Peter Flass 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.

But in these days of proportional fonts and typeset-quality output, your
output field width will be measured in some actual distance unit (e.g. mm
or points), not some number of characters.

["Followup-To:" header set to alt.folklore.computers.]
On 2024-09-28, geodandw <geodandw@gmail.com> wrote:
> On 9/28/24 17: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.
>>
> If you like getting security exploits due to buffer overruns.

Technically there's nothing stopping you from implementing, say,
Pascal-style strings in C. Of course, that doesn't save you from
null-terminated strings being used in other code you depend on.

Niklas
--
>I've always wondered why there's not a Chlamydia Quilt, a Walk for
>Gonorrhoea or a Syphilis Ribbon.
It's the idea of a Dash for Incontinence that worries me more.
-- Robert Uhl and Tanuki in asr
--
Cesium is also liquid just slightly above room temperature, but it explodes on
contact with moisture, which is inconvenient.
-- http://www.theodoregray.com/PeriodicTable/Elements/080/index.html

On Sat, 28 Sep 2024 10:29:01 -0700, Peter Flass wrote:

> Analytical Engine and Difference Engine were two different things, IIRC.

Of course they were. It’s just that Ms Padua seemed to prefer the name
“Difference Engine”, when the machine in her cartoon strip clearly has
more of the properties of the Analytical Engine.

In real life, the Difference Engine was designed purely to compute and
print difference tables. In other words, tables of polynomial functions.

The Analytical Engine had more of the characteristics we would recognize
as those of a modern programmable digital computer. I recall Babbage
described it at one point as “the engine eating its own tail”. Which was
one way of describing an iterative loop.

On 28/09/2024 14: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.

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.

It really was not until I got to California that it became easy to write
C. And by then, I was working on VMS and Unix (V7 on a pdp11/70, soon
replaced by 4.2BSD on a VAX-11/750).

Back when ACC stood for Associated Computer Consultants, I became
lars@acc - which then became lars@acc.arpa, even though we landed on the
MILNET side of the divide.

On 2024-09-28, Lars Poulsen wrote:

> On 28/09/2024 14: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.
>
> 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.

ISO-646?

In my journey with computers, I think I've only used the 8-bit encodings
that were supersets of ASCII, although I did have the opportunity to see
ISO-646-FI in action in a terminal once. It was interesting, trying to
get some software to produce a more readable/usable interface or convert
the content (If I understood correctly, irssi seemed to have lost some
of the handling for ISO-646 by then? I may have not checked thoroughly,
though.).

> It really was not until I got to California that it became easy to
> write C. And by then, I was working on VMS and Unix (V7 on a pdp11/70,
> soon replaced by 4.2BSD on a VAX-11/750).
>
> Back when ACC stood for Associated Computer Consultants, I became
> lars@acc - which then became lars@acc.arpa, even though we landed on
> the MILNET side of the divide.
>

--
Nuno Silva

On Sat, 28 Sep 2024 12:27:59 -0700, Lars Poulsen wrote:

> And for a C routine to call a subroutine in another language, it would
> have to build a descriptor structure for that argument.

extern "C"
{ ............
]

is handy in C++ but afaik it only works for C++.

On Sat, 28 Sep 2024 22:04:31 +0100, The Natural Philosopher wrote:

> 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 pretty much started with assembler and moved on to C.

Assembler served me well. When I went with the company that wanted a
faster BASIC they handed me a stack of greenbar with the disassembly of
what they were using. "Smells like a Trash-80 ROM" I thought to myself.
Disassembled code isn't that great but once you get the feel for it you
can figure out what's going on. It's actually much easier than making
sense of f2c output.

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.

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.

On 2024-09-27, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Fri, 27 Sep 2024 17:43:31 GMT, Charlie Gibbs wrote:
>
>> Yes, I got into them early - and found it was a short easy step to CSV,
>> so now my stuff can be read by the people in spreadsheet land. I have,
>> however, had to put a fair amount of effort into what I call
>> "Excel-proofing" my data, since our favourite Redmond software company
>> loves meddling with it.
>
> I found, years ago, that outputting SYLK format was a fairly robust
> way of generating data for use by the spreadsheet folks. But that
> doesn’t seem to be well-known these days.

Is that the one where dates are expressed as the number of days
since January 1, 1900? (Forty-something thousand these days.)
Yech. I might as well use raw time_t - and some systems do.

> Trying to “Excel-proof” data is generally regarded as a futile
> exercise. The logical answer would be “use a better tool than Excel”,
> but there seems to be a Gresham’s Law of IT interoperability, where
> the mediocre, Microsoft-based product pushes out the higher-quality
> alternatives ...
>
> <https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1008984>

Sad but true. Meanwhile, I at least get something done.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

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.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

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.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

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.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut