Ask Slashdot: Will Python Become The Dominant Programming Language?

An anonymous reader shares their thoughts on language popuarity: In the PYPL index, which is based on Google searches and is supposed to be forward looking, the trend is unmistakable. Python is rising fast and Java and others are declining. Combine this with the fact that Python is now the most widely taught language in the universities. In fields such as data science and machine learning, Python is already dominating. "Python where you can, C++ where you must" enterprises are following suit too, especially in data science but for everything else from web development to general purpose computing...

People who complain that you can't build large scale systems without a compiler likely over-rely on the latter and are slaves to IDEs. If you write good unit tests and enforce Test Driven Development, the compiler becomes un-necessary and gets in the way. You are forced to provide too much information to it (also known as boilerplate) and can't quickly refactor code, which is necessary for quick iterations.
The original submission ends with a question: "Is Python going to dominate in the future?" Slashdot readers should have some interesting opinions on this. So leave your own thoughts in the comments. Will Python become the dominant programming language?

Comments

No

[Anonymous Coward]

No.

Re:No

[Opportunist]

There are no stupid questions, only stupid people.

Re:No

[Z00L00K]

Python is to programming today what Basic was to programming in the 80's. With similar advantages and disadvantages.

Re: No

[K. S. Kyosuke]

The prime weakness of BASIC was goto.

I'd say that the prime weakness was the lack of product types and named objects such as functions and procedures, but that's just me...

Re: No

[CeasedCaring]

Back in the day, BBC Basic had both PROC & FN commands

Re:No

[h33t l4x0r]

Python has completely stepped on it's own dick by making v3 scripts incompatible with v2. In all likelihood it will never get over that clusterfuck. For data science, R is the future, and for everything else, it's really a toss-up.

Re:No

[DrXym]

The clusterfuck was not that some stuff broke in version 3 but that the community wasted an inordinate amount of effort and time supporting version 2 and version 3 in parallel, backporting some things, writing shims, maintaining & building two code bases.

Version 3 should have come out and the community told that in 18 months version 2 was going to be mothballed. A clear timeline that would have focused minds and moved the language forwards.

Re: No

[K. S. Kyosuke]

Well it did, and I *did* use them, but single-line branchless definitions is quite far from named definitions being an orthogonal concept in a language.

Re: No

[Anonymous Coward]

There is nothing wrong with GOTO, just as there is nothing wrong with longjmp or branch or break to label, it all depends on how and when you use it.

Re: No

[goose-incarnated]

The prime weakness of BASIC was goto. I suspect you're just trying to conflated the two because both are popular as teaching languages. Besides that, the two aren't comparable in any way.

Except that python is ALSO useful in the real world.

You think Basic wasn't useful in the real world? You must have been asleep for the latter part of the nineties.

Re:No

[goose-incarnated]

The clusterfuck was not that some stuff broke in version 3 but that the community wasted an inordinate amount of effort and time supporting version 2 and version 3 in parallel, backporting some things, writing shims, maintaining & building two code bases.

Version 3 should have come out and the community told that in 18 months version 2 was going to be mothballed. A clear timeline that would have focused minds and moved the language forwards.

That would have killed both versions. You underestimate the utility of backwards compatibility. Entire sub-optimal technology stacks currently owe their existence to being backwards compatible. The optimal ones with no backwards compatibility didn't make it.

Re:No

[Blrfl]

Entire sub-optimal technology stacks currently owe their existence to being backwards compatible.

The x86 platform being a perfect example of that.

Re:No

[RabidReindeer]

That, and the fact that python is horribly slow.

So was Java, once. Python has JIT-compiling these days, and thus, like Java, can potentially run faster than static-compiled programs.

What Python doesn't have is strong type enforcement. Unless you pre-compile the whole app, entire source files could be filled with monkey-typed gibberish and until the fateful day came that the defective modules were referenced (say, once a Leap Year), they'd be serpents in the grass.

Even pre-compiling won't help if there are insufficient cues to ensure that you won't be passing a dingus to a module that expects to use a wackdoodle.

Re:No

[xvan]

As far as I knew, C++ was fully compatible with ANSI C. That played a big part on its success.

Re:No

[fnj]

I'm going to say this is a case where Betteridge does NOT rule. Yes, python is not perfect: it is as slow as molasses in execution speed, and has terrible multithreading capability. So what. These imperfections are completely outweighed by its superb readability/understandability/clarity, and the ease with which it can be learned.

No one is going to write an OS or an office suite all in python. But for a large swathe of programming tasks it is ideal. It is a lot more than just a scripting tool like, for example, perl.

Re:No

[LifesABeach]

I call Bullshit. I've bench marked several Java vs /> and Ms*; only C++, C, and Assembler are faster, and in that order.

Re: No

[beelsebob]

The two are very comparable. They're both dynamically typed interpreted languages that are commonly used for writing more complex scripts, and some basic things that might be called "applications". They both provide ease of programming, relatively human readable syntax, and both suffer from significant performance issues relative to more on-the-metal solutions.

I'd say the comparison is spot on.

Re:No

[beelsebob]

What Python doesn't have is strong type enforcement.

Actually, it does - Python is a strongly typed language, what it isn't, is statically typed.

Re:No

[beelsebob]

Nope, C++ is not a superset of C at all. There's lots of subtle little things that are different in very important ways.

Some examples:

1) void* is not considered implicitly castable to any other pointer type. That means that you need to cast the output of malloc for example.

2) character literals have the type char, rather than int. That means their size is different, and hence programs behave differently.

3) C++ does not require to use the keyword 'struct' in front of structure names. This can subtly change the behaviour of programs like int A; void foo(void) { struct A { char x; }; return sizeof(A); }, which will return the size of the variable A in C; and the size of the structure A in C++.

Re: No

[serviscope_minor]

I what era? BBC basic had functions in 1981. The excellent quick basic (basically QBasic but better) had them by 1985. When QBasic was finally released in 1991, every PC from then on had a basic not beholden to line numbers.

Re:No

[serviscope_minor]

You missed FORTRAN. That's often faster than C. If your C is faster than your C++, you can fix it.

