Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Stats Programming

2019's Fastest Growing Programming Language Was C, Says TIOBE (tiobe.com) 106

Posted by EditorDavid from the C-you-later dept.
Which programming language saw the biggest jump on TIOBE's index of language popularity over the last year?

Unlike last year -- it's not Python. An anonymous reader quotes TIOBE.com: It is good old language C that wins the award this time with an yearly increase of 2.4%... The major drivers behind this trend are the Internet of Things (IoT) and the vast amount of small intelligent devices that are released nowadays...

Runners up are C# (+2.1%), Python (+1.4%) and Swift (+0.6%)...

Other interesting winners of 2019 are Swift (from #15 to #9) and Ruby (from #18 to #11). Swift is a permanent top 10 player now and Ruby seems [destined] to become one soon.

Some languages that were supposed to break through in 2019 didn't: Rust won only 3 positions (from #33 to #30), Kotlin lost 3 positions (from #31 to #35), Julia lost even 10 positions (from #37 to #47) and TypeScript won just one position (from #49 to #48).
And here's the new top 10 programming languages right now, according to TIOBE's January 2020 index.
  • Java
  • C
  • Python
  • C++
  • C# (up two positions from January 2019)
  • Visual Basic .NET (down one position from January 2019)
  • JavaScript (down one position from January 2019)
  • PHP
  • Swift (up six positions from January 2019)
  • SQL (down one position from January 2019)

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

2019's Fastest Growing Programming Language Was C, Says TIOBE More

2019's Fastest Growing Programming Language Was C, Says TIOBE

Comments Filter:
  • I've never even considered writing a program in SQL. I write programs in other languages that use SQL as needed.

    Then again, I've never written a program where the database was more than a glorified external storage

    • Re: (Score:3, Informative)

      by Tablizer ( 95088 )

      If you use it correctly, a database can process much of the domain logic also.

      • Re:Is SQL really a language? (Score:5, Interesting)

        by DogDude ( 805747 ) on Saturday January 11, 2020 @01:27PM (#59609992)
        Yup. Absolutely. You can (and in many cases SHOULD) put business logic in SQL because it's optimized like a kajillion times better than some high level scripting language. Most people don't know how to use SQL properly, though.
        • Omg, no!!!!! I can't even remember how many companies I've had to fix their idiotic use of the database as a business logic engine. holy fuck! There is a damned good reason by we have 3 tier architectures. Front end for display talking to browser/client, middle layer for BUSINESS LOGIC where it fucking belongs and DATA IN THE DATABASE!!!! which is purpose designed to store and retrieve data. O. M. F. G!!! Stop putting business logic in the database!!!!! What a fucking mess when you need to change log

          • Re: Is SQL really a language? (Score:4, Insightful)

            by Viol8 ( 599362 ) on Saturday January 11, 2020 @04:27PM (#59610348) Homepage

            Putting business logic in SQL is not the same as putting it in the DB you clown.

          • Re: (Score:1)

            by DogDude ( 805747 )
            I disagree. pl/SQL or TSql is designed for business logic, and it performs much better there than it does in some shitty scripting language. I fixed many systems by putting the business logic in the DB. It's just as easy to update as any other code, unless all you have are php kids that don't know SQL.

            • I have to agree with parent on this one. While initially it sounds like an incredibly good idea to put business logic within the database, there's just too many people who just suck at SQL. People who can actually think in relationships, sets, and domains can pull it off. But way too many people think in "row at a time" kind of thinking. There's just so much potential for mucking the whole thing. There's the overhead involved in serializing and sending the records into the layer that's doing the applic

              • Re: (Score:1)

                by malvcr ( 2932649 )

                I think that there is a generalized design practice in the industry: to model everything according with the tools you use.

                The right thing to do is to understand the problem, to device an "independent" solution (probably using math or a similar formal method), and then to go to check your paradigms and tools to see how to make that solution a reality.

                Because tools become obsolete, paradigms are surpassed by new ones, but a problem is a problem that use to continue being a problem. So, the solution must

          • Re: (Score:2)

            by tepples ( 727027 )

            Front end for display talking to browser/client, middle layer for BUSINESS LOGIC where it fucking belongs and DATA IN THE DATABASE!!!!

            What makes, say, PL/pgSQL an inferior language for implementing a middle layer?

          • Re: (Score:1)

            by Tablizer ( 95088 )

            Use the right tool for the job. Some business logic or parts of it is simpler and/or more efficient to implement as SQL, others as imperative logic.

        • Comment removed based on user account deletion

        • NOOOOOOOOOOOOOOOOOO.

          Anyone who really knows databases will tell you to let the database do what it's good at (respond to queries, full stop) and let the glue or intermediary language do everything else. EVERYTHING.

          Yes, I know people who calculate birth dates and and all sorts of other shit in PL/SQL, and they're doing it wrong.

          • I guess there are plenty of people who are mixing up business logic with business logic with business logic.
            There is plenty of things a database does better and faster and is completely clear logic, that belongs into the database layer.

            And dogmas, like yours, don't help anyone.

            A good example e.g. is a load profile, a 24h long time serial measured every 15 minutes, or every minute.
            Now at the end of the day, or before you hand in the schedule for the next day, you need a summary for a million or so profiles.

            • A good example e.g. is a load profile, a 24h long time serial measured every 15 minutes, or every minute.

              That's not what we're talking about. We're talking about writing some or most of the code that makes up some application. I've seen waaaaaaay too many things that are written in PL/SQL that should never have been written in PL/SQL.

              Just because you can write an application in PL/SQL doesn't mean you should. Just like I could use a hammer to drive in a screw, but that's not the way it should be done.

              "Let the database do what it does best", as Joe Celko [wikipedia.org] tells (told) his students over and over and over. (Yes, I

              • Well,
                I guess finding the balance between not abusing a (relational) DB pure datastore and not putting to much (or the wrong) logic into it, evolves only with experience. That is why I'm in a certain sense against dogmata ... albeit I'm in taching very dogmatic, lol.

      • Comment removed (Score:5, Insightful)

        by account_deleted ( 4530225 ) on Saturday January 11, 2020 @01:37PM (#59610010)
        Comment removed based on user account deletion

        • If you design the entire system properly from the backend to the UI, queries can be made very simple. The issue is with extreme paradigms, where you are constantly changing the business logic to accommodate some new required functionality. Depending on the project, after release, refactoring the database is probably a non-starter for adding new features, so you are left with having to kludge in performance at the query level.

    • SQL is a language that teaches you something (Score:5, Interesting)

      by raymorris ( 2726007 ) on Saturday January 11, 2020 @02:31PM (#59610096) Journal

      It's been said that a language that doesn't teach you something isn't worth learning. Learning to use SQL *well* will teach you new ideas that you can use, even in other languages. It's often the first declarative language people use, and even their first language that isn't yet another imperative procedural language.

      Languages such as JavaScript, PHP, Perl, and Python are all imperative languages. They are all procedural languages with a bit of OOP support. If that's what you think of when you think of programming languages, that's an important type of language, but only one of many types. You can learn a lot vy learning different types of languages, such as pure functional languages.

      If all of your SQL is "select blah from Stuff where id=that" and "insert into", that's roughly equivalent to "hello world". Important to learn, and not NEARLY all there is. I frequently write SQL statements that are a page long or longer, organized into CTEs or other structures.

      • Re:SQL is a language that teaches you something (Score:5, Interesting)

        by Antique Geekmeister ( 740220 ) on Saturday January 11, 2020 @02:58PM (#59610132)

        It's also almost all of SQL use in business. and science. It's almost entirely large-scale spreadsheet use. I have, personally, replaced several budiness databases with Excel spreadsheets because they could not be backed up, they could not be upgraded, and preserving the obsolete version of the database was far more expensive in time and resources than retraining people to use a large spreadsheet with proper backup policies.

        • Re:SQL is a language that teaches you something (Score:4, Insightful)

          by Known Nutter ( 988758 ) on Saturday January 11, 2020 @04:06PM (#59610278)

          I have, personally, replaced several budiness databases with Excel spreadsheets

          dafuq did I just read?

          • Wait until he comes to the idea that he can store the excel sheets a blobs in a database ... perhaps he even jumps imediately to a NoSQL database :P

        • Spreadsheets? Then you get versioning, source of truth and security issues. Why not use one of the several SaaS options?

          • Because the spreadsheets were enough for their needs, and were already being used by people who didn't like the complex and unstable one-off interfaces to the unreliable and expensive to support database.

            • Yeah I get why you killed the DB but why spreadsheet instead of a SaaS? There are several options available for SaaS multiuser real time shared, versioned, controlled, secure spreadsheeting from almost free like google all the way to true enterprise solutions that can support thousands of simultaneous accesses with ACLs and other fine grained controls, auto auto-backed up with version control and history.

              • Each case was somewhat different. For some, it predated modern web based SaaS as a business. For others, they had proprietary data which _must not leave the building_, which is how they wound up with internal proprietized database interfaces in the first place. For one, They found the spreadsheet very effective for generating precisely the charts they wanted without having to pay for another customized GUI and learning it, since they'd all done accounting work and learned Excel in the process.

                Providing larg

        • As the other person who replied said, dafuq?

          You aren't normally crazy or stupid, so I'm not sure what to think of this post. Can't be backed up? Dafuq are you talking about? mysqldump, or I Microsoft friggin CLICK "Backup" ....

          • Corrupt databases fail even the most basic backup or export procedures. I've encountered this kind of problem multiple times in my career, with open source and commercial database technologies which simply crashed when attempting exports of their content. This has included commercial MySQL, postgresql, Oracle, SQL, and the list goes on and on. It's particularly a problem when performing an inevitable database backup and upgrade. I've evolved some helpful practices and policies to avoid the issues, but it's

            • That makes a bit more sense. It almost sounded like you were saying SQL databases can't be backed up, which wouldn't make sense.

              Have you ever seen one where running "repair table" didn't bring it to a sane state that can be backed up?

              • Oh, my. Yes. That was very much the experience with each database I could not update or fix.

                • That's interesting. I wonder what the difference is between my experience and yours. I've only dealt with a couple thousand databases, you may have much more experience. Mine have MOSTLY been MySQL on Linux, and more recently Microsoft on modern Windows. You may have a lot more experience with older Microsoft.

                  • The larges _single_ MySQL environment I worked with was over 1000 distinct MySQL instances. It's not the one that had the problem. If I count all the individual ihstances on individual hosts or, these days, individual containers? It's over 1000 right now.

                    The largest deployment of databases was. Oh, oh, my. That was over 10,000 hosts using Berkeley DB. I didn't build it, but the "upgrade in place" and backup options weren't working. I had to convince the company that the fastest recover was to re-enter all o

            • Corrupt databases fail even the most basic backup or export procedures.

              If it's corrupt, why are you trying to back it up instead of restoring it from.....oh, I see. Never mind.

        • I have, personally, replaced several budiness databases with Excel spreadsheets

          What the fuck?

          1) Unless they were pure shit to begin with, you just made everything worse.

          2) How can you not be able to backup a database?

      • If your SQL queries are over a page long the your DB structure is non optimal for the data relationships you're trying to utilise. Plus queries that size can be a fucking nightmare to debug and can suddenly slow to a crawl if the optimiser takes a different path to what you expect one day. What's more they're highly sensitive to table and page locking issues.

        • > Plus queries that size can be a fucking nightmare to debug

          That's why you organize them, using things like CDTs, as I mentioned.

          You can write complex operations as a bunch of small queries and if those queries suck, performance will suck. You can write the same operation by nesting the queries and very often the optimizer will find ways to reduce it's work. If your queries suck, nesting them may not fix it (but it may, because the optimizer knows you aren't actually using a me of what you had asked fo

    • To answer your question: yes! (Score:4, Informative)

      by Somervillain ( 4719341 ) on Saturday January 11, 2020 @05:09PM (#59610432)
      You can write a LOT of useful code in the SQL extensions, like PL/SQL. I get in arguments about it all the time. A lot of shitheads at my giant company think that stored procedures are an anti-pattern....because none of them ever opened a book on the subject in their life and it's easier to be arrogant about your ignorance than to actually learn. It's easier to say "it's 2020 who uses SQL anymore?"...and then deliver something with a NoSQL DB that is no faster and is easily corrupted...that to know that Oracle, Cassandra, Mongo, Reddis, and every other major platform are useful tools with specific patterns where they shine and other situations in which they perform poorly and ineffectively

      Then they're shocked that I can take 10,000 lines of JPA and replace it with a 150 line stored procedure and take a process that takes them 2 minutes in JPA and do it in .6 seconds in a stored procedure.

      So yeah...SQL (and the extensions various platforms use to write stored procedures) is ugly and often misused, but when used by a skilled professional, can mean the difference between a project that scales and one that doesn't. It can mean the difference between success and failure. It is a tool that needs to be in the toolbox of every backend developer. It shouldn't be your first choice, but when it shines, it really blows any alternative out of the water.

      You can debate the specifics, but PL/SQL has flow control, variables, libraries, exception handling, and code reuse...in my mind that makes it a real programming language. T-SQL has the same. I think they count...they have more features than many major languages had in their early days.
      • No one cares how many lines of code or 2 seconds vs .6 seconds. Only maintainability and extension matter. Once you're gone who will maintain your code? If the answer is "no one" or "I dunno" or "the Bangalore outsource team" or "we'll have to hire someone, I guess", then you're doing it wrong.

        • Your response is only valid for small employers (Score:4, Insightful)

          by Somervillain ( 4719341 ) on Saturday January 11, 2020 @09:10PM (#59610952)
          First of all, the example gave was over 200x...everyone cares if user-facing function is dropped from 2 minutes to .6 seconds.

          I assume you misread...however, even if it was 2 seconds to .5 seconds...your users do care....but suppose you hate your users and value your convenience over their experience....do you host everything yourself?

          Most employers that contact me are moving to a cloud-based infrastructure. So yeah...a 4x difference will show up on your monthly bill if run frequently. For us, this was like $10,000 USD per month.

          Also, if you knew anything about databases, you would be very concerned by a 2 minute long transaction increasing the chance of a deadlock while slowing down everyone else. Life is a lot simpler when your transactions are short and as small as you can keep them valid.

          Finally, number of lines of code is usually associated with maintainability. Yeah, you have to hire people who know how to use Oracle, but you really shouldn't hire people to write DB code who don't know their way around Oracle's programming options. Sadly, it seems to be harder and harder to find skilled DB developers every year....so we get a bunch of kids and imports who write 2 minute long JPA saves that could have been done in .5s if they knew basic SQL.

          Every other week, I have to scold someone for loading a large hierarchical object into memory, modifying a field and saving it....preferring to use the Spring JPA Template save() method, executing 200 SQL statements...when he could have written an UPDATE statement in JPQL or basic SQL.

          So...not sure if you're implying me using Oracle's features correctly isn't jiving with your notion of maintainability...but it makes a huge difference and shouldn't be dismissed just because you don't want to learn how to use Oracle (or whatever platform you're on) correctly.

          • Re: (Score:1)

            by malvcr ( 2932649 )

            In my life I wrote extremely complex things with PL/SQL. And yes, when you know what you are doing, you can make magic with that tool ....

            .... until you decide to abandon Oracle (there are many reasons for that).

            In that moment, all the advantages disappear and you understand that was a really terrible idea to work with so specific extensions. This is why, the really important language to work with is not C or Java, neither SQL nor PLSQL but .... pseudo-code. Do the homework, describe completely your

  • That makes sense... (Score:4, Interesting)

    by Baby Yoda's Daddy ( 6413160 ) on Saturday January 11, 2020 @03:07PM (#59610156)
    Considering that C is the underlying language for most other programming languages.

    • Re: (Score:2)

      by Rei ( 128717 )

      My only gripe with "pure C"...

      I don't care if C programmers don't want to use classes. Don't.
      Hate templating? Avoid it.
      Despise cout? Don't touch it.

      But for god's sake, please compile your code with a C++ compiler and use STL. std::thread. std::string. std::vector. std::thread_guard. std::map. std::shared_ptr. Etc, etc, etc. Stop reinventing the wheel and making a maintenance nightmare and exposing yourself to memory leaks and giving yourself more work when you can just use libraries that exist,

      • Re: That makes sense... (Score:5, Insightful)

        by Viol8 ( 599362 ) on Saturday January 11, 2020 @05:08PM (#59610428) Homepage

        Std::thread is less powerful than pthreads as it caters to the lowest common denominator.

        Shared_ptr is great - unless your pointer is pointing at something that cant be free'd, then not so much.

        Also it's clear you've never had to program anything that has a RAM size measured in kilobytes such as PIC.
        Good luck using the STL there.

        • Also it's clear you've never had to program anything that has a RAM size measured in kilobytes such as PIC. Good luck using the STL there.

          True, but there are C++ libraries that are designed for tiny environments, which offer all of the reliability and safety of good C++ libraries, without generating large binaries or requiring a heap. C++ provides the same precise control over the generated code that C does, but still allows you the enormous benefits of constructors and destructors, with their guaranteed initialization and RAII. In many ways, tightly-constrained environments are the ideal context for C++. Because they're written by small g

          • I've written code for tiny systems with both plain C and C++, and I'll take the latter every time. I'm interested in experimenting with Rust to see if it can be stripped down far enough for tiny systems.

            Here's a great read for you: http://cliffle.com/blog/m4vga-... [cliffle.com]

        • Re: (Score:1)

          by functor0 ( 89014 )

          Shared_ptr is great - unless your pointer is pointing at something that cant be free'd, then not so much.

          Nonsense. One can create shared_ptr's with custom deleters. One can also create shared_ptr's that point to static objects (ie. is never to be freed) by just using the aliasing constructor and an empty shared_ptr. The latter being useful for poor-man's copy-on-write usage patterns via shared_ptr's.

          • Yeah genius! LEt's write a custom deleter to do nothing to use a class type that serves zero purpose In the given situation.

            Just fuck off already. If you have a pointer that points to stack memory or other non freeable memory location just use a raw pointer.
            Unless you're another so called coder who's too scared to use them in which case piss off to java and you and your bloatware code stay well
            away from C++.

            • Re: (Score:1)

              by functor0 ( 89014 )
              The reason why one would use shared_ptr's for non-freeable memory locations is to have variables which MAY point to EITHER static objects OR dynamic, shared ownership objects. A common scenario for this is for shared_ptr's to common "default" objects that are not frequently changed. However, one still wants to retain the flexibility that these pointers are "customized" for some particular purpose that you don't want to modify the common ones. This saves on a huge amount of memory that you would otherwise ha

              • Re: (Score:2)

                by Viol8 ( 599362 )

                Thats all well and good, but you can't used custom deleters with make_shared so you're going to have storage memory and control blocks scattered around the memory when using a container. Not very efficient. There's nothing wrong with raw pointers except to "coders" brought up on cotton wool programming who expect all the nasty stuff to be done for them.

          • Re: (Score:1)

            by malvcr ( 2932649 )

            Do you know ... I write huge things with C++ and zero leaks. And although I see these nice types of pointers appearing with each new language revision, I seldom use them because I don't need them.

            My solution is really simple: My software is extremely ordered with a very clear control on every dynamic thing I create, and I never destroy what is not mine. And when possible, just use the stack and play with the scope (this is very useful with Arduino), or manage the all almighty RAII. When there are too

        • You can specify a custom deleter for smart pointers, so you can absolutely use it for things that can't be free'd.

          Many parts of the STL, like most of the algorithms library, introduce absolutely no overhead, and often reduces the overhead of indirection that C libraries impose upon programs.

        • Also it's clear you've never had to program anything that has a RAM size measured in kilobytes such as PIC.
          Good luck using the STL there.

          You are technically correct which is, of course, the best kind of correct.

          Yes as of today, the C++ standard specifies that there is only hosted and non hosted and hosted gets everything and non hosted gets nothing. And of course Atmels are non hosted. So you get nothing.

          However, as a QoI, compilers can offer whatever bits of the standard library they want on the non hosted

        • Re: (Score:2)

          by Rei ( 128717 )

          A minimal detached pthread example:

          struct arg_struct {
          int x;
          int y;
          } args;

          static void* thread(void* _args) {
          struct arg_struct *args = (struct arg_struct *)_args;
          do_something_time_consuming_with_args(x, y);
          return NULL;
          }

          int main(void) {
          int x = function_to_get_x();
          int y = function_to_get_y();

          pthread_attr_t attr;
          pthread_attr_init(&attr);

          • Re: (Score:2)

            by Rei ( 128717 )

            And if you didn't want detached threads, you can just do "auto our_thread = std::thread(...." and don't even have to spell out the type if you don't want to. And when you want to join? Just "our_thread.join()". It could not get any simpler.

            Or take this sort of thing I've encountered a bloody million times in threaded C code:

            void some_function_called_by_a_thread()
            {
            pthread_mutex_lock(&lock); // Code here that does stuff

            pthread_mutex_unlock(&lock);
            }

            Then some inattentive

            • Re: (Score:2)

              by Rei ( 128717 )

              ED: Slashdot removed the newlines before and after the "// Code here" blocks.

          • Re: (Score:2)

            by Rei ( 128717 )

            ED: The pthread example should read "args->x" and "args->y" rather than just "x" and "y". But hey, I guess that's part of the consequence of being forced to needlessly write more code and needlessly use more abstractions: more needless mistakes.

      • By now the serious C coders long ago wrote their own (or downloaded) libraries to handle strings and pointers cleanly without loading in a bunch of bloat. If you're still seeing new code with shit like that in it they're either stupid or fluffing their hours.

        • By now the serious C coders long ago wrote their own (or downloaded) libraries to handle strings and pointers cleanly without loading in a bunch of bloat. If you're still seeing new code with shit like that in it they're either stupid or fluffing their hours.

          Without constructors and destructors, it cannot be done as cleanly, or without requiring programmers to manually handle all initialization and cleanup. Without move semantics it cannot be done as safely.

          • Without constructors and destructors, it cannot be done as cleanly,

            It can be, it just takes care (more than most people have, granted, but you cannot say it cannot be done).

            And bringing in support for constructors and destructors, you are going to bring in bloat to your system, there's no way around it.

            If you have a lot of resources, why are you using C anyway? If you are not, why would you ever consider bringing in a single aspect of C++ with memory and performance costs.

            • If you have a lot of resources, why are you using C anyway? If you are not, why would you ever consider bringing in a single aspect of C++ with memory and performance costs.

              What memory and performance cost. You know C++ runs fine on ATtiny's right?

            • Re: (Score:2)

              by Rei ( 128717 )

              you are going to bring in bloat to your system

              There's this myth that "C++ = bloat", and it's just not true. Most of what you expect to be "bloat" is just abstracted away by the compiler. Indeed, giving the compiler a chance to abstract things away generally makes things faster. For example, try benchmarking std::sort() vs. qsort(). Because the former is templated (so the compiler knows sizes at compiletime), and because its comparison function can be inlined (rather than being a function pointer that m

              • Re: (Score:2)

                by Megane ( 129182 )

                The bloat comes in when you use a templated function with a lot of different object types, and each type gets its own custom copy of the function. But each one is way faster! A late-binding language would only need one copy of the function, letting the object dispatch its own methods. (And iostream is responsible for some of the bloat too, just like how printf can pull in the entire floating point library if you don't select a no-floats printf.)

                It's a trade-off, though in the case of C++ the static binding

    • Considering that this is a completely pointless statement ...

  • I don't think that word means what you think (Score:4, Funny)

    by ceoyoyo ( 59147 ) on Saturday January 11, 2020 @03:23PM (#59610176)

    "Swift is a permanent top 10 player now"

    I do not think that word means what you think it means.

    • "Swift is a permanent top 10 player now"

      I do not think that word means what you think it means.

      Oh c'mon- Swift is definitely in the top 10,000 languages.

  • It's funny (or ironic?) that C is chosen over Java considering Java was originally designed for embedded applications.

    • Re: (Score:2)

      by Megane ( 129182 )

      Was it? They added some kind of Java-for-embedded support later on that absolutely never took hold, but I see Java as having had more of a goal of platform independence. In other words, pre-compiled code that can be run as universally as displaying a JPEG image. Then Java became famous for enterprisey code, which is the opposite of what you want for embedded.

      When I think of embedded, I don't think of bytecode virtual machines. The only possible advantages would be if you can't standardize on one architectu

  • If it wasn't for C, we'd be using BASI, PASAL, OBOL, Oam, oldFusion and JavaSript.

Slashdot Top Deals

The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Close