... I think BASIC did have a pretty good
run in the 90's and early 2000's, particularly on the Windows desktop platform.
On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
... I think BASIC did have a pretty good
run in the 90's and early 2000's, particularly on the Windows desktop
platform.
It had a role on 1980s micros, I’ll grant you that. The ability to switch >> on and start typing code made for quite a productive environment: type a
statement with a line number to add it to your in-memory program, or
without to execute the line immediately.
Nowadays, Jupyter notebooks offer a more modern environment for such
incremental, even scratchpad-style programming. And Python is a more
modern language without the limitations of BASIC.
Have you ever used DEC/Compaq/HP basic?
It is unlike the early home computer Basic. In its day it was a modern
highly structured language - which was of course compiled.
I maintained and developed an ERP system consisting of well over a
million lines of code, which worked well to support our business
On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
... I think BASIC did have a pretty good
run in the 90's and early 2000's, particularly on the Windows desktop
platform.
It had a role on 1980s micros, I’ll grant you that. The ability to switch on and start typing code made for quite a productive environment: type a statement with a line number to add it to your in-memory program, or
without to execute the line immediately.
Nowadays, Jupyter notebooks offer a more modern environment for such incremental, even scratchpad-style programming. And Python is a more
modern language without the limitations of BASIC.
On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
... I think BASIC did have a pretty good
run in the 90's and early 2000's, particularly on the Windows desktop
platform.
It had a role on 1980s micros, I’ll grant you that. The ability to
switch on and start typing code made for quite a productive
environment: type a statement with a line number to add it to your
in-memory program, or without to execute the line immediately.
Nowadays, Jupyter notebooks offer a more modern environment for such
incremental, even scratchpad-style programming. And Python is a more
modern language without the limitations of BASIC.
Have you ever used DEC/Compaq/HP basic?
It is unlike the early home computer Basic. In its day it was a modern
highly structured language - which was of course compiled.
I maintained and developed an ERP system consisting of well over a
million lines of code, which worked well to support our business
On Wed, 10 Jan 2024 23:28:29 +0000, Chris Townley wrote:
On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
... I think BASIC did have a pretty good
run in the 90's and early 2000's, particularly on the Windows desktop
platform.
It had a role on 1980s micros, I’ll grant you that. The ability to
switch on and start typing code made for quite a productive
environment: type a statement with a line number to add it to your
in-memory program, or without to execute the line immediately.
Have you ever used DEC/Compaq/HP basic?
I think so, yes. It very much tried to emulate the interactive BASIC-PLUS environment from RSTS/E, as I recall (right down to the “Ready” prompt).
I maintained and developed an ERP system consisting of well over a
million lines of code, which worked well to support our business
So you got it to work, back in the day. Nowadays, there are easier ways of achieving the same thing. For one thing, you would have many existing libraries to draw on, instead of having to write all that code yourself.
Nowadays, Jupyter notebooks offer a more modern environment for
such incremental, even scratchpad-style programming. And Python is
a more modern language without the limitations of BASIC.
Have you ever used DEC/Compaq/HP basic?
It is unlike the early home computer Basic. In its day it was a
modern highly structured language - which was of course compiled.
I maintained and developed an ERP system consisting of well over a
million lines of code, which worked well to support our business
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
bill
On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by Basic?
On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
... I think BASIC did have a pretty good run in the 90's and early
2000's, particularly on the Windows desktop platform.
It had a role on 1980s micros, I’ll grant you that. The ability to
switch on and start typing code made for quite a productive
environment: type a statement with a line number to add it to your
in-memory program, or without to execute the line immediately.
Nowadays, Jupyter notebooks offer a more modern environment for such incremental, even scratchpad-style programming. And Python is a more
modern language without the limitations of BASIC.
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
On 1/10/2024 6:54 PM, Lawrence D'Oliveiro wrote:
On Wed, 10 Jan 2024 23:28:29 +0000, Chris Townley wrote:
I maintained and developed an ERP system consisting of well over a
million lines of code, which worked well to support our business
So you got it to work, back in the day. Nowadays, there are easier
ways of
achieving the same thing. For one thing, you would have many existing
libraries to draw on, instead of having to write all that code yourself.
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
On 2024-01-10 20:17:03 +0000, Lawrence D'Oliveiro said:
On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
... I think BASIC did have a pretty good run in the 90's and early
2000's, particularly on the Windows desktop platform.
It had a role on 1980s micros, I’ll grant you that. The ability to
switch on and start typing code made for quite a productive
environment: type a statement with a line number to add it to your
in-memory program, or without to execute the line immediately.
Nowadays, Jupyter notebooks offer a more modern environment for such
incremental, even scratchpad-style programming. And Python is a more
modern language without the limitations of BASIC.
There's sufficient BASIC code that's still in active use to keep VSI interested in providing at least some tooling for those OpenVMS customers.
A whole lot of that BASIC code came through from the PDP-11 era
platforms and tools. It is entrenched.
Would I pick BASIC for wholly new app work? Probably not.
But there's a lot of BASIC code around that would otherwise need to be reworked or rewritten. Or ported to BASIC on some other platform.
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by Basic?
Usually the answer to this is going to be some combination of
better abstraction facilities, better safety properties, more
capable and ergonomic libraries, etc.
VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature.
String handling
seems anemic.
There doesn't seem to be support for generalized
memory pointers,
let along non-nullable references, so your
ability to create rich linked data structures seems limited.
I
don't see any support for higher-order functions,
lambdas,
or
closures;
no currying of functions.
Statement modifiers seem
kind of neat, but I bet they can be easily misused.
All in all, it doesn't look like a terrible language (it's not
COBOL); it looks like an early-1980s-era language. But nothing
about it jumps out at me as being spectacularly amazing, either.
I suppose I would turn the question around and ask what's about
BASIC makes it more suitable than other languages for particular
types of programs?
Basic in my opinion does strings very well.
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.
On 1/11/2024 2:42 PM, Dan Cross wrote:
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:Usually the answer to this is going to be some combination of
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by Basic? >>
better abstraction facilities, better safety properties, more
capable and ergonomic libraries, etc.
Which then asks the question, are such really better? Perhaps some of that is
more opinion than fact.
Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature.
What amuses me about that is that when people talk about "classes", I don't have
a clue what they are talking about. Perhaps I do, if the case is new names for
old concepts. That is something I didn't like about Microsoft, they seemed to
like re-naming concepts.
I suppose I would turn the question around and ask what's about
BASIC makes it more suitable than other languages for particular
types of programs?
For me personally, I really like the syntax of the language. When I have to attempt to read C code I'm easily confused. Many other languages seem to copy
the syntax of C.
On 1/11/2024 2:42 PM, Dan Cross wrote:
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:Usually the answer to this is going to be some combination of
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by Basic? >>
better abstraction facilities, better safety properties, more
capable and ergonomic libraries, etc.
VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature. String handling
seems anemic. There doesn't seem to be support for generalized
memory pointers, let along non-nullable references, so your
ability to create rich linked data structures seems limited. I
don't see any support for higher-order functions, lambdas, or
closures; no currying of functions. Statement modifiers seem
kind of neat, but I bet they can be easily misused.
All in all, it doesn't look like a terrible language (it's not
COBOL);
Dave has his fixation on BASIC. One of mine is COBOL.
When using it to do the kind of work is was designed and intended for
just what do you think is wrong with COBOL?
On 1/11/2024 2:42 PM, Dan Cross wrote:
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:Usually the answer to this is going to be some combination of
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by Basic? >>
better abstraction facilities, better safety properties, more
capable and ergonomic libraries, etc.
Which then asks the question, are such really better? Perhaps some of that is >more opinion than fact.
Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature.
What amuses me about that is that when people talk about "classes", I don't have
a clue what they are talking about. Perhaps I do, if the case is new names for
old concepts. That is something I didn't like about Microsoft, they seemed to >like re-naming concepts.
String handling
seems anemic.
Can't let that one go. Basic in my opinion does strings very well.
There doesn't seem to be support for generalized
memory pointers,
Correct, Basic does not have any pointer data types. It does have a function to
retrieve the value of a pointer.
let along non-nullable references, so your
ability to create rich linked data structures seems limited.
Not sure what that means ...
I
don't see any support for higher-order functions,
Not sure what that means ...
lambdas,
Not sure what that means ...
or
closures;
Not sure what that means ...
no currying of functions.
Not sure what that means ...
Statement modifiers seem
kind of neat, but I bet they can be easily misused.
Statement modifiers are very useful, and in some ways make code easier to >understand.
All in all, it doesn't look like a terrible language (it's not
COBOL); it looks like an early-1980s-era language. But nothing
about it jumps out at me as being spectacularly amazing, either.
It's not amazing, it just works.
I suppose I would turn the question around and ask what's about
BASIC makes it more suitable than other languages for particular
types of programs?
For me personally, I really like the syntax of the language. When I have to >attempt to read C code I'm easily confused. Many other languages seem to copy >the syntax of C.
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!
On 2024-01-12, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 2:42 PM, Dan Cross wrote:
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:Usually the answer to this is going to be some combination of
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:I confess to curiosity. In what ways has other languages passed by Basic? >>>
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by. >>>>
better abstraction facilities, better safety properties, more
capable and ergonomic libraries, etc.
Which then asks the question, are such really better? Perhaps some of that is
more opinion than fact.
Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature.
What amuses me about that is that when people talk about "classes", I don't have
a clue what they are talking about. Perhaps I do, if the case is new names for
old concepts. That is something I didn't like about Microsoft, they seemed to
like re-naming concepts.
This is absolutely nothing to do with Microsoft. It is a general language concept/construct.
Sorry David, but you don't understand this and the other items Dan lists, then you are not qualified to judge the relative merits of other languages
to BASIC.
[Snip other examples]
I suppose I would turn the question around and ask what's about
BASIC makes it more suitable than other languages for particular
types of programs?
For me personally, I really like the syntax of the language. When I have to >> attempt to read C code I'm easily confused. Many other languages seem to copy
the syntax of C.
I suggest you look at the Wirth-style languages then. They are nothing
like C.
In article <unqjcn$3c1o2$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 2:42 PM, Dan Cross wrote:
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:Usually the answer to this is going to be some combination of
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:I confess to curiosity. In what ways has other languages passed by Basic? >>>
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by. >>>>
better abstraction facilities, better safety properties, more
capable and ergonomic libraries, etc.
Which then asks the question, are such really better? Perhaps some of that is
more opinion than fact.
Some of it is opinion. Some of it is limitations in the
language. Some of it is suitability for purpose.
Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
Understood.
VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature.
What amuses me about that is that when people talk about "classes", I don't have
a clue what they are talking about. Perhaps I do, if the case is new names for
old concepts. That is something I didn't like about Microsoft, they seemed to
like re-naming concepts.
I'm not sure what Microsoft has to do with it. The concept of a
"class" has existed in one form or the others since Simula in
1967.
String handling
seems anemic.
Can't let that one go. Basic in my opinion does strings very well.
What do you like about it?
Consider writing a lexical analyzer for a simple expression
language; what would such a thing look like, in BASIC? Here I
want to take a string as input, and emit a list of tokens that
correspond to the elements of the langauge that are represented
in that string.
There doesn't seem to be support for generalized
memory pointers,
Correct, Basic does not have any pointer data types. It does have a function to
retrieve the value of a pointer.
That makes it challenging to implement dynamically sized data
structures like trees or graphs where the size is not already
known, or hash tables that use chaining for collision resolution
etc.
How would I do these things in VSI BASIC?
let along non-nullable references, so your
ability to create rich linked data structures seems limited.
Not sure what that means ...
Basically, pointers that are always valid in pointing to an
object of a known type and and that can never be nil.
I
don't see any support for higher-order functions,
Not sure what that means ...
Basically, functions that can be passed as arguments to other
functions or functions that can be returned from functions.
These let me do things like write a generic hash table
implementation, where I can then parameterize calls into the
resulting data type with functions that implement the actual
hash for particular types of data. "Hash table of FOO."
lambdas,
Not sure what that means ...
Anonymous functions; ie, functions that are unnamed. They're
very handy in languages that support higher-order functions.
For example, I can trivially write a projection function that
will extract a particular member from a data structure to use
as a sort key.
or
closures;
Not sure what that means ...
Functions that are created dynamically and "close over" part of
their surrounding environment, e.g., to capture a value that is
used in the closure itself.
no currying of functions.
Not sure what that means ...
Partial application of a function, which allows me to create a
new function that calls some underlying function with some
arguments already "filled in". An example, from SML:
fun fib' a b 0 = a
| fib' a b n = fib' (a + b) a (n - 1)
val fib = fib' 0 1
Here `fib` is a function to return the nth Fibonacci
number.
This example demonstrates several of these concepts:
; sml
Standard ML of New Jersey (64-bit) v110.99.4 [built: Tue Aug 01 16:07:38 2023]
- val fib =
= let fun fib' a b 0 = a
= | fib' a b n = fib' (a + b) a (n - 1)
= in fn n => fib' 0 1 n
= end;
val fib = fn : int -> int
- fib;
val it = fn : int -> int
- fib';
stdIn:3.1-3.5 Error: unbound variable or constructor: fib'
- map;
val it = fn : ('a -> 'b) -> 'a list -> 'b list
- map (fn n => fib n) [1,2,3,4,5,6,7,8,9];
val it = [1,1,2,3,5,8,13,21,34] : int list
- ^D
;
Here, we see an example of a closure, in which the anonymous
function (aka, lambda) returned from the `let` clause that is
bound to `fib` closes over the `fib'` function, which is not
visible outside of the `let`. Furthermore, `fib` is an example
of currying as above. We see the use of higher-order functions
in the call to `map`, which applies `fib` to each element of the
given list. We can see it again with a slightly different
example:
- List.tabulate(10, fn n => fib n);
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[autoloading done]
val it = [0,1,1,2,3,5,8,13,21,34] : int list
Again, these are all examples from Standard ML, a langauge that
dates from the 80s, and takes its roots in the 70s.
Statement modifiers seem
kind of neat, but I bet they can be easily misused.
Statement modifiers are very useful, and in some ways make code easier to
understand.
I'm sure they are useful, but I can also imagine that they can
turn into spaghetti if not used judiciously.
X = X * 0.1 unless FOO != 2;
X = X * 0.2 unless FOO = 2;
seems strictly less readable than
IF FOO != 2
X = X * 0.1
ELSE
X = X * 0.2
(Apologies for syntax errors.)
All in all, it doesn't look like a terrible language (it's not
COBOL); it looks like an early-1980s-era language. But nothing
about it jumps out at me as being spectacularly amazing, either.
It's not amazing, it just works.
Sure. That doesn't mean that it's good by modern standards.
I suppose I would turn the question around and ask what's about
BASIC makes it more suitable than other languages for particular
types of programs?
For me personally, I really like the syntax of the language. When I have to >> attempt to read C code I'm easily confused. Many other languages seem to copy
the syntax of C.
As has been mentioned, not all "modern" languages have C-like
syntax. Examples that pop out at me off the top of my head
include Oberon (Wirth's final language, descendent of Modula-2),
Ruby, Python, Clojure (a Lisp that targets the JVM), F# (a
dialect of the OCaml language --- another entry in the ML
family --- that targets the CLR), OCaml itself (with a native
compiler). Most of these are 20 years old or more; the youngest
language on the list is probably Clojure, which is only 17, but
has its root in Lisp, which dates from the 50s.
Simply preferring the syntax, however, doesn't feel like
sufficient reason to claim that other languages haven't passed
BASIC, even VSI BASIC, by. I'm sure it was a decent business
data processing langauge in the 80s; not so much now days.
- Dan C.
On 1/11/2024 2:42 PM, Dan Cross wrote:
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by
Basic?
Usually the answer to this is going to be some combination of
better abstraction facilities, better safety properties, more
capable and ergonomic libraries, etc.
Which then asks the question, are such really better? Perhaps some of
that is more opinion than fact.
VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature.
What amuses me about that is that when people talk about "classes", I
don't have a clue what they are talking about. Perhaps I do, if the
case is new names for old concepts. That is something I didn't like
about Microsoft, they seemed to like re-naming concepts.
I
don't see any support for higher-order functions,
Not sure what that means ...
lambdas,
Not sure what that means ...
or
closures;
Not sure what that means ...
no currying of functions.
Not sure what that means ...
In article <unqjcn$3c1o2$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 2:42 PM, Dan Cross wrote:
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:I confess to curiosity. In what ways has other languages passed by Basic?
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by. >>>>
String handling
seems anemic.
Can't let that one go. Basic in my opinion does strings very well.
What do you like about it?
Consider writing a lexical analyzer for a simple expression
language; what would such a thing look like, in BASIC? Here I
want to take a string as input, and emit a list of tokens that
correspond to the elements of the langauge that are represented
in that string.
There doesn't seem to be support for generalized
memory pointers,
Correct, Basic does not have any pointer data types. It does have a function to
retrieve the value of a pointer.
That makes it challenging to implement dynamically sized data
structures like trees or graphs where the size is not already
known, or hash tables that use chaining for collision resolution
etc.
How would I do these things in VSI BASIC?
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!
On 1/12/2024 12:26 PM, Dan Cross wrote:
[snip]
It does not mean much for writing business applications. Creating
such data structures are not part of writing business applications.
In article <uns6a6$3j4gn$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/12/2024 12:26 PM, Dan Cross wrote:
[snip]
It does not mean much for writing business applications. Creating
such data structures are not part of writing business applications.
Eh? Not building a fast indexing structure based on domain
rules isn't a part of writing business applications? I mean, ok
I'll take your word for it as I'm not a business applications
programmer type of guy, but that seems kind of weird to me.
On 1/12/2024 12:26 PM, Dan Cross wrote:
In article <unqjcn$3c1o2$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 2:42 PM, Dan Cross wrote:
In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:I confess to curiosity. In what ways has other languages passed by Basic?
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by. >>>>>
String handling
seems anemic.
Can't let that one go. Basic in my opinion does strings very well.
What do you like about it?
Consider writing a lexical analyzer for a simple expression
language; what would such a thing look like, in BASIC? Here I
want to take a string as input, and emit a list of tokens that
correspond to the elements of the langauge that are represented
in that string.
Basic has the fundamental string concept right with dynamic strings.
Maybe it miss a few string functions. Including something for regex.
But it is not that different from Java, C#, Python, whatever.
There doesn't seem to be support for generalized
memory pointers,
Correct, Basic does not have any pointer data types. It does have a function to
retrieve the value of a pointer.
That makes it challenging to implement dynamically sized data
structures like trees or graphs where the size is not already
known, or hash tables that use chaining for collision resolution
etc.
How would I do these things in VSI BASIC?
Basic operates on arrays via array indexes (like Fortran and Cobol).
And arrays can be resized.
I posted a tree example here 2 years ago.
Pretty? No. Pretty awful looking.
But what does that mean?
It means that Basic is a poor language for teaching fundamental
data structures.
It means that Basic should not be used for all libraries used
by Basic.
It does not mean much for writing business applications. Creating
such data structures are not part of writing business applications.
In article <unrsp9$ma6$2@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <unra5q$3eha8$1@dont-email.me>,
Chris Townley <news@cct-net.co.uk> 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!
Please don't feed the troll.
Perl _is_ the work of the devil but even so it does strings pretty well.
In article <unra5q$3eha8$1@dont-email.me>,
Chris Townley <news@cct-net.co.uk> 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!
Please don't feed the troll.
For some of us, it hasn't replaced awk.
On 1/12/2024 3:56 PM, Dan Cross wrote:
In article <uns6a6$3j4gn$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/12/2024 12:26 PM, Dan Cross wrote:
[snip]
It does not mean much for writing business applications. Creating
such data structures are not part of writing business applications.
Eh? Not building a fast indexing structure based on domain
rules isn't a part of writing business applications? I mean, ok
I'll take your word for it as I'm not a business applications
programmer type of guy, but that seems kind of weird to me.
The business application just builds on general purpose libraries.
If the platform comes with good general purpose libraries, then
everything needed is there.
If not so lucky then a custom library may be needed, but that
is a library not a business application thing. And that library
is not necessarily written by the same developer and not necessarily
in the same language as the business application. Different
skill set and different requirements.
Basic and some ERP system. It uses some collections framework,
some XML and JSON libs, a database lib etc.. Money is made
from getting the application completed and out the door, not
from creating better libraries.
Or Python and data analysis. The developer knows Python,
the data and how to interpret results. Deep down the
stack there are some matrix multiplication and inversion
code written in Fortran by a developer that knows nothing
about data analysis. What would happen if the Python
developer wanted to implement a custom matrix inversion?
Most likely not anything good!
[snip]
Overall, your post is interesting.
On 1/12/2024 12:26 PM, Dan Cross wrote:
In article <unqjcn$3c1o2$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 2:42 PM, Dan Cross wrote:
[snip]
Which then asks the question, are such really better? Perhaps some of that is
more opinion than fact.
Some of it is opinion. Some of it is limitations in the
language. Some of it is suitability for purpose.
Suitability for purpose is always rather important.
Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
Understood.
VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature.
What amuses me about that is that when people talk about "classes", I don't have
a clue what they are talking about. Perhaps I do, if the case is new names for
old concepts. That is something I didn't like about Microsoft, they seemed to
like re-naming concepts.
I'm not sure what Microsoft has to do with it. The concept of a
"class" has existed in one form or the others since Simula in
1967.
String handling
seems anemic.
Can't let that one go. Basic in my opinion does strings very well.
What do you like about it?
Consider writing a lexical analyzer for a simple expression
language; what would such a thing look like, in BASIC? Here I
want to take a string as input, and emit a list of tokens that
correspond to the elements of the langauge that are represented
in that string.
Don't totally understand, perhaps parsing for commands, switches, and such would
be similar.
There doesn't seem to be support for generalized
memory pointers,
A pointer data type can be very useful. A compiler could use such to generate >proper sizing for different systems. But, in the end, it is just a numeric >piece of data. If one can process the numbers, that works. Not as generic, >but, it works. For VAX, it is an unsigned longword. For 64 bit addressing, it
is an unsigned 64 bit integer.
For example, what is the difference between memory pointers and indices in an in
memory resident data structure, such as linked lists? Not much, in concept, right?
Correct, Basic does not have any pointer data types. It does have a function to
retrieve the value of a pointer.
That makes it challenging to implement dynamically sized data
structures like trees or graphs where the size is not already
known, or hash tables that use chaining for collision resolution
etc.
Not really. There is always LIB$GET_VM.
How would I do these things in VSI BASIC?
Once you can get the memory, what's the difference between say, linked lists >there, vs using pre-allocated array(s)?
let along non-nullable references, so your
ability to create rich linked data structures seems limited.
Not sure what that means ...
Basically, pointers that are always valid in pointing to an
object of a known type and and that can never be nil.
Seems to me, pointers/indices in use always have a valid value?
I
don't see any support for higher-order functions,
Not sure what that means ...
Basically, functions that can be passed as arguments to other
functions or functions that can be returned from functions.
These let me do things like write a generic hash table
implementation, where I can then parameterize calls into the
resulting data type with functions that implement the actual
hash for particular types of data. "Hash table of FOO."
Hash tables takes me back to the mid 1970s. :-)
Is what you mean something like:
Z = FIX( SQR( SomeValue ) )
Yeah, rather simple, but is that what you refer to?
lambdas,
Not sure what that means ...
Anonymous functions; ie, functions that are unnamed. They're
very handy in languages that support higher-order functions.
For example, I can trivially write a projection function that
will extract a particular member from a data structure to use
as a sort key.
Not sure if you're making my brain hurt, or discussing something so simple it >doesn't deserve a name. I've built sort keys for longer than I can remember.
or
closures;
Not sure what that means ...
Functions that are created dynamically and "close over" part of
their surrounding environment, e.g., to capture a value that is
used in the closure itself.
More brain pain ...
no currying of functions.
Not sure what that means ...
Partial application of a function, which allows me to create a
new function that calls some underlying function with some
arguments already "filled in". An example, from SML:
fun fib' a b 0 = a
| fib' a b n = fib' (a + b) a (n - 1)
val fib = fib' 0 1
Here `fib` is a function to return the nth Fibonacci
number.
Why does that require a special name?
This example demonstrates several of these concepts:
; sml
Standard ML of New Jersey (64-bit) v110.99.4 [built: Tue Aug 01 16:07:38 2023]
- val fib =
= let fun fib' a b 0 = a
= | fib' a b n = fib' (a + b) a (n - 1)
= in fn n => fib' 0 1 n
= end;
val fib = fn : int -> int
- fib;
val it = fn : int -> int
- fib';
stdIn:3.1-3.5 Error: unbound variable or constructor: fib'
- map;
val it = fn : ('a -> 'b) -> 'a list -> 'b list
- map (fn n => fib n) [1,2,3,4,5,6,7,8,9];
val it = [1,1,2,3,5,8,13,21,34] : int list
- ^D
;
Here, we see an example of a closure, in which the anonymous
function (aka, lambda) returned from the `let` clause that is
bound to `fib` closes over the `fib'` function, which is not
visible outside of the `let`. Furthermore, `fib` is an example
of currying as above. We see the use of higher-order functions
in the call to `map`, which applies `fib` to each element of the
given list. We can see it again with a slightly different
example:
- List.tabulate(10, fn n => fib n);
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[autoloading done]
val it = [0,1,1,2,3,5,8,13,21,34] : int list
Again, these are all examples from Standard ML, a langauge that
dates from the 80s, and takes its roots in the 70s.
I'm going to guess that your experience includes labels for certain things, >which might be helpful at times, and exist in subsets of programming practices.
Nothing wrong with that, but might be confusing to some others.
Statement modifiers seem
kind of neat, but I bet they can be easily misused.
Statement modifiers are very useful, and in some ways make code easier to >>> understand.
I'm sure they are useful, but I can also imagine that they can
turn into spaghetti if not used judiciously.
X = X * 0.1 unless FOO != 2;
X = X * 0.2 unless FOO = 2;
seems strictly less readable than
IF FOO != 2
X = X * 0.1
ELSE
X = X * 0.2
(Apologies for syntax errors.)
The first thing any programmer should learn is, at some time in the future code
will be read by another, and if it is not concise, clear, and understandable, it
is the fault of the original programmer, and he/she should find another occupation.
Yes, if-then-else, select case, and such can be good, and I've also seen such be
hundreds of lines of code, and a real PITA. I tend to favor modular code. >Simple, short, and to the point.
But for a simple true or false, the statement modifiers can be very useful. In
your first example, FOO should be evaluated only once.
All in all, it doesn't look like a terrible language (it's not
COBOL); it looks like an early-1980s-era language. But nothing
about it jumps out at me as being spectacularly amazing, either.
It's not amazing, it just works.
Sure. That doesn't mean that it's good by modern standards.
Nor does it mean it is bad either.
In article <unsbik$3jsdv$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
The business application just builds on general purpose libraries.
If the platform comes with good general purpose libraries, then
everything needed is there.
If not so lucky then a custom library may be needed, but that
is a library not a business application thing. And that library
is not necessarily written by the same developer and not necessarily
in the same language as the business application. Different
skill set and different requirements.
Basic and some ERP system. It uses some collections framework,
some XML and JSON libs, a database lib etc.. Money is made
from getting the application completed and out the door, not
from creating better libraries.
Or Python and data analysis. The developer knows Python,
the data and how to interpret results. Deep down the
stack there are some matrix multiplication and inversion
code written in Fortran by a developer that knows nothing
about data analysis. What would happen if the Python
developer wanted to implement a custom matrix inversion?
Most likely not anything good!
This may all be true, but a) suggesting that business
programmers can't or shouldn't implement elementary data
structures seems a bit on the nose,
and b) if the language makes
it difficult to do so, that's a real shame. BASIC is a general
purpose programming language, not a DSL.
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!
On 1/13/2024 9:54 AM, Dan Cross wrote:
In article <unsbik$3jsdv$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
The business application just builds on general purpose libraries.
If the platform comes with good general purpose libraries, then
everything needed is there.
If not so lucky then a custom library may be needed, but that
is a library not a business application thing. And that library
is not necessarily written by the same developer and not necessarily
in the same language as the business application. Different
skill set and different requirements.
Basic and some ERP system. It uses some collections framework,
some XML and JSON libs, a database lib etc.. Money is made
from getting the application completed and out the door, not
from creating better libraries.
Or Python and data analysis. The developer knows Python,
the data and how to interpret results. Deep down the
stack there are some matrix multiplication and inversion
code written in Fortran by a developer that knows nothing
about data analysis. What would happen if the Python
developer wanted to implement a custom matrix inversion?
Most likely not anything good!
This may all be true, but a) suggesting that business
programmers can't or shouldn't implement elementary data
structures seems a bit on the nose,
Some business applications developers can and should. Writing
good general purpose libraries is distinct from writing business
application, but the abilities are not mutually exclusive. Some
people have skills within more than one area,
and b) if the language makes
it difficult to do so, that's a real shame. BASIC is a general
purpose programming language, not a DSL.
Most general purpose languages have areas where they are
strong and areas where they are not strong. VMS Basic is good
at reading, writing and manipulating text and amount - old style
business programming. It is not good for writing various dynamic
data structures, multi threaded programming or privileged code. I
would not even consider it a good choice for scientific
programming. Its competitor languages must be Cobol, PL/I, Dibol
and maybe Pascal - not Fortran, C, C++, Ada, Bliss and Macro-32.
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.
On 1/12/2024 10:41 PM, Scott Dorsey wrote:
In article <unrsp9$ma6$2@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <unra5q$3eha8$1@dont-email.me>,
Chris Townley <news@cct-net.co.uk> 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!
Please don't feed the troll.
Perl _is_ the work of the devil but even so it does strings pretty well.
It is what it was created for.
And besides - can't we say that it replaced awk for that purpose?
On Fri, 12 Jan 2024 23:03:33 -0500, bill wrote:
For some of us, it hasn't replaced awk.
Perl does everything that Awk does, just as concisely. And it does more, >besides.
In article <ununma$35nkk$1@i2pn2.org>,
John Reagan <johnrreagan@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.
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.
What put me off Perl was [some idiot misusing it].
On 1/13/24 1:50 PM, Dan Cross wrote:
In article <ununma$35nkk$1@i2pn2.org>,
John Reagan <johnrreagan@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?
Yes, it's a trick question.
In article <unv79k$4qr0$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
On 1/13/24 1:50 PM, Dan Cross wrote:
In article <ununma$35nkk$1@i2pn2.org>,
John Reagan <johnrreagan@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!
On 1/13/24 7:29 PM, Dan Cross wrote:
In article <unv79k$4qr0$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
On 1/13/24 1:50 PM, Dan Cross wrote:
In article <ununma$35nkk$1@i2pn2.org>,
John Reagan <johnrreagan@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 article <uo1co2$ihn3$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
On 1/13/24 7:29 PM, Dan Cross wrote:
In article <unv79k$4qr0$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
On 1/13/24 1:50 PM, Dan Cross wrote:
In article <ununma$35nkk$1@i2pn2.org>,
John Reagan <johnrreagan@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).
This implies a Unix context
not VMS, though I suppose the POSIX environment for OpenVMS
might be applicable.
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.
Some specific problems with Perl _as a language_ include lack of
static typing, though that is also true of Python and Ruby
, 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.
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?
In article <uo1co2$ihn3$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
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.
On 1/13/24 1:50 PM, Dan Cross wrote:
In article <ununma$35nkk$1@i2pn2.org>,
John Reagan <johnrreagan@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?
Yes, it's a trick question.
On 2024-01-14, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <uo1co2$ihn3$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
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.
In some security-sensitive environments, such as the environments some
VMS systems are running on, you can't just install a scripting language
from the Internet that has not been validated by your vendor (ie: VSI).
On 1/14/24 2:55 PM, Dan Cross wrote:
In article <uo1co2$ihn3$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
On 1/13/24 7:29 PM, Dan Cross wrote:
In article <unv79k$4qr0$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
On 1/13/24 1:50 PM, Dan Cross wrote:
In article <ununma$35nkk$1@i2pn2.org>,
John Reagan <johnrreagan@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.
This implies a Unix context
not VMS, though I suppose the POSIX environment for OpenVMS
might be applicable.
It is not.
Extreme portability has been a hallmark of Perl for decades
and the VMS port has been around for roughly 30 years.
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.
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.
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.
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.
, 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.
Any benchmark
I've ever heard of shows Perl has a more performant regex engine than
most or all the others.
Discussions about a better object system are ongoing.
Perl isn't perfect, but it continues to improve in its fourth
decade without the massive corporate support that some other languages
get.
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.
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.
On 1/15/24 8:15 AM, Simon Clubley wrote:
On 2024-01-13, Craig A. Berry <craigberry@nospam.mac.com> wrote:
Which of the languages that are available as part of the base install of >>> OpenVMS x86 would you choose instead of Perl?
Yes, it's a trick question.
I would choose the Python installation that's part of the base install
and hence guaranteed to be present on every system.
I wish that Python were available out of the box, and perhaps it will be
some day, but as far as I know it isn't yet. In fact I don't think it's even available as a separate install for x86 yet is it?
On 2024-01-13, Craig A. Berry <craigberry@nospam.mac.com> wrote:
On 1/13/24 1:50 PM, Dan Cross wrote:
In article <ununma$35nkk$1@i2pn2.org>,
John Reagan <johnrreagan@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?
Yes, it's a trick question.
I would choose the Python installation that's part of the base install
and hence guaranteed to be present on every system.
I know that Craig is very fond of Perl, but IMHO, the way forward
is Python, not Perl. I was a Perl user at one time, but it must be
at least 15 years since I have touched it. Other alternatives have
taken over from the position Perl once held.
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
I know that Craig is very fond of Perl, but IMHO, the way forward
is Python, not Perl. I was a Perl user at one time, but it must be
at least 15 years since I have touched it. Other alternatives have
taken over from the position Perl once held.
There is far more new development being done in Python. But, there is far more existing code on VMS systems in Perl. If the goal is to get x64 VMS
up to the point of being able to move existing VMS users onto it, then Perl is a clear winner. If the goal is to get new systems and maybe even new customers onto x64 VMS, then Python is a clear winner.
In the end, both are going to be needed but I understand that the primary argument now is to get systems ready for existing users with existing code.
Personally I don't like either one very much and the indentation syntax
in Python drives me insane. Also I think the lack of RDB hooks and general hooks into VMS is a problem for both of them, although a problem that can be remedied in the future with some effort.
In article <uo3eqa$uunb$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2024-01-14, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <uo1co2$ihn3$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
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.
In some security-sensitive environments, such as the environments some
VMS systems are running on, you can't just install a scripting language >>from the Internet that has not been validated by your vendor (ie: VSI).
That may be true, but as you point out, there's Python, and
besides, I wasn't talking only about VMS: that's a strawman
Berry inserted. He appears to want to pick a fight about
something I didn't say. Oh well.
In some security-sensitive environments, such as the environments some
VMS systems are running on, you can't just install a scripting language
from the Internet that has not been validated by your vendor (ie: VSI).
On 2024-01-15, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <uo3eqa$uunb$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2024-01-14, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <uo1co2$ihn3$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
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.
In some security-sensitive environments, such as the environments some >>>VMS systems are running on, you can't just install a scripting language >>>from the Internet that has not been validated by your vendor (ie: VSI).
That may be true, but as you point out, there's Python, and
besides, I wasn't talking only about VMS: that's a strawman
Berry inserted. He appears to want to pick a fight about
something I didn't say. Oh well.
Sorry Dan, I guess I was too subtle.
Python is not currently available for x86-64 VMS, but there's an
opinion (which I share), that, instead of Perl, it would have been
far better for VSI to do the work needed to make it available, and
ship it as part of the base installation so that you could rely on
it being available on a site.
It has been available on VMS in the past as a third-party port, and
it was very popular with those who could run third-party software on
their systems.
I know that Craig is very fond of Perl, but IMHO, the way forward
is Python, not Perl. I was a Perl user at one time, but it must be
at least 15 years since I have touched it. Other alternatives have
taken over from the position Perl once held.
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
I know that Craig is very fond of Perl, but IMHO, the way forward
is Python, not Perl. I was a Perl user at one time, but it must be
at least 15 years since I have touched it. Other alternatives have
taken over from the position Perl once held.
There is far more new development being done in Python. But, there is far more existing code on VMS systems in Perl. If the goal is to get x64 VMS
up to the point of being able to move existing VMS users onto it, then Perl is a clear winner. If the goal is to get new systems and maybe even new customers onto x64 VMS, then Python is a clear winner.
In the end, both are going to be needed but I understand that the primary argument now is to get systems ready for existing users with existing code.
Personally I don't like either one very much and the indentation syntax
in Python drives me insane.
Also I think the lack of RDB hooks and general
hooks into VMS is a problem for both of them, although a problem that can be remedied in the future with some effort.
On 1/15/24 12:50 PM, Scott Dorsey wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
I know that Craig is very fond of Perl, but IMHO, the way forward
is Python, not Perl. I was a Perl user at one time, but it must be
at least 15 years since I have touched it. Other alternatives have
taken over from the position Perl once held.
There is far more new development being done in Python. But, there is
far
more existing code on VMS systems in Perl. If the goal is to get x64 VMS >> up to the point of being able to move existing VMS users onto it, then
Perl
is a clear winner. If the goal is to get new systems and maybe even new
customers onto x64 VMS, then Python is a clear winner.
In the end, both are going to be needed but I understand that the primary
argument now is to get systems ready for existing users with existing
code.
Yep, both are essential, and Python has clearly won in the marketplace
so it's an important path to the future. It wouldn't hurt to have a
Unix shell always available too just because of how many people are
already familiar with them. I guess that couldn't be bash given the GPL.
I was traumatized in my youth by some whitespace in column 72 of a
Fortran program that prevented it from compiling ...
On Mon, 15 Jan 2024 20:09:12 -0600, Craig A. Berry wrote:
I was traumatized in my youth by some whitespace in column 72 of a
Fortran program that prevented it from compiling ...
I wonder how that worked, given that Fortran was one language that would happily *ignore* whitespace in the middle of identifiers and syntax words.
On Mon, 15 Jan 2024 14:17:46 -0000 (UTC), Simon Clubley wrote:
In some security-sensitive environments, such as the environments some
VMS systems are running on, you can't just install a scripting language
from the Internet that has not been validated by your vendor (ie: VSI).
I don?t understand this. Corporate machines are supposed to be locked down for security, yet they let some third party (VSI, Microsoft, whoever)
control what does and doesn?t go on their machines? Surely they would want
to be the ones with that control. Aren?t these proprietary platforms
supposed to give them that control?
On 2024-01-14, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <uo1co2$ihn3$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
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.
In some security-sensitive environments, such as the environments some
VMS systems are running on, you can't just install a scripting language
from the Internet that has not been validated by your vendor (ie: VSI).
If the vendor screws up, you can
hold them accountable and your contract with them requires the vendor to
fix any faulty software.
On Tue, 16 Jan 2024 13:20:32 -0000 (UTC), Simon Clubley wrote:
If the vendor screws up, you can
hold them accountable and your contract with them requires the vendor to
fix any faulty software.
When was the last time Microsoft (or VSI, for that matter) was
successfully sued over the quality of its software?
On 1/10/2024 6:54 PM, Lawrence D'Oliveiro wrote:
There are some documents about [ZGRASS] at Bitsavers.
Well, as long as we're bringing up non-standard BASICs. How about
BASIC09.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 406 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 101:14:17 |
| Calls: | 8,521 |
| Files: | 13,209 |
| Messages: | 5,921,929 |