On Sat, 6 Apr 2024 18:57:47 +0200, Janis Papanagnou wrote:

> I named it always explicitly as "Algol 60" and "Algol 68". But at some
> instance of time I read somewhere that "Algol" would "now" refer to
> Algol 68, so I changed my habit.

Sure, Algol 60 is way beyond a museum piece by now. But remember, that was
the one that spawned a great number of offshoots, namely the “Algol-like”
language family--or really, superfamily. That included Pascal and its own
offshoots.

Algol 68 was a bit less influential in terms of language features (I think
C “int”, “char”, “struct” and “union”, and the “long” and “short”
qualifiers came from there, and csh “if ... fi” as well), but it did seem
to introduce a bunch of new terminology, some of which caught on, others
did not. See how many you can spot:

* “Elaboration” for the process of executing a program (including possibly
transforming from source form to an executable form)
* “Transput” instead of “input/output”
* “Heap” for an area in which memory may be dynamically allocated and
freed in no particular order
* “Overloading” for multiple context-dependent definitions of an operator
* “Name” instead of “pointer” or “address”
* “Mode” instead of “data type”
* “Coercion” for a type conversion
* “Cast” for an explicit type conversion
* “Void” for a construct yielding no value
* “Dereferencing” for following a pointer
* “Slice” for a subarray of an array
* “Pragmat” for compiler directive (I think “pragma” is more common
nowadays.)

On 07.04.2024 00:57, Lawrence D'Oliveiro wrote:
>
> Sure, Algol 60 is way beyond a museum piece by now. But remember, that was
> the one that spawned a great number of offshoots, namely the “Algol-like”
> language family--or really, superfamily. That included Pascal and its own
> offshoots.

Indeed, it became the base of a huge tree of important programming
languages.

>
> Algol 68 was a bit less influential in terms of language features

I like it more for its formal coherence than for specific features.

But of course it also has a lot of features; besides some mentioned
in your post, e.g., the generalized 'for' loop (that can even be
abbreviated for control structure subsets), but that we also find
(even in a more generalized version) already in Simula 67, BTW.

> (I think
> C “int”, “char”, “struct” and “union”, and the “long” and “short”
> qualifiers came from there, and csh “if ... fi” as well), [...]

It was more a base for the Bourne shell family (and its successors,
including POSIX shell through ksh88). But yes, it influenced quite
some languages. And, yes, it was less influential than Algol 60.

Janis

On 07.04.2024 00:57, Lawrence D'Oliveiro wrote:
>
> Algol 68 was a bit less influential in terms of language features [...]
> See how many you can spot:
>
> * “Elaboration” for the process of executing a program (including possibly
> transforming from source form to an executable form)
> * “Transput” instead of “input/output”

After all these decades it sounds still strange in my ears.

> * “Heap” for an area in which memory may be dynamically allocated and
> freed in no particular order
> * “Overloading” for multiple context-dependent definitions of an operator
> * “Name” instead of “pointer” or “address”

Well, we had function parameters called "by name" before.

And we have 'REF' for references. (Also seen in Simula 67.)

> * “Mode” instead of “data type”
> * “Coercion” for a type conversion
> * “Cast” for an explicit type conversion
> * “Void” for a construct yielding no value

This is an interesting thing in Algol 68 if you study the
details!

As the "type" of statements it makes function definitions
or the mentioned conditionals (statements and expressions)
a coherent concept.

> * “Dereferencing” for following a pointer
> * “Slice” for a subarray of an array
> * “Pragmat” for compiler directive (I think “pragma” is more common
> nowadays.)

And maybe printf() and the op:= set of operators, and more.

I also find its collateral abilities very interesting. But I
seem to recall that not every compiler supports that.

Janis

On Sat, 6 Apr 2024 08:58:45 -0000 (UTC), Muttley wrote:

> Lisp overloads them as block markers which simply makes the code more
> confusing, not less.

That’s because there is no fundamental difference between “blocks” and
whatever else it is you think those Lisp parentheses are used for.

On Sun, 7 Apr 2024 01:47:13 +0200, Janis Papanagnou wrote:

> On 07.04.2024 00:57, Lawrence D'Oliveiro wrote:
>>
>> * “Name” instead of “pointer” or “address”
>
> Well, we had function parameters called "by name" before.

Those were actually “thunks”. An early draft Algol 68 spec kept them on in
the form of “proceduring” coercions, but these were dropped in the revised
report.

