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.
1
(2)
1
(2)
No self-made man ever did such a good job that some woman didn't
want to make some alterations.
-- Kim Hubbard
(Score: 4, Interesting) by legont on Wednesday March 11 2020, @10:36PM (17 children)
This is my sad experience as we speak. Perl is dying exactly because nobody wants to study it. My management forces me to give up Perl because they can't find youngsters to replace us.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 2) by turgid on Wednesday March 11 2020, @10:41PM (4 children)
I thought Ruby had taken over from Perl.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @01:14AM
No, Ruby is a whole new level of fragility.
(Score: 3, Insightful) by arslan on Thursday March 12 2020, @01:54AM (1 child)
Nah, Ruby is already dead and buried.
(Score: 2) by Bot on Thursday March 12 2020, @09:14AM
Ruby got popular with rails, rails lost a bit of focus by concentrating on itself instead of catering to the devs/enterprise needs (which are stability and API stability and API stability and stability) and node js ate its lunch. Pity because as a language ruby is nice.
Account abandoned.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @05:41AM
Ruby is big in Japan. Everywhere else, not so much.
(Score: 3, Insightful) by The Mighty Buzzard on Thursday March 12 2020, @02:04AM (5 children)
Tell them to stop trying to find people who already know it and train some who don't. You can have them producing useful work inside a week if they know any language that's somewhat similar. And you can pay them less than someone who already has some expertise.
My rights don't end where your fear begins.
(Score: 2) by legont on Thursday March 12 2020, @02:44AM (1 child)
While I totally agree with you, this attitude is long gone from the minds of the managers. Besides, it's too complicated for the brave new world.
The motto of Perl is TRMTOWTDI (There Is More Than One Way To Do It). That's what Larry wrote on my copy of The Book. Goggle switched to Python which is TIEOWTDI (There Is Exactly One Way To Do It), but even that is too complicated for Google engineers. They require a dumbed down Go.
For the better or worse, the world has changed.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 2) by The Mighty Buzzard on Thursday March 12 2020, @04:49AM
That's why they're middle management and will never be anything better. You do not get the brass ring if you don't take the risk and reach for it. Caution's fine but fear causes mediocrity.
My rights don't end where your fear begins.
(Score: 2) by DannyB on Thursday March 12 2020, @03:07AM (2 children)
When you're hiring people, there is something to be said for being able to seek out skills for which there are plenty of candidates for.
On the flip side of that, you have to stand out to get hired.
So, for just one example, I know Visual FoxPro and was very good at it. A language lawyer. I mean I knew obscure corner details. But I don't expect to find a lot of demand for that obsolete skill. I also was once very good at Pascal, including inline or linked assembly.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 3, Informative) by HiThere on Thursday March 12 2020, @05:17PM (1 child)
In my opinion, FoxPro was a very good language/environment, which needed a bit of development. Microsoft bought it and intentionally broke in so that people would change to MSAccess. Which was profoundly inferior. Then they made the MSAccess environment so unstable that programs would run for awhile (as in periodically for months, with separate invocations), and then they would garbage the binary so you needed to reenter the source. (You didn't need to change it, but you needed to reenter it....I started saving working programs off as text files so I could do a copy/paste.) I can't guess why they did that, by guess would be incompetence, as I don't think it yielded them ANY value. Eventually I started writing routines that I could in Eiffel (well, and Eiffel dialect specialized for MSWindows), and those kept working. But they couldn't handle access to the database or screen display, only intermediate computations. (Which AccessBasic would, unpredictably, give the wrong results for.)
I started trying to avoid MS software because of that experience. I think this was around 1998. I know Linux didn't have a usable word processor.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Interesting) by DannyB on Thursday March 12 2020, @05:58PM
FoxPro ran on:
1. MS DOS
2. Unix
3. Classic Mac
4. Windows
Microsoft did away with the first two immediately, naming it Visual FoxPro.
Then after VFP 3, Microsoft did away with item 3 leaving only 4.
I did some cool things with VFP. And portable across Mac / Windows. Graphics. 7-segment LED displays in clocks and calculators. Those "Qix" like screen savers popular in the 90s. A 3D rotating box (just line segments, no shading) randomly changing rotation angles constantly and gradually so it wasn't repetitive. In pure VFP. No native code or Windows specific stuff. The tick was that you could put line segments and rectangle shapes onto a form (eg window). You could dynamically change their background color, and in the case of a line segment, change its endpoints. So 7-seg displays seem obvious, and the Qix like screen savers seem obvious. I also wrote HSV2RGB and vice versa conversions, so I could do lots of cool things with colors in VFP. Randomly color changing bouncing balls. A ball is just a circle whose color gradually changes hue, and changes position according to a velocity each frame, and bounces off the window edges. I also generated gradients. Simply draw a lot of segments where you vary either the hue, brightness or other attributes. Instant custom nice looking progress bars. It's just that aspbergers thing. Once I realized how far I could push some of the things available in VFP, I took it to the limits. Puzzle games, etc. None of these used any database, just used VFP as a language that could compile to an EXE. But then there were the boring business applications to write.
I did get into VB / Access for a short time before selecting Visual FoxPro. Cross platform turned out to be important for us. Alas, VFP became Windows only under Microsoft.
I never did learn the Windows GUI API the way I did the classic Mac. I just couldn't stomach Microsoft. And there was no need to write at that low level during this time period. Back in the 80's, the classic Mac, the Apple II, IBM PC, etc there was no off the shelf database like what we needed, so we had to build our own. We had files of records (analogous to DBF but not that format) and our own btree indexes (analogous to CDX but not that format). And it was cross platform using the UCSD p-System (Pascal) on Apple II, Apple III, MS-DOS and classic Mac.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 1, Insightful) by Anonymous Coward on Thursday March 12 2020, @02:43AM (5 children)
There is a high demand for Python. Mostly because people who don't understand programming, think they understand Python.
(Score: 2) by legont on Thursday March 12 2020, @02:46AM (2 children)
Yep, that's what's being pushed because supposedly it's what the new generation likes. I doubt it though.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @09:29AM (1 child)
I have close to 30 years of professional experience, a bit more than half of that using mainly Python. I love it. I'm fortunate to be able to use it for most of my work, with the remaining being done in C, C++, TypeScript (all of those I like), JavaScript (meh), and Java (which I don't like).
I hate Perl. I despise it with a passion. I had to use it in two of my projects, and despite an honest attempt to grok it, all I could see was a patchwork of a language that incentivize bad practices. You can find well-written Perl code, but 99% of what you find is a steaming pile of crap, and that's the language's fault. PHP suffers from the same problem, but it is not as bad.
(Score: 0) by Anonymous Coward on Sunday March 15 2020, @06:08AM
You could say that about most languages
(Score: 2) by HiThere on Thursday March 12 2020, @05:24PM (1 child)
Python is an excellent language for the correct problem space...which doesn't include fast. In some areas it's significantly better than C or C++. I do think Python3 is better than Python2, but it sure depends on your use case, as for many Python2 is better.
They do need to work on their interface to C and C++, but I don't expect that to happen. People who become devoted enough to a language to start developing it don't seem to see the need to link it to "the competition". Cython is promising, but it's not well documented, i.e. if you have a Python program that you want to speed up, Pypy is much more straightforward.
FWIW, I started off in FORTRAN, and one point C was my major language, and another point C++ was (though before the STL). I've also programmed in Java and a variety of other languages. So I feel entitled to think your denigration of Python is totally unjustified. It's got it's limits, but so does every language in practice, if not in theory.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 0) by Anonymous Coward on Saturday March 14 2020, @02:20PM
It's faster than PowerShell but not as extensible or flexible in the Windows Server space.
(Score: 2) by turgid on Wednesday March 11 2020, @10:43PM (6 children)
FORTH EXCELLENT = .
1
OK
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Interesting) by RamiK on Wednesday March 11 2020, @11:10PM (2 children)
https://factorcode.org/ [factorcode.org]
compiling...
(Score: 2) by HiThere on Thursday March 12 2020, @05:40PM (1 child)
The website doesn't seem well-maintained. Several of the examples yield "502: Bad Gateway".
OTOH, the development release has a recent date.
I was not able to quickly determine what representation they use for characters. They've got something called concurrency, but I'm not sure whether that is actual multi-processor execution or merely threading within the same process.
In short, the documentation needs a lot of work to interest me.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Interesting) by RamiK on Friday March 13 2020, @12:18AM
Slava Pestov stopped actively developing it around 2010 when he started plumbing for Google. Currently I believe he's working for Apple developing Swift? Regardless, there's a few guys hacking on it here and there but nothing major. Still, should be preferable to Forth.
https://factorcode.org/littledan/dls.pdf [factorcode.org]
https://andreaferretti.github.io/factor-tutorial/ [github.io]
coop coroutines implemented as a single threaded vm.
Topic of the discussion was Top 7 Dying Programming Languages to Avoid Studying in 2019 –2020 and you brought up Forth so I just couldn't help trying to outdo you with a more modern concatenative language that is similarly pinning for the fjords :D
Regardless, linear memory models are making a comeback with WebASM and I'm already seeing infant languages trying to pick up where Forth and Factor left off ( https://github.com/renatoathaydes/wasmin [github.com] https://github.com/obfusk/koneko [github.com] ) so there's still some hope.
compiling...
(Score: 2, Insightful) by noelhenson on Wednesday March 11 2020, @11:23PM (2 children)
I still love Forth though I have not programmed in it in maybe 8 years or so. It is truly astounding how much code one pack into a small space with it and have it execute at amazing speeds.
(Score: 1, Informative) by Anonymous Coward on Thursday March 12 2020, @04:31AM (1 child)
Pretty much by definition, as you basically build up the language to solve any task.
Also, two stacks do clash with present programming model which constantly uses callbacks from C/C++ based libraries (naturally using one stack).
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @02:45PM
Forth is basically the byte code language of a particular stack oriented virtual machine.
It's way too low level for software of any complexity. Thus, its main use which was in embedded systems doing control loops and hardware control.
(Score: 4, Insightful) by turgid on Wednesday March 11 2020, @10:56PM (4 children)
Objective-C is very interesting because it is a simple and elegant pure superset of C. It's what NextStep, OpenStep, GNUStep and the GUI of MacOS X were written in.
Ten years ago I bought a book on Scala. It was a nice Object Oriented language for the JVM with functional programming features (lambda) and full access to all the existing Java classes. Never got around to writing any myself due to circumstances, but it seemed far more terse and expressive than Java.
Perl is mad. It's worth looking at to see what an IQ of 200 and a lot of hubris, combined with contempt for us mortals can produce.
LISP is a family of languages. You haven't lived until you've tasted curried functions. Have a look at scheme (nice and simple) and DrRacket. Then look at Clojure on the JVM.
The Pascal family of languages are worth a look. I've written Pascal (Turbo) but I learned Modula-2 first in my teens. That taught me the importance of types and encapsulation.
FORTH because just you must. Radio telescopes.
Take some advice from Paul Graham and look for the best languages, not just the most popular. You have to be mindful of where your next salary payment is coming from but if you only aspire to be average, that's all you'll achieve. Look for the best. When you have the opportunity to use the best, use it, and beat the competition.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by melikamp on Wednesday March 11 2020, @11:22PM (1 child)
(Score: 2) by TheRaven on Thursday March 12 2020, @03:28PM
sudo mod me up
(Score: 2) by bradley13 on Thursday March 12 2020, @03:57PM (1 child)
"Ten years ago I bought a book on Scala. It was a nice Object Oriented language for the JVM with functional programming features (lambda) and full access to all the existing Java classes. Never got around to writing any myself due to circumstances, but it seemed far more terse and expressive than Java."
Exactly right. Scala is a really nice functional language. But functional languages and GUIs don't mix all that well, so having full compatibility with Java (and hence JavaFX), plus all the other Java libraries out there, was a really good move. I wrote several sample programs in Scala and quite enjoyed the experience.
I'm not sure why Scala hasn't seen more interest. It would have been far nicer to use Scala where functional programming is needed, rather than introducing those horrible Java lambdas that pretend to be functional, but really aren't.
Everyone is somebody else's weirdo.
(Score: 2) by turgid on Thursday March 12 2020, @08:42PM
I've just bought a copy of The D Programming Language book and I"m about 100 pages in. It seems to be a very powerful and clean language and another that should be more popular than it is.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Disagree) by Freeman on Wednesday March 11 2020, @11:16PM (13 children)
It can't die fast enough.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 5, Touché) by NickM on Thursday March 12 2020, @12:24AM (10 children)
I a master of typographic, grammatical and miscellaneous errors !
(Score: 4, Insightful) by The Mighty Buzzard on Thursday March 12 2020, @02:07AM (9 children)
Or regexes that make you look like a ninja wizard when you can glance at one and tell noobs that it does something in 50 characters that took them 750 to write out as proper code.
My rights don't end where your fear begins.
(Score: 3, Insightful) by DannyB on Thursday March 12 2020, @03:09AM (8 children)
You can love RegExs and use them frequently, without using Perl. I personally know.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @04:37AM (1 child)
and end up writing Perl. It is how it happened to me.
(Score: 3, Touché) by The Mighty Buzzard on Thursday March 12 2020, @04:45AM
The fun bit is, write some text wrangling in Perl what's regex-heavy then try doing the same in Python. It's quite painful, even laying aside all the other parts of Python that someone deserves throat punched for. Folks who know what they're talking about may not want to prefer Perl for text wrangling but they do prefer it.
My rights don't end where your fear begins.
(Score: 2) by The Mighty Buzzard on Thursday March 12 2020, @04:39AM (5 children)
That's all fine and good but we were talking origin stories and the P in PCRE don't stand for Python.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @01:05PM (1 child)
If you're going to get persnickety about origins, perl didn't invent regular expressions either. It took its inspiration from the existing unix tools such as sed and awk.
(Score: 2) by The Mighty Buzzard on Friday March 13 2020, @11:47AM
True, they just gathered together the most widely used standard for them to which most other languages subscribe.
My rights don't end where your fear begins.
(Score: 2) by DannyB on Thursday March 12 2020, @03:02PM (2 children)
I think the real P in PCRE deserves full credit for its contributions to field of computer science.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @03:27PM (1 child)
I think you need to expand on what those contributions are.
(Score: 2) by The Mighty Buzzard on Friday March 13 2020, @11:56AM
For starters, when it was the go-to language for so many things, it absolutely separated the wheat from the chaff in regards to programmers. It was dead easy to spot dipshit noobs who you needed to either teach or fire before they fucked things up.
My rights don't end where your fear begins.
(Score: 4, Funny) by petecox on Thursday March 12 2020, @12:47AM (1 child)
(Score: 2) by HiThere on Thursday March 12 2020, @05:43PM
I went to learn Raku a week or so ago, and most of the website was down.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 0) by Anonymous Coward on Wednesday March 11 2020, @11:26PM
I wish I could add C#. I made a few open source applications in C#. I usually don't expand my software until they can read mail, so when they are mature enough, I just port them from version to version unchanged, without adding features, and this can go for years. But in C#, porting quickly became "write again". It could go even bearable, but new versions broken APIs, which worked in a plug-in architecture breaking compatibility with other users' code. I abandoned the project with .Net 3.x. Came back to C++, this time with Qt, and the most painful porting I had was with 3.x->4.0, where I had to replace a few "take-the-object-through-the-class" hacks returning objects with "find-the-object-where-you-should-not-look" methods returning pointers :). The port 4.x->5 was really, really quick, just a few minutes.
About Perl... let's just say that it's not easy to find a replacement for text processing without unportable regexes or 250MB libraries launching Chrome to parse HTML (see Python). Modern popularity of string-unfriendly languages seem to be a result of making more tasks just outsourced to programmers, so it's not financially optimal to keep it simple.
(Score: 2) by black6host on Wednesday March 11 2020, @11:49PM (4 children)
I'm so glad Delphi isn't on that list! I hone my leet coding skills in it every day. Yeah, yeah, I know that train left the station a long time ago, lol.
(Score: 2) by DannyB on Thursday March 12 2020, @03:10AM (2 children)
Isn't Delphi really Pascal with objects, and nice development tools and GUI frameworks?
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 2) by black6host on Thursday March 12 2020, @05:24AM (1 child)
Yes yes and yes. For business applications it ran circles around most of the contenders. You could even code inline assembly if you wanted, for speed sensitive things. The two things I liked the most, however, were that you could compile to an exe and move just that into your working directory once you came out of testing. No need to install on all the client computers; and the fact that you could just have one damned .ini file in the working directory and not make a ton of registry changes on each client machine. It made rolling out a new version very easy.
(Score: 3, Insightful) by DannyB on Thursday March 12 2020, @02:56PM
I almost got into Delphi. But it was not cross platform enough. So Java.
But I look at Lazarus and related projects with a bit of nostalgia. Thinking if I had today's tools back then, it would have been this Delphi clone all the way.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 3, Funny) by turgid on Thursday March 12 2020, @09:59AM
Dad, I didn't realise you had an account here!
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @12:07AM
I'd put VB, COBOL and Perl in the category of "study these if you're at a company with a large installed base legacy code written in them, or intend to seek employment at such companies". You may not *like* it, but money is money. Maybe they're dying, but nowhere near dead.
I wouldn't say "don't study Lisp". On the contrary, study it. Maybe don't develop in it, maybe don't even seek jobs with it; but definitely study it. It's the "dual of Forth", which is equally obscure and not on his list. I think ESR had some kind of quote about Lisp along the lines of "worth it for the epiphany you might have". I don't think Lisp is dying at all--there are many variants of it. Niche, but not dying.
Objective-C I think might be dying because it used to be Apple's language of choice. Maybe that's truly worthy of bypassing. I'm not sure how much it was adopted in other areas.
That leaves CoffeeScript and Scala, the former being what I understand to be more of a transcompiler to JavaScript, and the latter a more ambitious functional programming language. Maybe they really are dying and don't have anything interesting to teach us, maybe they really were blind alleys. I haven't heard much about them lately.
Languages almost never die entirely, and even intentional esolangs have something to teach us--even if it's "what not to do".
(Score: 2) by Arik on Thursday March 12 2020, @12:11AM (8 children)
Visual Basic - brain damage on floppies. Made GWBasic look good. Not sure why anyone ever used it.
Objective C - gets a bad rap because the most prominent user is Apple and they've been going steeply downhill. There used to be decent GNU support too though, and it seemed like a nice language for anyone that wants C with object support in a more sane package than C++. I never really used it though, I was more into obj-pascal.
Perl - Wikipedia says "It has been nicknamed "the Swiss Army chainsaw of scripting languages" because of its flexibility and power,[20] and also its ugliness.[21]" and that sounds right as far as I know. Never used it much, some people swear by it.
COBOL - Everybody laughs, but if I'd gotten into that I'd probably be rich despite all best efforts to the contrary. Designed very early, but designed specifically for business purposes, which means for long established and relatively simple maths. So maybe they didn't get it fatally wrong. Anyhow, I didn't learn it, and I'm not rich.
CoffeeScript - The beans of Java? Never heard of it.
Scala - Claimed to be a general purpose programming language, but compiled to java bytecode. Has anyone actually made a java machine, as opposed to a java virtual machine? Android isn't java, remember.
Lisp - Lots of Irritating Silly Parenthesis. Still one that seemed quite promising. Are there *any* functional languages in common use now?
If laughter is the best medicine, who are the best doctors?
(Score: 2) by turgid on Thursday March 12 2020, @01:30PM (7 children)
Yes, Sun Microsystems used to make hardware that ran Java natively.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @02:33PM (6 children)
I only know of rings (for your finger) made with Java chips that were used as security tokens.
As far as I know, the number of Java native CPUs made was never more than a rounding error. It was more of a promotion of Java than anything that made sense. General purpose CPUs (not tied to any high level language) ALWAYS win.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @02:36PM
Oh, I just remembered, I believe Sun also made SunBlades which were supposed to be cheap terminals (think along the lines of a Chromebook, but wired, for the desktop), and these may have used Java CPUs. Can't remember. Total flop.
(Score: 2) by turgid on Thursday March 12 2020, @06:37PM (4 children)
Indeed they do, and JIT compilers can do fancy optimisation that static compilers and CPUs can't do.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Arik on Friday March 13 2020, @08:57PM (3 children)
If laughter is the best medicine, who are the best doctors?
(Score: 2) by turgid on Saturday March 14 2020, @09:07AM (2 children)
Human programmers can't predict the future. JITs and CPUs can be aware of the present as it happens (the future to the human) and make adjustments.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1) by Arik on Saturday March 14 2020, @01:55PM (1 child)
You've got that exactly wrong.
JIT's are clever creations, embodying *some* of the knowledge of the programmers who create them, and certainly capable of some impressive feats by combining that rote knowledge with a bunch of CPU cycles. But it's the compiler that can't predict the future - even the JIT is simply averaging the recent past and adapting to it in the expectation that the future will be similar. Only the human programmer is capable of actually seeing the future here - by understanding the larger context and meaning of the work.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by turgid on Saturday March 14 2020, @09:05PM
You might want to note the success of the Intel itanic.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Insightful) by Cosmic Debris on Thursday March 12 2020, @12:35AM (3 children)
What, no APL?
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @01:37AM
Last time I saw an APL keyboard was on an old Tektronix terminal.
(Score: 2) by bzipitidoo on Thursday March 12 2020, @03:06AM
TFA is about dying languages, not already dead ones. Otherwise, the list should be a lot, lot longer: Pascal, Modula, Modula-2, Modula-3, PL/1, almost every domain specific 4th generation language from the 1980s such as Informix 4GL, BASIC (the real BASIC with line numbers, not that VB stuff that was just trying to piggyback off the name), Rexx, and a bunch from the 1960s, including ALGOL and, I suppose, APL.
(Score: 2) by bootsy on Thursday March 12 2020, @01:52PM
Given the daily rate for KDB+ programmer (at the time of writing over 1000 UKP a day) and how K is basically APL/A+ and how you can then learn Q from that I wouldn't worry about knowing APL.
Arthur Whitney has now just come up with Shakti in yet another re-invention of the APL language.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @01:07AM
Not that I read TFA, mind you.
Here's a list that should open some eyes...
http://www.catb.org/retro/ [catb.org]
(Score: 2, Funny) by Anonymous Coward on Thursday March 12 2020, @01:12AM
For PL/1 [wikipedia.org]?
More details [ambians.com]:
(Score: 2) by jimbrooking on Thursday March 12 2020, @01:22AM
Much easier to get along wit than EXEC 2, both long dead, I uess.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @02:02AM (3 children)
LISP's last hurrah was the 1980s.
Aside from a brief spurt of LISP interest due to the Java implementation known as Clojure, it has been basically dead ever since.
(Score: 2) by The Mighty Buzzard on Thursday March 12 2020, @02:10AM (1 child)
Tell that to all the folks still using emacs.
My rights don't end where your fear begins.
(Score: 3, Funny) by Anonymous Coward on Thursday March 12 2020, @07:14AM
You tell him.
(Score: 2) by DannyB on Thursday March 12 2020, @03:12AM
Sad but true.
While Emacs users may use lisp, that is mostly to scratch their own itch. Not for commercially distributed software.
I have great fondness for Lisps.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 2, Interesting) by vu2lid on Thursday March 12 2020, @02:10AM
Perl is unmatched in it's intended original purpose - a general purpose scripting language that can be used as a glue. When used like this it is elegant, understandable and highly productive. Extremely complex tasks for interconnecting systems (which were never originally meant to be compatible) can be done relatively easily and with very little dependencies or overhead.
(Score: 3, Insightful) by darkfeline on Thursday March 12 2020, @02:47AM
Lisp is way too broad, that's like saying, procedural languages using curly braces are dying. Hell, Lisps don't even have the same paradigms, with Scheme and Clojure being far more functional than Common Lisp.
With that said, Emacs Lisp is by far the most amazing language that is in continued active use despite the many reasons why it should have died. There is literally only a single program that can run Emacs Lisp (ignoring XEmacs which is dead). There is no standard or significant alternative implementations. Everything is in a global namespace, which Best Practices tells us is bad for maintainability. There is no access control, which again violates Best Practices. No static typing. Inconsistent APIs cobbled together by random folks.
And yet.
Lots of people still actively develop Emacs Lisp, including many non-programmers. This language is 35 years old without any large backward compatibility break or cleanup of standard libraries. Lots of libraries have been shared via emailed patches and wikis. It's still around and kicking. That's impressive.
Join the SDF Public Access UNIX System today!
(Score: 3, Insightful) by Snotnose on Thursday March 12 2020, @03:15AM (3 children)
But I have to admit, it belongs there. I've become a perl expert what, um, mumble mumble, 4, maybe 5 times? In the last 25-30 years? That's not counting the passing acquaintance I've had with it since it was first released. Each time there was a team of us, and a few weeks in none of us could read anyone else's code.
There may be more than one way to do it, but for fucks sake when I can't make head nor tails out of your line noise, nor you mine, something is wrong.
This is not a knock on Perl, it was great in it's time. But please, let it die.
And I never even got into the, um, Perl 6? kerfuffle. Whenever they introduced OO stuff into it 10-15 years ago. I can only imagine how much worse it is now to pick up someone else's code.
/ that said, you'll have to pry my Camel book from my cold, dead hands.
// it's under my assault rifle
/// with the selector switch set to full auto and a hair trigger tied to my fingers :)
Relationship status: Available for curbside pickup.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @04:42AM (2 children)
No syntax can make clear what a muddled brain produced.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @07:18AM
Somehow you touche'd yourself. Do you like toucheing yourself?
(Score: 2) by Snotnose on Friday March 13 2020, @12:42AM
Yeah, that's not what we're talking about. We're talking 4-5 experienced software engineers who know the basics and now need to write large scripts. You divvy up the job, buy everyone a Camel book, and huddle down in your cube. A month later everyone's code works well, but nobody can figure out anyone else's code.
You try looking up ~, |, [, or , on google and see how far that gets you.
Relationship status: Available for curbside pickup.
(Score: 2) by bzipitidoo on Thursday March 12 2020, @03:23AM
Lists and discussions of this sort are somewhat a giant red herring. One of the things that made Perl was the intrinsic regular expression capabilities. Once Perl showed the world how useful that could be, it wasn't long before other languages incorporated it. C/C++ has the PCRE library.
I'm guessing that one of the things that will really distinguish programming languages of the future is the ease with which they can be expanded. Easy addition of useful features would make moot much of the debate over which languages are best. C/C++ is clunky, needing the "namespace" extension of the language to handle the proliferation of library functions. And, all those C libraries lack critical information needed to link. I have read that Perl 6 gets around this problem by having the capability to parse C header files, so that it can figure out how to call the functions. Perl 5 can't do that, and must lean on this huge library of wrapper code, CPAN. Java is in a world of its own.
(Score: 1) by pir on Thursday March 12 2020, @03:43AM (1 child)
There will be perl code running somewhere long after all of us reading this are dead and gone. Probably not *my* perl code, but ya never know. Probably COBOL too. Scala is interesting, and will likely live on. Objective-C, will probably fade into obscurity, unless someone outside Apple keeps it alive. VB, who cares, though it will probably live on out of spite. I barely know what CoffeeScript is.
However, forget all those, there will probably be lisp code (or some derivation thereof) still running somewhere even as the universe reaches heat death.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @04:44AM
http://www.oolite.org/ [oolite.org] - an open-source successor to Elite
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @06:36AM
As someone who has used it professionally, I am able to do things in Scala in a month that occupy entire departments in some companies, and which could literally not be done in any other language. The only other language with enough power is LISP, but it doesn't have access to the necessary libraries and platforms to make solving real-world problems practical. If something is theoretically possible within the capabilities of your computer, and it isn't hardware or OS-dependent code or otherwise something where you can't use the JVM, you can probably do it with Scala.
Here's another reason to use it. It is harder to learn but multiplies your productivity. Most programmers add zero value. Those programmers cannot learn Scala. The programmers that actually add value will find their productivity doubled, or more. Scala will get rid of your dead weight for you.
(Score: 2) by maxwell demon on Thursday March 12 2020, @08:56AM
Unlambda is not on the list. So I still have the chance to make a great career as Unlambda programmer, right? :-)
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Interesting) by bzipitidoo on Thursday March 12 2020, @12:41PM
Lists and discussions of this sort are somewhat a giant red herring. One of the things that made Perl was the intrinsic regular expression capabilities. Once Perl showed the world how useful that could be, it wasn't long before other languages incorporated it. For instance, C/C++ has the PCRE library.
I'm guessing that two things will really distinguish programming of the future: the ease with which languages can be expanded, and the lack of pointless distinctions and restrictions. Easy addition of useful features would make moot much of the debate over which languages are best. The function notation of C/C++ and curly brace languages is clunky. LISP is even worse. What I mean is that in most programming languages, we really have 2 notations for procedural instructions: basic arithmetic, and function calls. You can write "d = a + b * c;" It's neat, short, and widely understood. In LISP, that looks like "(setq d (+ a (* b c)))" or maybe "let" instead of "setq", with even more parens, if 'd' is a new variable being created rather than an existing variable to which a new value is being assigned. Argh. Function call syntax is fundamentally no better. In C, if those functions were not operators, it would have to be something like "assign(&d, add(a, mul(b,c)))". What can't be done in C/C++ code, or for that matter Perl, Python, Java, JavaScript, and many others, is the creation of a new operator. To C/C++, can't just simply add Perl's regex match operator, =~, no, have to use function call syntax. Got to be "foo(a,b)", never "a foo b". (Do you know that C++20 is finally bringing the spaceship operator, <=>, to C++? That's what it takes to add a new operator to C++, a lengthy debate by a standards committee.) LISP gets all the hate over the excessive quantities of parens, but that problem exists in most programming languages.
One of the reasons the notation of basic arithmetic works is that the operators operate on a fixed, known number of parameters. LISP can do "(+ a b c)". To make a similar summation function in C is a lot more painful. Got to drag in that variable length parameter list library they made long ago to handle printf. Consequently, most C functions operate on a fixed number of parameters. But, even though we know how many parameters most C functions take, because outside of the printf family, variable length parameter lists are rare in C, the language still insists on forcing the programmers to place parens around the parameter list.
As to pointless distinctions, the examples above have 2 already: the ampersand syntax that C requires to tell the compiler we want to be able to modify the parameter, not just read it, and the whole "setq" vs "let" distinction in LISP. Yes, C and especially C++ have added various notation changes to improve matters, such as placing the ampersand in the parameter list of the function definition, rather than forcing the programmers to type it every time they want to use the function. But I rather like Java's approach of just making everything a reference, and ditching the distinction. Okay, yeah, now you have to think more about "deep copy" vs "shallow copy", but I feel it's a net gain. Here's another pointless distinction, from Pascal: procedure vs function. Shell scripting, and Perl, and BASIC have another fun one: the heavy use of sigils to distinguish variables. Having to write "$d = $a + $b * $c;" is really tedious.
And, all those C libraries lack critical information needed to link. Especially ironic that C is so damned fussy about insisting that every variable's type be declared in advance. A pity there was no mechanism to put all that information so painfully wrung from the programmers into the library, no, it has to be in header files. An additional irony is that C is considered a weakly typed language. I have read that Perl 6 gets around this linking problem by having the capability to parse C header files, so that it can figure out how to call the library functions. Perl 5 can't do that, and must instead lean on this huge library of wrapper code, CPAN. Java is in a world of its own.
(Score: 3, Funny) by bzipitidoo on Thursday March 12 2020, @12:46PM (1 child)
Nuts, used the "Reply to article" instead of "Reply". Pointless distinctions, sigh...
Lists and discussions of this sort are somewhat a giant red herring. One of the things that made Perl was the intrinsic regular expression capabilities. Once Perl showed the world how useful that could be, it wasn't long before other languages incorporated it. For instance, C/C++ has the PCRE library.
I'm guessing that two things will really distinguish programming of the future: the ease with which languages can be expanded, and the lack of pointless distinctions and restrictions. Easy addition of useful features would make moot much of the debate over which languages are best. The function notation of C/C++ and curly brace languages is clunky. LISP is even worse. What I mean is that in most programming languages, we really have 2 notations for procedural instructions: basic arithmetic, and function calls. You can write "d = a + b * c;" It's neat, short, and widely understood. In LISP, that looks like "(setq d (+ a (* b c)))" or maybe "let" instead of "setq", with even more parens, if 'd' is a new variable being created rather than an existing variable to which a new value is being assigned. Argh. Function call syntax is fundamentally no better. In C, if those functions were not operators, it would have to be something like "assign(&d, add(a, mul(b,c)))". What can't be done in C/C++ code, or for that matter Perl, Python, Java, JavaScript, and many others, is the creation of a new operator. To C/C++, can't just simply add Perl's regex match operator, =~, no, have to use function call syntax. Got to be "foo(a,b)", never "a foo b". (Do you know that C++20 is finally bringing the spaceship operator, <=>, to C++? That's what it takes to add a new operator to C++, a lengthy debate by a standards committee.) LISP gets all the hate over the excessive quantities of parens, but that problem exists in most programming languages.
One of the reasons the notation of basic arithmetic works is that the operators operate on a fixed, known number of parameters. LISP can do "(+ a b c)". To make a similar summation function in C is a lot more painful. Got to drag in that variable length parameter list library they made long ago to handle printf. Consequently, most C functions operate on a fixed number of parameters. But, even though we know how many parameters most C functions take, because outside of the printf family, variable length parameter lists are rare in C, the language still insists on forcing the programmers to place parens around the parameter list.
As to pointless distinctions, the examples above have 2 already: the ampersand syntax that C requires to tell the compiler we want to be able to modify the parameter, not just read it, and the whole "setq" vs "let" distinction in LISP. Yes, C and especially C++ have added various notation changes to improve matters, such as placing the ampersand in the parameter list of the function definition, rather than forcing the programmers to type it every time they want to use the function. But I rather like Java's approach of just making everything a reference, and ditching the distinction. Okay, yeah, now you have to think more about "deep copy" vs "shallow copy", but I feel it's a net gain. Here's another pointless distinction, from Pascal: procedure vs function. Shell scripting, and Perl, and BASIC have another fun one: the heavy use of sigils to distinguish variables. Having to write "$d = $a + $b * $c;" is really tedious.
And, all those C libraries lack critical information needed to link. Especially ironic that C is so damned fussy about insisting that every variable's type be declared in advance. A pity there was no mechanism to put all that information so painfully wrung from the programmers into the library, no, it has to be in header files. An additional irony is that C is considered a weakly typed language. I have read that Perl 6 gets around this linking problem by having the capability to parse C header files, so that it can figure out how to call the library functions. Perl 5 can't do that, and must instead lean on this huge library of wrapper code, CPAN. Java is in a world of its own.
(Score: 2) by bzipitidoo on Thursday March 12 2020, @12:48PM
Okay, damn it, I'm not a coffee drinker. Page 2, bah.
(Score: 2) by DutchUncle on Thursday March 12 2020, @01:06PM (1 child)
I don't want to sound all "get off my lawn" here, but if people would just stop forking projects and inventing new languages, and instead spend some of that effort POLISHING and PERFECTING things that already work well, we'd all be much further along getting things done. It's like when the car companies started realizing that they had hundreds of different types of screws with ever-so-slightly-different pitch or thread-angle or [detail], and maybe 2/3 of them could be normalized down to commonality with no loss of function - except in computing we go the opposite way making ever-more variants.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @05:25PM
If you don't invent new languages and new methodologies, how can consultants get paid to go everywhere and teach the new languages and new methodologies?
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @03:33PM
ALL serious programmers should learn Lisp. Not for commercial use, but for its academic value.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @04:50PM (5 children)
I am going to add C and C++.
Oh they will live on for *many* years to come.
But name large greenfield projects where it would be your goto tool if you had another choice? Games but that is a cultural thing. But pretty much everything else is in a different domain seems to not be using C at all. No one would start a project in C other than maybe some oddball 'i am going to do it this way because I can' machismo.
Now do not get me wrong. Love C/C++ have made a lifelong career out of it. Will continue to rake more money out of it for years to come. But I think a good indicator of a 'dying' language is do people intentionally start 'big projects' in it? Even games you could argue because that is just how they have always done it and all of their libs/frameworks are in C.
Even analytic style projects usually start out in something else (excel and python typically is what I see). Then *maybe* they will port to C with some intention of getting speed with a stopover at the java world. But it is not the first thing people reach for these days.
Oh the existing projects will live on for many years. But new stuff? Not so much.
(Score: 0) by Anonymous Coward on Thursday March 12 2020, @05:29PM (1 child)
So, what? You think people are going to write real-time systems in Python, Java, or C#? Moron.
(Score: 0) by Anonymous Coward on Friday March 13 2020, @01:01PM
I have written all of those. 99.99% of the time most of those items do not real time. I have seen and used python IoT devices. Why? Because C is a language waiting to be exploited. In IoT it is a little problem waiting to happen. It is dead scary how much of it is out there. Using random kernel from the early 2000s. Some rando distro of busybox. If you are lucky a somewhat newer version of GCC. All of them which have known vulins in them. No one to fix them. Ever. It went EOL 10 years ago but they still sell thousands a year.
You also wooshed kind of my point. Would you *start* a greenfield project like that? No. Do you have to sometimes? Yeah.
Also no reason to be 'mean' with the moron comment. You maybe should calm down a bit. C is not going anywhere for a long time. But it is not exactly what people reach for when starting new projects. C had a good run. But its time is coming. We are demanding more out of our languages. Type and buffer safety being at the top of the list. C++ can only do one of those.
(Score: 2) by The Mighty Buzzard on Friday March 13 2020, @12:10PM (2 children)
Any OS. Anything that runs on a microcontroller. Most things that run on an otherwise underpowered processor. Anything distributed. Any shared library that might be called from something that needs to be realtime or even just run fast. Any application that needs to be memory efficient. Any application that needs to be processor efficient. And, yes, games.
Will that do or do you need a dozen more examples of the last two non-game categories instead of blanket coverage?
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Friday March 13 2020, @01:12PM (1 child)
I do not dispute that people are writing these things.
My point is outside of an existing architecture such as games, or an OS who is going to write say a word processor in it? C is quickly becoming a niche thing that has associated with it speed. I would argue that things like Rust are going to replace it. Sooner than you think. The interpreted langs long ago ran past 'good enough' on speed for most things. But other things are quickly becoming important too. Such as buffer and type safety. You can say 'oh but someone who knows what they are doing...', many dont. Even seasoned senior software engineers make mistakes.
Take something like tensorflow. Fairly popular python lib right? Under it a C lib that runs the show (look I am making your point). But, I would bet my breakfast that was not their first try. I would bet they started with a 100% python version and converted when it became clear python (which is written in C) could not cut it. People do not *start* new projects in C if they can help it. Us oldies may do it out of habit or because we know whats going on. But the dudes coming behind us? They do not really want anything to do with it. They are tired of patching their computers with the latest CVE list of crap that had to be fixed. They are looking for alternatives. They are making them.
But breath easy. We have made a huge pile of C stuff. Someone has to fix it. You will have job security for eons.
(Score: 2) by The Mighty Buzzard on Friday March 13 2020, @02:14PM
Man, I'd take a word processor written in C over (Libre|Open)Office and their insane java bloat any fucking day of the week.
As to Rust? Yeah, it may very well replace a lot of C, in ten years or more. I dig the shit out of it but it's nowhere near ready for production code. Production code needs a stable release schedule and stable libraries. Stable does not mean updated every bloody week or even every month. It most definitely does not mean there will be breaking changes in crucial libraries every year or that those crucial libraries will be abandoned in favor of shiny and new.
Heh, man, I don't write C unless it's for a job and most of the stuff I write it for almost never needs any kind of updates because it flat ignores (at the driver or what passes for one level) all network input and nobody ever asks for features I didn't already build in. Industrial remote sensors are an absolute joy to write the code for. For the control devices, if I can't convince them that it should either be on an air-gapped network or only accept input from buttons on the device, I tell them "If you insist on doing it that way, fine, but it absolutely will be hacked and you'll blame me when it is, so you're going to have to find someone else to do it."
My rights don't end where your fear begins.