EiffelStudio is an Integrated Development Environment (IDE), that enable programmers to produce correct, reliable, maintainable software and
control the development process. If you want to create fast, robust,
scalable applications, then EiffelStudio gives you a cost-effective
option.
Wouldn't it be lovely, if the modern Eiffel OO programming language
and IDE, under active development, were to come back the VMS fold?
It is just that logical and easy!
https://www.eiffel.com/eiffelstudio/system-requirements/
If my failing memory serves me, they dropped formal support for VMS
about a decade ago, but references to VMS are all through their
documents.
VAX/VMS, AXP/VMS, could be easily resurrected, and VSI/VMS support
easily implemented...
I fear that Team Eiffel don't even know that VSI exists, or that VMS
has a future.
Perhaps the Eiffel Team could be invited, or sponsored, to present at
the VSI boot camp in Malmo, Sweden, in may 2025?
There are other languages where work
could have a bigger positive impact on VMS. Improving PHP port,
port .NET and C#, port Go etc..
On 3/22/2025 9:47 PM, Arne Vajhøj wrote:
There are other languages where work
could have a bigger positive impact on VMS. Improving PHP port,
port .NET and C#, port Go etc..
Rust?
Wouldn't it be lovely, if the modern Eiffel OO programming languageDear Subcommandante,
and IDE, under active development, were to come back the VMS fold?
But how to make that happen?
https://www.eiffel.com/
EiffelStudio
A cost-effective way to develop quality applications
EiffelStudio is an Integrated Development Environment (IDE), that
enable programmers to produce correct, reliable, maintainable software
and control the development process. If you want to create fast,
robust, scalable applications, then EiffelStudio gives you a
cost-effective option.
Imagine being able to model your system as you think – capturing your requirements and your thought processes with EiffelStudio. When you
are ready to design, you build upon the model you created.
It is just that logical and easy!
https://www.eiffel.com/eiffelstudio/system-requirements/
If my failing memory serves me, they dropped formal support for VMS
about a decade ago, but references to VMS are all through their
documents.
VAX/VMS, AXP/VMS, could be easily resurrected, and VSI/VMS support
easily implemented...
I fear that Team Eiffel don't even know that VSI exists, or that VMS
has a future.
https://www.eiffel.com/resources/faqs/eiffel-language/
https://www.eiffel.com/resources/faqs/eiffel-studio/
https://www.eiffel.org/
Quite a few Swedes there:
https://www.eiffel.com/company/customers/
Perhaps the Eiffel Team could be invited, or sponsored, to present at
the VSI boot camp in Malmo, Sweden, in may 2025?
And given that the language is called Eiffel, perhaps the
VMSgenerations team could weigh in on the merits of bring back Eiffel
to the VMS fold, for the enrichment of the VMS ecosystem?
On 3/22/2025 9:47 PM, Arne Vajhøj wrote:
There are other languages where work
could have a bigger positive impact on VMS. Improving PHP port,
port .NET and C#, port Go etc..
Rust?
We live in a multilingual, multiplatform, multi-build-system world. Nobody >wants a new language or IDE that requires you to conform to its particular >view of how to do things.
Vous savez parler aux français. ("you know how to speak to the French"). Starting tomorrow, we'll be discussing it in the VMSgenerations working group.
For me, Eiffel is a benchmark. A great understanding of the art of programming. This made Eiffel a pioneer of contract programming, for
example. And the oldest book by Bertrand Meyer (the designer of Eiffel)
on introductory computer science (in French, well before object-oriented programming, for his company at the time) is one of the best books of
its kind I've read.
I will do everything I can to follow your excellent suggestion.
Gérard Calliet
On Sun, 23 Mar 2025 10:55:00 +1100, Subcommandante XDelta wrote:
EiffelStudio is an Integrated Development Environment (IDE), that enable
programmers to produce correct, reliable, maintainable software and
control the development process. If you want to create fast, robust,
scalable applications, then EiffelStudio gives you a cost-effective
option.
I’ve lost count of the number of times people have said they have a solution to all the world’s programming problems, just so long as you change your entire process to do things their way.
We live in a multilingual, multiplatform, multi-build-system world. Nobody wants a new language or IDE that requires you to conform to its particular view of how to do things.
On 23/03/2025 12:03 pm, Lawrence D'Oliveiro wrote:
On Sun, 23 Mar 2025 10:55:00 +1100, Subcommandante XDelta wrote:
EiffelStudio is an Integrated Development Environment (IDE), that enable >>> programmers to produce correct, reliable, maintainable software and
control the development process. If you want to create fast, robust,
scalable applications, then EiffelStudio gives you a cost-effective
option.
I’ve lost count of the number of times people have said they have a
solution to all the world’s programming problems, just so long as you
change your entire process to do things their way.
We live in a multilingual, multiplatform, multi-build-system world. Nobody >> wants a new language or IDE that requires you to conform to its particular >> view of how to do things.
Well, VSI, needs to focus on meeting the needs of the rusted on VMS
shops, first off, and primarily.
However, the VMS system needs to be revitalised, and that means
providing certified compilers for modern languages.
Rust is a 110% no brainer.
Not to stray off-topic, but a VSI/ELN RTOS, written in Rust, would be
way cool, and may thrill the industrial process guys in the VMS shops.
Erlang and Elixir would be most attractive as well:
https://www.erlang.org/
https://elixir-lang.org/
Not that I can weigh in with any technical quality, on such matters, the plethora of modern languages puts my head in a spin.
I hark back from a time of blinking lights, piano key consoles, and
false floors, and the likes of Fortran, Algol, Cobol, PL/1, and APL.
Come to think of it, VSI/VMS/APL would be way cool - just because! - Two
Big Kens - Ken Iverson, and Ken Olsen.
However, the VMS system needs to be revitalised, and that means
providing certified compilers for modern languages.
Rust is a 110% no brainer.
Not to stray off-topic, but a VSI/ELN RTOS, written in Rust, would be
way cool, and may thrill the industrial process guys in the VMS shops.
Erlang and Elixir would be most attractive as well:
Is there anything in the VSI licensing that would prevent a community of
VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a community of
VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to. And
they have done so in the past: old versions of GCC C and C++ ran on
VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
and VMS Itanium.
The reason it is not happening is not license restrictions, but
lack of interest (willing to do work type of interest - not
it would be nice if somebody else did the work interest) in
the VMS community.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available
(it is open source) then it would be easier for people to
write or port new compilers using LLVM as backend.
On 3/26/2025 1:09 AM, David Meyer wrote:It's the most important point.
Is there anything in the VSI licensing that would prevent a community of
VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to. And
they have done so in the past: old versions of GCC C and C++ ran on
VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
and VMS Itanium.
The reason it is not happening is not license restrictions, but
lack of interest (willing to do work type of interest - not
it would be nice if somebody else did the work interest) in
the VMS community.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available
(it is open source) then it would be easier for people to
write or port new compilers using LLVM as backend.
Arne
On 23/03/2025 8:20 pm, gcalliet wrote:The term important for me is: new shop. Because you agreee by that on
Vous savez parler aux français. ("you know how to speak to the French").
Starting tomorrow, we'll be discussing it in the VMSgenerations working
group.
For me, Eiffel is a benchmark. A great understanding of the art of
programming. This made Eiffel a pioneer of contract programming, for
example. And the oldest book by Bertrand Meyer (the designer of Eiffel)
on introductory computer science (in French, well before object-oriented
programming, for his company at the time) is one of the best books of
its kind I've read.
I will do everything I can to follow your excellent suggestion.
Gérard Calliet
Alas, non, mon ami, I am but a probationary member of the Academie
Franglais, at best.
I only speak English, well my sincere emulation of such: Emuglish - my grammar and punctuation remains decidedly iffy (never got the hand of possessive apostrophes) - however I still speak fluent DCL - the joys of f$lexical discourse.
VSI has it's rusted on client (and potential clients - The HP holdouts
of yore) customers of 30 years standing or more - however, I don't think
that they have had any new customers, yet, who have decided to bet their businesses, or part of the businesses, on adopting the VSI/VMS platform.
A modern, disciplined, application building, language such as Eiffel,
and the Eiffel studio, might perhaps encourage such a miracle, as a new
shop in the VMS ecosystem.
VSI/VMS + Eiffel - it has great merit.
In article <vs0qdf$1mlt9$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a community of >>> VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to. And
they have done so in the past: old versions of GCC C and C++ ran on
VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
and VMS Itanium.
The reason it is not happening is not license restrictions, but
lack of interest (willing to do work type of interest - not
it would be nice if somebody else did the work interest) in
the VMS community.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available
(it is open source) then it would be easier for people to
write or port new compilers using LLVM as backend.
The official Rust compiler is an interesting case in point, as
it's already built on LLVM. Getting it running on VMS probably
wouldn't be that hard; getting it to output code targetting VMS
is probably harder, but certainly doable.
On 3/26/2025 8:14 AM, Dan Cross wrote:
In article <vs0qdf$1mlt9$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a
community of
VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to. And
they have done so in the past: old versions of GCC C and C++ ran on
VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
and VMS Itanium.
The reason it is not happening is not license restrictions, but
lack of interest (willing to do work type of interest - not
it would be nice if somebody else did the work interest) in
the VMS community.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available
(it is open source) then it would be easier for people to
write or port new compilers using LLVM as backend.
The official Rust compiler is an interesting case in point, as
it's already built on LLVM. Getting it running on VMS probably
wouldn't be that hard; getting it to output code targetting VMS
is probably harder, but certainly doable.
Oversimplified I believe work would be:
"frontend" - should not be VMS specific, but it is written
in Rust so a bootstrapping process is needed - compiler bootstrapping
is a known concept, but still some work
"backend" - LLVM, if VSI release their VMS LLVM changes some integration work, if not a huge porting work
"library" - effort will depend on how much is directly calling the OS (meaning LIB$ or SYS$ calls on VMS) and how much it is utilizing the
C RTL - I don't know that so it can be little or much work
"VMS stuff" - installation script, VMS debugger support,
the equivalent to the C descrip.h, starlet.h and lib$routines.h etc. -
also some work (but when that work start then the goal post
is in sight!)
Certainly doable. It is being done all the time. Similar work has
been done on VMS in the past.
But still let us call it "non trivial".
Le 26/03/2025 à 13:02, Arne Vajhøj a écrit :
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a community of >>> VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to. And
they have done so in the past: old versions of GCC C and C++ ran on
VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
and VMS Itanium.
The reason it is not happening is not license restrictions, but
lack of interest (willing to do work type of interest - not
it would be nice if somebody else did the work interest) in
the VMS community.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available
(it is open source) then it would be easier for people to
write or port new compilers using LLVM as backend.
It's the most important point.
On 3/26/2025 8:14 AM, Dan Cross wrote:
In article <vs0qdf$1mlt9$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a community of >>>> VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to. And
they have done so in the past: old versions of GCC C and C++ ran on
VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
and VMS Itanium.
The reason it is not happening is not license restrictions, but
lack of interest (willing to do work type of interest - not
it would be nice if somebody else did the work interest) in
the VMS community.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available
(it is open source) then it would be easier for people to
write or port new compilers using LLVM as backend.
The official Rust compiler is an interesting case in point, as
it's already built on LLVM. Getting it running on VMS probably
wouldn't be that hard; getting it to output code targetting VMS
is probably harder, but certainly doable.
Oversimplified I believe work would be:
"frontend" - should not be VMS specific, but it is written
in Rust so a bootstrapping process is needed - compiler bootstrapping
is a known concept, but still some work
"backend" - LLVM, if VSI release their VMS LLVM changes some integration >work, if not a huge porting work
"library" - effort will depend on how much is directly calling the OS >(meaning LIB$ or SYS$ calls on VMS) and how much it is utilizing the
C RTL - I don't know that so it can be little or much work
"VMS stuff" - installation script, VMS debugger support,
the equivalent to the C descrip.h, starlet.h and lib$routines.h etc. -
also some work (but when that work start then the goal post
is in sight!)
Certainly doable. It is being done all the time. Similar work has
been done on VMS in the past.
But still let us call it "non trivial".
Not to stray off-topic, but a VSI/ELN RTOS, written in Rust, would be
way cool, and may thrill the industrial process guys in the VMS shops.
Erlang and Elixir would be most attractive as well:
https://www.erlang.org/
https://elixir-lang.org/
Not that I can weigh in with any technical quality, on such matters, the plethora of modern languages puts my head in a spin.
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a community of
VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to. And
they have done so in the past: old versions of GCC C and C++ ran on
VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
and VMS Itanium.
The reason it is not happening is not license restrictions, but
lack of interest (willing to do work type of interest - not
it would be nice if somebody else did the work interest) in
the VMS community.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available
(it is open source) then it would be easier for people to
write or port new compilers using LLVM as backend.
On 2025-03-25, Subcommandante XDelta <vlf@star.enet.dec.com> wrote:
Erlang and Elixir would be most attractive as well:
https://www.erlang.org/
https://elixir-lang.org/
Exactly zero paying customers are going to be interested in running
those on VMS.
If VSI didn't even consider it worthwhile to have an Ada compiler for
x86-64 why would anyone be interested in the above options on VMS ?
On 2025-03-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a community of >>> VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to. And
they have done so in the past: old versions of GCC C and C++ ran on
VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
and VMS Itanium.
The reason it is not happening is not license restrictions, but
lack of interest (willing to do work type of interest - not
it would be nice if somebody else did the work interest) in
the VMS community.
In the case of rust there are major technical reasons. See below.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available
(it is open source) then it would be easier for people to
write or port new compilers using LLVM as backend.
Would any rust toolkit version even build with the version of LLVM
that VSI use ?
This posting claims LLVM version 17 is a minimum for the current version
of rust:
https://users.rust-lang.org/t/does-anyone-know-the-lowest-version-of-llvm-that-rust18-can-use/120096
How far back would you have to go before you find a rust version that
would build with the LLVM version VSI have currently ported ?
So when Intel & AMD
release AVX-8192 in 2034, then LLVM add support for that,
VSI grab the latest LLVM and the VMS compilers support it.
It has to happen.
On 2025-03-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
So when Intel & AMD
release AVX-8192 in 2034, then LLVM add support for that,
VSI grab the latest LLVM and the VMS compilers support it.
It has to happen.
What makes you think Intel or AMD will even be relevant in 9 years time ?
9 years is a very long time in this technology world.
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available (it is open source) then it would be easier for people to write or port new
compilers using LLVM as backend.
On Wed, 26 Mar 2025 08:02:56 -0400, Arne Vajhøj wrote:
The specific discussion was about the LLVM compiler backend,
that VSI use for their compilers. If VSI made that available (it is open
source) then it would be easier for people to write or port new
compilers using LLVM as backend.
A key point about LLVM (and the reason why Apple, for example, has
embraced it and gone away from GCC) is that it is not copyleft. So
companies can use it and adapt it and redistribute it, with no obligation
to open any source. They are free to take without giving back.
On 2025-03-25, Subcommandante XDelta <vlf@star.enet.dec.com> wrote::
Erlang and Elixir would be most attractive as well:
https://www.erlang.org/
https://elixir-lang.org/
Exactly zero paying customers are going to be interested in running
those on VMS.
If VSI didn't even consider it worthwhile to have an Ada compiler for
x86-64 why would anyone be interested in the above options on VMS ?
We are arguing that it would be good business for VSI to release their changes.
On 2025-03-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
So when Intel & AMD
release AVX-8192 in 2034, then LLVM add support for that,
VSI grab the latest LLVM and the VMS compilers support it.
It has to happen.
What makes you think Intel or AMD will even be relevant in 9 years
time ? 9 years is a very long time in this technology world.
Given current trends the major processor of the day may very well be
a revolutionary European or Chinese design, given that the US is no
longer investing in its long-term future or developing engineers and scientists for that future.
Oh, and before you outright dismiss that idea, don't forget that
a British CPU design is at the centre of pretty much every smartphone
on the market because the US had nothing that could even come close
to matching that British design.
Simon.
The source for the French GNAT for VMS Itanium are here:
 https://github.com/AdaLabs/gnat-vms