See also <https://en.wikipedia.org/wiki/Jensen%27s_device>.

In comp.unix.shell Johanne Fairchild <jfairchild@tudado.org> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> At one time, we distinguished between “scripting” languages and
>> “programming” languages. [...] But there is one distinction that I
>> think is still relevant, and that is the one between shell/command
>> languages and programming languages.
>
> [...]
>
> Consider looking at a shell language like a domain-specific programming
> language. A shell is a programming language made specifically for
> running programs. When you write a shell line, you're specifying the
> arguments of execve(2). In other words, a shell is a programming
> language made to prepare the memory to be consumed by the system in a
> specific way---execve(2).

It certainly encourages the writing of small modular tools. The
downside is the loss of performance because of disk access for trivial
things like 'nfiles=$(ls | wc -l)'. I suspect disk access times where
one of the reasons for the development of perl in the early 90s.

On Sun, 07 Apr 2024 00:01:43 +0000, Javier wrote:

> The downside is the loss of performance because of disk access for
> trivial things like 'nfiles=$(ls | wc -l)'.

Well, you could save one process creation by writing
“nfiles=$(echo * | wc -l)” instead. But that would still not be strictly
correct.

> I suspect disk access times where
> one of the reasons for the development of perl in the early 90s.

Shells were somewhat less powerful in those days. I would describe the
genesis of Perl as “awk on steroids”. Its big party trick was regular
expressions. And I guess combining that with more sophisticated data-
structuring capabilities.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
[...]
> Sure, Algol 60 is way beyond a museum piece by now. But remember, that was
> the one that spawned a great number of offshoots, namely the “Algol-like”
> language family--or really, superfamily. That included Pascal and its own
> offshoots.
>
> Algol 68 was a bit less influential in terms of language features (I think
> C “int”, “char”, “struct” and “union”, and the “long” and “short”
> qualifiers came from there, and csh “if ... fi” as well), but it did seem
> to introduce a bunch of new terminology, some of which caught on, others
> did not. See how many you can spot:

csh uses "if ... then ... endif". Bourne shell uses "if ... fi" (and
"case ... esac").

> * “Elaboration” for the process of executing a program (including possibly
> transforming from source form to an executable form)

In Ada, statements are "executed", expressions are "evaluated", and
declarations are "elaborated".

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 07 Apr 2024 00:01:43 +0000, Javier wrote:
>
>> The downside is the loss of performance because of disk access for
>> trivial things like 'nfiles=$(ls | wc -l)'.
>
> Well, you could save one process creation by writing
> “nfiles=$(echo * | wc -l)” instead. But that would still not be strictly
> correct.

If that saves a process, it's because echo is builtin. But it will set
$nfiles to 1 (unless you happen to have files with newlines in their
names). Both skip hidden files, which may or may not be what you want.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Muttley@dastardlyhq.com writes:

On Fri, 05 Apr 2024 19:35:37 -0400
Alan Bawden <alan@csail.mit.edu> wrote:
...
>I.e., she would allow herself to use spaces and newlines, and just

ITYM "he" would allow HIMself.

My practice when I am writing and I need a generic pronoun is to flip a
coin to decide whether I am going to use "she" or "he". On this
occasion the coin determined that I was going to write "she".

I started doing this many years ago after some author, in his book's
introduction, offered as a defense of using exclusively male pronouns in
the rest of his book the fact that he had just used female pronouns in
the previous paragraph, and "the reader will have found this jarring".
Well I hadn't actually noticed that he had done that, and I had to go
back and check to be sure he had.

The book in question was a couple decades old at that time, so I took my
failure to notice what the author thought I would find jarring as
evidence that the language had evolved to the point where a occasional
generic "she" would not offend a reasonable reader. So for years I've
used "she" about 50% of the time, and nobody has _ever_ objected.

Until today...

Lets give the woke BS a miss, 95% of developers are men. It doesn't
give you any brownie points, just makes you look a try-hard ass.

It doesn't matter to me what percentage of developers are male. As long
as there are _some_ female developers, it is possible that the developer
in a hypothetical situation might be female, so it seems fair to
occasionally use "she".

If acknowledging the existence of female developers makes you
uncomfortable, you're just going to have to learn to deal with that
yourself. I'm not going to adjust my language to cater to your
insecurities.

- Alan

