[Info-vax] BASIC (was Re: 64-bit)

[Dan Cross]

In article <uo3aa1$u939$1 at dont-email.me>,
Craig A. Berry <craigberry at nospam.mac.com> wrote:
>On 1/14/24 2:55 PM, Dan Cross wrote:
>> In article <uo1co2$ihn3$1 at dont-email.me>,
>> Craig A. Berry <craigberry at nospam.mac.com> wrote:
>>>
>>> On 1/13/24 7:29 PM, Dan Cross wrote:
>>>> In article <unv79k$4qr0$1 at dont-email.me>,
>>>> Craig A. Berry <craigberry at nospam.mac.com> wrote:
>>>>> On 1/13/24 1:50 PM, Dan Cross wrote:
>>>>>> In article <ununma$35nkk$1 at i2pn2.org>,
>>>>>> John Reagan  <johnrreagan at earthlink.net> wrote:
>>>>>>> On 1/12/2024 7:09 AM, Chris Townley wrote:
>>>>>>>> On 12/01/2024 06:15, Lawrence D'Oliveiro wrote:
>>>>>>>>> On Fri, 12 Jan 2024 00:40:47 -0500, Dave Froble wrote:
>>>>>>>>>
>>>>>>>>>> Basic in my opinion does strings very well.
>>>>>>>>>
>>>>>>>>> Only if you measure it by the pre-Perl era.
>>>>>>>>
>>>>>>>> Perl is the work of the devil!
>>>>>>>>
>>>>>>>
>>>>>>> I actually like Perl and did a whole bunch of scripting with it
>>>>>>> during my time with HP-UX and NonStop compilers.
>>>>>>
>>>>>> In it's day, Perl was kind of the only viable solution in the
>>>>>> space it inhabited (that of a relatively light-weight middle
>>>>>> ground between C on one hand and the shell+utilites on the
>>>>>> other).  Raku fixed most of the deficiencies of perl 4 and perl
>>>>>> 5, but I'd argue there are other, better languages to
>>>>>> choose from these days.
>>>>>
>>>>> Which of the languages that are available as part of the base install of
>>>>> OpenVMS x86 would you choose instead of Perl?
>>>>
>>>> TPU!
>>>
>>> Sure, it's better than DCL for some kinds of text processing, but you
>>> didn't say why you think it's better than Perl.  Or were you not aware
>>> that Perl is in the base install of OpenVMS x86?
>> 
>> In fact, I did not know that.  But I fail to see the relavence.
>> 
>> What I wrote, that you quoted and responded to, was that in it's
>> day Perl filled a certain niche between C and the shell plus
>> utilities (awk, sed, filters, etc).  
>
>It still does that well and the whole unix/linux tech universe would
>dissolve into a pile of unusable bits if Perl weren't there holding it
>together. It can do a whole lot more, though, and all sorts of serious
>systems have been written in it.

It still does it, but the question was, "does it do it _as well
as other languages"?  I see nothing to recommend Perl versus any
number of other languages that fill a similar space.

Just because Perl is useful, does not mean that it is a _good_
languate.  Conflating utility with quality is a common mistake.

>> This implies a Unix context
>> not VMS, though I suppose the POSIX environment for OpenVMS
>> might be applicable.
>
>It is not.

What is not?

>Extreme portability has been a hallmark of Perl for decades
>and the VMS port has been around for roughly 30 years.

The thing you do not seem to be grasping is that I was talking
about a programming language, not what comes out of the box with
VMS.  I had specifically mentioned Perl as a tool that sat
between C and the shell+utilities.  Where you seem to be failing
to comprehend is that, when I said "shell+utilities" I was
referring to a Unix environment (where Perl was born).  I wasn't
talking about VMS; the fact that Perl ships as part of the base
image for OpenVMS x86 seems irrelevant to the strengths and
weakenesses of the language.

>In fact, I don't
>even know what you mean by "POSIX environment for OpenVMS."  I think
>there was something called that a long time ago, though I never saw it
>or used it.

It seems, then, that you are responding to a strawman of your
own invention.

>There have been various things in the CRTL and the file
>system that provide compliance with one POSIX standard or another. Perl
>on VMS has generally not relied on any of them but has attempted to
>support some of them.

Not relevant.  The specific thing I was talking about was a
Unix-like shell and the "usual" compliment of Unix utilities.