Anyone could try make it work on VMS x86-64 (and maybe start
upgrading as it is based on GCC 4.7).
Arne
On 27/03/2025 5:51 am, Simon Clubley wrote:
If VSI didn't even consider it worthwhile to have an Ada compiler for
x86-64 why would anyone be interested in the above options on VMS ?
Yes, it's a pity, that ADA didn't make the first cut, defense shops with
deep pockets might be disappointed.
Ada has a lot of good features.
Top performing Arm CPUs are designed in USA.
1. Cupertino, California (Apple)
2. Raleigh, North Carolina (Qualcomm)
3. Austin, Texas (Arm Inc)
On Wed, 26 Mar 2025 18:43:36 -0400, Arne Vajhøj wrote:
Ada has a lot of good features.
There’s a project called “SPARK†which is putting together a more verifiable subset of Ada, with the aim of eventually including the
whole language.
On 3/26/2025 7:55 PM, Lawrence D'Oliveiro wrote:
On Wed, 26 Mar 2025 18:43:36 -0400, Arne Vajhøj wrote:
Ada has a lot of good features.
There’s a project called “SPARK†which is putting together a more
verifiable subset of Ada, with the aim of eventually including the
whole language.
I have no experience with Spark, but my understanding is that it is
a subset of Ada with added contracts for verification.
But even "plain" Ada is very good.
Question: can one call a language where lower and upper bounds
of integer types are given by CPU architecture and not by
the problem domain for type safe?
If the answer is no, then that eliminates a lot of languages.
On 27/03/2025 9:43 am, Arne Vajhøj wrote:Hello,
:
The source for the French GNAT for VMS Itanium are here:
 https://github.com/AdaLabs/gnat-vms
