[Info-vax] Programming Languages (was: Re: VMS - The new file system. What do we know about it?...)

[Simon Clubley]

On 2016-11-14, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2016-11-14 00:23:14 +0000, Simon Clubley said:
>
>> On a more serious note, I do hope that any new work to VMS is being 
>> done purely in C at a minimum (with maybe even a better higher level 
>> language for the userland code). I think the days of Bliss and 
>> especially Macro-32 are long past for any new code (or at least for any 
>> new source code files added to VMS from now on).
>
> The shift from Macro32 or Bliss to C happened a couple of decades ago, 
> within OpenVMS development.    There was a large project to allow the 
> use of C for system programming, both for use within OpenVMS 
> development and by customers.   That involved removing register-based 
> calls and expunging dependencies on constructs such as co-routines from 
> the external and many of the internal APIs.  Part of that project work 
> included the move from the older VAX-ish "step 1" device drivers to the 
> "step 2" device drivers and interfaces.  This project wasn't in the 
> initial OpenVMS Alpha releases, but was in place and in use starting 
> around OpenVMS V6.1; at the so-called "functional equivalence" release.
>

I knew there was a lot of work done about that time to allow C in the
kernel (I've only ever written VMS device drivers in C) but I had
thought for some reason it was a driver only thing; I didn't realise
it extended to the rest of VMS as well.

> As for ~2021 to ~2026 and the future and as much as I like and use C 
> for system-level development work, it has problems and issues.   
> Locally deprecating specific calls from the standard library is a 
> common start toward more reliable C code is a start, as are knobs such 
> as QUESTCODE.   Tools for scanning C code for errors, vulnerabilities 
> and for dependencies on undefined behavior are increasingly common 
> practice too, both by the original authors of the code involved and 
> also by folks looking for weaknesses in the code.
>

In addition to language specific vulnerabilities, there are also the
vulnerabilities or issues which are independent of implementation
language such as missing logic checks or things the developer simply
didn't think to check for as well as trusting external data too much.

> Accordingly, I'd be looking past C for system-level work.   Probably 
> not to C++, though there are large system-level and application 
> projects using (usually a subset of) C++ for development.   Definitely 
> not to BASIC, Fortran or such, though those are fine choices for 
> various applications.   Quite probably toward Rust for wholesale 
> rewrites or wholly new system-level work, though that'd be a major 
> shift for VSI and for OpenVMS end-users that might follow, and there 
> are trade-offs there, too.  Rust avoids various of the worst of the 
> holes within C, and Rust code is intended to interoperate with C 
> libraries and frameworks.   There are some definite downsides to 
> choosing Rust, not the least of which are its recent advent (such 
> newness being major-scary for many organizations using OpenVMS), and 
> that Rust isn't presently available on OpenVMS.   I would also look at 
> Rust for application-level work, though there are other languages I'd 
> consider there and that might be better choices than Rust and that are 
> better choices than C, C++, BASIC and such.
>

The major problem with Rust is that it tends to make Perl code look
readable by comparison.

It's designers have forgotten that you write the code once, but read
it many times - they have embarked on a minimalistic keyboard typing
language style which would probably make a TECO advocate proud...

BTW, have the Rust developers stopped making incompatible changes to
newer versions of the language/APIs yet ?

It's not the fact Rust is new which is the major concern for me; it's
the above two issues which are the problems for me.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world