On Mon, 30 Sep 2024 05:52:35 GMT, Charlie Gibbs wrote:

> Be generous with comments ... [etc etc]

.... and remember they’re supposed to explain *why* the code does
something, not just repeat *what* it does.

You’re talking to someone who has code in his collection going back over
40 years. I learned the lessons of comments long ago.

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.

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.

On 9/30/24 1:52 AM, Charlie Gibbs wrote:
> On 2024-09-30, 186282@ud0s4.net <186283@ud0s4.net> wrote:
>
>> I've occasionally done that with Python.
>>
>> HOWEVER, the FUTURE readability suffers considerably.
>>
>> IMHO, write code so YOU can go back to it like five
>> years later and actually grasp what you did and why.
>> Overly-complex code, and 'feature creep' RUIN pgms.
>
> Yup. Be generous with comments, and write them in plain
> English, not some cryptic set of abbreviations that nobody
> else would understand. And remember that those comments
> aren't necessarily for someone else - they're for you
> six months from now, when you've forgotten why you wrote
> what you did.

All my work had more comments than code ... almost
every line explained and 'concept' stuff above
every function.

However 5+ years on, STILL kinda difficult to
get the whole groove sometimes. This is not
so good, but it seems COMMON.

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

On 30 Sep 2024 07:21:49 GMT, 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...

No, it wasn’t that. I had a full four digits for the year number (even
back then, I had this hazy premonition ...). The bug actually manifested
itself from 2004 onwards.

Here’s the patch that fixed the Fortran-90 version:

diff --git a/calend.f90 b/calend.f90
index e172fd5..dcbfdc3 100644
--- a/calend.f90
+++ b/calend.f90
@@ -48,14 +48,12 @@ contains
idx = idx + 1
res = mod(yr, divs(idx))
yr = yr / divs(idx)
- if (res == 0) then
+ if (flip_leap .and. res == 0) then
+ leap = .not. leap
rem = rem - l
else
flip_leap = .false.
end if
- if (flip_leap) then
- leap = .not. leap
- end if
if (yr == 0) &
exit
rem = rem + yr * l

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

> ... but it seems COMMON.

.... sorry, I thought you were making a Fortran joke ...

On 9/30/24 3:56 AM, Lawrence D'Oliveiro wrote:
> On Mon, 30 Sep 2024 03:40:49 -0400, 186282@ud0s4.net wrote:
>
>> ... but it seems COMMON.
>
> ... sorry, I thought you were making a Fortran joke ...

Almost :-)

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

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

You're right. I had suppressed that memory. M$ has made many bad
design decisions, this shows that they also spread a lot of bugs.

--
/~\ 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-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.

--
/~\ 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-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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

That may be, but we could never figure out how to get our impact
printers to print a horizontal pitch of anything other than 10
characters per inch. There was something about the spacing of
the print hammers, timing of the print band, etc. Laser printers
had just come out, but they still cost a quarter of a million
dollars, and we couldn't squeeze that - or the expansion of the
computer room to hold the beast - into the budget.

But that's just me being ANAL again.

--
/~\ 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 Mon, 30 Sep 2024 05:46:39 GMT, 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.

Where would all this save area go?

On Mon, 30 Sep 2024 05:46:40 GMT, Charlie Gibbs wrote:

> Laser printers had just come out, but they still cost a quarter of a
> million dollars ...

Ah, this was before the debut of the legendary Canon LBP-CX engine (basis
of both the original Apple LaserWriter and the original HP LaserJet) then.

On Mon, 30 Sep 2024 05:46:38 GMT, Charlie Gibbs wrote:

> On 2024-09-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> I think Excel did actually consider 1900 to be a leap year at one
>> point.
>
> You're right. I had suppressed that memory.

Sorry to bring it back ...

On Sun, 29 Sep 2024 22:38:25 -0400, 186282@ud0s4.net wrote:

> Have NO idea what PayPal/EBay/etc use. If they're smart they'll kinda
> HIDE that. Whatever it is, it's probably translated into 'C' at some
> point to build the final executables.

Assuming PayPal etc lasts 30 years do you think they will have at some
point rewritten their entire codebase in the flavor of the day or will
UseNet in 2054 be talking about the ugly, obsolete patched up mess?

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.

On 30 Sep 2024 07:40:58 GMT, rbowman wrote:

> Why does Religion X survive while Religion Y,
> which is equally as plausible/implausible become an also ran?

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.

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.

> Others like the i86 architecture seem more like accidents at a point in
> time.

I guess it came down to: Intel’s CPU chips had fewer pins on them,
compared to Motorola’s. That was a major factor in the cost. And when the
marketing behemoth of the time, IBM, made its decision, that clinched it.

