Better languages than BASIC

[Simon Clubley]

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?

There are multiple languages that have left BASIC in the dust.

If you want an initial teaching language, Python is _absolutely_ the
language you start people off with these days. BASIC is absolutely
dead here, and for very good reason.

If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

If you want to write modern-day CUSPs, then either C or C++.

If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.

There are other areas that BASIC was never suitable for, such as
number crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from
something like Python. There are also higher-level languages such as
MATLAB or Octave that can be used here as well.

BTW, Octave is available here if you want to look:

https://octave.org/

Simon.

[Lawrence D'Oliveiro]

If you want to write business applications, then either Java or a subset
of C++. C++ subset to be chosen based on programmer skillsets and the
problem to be solved.

Kotlin is an open-source alternative to Java that does not have Oracle’s
rapacious fingers all over it. Google has been adopting it for Android
development, for example.

If you want to write modern-day CUSPs, then either C or C++.
If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.

Rust is gaining some popularity for this. The Linux kernel is putting in
place infrastructure for writing device drivers in Rust, and there is some
intention to go beyond this in future.

There are other areas that BASIC was never suitable for, such as number
crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from
something like Python.

Python is very heavily used for professional-quality data analysis
nowadays, with toolkits like NumPy, SciPy, Pandas, Matplotlib and Jupyter.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

If you want to write business applications, then either Java or a subset
of C++. C++ subset to be chosen based on programmer skillsets and the
problem to be solved.

Kotlin is an open-source alternative to Java that does not have Oracle’s
rapacious fingers all over it. Google has been adopting it for Android
development, for example.

Both Kotlin and the common implementation of Java are open source.

Kotlin is Kotlin project and JetBrains. Java is JCP and Oracle.

No big difference.

The big difference is that Kotlin started without the backwards
compatibility requirements of Java, which enabled them to do a lot
of things better.

As I like to word it: Kotlin is how Java would look like, if
Java had been designed 20 years later than it was.

Arne

PS: And Kotlin does run on VMS !!!!

[Arne Vajhøj]

Post by Simon Clubley

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?

There are multiple languages that have left BASIC in the dust.

There are a lot more languages today than 40 years ago.

And VMS Basic has not evolved with the rest of the IT world.

But VB.NET is reasonable uptodate.

Post by Simon Clubley
If you want an initial teaching language, Python is _absolutely_ the
language you start people off with these days. BASIC is absolutely
dead here, and for very good reason.

I think last time Basic was hot for teaching was around when I was
in 1st grade.

Python, Java, C# or JavaScript depending on where and what.

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

This is a very crowded market today. There are so many options.

C++.

JVM language - Java or one of the other like Scala, Kotlin or Groovy. I
believe Groovy would be a good choice for Basic people.

.NET language - C#, VB.NET or F#. VB.NET is definitely not in fashion,
but it still exist.

Python. Yes business applications do get done in Python some time.

PHP. Many dislike PHP, but it is widely used.

JavaScript/TypeScript. Ditto.

And then there are all the not really intended for this market but
chosen anyway choices: C, Rust, Go.

Post by Simon Clubley
If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.

Ada is not so hot anymore. I believe a lot of that stuff are in C or
C++ today. One can argue that Ada is a lot better, but that does
not change reality.

Post by Simon Clubley
There are other areas that BASIC was never suitable for, such as
number crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from
something like Python. There are also higher-level languages such as
MATLAB or Octave that can be used here as well.

And R.

But Python is king in that market today.

The analysis logic is in Python. The matrix math is done
in modules in Fortran or C. The data is moved around in Java.

Arne

[Single Stage to Orbit]

Post by Arne Vajhøj
But VB.NET is reasonable uptodate.

Oh yes, it does work, that's for sure. But new things are now only
going in for C#.

[Chris Townley]

Post by Single Stage to Orbit

Post by Arne Vajhøj
But VB.NET is reasonable uptodate.

Oh yes, it does work, that's for sure. But new things are now only
going in for C#.

I thought new things went into the .net bit, and then could be called by
any of the languages

[Arne Vajhøj]

Post by Chris Townley

Post by Single Stage to Orbit

Post by Arne Vajhøj
But VB.NET is reasonable uptodate.

Oh yes, it does work, that's for sure. But new things are now only
going in for C#.

I thought new things went into the .net bit, and then could be called by
any of the languages

All libraries: yes.

But obviously not language syntax.

Arne

[Arne Vajhøj]

Post by Single Stage to Orbit

Post by Arne Vajhøj
But VB.NET is reasonable uptodate.

Oh yes, it does work, that's for sure. But new things are now only
going in for C#.

VB.NET got almost all the major stuff.

It is missing some of the latest C# language features, but most
of those are more cute than useful.

Arne

[Single Stage to Orbit]

Post by Arne Vajhøj

Post by Single Stage to Orbit
Oh yes, it does work, that's for sure. But new things are now only
going in for C#.

VB.NET got almost all the major stuff.
It is missing some of the latest C# language features, but most
of those are more cute than useful.

It's a good thing they got llambdas into VB. These are bloody useful.

[bill]

Post by Simon Clubley

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?

There are multiple languages that have left BASIC in the dust.
If you want an initial teaching language, Python is _absolutely_ the
language you start people off with these days. BASIC is absolutely
dead here, and for very good reason.

Other than high schools and a few community colleges BASIC saw very
little use for real teaching in the CS/CIS world. And just in case
your curious, I just had a short conversation with a very experienced
CS professor I used to work with and he commented on the unsuitability
of Python for teaching programming even though it has become the
standard.

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

bill

[Lawrence D'Oliveiro]

Post by bill

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.

[Chris Townley]

Post by Lawrence D'Oliveiro

Post by bill

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.

It wasn't difficulty to interface DEC Basic to a DB. Late in our systems
life, I had to interface it with interface traffic from Oracle on HP
Unix, and send it it an Oracle DB running on Linux

[Lawrence D'Oliveiro]

Post by Chris Townley
It wasn't difficulty to interface DEC Basic to a DB.

One thing all versions of BASIC had was decent string handling ... for its
day.

[bill]

Post by Chris Townley

Post by Lawrence D'Oliveiro

Post by bill

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.

It wasn't difficulty to interface DEC Basic to a DB. Late in our systems
life, I had to interface it with interface traffic from Oracle on HP
Unix, and send it it an Oracle DB running on Linux

It isn't difficult for COBOL either. I did it on mainframes back
in 1980 and I can do it with ease today using GnuCOBOL and Postgres.
And string handling is every bit as good as any other language.
Unless, of course, your idea of COBOL is the 1974 standard.

bill

[Lawrence D'Oliveiro]

Post by bill
And string handling is every bit as good as any other language.

Here, in Python, is the kind of dynamically-varying filter criteria I
did for a search function in one application. Note the inclusion of
field match checks only for fields where the user entered something:

conditions = \
(
list
( # free-text fields
"%(name)s like %(value)s"
%
{
"name" : field[0],
"value" :
sql_string("%" + escape_sql_wild(params.getvalue(field[1])) + "%"),
}
for field in
(
("make", "search_make"),
("model", "search_model"),
("details", "search_details"),
... etc ...
)
if params.getvalue(field[1]) != ""
)
+
list
( # date fields
"("
+
" or ".join
(
"%(name)s %(op)s %(value)s"
%
{
"name" : field[0],
"op" : op[0],
"value" : sql_string(params.getvalue(field[1])),
}
for op in
(
("<", "lt"),
("=", "eq"),
(">", "gt"),
)
if get_checkbox("%(name)s[%(op)s]" % {"name" : field[1], "op" : op[1]})
)
+
")"
for field in
(
("when_purchased", "search_when_purchased"),
("warranty_expiry", "search_warranty_expiry"),
)
if reduce
(
operator.__or__,
(
get_checkbox("%(name)s[%(op)s]" % {"name" : field[1], "op" : op})
for op in ("lt", "eq", "gt")
)
)
)
)

Expanding the list of conditions into the SQL query:

found_items = get_records \
(
table_name = "items",
fields =
(
"make", "model", "details", ... etc ...
),
condition = " and ".join(conditions),
extra = "order by make, model, inventory_nr"
)

Have you ever managed anything similar in COBOL?

[Simon Clubley]

Post by Lawrence D'Oliveiro

Post by bill
And string handling is every bit as good as any other language.

Here, in Python, is the kind of dynamically-varying filter criteria I
did for a search function in one application. Note the inclusion of

[Snip example]

Post by Lawrence D'Oliveiro
Have you ever managed anything similar in COBOL?

For security reasons, I would have preferred to see that as a
prepared statement instead of as a concatenated SQL statement.

Simon.

[Dan Cross]

Post by Simon Clubley

Post by Lawrence D'Oliveiro

Post by bill
And string handling is every bit as good as any other language.

Here, in Python, is the kind of dynamically-varying filter criteria I
did for a search function in one application. Note the inclusion of

[Snip example]

Post by Lawrence D'Oliveiro
Have you ever managed anything similar in COBOL?

For security reasons, I would have preferred to see that as a
prepared statement instead of as a concatenated SQL statement.

Please don't feed the troll.

- Dan C.

[Lawrence D'Oliveiro]

For security reasons, I would have preferred to see that as a prepared
statement instead of as a concatenated SQL statement.

Feel free to show us how you would write it as same. Can your prepared-
statement system cope with variable numbers of fields? Variable field
names? Variable operator selections? All these were present in the
example.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

For security reasons, I would have preferred to see that as a prepared
statement instead of as a concatenated SQL statement.

Feel free to show us how you would write it as same. Can your prepared-
statement system cope with variable numbers of fields? Variable field
names? Variable operator selections? All these were present in the
example.

I have _never_ had the need to do that. In the real world, you know what
data you want to read or update, and with what selection criteria, at the
point you write such code.

Typical criteria are static.

But if if one need dynamic criteria then there are also ways.

The COALESCE trick is quite common.

But as a fallback then it is still possible to build a
SQL string with placeholder markers dynamically, prepare
that and specify parameters.

The extendable string template mechanism added
to Java in version 21 (preview) can be used pretty
nifty.

Code snippet:

private static void test(Connection con, String f2) throws
SQLException {
PreparedStatementFormatter pstmtfmt = new
PreparedStatementFormatter(con);
try(PreparedStatement pstmt = pstmtfmt."SELECT COUNT(*) FROM t1
WHERE f2 = \{f2}") {
try(ResultSet rs = pstmt.executeQuery()) {
rs.next();
System.out.println(rs.getInt(1));
}
}
}

Arne

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro

For security reasons, I would have preferred to see that as a prepared
statement instead of as a concatenated SQL statement.

Feel free to show us how you would write it as same. Can your prepared-
statement system cope with variable numbers of fields? Variable field
names? Variable operator selections? All these were present in the
example.

I have _never_ had the need to do that.

That was a real-world example. You must never have had the need to create
interactive query functions, then. That’s not the only example of that
kind of code I have written for clients. Did you note the ability to
choose what kind of comparison (less than, equals, greater than) to
perform against date fields? Try doing that with your “prepared
statements”.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by bill

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.

Dynamically generating SQL strings is actually a big no no.

That is the road to poor performance and big security holes.

Traditional Cobol embedded SQL does much better than that.

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by bill

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.

Dynamically generating SQL strings is actually a big no no.
That is the road to poor performance and big security holes.
Traditional Cobol embedded SQL does much better than that.
Arne

SQL is nice. It works. But, I consider it a square hole, and you better not
have a round peg.

For some operations, one must go through rather convoluted things to get the
desired result.

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by bill

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.

Dynamically generating SQL strings is actually a big no no.
That is the road to poor performance and big security holes.
Traditional Cobol embedded SQL does much better than that.

SQL is nice.  It works.  But, I consider it a square hole, and you
better not have a round peg.
For some operations, one must go through rather convoluted things to get
the desired result.

SQL as a language is a bit quirky.

But its support across databases, support i libraries,
available skills and flexibility makes it "the" database
thing.

The modern solution is an ORM where the the developer does
not write the SQL manually but it gets generated by a library, so the
developer can focus on an object model.

Arne

[Lawrence D'Oliveiro]

Post by Dave Froble
SQL is nice. It works. But, I consider it a square hole, and you
better not have a round peg.
For some operations, one must go through rather convoluted things to get
the desired result.

Would some other language make things easier? Is this your idea of
“rather convoluted things”? It can display entries for all clients or
just a single specified client, and it can display only charged
entries, only uncharged entries, or both:

for entry in get_each_record \
(
table_name =
"clients inner join jobs on clients.client_id = jobs.client_id"
" inner join hours on jobs.job_id = hours.job_id",
fields =
[
"clients.client_id as client_id",
"jobs.job_id as job_id",
"clients.name as client_name",
"jobs.description as description",
"hours.from_time as from_time",
"hours.to_time as to_time",
"hours.notes as notes",
],
condition =
" and ".join
(
(
lambda : (),
lambda : ("clients.client_id = %u" % only_client,),
)[only_client != None]()
+
(
lambda : (),
lambda :
(
"hours.invoice_entry_id %s null"
%
(
"is",
"is not",
)[charged],
),
)[charged != None]()
+
(
"hours.from_time >= %u" % day_local_start(when_worked),
"hours.from_time < %u" % day_local_start(when_worked + 1),
"hours.to_time is not null",
)
),
extra = "order by hours.from_time, clients.name, jobs.description"
) \
:
... process entry ...
#end for

[Jan-Erik Söderholm]

Post by Lawrence D'Oliveiro

Post by bill

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.

Well, that is written by someone without a clue.

Building SQL queries using string operations is a no-no
for any professional database development. It does mean that
the whole SQL syntax check and compilation has to be done by
the run time environment. And if some parameter changes (like
an order number), the whole query is concidered to be "new" and
the full syntax check and compilation is done again each time.

In VMS, and using Rdb, this is called "Dynamic SQL" and is never
used for VMS based applications. There is a network interface
(SQL/Services) that receives dynamic SQL statements (usually)
comming from PC sources over some ODBC link. But other client
API libraries exist, even one native for VMS.

For applications developed on, and running on, VMS there are two
main options:

Embedded SQL.
Supported by most common languages. When building an application here,
a pre-compiler is first run. That one extracts all SQL statements and
compiles the SQL into object/machine code. When the main compiler is
then run, this object code is automaticaly included in the main object
file.

SQL Modular Language.
This is a bit similar to Embedded SQL, but the SQL code is kept in
a separate file by itself. And the SQLMOD compiler only reads this
file and creates a stand-alone object file. This object file is then
just included in the build of the main application. The main application
just calls some functions with any name (like "GetOrder") and it
(the main code) has no idea that there is any SQL or database or how
that order data is fetched. So it can be used from any compiled language
no matter if that specific language have any specific SQL support.

For Cobol both these options exists. They can be mixed anyway in the same
application, if needed. We had some common queries (like "FetchOrder") as
SQLMOD files and then added the specific application queries into the
application code as Embedded SQL for easier maintenance of the code.

So, the bottom line is, that there is absolutely no need for any
string operations to use SQL from Cobol applications.

And, as Arne also mentioned, there is a huge security issue with
bulding SQL queries using string operations, if you include any
dynamic parameters into that.

If you need to use dynamically built SQL queries, at least use what
is commonly called "parameter markers", where the main SQL code and
the values of any parameters are separated from each other. That way
you cannot include any non-wanted SQL code in the actual values of
the paramaters.

Jan-Erik.

[Arne Vajhøj]

Post by Jan-Erik Söderholm

Post by Lawrence D'Oliveiro

Post by bill

Post by Simon Clubley
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.

Or COBOL which was actually designed for the task.

Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.

Well, that is written by someone without a clue.
Building SQL queries using string operations is a no-no
for any professional database development.

Yes.

Post by Jan-Erik Söderholm
It does mean that
the whole SQL syntax check and compilation has to be done by
the run time environment. And if some parameter changes (like
an order number), the whole query is concidered to be "new" and
the full syntax check and compilation is done again each time.

And besides that there is the potential for SQL injection.

Post by Jan-Erik Söderholm
For applications developed on, and running on, VMS there are two
Embedded SQL.
Supported by most common languages. When building an application here,
a pre-compiler is first run. That one extracts all SQL statements and
compiles the SQL into object/machine code. When the main compiler is
then run, this object code is automaticaly included in the main object
file.
SQL Modular Language.
This is a bit similar to Embedded SQL, but the SQL code is kept in
a separate file by itself. And the SQLMOD compiler only reads this
file and creates a stand-alone object file. This object file is then
just included in the build of the main application. The main application
just calls some functions with any name (like "GetOrder") and it
(the main code) has no idea that there is any SQL or database or how
that order data is fetched. So it can be used from any compiled language
no matter if that specific language have any specific SQL support.

Embedded SQL is not bad. Not at all.

The biggest problem is the support for it.

Not that many databases comes with SQL precompilers today.

And if they do then the number of languages supported are often
limited. Rdb has great language support. But most other databases
only support Cobol and C.

I have a list of supported combinations on VMS in:
https://www.vajhoej.dk/arne/articles/vmsdbx.html#embsql
(scroll down a few pages until the "Support" section)

SQL modules are even more rare.

Post by Jan-Erik Söderholm
For Cobol both these options exists. They can be mixed anyway in the same
application, if needed. We had some common queries (like "FetchOrder") as
SQLMOD files and then added the specific application queries into the
application code as Embedded SQL for easier maintenance of the code.
So, the bottom line is, that there is absolutely no need for any
string operations to use SQL from Cobol applications.

Not for the common cases. In the rare cases people work around
it with coalesce trick or other.

Post by Jan-Erik Söderholm
And, as Arne also mentioned, there is a huge security issue with
bulding SQL queries using string operations, if you include any
dynamic parameters into that.

Yes.

Post by Jan-Erik Söderholm
If you need to use dynamically built SQL queries, at least use what
is commonly called "parameter markers", where the main SQL code and
the values of any parameters are separated from each other. That way
you cannot include any non-wanted SQL code in the actual values of
the paramaters.

Yes.

And practically all database API's support it today. I can only
remember two that did not - the old MySQL pre-4.1 C API and the
old Sybase DB API - both from the 90's.

Arne

[Marc Van Dyck]

Post by Simon Clubley

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?

There are multiple languages that have left BASIC in the dust.
If you want an initial teaching language, Python is _absolutely_ the
language you start people off with these days. BASIC is absolutely
dead here, and for very good reason.
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
If you want to write modern-day CUSPs, then either C or C++.
If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.
There are other areas that BASIC was never suitable for, such as
number crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from
something like Python. There are also higher-level languages such as
MATLAB or Octave that can be used here as well.
https://octave.org/
Simon.

Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of
momentum
and never was a big success outside of the academic field, which used
to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?

I'm still doing all my programming in Pascal... Now that I'm retired,
no
one else at my former work uses it anymore. They keep a one user
license
to maintain my code, if it is ever needed. But I'm afraid this compiler
will feel very lonely...

[Arne Vajhøj]

Post by Marc Van Dyck
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of momentum
and never was a big success outside of the academic field, which used to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?
I'm still doing all my programming in Pascal... Now that I'm retired, no
one else at my former work uses it anymore. They keep a one user license
to maintain my code, if it is ever needed. But I'm afraid this compiler
will feel very lonely...

There are VMS Pascal applications out there. Pascal question
do come up here and at the VSI forum.

In many ways Pascal is in the same boat as Basic.

VMS Pascal was a great language in the 80's.

It never got extended with as much stuff as some other
Pascal dialects (object-Pascal, Delphi etc.).

But it could!

Pascal and Basic seems to be the most promising languages
for modernization if VSI want to do anything with native
languages besides C++.

Arne

[Simon Clubley]

Post by Marc Van Dyck
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of
momentum
and never was a big success outside of the academic field, which used
to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?

Pascal is a dead language for most new development. Unfortunately.

VSI released the compilers in order of customer usage and there is still
a large base of existing Pascal source code that needs to be able to
run on x86-64 VMS.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Marc Van Dyck
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of
momentum
and never was a big success outside of the academic field, which used
to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?

Pascal is a dead language for most new development. Unfortunately.

Yes.

Delphi usage has declined for many year.

Post by Simon Clubley
VSI released the compilers in order of customer usage and there is still
a large base of existing Pascal source code that needs to be able to
run on x86-64 VMS.

VMS Pascal compatible with VMS Pascal 10-20-30-40 years ago
is a must for VSI.

But trying to modernize VMS Pascal by adding new features
seems like an interesting possibility to me!

Arne

[John Reagan]

Post by Marc Van Dyck

Post by Simon Clubley

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?

There are multiple languages that have left BASIC in the dust.
If you want an initial teaching language, Python is _absolutely_ the
language you start people off with these days. BASIC is absolutely
dead here, and for very good reason.
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
If you want to write modern-day CUSPs, then either C or C++.
If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.
There are other areas that BASIC was never suitable for, such as
number crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from
something like Python. There are also higher-level languages such as
MATLAB or Octave that can be used here as well.
https://octave.org/
Simon.

Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of momentum
and never was a big success outside of the academic field, which used to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?
I'm still doing all my programming in Pascal... Now that I'm retired, no
one else at my former work uses it anymore. They keep a one user license
to maintain my code, if it is ever needed. But I'm afraid this compiler
will feel very lonely...

I wrote a lengthy reply to this to answer your (and others) questions.
I don't see it online however. If it doesn't show up at some point,
I'll dig it out of some sent folder and resend.

John

[John Reagan]

I wrote a lengthy reply to this to answer your (and others) questions. I
don't see it online however.  If it doesn't show up at some point,
I'll dig it out of some sent folder and resend.

2nd attempt:

- There are MANY customer applications written in VMS Pascal with
many of them in the millions of lines. Still an important legacy
language. Just like we aren't forgetting BASIC.

- Why so "early"? Partly that I know the compiler and RTL's build
system, test system, configuration scripts, etc. It was "easy" and it
didn't use any really sketchy coding practices (BASIC compiler, I'm
looking at you). I'll give credit to several former developers
(including myself). As a piece of trivia, the Pascal RTL was originally
developed by "Mr Fortran", Steve Lionel.

- VMS Pascal has many of the features from the Extended Pascal standard
from the late 1980s (that's where all the things like schema types came
from). Several of the features in EP came from Digital with slightly
different syntax (direct file access for example). Borland did
participate on the X3J9 committee but was more concerned with low level
concepts like wanting to "standardize" PEEK and POKE and ignored the
rest.

- There was an Object-Oriented Addendum to the Extended Pascal standard.
Pretty much matched the C++ of the day along with a little Oberon mixed
in for fun.

I think that the Prospero (now defunct) Extended Pascal compiler
actually implemented it
http://www.edm2.com/index.php/Prospero_Software

- I don't see the need to add OO to VMS Pascal. There are several other
languages to choose from these days. We have added a feature or two
over the years based on customer requests (the last "big" feature was
my addition of the SELECT/SELECTONE statements patterned after the
BLISS equivalents). With all the discussions around what it means to be
a 64-bit program, perhaps I should get the compiler to be more flexible
with its handling of 32-bit vs 64-bit descriptor forms.

- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the
release notes that have never made it to the manual. [I've been doing
lots of doc review lately.]

[Arne Vajhøj]

Post by John Reagan
- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the
release notes that have never made it to the manual.  [I've been doing
lots of doc review lately.]

Can you reveal anything about how far out Basic for VMS x86-64 is?

1 day? 1 week? 1 month? 1 quarter?

Arne

[Robert A. Brooks]

Post by Arne Vajhøj

Post by John Reagan
- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the
release notes that have never made it to the manual.  [I've been doing
lots of doc review lately.]

Can you reveal anything about how far out Basic for VMS x86-64 is?
1 day? 1 week? 1 month? 1 quarter?

Closer to 1 quarter than one month.

[Robert A. Brooks]

Post by Robert A. Brooks

Post by Arne Vajhøj

Post by John Reagan
- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the
release notes that have never made it to the manual.  [I've been doing
lots of doc review lately.]

Can you reveal anything about how far out Basic for VMS x86-64 is?
1 day? 1 week? 1 month? 1 quarter?

Closer to 1 quarter than one month.

Oh Goody! Will it come with LSE?

They are unrelated.

LSE still has some issues with exception handling. The problems are
somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.

It's on my to-do list, but it's not at the top right now, although
it's close.

[Chris Townley]

Post by Robert A. Brooks

Post by Robert A. Brooks

Post by Arne Vajhøj

Post by John Reagan
- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the
release notes that have never made it to the manual.  [I've been doing
lots of doc review lately.]

Can you reveal anything about how far out Basic for VMS x86-64 is?
1 day? 1 week? 1 month? 1 quarter?

Closer to 1 quarter than one month.

Oh Goody! Will it come with LSE?

They are unrelated.
LSE still has some issues with exception handling.  The problems are
somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.
It's on my to-do list, but it's not at the top right now, although
it's close.

Thanks, I will await it

[Robert A. Brooks]

Post by Robert A. Brooks
LSE still has some issues with exception handling.  The problems are
somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.
It's on my to-do list, but it's not at the top right now, although
it's close.

Oh, if we speak about DECset, what about the other products ? PCA being
essentially an alternate debugger, it might cause some issues too,
right ?

PCA will be a bit of a challenge, unrelated to LSE.

[Arne Vajhøj]

- I don't see the need to add OO to VMS Pascal.  There are several other
languages to choose from these days.  We have added a feature or two
over the years based on customer requests (the last "big" feature was
my addition of the SELECT/SELECTONE statements patterned after the
BLISS equivalents).  With all the discussions around what it means to be
a 64-bit program, perhaps I should get the compiler to be more flexible
with its handling of 32-bit vs 64-bit descriptor forms.

Right now the goal of VSI must be to get all the existing
VMS customer to port their existing applications to VMS x86-64.

But what is the plan when that is done?

(not urgent because it will take years)

What will new business applications for VMS be written in?

(we are hoping for such!)

Obviously all the non-native languages (Java, Python, PHP etc. - I
still recommend Groovy!) are going to grab the majority.

But for those wanting native code (and quite some will due
to need to link with old legacy code) will C++ really be
the only choice?

I would hate to see that.

I would love to see VMS Pascal and VMS Basic being beefed up
with OO, generic and maybe a drizzle of functional.

Arne

[John Reagan]

Post by Arne Vajhøj

- I don't see the need to add OO to VMS Pascal.  There are several other
languages to choose from these days.  We have added a feature or two
over the years based on customer requests (the last "big" feature was
my addition of the SELECT/SELECTONE statements patterned after the
BLISS equivalents).  With all the discussions around what it means to be
a 64-bit program, perhaps I should get the compiler to be more flexible
with its handling of 32-bit vs 64-bit descriptor forms.

Right now the goal of VSI must be to get all the existing
VMS customer to port their existing applications to VMS x86-64.
But what is the plan when that is done?
(not urgent because it will take years)
What will new business applications for VMS be written in?
(we are hoping for such!)

Beats me, ask the people who want to write those business applications.
I just make the "hammers", I don't know if you'll use it to build a
house or break a window.

Post by Arne Vajhøj
Obviously all the non-native languages (Java, Python, PHP etc. - I
still recommend Groovy!) are going to grab the majority.
But for those wanting native code (and quite some will due
to need to link with old legacy code) will C++ really be
the only choice?

I don't understand your use of "native"? All of the compilers
generate real instructions and are not interpreted. Did you
forgot to say OO?

Post by Arne Vajhøj
I would hate to see that.
I would love to see VMS Pascal and VMS Basic being beefed up
with OO, generic and maybe a drizzle of functional.

Implementing an OO model is quite involved. The OO Pascal
addendum to the standard was limited (no multiple inheritance,
just "mixins") but would still be a beast to implement fully.

It isn't something we can hack over a weekend. People who want
such features will need to write that on the back of a large
stack of $100 bills and send that to VSI.

Post by Arne Vajhøj
Arne

[Arne Vajhøj]

Post by Arne Vajhøj
Obviously all the non-native languages (Java, Python, PHP etc. - I
still recommend Groovy!) are going to grab the majority.
But for those wanting native code (and quite some will due
to need to link with old legacy code) will C++ really be
the only choice?

I don't understand your use of "native"?  All of the compilers
generate real instructions and are not interpreted.  Did you
forgot to say OO?

With native I mean traditional EXE.

Yes - there were an implicit "with modern features:
object oriented, generic and functional".

Post by Arne Vajhøj
I would hate to see that.
I would love to see VMS Pascal and VMS Basic being beefed up
with OO, generic and maybe a drizzle of functional.

Implementing an OO model is quite involved.  The OO Pascal
addendum to the standard was limited (no multiple inheritance,
just "mixins") but would still be a beast to implement fully.
It isn't something we can hack over a weekend.  People who want
such features will need to write that on the back of a large
stack of $100 bills and send that to VSI.

I know it is a big task.

But when the number of bug reports starts descending towards zero
and LLVM team releases new C/C++ and Fortran compilers and no Cobol
developers want OO, then what are you going to spend time on?

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by John Reagan

Post by Arne Vajhøj
Obviously all the non-native languages (Java, Python, PHP etc. - I
still recommend Groovy!) are going to grab the majority.
But for those wanting native code (and quite some will due
to need to link with old legacy code) will C++ really be
the only choice?

I don't understand your use of "native"? All of the compilers
generate real instructions and are not interpreted. Did you
forgot to say OO?

With native I mean traditional EXE.
object oriented, generic and functional".

Post by John Reagan

Post by Arne Vajhøj
I would hate to see that.
I would love to see VMS Pascal and VMS Basic being beefed up
with OO, generic and maybe a drizzle of functional.

Implementing an OO model is quite involved. The OO Pascal
addendum to the standard was limited (no multiple inheritance,
just "mixins") but would still be a beast to implement fully.
It isn't something we can hack over a weekend. People who want
such features will need to write that on the back of a large
stack of $100 bills and send that to VSI.

I know it is a big task.

You forgot to ask how big of a stack ...

:-)

I'm guessing the top of the stack might lack enough oxygen ...

Post by Arne Vajhøj
But when the number of bug reports starts descending towards zero
and LLVM team releases new C/C++ and Fortran compilers and no Cobol
developers want OO, then what are you going to spend time on?
Arne

[Dave Froble]

Post by Marc Van Dyck
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of momentum
and never was a big success outside of the academic field, which used to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?

You finally figured it out.

:-)

Pascal is John's baby, and if you have John running the compiler people, you
will always have Pascal. If you don't have John running things, you might be sorry.

:-)

[Lawrence D'Oliveiro]

Post by Marc Van Dyck
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore.

Standard Pascal was little more than a toy, useful for teaching but not a
lot more.

To make it useful you needed some serious extensions. But that’s where
things diverged. Look at VAX Pascal (v2 or later) and you see things like
external symbols, structure layout control and arguments by keyword, which
made it great for system programming on VMS.

Outside the DEC world, there was UCSD Pascal, with an entirely different
(and incompatible, and less ambitious) set of extensions. That became kind
of a de facto standard in the PC world, with Turbo Pascal copying the same
set of extensions, for example.

One project that still lives on is Free Pascal
<https://www.freepascal.org/>, which aims to be compatible with UCSD/
Turbo.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro
Outside the DEC world, there was UCSD Pascal, with an entirely different
(and incompatible, and less ambitious) set of extensions. That became kind
of a de facto standard in the PC world, with Turbo Pascal copying the same
set of extensions, for example.
One project that still lives on is Free Pascal
<https://www.freepascal.org/>, which aims to be compatible with UCSD/
Turbo.

TurboPascal 5.5 added OOP. FPC aims at being Delphi compatible.

Which means that the main flow of extensions must be:

Apple Object-Pascal -> TP 5.5+ -> Delphi -> FPC

Arne

[smartbuck]

business apps use DIBOL - Synegy DBL ...

[Arne Vajhøj]

Post by smartbuck
business apps use DIBOL - Synegy DBL ...

Business apps on VMS are pretty diverse language wise.

Cobol, Basic, Pascal, Dibol/DBL, PL/I. I suspect even some
Fortran despite the language not being a super obvious
choice for that purpose.

Newer business apps: C. Even newer: C++. Only 20 years
old: maybe Java.

Arne