The Top Programming Languages 2023

[Winston]

With nice interactive infographic:

The Top Programming Languages 2023

https://spectrum.ieee.org/the-top-programming-languages-2023

 

[Hobie1dog]

where in the world have you been?

 

[cerving]

I've been programming in "dead" languages almost my entire working career. I can tell you definitively that there are some very large companies that are desperate for Cobol programmers... especially on IBM legacy systems. The cost to replace those 30 y/o highly customized software packages is so high that they soldier on with them, despite their many architectural limitations.

 

[John Kemker]

I've been programming in "dead" languages almost my entire working career. I can tell you definitively that there are some very large companies that are desperate for Cobol programmers... especially on IBM legacy systems. The cost to replace those 30 y/o highly customized software packages is so high that they soldier on with them, despite their many architectural limitations.

Shoot, you might be surprised by how advanced COBOL has become.

I used to program in a language named after a childhood disease: Massachusetts General Hospital Utility Multi-Programming System/MUMPS.

 

[Handeman]

I used to use PL/M-86 and burn the machine code into EPROMs. At least by the time I started using it, the code and compilers were on a $10K IBM 286 with 5.25 floppies instead of the IBM development system with the 8" floppies.

 

[sambatterman]

The first four are 30 years old. I'm a C# guy, but I've programmed in all those languages. Python always makes me laugh - it's not new at all. And it's not named for a snake

 

[cls]

I read somewhere, there are more than 800 million lines of COBOL running in the world today. Thing is, nobody knows exactly what it's supposed to be doing. Seriously, no specs, no docs, original folks long gone.

Personally, I most enjoy Python and C.

I remember PL/M for 8008 (!) and 8080. But the Mostek Z80 mnemonics were better than Intel's.

Arguably things like SQL and VHDL should not be on the list of programming languages because they are not Turing complete.

 

[Jeff Lassahn]

It seems fair allow non-Turing-complete languages as long as they can do reasonably complicated logic on reasonably large data. Kind of like how the laptop I'm typing this on right now isn't actually Turing complete, but I still think it's OK to call it a "computer".

 

[cls]

the laptop I'm typing this on right now isn't actually Turing complete,

Yes it is. Or rather, the CPU is.

 

[Jeff Lassahn]

No. It is not. A Turing machine can access an unbounded amount of memory. This machine can only access 2^64 bytes. It's not a Turing machine, it's a very large finite state machine.

 

[cls]

2^64 ought to be enough for anyone!

 

[jderimig]

Shoot, you might be surprised by how advanced COBOL has become.

I used to program in a language named after a childhood disease: Massachusetts General Hospital Utility Multi-Programming System/MUMPS.

My son, new grad, works in MUMPS.

 

[John Kemker]

My son, new grad, works in MUMPS.

Good chance he works for the VA.

F I=1:1 W I,!

 

[jderimig]

Good chance he works for the VA.

F I=1:1 W I,!

Epic Systems

 

[Chad]

preface: I'm skeptical of these lists, i've seen enough to know that they don't really tell you much

I think Python is fast becoming the default classroom language at least at the middle school and HS level. My kids will be learning some Python in middle school this year it seems to be the next step after the graphical setups like Scratch. I know a lot of people who do not consider themselves software developers that use Python from time to time. My BIL is a biology phd and he writes some Python when doing data analysis and other misc things for his research plus, PyTorch (a Python framework), is very popular with the AI academic crowd. I like Python ok but am no expert and definitely not a super fan or anything, it's certainly versatile and good enough in a lot of cases though. Java being #2 isn't surprising, there's just so much of it out there. It's like sanitation services, in the software dev trends world no on really notices Java or gives it much attention but it's out there every day doing a very important job and you would certainly notice if it stopped.

I encounter (and write) a lot of Javascript in my day job. Javascript is like a crazy girl/boyfriend. When it's good it's great but when it's bad, man, is it bad. I have mixed feelings about it.

btw, HTML and SQL aren't programming languages

 

[Handeman]