On 9/30/24 3:26 AM, rbowman wrote:
> On Sun, 29 Sep 2024 22:38:25 -0400, 186282@ud0s4.net wrote:
>
>> Have NO idea what PayPal/EBay/etc use. If they're smart they'll kinda
>> HIDE that. Whatever it is, it's probably translated into 'C' at some
>> point to build the final executables.
>
> Assuming PayPal etc lasts 30 years do you think they will have at some
> point rewritten their entire codebase in the flavor of the day or will
> UseNet in 2054 be talking about the ugly, obsolete patched up mess?

The ugly patched MESS :-)

BET on it !

Rewriting large code-bases ... TOO time consuming,
TOO risky, TOO expensive - so they WON'T. It's like
the old COBOL code in recent threads here. Hire a
few gurus and PATCH PATCH PATCH.

EVENTUALLY the whole thing will implode, of course.
But the IDEA is that it won't happen on YOUR watch.

It was recently reported that the US Internal Revenue
Service was STILL using rather a lot of 60s hardware
and software for daily needs. Software can be fixed
and patched - but the HARDWARE ! Even transistors
and diodes and resistors have a HALF-LIFE. Most of
the old mini/mainframe vendors are GONE or totally
out of that biz. So WHO maintains the hardware ???
That'd be MAJOR.

The old IBM System-360s had a mass of what LOOKED like
'chips' in the big CPU unit. However, pop 'em open and
they were some discrete transistors/resistors - each
was an independent logic gate, hand soldered. IBM is
still in biz, but almost all the others are just GONE.

Yea, in theory, you can EMULATE old mini/mainframes,
but at least in the case of the IRS and likely many
other govt/mil entities they just don't DARE. They
will keep the old hardware running NO MATTER WHAT.
What they've got WORKS. Never mess with what works.
Can't AFFORD to mess with it anyway. Nobody wants
a failure on THEIR watch either .......

In short, we built a tech "foundation" mostly during
the 1960s. Much else DEPENDS on it being solid and
maintained kinda FOREVER.

On 9/29/24 07:50, The Natural Philosopher wrote:
> 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.

I think of OO more as a design philosophy than a language feature. The
early problem I saw with C++ was projects that implemented classes
bottom up. If you saw they had written their own string class, you
immediately knew the project was going to fail.

The basic idea behind this is that initially you need to have a good
overall picture of what your application is going to do. You need to be
able to split a project into separate parts, separate components. This
effectively mapped to designing classes top down.

The failing projects would get programmers learning a new language
trying to develop utility classes to make their life "easy". They would
spend all their time doing this and hence the project would fail. It
would also be difficult to on board new programmers, due to all the
badly designed utility classes they needed to learn.

Of its self I thought C++ was a brilliant language, for its time.

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

It maps fine. Most optimisation is about efficient algorithms, not about
shaving micro-seconds off a loop in a crap or naive algorithm.

Without high level concepts such as objects, it is very hard to
implement more abstract, but more efficient algorithms. Caveat, I'm
relatively bad with complexity. I'm very good with simplicity, but bad
with complexity, I have sometimes wondered if there are different types
of intelligence. I have worked with Cambridge types who claimed to be
good with complexity.

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

Yes, I could implement OO designs in C, and I would if I had to, but I
would be borrowing what I learnt from C++ and other OO languages.

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

Syntactic sugar can be nice, as long as it doesn't obscure what is
really going on. Mainly I don't like it because it makes unfamiliar
languages harder to understand.

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

Oh, I can be unaware of what my code is really doing, in any language :-)

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

And you can deallocate RAM many times, or not at all. I have a friend
interested in music and he won't touch garbage collection, but I rarely
cared about non deterministic short pauses. The benefits of not doing
all the janitor stuff with memory was huge.

I think even non garbage collection modern languages try to automate
memory allocation and deallocation, ref counting, out of scope
destructors etc. Being happy with garbage collection I never looked at
it, but the ideas date back to (at least) the mid 1990s C++, Scott
Meyers etc.

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

Only with old codgers.

>
>

On 9/30/24 00:15, Lawrence D'Oliveiro wrote:
> C3 linearization

Never heard of that before. It sounds far to difficult to understand in
practice. I'll leave topological sorts, dependency graphs to spreadsheets.

On 9/29/24 06:35, Lawrence D'Oliveiro wrote:
> 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.

The problem predated Excel. Microsoft knowingly implemented it that way
for compatibility with Lotus 123.

In alt.folklore.computers Peter Flass <peter_flass@yahoo.com> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On 25 Sep 2024 04:38:54 GMT, rbowman wrote:
>>
>>> Better Pascal than Modula/Modula-2.
>>
>> It’s in the name: “modular”. Pascal had features like I/O and memory
>> management as predefined functions/procedures; Modula-2 made them into
>> library routines that could be implemented in Modula-2 itself.
>>
>> Why? So that Modula-2 could be used to write an actual operating system
>> (Medos, for the Lilith workstation), which you couldn’t do in Pascal
>> alone.
>>
>
> Operating Systems written in FPC
>
> https://wiki.freepascal.org/Operating_Systems_written_in_FPC
>
> I don’t know how much has been added to FPC above the base language.