Re:No

[swillden]

What Python doesn't have is strong type enforcement.

Actually, it does - Python is a strongly typed language, what it isn't, is statically typed.

Which means that you have no idea that you passed a dingus instead of a wackadoodle until some codepath that exercises the difference... and then you only find out at run-time, when your production system crashes. Sure, you can argue that this just means your automated tests were deficient, but that's always going to be the case, even when you apply great effort to get to 100% coverage. And you can argue that static typing isn't a perfect solution either, and I would never claim otherwise.

But the combination of TDD and static typing catches more defects than TDD alone, and static typing often enables errors to be caught at the time when they're easiest to fix, compilation. Judicious use of strong static typing enables us to write code that cannot compile unless it's correct. It's unfortunate that the very best popular-language example of this comes from the most powerful footgun language, C++, but that doesn't make it any less true. The C++ templating system, combined with static typing, makes it fairly easy to build infrastructure that allows the compiler to catch huge classes of likely errors. Haskell is an even better example of the tremendous error-correction power of strong and thorough static typing, though it's not likely ever to become popular.

Python is great for rapid prototyping and small scripts, but for large, complex systems I want both TDD and strong typing. At present, Java is probably the best language for such systems, when you consider availability of experienced staff, tooling and native features.

Re:No

[beelsebob]

Which means that you have no idea that you passed a dingus instead of a wackadoodle until some codepath that exercises the difference... and then you only find out at run-time, when your production system crashes. Sure, you can argue that this just means your automated tests were deficient, but that's always going to be the case, even when you apply great effort to get to 100% coverage. And you can argue that static typing isn't a perfect solution either, and I would never claim otherwise.

Hey, I never claimed it was good. I just corrected your assertion. Python *is* strongly typed. You absolutely can not pass a dingus instead of a wackadoodle. It will crash with a type error every time. It just will crash, instead of causing a compilation error, making the language strongly dynamically typed, not weakly typed as you asserted.

Re:No

[Jeremi]

Nope, C++ is not a superset of C at all. There's lots of subtle little things that are different in very important ways.

All true, but irrelevant, since C++ is "close enough" to compatible with C that in most cases you can simply rename a .c file to .cpp and it will compile and run correctly (possibly with a few minor tweaks).

Perhaps more importantly, you can link your C++ code directly to code that was compiled with a C compiler and have it call into the C code without any major hassles.

So the major benefit -- being able to keep using all those existing C codebases from your C++ program -- was preserved.

Re:No

[goose-incarnated]

, the typing is quite strongly enforced. Me's thinks you don't know what you're talking about.

The typing is strongly enforced at runtime. We'd like to catch those obvious errors before it runs.

Re:No

[mysticgoat]

I worked with a couple of different varieties of Business Basic between 1986 and 1993. Hewlett-Packard's version was particularly easy to work with.

Basic's two primary advantages in the business office were that

1. it was the first and best developed interpreted language. If your business was successful enough to have a couple of dedicated IT employees, it could afford a minicomputer and could make good use of compiled languages. But compiled languages suck on the PCs that were affordable to small businesses of that time period. The RAM was too tiny and limiting, hard drives were too small and slow for an efficient compiler environment. Some form of Basic was your only way forward.

2. With a good business Basic you could get the point of sales pizzabox PCs generating data for the back office accounting PC while your competitor down the street was still working on how to build a string variable in Pascal. You didn't worry about the other competitors who were trying to use C. Their development cycles were constantly broken as bigger businesses hired away their C programming staff.

Those were the wild and wooly days of cheapernet, LANtastic, and sneakernet, when we were all still buying huge 40 megabyte hard drives that had to be partitioned since DOS was limited to 32 MB. Back when "Windows was a 16-bit GUI running on an 8-bit operating system, written for a 4-bit processor, by a 2 bit company that can't stand 1 bit of competition".

Umm, some things haven't changed that much I guess. I just came across this definition of Windows 10:

Windows 10 (n): A 64-bit "upgrade" to a 32-bit patch for a 16-bit GUI shell running on an 8-bit operating system, written for a 4-bit processor by a 2 bit company that can't stand 1 bit of competition!

I of course use Linux. It's true that during the first decade of switching from Windows to Ubuntu I had a few miserable moments, but now it's all smooth sailing.

Re:No

[mysticgoat]

The point of my earlier post got lost in the reverie.

Python is nothing like the Basic of the 1980s. Basic's development was strongly shaped by the limitations of the hardware it was run on. Python's development is shaped by the self-imposed limitations of the minds of its developers. Two very different things.

Re:No

[mbkennel]

> Python is great for rapid prototyping and small scripts, but for large, complex systems I want both TDD and strong typing. At present, Java is probably the best language for such systems, when you consider availability of experienced staff, tooling and native features.

That's my experience as well. I work in what is now called "data science" (though I've been doing the same stuff for decades, back when it might have been called 'computational physics' or 'statistics' or whatever).

I find that even for initial development past a a hundred or two lines, I now prefer Java. Why? A simple, but universal and ubiquitous answer: just looking up the damn order and meaning of the arguments of a method.

For instance, in python data manipulation, which uses almost universally the Pandas library, built on numpy library, you could need to pass a DataFrame, a Series, or the underlying numpy array, or even lower level a built-in Python list as arguments (and they can be converted back and forth). I now have to look at my code at the called method to see which it was supposed to take and in what position.

With a typical Java IDE, I'd get feedback on the spot (red line) if I used the wrong one and a space would likely bring up the appropriate conversion method or a type-matching object reference.

Python does have many great libraries (though java isn't too bad at all) but I do not at all find it easier or faster to develop once a project is worth setting up a Java devel pipeline. Don't forget the cost to write all those tests which are much more necessary in Python than Java (and yes I have many more run-time errors with Python than Java).

Kotlin is a face-lifted & flab-tucked Java, compatible with all JVM libraries, and Scala is an interesting and sophisticated language with the same.

Personally, Fortran, and I mean modern Fortran 95+ is heavily underrated in usefulness. It still has by far the best array and matrix handling, many excellent intrinsic parallel constructions, an very good and ergonomic syntax (it went from the worst to the best with F90) for its purpose, and of course speed speed speed.

If it had been invented by some well funded Silicon Valley startup with a hipster web designer and partnered with nVidia as their native development platform for CUDA GPUs, it would be the considered the new hotness.

And it solved the Python indentation vs C/Java brace wars correctly: newlines are significant, tabs and space indentation is not.

if (cond) then
      statement
else if (cond2) then
      statement
else
      statement
endif

And there has been academic empirical research on syntax style and errors----that one won. (I think it is also what Ada did).

Re:No

[StikyPad]

You can shoot yourself in the foot with any Turing-complete programming language, and most of the items noted in "The R Inferno," are in no way unique to R, such as floating-point operations, the pros and cons of various memory allocation strategies, and inherent problems in dynamically typed languages. These are CS101 issues, and the target audience of the book seems to be mathematicians with little or no exposure to programming.

Re:No

[SoftwareArtist]

> Python has JIT-compiling these days, and thus, like Java, can potentially run faster than static-compiled programs.

Not really. CPython, which is what most people use, is just interpreted. Sure Pypy has a JIT, but it's not that useful because so many libraries don't work with it. And even Pypy is still pretty slow compared to Java. That's not because the authors are bad at writing compilers. It's because Python as a language is really badly suited to JIT compilation.

I'm a big fan of Python and I use it a lot, but I don't think it is or should be "the dominant language". It's good for certain things (single use scripts, chaining together libraries written in other langauges), but bad for others (anything that has to be fast, big code bases with lots of interacting parts). And long term, I think more modern languages like Swift and Kotlin "should" win out. They combine the benefits of Python (fast to write code) with the benefits of Java or C++ (faster execution, static typing).

Re: No

[Darinbob]

I was a proctor for an intro to programming class for a couple of years, teaching Pascal. All the students who showed up already knowing BASIC and proclaiming that they already knew how to program tended to have the most difficulty in the class. Some would whine that it was a waste of time to declare variables.

Declaring variables and their types is very important. The reason there are unit tests and code reviews are to find bugs early, because the earlier you find them the cheaper they are to fix (and horrendously expensive if the customer finds them). So having type checking often means finding bugs very early. It means you don't wait until late in the process before you run a static analysis tool before the errors show up.

Re:No

[Darinbob]

Modern C compilers that are fully compliant to the latest standard will compile code that works with C89 (before Python was invented). With a flag or two they will likely compile K&R C as well.

Betteridge says:

[KeensMustard]

No.

But in all seriousness, is this even for real or just clickbait? Why would we want just one programming language?

Re:Betteridge says:

[sthomas]

To.... rule them all?

Re: Betteridge says:

[K. S. Kyosuke]

You don't, but it better be reasonably powerful. Languages like Lisp or Forth can sustain themselves because of their "all-level" nature. COBOL is is the obvious opposite. Python sits somewhat closer to the former but the sheer size of PyPy suggests it may still be somewhat lacking.

Re:Betteridge says:

[jellomizer]

There is a difference between being the dominate language and the only one.
C has been the dominate language for decades and they were also many other popular languages as well. However dominate language status meant you better know this language because even if it it isn't your bread and butter you will run across it.

However today where hardware is cheap and fast and most software written is web based or cloud based means that many of the advantages of the older language are becoming moot. Now that being the case these languages will not go away there is still a need for them Python is just an interpreted language. We still need language that compile to an optized binary format and we still need high performance software that will run on the local system. But just not as much as before.

Re:Betteridge says:

[jblues]

640K programming languages ought to be enough for anybody.

Re: Betteridge says:

[zifn4b]

Languages like Lisp or Forth can sustain themselves because of their "all-level" nature. COBOL is is the obvious opposite.

When you mention Lisp, Forth and COBOL instead of Ruby, NodeJS, Haskell, etc. it's probably time to retire.

Re: Betteridge says:

[K. S. Kyosuke]

NodeJS is a language? Well, if people say things like these now, maybe I really should retire for my own sanity.

Re: Betteridge says:

[K. S. Kyosuke]

So....denotational or operational semantics? :D

Re:Betteridge says:

[chthon]

Steel Bank Common Lisp has the best Common Lisp compiler. With the right optimisations you can build code that is as fast as C.

Re:Betteridge says:

[jellomizer]

The real advantage of Web-Based and Cloud systems is really we are saved from the pain of deployment, not programming time. Deployment on PC's creates a ton of problems. Such as having to make sure the PC is functioning correctly when they are software errors, Dll and other sub systems that come in conflict, then trying to push updates on a wide scale.
In terms of Python vs. C. on System resources is often very minor. And for most applications they may run faster in Python, just because better versions of algorithms are on hand built in vs. having to code it yourself. In real life doing C Coding if you are under the pressure to get it done and working. Picking the better performing algorithm may fail on a good enough easier to code algorithm. C and C++ coding is good when you really need performance as one of the key features. Python will be better for cases where the program needs to be deployed fast and and run well.
What is actually more expensive than hardware and development time, is opportunity cost. If a process by hand costs a company of 1000 employees to waste 20 minutes a day which can be automated to run near automatically say 2 seconds in Python or 1 second in C. So saying the average employee is getting paid $20 an hour. That will mean that every week $33,000 is wasted every week, now if that program takes 1 week to develop and deploy in Python vs 2 weeks in C. That will cover the cost of hardware and development time, in that one week difference.

Re:Betteridge says:

[Austerity Empowers]

Why would most of us need more than one programming language?

I find that Python and C combined answer 100% of my programming needs. While C alone can do literally anything at all, as the youngins are quick to point out "there's all those pointers". Some tasks need to be done quickly, other tasks need to run quickly.

Re: Betteridge says:

[TechyImmigrant]

Surely you mean LISP, not Lisp.

Yeth,

Betteridge's law of headlines

[Anonymous Coward]

No.

Can you just stop?

I will now end the discussion with the word Hitler.

Re: Betteridge's law of headlines

[plopez]

You Hillary supporters don't understand Godwin's law.

Re:Betteridge's law of headlines

[fahrbot-bot]

I will now end the discussion with the word Hitler.

But he would have totally been on-board with the whole whitespace to delimit things thing ...

No, because meaningful whitespace

[mfearby]

Enough said. Whitespace which has meaning is just nasty.

Re:No, because meaningful whitespace

[Hognoxious]

I agree, and so do many therapists.

Re:No, because meaningful whitespace

[thesupraman]

Iseeyourpointinfactifeelthatyoushouldpushforsuchaconcepttobemorewidelyaccepted.

Or, on the other hand, perhaps it is just as valid as any other parsing requirement? Language commands need some form of context, python just happens to choose that one.

The real issues with python are lack of performance scaling within the language (without using extension hacks), and the horrific threading problem. If those were solved then it would be much much much better.

Fwiw I have been developing commercial systems in python for over ten years.

Re: No, because meaningful whitespace

[plopez]

The last programming I know of, other than the joke ones, that had significant white space was Fortran 77. That was due to punch cards. It was due to punch cards that you also could not use lower case letters. F90 discarded white space significance in 1990. Thee years later Guido reinvents it. What next, is he going to force us to use UPPERCASE CHARACTERS?

Re:No, because meaningful whitespace

[Anonymous Coward]

I'm a Whitespace developer, you insensitive clod!

Re:No, because meaningful whitespace

[Anonymous Coward]

BS. Any sensible programmer will produce code with the same correct indentation, but with the added ugly-braces or ENDIF, or whatever clutter that language uses. Python recognizes this, and does away with the clutter for the sake of cleaner code.

And if you start mixing up the indentation then you'll get a big mess anyway, no matter the language.

Re:No, because meaningful whitespace

[superwiz]

It doesn't have a threading problem. It solves the threading vs process problem. CPU bound threats *should* be processes. And it is safer and more efficient to have 1 GIL per CPU. IO bound threads should be threads. This why threads developed on 1-CPU machines and multi-process model developed on multi-CPU machines. Python has 2 libraries with effectively unifying model for inter-thread communications, but one uses processes while the other threads. Both have almost the same API. Processes are bad if you need a context switch before data can travel from one task's to another task's space. In modern processes, you lose more by having data travel from 1 L1 cache to another L1 cache. So you might as well have 1 CPU-bound thread per core when your threads are CPU-bound and do very little talking to each other. Which exactly what you get with multiprocess threading library.

Re: No, because meaningful whitespace

[K. S. Kyosuke]

Whar does Jesse James say about lack of diversity?

Re:No, because meaningful whitespace

[Geeky]

Agree. Code should not fail to run because of programmer errors that are not visible in the text editor - i.e. a stray tab instead of spaces.

It's also a nightmare copying code snippets, especially from the web - you might as well retype them by the time you've fixed the tab vs. space issues.

Re: No, because meaningful whitespace

[itsdapead]

Braces didn't win over whitespace because of C's readability.

Its not about readability: its about not having your code turned into line noise because you accidentally left "hard tabs" enabled in the editor, some idiot hit "reformat" or or mixed DOS and UNIX line endings, or tried to merge code written by some heretic who indented by 3 spaces instead of the 2 spaces carved in stone by His Noodley Appendage.

Like all punctuation, it is a bit of Belt and Braces (haha!) redundancy that removes any ambiguity and which you'll be grateful of should you ever need to reformat your code.

Maybe that's the thing - it appeals to the Sheldon Coopers of this world that code written by anybody who doesn't follow their particular One True Indentation Style (or nests blocks more than 1 deep when they should implement any sequence of more than two lines as a function) can be deemed officially unusable and can't be fixed at a stroke by hitting Escape-meta-whatever.

Re:No, because meaningful whitespace

[religionofpeas]

It's because the indentation happens automatically based on logical structure, not the other way around.

Re:No, because meaningful whitespace

[Geeky]

The difference between wrongly balanced braces and whitespace is that whitespace is invisible. You're literally trying to debug an invisible error - it's indented to the same level, but with a single tab instead of spaces.

Maybe I'm using the wrong editor, but I get annoyed at the number of times it seems to forget that I'm using spaces to indent and adds a tab, throwing off the code. I have to keep running the "convert tabs to spaces" function on it before I save.

OK, I'm an occasional Python programmer, so maybe it annoys me more than someone working with it all day every day. It's just a mental gear shift and annoyance that I could do without compared with every other language I currently use. There's a lot I like about Python, but the whitespace thing is a pain in the arse.

Re:No, because meaningful whitespace

[Ihlosi]

So, unfortunately, are zillions of easily mismatched, hard to read, bracket pairs.

Which are definitely a problem of the person who wrote them, not with the programming language. And it can easily be fixed by teaching said person to write human-legible code, which includes much more than just proper placement of brackets.

If you have programmers working illegible code, then Python won't save you, because there's about a few hundred things that make code illegible that work just fine in Python.

Re: No, because meaningful whitespace

[Anonymous Coward]

Python reminds me of the assholes who insist everyone indent with literal spaces instead of tabs:

Pointless rules by rockstar fuckos who are so talented they can't even figure out how to adjust tab width on their editor.

Re:No, because meaningful whitespace

[Dog-Cow]

Correct indentation, in normal languages, is helpful for the human reader, and is fixable by the computer. In Python, it is mandatory for both, which means the computer can never help. Creating a language that prevents automation, to be used on a tool for automation, seems like sadism to me.

Re:No, because meaningful whitespace

[BenJeremy]

Wow, great way to prove the point that C is superior due to the requirement of proper scoping delimiters.

If I have mismatched braces, I can EASILY track that down. I can also de-obfuscate the code above in almost any modern code editor into a readable format.

Python? No, not so much. Not at all, in fact.

Re:No, because meaningful whitespace

[goose-incarnated]

So:

#include int main(void){int i;for(i=1; i<=100; i++){if(((i%3)||(i%5))== 0) printf("number= %d FizzBuzz\n", i);else if((i%3)==0) printf("number= %d Fizz\n", i);else if((i%5)==0) printf("number= %d Buzz\n", i);else printf("number= %d\n",i);} return 0;}

Actually, that IS superior to using whitespace for indentation, because I ran it through indent on the default settings and got this..

If that line of code was python, no tool on earth will figure out the correct formatting. You provide a compelling reason for whitespace to be independent of meaning in the source code.

Re:No, because meaningful whitespace

[mfearby]

You mention "easier readability" but I wonder if Python gets any love among blind developers? I wouldn't want to be counting spaces in my head to determine where I'm at (you'd probably even have to turn on the reading-aloud of spaces, which would just drive me nuts!)

Re:No, because meaningful whitespace

[ceoyoyo]

You're using the wrong editor. Probably an IDE? IDEs are evil.

Personally, I find braces the bad option. Whitespace IS visible, and the interpreter will happily point out where you (or your editor) screwed up. Braces are hard to keep track of, particularly when heavily nested. Of course, if you use whitespace appropriately the braces are much easier to track....

Re: No, because meaningful whitespace

[nasch]

How many of those conventions are about something that you cannot normally see and screw up the code if done incorrectly?

No

[grungeman]

And my teacher was wrong. There actually are stupid questions.

eh

[buddyglass]

I could see it supplanting Java in some situations and utterly obliterating Ruby and PHP. That said, I like compilers, even if they're compiling to byte code. And I don't find refactoring to be a chore. Especially when your IDE does some of the more mundane tasks for you.

Re:eh

[Ambassador Kosh]

I can easily see it supplanting Java in many situations. My experience is that usually python solutions end up faster and easier to work with than Java ones. Mostly because of the libraries. It is easy to make a cross platform python program that uses native gui libraries, image libraries, numerical libraries etc.

When I have looked at things like simple numerics in Java it gets killed by C++ and by Python since Python programs will normally rely on scipy which will in turn rely in BLAS and LAPACK. From everything I have seen so far calling BLAS from Java through the C runtime has higher overhead than doing the same from Python and the pure Java numeric runtimes are BAD.

It is just easier to end up with cross platform working code by coupling Python to low level libraries.

Re:What it is used for?

[Hognoxious]

It fills the "smug hipster twat who can't grok lisp" niche perfectly.

Re:Dominant where?

[Anonymous Coward]

And is not an important project, so that you will never do branches or merges.
Because merges + significant whitespace = unholy mess you will spend ages debugging after each merge.

Lol

[Anonymous Coward]

Is that a parody?
"People who complain that you can't build large scale systems without a compiler likely over-rely on the latter and are slaves to IDEs"

Sure, who needs good tools when you can just do the work of the compiler yourself?

I'm pretty sure - the day will come where even the author will be bored of checking datatypes and constraints in unit tests that have to cover all possible runtime paths. For me the future will be a language with a really strong type system, that can be verified by the machine as much as possible. You can't have systems crash after 4 days of number crunching because it finally reached that stupid mistake in one path that was forgotten in the unit tests.

We have computers to do that work for us, not the other way round.

Oh and of course we'll use machine learning as much as possible to automate the automating.

Re:Lol

[Entrope]

Most of my time is spent working on an app with C++ at the low levels, Python at the high levels, and Perl/JS for web stuff. I am one of two developers who primarily does C++, we have two who primarily do Python, and one who primarily does the web bits. The Python code unsurprisingly does a lot of database operations and IPC, so many of its endpoint types are strings. I am always shocked how many of the Python-domain commits are only to add or remove type conversions that testing missed. That problem is almost entirely absent in C++, with its strong static typing, and in Perl and JS, with their mostly "DWIM" operators and types.

I do not bet on Python being much more than a glue language unless it gets strong compile-type type checking. That may be enough to make it a "dominant" language, because people ship more and more good libraries that can be simply picked up and used by higher-level code, but it will probably never displace other languages without stronger compile-time checks.

Re:Lol

[MatthiasF]

I wish I could find an IDE worth learning so I could stop needing to learn all these damn languages.

False equivalence.

[Lanthanide]

False equivalence. It doesn't say "one" programming language, it says "dominant" programming language.

Global Interpreter Lock

[fazig]

Is that still a thing in Python? I've been out of the loop for quite some time. But the last time I've been into it, this 'feature' was a big obstacle for modern hardware, considering the hardware trends of having more and more CPU cores.

Re:Global Interpreter Lock

[oakgrove]

It's still a thing and likely will always be a thing. That said, the multiprocessing module makes writing code that can spin up as many processes as you want and allow them all to communicate is relatively painless.

Re:Global Interpreter Lock

[oakgrove]

Maybe true but I just say that I write my fair share of Python scripts using multiprocessing and it works for me. That said, if somebody feels like the GIL is truly getting in the way, there is always IronPython and Jython, neither of which have this restriction. I also believe the PyPy team is working feverishly on getting rid of the GIL in their implementation which among other things is much faster than regular Python thanks to just in time compilation. I've used it for a few things and heartily recommend it if speed is of the essence.

More info here for those inclined.

Yes and for bad reasons

[plopez]

The same reason we had languages such as Basic and Pascal as languages. Namely universities using them in intro classes because they are "easy". So people with no concept of the scale or complexity of commercial software think it is the be all and end all of programming. So you get MBAs mandating Python on their projects even though it is the wrong tool for the job.

Re:Yes and for bad reasons

[blind biker]

I dunno, I think Pascal was awesome and I would always love to use it. I see absolutely no downside to Pascal.

Depends on the future

[Opportunist]

Python is easy to pick up and can do anything (on high level) that C can. On the other side, its drawbacks include being an interpreted language, meaning both that whoever wants to run Python scripts has to have the relevant interpreter on his system, which is arguably easier and more likely to work in Linux than Windows and that it will run slower and need more resources than a comparable C program.

So whether Python will become the dominant language will mostly depend on

1) Whether enough people with little to no programming experience feel the urge to create code.
2) Whether enough people can be bothered to install the runtime to run said code.
3) Whether we continue to have no problem wasting resources on inefficient code or whether we move towards more virtualization/containerization where the individual VMs have to do with very little CPU time.

