Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming Stats

Python Displaces C++ In TIOBE Index Top 3 (infoworld.com) 154

InfoWorld described the move as a "breakthrough": As expected, Python has climbed into the Top 3 of the Tiobe index of language popularity, achieving that milestone for the first time ever in the September 2018 edition of the index. With a rating of 7.653 percent, Python placed third behind first-place Java, which had a rating of 17.436 percent, and second-place C, rated at 15.447. Python displaced C++, which finished third last month and took fourth place this month, with a rating of 7.394 percent...

Python also has been scoring high in two other language rankings:

- The PyPL Popularity of Programming Language index, where it ranked No. 1 this month, as it has done before, and has had the most growth in the past five years.

- The RedMonk Programming Language Rankings, where Python again placed third.

Tiobe notes that Python's arrival in the top 3 "really took a long time," since it first entered their chart at the beginning of the 1990s. But today, "It is already the first choice at universities (for all kinds of subjects for which programming is demanded) and is now also conquering the industrial world." In February Tiobe also added a new programming language to their index: SQL. (Since "SQL appears to be Turing complete.")

"Other interesting moves this month are: Rust jumps from #36 to #31, Groovy from #44 to #34 and Julia from #50 to #39."
This discussion has been archived. No new comments can be posted.

Python Displaces C++ In TIOBE Index Top 3

Comments Filter:
  • by Anonymous Coward

    ... but if they hadn't handled the Python 2/3 fork so clumsily, this might have happened years ago.

    • by raymorris ( 2726007 ) on Saturday September 08, 2018 @03:58PM (#57276974) Journal

      Never mind Python 2 vs 3; one major reason I shy away from Python is the incompatibility in point releases. I'd see "requires Python 2.6â and see that I have Python 2.7 so it should be fine, right? Nope, code written for 2.6 won't run under Python 2.7. It needs to be EXACTLY 2.6.

        It's at this point that some Python fanboi gets really upset and starts screaming about how that's now problem, with Python you set up separate virtual environments for each script, so that each one can have exactly the version of Python it is written for, with exactly the version of each library. When there is some bug or security issue you then hope that there is a patch for each, and deal with all that. (As opposed to every other peice of software in the world, which you simply upgrade to the latest version to get all the latest fixes). Yes, you CAN deal with that problem, it's possible, in most cases. You shouldn't have to. Every other language does some simple things to maintain backward compatibility in point releases (and mostly in major releases too).

      Also the fact that most languages use every day and have used for decades use braces for blocks means my eyes and mind are very much trained for that. Braces aren't necessarily BETTER than just using indentation, but it's kinda like building a car which uses the pedals to steer and a hand stick for the gas. It's not necessarily inherently better or worse, but it would be almost undriveable for an experienced driver with decades of muscle memory in normal cars. Python's seemingly random choices on these things make it feel like using your feet to steer a car. There should be compelling reasons before you break long-established conventions and Python seems to prefer to break conventions just to be different. It seems the Python team is a bit like Berstein in that way. It's really annoying.

      • by slack_justyb ( 862874 ) on Saturday September 08, 2018 @05:00PM (#57277244)

        Python 2.7. It needs to be EXACTLY 2.6

        Yeah, just FYI Python 2.7 is in a way its own thing. Different from the 2.x and different from the 3.x series. 2.6 is a no holds barred pure 2.x whereas 2.7 is a mixture of 2.x and 3.x features. So if you want to compare point releases, best to try that with the 3.x series. Also, if you're using something that requires the 2.x series, you shouldn't use that unless it is absolutely critical with zero replacements.

        You shouldn't have to. Every other language does some simple things to maintain backward compatibility in point releases (and mostly in major releases too).

        Again see argument about 3.x, but yeah not every language does this. Java 8/9 transition breaks things. ASP.Net to ASP.Net core breaks things along the way. I'm interested in what languages you have in mind, because I know quite a few languages that do maintain backwards compatibility (ish). For example, C++ pre and post namespace breaks fstreams in programs, but compilers provide flags to override that, so it depends on what you mean by breaking. Does it count if the compiler by default breaks, but providing flags fixes it? Because if your definition means including flags break compatibility, then oooh boy are there a a shit ton of broken languages.

        Also the fact that most languages use every day and have used for decades use braces for blocks means my eyes and mind are very much trained for that

        Yeah, it's clear that you've never used a positional programming language. I guess it'll be a sign of my age, but buddy, program COBOL or RPG on punch cards and let me know about that curly brace issue you're having. Positional and indentation has been used way, way, way, longer than curly braces. That's not me knocking on the curly braces, I love my C/C++ folks out there! But I hate to tell you C and C-style is pretty recent in the timeline of all things computer.

        • > C++ pre and post namespace breaks fstreams in programs, but compilers provide flags to override that, so it depends on what you mean by breaking. Does it count if the compiler by default breaks, but providing flags fixes it?

          If it results in weird runtime errors, that's definitely a problem.
          If the compiler I'm using gives the message "incompatible use of fstream, try '-fstreamcompat' flag", that's no big deal.

          • On a similar note, if something is marked deprecated long before it's removed, that matters. Five years of compiler/interpreter warnings saying "deprecated use of function in null context on line #47" gives plenty of opportunity. To fix it. From the bit of Python I've worked with, the recommended method on Friday completely stops working on Monday.

            • That's plainly not true - Python follows the established deprecate-first-remove-next cycle. This is readily obvious when you look at the changelogs. For example, from the 2.6 changelog:

              The threading module API is being changed to use properties such as daemon instead of setDaemon() and isDaemon() methods, and some methods have been renamed to use underscores instead of camel-case; for example, the activeCount() method is renamed to active_count(). Both the 2.6 and 3.0 versions of the module support the same properties and renamed methods, but don’t remove the old methods. No date has been set for the deprecation of the old APIs in Python 3.x; the old APIs won’t be removed in any 2.x version.

              For another example, the ability to throw strings (rather than BaseException-derived objects) was deprecated in 2.3 (2003) and finally removed in 2.6 (2008).

              For comparison, in the C++ land, dynamic exception specifications were deprecated in C++11, and removed in C++17. So the time scale is comparable.

              • That's great that they deprecate something on some occasions.
                MY experience with the Python I run is that one version gives no warning, going up one point release throws multiple fatal errors.

                > This is readily obvious when you look at the changelogs

                Maybe that's the thing - one has read the changelogs to see what is deprecated, as opposed to getting a clear deprecation warning from the interpreter/compiler like you would with C, Perl, and other languages?

                It's possible that a Python expert might be able to

                • MY experience with the Python I run is that one version gives no warning, going up one point release throws multiple fatal errors.

                  Can you give an example? I'm just not aware of any, and it makes me suspect that what you were running into was an issue in a third-party library (some of which do indeed have a cowboy attitude towards breaking changes - but that's common across all languages).

                  Maybe that's the thing - one has read the changelogs to see what is deprecated, as opposed to getting a clear deprecation warning from the interpreter/compiler like you would with C, Perl, and other languages?

                  Like this [python.org]?

                  And I have never, ever seen a deprecation warning in C or C++. You have to read the change sections for new standards to see what was deprecated or removed.

                  • > And I have never, ever seen a deprecation warning in C or C++. You have to read the change sections for new standards to see what was deprecated or removed.

                    The default with gcc is to warn about deprecation.
                    You can turn the warnings off by setting the CFLAGS environment variable to include -Wno-deprecated, which you can do in your .bashrc oe wherever. What's most often recommended is -Wall to show all warnings of all types.

        • For example, C++ pre and post namespace breaks fstreams in programs, but compilers provide flags to override that

          Dude, that was in 1990, back before there even was a standard C++. And I very much doubt those flags still exist today.

          program COBOL or RPG on punch cards and let me know about that curly brace issue you're having

          You seem to have forgotten how that really worked in your old age though. Punch cards had columns with specific functions assigned to them, so yes, of course you would have to skip certain columns on occasion. That was not indentation, though. You didn't have indentation; moving your holes by one position or one column meant the machine would interpret your instruction as something else ent

      • by sjames ( 1099 )

        That must be an odd package. I have literally NEVER seen that with anything I have wanted to use, including my own pre-2.7.x software.

  • Real code warriors don't need static types. If a variable is so badly named that the type is not clear, use type().
    • If a variable is so badly named that the type is not clear

      Never fear, I've brought my LPCWSTR.

    • Re: Warrior (Score:3, Insightful)

      by jd ( 1658 )

      Static typing isn't just about clarity to the programmer. In strict typing languages, the rule is to use the type that matches the range that actually applies. This is to help testing (something coders should not ignore), automated validation, compilation (a compiler can choose sensible values, optimise the code, etc etc etc) and maintainers (a clear variable name won't tell anyone if a variable's range can be extended without impacting the compiled code).

      Besides, I've looked at Python code. I'm not convinc

    • Real code warriors don't need static types. If a variable is so badly named that the type is not clear, use type().

      pfaaah. Real programmers don't need names. If the type of a variable is not obvious from context, get another job.

    • Type annotations and docstrings help with the whole lack of type declaration thing. Of course that requires discipline, which is in short supply from my experience. If you can force your developers to run pylint that will at least complain when they don't have docstrings.

  • by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Saturday September 08, 2018 @03:42PM (#57276880) Homepage Journal

    behind first-place Java

    Whatever the list, if Java is in the first place, there is no honor in being anywhere near the top.

    • by jd ( 1658 ) <imipakNO@SPAMyahoo.com> on Saturday September 08, 2018 @04:18PM (#57277066) Homepage Journal

      The list is compiled from a restricted pool and lists popularity.

      That may mean a vendor throwing out ten individually packaged Python scripts counts as ten sources with one C program of equalling counts as one. If that's the case, Python would be ten times as popular in the stats whilst being equally popular in practice.

      So if Python needed ten times as many modules to be as versatile, it would seem popular whilst only being frustrating.

      The fact is, we don't know their methodology. We don't know if they're weighting results in any way to factor in workarounds and hacks due to language deficiency that might show up as extra use.

      We do know they don't factor in defect density, complexity or anything else like that as they do say that much. So are ten published attempts at a working program worth ten times one attempt in a language that makes it easy first time? We will never know.

    • by nten ( 709128 )

      I find java in an uncanny valley. Its still a few times slower than c++ for the sort of stuff I do but it isn't enough quicker to develop than c++ to be worth that hit. Python is far slower than java even using numpy but its so easy to develop in that it is worth the gamble that it will be fast enough. And the rewrite in c++ will go quickly even if it isn't. The title is because VBA is 11x faster than numpy at small dense matricies and almost as easy to develop in.

      • Java is useful because you can throw a team of lowskill developers at it and they won't mess things up beyond the point of unmaintanability. It will be a pain to maintain, sure, but the same developers using C would make memory errors that push things beyond hopeless, and if they were using Python or JavaScript the types would become more and more jumbled as the size of the program increases that no one would be able to understand it and things would start breaking more and more. Java enforces a minimal lev
    • Tiobe is utter crap. Javascript (barf) is by far the most popular programming language today and Tiobe puts it in 8th place, behind Visual Basic.

    • From the same article - Visual Basic overtakes C#, PHP and Javascript...

  • by El Cubano ( 631386 ) on Saturday September 08, 2018 @03:59PM (#57276982)

    Tiobe notes that Python's arrival in the top 3 "really took a long time," since it first entered their chart at the beginning of the 1990s. But today, "It is already the first choice at universities (for all kinds of subjects for which programming is demanded)

    Undergraduate was all C/C++ for me then I ended up at a graduate school where everything was Java. I disliked it so much that I decided to find an alternative and teach myself. I found Python and loved it. I still love it. You can't find anything better for both heavy duty programming and quick and dirty scripting. It's versatility makes It like the Linux of programming languages.

    • Re:Love Python (Score:4, Insightful)

      by Tough Love ( 215404 ) on Saturday September 08, 2018 @05:02PM (#57277252)

      I found Python and loved it. I still love it. You can't find anything better for both heavy duty programming...

      What? Python is hopelessly inefficient for heavy duty programming, unless you happen to be doing something that is mainly handled by a Python library, written in C. Python's interface to C disgusting, so if you have a lot of small operations handled by a C library, you will get pathetic performance.

      • by sjames ( 1099 )

        It really isn't. There are some apps that actually need something faster and a lot of apps that don't. It really doesn't help if a faster executable ends up waiting for I./O.

        • It really isn't.

          It really is [debian.net] and you blathering about what you don't know does not change that fact. (Python 14 minutes vs C++ 8..24 seconds for N-Body simulation.)

          • by sjames ( 1099 )

            Well, since 99.99999999999% of all software run by literally everybody is an n-body simulation....

            That would be an example of the "some apps" I spoke of. I note that Intel Fortran was at the top of the list (not surprising). Would ifort be your first choice if you were writing a text editor or a tar file splitter? How about an smtp daemon?

            I sure hope not.

            • Well, since 99.99999999999% of all software run by literally everybody is an n-body simulation..

              Explaining the concept of "compute intensive" to you makes me feel more stupid. Check out any of the compute intensive Python benchmarks. Consider not waving your ignorance around quite so much.

              • by sjames ( 1099 )

                Having actually built a cluster that was in the top 500 for a while, I am well acquainted with compute intensive applications. I am also aware that compute intensive is a subset of "heavy duty" programming which is a subset of general programming.

                Now, pull your head out of your ass and look around, you might learn something. And while you're at it, consider working on your social skills.

                • Either you understand that Python is crap for compute intensive work, or you are lying about building a cluster. Or you just connected the cables, more like it, and really don't have a clue about how to use it.

                  • by sjames ( 1099 )

                    I do understand that python isn't the right choice for compute intensive work. With the exception that if it is great for doing setup for something in FORTRAN or C that does the heavy lifting.

                    I am certain that YOU don't understand that compute intensive work is a small fraction of what is done on computers. For example, I/O intensive work doesn't really care if it is Python or FORTRAN that is waiting for I/O to complete. There is a reason people don't drive a top fuel dragster to work.

                    If you meant compute i

                    • I am certain that YOU don't understand that compute intensive work is a small fraction of what is done on computers.

                      First, you have no idea what I do or do not understand because you find yourself way too entertained by your own blather, and second, computers are used more for browsing than any other single task these days, and wasteful use of the CPU translates into perceptible lag. Playing media is very CPU intensive. You don't write those things in Python because Python sucks for efficiency. My point.

                      Yes, I had you figured, you're a sysadmin with delusions about being a dev. Seen way too many of those. They tend to ta

                    • by sjames ( 1099 )

                      I draw my conclusions from what you have written in this thread. You see one screw and think NOTHING is a nail.

                      You don't write a video codec in Python, but it's a great choice for handling the UI and feeding the stream to the codec.

                      You have much to learn.

                    • As I said, "Python is hopelessly inefficient for heavy duty programming". WTF are you blathering on about. Fresh air is good for you, maybe get out of your basement more.

                    • by sjames ( 1099 )

                      "Heavy Duty " != "compute intensive". Say what you mean or don't complain when people disagree.

                    • OK, you have your own private definition of terminology. Enjoy life in your own private universe.

                    • by sjames ( 1099 )

                      I made a couple attempts to clarify terminology but you were too busy looking for an excuse to make an ass of yourself to notice.

          • It really is [debian.net] and you blathering about what you don't know does not change that fact. (Python 14 minutes vs C++ 8..24 seconds for N-Body simulation.)

            I've just run it on my machine. C++: 2.3 seconds, Python: 22 seconds. That's for straightforward mathy Python against C++ code with vector instrinsics. Concerning C++ code without manual vectorization, it's 4 seconds against 22. Not terribly bad, I'd say. Not to mention that this isn't the kind of code that would be typical for a larger application.

            • 5x+ penalty just for writing the code in Python, you call it not terribly bad? So this is how Python fans think.

              • The first python program I wrote was a test for a job interview.
                It involved downloading meteorologic data from the internet.
                Analyzing it, creating a kind of summary and using a graph plotting library to display a graph (generate a *.png)

                It would not have been noticeable faster if I had written it in C++, because ... you know: downloading via a network.

              • I'm pretty sure you get another 3x penalty for not writing in assembly, too. So this is how C++ fans think.
                • I'm pretty sure you get another 3x penalty for not writing in assembly, too...

                  You are sure of that, are you? I bet you have never coded in assembly yourself, or looked at the assembly that gcc puts out in O3.

                  • I did, for 6502, 8051 and 8086. And I've seen GCC's output.
                    • Then you looked at it without understanding it. Do you seriously think you can out-optimize gcc's code generator? Do you even know how to use LEA for arithmetic?

                    • LEA is not going to help you much in a small fixed-size n-body kernel. That's going to be mostly unrolled AVX code.
    • by dwpro ( 520418 )
      Have you worked on or have an example of a large, complex application in Python? I'd like to see how it's organized, seems like it'd be a nightmare.
    • Undergraduate was all C/C++ for me [...]

      And I believe you! — because...

      It's versatility makes It [...]

      ...evidentally you forgot to take grammar class. ;)

  • by Anonymous Coward

    Is there a programming language out there, that is as fast as C++ or even C, has a proper strict type system (no duck typing, nothing like Python or JS), fast garbage collection (no fuckin' auto_pointer worst-of-both-worlds), is elegant and emergent (so very powerful for its simplicity), and doesn't require an advanced degree in computer sciences to do simple things (Hello Haskell!).
    Of course with key libraries being available for it. (The equivalent of a standard library, Vulcan, a simple GUI widget toolki

    • by Tablizer ( 95088 )

      It's called "IwannaPony", and you are NOT going to get one. You are asking too much.

    • I really like the Qt framework. It's well done, well documented and well supported. Sure it's C++ so it doesn't meet your need of finding a new language but the API is pretty clean and simple so that you can avoid the complications and ugliness of C++ in most cases. If you need to though, it's all right there so you don't give up the additional power if you need it. The Python version is good too and very similar to the C++ version so it's not hard to switch between languages as your needs change.

    • Is there a programming language out there, that is as fast as C++ or even C, has a proper strict type system (no duck typing, nothing like Python or JS), fast garbage collection

      No.

      Neither will there be. There's always a penalty for garbage collection.

      • by rkcth ( 262028 )

        Is there a programming language out there, that is as fast as C++ or even C, has a proper strict type system (no duck typing, nothing like Python or JS), fast garbage collection

        No.

        Neither will there be. There's always a penalty for garbage collection.

        I think go is the closest to your requested feature list.

        • I think go is the closest to your requested feature list.

          The GP, not mine. And yuck, no thanks. Go just seems, well, deeply mediocre in many places. It's like someone pdated C, ignoreing the last 40 years of language developments.

          Sure I can program without generics, I'm at a loss to see why I'd want to though.

    • Julia? It ticks quite a few of those boxes.

      Its performance is good enough that I'm able to drop C++ (I'm a mathematical modeller), it's amazing at multidimensional array manipulation, and its typing system is really good. It just feels nice to program in. Bonus, one of the inspirations was Lisp, so it's got good metaprogramming. Also it's free software, made by people at MIT, so your conscience can remain appeased.

      It's still a young language, but libraries are being built for it at an impressive rate, and i

  • That advocated a language. Languages shift faster than sand on speed. Universities should teach logic, reasoning, methodology, good practices and programming technique.

    Languages should be for the purpose of example only. Universities should teach programming, not Java, software engineering, not Python. Java and Python should be in there, yes, along with Perl, C and Ada. Syntax is just sugar over the semantics. Learn the semantics well and the syntax is irrelevant. You want universities to teach kids how to

    • by Tablizer ( 95088 )

      when Cobol and Fortran were the in thing. Last forever, they thought.

      Any evidence most universities believed that? (They are still around and relatively common, by the way.)

      Universities have to pick something to program lesson projects in, and selecting language(s) common in the current market helps student job prospects. I suggest STEM students be required to learn at least one compiled/strong-typed language, and one script/dynamic language.

      • My university (Manchester University, UK) certainly didn't pick a language.

        We studied many languages, compiler design, formal semantics and a boatload of other computer science things but at no point did they try to teach me a programming language. In fact at induction they said explicitly that they expected us all to know how to program before we arrived.

        That was 30 years ago. Things might have changed.

        • (note: this is a UK perspective, other places may vary)

          Universities have to work with the students they can get.

          I think you and your co-students were lucky to catch the height of the 80s microcomputer boom, the time when computers booted into BASIC, when using a computer pretty much meant programming it.

          Then the windows PCs with their pre-canned applications and no obvious programming language swept in. Leaning to program now meant not just finding a suitible book, it often meant buying the programming lang

        • by Tablizer ( 95088 )

          My university...didn't pick a language.

          Didn't you have projects that involved turning in your code to the teacher/graders? The graders don't want to see every which language. Multi-lingual graders are more expensive. Most colleges dictate a narrow set of languages for such projects.

          • My university...didn't pick a language.

            Didn't you have projects that involved turning in your code to the teacher/graders? The graders don't want to see every which language. Multi-lingual graders are more expensive. Most colleges dictate a narrow set of languages for such projects.

            Yes, but it was hardly narrow. We had homework to hand in using a variety of languages, depending on the course. Pascal tended to be used for general algorithm stuff. But Smalltalk, Prolog, ML and other usual suspects were used when they made sense for the course. You were supposed to leave with a CompSci degree where you understood the theory of languages more than the details of specific languages. Usually, for project work, you were free to choose your language and would be expected to justify the reason

            • by Tablizer ( 95088 )

              I don't remember herds of graders. That's what postgrads are for.

              Maybe the graduation % was too low at my U.

    • If you want to teach semantics, use either Smalltalk or Scheme. You can teach the syntax for either in five minutes.
  • Groovy from #44 to #34

    That's a pretty big jump. Groovy is a well-thought-out language and nicely facilitates writing clean, readable, compact code (especially compared to Java). However, it needs a better framework than Grails (85% really good convention over configuration stuff but 15% convoluted j2ee era framework stuff).

  • [SQL added to list] since "SQL appears to be Turing complete."

    Not sure that's a good thing.

  • Can someone explain to me why using a dynamically typed language is a good idea for "big" applications ?

    Python is subject to all sorts of really horrendous bugs that would not happen in a compiled, type-checked language.

    For example if you are accessing an undefined variable in the else branch of an if statement, you won't know it's undefined unless that branch is taken. which means if it's something like a rarely occurring error condition it's kind of annoying. yes you can figure it out by writing enough t

    • It's really simple, Writing an application in Python is x3 quicker than writing it in C/C++/Java, etc... That means you either get to market 3x faster or only need 1/3 the number of programmers. Everything else is completely and utterly irrelevant. "you won't know it's undefined unless that branch is taken" The code linter built into your Python IDE, will tell you about it.
      • by dwpro ( 520418 )
        Hogwash. Even if x3 were true, Dev is roughly 20-40% of overall software cost. Unless you're arguing that every aspect of coding is reliably 3x faster in Python. Given the value of strong typing when refactoring, I'd wager python is not even competitive price wise past the proof of concept/one-off script scenario.
        • I'm am arguing that because it's true. There isn't much benefit to strong typing when refactoring but the benefits of duck typing when it comes to unit testing are quite significant. I've done commercial software development in strong and weakly typed languages before. The benefits of things like "strong typing" are generally not that much. If you are on board with the whole agile bandwagon and writing unit tests and all that. You would be much better off with Python's significally better unit testing fac
          • by dwpro ( 520418 )
            I'm at least in the caravan trailing the agile/unit-test bandwagon, but those are orthogonal to typing (and being explicit generally). Looking at a method signature and knowing that it requires a decimal and enumeration of a given type is more than a run-time check; it provides information about the intent, limitations, and discoverability options. There are very real trade-offs for the speed and flexibility of a language like Python, and my view is that it's more jet-fuel than solar power.
            • If you are using a good IDE "provides information about the intent, limitations, and discoverability options" can all be found out with a couple of key strokes (git blame, find all usages, pylint, etc..). So putting that information into the language explicitly is an obsolete and backwards way of going about things :p The job of the compiler in Python has just been redistributed elsewhere. It's different but there are many ways to solve the same problems.
    • by sjames ( 1099 )

      Six of one, half dozen of the other. The Python program will be smaller for the same functionality and it won't have buffer overflows and memory leaks The C program will run faster (unless it has to wait on I/O) and will check for variables used before assignment.

    • by munch117 ( 214551 ) on Sunday September 09, 2018 @03:40AM (#57278724)

      Using an undefined variable in Python triggers an exception, and you get a traceback. In a larger program you will normally have a system for capturing and storing such tracebacks for analysis, and with the traceback in hand, it's typically a very simple fix.

      In C++ you get an incorrect value created by default-initialisation (or maybe undefined behaviour): the program hobbles along as best it can, and you may never find the problem. You just see your program behaving strangely sometimes, and as the program gets larger, those strange behaviours accumulate.

      Python is subject to all sorts of really horrendous bugs that would not happen in a compiled, type-checked language.

      Horrendous is not the right word. Bugs that come with tracebacks are simple bugs. Zen#10: "Errors should never pass silently" is exactly what you want in large-scale programming.

      • By "undefined variable" I think he means undeclared (or, in Python, unassigned in the proper scope, since locals are declared implicitly).

    • Writing big applications in Java/C++ takes too long. And then managements decide to avoid 'custom code' in favor of 'standard' vendor tools where you can drag and drop to build parts of the 'big' application. This applies to ETL, reporting, messaging to name a few. With Python, the development cycle shortens and you can still stick to writing code instead of dealing with vendor binaries, lock-ins, licensing etc. Python with strong emphasis on unit tests, coupled with plugging in C/C++ where necessary f
    • by nashv ( 1479253 )

      If you are really really asinine about strong typing, you can declare types in Python https://medium.com/@ageitgey/l... [medium.com]

  • by SuperKendall ( 25149 ) on Saturday September 08, 2018 @09:51PM (#57278124)

    I think what has really propelled Python into a higher rank is machine learning, where it is simply the de-facto language of choice by quite a margin.

    I have to admit I am impressed with the progress it has made; of many recent CS grads I've talked to it seemed to be the favorite language...

    I have to admit that over the years I've not really enjoyed Python much myself in the on and off again times I've used it, for me the spaces as indent levels maybe get too close to the meaningful whitespace of Fortran... I guess modern programmers do not have this hangup. :-)

    So good work Python, a well deserved ascent!

    • It's not just ML, but data science in general.

      And the other big thing was many universities switching to it from Java for their CS courses.

      • That's a great point, and to be honest that is probably a better language for learning than Java... it would also explain why newer CS grads all like it more now.

        The only downside is that most jobs are still using Java or something besides python... but probably it means we'll se more python used in businesses I guess. That usually ends up following eventually.

  • Comment removed based on user account deletion
  • I don't think this should be about lines of code written. A more interesting approach would be to also count all dependencies, counting things like libc a gazillion times. Even more interesting would be to count what's actually executed.

  • Not typesafe, and no switch/case ... what ever rocks your boat.

Keep up the good work! But please don't ask me to help.

Working...