Anyone could try make it work on VMS x86-64 (and maybe start
upgrading as it is based on GCC 4.7).
Arne
Gerard gets around!
On Wed, 26 Mar 2025 23:45:54 +0200, Michael S wrote:
Top performing Arm CPUs are designed in USA.
1. Cupertino, California (Apple)
2. Raleigh, North Carolina (Qualcomm)
3. Austin, Texas (Arm Inc)
All outclassed by Fujitsu’s A64FX, as used in the Fugaku machine, and successors -- designed in Japan.
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a community of
VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to.
On 3/26/2025 5:05 PM, Subcommandante XDelta wrote:
On 27/03/2025 5:51 am, Simon Clubley wrote:
If VSI didn't even consider it worthwhile to have an Ada compiler for
x86-64 why would anyone be interested in the above options on VMS ?
Yes, it's a pity, that ADA didn't make the first cut, defense shops with
deep pockets might be disappointed.
Sadly, defense shops with deep pockets gave up on VMS a long time
ago and I see no reason they might consider coming back.
On 3/26/25 7:02 AM, Arne Vajhøj wrote:
On 3/26/2025 1:09 AM, David Meyer wrote:
Is there anything in the VSI licensing that would prevent a community of >>> VMS and Rust (for example) fans from developing a VMS port of a Rust
compiler and releasing the compiler as open source?
No.
VMS users can write or port all the compilers they want to.
One of the following things would have to happen for that to be true:
- VSI produces and makes available an LLVM developer kit
- VSI pushes back upstream everything people would need to develop
compilers with LLVM
- People create their own port of LLVM for VMS
As of today, the only way to get LLVM on VMS is to get a compiler
produced by VSI, and those compilers are not going to be
redistributable. I think VSI has expressed an intention to push their
changes back upstream but that hasn't happened yet and they have a
mountain of work to do to get there.
On Wed, 26 Mar 2025 23:53:14 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 26 Mar 2025 23:45:54 +0200, Michael S wrote:
Top performing Arm CPUs are designed in USA.
1. Cupertino, California (Apple)
2. Raleigh, North Carolina (Qualcomm)
3. Austin, Texas (Arm Inc)
All outclassed by Fujitsu’s A64FX, as used in the Fugaku machine, and
successors -- designed in Japan.
That's very OT in comp.os.vms, but I'd write it anyway. A64FX did not outclass any of mentioned above.
A64FX is good chips for its intended applications, i.e. massively
parallel supercomputers. Its most important feature is Tofu comm links
that together with Tofu switches allow high-bandwidth communication
between tens of thousands of nodes with the latency that is not exactly
low, but can be called acceptable. It's second important feature is
built-in connection to HBM2 memory. Its third important feature is
rather good floating-point throughput when the application amenable to vectorizing. Its fourth important feature is that said good throughput
is achieved without consuming too much power.
VMS usage within DoD has plummeted similar to most other markets.
... but if DoD want a system to track paperclips
usage, then they will do the same as BigBizInc.
The VMS community's interest in taking on open source work is
notoriously low.
Wouldn't it be lovely, if the modern Eiffel OO programming languageLots of interesting discussions but I'll reply here.
and IDE, under active development, were to come back the VMS fold?
But how to make that happen?
https://www.eiffel.com/
EiffelStudio
A cost-effective way to develop quality applications
EiffelStudio is an Integrated Development Environment (IDE), that
enable programmers to produce correct, reliable, maintainable software
and control the development process. If you want to create fast,
robust, scalable applications, then EiffelStudio gives you a
cost-effective option.
Imagine being able to model your system as you think – capturing your requirements and your thought processes with EiffelStudio. When you
are ready to design, you build upon the model you created.
It is just that logical and easy!
https://www.eiffel.com/eiffelstudio/system-requirements/
If my failing memory serves me, they dropped formal support for VMS
about a decade ago, but references to VMS are all through their
documents.
VAX/VMS, AXP/VMS, could be easily resurrected, and VSI/VMS support
easily implemented...
I fear that Team Eiffel don't even know that VSI exists, or that VMS
has a future.
https://www.eiffel.com/resources/faqs/eiffel-language/
https://www.eiffel.com/resources/faqs/eiffel-studio/
https://www.eiffel.org/
Quite a few Swedes there:
https://www.eiffel.com/company/customers/
Perhaps the Eiffel Team could be invited, or sponsored, to present at
the VSI boot camp in Malmo, Sweden, in may 2025?
And given that the language is called Eiffel, perhaps the
VMSgenerations team could weigh in on the merits of bring back Eiffel
to the VMS fold, for the enrichment of the VMS ecosystem?
On Thu, 27 Mar 2025 15:27:01 -0400, Arne Vajhøj wrote:
VMS usage within DoD has plummeted similar to most other markets.
If VMS on x86 could have come out a few years earlier, it would likely
have kept more customers.
On Thu, 27 Mar 2025 15:27:01 -0400, Arne Vajhøj wrote:
... but if DoD want a system to track paperclips
usage, then they will do the same as BigBizInc.
PHP? NodeJS?
I really like Eiffel. Actually one of the languages that influenced
the Extended Pascal standard was Eiffel. Of course, you can see how
well that crushed in the market. C++26's contracts finally gets to
something that Eiffel did from the beginning.
I see Eiffel allows multiple inheritance <https://www.eiffel.org/doc/eiffel/I2E-_Inheritance>, but I haven’t yet found any details of the method resolution order. Python does C3 linearization (invented by the Dylan folks), but as I recall both C++ and Eiffel date from before that was invented.
I actually contacted one of the Rust folks a few years back but haven't
kept up the connection.
I really like Eiffel. Actually one of the languages that influenced the >Extended Pascal standard was Eiffel. Of course, you can see how well
that crushed in the market. C++26's contracts finally gets to something
that Eiffel did from the beginning.
As I mentioned in another post, I do want to provide the LLVM libs for >OpenVMS either thru the actual LLVM repo or with something on the side.
Having help for Rust (or other languages) once we have the libraries in >place, would be great. I'm all for that. I just have to convince VSI
mgmt to do that. Anybody want to approach them (Rust or one of their
users)?
C3 can be quite confusing.
I am pretty sure very few would have guessed the output from this
one:
On 3/26/2025 9:17 PM, bill wrote:
On 3/26/2025 5:05 PM, Subcommandante XDelta wrote:
On 27/03/2025 5:51 am, Simon Clubley wrote:
If VSI didn't even consider it worthwhile to have an Ada compiler for
x86-64 why would anyone be interested in the above options on VMS ?
Yes, it's a pity, that ADA didn't make the first cut, defense shops with >>> deep pockets might be disappointed.
Sadly, defense shops with deep pockets gave up on VMS a long time
ago and I see no reason they might consider coming back.
VMS usage within DoD has plummeted similar to most other
markets.
But my understanding is that so has Ada usage - DoD are
going with more standard solutions when possible. So some
of the code for the new F-47 may be written in Ada, but
if DoD want a system to track paperclips usage, then they
will do the same as BigBizInc.
But even "plain" Ada is very good.
Question: can one call a language where lower and upper bounds
of integer types are given by CPU architecture and not by
the problem domain for type safe?
If the answer is no, then that eliminates a lot of languages.
or:
- people use a different backend than LLVM (GCC, custom, whatever)
As for the programming language, the code is probably going to be written
in Orange (which will be the bestest programming language ever :-) )
Simon.
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
The market for super optimizing compiler backends for x86-64 seems to be becoming a duopoly.
In article <de6f4fa6d5594b31aed18a7ab508e091dc86a4f3@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
I actually contacted one of the Rust folks a few years back but haven't
kept up the connection.
I really like Eiffel. Actually one of the languages that influenced the
Extended Pascal standard was Eiffel. Of course, you can see how well
that crushed in the market. C++26's contracts finally gets to something
that Eiffel did from the beginning.
As I mentioned in another post, I do want to provide the LLVM libs for
OpenVMS either thru the actual LLVM repo or with something on the side.
Having help for Rust (or other languages) once we have the libraries in
place, would be great. I'm all for that. I just have to convince VSI
mgmt to do that. Anybody want to approach them (Rust or one of their
users)?
Rust isn't a monolith, but I can ask through a back channel if
anyone from the community may be interested in helping with a
VMS port. I don't know if the requisite mixture of interest,
time, and VMS expertise and access is readily available, though.
- Dan C.
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
Simon.
PS: And no Bill, the Amsterdam Compiler Kit does not apply. :-)
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 3/26/2025 9:17 PM, bill wrote:
On 3/26/2025 5:05 PM, Subcommandante XDelta wrote:
On 27/03/2025 5:51 am, Simon Clubley wrote:
If VSI didn't even consider it worthwhile to have an Ada compiler for >>>>> x86-64 why would anyone be interested in the above options on VMS ?
Yes, it's a pity, that ADA didn't make the first cut, defense shops with >>>> deep pockets might be disappointed.
Sadly, defense shops with deep pockets gave up on VMS a long time
ago and I see no reason they might consider coming back.
VMS usage within DoD has plummeted similar to most other
markets.
But my understanding is that so has Ada usage - DoD are
going with more standard solutions when possible. So some
of the code for the new F-47 may be written in Ada, but
if DoD want a system to track paperclips usage, then they
will do the same as BigBizInc.
A few years ago, would that have been called the F-45 ?
As for the programming language, the code is probably going to be written
in Orange (which will be the bestest programming language ever :-) )
Simon.
On 28/03/2025 19:08, Simon Clubley wrote:
As for the programming language, the code is probably going to be written
in Orange (which will be the bestest programming language ever :-) )
Simon.
Can anything Orange be good? ;)
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
Simon.
PS: And no Bill, the Amsterdam Compiler Kit does not apply. :-)
On 29/03/2025 18:19, Waldek Hebisch wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
Simon.
PS: And no Bill, the Amsterdam Compiler Kit does not apply. :-)
Depends what you consider serious (and what "backend" means).
There is bunch of compilers that use their own backend,
for example optimized Ocaml or SBCL Lisp. If you aim at
highest possible speed, regardless of language, then they
can not compete. If you look at native performance for
relevant languages, then they are top performers (there are
Lisp compilers which generate code via translation to C,
resulting speed is lower than obtained using SBCL).
Note that context was porting languages, "classic"
languages are covered by VSI, so relevant things are
backends for more exotic languages. There was recent
trend to adopt LLVM in such cases, and Julia seem to
be prominent example of language dependent on LLVM.
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
Isn't that what GNAT does for Ada?
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
Simon.
PS: And no Bill, the Amsterdam Compiler Kit does not apply. :-)
Depends what you consider serious (and what "backend" means).
There is bunch of compilers that use their own backend,
for example optimized Ocaml or SBCL Lisp. If you aim at
highest possible speed, regardless of language, then they
can not compete. If you look at native performance for
relevant languages, then they are top performers (there are
Lisp compilers which generate code via translation to C,
resulting speed is lower than obtained using SBCL).
Note that context was porting languages, "classic"
languages are covered by VSI, so relevant things are
backends for more exotic languages. There was recent
trend to adopt LLVM in such cases, and Julia seem to
be prominent example of language dependent on LLVM.
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
Chris Townley <news@cct-net.co.uk> wrote:
On 29/03/2025 18:19, Waldek Hebisch wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
Simon.
PS: And no Bill, the Amsterdam Compiler Kit does not apply. :-)
Depends what you consider serious (and what "backend" means).
There is bunch of compilers that use their own backend,
for example optimized Ocaml or SBCL Lisp. If you aim at
highest possible speed, regardless of language, then they
can not compete. If you look at native performance for
relevant languages, then they are top performers (there are
Lisp compilers which generate code via translation to C,
resulting speed is lower than obtained using SBCL).
Note that context was porting languages, "classic"
languages are covered by VSI, so relevant things are
backends for more exotic languages. There was recent
trend to adopt LLVM in such cases, and Julia seem to
be prominent example of language dependent on LLVM.
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
Isn't that what GNAT does for Ada?
I am not sure what you wanted to say. GNAT is a native
compiler using GCC backend. There were some talk about
interfacing it to LLVM, but I am not aware of anything
working in this direction. GNAT does _not_ generate
C, it interfaces with the backend using constructs not
available in C.
On 29/03/2025 18:19, Waldek Hebisch wrote:
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
Isn't that what GNAT does for Ada?
It did originally not sure about later versions, But then, isn't
that pretty much how a lot of the early free compilers worked?
F2C, P2C?
On 29/03/2025 18:19, Waldek Hebisch wrote:
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
Isn't that what GNAT does for Ada?
On 29/03/2025 18:19, Waldek Hebisch wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
[snip]
Note that context was porting languages, "classic"
languages are covered by VSI, so relevant things are
backends for more exotic languages. There was recent
trend to adopt LLVM in such cases, and Julia seem to
be prominent example of language dependent on LLVM.
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
Isn't that what GNAT does for Ada?
On 3/27/2025 11:10 PM, Dan Cross wrote:
In article <de6f4fa6d5594b31aed18a7ab508e091dc86a4f3@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
I actually contacted one of the Rust folks a few years back but haven't
kept up the connection.
I really like Eiffel. Actually one of the languages that influenced the >>> Extended Pascal standard was Eiffel. Of course, you can see how well
that crushed in the market. C++26's contracts finally gets to something >>> that Eiffel did from the beginning.
As I mentioned in another post, I do want to provide the LLVM libs for
OpenVMS either thru the actual LLVM repo or with something on the side.
Having help for Rust (or other languages) once we have the libraries in
place, would be great. I'm all for that. I just have to convince VSI
mgmt to do that. Anybody want to approach them (Rust or one of their
users)?
Rust isn't a monolith, but I can ask through a back channel if
anyone from the community may be interested in helping with a
VMS port. I don't know if the requisite mixture of interest,
time, and VMS expertise and access is readily available, though.
I'll ask around at next month's LLVM Euro conference in Berlin
On 3/29/2025 2:44 PM, Chris Townley wrote:
On 29/03/2025 18:19, Waldek Hebisch wrote:
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
Isn't that what GNAT does for Ada?
GNAT can do a lot of things.
But I believe the "standard" is to generate native
object code.
On 3/29/2025 6:40 PM, bill wrote:
On 29/03/2025 18:19, Waldek Hebisch wrote:
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
Isn't that what GNAT does for Ada?
It did originally not sure about later versions, But then, isn't
that pretty much how a lot of the early free compilers worked?
F2C, P2C?
One of the somewhat more serious compilers generating C is
GnuCOBOL.
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
Depends what you consider serious (and what "backend" means).
There is bunch of compilers that use their own backend,
for example optimized Ocaml or SBCL Lisp. If you aim at
highest possible speed, regardless of language, then they
can not compete. If you look at native performance for
relevant languages, then they are top performers (there are
Lisp compilers which generate code via translation to C,
resulting speed is lower than obtained using SBCL).
Note that context was porting languages, "classic"
languages are covered by VSI, so relevant things are
backends for more exotic languages. There was recent
trend to adopt LLVM in such cases, and Julia seem to
be prominent example of language dependent on LLVM.
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
On 3/29/2025 2:19 PM, Waldek Hebisch wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
Depends what you consider serious (and what "backend" means).
There is bunch of compilers that use their own backend,
for example optimized Ocaml or SBCL Lisp. If you aim at
highest possible speed, regardless of language, then they
can not compete. If you look at native performance for
relevant languages, then they are top performers (there are
Lisp compilers which generate code via translation to C,
resulting speed is lower than obtained using SBCL).
Note that context was porting languages, "classic"
languages are covered by VSI, so relevant things are
backends for more exotic languages. There was recent
trend to adopt LLVM in such cases, and Julia seem to
be prominent example of language dependent on LLVM.
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
For true general purpose languages, then highly
optimizing is a must have.
But for many less general purpose languages then
it is not so important.
The typical business application is not CPU bound.
There are some very widely used languages out
there where most use interpretation despite
JIT compilation being available. Because the speed
difference does not matter for most.
There are also embedded applications where
real time characteristics are essential but
speed does not matter.
If a language is more specialized and targeting
a market where speed is not important, then the
compiler backend does not need to be state of
the art.
Currently free avalability of gcc and clang limits use of other C
compilers.
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 3/29/2025 2:19 PM, Waldek Hebisch wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
Depends what you consider serious (and what "backend" means).
There is bunch of compilers that use their own backend,
for example optimized Ocaml or SBCL Lisp. If you aim at
highest possible speed, regardless of language, then they
can not compete. If you look at native performance for
relevant languages, then they are top performers (there are
Lisp compilers which generate code via translation to C,
resulting speed is lower than obtained using SBCL).
Note that context was porting languages, "classic"
languages are covered by VSI, so relevant things are
backends for more exotic languages. There was recent
trend to adopt LLVM in such cases, and Julia seem to
be prominent example of language dependent on LLVM.
But more popular approach seem to be via custom
backend or via C. For example Haskell folks some time
ago said that LLVM does not really give them advantages
compared to going via C, and C way is easier.
For true general purpose languages, then highly
optimizing is a must have.
I think it is more complicated. In era of commercial C
compilers comparing speed of code generated by two different
compilers one could get factor like 1.5 or even 2. Do
you consider both as highly optimizing? And there were
customers paying for compiler that generated slower code.
Currently free avalability of gcc and clang limits use of
other C compilers. But advantages of other language may
be deemed more important than modest difference in speed.
Also, if you try to mimic style from other language in C
code, you may end up with slower code than using compiler
for other langage: both Ocaml and SBCL Lisp optimize and
optimization have significant effect for idomatic code in
respective languages.
But for many less general purpose languages then
it is not so important.
The typical business application is not CPU bound.
There are some very widely used languages out
there where most use interpretation despite
JIT compilation being available. Because the speed
difference does not matter for most.
There are also embedded applications where
real time characteristics are essential but
speed does not matter.
If a language is more specialized and targeting
a market where speed is not important, then the
compiler backend does not need to be state of
the art.
Ocaml have also interpetive backend, that one is for uses
where speed is not important. Optimized Ocaml and SBCL
are used in situations were speed is important, but
writing program in C would be too expensive.
I'll be in Malmö as a sponsor. Not because I can sell anything, but
because as an example of a very very small company, I have to explain
how some business plan are good for the whole ecosystem, and other less
good. Because I gona be a sponsor, I'l give goodies. In it there will be
an Ada distrib for Itanium.
Gérard Calliet
Might you be wearing a Gaul helmet adorned with wings, per Asterix,
for easy visibility?
On 27/03/2025 7:33 pm, gcalliet wrote:I have to think about it, thanks for the suggestion.
I'll be in Malmö as a sponsor. Not because I can sell anything, but
because as an example of a very very small company, I have to explain
how some business plan are good for the whole ecosystem, and other less
good. Because I gona be a sponsor, I'l give goodies. In it there will be
an Ada distrib for Itanium.
Gérard Calliet
Might you be wearing a Gaul helmet adorned with wings, per Asterix, for
easy visibility?
If you try the Swedish meat-balls, you won't have to prove your courage
in any other way - it's what passes for Sverige haute cuisine - though they're not too shabby with Lingon-berry sauce. :-)
On 28/03/2025 19:08, Simon Clubley wrote:
As for the programming language, the code is probably going to be written
in Orange (which will be the bestest programming language ever :-) )
Can anything Orange be good? ;)
On 3/28/2025 3:15 PM, Simon Clubley wrote:
On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
or:
- people use a different backend than LLVM (GCC, custom, whatever)
If anyone knows of a serious backend code generator other than LLVM
or GCC, please feel free to point me at it. :-)
The market for super optimizing compiler backends for x86-64
seems to be becoming a duopoly.
But if you can live with less optimization and less maturity,
then I believe there are options. Google finds options like
Cranelift and QBE.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 96:46:16 |
| Calls: | 9,503 |
| Calls today: | 2 |
| Files: | 13,627 |
| Messages: | 6,127,574 |