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

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:

[K. S. Kyosuke]

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

Betteridge's law of headlines

[Anonymous Coward]

No.

Can you just stop?

I will now end the discussion with the word Hitler.

No, because meaningful whitespace

[mfearby]

Enough said. Whitespace which has meaning is just nasty.

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

[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

[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

[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

[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!)

No

[grungeman]

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

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: 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.

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

[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 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.

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: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.