On 06/04/2024 22:54, Janis Papanagnou wrote:
> But, WRT Algol 60 vs. Algol 68, these are quite different languages;
> I wouldn't call the latter a new version.

I agree; OTOH, WG2.1 accepted A68 as the "new" Algol. The
instant question here was what an unadorned "Algol" means, and while
I can see an argument for saying that it shouldn't happen, I can see
no argument for saying that it, by default, refers to A60.

[...]
> Algol 60, OTOH, also had an own history and continued use after 1968;
> to my knowledge it had been used in numerical mathematics [...].

It was intended for use in the /description/ of NA, for which
it was decently suitable. But it was unsuitable as a practical language
for use in NA: no proper error control, no double-length numbers, no
array slices, and doubtless other things I've forgotten. So you could
say "Here is my new whizzo algorithm for [whatever]", get it published,
and "everyone" would understand what your code meant. But in practice
you would transcribe it into Fortran or some Autocode, typically twice
as fast and with much better practical facilities.

> But Algol 60, Simula, and also Algol 68 are all meaningless today, I
> (sadly) dare to say.

You're probably right. But A68G is still a nice language. It
creaks in places, and it's not suitable for everything [what is?]. But
it serves all my programming needs. It has the advantage, in practice,
over C that all the common programming blunders -- use of uninitialised
variables, array accesses out of bounds, numerical overflow, dereferencing
null pointers, memory leaks and consequences thereof, the things that
cause most of the security holes -- are picked up either by the compiler
or at run-time before they can do any damage. I expect there are modern
languages that also do that, but at my age it's not worth learning a new
language when the old one works perfectly well.

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

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 06.04.2024 20:32, Andy Walker wrote:
>
>
>But Algol 60, Simula, and also Algol 68 are all meaningless today, I
>(sadly) dare to say. Maybe more than of "niche interest"? Can't tell.

There is still some small amount of new Algol code being developed
and likely quite a bit in production in Unisys Clearpath shops.

On Sun, 7 Apr 2024 14:43:04 +0100, Andy Walker wrote:

> I can see no argument for saying that [“Algol”], by default, refers to
> A60.

“Wirth-Hoare Algol”, a.k.a. “Algol-W” (the precursor of Pascal) was a
derivative of Algol-60, not Algol-68 (which didn’t exist yet).

“Burroughs Algol” was an implementation of Algol-60, not Algol-68.

Even in the 21st century, articles like
<https://seattlewebsitedevelopers.medium.com/algol-the-language-that-influenced-the-future-cfec9a3e2a4c>
can say

Generally called ALGOL 60, ALGOL had three major updates ...

Andy Walker <anw@cuboid.co.uk> writes:
> On 06/04/2024 22:54, Janis Papanagnou wrote:
>> But, WRT Algol 60 vs. Algol 68, these are quite different languages;
>> I wouldn't call the latter a new version.
>
> I agree; OTOH, WG2.1 accepted A68 as the "new" Algol. The
> instant question here was what an unadorned "Algol" means, and while
> I can see an argument for saying that it shouldn't happen, I can see
> no argument for saying that it, by default, refers to A60.

The question is not which language "Algol" *should* refer to. Or
rather, that's a different question. The question is which language
"Algol" refers to in real-world common usage. In my (obviously not
universal) experience, "Algol" by itself never means Algol 68; it always
means Algol 60.

https://en.wikipedia.org/wiki/ALGOL

ALGOL 68 is substantially different from ALGOL 60 and was not well
received,[according to whom?] so reference to "Algol" is generally
understood to mean ALGOL 60 and its dialects.[citation needed]

Since this confusion obviously exists, I suggest referring to "Algol 60"
and "Algol 68" explicitly.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Sat, 6 Apr 2024 23:49:30 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 6 Apr 2024 08:58:45 -0000 (UTC), Muttley wrote:
>
>> Lisp overloads them as block markers which simply makes the code more
>> confusing, not less.
>
>That’s because there is no fundamental difference between “blocks” and
>whatever else it is you think those Lisp parentheses are used for.

Hmm, wonder why hardly anyone outside academia used the language even back in
the day, never mind now....

On Sun, 07 Apr 2024 06:04:16 -0400
Alan Bawden <alan@csail.mit.edu> wrote:
>If acknowledging the existence of female developers makes you
>uncomfortable, you're just going to have to learn to deal with that
>yourself. I'm not going to adjust my language to cater to your
>insecurities.