Free Pascal started as open source implementation of Borland Turbo
Pascal. Turbo Pascal added esentailly all features of C like
casts, pointer arithmetic and bit operations. And Turbo Pascal
programs massively used inline assembly (Free Pascal is intended
to be partable and I saw no example of inline assemby in Free
Pascal but I think that it is supported).

--
Waldek Hebisch

On 29/09/2024 21:00, rbowman wrote:
> On Sun, 29 Sep 2024 05:42:15 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> 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.
>
> How many government agencies, financial institution and so forth do you
> think DON NOT have reams of legacy COBOL?
>
I suspect PayPal and Ebay actually do still use COBOL somewhere
The investment represented by 5-10 man years of COBOL back in 1975 is a
lot more than the machine to run it on today, and the glue software to
integrate it into whatever software muddle companies use today.

My brush with financial software suggest that it is (or was 15 -20 years
aqo) run on Oracle databases, by and in Oracle aligned software data
centres. In short the code development and the data is outsourced to a
big secure data centre

Oracle had a version of COBOL (PRO COBOL) that is able to call SQL
statements.

I think it is still supported.

They also have a FORTRAN that can interface to it. What better place to
put gigabytes of scientific data than an Oracle database?

And scientists still use FORTRAN

Now as far as new code is concerned, COBOL is still being written. But
my nephew who writes banking software in Australia says he uses Java mostly.
A friend who does that uses C++

I've written database based software in PHP, and C. As a web application.

"about 240 billion lines of COBOL are in use today, and about 5 billion
lines of COBOL code are written each year, claims IBM"

....a random google found.

There are huge FORTRAN libraries around that have taken years to write.
COBOL and FORTRAN are not hard languages to learn, especially for non
computer nerds. And they work and are well supported.
Why NOT carry on using them?

--
"Socialist governments traditionally do make a financial mess. They
always run out of other people's money. It's quite a characteristic of them"

Margaret Thatcher

On 30/09/2024 08: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.
Damn good question. I can answer for C and c++ personally, in that the
investment in time and effort to learn C++ and be fluent at it was
simply not worth it, whereas with C back in 1983 it was the other way
about. a huge increase in productivity for the simple expedient of
reading and digesting K &R which was not a big book at all.
I have MASSIVE books to describe out of date Jasvascript and C++ ...

Stroustrup joked that C+++ would increase employment of programmers.

I also briefly was paid to port FORTH to an 8086 board. Not a PC, a part
of a minicomputer. I was impressed by how small it was, but utterly
unimpressed by how you were supposed to document it.
LISP - Lots of Irrelevant Superfluous Parentheses is simply a
theoretical language I never saw the point of. Same with Prolog.
Pascal was impractical in an engineering context as it didn't envisage
real world I/O. Too formal and academic
Modula 2 was Pascal on steroids. Designed to write bug proof code. Well
anyone can do that...
printf("hello world"); That's bug proof. Just wont fly an F35
I had a girl friend who did COBOL back in the day. I liked it. Burt
financial programming want my 'thing'
I did FORTRAN,. Well its pretty much a better form of BASIC. Good
languages for non computer people.

I learnt PHP because it was the de facto open source code to run active
websites. I learnt SQL and in particular mySQL because they were again
the de facto choice . I learn JavaScript because it is the only language
that runs in peoples browsers, and if you ant a smart web app there is
no other real choice.

I hate it. It really is the most utter and complete shit. So shit they
had to write json to cover up the mess.

But is here to stay because it was there, like MSDOS, at a time when we
needed a standard, and like MSDOS it too is a pile of crap.

This suggests to me that there are two factors that make for a languages
success.
1/. It aptly fills a niche really well.
or
2/. It is the only language in town, and people learn how to avoid the
worts of its egregiousness.

--
"Anyone who believes that the laws of physics are mere social
conventions is invited to try transgressing those conventions from the
windows of my apartment. (I live on the twenty-first floor.) "

Alan Sokal

On 29/09/2024 21:15, Peter Flass wrote:
> John Levine <johnl@taugh.com> 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.
>>
>
> C was/is great for the low-level systems stuff, but then it started getting
> used for everything, and getting stuf added to greatly complexity it.
>
Well yes. But you get around that by writing powerful well documented C
libraries, so that complex operations become a simple function call.

--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey

On 29/09/2024 21:15, Peter Flass wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> 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.
>>
>
> Done for years before stacks were invented. You just can’t have RECURSIVE
> subroutines, or at least not without a lot of work. A fairly common calling
> convention, used on the 1130, saves the “next” address after the CALL in
> the first word of the subroutine and jumps to the second. Arguments follow
> the CALL, so you can access them using the saved word, otherwise the return
> address, as an index. If you want recursion you have to stash the return
> address somewhere.
>
In my terms that is 'some form of stack' :-)

--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey