SoylentNews is people
SoylentNews
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:
- Visual Basic
- Objective-C
- Perl
- COBOL
- CoffeeScript
- Scala
- Lisp
Do you agree with his assessment? Are there any other language(s) you would add to the list?
This discussion has been archived.
No new comments can be posted.
Top 7 Dying Programming Languages to Avoid Studying in 2019 –2020
|
Log In/Create an Account
| Top
| 195 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Two is not equal to three, even for large values of two.
(Score: 5, Interesting) by Unixnut on Wednesday March 11 2020, @10:37PM (19 children)
I don't know. I used Perl(5) on and off historically, mostly to deal with existing legacy stuff others had written, so I knew it on a basic level, but never put the effort in to understand it. Spent most of my time in Python (and C occasionally).
Funny thing is, after Python3 was released, and I found it a frustrating and irritating modification of what was originally a good language (IMO), that made even basic tasks harder, I started looking more into Perl, and actually writing software in it, and actively learning more about it... and the thing is, I like it.
In many ways, it does things no other language can do as easily. It is an excellent scripting language in the original sense of the term, and it is now my go-to for small to medium automation, data munging and general scripting tasks. I don't think it is dying, I think it is just fading more into the background. It was originally developed as a systems language, for sysadmins to glue together and build environments and machines. Within that scope it does the job brilliantly, and I suspect that deep in the bowels of pretty much every system "popular languages" touch in some way, there is some Perl getting the work done.
It is not a language I would write a massive object orientated project in. For large scale software projects I still use Python3, as the annoyances they added to the language fade a bit when you are building a proper piece of software vs scripting/automation single file executable, but it has displaced Python in most other places for me at least, making it very much alive and kicking.
(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++.
🌻🌻 [google.com]
(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.
🌻🌻 [google.com]
(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.
(Score: 3, Insightful) by Anonymous Coward on Thursday March 12 2020, @02:41AM (1 child)
You can't go a week without somebody predicting perls doom. But there is no other language that will let you do the crazy shit perl will let you do. Not that you should do it. But you can.
The story behind perl hate is almost unversally this:
Boss ask tech to fix. Tech get tired of fixing, he slap a perl one liner on it. Boss notices tech no longer contemplating hari-kari. Boss tell tech to fix other. Tech extends perl. Five years later, one liner is company wide ERP system that saves million of shinys.
Boss tells tech to make big tittied naked women fall from the sky. Tech finally says: "Yeah, that needs a ground up rewrite with a proper development cycle". Boss wonder why tech no longer love him? Cry's quietly in a corner, then become angry. "Fucking tech! Do what I want!". Tech says: "No. It doesn't work that way." Boss fires tech. Boss's boss asks to fix something. Boss cannot. Boss no program. Boss is sad. Boss reads article that say: "Python so easy!". Boss read 5 lines of Python and think that programming. Boss hires tech, says "python gud!". Tech says, "Yeah, a whole team needed for that.". Boss pays ten times as much to do it in Python. Boss tell everyone: "perl is for assholes! See! Me did it in python!" Boss fires four out of five programmers, and locks the last one in a cage with bread and water to maintain code. Boss gets promotion and new company Wooly Mammoth.
If you like it dirty, perl. If you want it to scale, perl. If you want it efficient, perl. If you want the programmer to be an easily replacable commodity: python.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @04:21AM
With that being a rare commodity, bitchfest from those afflicted by sour grapes never ceases and never will.
(Score: 2) by edIII on Thursday March 12 2020, @11:00PM (2 children)
Perl isn't fading into the background, as much as the BSD's are in the background. It seems to me that Perl is a very big thing in OpenBSD. That's why I laughed when Joe said, "A lot of legacy code". Perl is on the front line for a great many people, including myself.
I'll admit, I don't know what this Perl 6 BS is actually about, but Perl 5 is perfectly adequate for modern tasks. Some pretty nice enterprise frameworks based on Perl like Catalyst, and there is Mojolicious (which I took to be Catalyst Light).
There's a lot of people using Perl for modern use cases with varying complexities and requirements. Not on legacy equipment, but cutting edge embedded systems. To say it's a dying language is amusing.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @11:30PM
Yup, at Intel in the hardware engineering groups, perl is the most commonly used scripting language with TCL being second since all the EDA tools have TCL parsers.
(Score: 1) by sorpigal on Friday March 13 2020, @12:15AM
First, Perl6 is now called Raku (renamed last year to hopefully end the confusion). Consider it to be a language riffing on Perl sensibilities, but for the modern age and the future. If there's a programming paradigm or language feature that has come out of academia in the last 30 years and is useful to anyone, Raku implements it--but it doesn't just throw everything in to a big pile and say "there you go." Instead, the designers seem to have looked at all of the different features out there and broken them down in to primitives that they then used to build up to every feature you could possibly imagine. The net effect of this is that everything works with everything else, and if you dig down far enough, much like the root system of a vast interconnected mushroom, everything is connected. The worst and best part of Raku is when you're trying to figure out how to do something and take a trip to the documentation, then wind up staring in to the abyss that is the depths that are available for you to plumb. I expect that this will, with time and experience, happen less often (but not, alas, for me as yet).
Perl5, or (now) just Perl, meanwhile has continued to evolve--and its evolution is accelerating. The primary reason, I think, for the loss of Perl popularity was that at a critical time in the explosion of the web (late 1999 to maybe about 2006) there was nearly zero work on the language. This is now dramatically better and improvements are being made regularly again, sometimes borrowing bits and pieces of the good ideas from Raku. If you haven't looked at Damian Conway's Dios.pm or his Regexp::Debugger, for example, you're missing out on modern Perl at its best.
Perl may not get the press any more, apart from unfortunate inclusions in articles like this, but it's an exciting time for the language... and for Raku, too.