[Info-vax] Viable versus ideal programming languages

[Dan Cross]

In article <t1d53c$ges$1 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-03-21, Bill Gunshannon <bill.gunshannon at gmail.com> wrote:
>> On 3/21/22 14:46, Simon Clubley wrote:
>>> 
>>> I would say that C is a _viable_ programming language in that case,
>>> but I would not say that it is an _ideal_ programming language.
>>> 
>>> You may end up using something that is viable but is not your preferred
>>> language. This could be due to language availability across multiple
>>> environments, the ability of the language to be easily called from
>>> other languages, etc.
>>> 
>>> This is especially important when you are writing library code for
>>> example. Consider that I can write a portable library in C, and I can
>>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>>> the library is small enough.
>>> 
>>> I can then easily call that C library from a wide range of languages
>>> running on those multiple operating systems and environments. The language
>>> also allows me to create code that runs both in kernel mode and user mode.
>>> 
>>> Name one other programming language that allows me to do all that.
>>
>> What does any of that have to do with the language?  The specific
>> compiler maybe, but not necessarily the language.  I could see
>> not doing it in COBOL and probably LISP but otherwise, most languages
>> can do what you want.
>>
>
>Fine. Where do I find the compilers in today's world that allow me
>to do all of the above in a language other than C ? :-)

I do pretty much everything listed here in Rust on a daily
basis.

>BTW, you are not going to be writing kernel mode device drivers or
>kernel modules in Fortran (for example).

Hmm, I seem to recall that much of JNet was written in FORTRAN.
On several systems, it was extended enough to be a viable
language for low-level work.

>BTW #2, you can only easily call C++ code from a non-C++ program by
>providing a C interface in the C++ library so you are back to using
>C as an interface language even with C++...

That's not precisely true; you're using an ABI that the C
compiler targets, but that's qualitatively different than using
the C language.  For example, in Rust, I can define structures
that use the layout of the system's native ABI, or functions
that use the ABI's calling convention, etc.  In my work, that
usually implies calling between Rust and primitives written in
assembly, but not C.  In some sense, the connection with C is
incidental, though admittedly many such ABIs were designed as a
target for C primarily.

>Would be nice if that was not the only viable option, but the problem
>is that C is a very viable language in all of these cases, even when
>it is not an ideal language, so no-one has developed a viable alternative
>over the decades.

It's true that e.g. Rust isn't presently as popular as C, but as
an alternative, it's pretty viable.

	- Dan C.