Re:What it is used for?

[Jon Peterson]

Java is mainly large enterprise back end systems, and some android, and quite a lot of embedded stuff (nominally what it was invented for), and, worryingly, quite a lot of client side GUI stuff.

C++ is used for legacy systems and where you need speed.

C is used where you need speed, have simple programs and memory constraints, and old fashioned unix software.

C# is for windows programming and .net

Javascript is for browser programming and Node, and some general scripting, where someone has used it as their system's internal scripting language (see also lua)

PHP is used for relatively simple web stuff, because it's easy and works and has wide library support

Python is used for what PHP is by better developers, and has brilliant maths libraries so is increasingly used for anything maths related where esoteric things like matlab and R and F# are unhelpfully niche.

Haskell is used for academic curiosity, and some maths stuff.

Perl is dying out, but is still used for unix automation a fair bit.

Ruby

[Meneth]

I should hope not. Ruby is much nicer.

Re:Ruby

[BlackPignouf]

Ruby lover here. I can code Ruby while I sleep, but I felt a bit left out because there are so many awesome Python projects.
In comparison, there's Rails as awesome Ruby project with a lot of momentum, and .... that's about it.

With Ruby knowledge, it's actually pretty easy to grasp Python. There are a few gotchas and the syntax feels a bit boring compared to Ruby, but it's also easier to read other people's code because it's usually more explicit and a bit less dynamic than Ruby.

I still love Ruby, but it's good to be able to write a few lines of Python and release the power of Numpy/Pandas/Sympy/Matplotlib/NetworkX/... It took me about 2 weeks to learn enough Python to use those libraries, and I still learn new stuff every day.

Some parts of Python's syntax are really nice, e.g. list comprehension :

    >>> [x**2 for x in range(10) if x % 2 == 1]
    [1, 9, 25, 49, 81]

It's completely different than all the Enumerable methods in Ruby, but it's very powerful and quite easy to read after a while.

Python is great for command and control

[Ambassador Kosh]

There are lots of good libraries for python that hand off the heavy lifting to c,c++ and fortran. Python works well for gluing these things together.

Python on its own though is quite slow and if you find yourself needing to chain together calls between low level libraries where each call is quite fast the cost of gluing them together can be extreme. However the parts of the code that are seriously CPU bound tend to be fairly small while all the rest of the stuff build no top takes up most of the time to write.

I would say for most software you could do a python wrapper around a C++ core and end up with more maintainable and faster code. In my case I use a python optimization framework around a c++ based simulator. Writing all the optimization code in C++ would be a pain in the neck and provide no real speedup since the current code is not speed bound in the python part anyways. I see the same things in cluster control software when the code that distributes my jobs to the nodes and then gathers the data back and then makes the decisions on the next set of jobs to run accounts for 1% of the total runtime.

