Rocksolid Light

News from da outaworlds

mail  files  register  groups  login

Message-ID:  

BOFH excuse #164: root rot


comp / comp.unix.shell / Re: Command Languages Versus Programming Languages

SubjectAuthor
* Re: Command Languages Versus Programming LanguagesBozo User
+* Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
|`* Re: Command Languages Versus Programming Languagesusuario
| `* Re: Command Languages Versus Programming LanguagesMuttley
|  `* Re: Command Languages Versus Programming Languagesusuario
|   `- Re: Command Languages Versus Programming LanguagesMuttley
`* Re: Command Languages Versus Programming LanguagesRainer Weikusat
 `* Re: Command Languages Versus Programming LanguagesMuttley
  +* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  |+* Re: Command Languages Versus Programming LanguagesMuttley
  ||+* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  |||+* Re: Command Languages Versus Programming LanguagesKaz Kylheku
  ||||`* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  |||| `* Re: Command Languages Versus Programming LanguagesBart
  ||||  `* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  ||||   `* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    +* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |+* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    ||+* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||`* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    ||| `* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||  `* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    |||   +* Re: Command Languages Versus Programming LanguagesScott Lurndal
  ||||    |||   |`- Re: Command Languages Versus Programming LanguagesMuttley
  ||||    |||   `* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||    `* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    |||     +* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||     |+* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    |||     ||+* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||     |||`* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    |||     ||| +* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||     ||| |`* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    |||     ||| | `* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||     ||| |  `* Re: Command Languages Versus Programming LanguagesMuttley
  ||||    |||     ||| |   `* Re: Command Languages Versus Programming LanguagesScott Lurndal
  ||||    |||     ||| |    `- Re: Command Languages Versus Programming LanguagesDavid Brown
  ||||    |||     ||| `- Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
  ||||    |||     ||`- Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
  ||||    |||     |`* Re: Command Languages Versus Programming LanguagesScott Lurndal
  ||||    |||     | `* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||     |  `* Re: Command Languages Versus Programming LanguagesBart
  ||||    |||     |   `* Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |||     |    `* Re: Command Languages Versus Programming LanguagesBart
  ||||    |||     |     `- Re: On overly rigid definitions (was Re: Command Languages Versus Programming LaDan Cross
  ||||    |||     `- Re: Command Languages Versus Programming LanguagesScott Lurndal
  ||||    ||`* Re: Command Languages Versus Programming LanguagesKaz Kylheku
  ||||    || +- Re: Command Languages Versus Programming LanguagesBart
  ||||    || `- Re: Command Languages Versus Programming LanguagesDan Cross
  ||||    |`- Re: Command Languages Versus Programming LanguagesScott Lurndal
  ||||    +* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  ||||    |`- Re: Command Languages Versus Programming LanguagesMuttley
  ||||    `* Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
  ||||     `* Re: Command Languages Versus Programming LanguagesMuttley
  ||||      +* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  ||||      |+* Re: Command Languages Versus Programming LanguagesChristian Weisgerber
  ||||      ||+- Re: Command Languages Versus Programming LanguagesMuttley
  ||||      ||`- Re: Command Languages Versus Programming LanguagesRainer Weikusat
  ||||      |`- Re: Command Languages Versus Programming LanguagesBart
  ||||      `* Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
  ||||       `* Re: Command Languages Versus Programming LanguagesMuttley
  ||||        `- Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
  |||+* Re: Command Languages Versus Programming LanguagesBart
  ||||`- Re: Command Languages Versus Programming LanguagesRainer Weikusat
  |||`* Re: Command Languages Versus Programming LanguagesMuttley
  ||| `- Re: Command Languages Versus Programming LanguagesRainer Weikusat
  ||`- Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
  |`* Re: Command Languages Versus Programming LanguagesEric Pozharski
  | `* Re: Command Languages Versus Programming LanguagesMuttley
  |  +- Re: Command Languages Versus Programming LanguagesJanis Papanagnou
  |  +* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  |  |`* Re: Command Languages Versus Programming LanguagesMuttley
  |  | `* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  |  |  `* Re: Command Languages Versus Programming LanguagesMuttley
  |  |   `* Re: Command Languages Versus Programming LanguagesRainer Weikusat
  |  |    `- Re: Command Languages Versus Programming LanguagesMuttley
  |  `- Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
  `* Re: Command Languages Versus Programming LanguagesSebastian
   +* Re: Command Languages Versus Programming LanguagesMuttley
   |+* Re: Command Languages Versus Programming LanguagesWolfgang Agnes
   ||`- Re: Command Languages Versus Programming LanguagesMuttley
   |+- Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
   |`* Re: Command Languages Versus Programming LanguagesJanis Papanagnou
   | `* Re: Command Languages Versus Programming LanguagesMuttley
   |  +* Re: Command Languages Versus Programming LanguagesJanis Papanagnou
   |  |`* Re: Command Languages Versus Programming LanguagesMuttley
   |  | `* Re: Command Languages Versus Programming LanguagesJanis Papanagnou
   |  |  `- Re: Command Languages Versus Programming LanguagesMuttley
   |  `- Re: Command Languages Versus Programming LanguagesWolfgang Agnes
   `* Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
    +* Re: Command Languages Versus Programming LanguagesJanis Papanagnou
    |+- Re: Command Languages Versus Programming LanguagesWolfgang Agnes
    |`- Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
    `* Re: Command Languages Versus Programming LanguagesRandal L. Schwartz
     +- Re: Command Languages Versus Programming LanguagesLawrence D'Oliveiro
     `* Re: Command Languages Versus Programming LanguagesMuttley
      +* Re: Command Languages Versus Programming LanguagesJanis Papanagnou
      |+* Re: Command Languages Versus Programming LanguagesMuttley
      ||`* Re: Command Languages Versus Programming LanguagesJanis Papanagnou
      || +* Re: Command Languages Versus Programming LanguagesMuttley
      || |`* Re: Command Languages Versus Programming LanguagesRainer Weikusat
      || | +* Re: Command Languages Versus Programming LanguagesJohn Ames
      || | `* Re: Command Languages Versus Programming LanguagesMuttley
      || `* Re: Command Languages Versus Programming LanguagesRainer Weikusat
      |`* Re: Command Languages Versus Programming LanguagesKaz Kylheku
      +* Re: Command Languages Versus Programming LanguagesEd Morton
      `* Re: Command Languages Versus Programming LanguagesRainer Weikusat

Pages:1234567
Subject: Re: Command Languages Versus Programming Languages
From: Bozo User
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Mon, 30 Sep 2024 20:04 UTC
References: 1 2 3 4
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anthk@disroot.org (Bozo User)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Mon, 30 Sep 2024 20:04:54 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <vdf096$2c9hb$8@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 30 Sep 2024 22:04:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a34d6f5221beabc0a05e77e5b08e5f7d";
logging-data="2500139"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19tMyPhxllztVBg8KE7mLnO"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:drqVbEG4uFYkMnn3NCM273Bvmz4=
View all headers

On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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.

Perl is more awk+sed+sh in a single language. Basically the killer
of the Unix philophy in late 90's/early 00's, and for the good.

Subject: Re: Command Languages Versus Programming Languages
From: Lawrence D'Oliv
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Mon, 30 Sep 2024 21:04 UTC
References: 1 2 3 4 5
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: ldo@nz.invalid (Lawrence D'Oliveiro)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Mon, 30 Sep 2024 21:04:24 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 19
Message-ID: <vdf3oo$2cn51$3@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 30 Sep 2024 23:04:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a1a02b051aaecb67c07f3c0a04f3a680";
logging-data="2514081"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18f3/XXAhol1fIL1F12gcjc"
User-Agent: Pan/0.160 (Toresk; )
Cancel-Lock: sha1:s+wRpVIyZQ9Tlx3jYLpLpsvnrBo=
View all headers

On Mon, 30 Sep 2024 20:04:54 -0000 (UTC), Bozo User wrote:

> Perl is more awk+sed+sh in a single language. Basically the killer of
> the Unix philophy in late 90's/early 00's, and for the good.

That’s what Rob Pike said
<https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds>:

Q: “Given the nature of current operating systems and
applications, do you think the idea of "one tool doing one job
well" has been abandoned?”
A: “Those days are dead and gone and the eulogy was delivered by
Perl.”

But I’m not sure I agree. Those small, specialized tools always
required large, monolithic pieces under them to operate: the shell
itself for shell scripts, the X server for GUI apps, the kernel itself
for everything. So while the coming of Perl has changed some things,
it has not made a difference to the modularity of the Unix way.

Subject: Re: Command Languages Versus Programming Languages
From: usuario
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Tue, 1 Oct 2024 20:18 UTC
References: 1 2 3 4 5 6
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anthk@disroot.org (usuario)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Tue, 1 Oct 2024 20:18:28 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <vdhlek$2sc22$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<vdf3oo$2cn51$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 01 Oct 2024 22:18:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6a14c9de7a5757eec5a1ca641c874bd8";
logging-data="3027010"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19i7QbP/wbjt29J09KVoRJS"
User-Agent: Pan/0.149 (Bellevue; 4c157ba)
Cancel-Lock: sha1:C3wnUYlQdageSQVInzARAp2EqrE=
View all headers

El Mon, 30 Sep 2024 21:04:24 -0000 (UTC), Lawrence D'Oliveiro escribió:

> On Mon, 30 Sep 2024 20:04:54 -0000 (UTC), Bozo User wrote:
>
>> Perl is more awk+sed+sh in a single language. Basically the killer of
>> the Unix philophy in late 90's/early 00's, and for the good.
>
> That’s what Rob Pike said
> <https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-
responds>:
>
> Q: “Given the nature of current operating systems and applications,
> do you think the idea of "one tool doing one job well" has been
> abandoned?”
> A: “Those days are dead and gone and the eulogy was delivered by
> Perl.”
>
> But I’m not sure I agree. Those small, specialized tools always required
> large, monolithic pieces under them to operate: the shell itself for
> shell scripts, the X server for GUI apps, the kernel itself for
> everything. So while the coming of Perl has changed some things,
> it has not made a difference to the modularity of the Unix way.

The shell could be changed as just a command launcher with no
conditionals, while perl doing all the hard work.

On X11/X.org, X11 was never very "Unix like" by itself.

Subject: Re: Command Languages Versus Programming Languages
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Wed, 2 Oct 2024 07:10 UTC
References: 1 2 3 4 5 6 7
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Wed, 2 Oct 2024 07:10:32 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <vdirl8$357oi$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<vdf3oo$2cn51$3@dont-email.me>
<vdhlek$2sc22$1@dont-email.me>
Injection-Date: Wed, 02 Oct 2024 09:10:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="87d4e560371032418cbe4f0e3ab62265";
logging-data="3317522"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ckZitBN8Y5uSDkJdxOA0v"
Cancel-Lock: sha1:26UuZjWX4DmHBuGS7nJ3vv+Osc8=
View all headers

On Tue, 1 Oct 2024 20:18:28 -0000 (UTC)
usuario <anthk@disroot.org> boring babbled:
>El Mon, 30 Sep 2024 21:04:24 -0000 (UTC), Lawrence D'Oliveiro escribió:
>
>> On Mon, 30 Sep 2024 20:04:54 -0000 (UTC), Bozo User wrote:
>>
>>> Perl is more awk+sed+sh in a single language. Basically the killer of
>>> the Unix philophy in late 90's/early 00's, and for the good.
>>
>> That’s what Rob Pike said
>> <https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-
>responds>:
>>
>> Q: “Given the nature of current operating systems and applications,
>> do you think the idea of "one tool doing one job well" has been
>> abandoned?”
>> A: “Those days are dead and gone and the eulogy was delivered by
>> Perl.”
>>
>> But I’m not sure I agree. Those small, specialized tools always required
>> large, monolithic pieces under them to operate: the shell itself for
>> shell scripts, the X server for GUI apps, the kernel itself for
>> everything. So while the coming of Perl has changed some things,
>> it has not made a difference to the modularity of the Unix way.
>
>The shell could be changed as just a command launcher with no
>conditionals, while perl doing all the hard work.
>
>On X11/X.org, X11 was never very "Unix like" by itself.

An X server is about as minimal as you can have a graphics system
and still make it usable. I don't see how it could have been
subdivided any further and still work.

Subject: Re: Command Languages Versus Programming Languages
From: usuario
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Wed, 2 Oct 2024 12:52 UTC
References: 1 2 3 4 5 6 7 8
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anthk@disroot.org (usuario)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Wed, 2 Oct 2024 12:52:03 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <vdjflj$37jq5$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<vdf3oo$2cn51$3@dont-email.me> <vdhlek$2sc22$1@dont-email.me>
<vdirl8$357oi$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 02 Oct 2024 14:52:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="92bc2ed0868980638a16648ecf447f17";
logging-data="3395397"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18koELhEW3/pgRH/zE7939g"
User-Agent: Pan/0.149 (Bellevue; 4c157ba)
Cancel-Lock: sha1:plAzC14N0ukmDMfYvsjDp2ez0iM=
View all headers

El Wed, 2 Oct 2024 07:10:32 -0000 (UTC), Muttley escribió:

> On Tue, 1 Oct 2024 20:18:28 -0000 (UTC)
> usuario <anthk@disroot.org> boring babbled:
>>El Mon, 30 Sep 2024 21:04:24 -0000 (UTC), Lawrence D'Oliveiro escribió:
>>
>>> On Mon, 30 Sep 2024 20:04:54 -0000 (UTC), Bozo User wrote:
>>>
>>>> Perl is more awk+sed+sh in a single language. Basically the killer of
>>>> the Unix philophy in late 90's/early 00's, and for the good.
>>>
>>> That’s what Rob Pike said
>>> <https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-
>>responds>:
>>>
>>> Q: “Given the nature of current operating systems and
>>> applications,
>>> do you think the idea of "one tool doing one job well" has been
>>> abandoned?”
>>> A: “Those days are dead and gone and the eulogy was delivered by
>>> Perl.”
>>>
>>> But I’m not sure I agree. Those small, specialized tools always
>>> required large, monolithic pieces under them to operate: the shell
>>> itself for shell scripts, the X server for GUI apps, the kernel itself
>>> for everything. So while the coming of Perl has changed some things,
>>> it has not made a difference to the modularity of the Unix way.
>>
>>The shell could be changed as just a command launcher with no
>>conditionals, while perl doing all the hard work.
>>
>>On X11/X.org, X11 was never very "Unix like" by itself.
>
> An X server is about as minimal as you can have a graphics system and
> still make it usable. I don't see how it could have been subdivided any
> further and still work.

Check out Blit under Unix V10 and Rio under plan9/9front for a much better
Unix-oriented (9front/plan9 it's basically Unix philosophy 2.0) approach.

Subject: Re: Command Languages Versus Programming Languages
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Wed, 2 Oct 2024 16:00 UTC
References: 1 2 3 4 5 6 7 8 9
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Wed, 2 Oct 2024 16:00:55 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 14
Message-ID: <vdjqnn$39rh9$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<vdf3oo$2cn51$3@dont-email.me> <vdhlek$2sc22$1@dont-email.me>
<vdirl8$357oi$1@dont-email.me>
<vdjflj$37jq5$1@dont-email.me>
Injection-Date: Wed, 02 Oct 2024 18:00:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="87d4e560371032418cbe4f0e3ab62265";
logging-data="3468841"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19irXykphrxI3a8n9NfHzfN"
Cancel-Lock: sha1:Bki3o8YDT/rcl6rTShxA7v3/igw=
View all headers

On Wed, 2 Oct 2024 12:52:03 -0000 (UTC)
usuario <anthk@disroot.org> boring babbled:
>El Wed, 2 Oct 2024 07:10:32 -0000 (UTC), Muttley escribió:
>> An X server is about as minimal as you can have a graphics system and
>> still make it usable. I don't see how it could have been subdivided any
>> further and still work.
>
>Check out Blit under Unix V10 and Rio under plan9/9front for a much better
>Unix-oriented (9front/plan9 it's basically Unix philosophy 2.0) approach.

Don't have the time. Presumably its a raw frame buffer or similar? If so
I can't see it being popular. The unix philosphy or breaking workflows up
into small subsections has it place, but I don't think graphics is that place.

Subject: Re: Command Languages Versus Programming Languages
From: Rainer Weikusat
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Date: Wed, 9 Oct 2024 21:25 UTC
References: 1 2 3 4 5
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rweikusat@talktalk.net (Rainer Weikusat)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Wed, 09 Oct 2024 22:25:05 +0100
Lines: 30
Message-ID: <87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net LxSVPTA9WyQdAFWtZPBKAAvtd0Nt93AZ/2AgmhJZNh/Z2B3ds=
Cancel-Lock: sha1:wC0gcORh9V2J42qfZCu5VOcKNaY= sha1:Qxxw/P+BjJuxHJTy2nLZvHMOhI0= sha256:zgEO0JmwUA9FiRIqtneHvWNCY8Odg+8hJDI02GUvJd8=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
View all headers

Bozo User <anthk@disroot.org> writes:
> On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> 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.
>
> Perl is more awk+sed+sh in a single language. Basically the killer
> of the Unix philophy in late 90's/early 00's, and for the good.

Perl is a high-level programming language with a rich syntax¹, with
support for deterministic automatic memory management, functions as
first-class objects and message-based OO. It's also a virtual machine
for executing threaded code and a(n optimizing) compiler for translating
Perl code into the corresponding threaded code.

¹ Has recently gained try/catch for exception handling which is IMNSHO a
great improvement over eval + $@.

Subject: Re: Command Languages Versus Programming Languages
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Thu, 10 Oct 2024 08:38 UTC
References: 1 2 3 4 5 6
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Thu, 10 Oct 2024 08:38:26 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <ve83q2$33dfe$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
Injection-Date: Thu, 10 Oct 2024 10:38:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d65fb65922ea715358b074c85545da6a";
logging-data="3257838"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19P1FJrlB1HvTQQb4kxyv/1"
Cancel-Lock: sha1:F61o++hDHMgCv4tzJeorXIRB8wQ=
View all headers

On Wed, 09 Oct 2024 22:25:05 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>Bozo User <anthk@disroot.org> writes:
>> On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> 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.
>>
>> Perl is more awk+sed+sh in a single language. Basically the killer
>> of the Unix philophy in late 90's/early 00's, and for the good.
>
>Perl is a high-level programming language with a rich syntax¹, with
>support for deterministic automatic memory management, functions as
>first-class objects and message-based OO. It's also a virtual machine
>for executing threaded code and a(n optimizing) compiler for translating
>Perl code into the corresponding threaded code.

Its syntax is also a horrific mess. Larry took the worst parts of C and shell
syntax and mashed them together. Its no surprise Perl has been ditched in
favour of Python just about everywhere for new scripting projects. And while
I hate Pythons meangingful whitespace nonsense, I'd use it in preference
to Perl any day.

Subject: Re: Command Languages Versus Programming Languages
From: Rainer Weikusat
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Date: Thu, 10 Oct 2024 15:09 UTC
References: 1 2 3 4 5 6 7
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rweikusat@talktalk.net (Rainer Weikusat)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Thu, 10 Oct 2024 16:09:49 +0100
Lines: 46
Message-ID: <87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net bewH1x+rEknOidLHrAkF7QFVWSJfGLIi2DqUpP/z/UwO2QCA0=
Cancel-Lock: sha1:1Hwtjvc5war882w63Yy2rN6UtPw= sha1:ERekyLlVgj/hg2WvfLv0wP1/8FE= sha256:QyL8+IrisDy72ovyQj9xbj8mhqEdm80QtD11lIDCwW4=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
View all headers

Muttley@DastartdlyHQ.org writes:
> On Wed, 09 Oct 2024 22:25:05 +0100
> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>Bozo User <anthk@disroot.org> writes:
>>> On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> 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.
>>>
>>> Perl is more awk+sed+sh in a single language. Basically the killer
>>> of the Unix philophy in late 90's/early 00's, and for the good.
>>
>>Perl is a high-level programming language with a rich syntax¹, with
>>support for deterministic automatic memory management, functions as
>>first-class objects and message-based OO. It's also a virtual machine
>>for executing threaded code and a(n optimizing) compiler for translating
>>Perl code into the corresponding threaded code.
>
> Its syntax is also a horrific mess.

Which means precisely what?

> Its no surprise Perl has been ditched in favour of Python just about
> everywhere for new scripting projects.

"I say so and I'm an avid Phython fan?"

Not much of a reason.

BTW, I didn't mean to start another entirely pointless language
war. Just pointing out the referring to a general-purpose programming
language as "killer of the UNIX philosophy" makes no sense.

Subject: Re: Command Languages Versus Programming Languages
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Thu, 10 Oct 2024 15:34 UTC
References: 1 2 3 4 5 6 7 8
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Thu, 10 Oct 2024 15:34:37 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 21
Message-ID: <ve8s6d$3725r$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
Injection-Date: Thu, 10 Oct 2024 17:34:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d65fb65922ea715358b074c85545da6a";
logging-data="3377339"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zOdfHBMKnmRMhhicTTTCb"
Cancel-Lock: sha1:TUw3ecLfaJrTjQoKkkjhS0yb4MA=
View all headers

On Thu, 10 Oct 2024 16:09:49 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>Muttley@DastartdlyHQ.org writes:
>> Its syntax is also a horrific mess.
>
>Which means precisely what?

Far too much pointless punctuation. An interpreter shouldn't need the vartype
signified by $ or @ once its defined, it should already know. And then there
are semantically meaningful underscores (seriously?) and random hacky keywords
such as <STDIN>. I could go on.

>> Its no surprise Perl has been ditched in favour of Python just about
>> everywhere for new scripting projects.
>
>"I say so and I'm an avid Phython fan?"
>
>Not much of a reason.

It shows the general consensus of which is an easier language to work with.

Subject: Re: Command Languages Versus Programming Languages
From: Rainer Weikusat
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Date: Thu, 10 Oct 2024 16:55 UTC
References: 1 2 3 4 5 6 7 8 9
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rweikusat@talktalk.net (Rainer Weikusat)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Thu, 10 Oct 2024 17:55:32 +0100
Lines: 73
Message-ID: <87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net kPkG+M8jTWvFhtlyR2Oyog7P+ZQ8LCIhOhJH2kA0NQx5lapTY=
Cancel-Lock: sha1:Qwl05E45mJZRMsRplIbsffdA8qo= sha1:pjD41EsyLt8VfHDIxtsPK/JVQx8= sha256:mddXLdLxyMsbpuR7KaMvdGpsKRFudO8Vl0ugDRqnfk0=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
View all headers

Muttley@DastartdlyHQ.org ignorantly rambled:
> On Thu, 10 Oct 2024 16:09:49 +0100
> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>Muttley@DastartdlyHQ.org writes:
>>> Its syntax is also a horrific mess.
>>
>>Which means precisely what?
>
> Far too much pointless punctuation. An interpreter shouldn't need the vartype
> signified by $ or @ once its defined, it should already know.

For the purpose of variable declaration, how's the interpeter going to
know the type of a variable without being told about it? Obviously, not
at all.

Perl has three builtin types, scalars, arrays and hashes and
each is denoted by a single-letter prefix which effectively creates
three different variable namespaces, one for each type. That's often
convenient, because the same name can be reused for a variable of a
different type, eg:

my ($data, @data, %data);

$data = rand(128);
@data = ($data, $data + 1);
%data = map { $_, 15 } @data;

it's also convenient to type and easy to read due to being concise.

Outside of declarations, $ and @ really denote access modes/ contexts,
with $ standing for "a thing" and @ for "a number of things", eg

$a[0]

is the first element of the array @a and

@a[-3 .. -1]

is a list composed of the three last elements of @a.

> And then there are semantically meaningful underscores (seriously?)

Similar to the number writing convention in English: 1,600,700, numbers
in Perl can be annotated with _-separators to make them easier to
read. Eg, all of these are identical

1_600_700
16_007_00
1_6_0_0_7_0_0_

But the underscores have no meaning in here.

> and random hacky keywords such as <STDIN>.

<STDIN> isn't a keyword. STDIN is the name of a glob (symbol table
entry) in the symbol table of the package main. It's most prominent use
is (as they name may suggest) to provide access to "the standard input
stream".

<> is an I/O operator. It's operand must be a file handle, ie, either
the name of glob with a file handle associated with it like STDIN or a
scalar variable used to hold a file handle. In scalar context, it reads
and returns the next line read from this file handle. In list context,
it returns all lines in the file.

Eg, this a poor man's implementation of cat:

perl -e 'open($fh, $_) and print <$fh> for @ARGV'

> I could go on.

Please don't enumerate everything else on this planet you also don't
really understand as that's probably going to become a huge list. ;-)

Subject: Re: Command Languages Versus Programming Languages
From: Kaz Kylheku
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Thu, 10 Oct 2024 19:14 UTC
References: 1 2 3 4 5 6 7 8 9 10
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: 643-408-1753@kylheku.com (Kaz Kylheku)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Thu, 10 Oct 2024 19:14:15 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <20241010120827.867@kylheku.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
Injection-Date: Thu, 10 Oct 2024 21:14:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fd525c31a89e53d177e6d80cbe5a279b";
logging-data="3447717"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Q4BDCQuBJT2M4RLr6hysEeJC068YmV7o="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:Ue20SFBWPFq3eiKaRMMb4MudOu8=
View all headers

On 2024-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Muttley@DastartdlyHQ.org ignorantly rambled:
>> On Thu, 10 Oct 2024 16:09:49 +0100
>> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>Muttley@DastartdlyHQ.org writes:
>>>> Its syntax is also a horrific mess.
>>>
>>>Which means precisely what?
>>
>> Far too much pointless punctuation. An interpreter shouldn't need the vartype
>> signified by $ or @ once its defined, it should already know.
>
> For the purpose of variable declaration, how's the interpeter going to

Interpreter? Perl has some kind of compiler in it, right?

Interpreters for typed languages are possible. The lexical environment
bidnings contain type info, so when the interpreter sees x, it resolves
it through the environment not only to a location/value, but to type
info.

> know the type of a variable without being told about it? Obviously, not
> at all.

But it's not exactly type, because $x means "scalar variable of any
type" whereas @x is an "array of any type".

That's quite useless for proper type checking and only causes noise,
due to having to be repeated.

Actually typed languages don't use sigils. How is that?

The type of a name is declared (or else inferred); references to that
name don't need to repeat that info.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Subject: Re: Command Languages Versus Programming Languages
From: Rainer Weikusat
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Date: Thu, 10 Oct 2024 20:31 UTC
References: 1 2 3 4 5 6 7 8 9 10 11
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rweikusat@talktalk.net (Rainer Weikusat)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Thu, 10 Oct 2024 21:31:39 +0100
Lines: 112
Message-ID: <87frp3itsk.fsf@doppelsaurus.mobileactivedefense.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
<20241010120827.867@kylheku.com>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: individual.net Htlca5IOn5jNglhcIrINaghx8dcC4IJZNjow8Kw+0a5tOiTPo=
Cancel-Lock: sha1:6focjzhmDXvWGKKONRCpyOIddJQ= sha1:UZAVkInEhjLkagHu4snh0A22xv4= sha256:4W3g5RyvQu3EhPnz2OP6m3QVqyArcYM0VL1THX65lHE=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
View all headers

Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2024-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Muttley@DastartdlyHQ.org ignorantly rambled:
>>> On Thu, 10 Oct 2024 16:09:49 +0100
>>> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>>Muttley@DastartdlyHQ.org writes:
>>>>> Its syntax is also a horrific mess.
>>>>
>>>>Which means precisely what?
>>>
>>> Far too much pointless punctuation. An interpreter shouldn't need the vartype
>>> signified by $ or @ once its defined, it should already know.
>>
>> For the purpose of variable declaration, how's the interpeter going to
>
> Interpreter? Perl has some kind of compiler in it, right?

The Perl compiler turns Perl source code into a set of (that's a
conjecture of mine) so-called "op trees" whose nodes contain pointers to
built-in functions and pointers to "op subtrees" supplying arguments for
these and the interpeter/ virtual machine then evaluates these op trees
to run the program.

[...]

>> know the type of a variable without being told about it? Obviously, not
>> at all.
>
> But it's not exactly type, because $x means "scalar variable of any
> type" whereas @x is an "array of any type".

$x means 'scalar variable'. There's no furher differentiation of that at
the language level despite there are two kinds of scalar variables at
the implentation level, scalars whose values are "values" of some sort
(ie, strings or numbers) and scalars whose values are references to
something.

@x is an 1-D array of scalars.

> That's quite useless for proper type checking and only causes noise,
> due to having to be repeated.
>
> Actually typed languages don't use sigils. How is that?
>
> The type of a name is declared (or else inferred); references to that
> name don't need to repeat that info.

The Perl type system is based on using different namespaces for
different types which means the type of a variable is part of its
name. This has the advantages that declaration syntax is concise and
that it's possible to have different kinds of variables with the same
name. It's also not really specific to Perl as C uses a similar model
for structures declarations and definitions.

The obvious disadvantage is that every variable name in Perl and every
use of a variable in an expression has and additional meta-information
character associated with it. The actual rules outside of declarations
are also more complicated because of the underlying idea that $ would be
something like a singular article in a spoken language an @ a plural
article. This means that elements of arrays and hashed are referred to
using a $ prefix and not @ or %, eg,

my @a;
$a[0] = 1;

or

my %h;
$h{goatonion} = 'winged cauliflower';

I think that's rather a weird than a great idea but it's internally
consistent and as good (or bad) as any other language ideosyncrasy. It's
certainly less confusing than the : as expression separator in
supposedly punctuation-free Python which tripped me up numerous times
when initially starting to write (some) Python code.

Things only start to get slightly awful when references become
involved. In Perl 4 (reportedly, I've never used that) a reference was a
variable holding the name of another variable, eg

$b = 1;
$a = 'b';
print $$a; # prints 1

Perl 5 added references as typed pointers with reference counting but
retained the symbolic referenc syntax. For the example above, that would
be

$b = 1;
$a = \$b;
print $$a; # also prints 1

Thinks start to become complicated once references to complex objects
are involved. Eg,

@{$$a[0]}

is the array referred to by the first item of the array $a refers to and

${$$a[0]}[0]

which seriously starts to look like a trench fortification with
barbed-wire obstacles is a way to refer to the first element of this
array. The {$$a[0]} is a block returning a reference to an array which
the surrounding $ and [0] then dereference. The { } could contain
arbitrary code returning a reference. But for the simple case of
dereference-chaining, this is not needed as it's implied for adjacent
subscript (for both hashes and arrays) which means the simpler

$$a[0][0]

is equivalent to the other expression.

Subject: Re: Command Languages Versus Programming Languages
From: Bart
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Thu, 10 Oct 2024 23:07 UTC
References: 1 2 3 4 5 6 7 8 9 10
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 00:07:02 +0100
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <ve9mml$3aiao$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 11 Oct 2024 01:07:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e855f7326897fc9dc7def665be4b215a";
logging-data="3492184"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX193HutsHDb2Tv+vW5SeLWTQ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:k0ETDaU3PZsKlkT8lgDaLgtxh0E=
In-Reply-To: <87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
Content-Language: en-GB
View all headers

On 10/10/2024 17:55, Rainer Weikusat wrote:
> Muttley@DastartdlyHQ.org ignorantly rambled:
>> On Thu, 10 Oct 2024 16:09:49 +0100
>> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>> Muttley@DastartdlyHQ.org writes:
>>>> Its syntax is also a horrific mess.
>>>
>>> Which means precisely what?
>>
>> Far too much pointless punctuation. An interpreter shouldn't need the vartype
>> signified by $ or @ once its defined, it should already know.
>
> For the purpose of variable declaration, how's the interpeter going to
> know the type of a variable without being told about it? Obviously, not
> at all.
>
> Perl has three builtin types, scalars, arrays and hashes and
> each is denoted by a single-letter prefix which effectively creates
> three different variable namespaces, one for each type. That's often
> convenient, because the same name can be reused for a variable of a
> different type, eg:
>
> my ($data, @data, %data);

Why would you want to do this?

> $data = rand(128);
> @data = ($data, $data + 1);
> %data = map { $_, 15 } @data;
>
> it's also convenient to type and easy to read due to being concise.

Adding shifted punctuation at the start of every instance of a variable?
I don't call that convenient!

So, $ is scalar, @ is an array, and % is a hash?

> Outside of declarations, $ and @ really denote access modes/ contexts,
> with $ standing for "a thing" and @ for "a number of things", eg
>
> $a[0]

> is the first element of the array @a and

Now I'm already lost. 'a' is an array, but it's being used with $? What
would just this:

a[0]

mean by itself?

> @a[-3 .. -1]
>
> is a list composed of the three last elements of @a.

Sorry, these prefixes look utterly pointless to me. This stuff works
perfectly well in other languages without them.

I can write a[i..j] in mine and I know that it yields a slice.

What would a[-3 .. -1] give you in Perl without the @? What would $a[-3
... -1] mean?

What happens if you have an array of mixed scalars, arrays and hashes;
what prefix to use in front of a[i]?

Subject: Re: Command Languages Versus Programming Languages
From: Bart
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Thu, 10 Oct 2024 23:09 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 00:09:39 +0100
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <ve9mrh$3aiao$2@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
<20241010120827.867@kylheku.com>
<87frp3itsk.fsf@doppelsaurus.mobileactivedefense.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 11 Oct 2024 01:09:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e855f7326897fc9dc7def665be4b215a";
logging-data="3492184"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MJ+S/6bR96e3tMvc/0Gpu"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:lGjq9h1UiR+w0caS816/GFRy7aI=
In-Reply-To: <87frp3itsk.fsf@doppelsaurus.mobileactivedefense.com>
Content-Language: en-GB
View all headers

On 10/10/2024 21:31, Rainer Weikusat wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:

> Thinks start to become complicated once references to complex objects
> are involved. Eg,
>
> @{$$a[0]}
>
> is the array referred to by the first item of the array $a refers to and
>
> ${$$a[0]}[0]
>
> which seriously starts to look like a trench fortification with
> barbed-wire obstacles is a way to refer to the first element of this
> array.

I thought you were defending the language. Now you seem to be agreeing
with how bad this syntax is.

Subject: Re: Command Languages Versus Programming Languages
From: Lawrence D'Oliv
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Fri, 11 Oct 2024 01:33 UTC
References: 1 2 3 4 5 6 7 8 9
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: ldo@nz.invalid (Lawrence D'Oliveiro)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 01:33:21 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 7
Message-ID: <ve9v91$3cbkr$3@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 11 Oct 2024 03:33:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0b5f06eee4a1d884280520d20084135c";
logging-data="3550875"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/MP+v7J5tuPWNMY4f5NFgx"
User-Agent: Pan/0.160 (Toresk; )
Cancel-Lock: sha1:R1Z6OCOS9f6R0HS8CGVzEIkC3lE=
View all headers

On Thu, 10 Oct 2024 15:34:37 -0000 (UTC), Muttley wrote:

> An interpreter shouldn't need the vartype signified by $ or @ once its
> defined, it should already know.

You realize those symbols represent, not just different types, but
different namespaces as well?

Subject: Re: Command Languages Versus Programming Languages
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Fri, 11 Oct 2024 08:17 UTC
References: 1 2 3 4 5 6 7 8 9 10
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 08:17:22 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <veamui$3jen7$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
Injection-Date: Fri, 11 Oct 2024 10:17:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0c90553b44865ecc4db3531d281fdd3e";
logging-data="3783399"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX181hcWRgznKT+IX8x/HYzl/"
Cancel-Lock: sha1:eS92cKqjBlK3KZt/dZK/zjNdglA=
View all headers

On Thu, 10 Oct 2024 17:55:32 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>Muttley@DastartdlyHQ.org ignorantly rambled:
>> On Thu, 10 Oct 2024 16:09:49 +0100
>> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>Muttley@DastartdlyHQ.org writes:
>>>> Its syntax is also a horrific mess.
>>>
>>>Which means precisely what?
>>
>> Far too much pointless punctuation. An interpreter shouldn't need the vartype
>
>> signified by $ or @ once its defined, it should already know.
>
>For the purpose of variable declaration, how's the interpeter going to

Which part of "once its defined" did you not understand?

>convenient, because the same name can be reused for a variable of a
>different type, eg:
>
>my ($data, @data, %data);
>
>$data = rand(128);
>@data = ($data, $data + 1);
>%data = map { $_, 15 } @data;

What a mess. And I didn't realise perl allowed variables of different types
to have the same name! Insanity! Another reason never to use it again.

>it's also convenient to type and easy to read due to being concise.

If you say so. Others may disagree.

>and returns the next line read from this file handle. In list context,
>it returns all lines in the file.
>
>Eg, this a poor man's implementation of cat:
>
>perl -e 'open($fh, $_) and print <$fh> for @ARGV'

Meanwhile in awk: { print }

>Please don't enumerate everything else on this planet you also don't
>really understand as that's probably going to become a huge list. ;-)

I understand Perl vies with C++ as the most syntactically messy language
in common use. Unfortunately I have to use the latter, I don't have to use
the former.

Subject: Re: Command Languages Versus Programming Languages
From: Rainer Weikusat
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Date: Fri, 11 Oct 2024 14:47 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rweikusat@talktalk.net (Rainer Weikusat)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 15:47:06 +0100
Lines: 113
Message-ID: <87jzee3ded.fsf@doppelsaurus.mobileactivedefense.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
<20241010120827.867@kylheku.com>
<87frp3itsk.fsf@doppelsaurus.mobileactivedefense.com>
<ve9mrh$3aiao$2@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: individual.net ApZW+zvyfGH9HvzuTlOnoQbjnzLOWMZvOI7DjOdQgfoJ1aGPk=
Cancel-Lock: sha1:aG3K37F8O4aLoPFHb4PAecZM8M4= sha1:wIV0Rwkdh6Ho4dWrXyauAcOR/UY= sha256:XhbpcOMlDAiv4HFuZYoeT426YhdNO2ponGRXFUWI2mA=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
View all headers

Bart <bc@freeuk.com> writes:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2024-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Muttley@DastartdlyHQ.org ignorantly rambled:
>>> On Thu, 10 Oct 2024 16:09:49 +0100
>>> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>>Muttley@DastartdlyHQ.org writes:
>>>>> Its syntax is also a horrific mess.
>>>>
>>>>Which means precisely what?
>>>
>>> Far too much pointless punctuation. An interpreter shouldn't need the vartype
>>> signified by $ or @ once its defined, it should already know.
>>
>> For the purpose of variable declaration, how's the interpeter going to
>
> Interpreter? Perl has some kind of compiler in it, right?

The Perl compiler turns Perl source code into a set of (that's a
conjecture of mine) so-called "op trees" whose nodes contain pointers to
built-in functions and pointers to "op subtrees" supplying arguments for
these and the interpeter/ virtual machine then evaluates these op trees
to run the program.

[...]

>> know the type of a variable without being told about it? Obviously, not
>> at all.
>
> But it's not exactly type, because $x means "scalar variable of any
> type" whereas @x is an "array of any type".

$x means 'scalar variable'. There's no furher differentiation of that at
the language level despite there are two kinds of scalar variables at
the implentation level, scalars whose values are "values" of some sort
(ie, strings or numbers) and scalars whose values are references to
something.

@x is an 1-D array of scalars.

> That's quite useless for proper type checking and only causes noise,
> due to having to be repeated.
>
> Actually typed languages don't use sigils. How is that?
>
> The type of a name is declared (or else inferred); references to that
> name don't need to repeat that info.

The Perl type system is based on using different namespaces for
different types which means the type of a variable is part of its
name. This has the advantages that declaration syntax is concise and
that it's possible to have different kinds of variables with the same
name. It's also not really specific to Perl as C uses a similar model
for structures declarations and definitions.

The obvious disadvantage is that every variable name in Perl and every
use of a variable in an expression has and additional meta-information
character associated with it. The actual rules outside of declarations
are also more complicated because of the underlying idea that $ would be
something like a singular article in a spoken language an @ a plural
article. This means that elements of arrays and hashed are referred to
using a $ prefix and not @ or %, eg,

my @a;
$a[0] = 1;

or

my %h;
$h{goatonion} = 'winged cauliflower';

I think that's rather a weird than a great idea but it's internally
consistent and as good (or bad) as any other language ideosyncrasy. It's
certainly less confusing than the : as expression separator in
supposedly punctuation-free Python which tripped me up numerous times
when initially starting to write (some) Python code.

Things only start to get slightly awful when references become
involved. In Perl 4 (reportedly, I've never used that) a reference was a
variable holding the name of another variable, eg

$b = 1;
$a = 'b';
print $$a; # prints 1

Perl 5 added references as typed pointers with reference counting but
retained the symbolic referenc syntax. For the example above, that would
be

$b = 1;
$a = \$b;
print $$a; # also prints 1

Thinks start to become complicated once references to complex objects
are involved. Eg,

@{$$a[0]}

is the array referred to by the first item of the array $a refers to and

${$$a[0]}[0]

which seriously starts to look like a trench fortification with
barbed-wire obstacles is a way to refer to the first element of this
array. The {$$a[0]} is a block returning a reference to an array which
the surrounding $ and [0] then dereference. The { } could contain
arbitrary code returning a reference. But for the simple case of
dereference-chaining, this is not needed as it's implied for adjacent
subscript (for both hashes and arrays) which means the simpler

$$a[0][0]

is equivalent to the other expression.

Subject: Re: Command Languages Versus Programming Languages
From: Rainer Weikusat
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Date: Fri, 11 Oct 2024 15:15 UTC
References: 1 2 3 4 5 6 7 8 9 10 11
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rweikusat@talktalk.net (Rainer Weikusat)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 16:15:14 +0100
Lines: 98
Message-ID: <87frp23c3h.fsf@doppelsaurus.mobileactivedefense.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
<ve9mml$3aiao$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: individual.net LYedjN1Ajfsmr0P+G4bJzQ1fN/MLHcnnjhO46Hn3k3TbHGCbo=
Cancel-Lock: sha1:aq+VHmmntaC4EYsVjN8/kyMxmCs= sha1:HNJLHcwRvMgkqCW6xK301oXIY7A= sha256:95rzEH3RtmiMS5FLQiLApoclCK1wRh0UWdv9BwPcBCE=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
View all headers

Bart <bc@freeuk.com> writes:
> On 10/10/2024 17:55, Rainer Weikusat wrote:
>> Muttley@DastartdlyHQ.org ignorantly rambled:
>>> On Thu, 10 Oct 2024 16:09:49 +0100
>>> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>> Muttley@DastartdlyHQ.org writes:
>>>>> Its syntax is also a horrific mess.
>>>>
>>>> Which means precisely what?
>>>
>>> Far too much pointless punctuation. An interpreter shouldn't need the vartype
>>> signified by $ or @ once its defined, it should already know.
>> For the purpose of variable declaration, how's the interpeter going
>> to
>> know the type of a variable without being told about it? Obviously, not
>> at all.
>> Perl has three builtin types, scalars, arrays and hashes and
>> each is denoted by a single-letter prefix which effectively creates
>> three different variable namespaces, one for each type. That's often
>> convenient, because the same name can be reused for a variable of a
>> different type, eg:
>> my ($data, @data, %data);
>
> Why would you want to do this?

Because it's convenient. It's possible to have a single variable
denotning something, say $car, and also a variable use to hold a list of
cars which could be named @car.

>> $data = rand(128);
>> @data = ($data, $data + 1);
>> %data = map { $_, 15 } @data;
>> it's also convenient to type and easy to read due to being concise.
>
> Adding shifted punctuation at the start of every instance of a
> variable? I don't call that convenient!

It's convenient for declarations, because it's the shortest possible
syntax which can be used to declare the type of a variable.

> So, $ is scalar, @ is an array, and % is a hash?

Yes.

>> Outside of declarations, $ and @ really denote access modes/ contexts,
>> with $ standing for "a thing" and @ for "a number of things", eg
>> $a[0]
>
>> is the first element of the array @a and
>
> Now I'm already lost. 'a' is an array, but it's being used with $?
> What would just this:
>
> a[0]
>
> mean by itself?

Nothing, ie, it's a syntax error.

>> @a[-3 .. -1]
>> is a list composed of the three last elements of @a.
>
> Sorry, these prefixes look utterly pointless to me. This stuff works
> perfectly well in other languages without them.
>
> I can write a[i..j] in mine and I know that it yields a slice.

But presumably only if a is actually an array. In Perl, it's a so-called
bareword which was historically just a string. In current Perl, it's
either a filehandle (which can't be indexed) or calling a function named
a (which also can't be indexed).

[...]

> What would $a[-3 .. -1] mean?

$a[0]

In list context (denoted by @) the .. operator returns a sequence of
numbers starting from the value on the left and ending with the value on
the right. But because of the $, it's in scalar context. Then, it
returns a boolean value which is false until the left operand becomes
true, then remains true until the right operand becomes true and then
again becomes false. That's supposed to be used for matching ranges of
something. If an operand is a constant expression, it's supposed to
refer to a line number of the last file which was accessed. Eg,

perl -ne 'print if 10 .. 15' </var/log/syslog

prints lines 10 - 15 from standard input (connected to /var/log/syslog).

For the given example, the value is always false (arithmetically equal
to 0) because -3 cannot occur as line number of a file.

> What happens if you have an array of mixed scalars, arrays and hashes;
> what prefix to use in front of a[i]?

Elements of arrays or hashes are always scalars.

Subject: Re: Command Languages Versus Programming Languages
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Fri, 11 Oct 2024 15:15 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 15:15:57 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 11
Message-ID: <vebffc$3n6jv$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
<20241010120827.867@kylheku.com>
<87frp3itsk.fsf@doppelsaurus.mobileactivedefense.com>
<ve9mrh$3aiao$2@dont-email.me>
<87jzee3ded.fsf@doppelsaurus.mobileactivedefense.com>
Injection-Date: Fri, 11 Oct 2024 17:15:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0c90553b44865ecc4db3531d281fdd3e";
logging-data="3906175"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18jQLlu/mrgcGIisXWewxr1"
Cancel-Lock: sha1:Kec1UcvRF0UyaaiUvXce5Fax8oI=
View all headers

On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>Bart <bc@freeuk.com> writes:
>> Interpreter? Perl has some kind of compiler in it, right?
>
>The Perl compiler turns Perl source code into a set of (that's a

Does it produce a standalone binary as output? No, so its an intepreter
not a compiler. However unlike the python interpreter its non interactive
making it an even less attractive option these days.

Subject: Re: Command Languages Versus Programming Languages
From: Dan Cross
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: PANIX Public Access Internet and UNIX, NYC
Date: Fri, 11 Oct 2024 15:45 UTC
References: 1 2 3 4
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!border-1.nntp.ord.giganews.com!border-3.nntp.ord.giganews.com!nntp.giganews.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 15:45:01 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vebh5t$mnh$1@reader1.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <ve9mrh$3aiao$2@dont-email.me> <87jzee3ded.fsf@doppelsaurus.mobileactivedefense.com> <vebffc$3n6jv$1@dont-email.me>
Injection-Date: Fri, 11 Oct 2024 15:45:01 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
logging-data="23281"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Lines: 22
View all headers

In article <vebffc$3n6jv$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>On Fri, 11 Oct 2024 15:47:06 +0100
>Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>Bart <bc@freeuk.com> writes:
>>> Interpreter? Perl has some kind of compiler in it, right?
>>
>>The Perl compiler turns Perl source code into a set of (that's a
>
>Does it produce a standalone binary as output? No, so its an intepreter
>not a compiler. However unlike the python interpreter its non interactive
>making it an even less attractive option these days.

That's a bad distinction. There have been "Load and Go"
compilers in the past that have compiled and linked a program
directly into memory and executed it immediately after
compilation. As I recall, the Waterloo FORTRAN compilers on the
IBM mainframe did, or could do, more or less this.

Saving to some sort of object image is not a necessary function
of a compiler.

- Dan C.

Subject: Re: Command Languages Versus Programming Languages
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: A noiseless patient Spider
Date: Fri, 11 Oct 2024 15:59 UTC
References: 1 2 3 4 5
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastartdlyHQ.org
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 15:59:15 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <vebi0j$3nhvq$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <ve9mrh$3aiao$2@dont-email.me> <87jzee3ded.fsf@doppelsaurus.mobileactivedefense.com> <vebffc$3n6jv$1@dont-email.me> <vebh5t$mnh$1@reader1.panix.com>
Injection-Date: Fri, 11 Oct 2024 17:59:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0c90553b44865ecc4db3531d281fdd3e";
logging-data="3917818"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/QcFUIrbhx3WBH28goIXDZ"
Cancel-Lock: sha1:tyE1PTNDuqpHRpCfYQPJop0KKVU=
View all headers

On Fri, 11 Oct 2024 15:45:01 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>In article <vebffc$3n6jv$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>On Fri, 11 Oct 2024 15:47:06 +0100
>>Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>Bart <bc@freeuk.com> writes:
>>>> Interpreter? Perl has some kind of compiler in it, right?
>>>
>>>The Perl compiler turns Perl source code into a set of (that's a
>>
>>Does it produce a standalone binary as output? No, so its an intepreter
>>not a compiler. However unlike the python interpreter its non interactive
>>making it an even less attractive option these days.
>
>That's a bad distinction. There have been "Load and Go"
>compilers in the past that have compiled and linked a program
>directly into memory and executed it immediately after
>compilation. As I recall, the Waterloo FORTRAN compilers on the
>IBM mainframe did, or could do, more or less this.

Irrelevant. Lot of interpreters do partial compilation and the JVM does it
on the fly. A proper compiler writes a standalone binary file to disk.

>Saving to some sort of object image is not a necessary function
>of a compiler.

Yes it is.

Subject: Re: Command Languages Versus Programming Languages
From: Dan Cross
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: PANIX Public Access Internet and UNIX, NYC
Date: Fri, 11 Oct 2024 16:28 UTC
References: 1 2 3 4
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 16:28:03 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vebjmj$5dc$1@reader1.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <vebffc$3n6jv$1@dont-email.me> <vebh5t$mnh$1@reader1.panix.com> <vebi0j$3nhvq$1@dont-email.me>
Injection-Date: Fri, 11 Oct 2024 16:28:03 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
logging-data="5548"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
View all headers

In article <vebi0j$3nhvq$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>On Fri, 11 Oct 2024 15:45:01 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <vebffc$3n6jv$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>>On Fri, 11 Oct 2024 15:47:06 +0100
>>>Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>>Bart <bc@freeuk.com> writes:
>>>>> Interpreter? Perl has some kind of compiler in it, right?
>>>>
>>>>The Perl compiler turns Perl source code into a set of (that's a
>>>
>>>Does it produce a standalone binary as output? No, so its an intepreter
>>>not a compiler. However unlike the python interpreter its non interactive
>>>making it an even less attractive option these days.
>>
>>That's a bad distinction. There have been "Load and Go"
>>compilers in the past that have compiled and linked a program
>>directly into memory and executed it immediately after
>>compilation. As I recall, the Waterloo FORTRAN compilers on the
>>IBM mainframe did, or could do, more or less this.
>
>Irrelevant. Lot of interpreters do partial compilation and the JVM does it
>on the fly. A proper compiler writes a standalone binary file to disk.

Not generally, no. Most compilers these days generate object
code and then, as a separate step, a linker is invoked to
combine object files and library archives into an executable
binary.

By the way, when many people talk about a "standalone" binary,
they are referring to something directly executable on hardware,
without the benefit of an operating system. The Unix kernel is
an example of such a "standalone binary."

Most executable binaries are not standalone.

>>Saving to some sort of object image is not a necessary function
>>of a compiler.
>
>Yes it is.

So you say, but that's not the commonly accepted definition.
Sorry.

- Dan C.

Subject: Re: Command Languages Versus Programming Languages
From: Scott Lurndal
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Organization: UsenetServer - www.usenetserver.com
Date: Fri, 11 Oct 2024 16:37 UTC
References: 1 2 3 4 5
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!news.mb-net.net!open-news-network.org!news.mind.de!bolzen.all.de!npeer.as286.net!npeer-ng0.as286.net!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: scott@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Command Languages Versus Programming Languages
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
References: <uu54la$3su5b$6@dont-email.me> <ve9mrh$3aiao$2@dont-email.me> <87jzee3ded.fsf@doppelsaurus.mobileactivedefense.com> <vebffc$3n6jv$1@dont-email.me> <vebh5t$mnh$1@reader1.panix.com>
Lines: 35
Message-ID: <OucOO.216223$EEm7.114855@fx16.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Fri, 11 Oct 2024 16:37:02 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Fri, 11 Oct 2024 16:37:02 GMT
X-Received-Bytes: 2227
View all headers

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <vebffc$3n6jv$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>On Fri, 11 Oct 2024 15:47:06 +0100
>>Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>Bart <bc@freeuk.com> writes:
>>>> Interpreter? Perl has some kind of compiler in it, right?
>>>
>>>The Perl compiler turns Perl source code into a set of (that's a
>>
>>Does it produce a standalone binary as output? No, so its an intepreter
>>not a compiler. However unlike the python interpreter its non interactive
>>making it an even less attractive option these days.
>
>That's a bad distinction. There have been "Load and Go"
>compilers in the past that have compiled and linked a program
>directly into memory and executed it immediately after
>compilation. As I recall, the Waterloo FORTRAN compilers on the
>IBM mainframe did, or could do, more or less this.

Indeed, the Burroughs mainframes also had compile&go capabilities.

HP-3000 had a concept called "pass files" which held the intermediate
formats between source and executable:
$ BASICCOMP HANGMAN.BAS
$ PREP $OLDPASS, $NEWPASS ($OLDPASS and $NEWPASS were implied if omitted).
$ RUN $OLDPASS

It also had

$ BASICGO (compile, prepare (link) and run)
$ BASICPREP (compile and prepare)

Similarly for COBOL, FORTRAN and SPL.

Subject: Re: Command Languages Versus Programming Languages
From: Rainer Weikusat
Newsgroups: comp.unix.shell, comp.unix.programmer, comp.lang.misc
Date: Fri, 11 Oct 2024 18:01 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rweikusat@talktalk.net (Rainer Weikusat)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 11 Oct 2024 19:01:27 +0100
Lines: 18
Message-ID: <871q0m7c3s.fsf@doppelsaurus.mobileactivedefense.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
<ve83q2$33dfe$1@dont-email.me>
<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
<ve8s6d$3725r$1@dont-email.me>
<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
<20241010120827.867@kylheku.com>
<87frp3itsk.fsf@doppelsaurus.mobileactivedefense.com>
<ve9mrh$3aiao$2@dont-email.me>
<87jzee3ded.fsf@doppelsaurus.mobileactivedefense.com>
<vebffc$3n6jv$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: individual.net BZ4TmUkN6wn/yp6stwvGFgoIeTn/gnHIRb09tsQh2JlOc2eXc=
Cancel-Lock: sha1:txXjcw49r1yr8iEvDqUSdHUuDag= sha1:Y1Sz8QIZFOt+B7aAAjrLilDbT0k= sha256:18z5NDuFyIB4sde3ejw3PSm87CgFlJBoNZk1V3LxTEQ=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
View all headers

Muttley@DastartdlyHQ.org writes:
> On Fri, 11 Oct 2024 15:47:06 +0100
> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>Bart <bc@freeuk.com> writes:
>>> Interpreter? Perl has some kind of compiler in it, right?
>>
>>The Perl compiler turns Perl source code into a set of (that's a
>
> Does it produce a standalone binary as output? No, so its an intepreter
> not a compiler. However unlike the python interpreter its non interactive
> making it an even less attractive option these days.

The perl debugger offers an interactive environment (with line editing support if
the necessary packages/ modules are available). It can be invoked with a
suitable 'script argument' to use it without actually debugging
something, eg,

perl -de 0

Pages:1234567

rocksolid light 0.9.8
clearnet tor