On 30/09/2024 06:46, Charlie Gibbs wrote:
> On 2024-09-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> 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?
>
> The subroutine calling convention required the calling program
> to pass a pointer to a register save area. A recursive routine
> would have to allocate a save area in each instance (and, of
> course, free it before exiting). If they wanted local variables,
> they'd have to allocate and free them as well.
>
Exactly . At the end of the day., someone looked at how code was
developing and said 'y'know, all this would be a piece of piss if we
invented a STACK'

No need to explicitly allocate and free memory.
I think it was ALGOL that first used a stack for all that - not sure.

--
"Fanaticism consists in redoubling your effort when you have
forgotten your aim."

George Santayana

In alt.folklore.computers Peter Flass <peter_flass@yahoo.com> 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.
> Assign a longer to a shorter and the longer is truncated, with or without
> an error.

In my world blank padding is simply wrong result. Truncation too.
To have natural handling language needs to track actual lengths
(and signal (catchable) error on overflow). And such natural
handling may be quite inefficient. I recently looked at code
generated by GNU Pascal compiling for a 32kB machine. String
handling needed about 60kB for string buffers (30 buffers 2kB
each) and the file did not compile. Compiler handling string
buffers in smarter way probably could reuse some buffers.
But there were several copy operations (or rather concatenations)
and some string variables were used multiple times, so even
with good optimizer for string operations the code would still
be rather inefficient.

To put it differently: natural string operations work nicely
if you have big machine with lot of memory and machine cycles
to waste. But if you need efficient code for small machine,
then you want single buffer which is modified in place.

And of course, on big modern machines people use dynamic memory
allocation.

--
Waldek Hebisch

On 30/09/2024 13:35, Waldek Hebisch wrote:
> In my world blank padding is simply wrong result.

Hah. That reminds me of a project I once worked on. The disk space was
getting tight tos a nice liitle sysdamin write a script that removed all
instances of IIRC 4 spaces in our code and replaced then with tabs.

Unfortunately my software was working on a digital oscilloscope whose
underlying software did not know what to do with tabs, so all the on
screen menus came out all over the place.

I had to manually reinsert all the spaces in the display strings

Because his theory that all spaces could be replaced with tabs, was not
applicable to padded string literals inside the code itself

--
Microsoft : the best reason to go to Linux that ever existed.

On 9/30/24 00:40, rbowman wrote:
> On Sun, 29 Sep 2024 23:36:11 -0400, 186282@ud0s4.net wrote:
>
>> There's always a psychology in the computer world that immediately
>> embraces the "Newest/Greatest Thing"
>> whether it's actually good/improved or not. Shit, I remember when 'C'
>> was in that category ... that one DID hang on
>
> That's something that's puzzled me all of my life and on a wider scale
> than computer languages. Why does Religion X survive while Religion Y,
> which is equally as plausible/implausible become an also ran? Why does C
> hand on while C++ never quite lived up to its promises? Why is Pike
> completely off the map? It isn't that bad of a C-like language?
>
> Some things live the AC vs. DC wars have valid technological answers.
> Others like the i86 architecture seem more like accidents at a point in
> time.

I dunno about Computer launguages but religions survive due to various
factors. The Christian religion in Europe survived because its
converts were willing to murder adherents of other religions.
In one case a noble family close to Royalty converter and
burned the royal family in their palace. In Eurasia the same could
be said of the Islamic converts. In India Hindu nationalists are
presently persecuting the adherents of Islam, Christianity and
any other none-Hindu religion. In some corners or ilands they even
persecute Buddhists. Early on in Japan about 600 CE the Buddhists
and the Shinto followers fought. When Christianity showed up in
the late 1500s with the Portuguese traders and guns it took until
around 1640s for the Shogunate to suppress it killing about 40,000
Christians. I think they crucified the missionaires. When the Emperor
was restored(as a front for the magnates) in the 1860s, State Shinto
was born and the Buddhists were expelled from their temples where
Shinto shrines had shared the space for hundreds of years. After 1945
things changed again and religious freedom was a change.
The muscular Christianity of the 1600s in Japan was aimed at
converting the Japanese to a Catholic Dependency and the Shogun aimed
to the the sole authority in Japan.

On the matter of the i86 remember the 4004 came first. There
is the matter of inheritance in product lines.

bliss
--
b l i s s - S F 4 e v e r at D S L E x t r e m e dot com

