Please don't remove VMS, I am so happy that I can use Perl on VMS platforms. Last week, following a change in architecture, I rewrote a 1400+ DCL (equivalent of shell scripting under VMS) program into a 25 lines Perl program. It took me a few hours (I know, a few hours for a 25-line program might seem to be inefficient, but I had to face some complicated system problems having nothing to do with Perl, and I don't think anyone could have rewritten the DCL in less than several days, perhaps more).
Although I am working mostly under Unix, I have to spend about 25 to 30% of my time on VMS platforms. And, for me, Perl is even more important with VMS than it is under Unix, because VMS, while still being pretty efficient in some respects, does not have sed, awk, cut, find, grep, redirections, pipes (well VMS does have a form of pipe, but much less practical), and so on. And Perl basically gives me a substitute for all or most of these Unix utilities.
| [reply]
[d/l]
[select] |
- I wouldn't remove it.
It would be (have been) a collective decision; had there been any interest.
- I'm not advocating its sudden disappearance from the Perl 5.something line.
Just from the rewrite; had there been any interest.
- Any platform where there were 4 or 5 people prepared to take part in bringing a platform along for the ride, would potentially be supportable.
But they'd have to be active and keep up.
- I would have thought that with Itanium (or whatever other hardware you're running VMS on?) likely to go away in the next couple or three years, you've got greater problems than the lack of VMS support in a non-existent rewrite of Perl.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
I think QNX would be a poor target for removal up front. It's a mostly POSIX-compatible system that runs on modern embedded hardware very well. ( http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html#POSIX ) If your desire is to make Perl more relevant, abandoning a system with decent although small market share on ARM Core and Intel Atom systems is probably not a good way to do that. Should the GNU-userland Linux systems, the BSD systems, OSX, Windows, and maybe Android be higher priority? Sure. But to get to all of those portably gets you a pretty long way toward QNX. If support for it fell off it may not be a catastrophe. Writing it off before any attempt to gauge the work necessary to keep it seems premature.
VMS may not be cutting edge, but it's still used in some important places.
I don't imagine it would be hard with a Windows version and a GNU userland installed on top of their OS to keep the eComStation die-hards interested in maintaining the OS/2 and eComStation portability. It's not a very big community, but it's still fairly active.
I think if you wanted a better list of systems to abandon for being irrelevant you could start with MS-DOS/PC-DOS, AmigaOS, Haiku, Mac OS Classic, and BS2000. I almost included RISC OS. Their community seems pretty headstrong and there's still work going into the OS.
| [reply] |
See points 1 through 3.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
++ and I'd already read that. My point is less that I'd have picked differently and more that how much effort a minor platform takes is perhaps as important as how many users it has.
Starting with a cleaner, simpler, more easily managed core could make managing ports around the edges of the code simpler. Starting with an example POSIX machine (and sticking to mostly POSIX), be that GNU/Linux, FreeBSD, Darwin, or whatever and then adding thin, isolated compatibility layers around the file handling and signals on not-so-POSIX systems goes a long way toward portability. One or two platforms is plenty for a first model, but choosing not to support low-hanging fruit beyond that just because the fruit isn't very popular seems silly. Now, if there's a platform that absolutely nobody will step up to support, that's an issue for that platform.
| [reply] |