If my insecurities you mean acknowledging reality then fine. The thing about
people like you is (and I don't believe the 50% thing, sorry) is that you
would never use a male pronoun if talking about nurses or pre school teachers
who are heavily biased towards women.

On 06.04.2024 11:00, Muttley@dastardlyhq.com wrote:
> On Fri, 05 Apr 2024 19:35:37 -0400
> Alan Bawden <alan@csail.mit.edu> wrote:
>>
>> A normal programmer would write something like:
>> [...]
>> I.e., she would allow herself to use spaces and newlines, and just
>
> ITYM "he" would allow HIMself.

That topic is heated (also in the country where I'm living in[*]).

The solution might be to take out the personal aspects in writing.
(BTW; a "normal programmer" is already a problematic formulation;
but that's not the central issue here.)

The "she would allow herself" could be formulated in two forms, a
plural form ("we would allow ourselves") or a non-personal form
("spaces or newlines could be used"). - Note I'm not a native EN
speaker, so please correct and inaccuracy in my formulations. But
I'm sure that such formulations should be possible in some form
also in English.

Anyway, let's not carry such senseless battle into out posts.

Janis

[*] Here the municipal government of our city has rules to foster
speech and writing that (by its form) includes "the two" genders.
But these rules don't cover a third gender we officially have to
support, a non-male/female gender form ("diverse"), that are now
acknowledged by the laws of our country (thus discriminating the
third gender people by city-rules, by now mentioning [only] two.
And recently the state my city is part of forbids writing in forms
that are not correct language, thus effectively forbidding these
gender forms. Incompatible country, state, and city laws and rules;
it's crazy!

On 07.04.2024 15:43, Andy Walker wrote:
>
> I agree; OTOH, WG2.1 accepted A68 as the "new" Algol. The
> instant question here was what an unadorned "Algol" means, and while
> I can see an argument for saying that it shouldn't happen, I can see
> no argument for saying that it, by default, refers to A60.

Well, after that other post I decided to explicitly differentiate them
per year suffix to not confuse anyone. That's okay for me. (OTOH I just
notice that I missed to identify "Simula" as "Simula 67"; there's also
"Simula I". But in case of Simula it's anyway more of a version.[*])

>
>> But Algol 60, Simula, and also Algol 68 are all meaningless today, I
>> (sadly) dare to say.
>
> You're probably right. But A68G is still a nice language. It
> creaks in places, and it's not suitable for everything [what is?]. But
> it serves all my programming needs. It has the advantage, in practice,
> over C that all the common programming blunders -- use of uninitialised
> variables, array accesses out of bounds, numerical overflow, dereferencing
> null pointers, memory leaks and consequences thereof, the things that
> cause most of the security holes -- are picked up either by the compiler
> or at run-time before they can do any damage. I expect there are modern
> languages that also do that, but at my age it's not worth learning a new
> language when the old one works perfectly well.

Yes, indeed.

Janis

[*] Nice fact, BTW, that you can compile (almost all) Algol 60
programs with Simula 67 - Algol 60 is [mostly] a subset - but not
with Algol 68, which is a different language.

On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
> On Sun, 07 Apr 2024 06:04:16 -0400
> Alan Bawden <alan@csail.mit.edu> wrote:
>> If acknowledging the existence of female developers makes you
>> uncomfortable, you're just going to have to learn to deal with that
>> yourself. I'm not going to adjust my language to cater to your
>> insecurities.
>
> If my insecurities you mean acknowledging reality then fine. The thing about
> people like you is (and I don't believe the 50% thing, sorry) is that you
> would never use a male pronoun if talking about nurses or pre school teachers
> who are heavily biased towards women.
>

What makes you so sure about that? Are you assuming that because /you/
are sexist, everyone else is?

It is a fact that some professions have a heavy gender bias. Yes, most
programmers are male, and most nurses are female. It is even reasonable
to say that for some tasks there are statistically relevant biological
differences that justify a bias (in the same way that you can say men
are, on average, taller than women, even though some women are taller
than some men).

But is it a good thing that there is such gender bias? Usually not - it
is usually best to have a mix in all practical ways (genders, race,
nationality, age, etc.).

Being inclusive in the language used is not likely to make a big dent in
attracting people from poorly represented groups in a particular field -
but using non-inclusive language does make a difference in chasing away
those that venture in. Worst of all is people like you who actively say
that women programmers are so abnormal we should ignore the possibility
of their existence!

Some people write "he/she". Some people alternate gender pronouns, or
pick randomly. Some people use "they", or try to avoid using pronouns
at all in their wording. These are all fine. It is also entirely
understandable that some people just write "he" because they don't think
about it at all. But I can't understand the mentality of someone who
actively tries to work against inclusive language. We are not talking
about some kind of quota system that you might feel is unfair, or even
requiring you to change /your/ language - we are talking about someone
who used "she" in reference to "a normal programmer", and that has got
you throwing a fit.

And for the record, I would use he/she/they for nurses or pre-school
teachers if I did not know the gender of the individual.

On 07.04.2024 23:05, Lawrence D'Oliveiro wrote:
>
> Even in the 21st century, articles like
> <https://seattlewebsitedevelopers.medium.com/algol-the-language-that-influenced-the-future-cfec9a3e2a4c>
> can say
>
> Generally called ALGOL 60, ALGOL had three major updates ...

An extremely badly written article in *all* aspects (form, content,
facts, quality, etc.). Not worth reading (I've just read it).
And thus even less useful as sort of "reference" to any argument.

Janis

On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
>> On Sun, 07 Apr 2024 06:04:16 -0400
>> Alan Bawden <alan@csail.mit.edu> wrote:
>>> If acknowledging the existence of female developers makes you
>>> uncomfortable, you're just going to have to learn to deal with that
>>> yourself. I'm not going to adjust my language to cater to your
>>> insecurities.
>>
>> If my insecurities you mean acknowledging reality then fine. The thing about
>> people like you is (and I don't believe the 50% thing, sorry) is that you
>> would never use a male pronoun if talking about nurses or pre school teachers
>
>> who are heavily biased towards women.
>>
>
>What makes you so sure about that? Are you assuming that because /you/
>are sexist, everyone else is?

An immediate fallacious ad hominem no doubt in order to prop up whatever
straw men follow.

tl;dr, bugger off.

On Sun, 07 Apr 2024 00:01:43 +0000
Javier <invalid@invalid.invalid> wrote:

> It certainly encourages the writing of small modular tools. The
> downside is the loss of performance because of disk access for trivial
> things like 'nfiles=$(ls | wc -l)'. I suspect disk access times where
> one of the reasons for the development of perl in the early 90s.

You really want either built-ins for a lot of basic commands, or a good
scheme for caching commonly-used executables. AmigaDOS (a TriPOS
derivative) made it pretty trivial to set up a RAM disk and add that to
the search path, which made a big difference in performance since
almost nothing was built-in. Wouldn't be hard to do in *nix-land,
either, but it's an open question whether you'd gain anything over
modern generalized disk caching.

On Sat, 6 Apr 2024 00:25:45 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> It’s like, I don’t know ... you’re trying to save space. Why?
>
> It’s like programming inside an apartment block, instead of having a
> bungalow with a yard of your own.

It's a matter of balance. Needlessly crunching things to fit onto a
single line is hard to read, yes - but compulsively indenting and
splitting across lines can get out of hand, too. It seems to me that a
lot of people in this age of "cinematic" aspect ratios and super-sized
displays in personal computing forget that eye-travel isn't free, and
spreading information across maximal space can make it *harder* to keep
track of context.

Better, IMHO, to group operations in a way that logically reflects the
structure of the program, to whatever extent that *A.* is syntactically
feasible in $LANGUAGE, and *B.* doesn't crowd things to the point of
hampering basic readability.

(Of course, whether or not the ternary operator is fundamentally
confusing is an entirely separate question.)

In article <uv0v7l$3i0l6$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
....
>An immediate fallacious ad hominem no doubt in order to prop up whatever
>straw men follow.

When you find yourself in a hole, the first thing to do is to stop digging.

--
Genesis 2:7 And the LORD God formed man of the dust of the ground, and
breathed into his nostrils the breath of life; and man became a living soul.

On Mon, 8 Apr 2024 15:20:57 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>In article <uv0v7l$3i0l6$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>....
>>An immediate fallacious ad hominem no doubt in order to prop up whatever
>>straw men follow.
>
>When you find yourself in a hole, the first thing to do is to stop digging.

Thats fine, I'll keep watching you lot dig your holes while I stand at the
side.