>> Regardless I went on to say, "there are
>> other, better languages to choose from these days."  I never
>> stipulated or implied that those languages should be part of the
>> base OpenVMS x86 instalation; that seems to be a requirement
>> that you imposed after the fact.
>>
>> As for languages that I think are better than Perl on their
>> merits as languages, independent of a particular execution
>> environment defined by hardware and operating system, I'd put
>> both Ruby and Python in that camp for light-ish weight
>> scripting.  For systems lanugages I'd look at Rust or Ada.  For
>> engineering large solutions I'd look at Go or Rust.  For serious
>> string processing applications, building compilers or the like,
>> I'd look at OCaml, Rust, Go, or even SML (the MLton compiler is
>> whole-program optimizing and quite good).  Haskell is also a
>> nice language, but tends not to be very accessible to workaday
>> programmers.
>
>That's a good, if predictable, list of the most popular languages around
>in the marketplace. I was genuinely curious whether, given the
>(implicit) list of DCL, TPU, and Perl available to all VMS users out of
>the box, you would be able to give an on-topic, practical answer rather
>than a lecture about how many languages you know and what's wrong with
>the languages people can actually use. We see how that turned out.

You asked my opinion about programming languages then imposed
this requirement that they come with OpenVMS by default after
the fact.  That's a strawman.  Physician, heal thyself.

>> Some specific problems with Perl _as a language_ include lack of
>> static typing, though that is also true of Python and Ruby
>
>They are dynamic languages, and as Steven Schweda would say, "dynamic"
>is spelled differently from "static" for a reason.

Yeah, and having worked on large systems written in both Python
and Common Lisp, I wouldn't recommend a dynamic language for
serious work given other alternatives.  Have you ever worked in
a million line system in a dynamic language?  Be honest.  I once
debugged a production outage in a Lisp system where someone
tried to add a number to the CDR of a list, raising a condition.
The CONS cell in question had originally be used to hold a pair
of numbers; that pair was then extended to a thruple but the
programmer who made the change missed one updating one call to
CADR.  Something that would have been trivially caught by the
compiler in a statically typed language.  Static type systems
render entire classes of errors unrepresentable.

>>, but
>> also lack of formal argument parameters to subroutines (fixed in
>> Raku however), the abstruse object system, overly implicit
>> behavior with respect to scope for things like splitting strings
>> and so on (an attempt to inherent a sort of "current record"
>> notion from awk), and the inefficient "regexp" implementation
>> that goes way beyond the regular languages and uses backtracking
>> for matching e.g. backrefs.
>
>Raku, despite it origins, is a language unrelated to Perl.

"Raku is a member of the Perl family of programming languages.
Formerly known as Perl 6, it was renamed in October 2019."
https://en.wikipedia.org/wiki/Raku_(programming_language)

>Any benchmark
>I've ever heard of shows Perl has a more performant regex engine than
>most or all the others.

https://swtch.com/~rsc/regexp/regexp1.html

>Discussions about a better object system are ongoing.

That's great!

>Perl isn't perfect, but it continues to improve in its fourth
>decade without the massive corporate support that some other languages
>get.

That's also great!

>To your credit, you did not say it looks like line noise, the
>oft-cited criticism from people who don't know what regular expressions are.

Because I don't think that it looks like line noise.  I don't
even really think that perl is a _bad_ language, and at one
point it was de facto necessary, as I pointed out.

You seem to be offended and reactive that I think there are
_better_ langauges and you seem to think it a sign of a poor
argument that I pointed to other, currently popular, languages
as alternatives.  Have you considered that those other
languages may be more popular than Perl these days for a
_reason_?  Have you further consider that languages designed
more recently might have even taken lessons from, perhaps even
been inspired by aspects of, Perl's design?  That's actually
quite a complimentary legacy, if you can get beyond the
emotion about it.

>> At this stage, given a choice between Perl and Ruby or Python,
>> I'd pick one of the latter two every time.
>>
>> Does that answer your question?
>
>Yeah, pretty much.

Cool.

Look man, a programming language is not my sister: I don't feel
the need to defend its honor if its criticized.  After many
decades in this industry I can no longer bring myself to feel
strong emotions about technology; it's just not worth it.
Things come and go; Perl had a great run and enjoyed a long time
in the sun.  That doesn't mean that it's bad, but time doesn't
stand still and it also doesn't mean that there aren't other,
better options available today.  Perhaps put down the knee-jerk
defensiveness and investigate why people think other languages
are better.  You might just learn something.

	- Dan C.