A language that has not received your attention is "REXX", and the reason is probably because you are not IBM Mainframe oriented… ...and/or because of some Microsoft actions in the past, you probably have not been exposed to the language.
While Microsoft did distribute and support REXX under the later releases of DOS and early versions of Windows, a highly confrontational series of conversations between Microsoft and IBM (while the two were working on a joint project involving OS/2) lead to Microsoft eventually removing the REXX language from the Windows operating system distribution. (A classic case of “If you don’t play by my rules, I’ll take my marbles and go home...”)
I have been told, that part of the reason for the removal, is that Microsoft wanted to make syntactical changes to the REXX language and IBM would not allow it, because it would have affected the ability of REXX to operate under a variety of different Operating System Environments, and would also affect its ability to be used as an application scripting language while also being used as an Operating System scripting language.
I have personally been using the language since the late 1980’s, and have found it’s capabilities more than adequate for the development of application systems (including the modeling of proposed designs), and for System Level utilities – not to mention it’s original design concept of being an interactive operating system scripting language (i.e. A command line “shell” processing language).
REXX was adopted by IBM to be its standardized scripting language across all of its computing platforms, (and there are many more than you can imagine!) and as a result, REXX has replaced many other operating system specific languages – end result, due to the standardization, programmers can create scripts that will run on multiple platforms “without having to make local changes” first.
There have been a number of implementations of the REXX Language ranging from the larger IBM mainframe systems (System/360, System/370, System/390, and the current System Z hardware running operating systems like: VM, MVS, OS/390, Z/OS, Z/VM, etc ) to IBM mid-range systems like the AS-400 and OS-2, and many non-IBM systems like Linux, FreeBSD, Solaris, AIX, HP-UX, DOS, Windows/2k/XP/Vista/7/8/8.1/10, MacOS X, Amiga, eCS, AROS, QNX4.x, QNX6.x, BeOS, EPOC32, AtheOS, OpenVMS, SkyOS, OpenEdition. and a host of others.
For the most part you will find two potential variations of REXX, (1) a flavor of REXX which supports the original “Classic” REXX syntax and (2) a second flavor that supports a more Object Oriented variation of REXX. You will also find versions of REXX which have been enhanced to
support specialized areas like Music and sound processing.
In the “Classic” arena you will find the IBM versions of REXX as found in the VM/CMS and MVS/TSO, and Z/OS/TSO environments. One of the first implementations of REXX outside the IBM universe was Charles Manfield’s Personal Rexx and also his KEDIT text editor that used REXX as an internal macro language. Quercus Systems produced a Terminal program that used REXX as it’s internal Macro language. Many other commercial and freeware products have also incorporated REXX as their internal Macro Language.
The 1996 American National Standard (ANSI Standard) for Rexx is called "Programming Language - REXX", and its number is X3.274-1996, which basically defines the “classic” or procedural form of the language.
A CLASSIC version of REXX known as REGINA is available on several LINUX distributions, and is downloadable from sourceforge.net Another classic version of REXX is REGINALD by Jeff Glantt
which also supports Windows GUI operations.
In the Object Oriented world, there are also several versions of REXX available. Personally I use ooRexx (downloadable from sourceforge.net) for two reasons: (1) it is fully maintained...
I have used Python, Java, JavaScript, PHP, and C/C++ quite a bit. What follows are my thoughts.
1. There is a general trend towards high-level interpretive languages (Python, JavaScript, PHP, Perl, etc.), and away from compiled languages (Java, C/C++, etc.). The key driver has been and remains the declining cost of hardware. Basically programmers can get a lot more work done, in less time, using interpretive languages. Of course, interpretive languages are massively slower than compiled languages. However, they doesn’t always matter a lot. Say a program would take 4 hours to write in C++, but only one hour in Python. If the Python program runs for 10 seconds on a PC, does it really matter that the C++ program would run in less than one second? Basically, cheap hardware make programmer productivity, the key issue, which favors interpretive languages.
2. These days JavaScript is actually a very good, very powerful language. Perhaps better than Python even. However, JavaScript only really works in a browser. Yes, you can use node.js. However, in my experience node.js is painful at best. For better or worse, the link between the browser and JavaScript remains firmly intact. The reverse is also true, running Python in a browser is painful at best.
3. PHP is also a rather good language these days. However, it tends to be viewed as a website tool and not as a general purpose programming language. That might not be fair, but appears to be true. PHP also suffers from a few quirks (all those dollar signs).
4. The Python 2->3 transition was hard for many folks (not me, I started with Python 3). However, it is mostly over by now. The transition did bring one rather large benefit. Python 3 fully supports Unicode. The same can not be said for a rather long list of languages.
5. As the author pointed out, Ruby has always been handicapped by its origins in Japan. That may not be fair. However, it still appears to be true.
6. Perl is just a relic from the past. Essentially nobody takes it seriously these days.
What this amounts to is that Python is the “last man standing”. Hence, the rising popularity of Python (outside of the browser).
Hello Peter, Gregory (author) here, thank you for your comment! I agree with all your points, especially the first one - I think there's no way to reverse this trend. Lower level languages will always have some share of the market, but it will shrink over time.
What I'm not sure about is why other languages did not leverage the issue with Python's migration - because that migration took really a decade, during which time Ruby became very popular thanks to Rails, and JavaScript evolved to a really solid language. Yet neither of them became popular outside of webdev. It seems that a lot of people were really attached to Python and decided that it was more beneficial to stay as long as possible on Python 2.7 and later migrate than to pick another language.
4 comments
[ 4.3 ms ] story [ 21.9 ms ] threadA language that has not received your attention is "REXX", and the reason is probably because you are not IBM Mainframe oriented… ...and/or because of some Microsoft actions in the past, you probably have not been exposed to the language.
While Microsoft did distribute and support REXX under the later releases of DOS and early versions of Windows, a highly confrontational series of conversations between Microsoft and IBM (while the two were working on a joint project involving OS/2) lead to Microsoft eventually removing the REXX language from the Windows operating system distribution. (A classic case of “If you don’t play by my rules, I’ll take my marbles and go home...”)
I have been told, that part of the reason for the removal, is that Microsoft wanted to make syntactical changes to the REXX language and IBM would not allow it, because it would have affected the ability of REXX to operate under a variety of different Operating System Environments, and would also affect its ability to be used as an application scripting language while also being used as an Operating System scripting language.
I have personally been using the language since the late 1980’s, and have found it’s capabilities more than adequate for the development of application systems (including the modeling of proposed designs), and for System Level utilities – not to mention it’s original design concept of being an interactive operating system scripting language (i.e. A command line “shell” processing language).
REXX was adopted by IBM to be its standardized scripting language across all of its computing platforms, (and there are many more than you can imagine!) and as a result, REXX has replaced many other operating system specific languages – end result, due to the standardization, programmers can create scripts that will run on multiple platforms “without having to make local changes” first.
There have been a number of implementations of the REXX Language ranging from the larger IBM mainframe systems (System/360, System/370, System/390, and the current System Z hardware running operating systems like: VM, MVS, OS/390, Z/OS, Z/VM, etc ) to IBM mid-range systems like the AS-400 and OS-2, and many non-IBM systems like Linux, FreeBSD, Solaris, AIX, HP-UX, DOS, Windows/2k/XP/Vista/7/8/8.1/10, MacOS X, Amiga, eCS, AROS, QNX4.x, QNX6.x, BeOS, EPOC32, AtheOS, OpenVMS, SkyOS, OpenEdition. and a host of others.
For the most part you will find two potential variations of REXX, (1) a flavor of REXX which supports the original “Classic” REXX syntax and (2) a second flavor that supports a more Object Oriented variation of REXX. You will also find versions of REXX which have been enhanced to support specialized areas like Music and sound processing.
In the “Classic” arena you will find the IBM versions of REXX as found in the VM/CMS and MVS/TSO, and Z/OS/TSO environments. One of the first implementations of REXX outside the IBM universe was Charles Manfield’s Personal Rexx and also his KEDIT text editor that used REXX as an internal macro language. Quercus Systems produced a Terminal program that used REXX as it’s internal Macro language. Many other commercial and freeware products have also incorporated REXX as their internal Macro Language.
The 1996 American National Standard (ANSI Standard) for Rexx is called "Programming Language - REXX", and its number is X3.274-1996, which basically defines the “classic” or procedural form of the language.
A CLASSIC version of REXX known as REGINA is available on several LINUX distributions, and is downloadable from sourceforge.net Another classic version of REXX is REGINALD by Jeff Glantt which also supports Windows GUI operations.
In the Object Oriented world, there are also several versions of REXX available. Personally I use ooRexx (downloadable from sourceforge.net) for two reasons: (1) it is fully maintained...
I have used Python, Java, JavaScript, PHP, and C/C++ quite a bit. What follows are my thoughts.
1. There is a general trend towards high-level interpretive languages (Python, JavaScript, PHP, Perl, etc.), and away from compiled languages (Java, C/C++, etc.). The key driver has been and remains the declining cost of hardware. Basically programmers can get a lot more work done, in less time, using interpretive languages. Of course, interpretive languages are massively slower than compiled languages. However, they doesn’t always matter a lot. Say a program would take 4 hours to write in C++, but only one hour in Python. If the Python program runs for 10 seconds on a PC, does it really matter that the C++ program would run in less than one second? Basically, cheap hardware make programmer productivity, the key issue, which favors interpretive languages.
2. These days JavaScript is actually a very good, very powerful language. Perhaps better than Python even. However, JavaScript only really works in a browser. Yes, you can use node.js. However, in my experience node.js is painful at best. For better or worse, the link between the browser and JavaScript remains firmly intact. The reverse is also true, running Python in a browser is painful at best.
3. PHP is also a rather good language these days. However, it tends to be viewed as a website tool and not as a general purpose programming language. That might not be fair, but appears to be true. PHP also suffers from a few quirks (all those dollar signs).
4. The Python 2->3 transition was hard for many folks (not me, I started with Python 3). However, it is mostly over by now. The transition did bring one rather large benefit. Python 3 fully supports Unicode. The same can not be said for a rather long list of languages.
5. As the author pointed out, Ruby has always been handicapped by its origins in Japan. That may not be fair. However, it still appears to be true.
6. Perl is just a relic from the past. Essentially nobody takes it seriously these days.
What this amounts to is that Python is the “last man standing”. Hence, the rising popularity of Python (outside of the browser).
What I'm not sure about is why other languages did not leverage the issue with Python's migration - because that migration took really a decade, during which time Ruby became very popular thanks to Rails, and JavaScript evolved to a really solid language. Yet neither of them became popular outside of webdev. It seems that a lot of people were really attached to Python and decided that it was more beneficial to stay as long as possible on Python 2.7 and later migrate than to pick another language.