Ilya Dudkin at Skywell Software has a story
Top 7 Dying Programming Languages to Avoid Studying in 2019 –2020.
Each language gets a paragraph's treatment as to why he thinks these languages are dead or dying. Those languages are:
Do you agree with his assessment? Are there any other language(s) you would add to the list?
(Score: 2) by JoeMerchant on Wednesday March 11 2020, @11:14PM (13 children)
I have found that most of the obscure scripting languages (like SquirrelScript) were basically "doing Python" before Python got popular, and they were a bit ahead of Python in this area or that for a while, but the snake has pretty well squeezed the scripting world to where it is the weapon of choice, if you need that sort of thing.
I recently ported a (Qt) C++ app to Python (PyQt) - and I was pretty happy with the initial results, calling cookie cutter library functions Python was only about 4% slower than C++, but, when I got to the meat of what I really wanted to do (pixel by pixel manipulations in LOTS of images), Python just fell on its face, taking over 2000x longer to process than C++.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 5, Insightful) by Unixnut on Thursday March 12 2020, @12:09AM (12 children)
There is no one language "to rule them all". They all have pros and con's, which is why I tend to try to use whichever one I have in my toolbox that best fits the use case.
I would write image manipulation in C for performance, even if the rest of the program is Python (it is nice you can drop into C from python when you need to, although its a bit clunky). Likewise I would not write a quick script to parse out and batch rename some files in C.
Generally what I have done when writing image processing systems, is first write the whole thing in Python, even if the compute intensive bits are 2000x slower, you have a proof of concept that provides the correct result, and a reference program to compare optimisations (or C rewrites) against.
I switch between Bash/Perl/Python/C depending on needs, and (so far) those are the only ones I have needed in my toolbox, between them they cover everything I need to do well enough to get the job done in a sensible way.
Python has strength in its libraries, especially things like its ZeroMQ bindings (PyZMQ) , which I use to split tasks across machines (sometimes that is faster than the programming effort needed to rewrite in C for more performance), numpy, and the fact is is used more and more in data science/modelling and statistical analysis.
Saying that, I use Perl to pre-process the (generally messy) data sources into one consistent format for the Python analysis to do its thing, and in some cases the data is initially fetched with a bash wrapper around Curl. A lovely thing about Unix is the fact you easily string together programs on the command line, allowing me to use the right tool, written in the right language, for each stage of the work.
(Score: 3, Funny) by Arik on Thursday March 12 2020, @01:37AM (10 children)
"There is no one language "to rule them all"."
Yes. Yes there is. It's binary*.
Anything else you do has to be machine-translated, in one way or another, into binary. Therefore that is the veritable one language to rule them all.
*It's generally easier to think of it as hex, but they map 1:1 unless you're on exotic hardware.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @05:09AM
Wrong! Specs are no less important than machine code implementing them, and their native tongue is not binary.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @07:32AM (2 children)
I'm so old, I remember why most of the RFCs specify data transfer in octets instead of bytes or another unit because they were different sizes on different machines. And "nybble" has a "y" in it, heretics!
(Score: 2) by turgid on Thursday March 12 2020, @10:18AM (1 child)
EBCDIC.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Friday March 13 2020, @06:31AM
That comment divides all Soylentils into two categories. 1) Those who think you are old because they know what that comment is referencing. 2) Those who think you are old because you had a stroke when writing that comment.
(Score: 2) by maxwell demon on Thursday March 12 2020, @08:31AM (4 children)
Binary is not a language. Maybe you are thinking of machine language? But then, there is not one machine language; the x86 machine language is different from the ARM machine language, for example. So still no language to rule them all, just a family of languages.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Arik on Thursday March 12 2020, @09:18AM (3 children)
If laughter is the best medicine, who are the best doctors?
(Score: 2) by quietus on Thursday March 12 2020, @10:32AM (1 child)
(Score: 2) by Arik on Friday March 13 2020, @08:58PM
It's 1 or it's 0, or at most the third option is there's an error and we backup and try again.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by JoeMerchant on Thursday March 12 2020, @12:56PM
Binary is more the phonemes of computer control - and it doesn't cover analog, or trinary, or other systems.
That's not even close to what I would call true... 6502/6809 are somewhat related, but they're pretty far from 8088, which itself bears almost no practical resemblance to modern Core iX machine code. The only thing they all have in common is some degree of simplicity / closeness to the hardware, a lack of abstraction.
This is also true of human spoken / written language, the difference being: we don't understand how wetware machine language works.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @01:41PM
"Binary" isn't a language.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @06:11PM
The thing is, the tool that best fits the use case is more often than not the tool you understand the best. So language A is better for case X than language B really just comes down to "I know how to do this in language A, but I don't know how to do this in language B"
At an academic level an expert in the field may be able to recommend one language over another. But in the real world, it rarely if ever matters.