I think this will result in better software overall with Python as the core language wrapping high speed libraries. In many cases those libraries already exist, where they don't exist you have to write them.

LOL

[Otis_INF]

People who complain that you can't build large scale systems without a compiler likely over-rely on the latter and are slaves to IDEs. If you write good unit tests and enforce Test Driven Development, the compiler becomes un-necessary and gets in the way.

No, dummy, the compiler is a large set of unit tests for you, ready to run, so you don't have to write them yourself. Why wouldn't you use a compiler so you can avoid runtime exceptions/errors? Why would you choose deliberately to postpone that to be checked at runtime or worse: that you have to write checks for all those cases yourself (and you'll miss a lot of them)

The compiler isn't something used by 'slaves of an IDE', but by developers who know a compiler will save them from writing tests for situations already checked by the compiler. Oh, and it generates fast code ahead of time too, so your users don't have to wait for an interpreter to come up with fast code.

Re: Clickbait is clickbait

[Malenx]

My college taught had a course that went through every language to teach differences and focused on the fact that there were different tools for different tasks. The core classes however all used java to teach programming principles. I really felt it was the right approach. Learning different tools is necessary as a programmer, but even more important is the proper mindset, patterns, and approaches, regardless of our chosen language. A good programmer can pickup any language and work towards proficiency then mastery.

modules

[DrYak]

So, you can see the attraction of Python for, say a scientist - there are modules for many specialised, mathematical areas, all of which are very difficult to code from scratch, and although there are similar packages for C, C++ and FORTRAN, they are less easy to just pick up and use.

Note that often, the Python modules *are bindings* to the C/C++ & FORTRAN packages.
Python is literally the glue code layer that makes these modules "easy to just pick up".

Perl...

[Freischutz]

Python will never beat Perl ... ever!!! **Ducks for cover**

Re:Perl...

[ckatko]

I find it disturbing that people would want Python to beat Perl.

Women have enough problems with domestic violence. We shouldn't be supporting hitting a woman with a snake.

No, because it's too slow

[butzwonker]

I admire Python for its toolchain and libraries but it's just way too slow. Even Racket is faster and it's probably still too slow for my current needs. ( I use it for making a prototype first.) By 'slow' I refer to lack of snappiness and long startup times, these bottlenecks cannot be eliminated by writing support libraries in C. The actual algorithms I use don't need much speed, but the user interface and support functions like searching, directory scanning etc. need to be fast. You can fake speed by using a lot of threading in the user interface, but that's complicated, error-prone, and the end result still feels somewhat sluggish.

Ok, I'll bite...

[wheelbarrio]

I'm a fan of Python, but this question is a joke, right?
Sidestepping interminable arguments about the merits of language A vs language B, and ignoring the flat-out ignorant assertions in the 'anonymous reader's thoughts' about IDEs and compilers, the question is predicated on a culpably ignorant interpretation of the very data they cite.

So here's how PYPL works:

The PYPL PopularitY of Programming Language Index is created by analyzing how often language tutorials are searched on Google.

so... what the data actually show is that relatively more folks want to learn Python these days than C or Java or Haskell (or whatever) — which is scarcely surprising since more non-specialist programmers are learning to code than ever before, and Python is easy to learn and great to teach with for that demographic — what the data definitely do NOT show is that Python is replacing C or Java or Haskell (or whatever) in the production domains in which those languages shine. And it never will.

I don't think so

[gweihir]

Don't get me wrong, I like Python and have done quite a few things with it, including performance-critical Python classes in C. But I think writing good Python code is something that requires a lot of experience, including with other languages. Python is a language that does not stand in your way to an extreme degree. That means in many cases you have to do things yourself that other languages do for you, for example type checks (yes, they are needed sometimes) and decisions when doing inheritance. Do them wrong or not do them at all and you end up with an unmaintainable mess. There is also quite a bit of stuff you have to test at run-time that compiled languages probably find at compile-time. That requires good testing and a design-by-contract approach helps a lot.

One the other hand, for actual experienced experts, glue-code and "business logic" does not get much better than what Python offers, and embedding C-code is easy once you have understood the idea. It definitely has a long-term future.

It Depends

[Mordaximus]

Interestingly, selecting countries on PYPL shows that Python is #1 in the US, France and UK. India and Germany have Java #1.

Not that it's an indication of anything, really. Right tool for the right job. The projects being worked on in Java probably don't lend themselves well to Python and vice versa.

Dominant?

[aglider]

Please elaborate. By number of lines written? The number of programs written? The number of fortune500 choices?

Should disallow mixing tabs/spaces

[swilver]

If Python just disallowed mixing of tabs / spaces in files, it would already be a lot better. Just flag an error as soon as indentations are detected that are not the same style.

Re:Reduced tool complexity = econonomic beneifts

[squiggleslash]

We're only going to reduce errors if it's a programming language that makes errors harder to make. I switch routinely between a number of different languages in my current job, and it's not the switching that has any affect on the reliability of the end result.

I can also pretty much guarantee that if the world did standardize on just one or two languages, it'd probably be the worst of them. For better or worse, the languages of the world wide web right now are Javascript, PHP, and C. The infrastructure is written in C. The applications are written in PHP. The front end is written in Javascript.

These are three awful, awful, programming languages to standardize on, and yet within one sector of the industry, that's exactly what we've done. Why have we done this?

- We standardized on C because we'd already standardized on it in the mid-1980s. It could have been Modula 2 or Oberon, but we ended up with C because at the time we were trying to squeeze functionality out of every byte of memory. Ironically, C is so clumsy we've ended up abstracting everything up the wazoo a million times and so it's far less efficient than it needs to be. There's no need for Apache to be written in C. But when Apache was written, that was what you wrote Unix servers in, so, 20-25 years later we're still stuck with it.

- We standardized on PHP because it's easy for non-developers to pick up, and it was there, and it was free, and it was kinda sorta marketed at them at a time when everyone wanted to build a website. And as a result critical frameworks like Wordpress are written in PHP. PHP is seductively convenient too, but almost everything that makes it convenient also is a bomb that just needs a detonator of ignorance to cause a problem.

- We standardized on Javascript (which is perhaps the better of the three languages) because it's built into every web browser because every web browser in the 1990s had to be compatible with Netscape, and Netscape introduced JS.

At no point were issues like reliability or security considered as criteria for the "market" to pick these three. The market didn't care. And so we're stuck with that as our technology stack.

The only way out of this mess is to be able to break out of "standards" and be able to use better languages as they come up. The market failed in terms of picking a sane winner. But as long as there's more than one stall at the market, better developers can at least get around that.

Re:Reduced tool complexity = econonomic beneifts

[drinkypoo]

It seems like we could derive most of the benefits by extending more languages to be able to use... one another. So that if we have a code component written in one language, we can more easily use it in another language. Obviously there are mechanisms for doing this already in many if not most languages, and even some systems. It is (or was?) a standard feature of the AS/400 platform (whatever series they call that now, or did they finally kill it?) that you could link together code from multiple languages into a single binary. I'm not familiar enough with the architecture to know how their approach works, I just took a basic class and that stuck out.

To quote a legend...

[GotoGuy]

"Do you think Ringo is the best drummer in the world?" "Ringo isn't even the best drummer in the Beatles."

Overconfident bullshit

[lorinc]

People who complain that you can't build large scale systems without a compiler likely over-rely on the latter and are slaves to IDEs. If you write good unit tests and enforce Test Driven Development, the compiler becomes un-necessary and gets in the way.

Says the guy that never worked on a project with 100+ classes and 100k+ lines of code...

Don't get me wrong, I love python and it's become my main programming language. But hey, I'm a researcher and everything I code doesn't have to do more than producing a few results to put in a paper and then be thrown away and never looked at again.

You know why Java is the top language now? It's not only because it's so easy that many professional applications have been written 15 years ago by dumb interns, but also because it's so robust that these applications can still be maintained by even dumber interns today. You're never going to get that with python (or js, or ruby, or whatever new hype thing you believe is the new messiah).

Re:How many anonymous readers?

[Desler]

Grammar nazi fail:

: his or her : his, her, its —used with an indefinite third person singular antecedent
anyone in their senses — W. H. Auden

https://www.merriam-webster.co...

Re:Wheel re-invention

[Ambassador Kosh]

I don't want to write a genetic algorithm with automatic switchover to various gradient descent methods based on local properties in any kind of shell script. The python version of that code takes up 1% of the runtime for me and serves as a command and control system for my c++ simulator. The same is true for plotting the results afterwards and evaluating the quality of the results.

Almost all the command and control I am talking about using python for is not something I would EVER consider doing in shell script.

Re:Reduced tool complexity = econonomic beneifts

[Chris Mattern]

the AS/400 platform (whatever series they call that now, or did they finally kill it?)

IBM changed the name to "i series" in 2000 and replaced it with the Power series in 2008. They still offer the software platform (originally OS/400) to run on Power servers, calling it "IBM i"..

Re:Dominant where?

[goose-incarnated]

Non-issue. It's no different than agreeing on a nomenclature before starting any other software collaboration. If you don't, you'll get a big mess, regardless of language.

Incorrect - in non-python language I can run an indent program, turning the big mess into a non-existent one. In python your big mess has to be manually fixed by a human.

Javascript?

[Zobeid]

I thought Javascript was going to rule the world? Dammit...

Re:No, not for a long time.

[barbariccow]

But are there Kanji (to use the Japanese term) based programming languages?

My experience working with Japanese coders is that no major language supports arbitrary glyphs. If they did, it would probably be like the early specifications for perl6 with the "Yen" operator and whatnot. The language doesn't construct like Arabic languages.

They just program in ascii with variable names and functions which they sound out to their words. But they can put Kanji or Katakana into comments above lines, and they generally over-comment.

Re: The answer is no

[barbariccow]

But I speak EXCLUSIVELY in "Personal Home Page"

Don't you want "Personal Home Page" for your business?

Crap I forgot <?php during some random error handling case and now it's printing all my source code....

die('A lonely, sad, death.');

Re:No Python does not have actual threads

[MightyYar]

It's a wart, but it shouldn't stop you from getting your parallel computing done. You fire up the multiprocessing module, create as many processes as you think you need, and start crunching. I write most of my longer-running programs this way so that I can take advantage of multiple cores. But that's the beauty of Python - it's easy to avoid premature optimization. Write the script the easiest way first, profile it, and then go after the low-hanging fruit. Worst case, you end up with working code written entirely in C that's been thoroughly prototyped in Python. :)

Dominant, or most popular?

[Angst Badger]

According to the linked PYPL rankings, Java is at the top with less than a quarter of the market at 22.7%, and other ranking methodologies return different results with lower percentages for everyone. I like Python, along with several other languages on the list, but the reality is that the language market is highly fragmented and, for obvious reasons, overwhelmingly likely to remain so. There is no dominant language now, and arguably hasn't been one since the early days when there were relatively few languages, so why would there be one in the foreseeable future? Could Python become the most popular of many languages by a few points? Sure. But does that matter in any meaningful way?

I ONLY use Python becaues I can't use Perl

[furry_wookie]

Frankly I would much rather use Perl, but its not cool and people will complain if I did.

So I use Python because no one complains about it.

not without major changes

[ooloorie]

Python's widespread adoption is not due to some magic programming language sauce but network effects. In a sense, Python has taken on a niche similar to Visual Basic. But that's also why Python has such a hard time evolving: you can't improve it much without breaking a lot of its libraries.

Python's biggest limitations, the way it represents objects and limited concurrency, actually already have been addressed in a number of Python re-implementations, but people aren't using those because many extensions and libraries don't quite run in those environments.

So, Python won't become "the" dominant programming language, it will just remain one of of a number of popular programming languages.

If there will be a single dominant programming language eventually, it will probably have to look more like Swif: near native speed, garbage collection, some systems programming features, and yet interactive execution via on-the-fly LLVM compilation.

Re:No Python does not have actual threads

[tepples]

You fire up the multiprocessing module, create as many processes as you think you need, and start crunching.

Then serialization and deserialization of objects to and from the manager process spawned by the multiprocessing module becomes the bottleneck.

Python 3 makes tab/space stricter

[tepples]

Python 3 already goes much of the way toward this. Instead of treating tab as round up to the next multiple of 8 spaces, as Python 2 did, Python 3 requires the entire sequence of leading whitespace to match in order to include statements in a block. So if you mix tabs and spaces, you're much more likely to get IndentationError in Python 3 than before.

Static vs Dynamic

[samwhite_y]

Here is my take on the situation, and much of this has essentially been said by others in one form or another.

Some of the debate here seems to be a repeat of prior debates between static and dynamic languages. Dynamic languages have a lot of perks. Usually the compile speeds are awesome, building small solutions quickly is likewise awesome. They also usually make it easier to write less lines of code and the code is usually more elegant and straightforward with less overhead and few or minimal boiler plate constructions.

But dynamic languages really fall over when the project you are working on reaches a certain level of size and complexity and really die when issues of scalability and performance become primary factors. In particular, the places where I have run into trouble are the following.

* Having to refactor an API used throughout an application because of a new feature (such as instrumenting with auditing number of calls to persistent storage and time take to make such calls).
* Using an IDE to investigate somebody else's not so great code (but a vital, complex, and deeply integrated component in much larger project) that was written two years ago that needs a serious refactoring and upgrade to continue its viability. Usually part of this investigation involves using a debugger. If the code had great documentation and unit tests, it probably would not be a problem. But assuming that you are always going to work with great code is nonsensical.
* Writing code that uses optimal algorithms and minimizes usage of persistent storage. It can sometimes be quite hard to predict the performance characteristics of a particularly complex piece of dynamic code (especially one that uses "code blocks" and other functional programming styles).

Coding in static languages is more laborious, has more up-front costs, and in general can be a large pain when compared to dynamic languages. But having an IDE and compiler enforcing sophisticated contracts between various modules in your code set are vital to the long term viability of large projects.

Re:Static vs Dynamic

[h4ck7h3p14n37]

I find learning new APIs to be much easier when a language is statically typed like Java versus something with dynamic typing like Python.

With Java you can look at hardcopy of code or Javadoc, see the interfaces, the classes, the method calls, the type for each parameter and slowly work your way through how it all fits together. You can find a method that does what you want and then see that you need pass in an instance of class A and then go read about how to get an instance of that class and so on.

With Python code you have no clue what types are allowed in your function calls just by doing static analysis. If you're lucky the author added comments to document this missing information, but you typically have to fire up an interpreter, execute some code and then look at what you get back. This makes learning new API's from only the code much more difficult.

I wish Python would give you the option of specifying types and let me omit that information only when I want to instead of forcing me do the C equivalent of casting everything to void *, or making everything an Object in Java.

perl5 advantages

[doom]

On a serious note, perl5 has some actual technical advantages over python (and most other languages), e.g. it's unicode support is excellent. Perl regular expressions can search for characters based on unicode properties, e.g. /\p{Greek}/ matches a character Unicode considers Greek.

Re:Reduced tool complexity = econonomic beneifts

[petermgreen]

In practice what has happened is that "C style" interfaces have become the common point for interoperation between languages.

So you basically if you want to call code written in language A from language B you have to.

1. Wrap the code written in language A in a C style wrapper.
2. Wrap the C style wrapper in language B.
3. Work out how to build/link the resulting project.

This is doable but it's a sufficient PITA that a lot of the time rewriting the code seems more practical.