I think that list was more about popularity and had nothing to do with how good or bad the language is. Actually, all the languages are both good and bad. It all depends on what you are using it for. Kind of like screwdrivers, phillips, flat, square, star, etc. You have to have the right tool for the job.

 

[tHoagland]

My kids will be learning some Python in middle school this year it seems to be the next step after the graphical setups like Scratch. I know a lot of people who do not consider themselves software developers that use Python from time to time.

This is what makes Python so powerful. It's easy enough to teach a middle school student, capable
of powering the backend of some of the of some of the world's largest websites, and flexible enough for all manner of data science.

Like Handeman said, the right tool for the right job. But, if I only get one tool, it's Python.

 

[John Kemker]

I learned Python in order to write monitoring software for a pure software phone switch. It's actually how I learned how to program OOP. I love how Python is, to a degree, self-documenting. At least, a lot more self-documenting than most other languages I've used. DEFINITELY a lot more self-documenting than MUMPS.

 

[Handeman]

I've found that too many programmers don't document their code very well. I learned to document extensively after writing MS Access applications with Visual Basic for Applications and going back to code I'd written 2 - 3 years previously and having to reverse engineer it because I didn't comment it well and totally forgot how and what the code was doing.

Most companies have standards on how code should be commented, but hobbyists don't. I was taught about commenting my code back in the mid-80s when I got access to Basic programming on a mini-computer system. I've developed my own way of doing comments as the computers and languages evolved. I think all code segments should include a general header explaining what that code is doing, what subs and objects it uses, where it's used, how it's used, and how to call it. Then each loop and structure should have comments that explain what they are doing and how they work. You can never have too many comments, especially when creating or using objects in OOP languages.

 

[ep29030]

Long live TurboBASIC and TurboPASCAL! And if you don’t have those, just do assembler.

 

[BDB]

I'm just sad BASIC didn't make the list.

I can tell you that the majority of our grad students are proficient in either Python or R. Most use a combination of both for their research.

 

[ep29030]

I've found that too many programmers don't document their code very well. I learned to document extensively after writing MS Access applications with Visual Basic for Applications and going back to code I'd written 2 - 3 years previously and having to reverse engineer it because I didn't comment it well and totally forgot how and what the code was doing.

Most companies have standards on how code should be commented, but hobbyists don't. I was taught about commenting my code back in the mid-80s when I got access to Basic programming on a mini-computer system. I've developed my own way of doing comments as the computers and languages evolved. I think all code segments should include a general header explaining what that code is doing, what subs and objects it uses, where it's used, how it's used, and how to call it. Then each loop and structure should have comments that explain what they are doing and how they work. You can never have too many comments, especially when creating or using objects in OOP languages.

Nice to know that lack of programming comments is not new—it was also bad 30 years ago. The standard response to this was “if you want to know what it does, read the code”. Then, I remember reading a funny article where a guy wrote at length about how to write code that only he could untangle—so they would always hire him back to make updates.

 

[jderimig]

Sad to see Forth so down on the list. I used in the 80's, I though it was the next great thing.

 

[robopup]

I've found that too many programmers don't document their code very well. I learned to document extensively after writing MS Access applications with Visual Basic for Applications and going back to code I'd written 2 - 3 years previously and having to reverse engineer it because I didn't comment it well and totally forgot how and what the code was doing.

Most companies have standards on how code should be commented, but hobbyists don't. I was taught about commenting my code back in the mid-80s when I got access to Basic programming on a mini-computer system. I've developed my own way of doing comments as the computers and languages evolved. I think all code segments should include a general header explaining what that code is doing, what subs and objects it uses, where it's used, how it's used, and how to call it. Then each loop and structure should have comments that explain what they are doing and how they work. You can never have too many comments, especially when creating or using objects in OOP languages.

I used to be a big fan of comments on everything, but I've dug through enough large, legacy codebases with hundreds of developers touching things that I'm not so sure anymore. I've read comments where the author went nuts and commented every single simple two line for loop (distracting), comments which didn't get updated when some implementation below changed (misleading) and comments which flat out didn't properly describe what was going on below. At best, I take many comments with a grain of salt now. Unfortunately, I think the cliche "read the code" is the only guarantee.

