Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Stats Programming Python

C Drops, Java (and Rust) Climb in Popularity - as Coders Seek Easy, Secure Languages (techrepublic.com) 108

Last month C dropped from 3rd to 4th in TIOBE's ranking of programming language popularity (which tries to calculate each language's share of search engine results). Java moved up into the #3 position in September, reports TechRepublic, which notes that by comparison October "saw relatively little change" — though percentages of search results increased slightly. "At number one, Python jumped from 20.17% in September to 21.9% in October. In second place, C++ rose from 10.75% in September to 11.6%. In third, Java ascended from 9.45% to 10.51%..."

Is there a larger trend? TIOBE CEO Paul Jansen writes that the need to harvest more data increases demand for fast data manipulation languages. But they also need to be easy to learn ("because the resource pool of skilled software engineers is drying up") and secure ("because of continuous cyber threats.") King of all, Python, is easy to learn and secure, but not fast. Hence, engineers are frantically looking for fast alternatives for Python. C++ is an obvious candidate, but it is considered "not secure" because of its explicit memory management. Rust is another candidate, although not easy to learn. Rust is, thanks to its emphasis on security and speed, making its way to the TIOBE index top 10 now. [It's #13 — up from #20 a year ago]

The cry for fast, data crunching languages is also visible elsewhere in the TIOBE index. The language Mojo [a faster superset of Python designed for accelerated hardware like GPUs]... enters the top 50 for the first time. The fact that this language is only 1 year old and already showing up, makes it a very promising language.

In the last 12 months three languages also fell from the top ten:
  • PHP (dropping from #8 to #15)
  • SQL (dropping from #9 to #11)
  • Assembly language (dropping from #10 to #16)

This discussion has been archived. No new comments can be posted.

C Drops, Java (and Rust) Climb in Popularity - as Coders Seek Easy, Secure Languages

Comments Filter:
  • by vadim_t ( 324782 ) on Sunday October 13, 2024 @10:04AM (#64860741) Homepage

    Why is TIOBE still talked about? Their data is complete nonsense. Don't believe me? Look at how it's made:

    https://www.tiobe.com/tiobe-in... [tiobe.com]

    It's basically searching for "$LANGUAGE programming" on various search engines, then taking the "5 million results found" counts. After that they use some fudge factor they seem to have come up by themselves. Why is google.com worth 7.69%? Why is Wikipedia the second in the list, do mentions on Wikipedia go up and down by language popularity? Why is google.co.uk in the list, when it also returns English results?

    Does Google even promise that the result count they display is remotely accurate?

    Let alone that this barely means anything if it worked because it's trivial for anyone to inflate counts by encouraging the use of the term, or it can also go down if some prominent site happens to go down.

    It's an absolutely terrible metric and I don't understand why anyone cares about it. At least try to be remotely accurate. Look at Stack Overflow activity. Look at commits on Github. Look at subreddits. Something that indicates actual usage at a given point in time.

    • by Entrope ( 68843 )

      The "why" is right there in the name: The Importance Of (click-)Baiting Engagement.

      I also find it interesting that the focus is in easy and safe languages. Nobody cares about developer productivity or flexibility these days? Usually, you compromise on two -- and at least one -- I irder to get the other two.

      • It at least helps keep the over-hyped fanboy languages from widespread use in critical systems.

        They should post a comparable list looking at what languages are in actual job postings.

        • by Creepy ( 93888 )

          I don't know - Python is a pretty fanboy language that is pretty effed up still for commercial use. It is a really good scripting language, despite my hatred for certain design things (I hate whitespace/tab syntax. Makefile, I blame you). I don't know if it is the language or the programmers (HIGHLY likely), but I've found serious security issues with code written in it. Again, programs written by non-programmers, but they fired 90% of the programmers and just use coders... I'm now in IT because I'm too exp

    • Why is TIOBE still talked about?

      I'm assuming because someone is paying for it to be talked about. As you've pointed out it's data based on completely bogus metrics, which usually means they started with the conclusion they wanted and found a way to reach it. Then shitty media companies desperate for any dollars they can get feature stories about this research so that it gets some eyeballs on it. Then they throw a few nickels at the tail-end of the media-human-centipede and get /. editors to post it here because no one actually reads the c

      • I'm assuming because someone is paying for it to be talked about.

        That's my conclusion by now as well.
        On and off I posted about how I can't understand why this is "news" _every month_

        Now my guess is that Tiobe pays slashdot somehow.

    • I don't mind because it causes people to discuss programming languages and I can pick up pointers about what's good and bad about each.

      There should be a monthly list of popular programming paradigms and methods.

    • Why is TIOBE still talked about?

      The Fucking Headline (TFH) is nothing but clickbait. Wasn't that enough to answer your question? Seriously, /. gets these "stories" about once a week.....

  • Java? Rust? Get serious, world. Does Mommy massage your wrists while you type, so her pwecious angew doesn't get carpal tunnel? If you're not managing your own memory, are you even really programming? Ideally, I'd like a language that lets me adjust my own voltage and Hertz.
    • by narcc ( 412956 ) on Sunday October 13, 2024 @11:34AM (#64860853) Journal

      Cartoonish machismo aside, the belief that you don't need to think about memory when using a managed language is a real problem.

      • What are you thinking about in terms of memory when using a managed language? If you open your resources using the try-with-resources mechanism, any system resources get automatically closed. The garbage collector largely takes care of everything else.

        If you have performance constraints, you might find yourself using native arrays which are *much* faster. And, in that case, you need to check bounds. Of course, if you do mess up, you'll get a helpful stack trace which will make fixing the bug trivial.

        • by narcc ( 412956 )

          *facepalm*

          This, folks, is why modern software is such a shit show...

        • You still have to think about a lot of memory-related things to make applications memory-efficient and free of memory leaks.

          For example, somewhere in my code, I might have a map from sockets to users, to keep track of which user is authenticated on any given socket. However, I need to either make absolutely sure that I am removing mappings from that when a socket terminates through any means - even unclean ones - or, I need to use weak references to make the garbage collector do that for me. The fact that j

          • I specifically mentioned system resources. For any non-trivial application, the mapping of authentication to sockets should be a miniscule part and it only applies if your application absolutely needs to use raw sockets. If you can use Websockets over https, the entire thing can be managed by the Servlet infrastructure (part of the Java standard) and you won't have to think about that at all.

            You really don't need to think about interning strings. Any string constants in your code get automatically inte

            • you won't have to think

              You really don't need to think

              If you find yourself thinking

              The job of a programmer *IS* to think. Specifically, to think about the operations required to complete a task, what is the most efficient way to perform those operations (and in what order), and how to perform those operations securely.

              Your post reads like a mockery of the position. The kind that would encourage doublethink. Such politicization will not protect your user's data when your program fails due to bad design. Nor will the language itself. Only proper well thought out design will do that, and

              • The job of a programmer is, of course to think. Primarily about the problem that the software they are developing is intended to solve. Human beings only have limited thinking capacity. By spending less time thinking about string interning (yawn) and more time thinking about how to best meet the need of the business who is paying for the work, a programmer makes themselves much more valuable.

                But have fun thinking about how to write your own bubble sorting algorithm or whatever. I'm going to go think

            • Sorry but this is still wrong on a number of counts.

              I specifically mentioned system resources. For any non-trivial application, the mapping of authentication to sockets should be a miniscule part and it only applies if your application absolutely needs to use raw sockets. If you can use Websockets over https, the entire thing can be managed by the Servlet infrastructure (part of the Java standard) and you won't have to think about that at all.

              GGP did not limit the scope to just system resources. System resources are usually not the issue anyway. Nobody says that an app is a "resource hog" because it left a few file descriptors open. They say it's a resource hog because it's using 4GB of RAM to do nothing. The socket to user mapping is merely an example - you're supposed to extrapolate it to whatever use case you have.

              You really don't need to think about interning strings. Any string constants in your code get automatically interned by the compiler (which is why you shouldn't use them as lock objects.) If you're really worried about saving a few bytes of memory, put your strings in a HashMap.

              You absolutely should be thinking about this. I can tell you've probably never

    • by Kisai ( 213879 )

      The only languages that matter are C (which you are required to know if you want to use any existing software library.)

      You can learn any scripting language (eg Javascript, PHP, Perl, Python) and you will generally understand how it works before the idiots inflating the version numbers start core-rotting the language with features that belong in C++ not a scripting language.

      Like good god , "WebASM" was the worst possible thing to exist, now you get people porting their rubbish code from "language and engine

      • Yes, you can install more than one JRE. I have Java 8, Java 16, Java 17, and Java 21 on my development box. I run Minecraft as a player with Java 8, Java 16, and Java 21.

      • by Pieroxy ( 222434 ) on Sunday October 13, 2024 @02:43PM (#64861307) Homepage

        nobody should be using Java to develop anything due to Oracle's meddling.

        Nobody in their right mind uses Oracle's JVM or JDK. Everyone uses OpenJDK which is 100% open source thanks to Sun Microsystems open sourcing it before Oracle bought them. Oracle is *nothing* in the Java world, as and their potential discontinuation of the JRE would greatly benefit the Java community.

        You should talk about stuff you know. You draw conclusions based on fantasies, no wonder they're completely off base.

      • by Ed Tice ( 3732157 ) on Sunday October 13, 2024 @02:45PM (#64861311)
        Who cares if your JRE gets discontinued? You can run older JRE code on newer JREs just fine. Or if you don't like that, you can keep an older JRE around.

        With Java, you don't have to recompile for different architectures. If you have old C code around and want to run it on a newer architecture, you have to recompile. And your code might not compile with the latest compiler. And the older compiler might not be available for a new architecture, so you're stuck.

        With Java, you just copy the JAR file anywhere and run it.

    • Makes no sense to compare rust to java in this regard. You very much manually manage memory with rust, however most of it is done implicitly through better semantics.

      C++ developers complain about it because they don't understand the concept of implicit destructive move semantics -- one here referred to the idea as "cretinous" because he's used to C++ moves, which are fucking bonkers, just like everything else in that language. As Linus Torvalds and Drew Devault have said: It's a language only enjoyed by bad

  • ...of CHEAP software engineers is drying up
    Companies prefer tools that allow cheap and low skilled coders to quickly churn out mediocre code

    • If the code isn't core to the function of your business, this is a wise choice.
  • by Somervillain ( 4719341 ) on Sunday October 13, 2024 @10:19AM (#64860757)
    I care about what employers choose. I like to get paid. New programming languages honestly rub me the wrong way as every person I've ever met who pursues new languages does so as a substitute for mastering an older one. Most people who have written in 10 languages have never mastered a single one. If you know what you're doing?...the old languages are perfectly fine.

    For me, libraries make a much bigger difference than languages. Java is my main language and there are dozens of things it can do better....but I rarely write PURE Java. Most of what I've ever needed to do has been written and is in a library somewhere. I spend more time assembling library code than writing pure Java. But even when I do...it's fine...some languages do things maybe 5-10% better, but it really never adds up.

    I will wager that if Rust is a night and day difference for you, then you didn't learn your old language correctly. Certainly, that was the case for everyone I've ever met who jumped ship to node.js and Python.

    Great...you improved your productivity slightly by moving to Python/node.js/Rust...now you can write novice code even faster?
    • Re: (Score:1, Insightful)

      by Anonymous Coward

      Most of what I've ever needed to do has been written and is in a library somewhere

      Oh, you're one of those... Gluing hundreds of libraries together, along with their hundreds of dependencies, is the reason that software is so bloated and slow these days.

      Libraries should be used sparingly, only for things that it doesn't make sense for you to do yourself. Libraries are coded for the general case, not the specific. It's going to be larger and slower. If your use case wasn't one of the ones the library authors foresaw, you're going to have some ugly hack to make it work the way you want,

      • Libraries are coded for the general case, not the specific. It's going to be larger and slower. If your use case wasn't one of the ones the library authors foresaw, you're going to have some ugly hack to make it work the way you want, probably involving another needless library.

        No, you're not saving time. More often than not, the time it takes to find, vet, and learn a library for whatever it is you're trying to avoid doing takes significantly longer than just doing the job yourself.

        No, you're not making your code more secure. As we've learned, just because a library is popular doesn't mean that it's secure. If anything, its popularity makes you more vulnerable, not less.

        If you're making such bold statements, you either misunderstood what I said or you don't understand how modern runtimes work. For Java specifically, only the classes used are loaded, not the whole jar. You can have a 1GB jar in your classpath (if one existed), but only the classes called are loaded into memory. So importing a large library, but only using a few classes, is no real tangible penalty...especially on a server. Secondly, you assume I import more than I need. I don't.

        The whole reason a company hires a developer with my experience level is because ideally someone who has been doing this as long as I have knows when to use an existing library and when to write their own implementation. Also, due to both my high standards and the use of automated tools my company set up as well as the ones I run, unneeded imports and dependencies are purged.

        You specifically mentioned libraries designed for broad purposes rather than specific ones. Modern JIT compilers, like the JVM, optimize for use case, so while my code may be simpler and more beautiful....I can't benchmark a difference...I've tried....unless the algorithm is fundamentally different and you're explicitly telling the runtime to do more, complex code runs at the same speed as simple code, when given the same instructions. So you may scoff at that Apache library that was designed to do 20 things when you only need it to do 5, but have you actually tried benchmarking your work? I have...the difference disappears within a dozen executions and everything people have ever paid me to do is business code running on servers for thousands to billions of users.

        Believe me, I wish what you said was right. I'd love to get paid to reinvent the wheel and show off how much faster my beautiful code is than those decades old libraries written by specialists....too bad the JVM disagrees. I'd love to solve old simple problems in faster ways than do what my employer paid me to do, which is solve their business problems.

        So yeah...I would wager I've been doing this much longer than you have....and if not...well, then I will also wager I do a better job than you do if you think we should reject most libraries in favor of writing our own implementation. There's time to market, performance, security, as well as long-term maintenance. Have you seen what happens to your code 5 years later? 10 years? How about 15? I have seen code I wrote almost 20 years ago still in use today, having changed hands a dozen times, been modified many times and evolved....that's why I use standard libraries. I know what is easier to maintain by strangers I will never meet.

        Anyone who pays me money wants to get a return on their investment...and having something that is easy to maintain, reliable, and secure is far more important than any minuscule performance improvements an individual can write....if you even could...which I seriously doubt....why?...because I've tried myself. I've tried writing methods that are a fraction of the functional complexity, highly optimized, and I even tried both highly threaded and not...the JIT optimized the standard library to the point where no one could tell the difference.

    • Re: (Score:3, Interesting)

      by ctilsie242 ( 4841247 )

      I have found that you can have years to decades of experience, but in my experience with job hunting, if you don't have experience in that language, even though it is like 100 other languages, but written by a startup so they can make money on support of it, you get shown the door. I wouldn't be surprised to see another language popping up out of nowhere and becoming the latest "fad", just because C-levels will demand it used just to keep up with the Joneses, and we get a generation of programmers who know

      • Re: (Score:2, Insightful)

        by SirSlud ( 67381 )

        "The funny thing is that C and C++ have so many tools to check for pointer issues, and dangerous function calls like scanf(), that show-stopping memory leaks or buffer overflows is pretty much past us, other than for legacy code."

        Holy fuck I can tell you don't actually make software for a living

      • I have found that you can have years to decades of experience, but in my experience with job hunting, if you don't have experience in that language, even though it is like 100 other languages, but written by a startup so they can make money on support of it, you get shown the door.

        It honestly sounds like you're making my point rather than rebutting it. The employer chooses the language and technology in nearly all cases. It's extremely rare for a company to hire an experienced developer and have no opinions on what platform they want the work written in. In fact, I don't think I have ever been hired to write an application where there wasn't already some code in place. Thus, I don't care what brings joy to developers. I am a professional. I go in and write what I am told to writ

    • by jma05 ( 897351 )

      > I will wager that if Rust is a night and day difference for you, then you didn't learn your old language correctly.

      What do you think is the percentage of C++ programmers who can be trusted to write safe code, empirically? Every study shows Rust code is safer, significantly, with no loss in performance or productivity.

      C is a night and day difference from assembler. Would you blame C programmers for not knowing how to write assembler safely? C++ to Rust is just progress, just as assembler to C was.

      There

      • What do you think is the percentage of C++ programmers who can be trusted to write safe code, empirically? Every study shows Rust code is safer, significantly, with no loss in performance or productivity.

        Aren't you making my point? If the C++ programmer isn't skilled enough to safely work with C++...well...should they be writing in C++? I have never been a professional C++ programmer, so I will leave it at that...maybe rust is superior.

        However, I am a professional Python and Java developer. Python has SEVERE maintenance issues and if you were a professional, you would know this too. Yeah, it's nice...it's easy to get out the door. Here's the problem...you're a Python rockstar, you write a nice appli

        • by jma05 ( 897351 )

          I don't disagree with any of that. My experiences are similar.

          I am not suggesting that Python is a panacea. In fact, it has the worst technical foundations among the currently popular languages. Java is better for business apps. Python is generally better for scripts, science and analytics.

          My point was that Rust is better than C++ in most cases. Nim and mojo are other interesting alternatives which likely won't get that level of traction.

  • C is still great (Score:5, Insightful)

    by Uecker ( 1842596 ) on Sunday October 13, 2024 @10:39AM (#64860773)

    IMHO C is still one of the most useful languages and perfectly fine even for large projects (why should this have changed suddenly after many decades?).

    Safety is an issue but there are also many great tools to help with this and which get better continuously (e.g. GCC's analyzer), and the alternatives have their fair share of problems too.

    • by gweihir ( 88907 )

      Indeed. The problem with C is mostly people that try to code in it while not being sufficiently competent. It is absolutely no problem to code defensively in C and to not screw up. But it requires real insight to do so. The good thing about C is that the really incompetent will not even get their code to compile. But that turns out to be a too low bar.

      • The problem with C is mostly people that try to code in it while not being sufficiently competent

        Exactly! No one should ever write a line of C until they're an expert.

        • by Uecker ( 1842596 )

          I work a lot with inexperienced programmers and this is not a problem. But they need some good examples, some guidance what not to do, and need to use good tooling (C has excellent tools). The idea is that nobody (or only experts) can write good C code is wrong. Of course, this is part of the foundation myths of certain other languages..... And don't get me wrong, there is certainly a huge amount of really bad C code out, but this does not mean it is fundamentally difficult to write reasonable C code w

          • I was making a sarcastic comment about the parent post. How is someone supposed to become sufficiently competent in a language before they start writing code in that language?

            I imagine what they were trying to say is that they shouldn't be releasing code or contributing to releases until they're sufficiently competent. But the Dunning-Kruger Effect leads to people believing they're far more competent than they actually are. If a programming language has that high of a barrier to entry, then it's proba
            • by gweihir ( 88907 )

              Have you looked at Rust? It requires a lot more skill and experience to use it competently than C does.

              • You are absolutely correct. At the same time, when using Rust incompetently, the program will often fail to compile. I prefer this method of failing to compile rather than allowing compilation and leaving it to me to (hopefully) find the bugs later. Of course, I sacrifice the level of control I have over the software, but for my tastes that sacrifice is worth it. And C remains a great option for people who feel otherwise.
  • All languages as the final step of their compilation are rendered into assembly language. All the low-level bits of an OS that deal directly with the hardware are also written, at least partially in assembly language. Ditto low-level library bits like memcpy. Assembly language is the giant upon whose shoulders all else rests.
    • Everything you write in assembly, you can write in C, or Pascal, or Oberon or Ada ... and so on.

    • All languages as the final step of their compilation are rendered into assembly language. All the low-level bits of an OS that deal directly with the hardware are also written, at least partially in assembly language. Ditto low-level library bits like memcpy. Assembly language is the giant upon whose shoulders all else rests.

      Why are you obscuring how the computer really works with a bunch of human constructs like symbols, mnemonics and labels?

      Computers work exclusively with binary numbers. You need to look directly at the bits to fully understand your code.

      Preferably, you should exclusively use rows of toggle switches and neon indicators to interact with your system.

      • All languages as the final step of their compilation are rendered into assembly language. All the low-level bits of an OS that deal directly with the hardware are also written, at least partially in assembly language. Ditto low-level library bits like memcpy. Assembly language is the giant upon whose shoulders all else rests.

        Why are you obscuring how the computer really works with a bunch of human constructs like symbols, mnemonics and labels?

        Computers work exclusively with binary numbers. You need to look directly at the bits to fully understand your code.

        Preferably, you should exclusively use rows of toggle switches and neon indicators to interact with your system.

        I mean, ostensibly, we have been there and have done it that way in the past. The discipline has evolved with newer tools and better techniques, but at the end of the day if you are writing performance-critical software, stuff that needs to be hard realtime (not as uncommon as a lot of people think) or work in resource constrained environments (again, way more common than a lot believe) it is still not uncommon to drop down into assembly to hand-code things where you need absolute control of the instruction

  • WTF is with (all of the parens)? [Why not take it to the next level with some brackets too?]

    Maybe (it's all) [bullshit] anyway.

  • by quonset ( 4839537 ) on Sunday October 13, 2024 @11:29AM (#64860845)

    For all you coders, a list [imgur.com] of programming languages and how they work.

    • Still missing the panels showing the horse built in C both looks good and is fast (but should not be ridden by a fat jockey).

      Not to mention it'll translate between all the other horses, as well as ponies and donkeys.

    • by shanen ( 462549 )

      Funny enough, but I thought it was going to be a list of "How to shoot yourself in the foot using <language>" jokes. Predates Rust?

  • by gweihir ( 88907 ) on Sunday October 13, 2024 @11:35AM (#64860861)

    Good coders will code in whatever suits the task best. Bad coders do follow-the-hype and often cannot even really go to another language on short notice.

    That said, Rust is still niche and will remain niche. It is too complex and requires too much experience with different coding concepts to be accessible to bad and mediocre coders, and these are the vast majority. That is not to say it is a bad design. I had a look at it a while back and it gets some things right, like prevalent immutability, functional concepts, dropping of "classical" OO (which never delivered on its promises, but made everything more complex) and some other things. But the average (and worse) coder is not on a skill-level to be really able to leverage these features competently. So, nice as a systems language (if you ignore the defective woke "community"), but it will never be mainstream.

    • Re:Not really (Score:4, Interesting)

      by Uecker ( 1842596 ) on Sunday October 13, 2024 @12:11PM (#64860973)

      Rust has some good ideas. But for my taste it is far too complex. With respect to C it has essentially thrown out the baby with the bathwater.

      Other problems I have with Rust are: long compilation times, instability of language and dependencies, the supply-chain disaster that is cargo.

      Marketing wise I find it annoying that they pretend that memory safety is the only important thing and that they like to compare safe Rust to arbitrary C (no tools for improving safety) when talking about safety and compare C to unsafe Rust when talking about speed, which I think is not entirely honest.

      • Marketing wise I find it annoying that they pretend that memory safety is the only important thing

        Well, that is pretty much its only real selling point...

      • by gweihir ( 88907 )

        Yes. The Rust propaganda and the claims of its community are dishonest on an advanced level. Or maybe they are simply collectively delusional.

      • the supply-chain disaster that is cargo

        That is certainly a matter of opinion. I love the fact that I can quickly download and build a project to make some small tweaks without having to spend hours of frustrating work manually identifying and installing all of the exact versions of the dependencies necessary to build the project. Almost anyone who has worked with a modern language will find the process of starting development on a mature C/C++ project to feel absolutely archaic. I'm not even that big of

        • by Uecker ( 1842596 )

          I usually use apt-get to install my dependencies, which works flawlessly. But yes, this is then a then on the level of Linux distributions.

          But my issue with cargo is not that it makes installing dependencies easy, but that it is an essentially un-curated list of unstable code that changes all the time, where a project might not actually be associated with the repository that it claims to be, can run arbitrary code as your users during compilation, and hides in a hidden directory in your home directory. (A

          • I usually use apt-get to install my dependencies, which works flawlessly. But yes, this is then a then on the level of Linux distributions.

            The issue is how do I know which dependencies I need? Sure, that should be in the documentation, but the docs are often non-existent or very out-of-date. And which package contains the dependency (packages are named differently across Linux distros)? And which version of the dep do I need? And how do I get that version if my distro doesn't offer it? Cargo, like the

            • by Uecker ( 1842596 )

              apt-get build-dep installs all build dependencies of a package.

              Regarding the issues, the first is obvious, for the second see the recent Rust foundation activity report, for the third see proc macros and Rust build scripts, and I think the last is known.

              • Using apt-get build-dep won't work if you're attempting to build software that is not included in your distribution. The software may not have a release yet, may not be popular enough to get picked up by your distro, may be intended to run in a Docker container, etc.
                • by Uecker ( 1842596 )

                  cargo only installs software which is in cargo. That is very easy go list software there because there is no quality control is part of the problem.

  • TIOBE (Score:3, Interesting)

    by Scythal ( 1488949 ) on Sunday October 13, 2024 @11:37AM (#64860867)
    TIOBE has always shown strange results. Just comparing to a more reliable source as StackOverflow's yearly survey shows how unreliable counting hits can be. For all you know, more hits could be due to people having problems with it or the buzz made by some government about good languages for security. News can be amplified by random outlets, which makes the principle fundamentally flawed. I'm surprised some people are still basing their articles on that index.
  • by Ronin Developer ( 67677 ) on Sunday October 13, 2024 @12:20PM (#64860989)

    They don't mention that the 27 year old language, Delphi, has risen into the top 10 and displacing those so-called wonder languages.

    Delphi's Object Pascal is very capable, easier to read and write over Rust, quick and backwards compatible with older code.

    Still, Tiobe, goes to great measures to ignore it for years.

  • by 93 Escort Wagon ( 326346 ) on Sunday October 13, 2024 @01:16PM (#64861107)

    I was worried someone might forget.

  • hard.

    The smarter the tool the dumber the operator. That's the point of tools, isn't it?
    Then of course, the cheaper the operator is too... as pointed out above.

    Look at "network operations centers" now. I read a few of the job postings lately for fun and they want a monkey to "monitor alarms" .. I'll pass Homer's resume along... he's been in that job at the nuclear plant for over 30 years, must be getting bored by now... ...and if you think about it, automating those button pushing monkeys with "AI" will be a
    • What is wrong with monitoring alarms? Somebody has to triage the outages. If you do this with a shell script (possible), you have to continuously maintain the shell script. And if the script has a problem, you have exactly one person to call (the person who maintains it.) If you, instead, put a human in the NOC, it's much easier to make changes and they can handle unexpected conditions. The reason you have a NOC is because you care about reliability.
      • Sure, but my point is this is a Homer Simpson level job. If the red light flashes, press that button over there. Yes, a monkey could be trained to do it.

        You don't hire pricy brains to do that, you want a large pool of cheap labour, so the guy sitting there has virtually no training beyond a Cisco or similar certification, and the job is procedural, so he's going to have respond using a pre written script. If a truly unexpected condition comes up, he excalates to the more brainy people.

        That is truly the low
        • No, because the automation would tend to have correlated failure with the underlying systems failure. And yes, you would hire somebody with very limited skills. At a good employer, that person would build skills. At a bad employer, they would never progress in their career no matter how motivated they are.
  • by Tablizer ( 95088 ) on Sunday October 13, 2024 @04:16PM (#64861481) Journal

    Java is possibly up because C#'s libraries are getting bloated with async/await shit. Most projects are NOT web-scale. In addition to syntax bloat, it complicates debugging. Other approaches can handle occasional parallel tasks without bloating the 98% that doesn't need it.

    I like C# overall, but the async fad is F'ing its libraries. Java will be the beneficiary of asyc frustration. (Java & JavaScript, please add optional named parameters, one of C#'s best features, lovit! The workarounds/emulations are not good enough.)

  • What if the programming language I'm using is no longer popular? How will I face the other programmers at work? I desperately want to avoid becoming unpopular or ostracized by my peer group.

  • The article mentions the need for data manipulation languages. Wasn't COBOL designed for this? We keep saying COBOL needs to die, but does it? Maybe it just needs to modernize.

I'd rather just believe that it's done by little elves running around.

Working...