On 2024-01-11, 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?
>

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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Thu, 11 Jan 2024 18:30:07 -0000 (UTC), Simon Clubley wrote:

> 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.

On 1/11/2024 1:30 PM, Simon Clubley wrote:
> On 2024-01-11, 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?
>
> 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.

> 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.

> 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.

> 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.

> 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

On 1/11/2024 5:22 PM, Lawrence D'Oliveiro wrote:
> On Thu, 11 Jan 2024 18:30:07 -0000 (UTC), Simon Clubley wrote:
>> 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 !!!!

On 1/11/2024 1:30 PM, Simon Clubley wrote:
> On 2024-01-11, 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?
>>
>
> 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.

>
> 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

On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:

> On 1/11/2024 1:30 PM, Simon Clubley wrote:
>
>> 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.

On 12/01/2024 01:56, Lawrence D'Oliveiro wrote:
> On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
>
>> On 1/11/2024 1:30 PM, Simon Clubley wrote:
>>
>>> 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

--
Chris

On Fri, 12 Jan 2024 02:18:36 +0000, Chris Townley wrote:

> 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.

On 1/11/2024 9:18 PM, Chris Townley wrote:
> On 12/01/2024 01:56, Lawrence D'Oliveiro wrote:
>> On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
>>
>>> On 1/11/2024 1:30 PM, Simon Clubley wrote:
>>>
>>>> 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

On Thu, 11 Jan 2024 22:38:55 -0500, bill wrote:

> 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 formulated on Thursday :
> On 2024-01-11, 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?
>>
>
> 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.

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...

--
Marc Van Dyck

On 1/11/2024 8:56 PM, Lawrence D'Oliveiro wrote:
> On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
>> On 1/11/2024 1:30 PM, Simon Clubley wrote:
>>> 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

On 1/12/2024 6:15 AM, Marc Van Dyck wrote:
> 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

Den 2024-01-12 kl. 02:56, skrev Lawrence D'Oliveiro:
> On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
>
>> On 1/11/2024 1:30 PM, Simon Clubley wrote:
>>
>>> 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.

On 2024-01-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 11 Jan 2024 22:38:55 -0500, bill wrote:
>
>> 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:
>

[Snip example]

>
> 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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-12, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>
> 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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/12/2024 8:22 AM, Jan-Erik Söderholm wrote:
> Den 2024-01-12 kl. 02:56, skrev Lawrence D'Oliveiro:
>> On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
>>
>>> On 1/11/2024 1:30 PM, Simon Clubley wrote:
>>>
>>>> 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.

> 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.

> 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.

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.

> 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.

> 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.

> 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

On 1/12/2024 8:45 AM, Simon Clubley wrote:
> On 2024-01-12, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>> 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.

> 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

On Thu, 2024-01-11 at 19:22 -0500, Arne Vajhøj wrote:
>
> 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#.
--
Tactical Nuclear Kittens

On 12/01/2024 13:03, Single Stage to Orbit wrote:
> On Thu, 2024-01-11 at 19:22 -0500, Arne Vajhøj wrote:
>>
>> 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

--
Chris

On 1/12/2024 9:05 AM, Chris Townley wrote:
> On 12/01/2024 13:03, Single Stage to Orbit wrote:
>> On Thu, 2024-01-11 at 19:22 -0500, Arne Vajhøj wrote:
>>>
>>> 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

On 1/12/2024 8:03 AM, Single Stage to Orbit wrote:
> On Thu, 2024-01-11 at 19:22 -0500, Arne Vajhøj wrote:
>>
>> 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

In article <unrf5s$3fiqb$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-01-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 11 Jan 2024 22:38:55 -0500, bill wrote:
>>
>>> 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:
>>
>
>[Snip example]
>
>>
>> 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.

On 1/12/2024 6:15 AM, Marc Van Dyck wrote:
> Simon Clubley formulated on Thursday :
>> On 2024-01-11, 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?
>>>
>>
>> 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.
>
> 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

On Fri, 2024-01-12 at 09:12 -0500, Arne Vajhøj wrote:
> >
> > 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.
--
Tactical Nuclear Kittens