Having said that, I really appreciate a few sentences of documentation in plain english explaining the intent behind large sections, best practices for api etc. Also a quick comment for some short line which is convoluted for some necessary but non obvious reason.

I think well written code can be very self documented, but this requires consistency, short descriptive functions, clean management of scope and very intentional about classes and datastructures etc. Also, I usually find OOP languages to be more self documented, not less...

 

[John Kemker]

Nice to know that lack of programming comments is not new—it was also bad 30 years ago. The standard response to this was “if you want to know what it does, read the code”. Then, I remember reading a funny article where a guy wrote at length about how to write code that only he could untangle—so they would always hire him back to make updates.

That sounds a lot like the VA developers, especially the Radiology package.

As the resident systems manager/DBA/lead programmer for the Atlanta VAMC during the 90s, I got into the guts of most of the software that comprised what we used to call DHCP, Decentralized Hospital Computer Program. (We renamed it when Micro$oft named their version of BOOTP Distributed Host Configuration Protocol. We renamed it ViSTA. /sigh) Our Radiology transcriptionists hated the line-oriented editor that came with DHCP, so I took a version of Kermit that had been written in MUMPS, WordPerfect, and some custom programming to write an app that allowed them to transcribe using WP, upload it into DHCP, then associate it with a Radiology record so it would be stored in the database. Reading the Radiology code was painful, to say the least. It was obvious that the developers wrote code to ensure long-term employment, not ease of maintenance. That's what you get when you have MDs, Dentists, Nurses, and Dietitians writing code to run a hospital.

 

[ep29030]

That sounds a lot like the VA developers, especially the Radiology package.

As the resident systems manager/DBA/lead programmer for the Atlanta VAMC during the 90s, I got into the guts of most of the software that comprised what we used to call DHCP, Decentralized Hospital Computer Program. (We renamed it when Micro$oft named their version of BOOTP Distributed Host Configuration Protocol. We renamed it ViSTA. /sigh) Our Radiology transcriptionists hated the line-oriented editor that came with DHCP, so I took a version of Kermit that had been written in MUMPS, WordPerfect, and some custom programming to write an app that allowed them to transcribe using WP, upload it into DHCP, then associate it with a Radiology record so it would be stored in the database. Reading the Radiology code was painful, to say the least. It was obvious that the developers wrote code to ensure long-term employment, not ease of maintenance. That's what you get when you have MDs, Dentists, Nurses, and Dietitians writing code to run a hospital.

Sounds like the Therac-25 disaster. Therac-25 - Wikipedia

 

[John Kemker]

Sounds like the Therac-25 disaster. Therac-25 - Wikipedia

Not quite.

The Radiology package did not control any equipment. It was a record-keeping and scheduling package for the Radiology department. The software worked, it was just intentionally poorly-documented.

None of the VA's software controlled equipment. Even the Lab package, which talked to equipment, only received data from the equipment and recorded it as part of the VA's Electronic Patient Record.

 

[Joel Shepherd]

I've found that too many programmers don't document their code very well.

Mostly to their own detriment. Personally, I find the main value in writing code documentation is to clarify my own understanding of the code I’m working on. I’ll document a class, a method, etc., reread what I wrote, and about half the time realize that the code doesn’t quite line up with the comment, semantically. So then, I have to think about both for a bit, figure out which one is confused, correct it and try again. Describing something using a different style of language— code vs comment, form vs summary, narrative vs bullet points— forces your brain to slow down and think, not just spew lines of code that you think you understand … but that you probably don’t, at least not as well as you assume.

If that doc is useful to someone else later, great, but I find that I can’t write high quality code without writing high quality doc with it.

 

[neil_w]

Sad to see Forth so down on the list. I used in the 80's, I though it was the next great thing.

I was impressed it made it onto the list at all. No such love for APL.

Actually, all the languages are both good and bad.

Not all of them.

 

[cls]

The truly intentionally worst programming language of all time is INTERCAL. Check it out, around 4:30 to 7:00 in above video. (Invented by Jim Lyon btw)