On 30/09/2024 16:36, Bobbie Sellers wrote:
>   I dunno about Computer launguages but religions survive due to
> various factors. The Christian religion in Europe survived because its
> converts were willing to murder adherents of other religions.

Not really.

That is of course a story made up by the other religions who strove to
murder christians.

All belief systems strive to 'cancel' other belief systems.

Look at today's 'religion' of woke liberalism. Or climate change. If
your beliefs differ, you are out of a career and possibly in court

I agree it isn't quite as blatant as the Islamic 'cheat steal from and
finally torture rape and kill the kuffir, especially the Jewish ones' .

But give it time.

The problem is that on their wown, belief systems are quite good in
promoting a feeling of shared values. The problem is when 'diversity'
brings one set of shared values in direct conflict with another set of
shared values . Or in conflict with reality.

If I drive on the Left and you drive on the Right, one of us will have
to give way...or neither of us will live to say 'how right we were.'

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Sun, 29 Sep 2024 07:16:43 +0100, The Natural Philosopher wrote:
>
>> 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 }
>
>As of C99, there is a standard C header file called iso646.h. Its contents
>look like

Back in the early days of C standardization ('89), trigraphs were supported
to handle characters missing from the compiler character set.

Specifically to handle the braces (??< and ??>).

On Mon, 30 Sep 2024 03:43:16 -0400, 186282@ud0s4.net wrote:

> On 9/30/24 3:21 AM, rbowman wrote:
>> On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>>> Fun fact: I was reworking an old perpetual-calendar program I first
>>> wrote back in 1980, to use Fortran 90, a few months ago. And I found a
>>> bug in my algorithm that never showed up in any years from the 20th
>>> century, but did manifest itself in the 21st century.
>>
>> Y2K rides again... I think in many cases the problem was recognized in
>> the '70s and '80s but nobody expected the code to last decades.
>
> Very true - and TROUBLESOME.
>
> We all think in the NOW. With effort we can think a FEW years ahead.
> But a whole new century or something similar ... TOO MUCH WORK to
> future- proof. We'll "get back to it", sometime ......

It won't be my problem but my bet is there will be a flurry of activity in
2037...

186282@ud0s4.net <186283@ud0s4.net> wrote at 07:43 this Monday (GMT):
> On 9/30/24 3:21 AM, rbowman wrote:
>> On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>>> Fun fact: I was reworking an old perpetual-calendar program I first
>>> wrote back in 1980, to use Fortran 90, a few months ago. And I found a
>>> bug in my algorithm that never showed up in any years from the 20th
>>> century, but did manifest itself in the 21st century.
>>
>> Y2K rides again... I think in many cases the problem was recognized in
>> the '70s and '80s but nobody expected the code to last decades.
>
> Very true - and TROUBLESOME.
>
> We all think in the NOW. With effort we can think
> a FEW years ahead. But a whole new century or
> something similar ... TOO MUCH WORK to future-
> proof. We'll "get back to it", sometime ......

Then, people ignore the problem until it's right there.
For instance, the 2038 problem I'm betting will be ignored until 2035.
--
user <candycane> is generated from /dev/urandom

On Mon, 30 Sep 2024 19:40:06 -0000 (UTC), candycanearter07 wrote:

> For instance, the 2038 problem I'm betting will be ignored until 2035.

It’s not being ignored. The Linux kernel added the option to build a 32-
bit kernel with time_t having 64 bits, and Debian has been going through a
reorg to incorporate this into its 32-bit builds (look for package names
appearing with “t64” in there somewhere).

On Sun, 29 Sep 2024 07:22:45 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

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

OTOH, like BASIC, it *enabled* large numbers of amateurs to actually get
shit done and develop software that met their own needs when solutions
were either nonexistent or prohibitively expensive - the kind of thing
that drove the microcomputer revolution. Sure, it might've made for a
little mess along the way, but in the long run it's not so terrible ;)

On 30/09/2024 17:31, Scott Lurndal wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Sun, 29 Sep 2024 07:16:43 +0100, The Natural Philosopher wrote:
>>
>>> 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 }
>>
>> As of C99, there is a standard C header file called iso646.h. Its contents
>> look like
>
> Back in the early days of C standardization ('89), trigraphs were supported
> to handle characters missing from the compiler character set.
>
> Specifically to handle the braces (??< and ??>).

That friend said that around 1983. About the Apple II (released 1978)

The Apple II had no | or \ or { or } or even [ or ] on the keycaps. Nor
_ or ~

These were added for the Apple III. I have no idea whether they were in
fact able to display them or to enter them via some obscure sequence of
keystrokes, but it wasn't a simple process.

The easy way would be to use a generate a macro file like
printf("#define BEGIN %c\n", 123 );

....and so on to bootstrap being able to write the code using what
keyboard input you had.

Looking back, it seems unlikely that any programming language apart from
BASIC or ASSEMBLER would be possible.

There were compilers for 6502s but the rather large runtime libraries
made them a poor choice for small memory machines. BASIC was in ROM and
ASSEMBLER only used what you wanted it to use

Personally I thought the Apple II was a rich boy's toy.

Come to think of it, that sums up nearly every apple product..

--
“Some people like to travel by train because it combines the slowness of
a car with the cramped public exposure of 
an airplane.”

Dennis Miller

On Fri, 27 Sep 2024 21:49:43 -0400
"186282@ud0s4.net" <186283@ud0s4.net> wrote:

> Revelation DB system used ascii-255 as the record
> mark, 254 as the field marks and worked backwards
> from there, thus allowing about 127 levels of
> sub-sub values though nobody EVER used THAT many.

It's always struck me as funny that nobody *ever* seems to use the
ASCII control characters that already exist for record demarcation for
that purpose; aside from CR/LF/tab/NUL, and BEL/SUB/ESC in interactive-
terminal contexts, the whole 0x00-0x1F range might as well not exist.
Not that it'd be a conspicuously *good* idea, but I've always harbored
an impish desire to devise a format that makes use of the rest in some
way that maps relatively logically to the original intent/description...

On 30/09/2024 18:01, John Ames wrote:
> On Sun, 29 Sep 2024 07:22:45 +0100
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> I think the worst thing was Turbo Pascal, which convinced huge
>> numbers of amateurs that they could actually write code.
>
> OTOH, like BASIC, it *enabled* large numbers of amateurs to actually get
> shit done and develop software that met their own needs when solutions
> were either nonexistent or prohibitively expensive - the kind of thing
> that drove the microcomputer revolution. Sure, it might've made for a
> little mess along the way, but in the long run it's not so terrible ;)
>
The problem is that many of those amateurs thought they were in fact
professionals

And you could hack code *without regard to its context*

Sure I hacked a little basic, but once I started on assembler and C, my
engineering training kicked in and it was all documented, sometimes
planned and really quite structured.
"Every code block in assembler must have an explanation of its purpose
that will likely be three times the length of the code."..was the
mantra. Even today writing code that no one but me will see I have
extensive headers for every function or code block explaining what it is
supposed to do and often line by line comments.

And sometimes I write the comments first.

// open port

//set up event handler for asynch connection

//listen on port, and vector incoming data to handler

....and so on

--
You can get much farther with a kind word and a gun than you can with a
kind word alone.

Al Capone

On 30/09/2024 18:36, John Ames wrote:
> On Fri, 27 Sep 2024 21:49:43 -0400
> "186282@ud0s4.net" <186283@ud0s4.net> wrote:
>
>> Revelation DB system used ascii-255 as the record
>> mark, 254 as the field marks and worked backwards
>> from there, thus allowing about 127 levels of
>> sub-sub values though nobody EVER used THAT many.
>
> It's always struck me as funny that nobody *ever* seems to use the
> ASCII control characters that already exist for record demarcation for
> that purpose; aside from CR/LF/tab/NUL, and BEL/SUB/ESC in interactive-
> terminal contexts, the whole 0x00-0x1F range might as well not exist.
> Not that it'd be a conspicuously *good* idea, but I've always harbored
> an impish desire to devise a format that makes use of the rest in some
> way that maps relatively logically to the original intent/description...
>
The issue is that it's not human readable

In fact CTRL-Z was CP/Ms EOF mark

And lots of the others get used in non textual contexts

--
"Nature does not give up the winter because people dislike the cold."

― Confucius

John Ames <commodorejohn@gmail.com> writes:
>On Fri, 27 Sep 2024 21:49:43 -0400
>"186282@ud0s4.net" <186283@ud0s4.net> wrote:
>
>> Revelation DB system used ascii-255 as the record
>> mark, 254 as the field marks and worked backwards
>> from there, thus allowing about 127 levels of
>> sub-sub values though nobody EVER used THAT many.
>
>It's always struck me as funny that nobody *ever* seems to use the
>ASCII control characters that already exist for record demarcation for
>that purpose; aside from CR/LF/tab/NUL, and BEL/SUB/ESC in interactive-
>terminal contexts, the whole 0x00-0x1F range might as well not exist.
>Not that it'd be a conspicuously *good* idea, but I've always harbored
>an impish desire to devise a format that makes use of the rest in some
>way that maps relatively logically to the original intent/description...
>
Burroughs used FS, GS, RS and US (in both EBCDIC and ASCII) for various
related purposes (most significantly to delimit fields in the block-mode
terminals).

On Sun, 29 Sep 2024 07:06:57 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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

This bears repeating. As someone whose initial exposure to OOP concepts
was via C++ (and then Java,) I spent *years* never understanding what
the appeal was. Wasn't until I encountered Smalltalk, way on down the
line, that I finally *got* it.

On Mon, 30 Sep 2024 18:39:38 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> The problem is that many of those amateurs thought they were in fact
> professionals

Sure - but from the dawn of history, those types have *never* required
special toolsets to get in over their head. And on the flip side, far
better for amateurs to be able to create non-professional solutions
than for people to have no solution at all, when professional solutions
are either unavailable or unaffordable...

John Ames <commodorejohn@gmail.com> wrote or quoted:
>This bears repeating. As someone whose initial exposure to OOP concepts
>was via C++ (and then Java,) I spent *years* never understanding what
>the appeal was. Wasn't until I encountered Smalltalk, way on down the
>line, that I finally *got* it.

Can you explain what the that appeal was?

On Mon, 30 Sep 2024 14:26:54 +0100, The Natural Philosopher wrote:

> Because his theory that all spaces could be replaced with tabs, was not
> applicable to padded string literals inside the code itself

I've worked with interfaces where the data fields are determined by the
character position in the string with spaces used to pad fields. It was
fun explaining to the support people configuring the queries that what
appeared to be an empty field had to be exactly 5 spaces or the whole
thing would be thrown off.

On Mon, 30 Sep 2024 07:52:32 -0000 (UTC), Lawrence D'Oliveiro wrote:

> If you manage to convert the ruler of an empire to your religion, then
> he can make his subjects follow suit. Or sometimes the religious
> ideology itself serves as a unifying force to mobilize the people to
> dominate their less organized neighbours.

That works. Aethelbehrt married a little French hottie to cement the
relationship with the Franks. She was a Christian and Aethelbehrt
converting may have something to do with getting her in bed. All downhill
from there.

The conversion of the Saxons by Karl der Grosse wasn't as pleasant.

I had more limited offshoots in mind. The Second Great Awakening in the US
spawned a number of Christian variants. Some survived as minor branches
like the Seventh Say Adventists while the Latter Day Saints movement was
much more successful. More recently you have Scientology.
>
> Astute politics can work in many ways. When the Catholic missionaries
> went into Ireland and encountered the panoply of local deities, they
> renamed various of them into “saints”. And suddenly the local believers
> in those deities were no longer “pagans”, it turned out they were
> Christians all along.

Russell's 'The Germanization of Early Medieval Christianity' covers that
well. The 'Heliand' was a rewrite od the synoptics to make it more
palatable to the Saxons. Jesus was the leader of a war band who went to
the hill fort of Jerusalem. Others weren't so gentle.

https://en.wikipedia.org/wiki/Donar's_Oak

Boniface's last attempt to convert the Frisians didn't work too well and
he joined the rank of martyrs.

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

> There was a PL/0 -- I think it was a toy example language concocted by
> Wirth to demonstrate compiler techniques.

PL/0 appears in Wirth's early book _Algorithms + Data Structures = Programs_.
It is clearly on its way to becoming Pascal (which was later than the
publication of this book).

The architecture of the language is very clearly influenced by the underlying
machine architecture (the CDC 6600). It's cute.

Amusingly, when I was reading this book, my office mate--a COBOL and PL/I guru
--objected that the proper order is _Data Structures + Algorithms = Programs_.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 29/09/2024 05:26, Charlie Gibbs wrote:

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

Or actual machine instruction codes, as on the PDP-6 and PDP-10:

PUSH ac,address ;any accumulator can be a stack pointer
POP ac,address

PUSHJ ac,address ;address of next instruction on stack, jump to address
POPJ ac, ;pop address from stack and jump to it

There are also subroutine call instructions which do not use a stack, instead
using either the "save return address in first instruction of subroutine" or
"save the return address in an accumulator". The former is nonreentrant; the
latter allows placing parameters inline, with address manipulation via indexing
to access and later skip over them.

Lovely machines to program.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 30 Sep 2024 19:32:56 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> John Ames <commodorejohn@gmail.com> wrote or quoted:
> >This bears repeating. As someone whose initial exposure to OOP
> >concepts was via C++ (and then Java,) I spent *years* never
> >understanding what the appeal was. Wasn't until I encountered
> >Smalltalk, way on down the line, that I finally *got* it.
>
> Can you explain what the that appeal was?

I must confess that I haven't made enough use of it myself to say how
well it holds up in real-world usage (it certainly has its proponents,
but so does basically anything,) but ST at its core* has a beautifully
consistent, coherent approach to OOP design compared to C++ (where the
OOP elements are clearly a bolt-on to something else which never feels
entirely natural or particularly necessary - how many C++ programs are
really just C programs with a different file extension, or at best use
iostream because it's easier than reconfiguring printf format strings
every time you change what debug info you're logging to stderr?)

* (I say this because it seems to have accreted a substantial layer of
other-stuff - ST people are really, really into model-view-controller
design, f'rexample, and the GUI has evolved on a parallel track to
basically everything else in the world since the '70s, so it's not
terribly intuitive for anybody accustomed to Mac/Windows/X/* - that
may or may not be a natural fit with its way of doing things, but
isn't strictly essential to what I'm describing.)

With ST, it's "objects all the way down" (at least 'til you hit that
magic ignore-the-man-behind-the-curtain barrier that every HLL has at
some point, which is still admirably low compared to most "friendly"
languages,) and the underlying design makes it possible to examine and
modify even a substantial portion of the runtime itself.

This gives it a kind of self-similar quality that reminds me of Lisp -
nothing is magic, even the "magic" bits (the primitives generally have
a "reference" version in pure ST, when possible,) and everything's made
from the same kind of stuff. That's what I find appealing about it; I
haven't worked with it enough to say whether it's truly *useful,* but
in its own way it *is* beautiful.

On Mon, 30 Sep 2024 16:51:33 -0400, Rich Alderson wrote:

> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> On 29/09/2024 05:26, Charlie Gibbs wrote:
>
>>> 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
>
> Or actual machine instruction codes, as on the PDP-6 and PDP-10:
>
> PUSH ac,address ;any accumulator can be a stack pointer
POP ac,address
>
> PUSHJ ac,address ;address of next instruction on stack,
jump to address
> POPJ ac, ;pop address from stack and jump to it

Unfortunately not well known, but the ICL 2900 series has a good stack
implementation.

It has a stack frame pointer (ONB, or Local Name Base), a stack front
pointer (SF) as well as off stack bases. The accumulator is variable size
(32, 64, 128).

There are 32 address mode, including those that use the top of stack. So
ST.T stores the accumulator at top of stack, and LSS.T (also LSD.T and
LSQ.T for the larger sizes) to unstack. Most other instructions can
equally well use top of stack in the same way.

(yes, there's just one accumulator, but the stack etc. are heavily
cached).

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

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

John Ames <commodorejohn@gmail.com> wrote or quoted:
>On 30 Sep 2024 19:32:56 GMT
>ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>>John Ames <commodorejohn@gmail.com> wrote or quoted:
>>>This bears repeating. As someone whose initial exposure to OOP
>>>concepts was via C++ (and then Java,) I spent *years* never
>>>understanding what the appeal was. Wasn't until I encountered
>>>Smalltalk, way on down the line, that I finally *got* it.
>>Can you explain what the that appeal was?
>With ST, it's "objects all the way down" (at least 'til you hit that
>magic ignore-the-man-behind-the-curtain barrier that every HLL has at
>some point, which is still admirably low compared to most "friendly"
>languages,) and the underlying design makes it possible to examine and
>modify even a substantial portion of the runtime itself.

I see. So, it seems to me that what you discovered was more
about Smalltalk specifically than about OOP concepts in general.
I thought maybe you could give some insights about what OOP is
and what any advantages or disadvantages of it might be because in
your "I finally *got* it", I assumed that "it" referred to "OOP".