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

[Anonymous Coward]

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.

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

[K. S. Kyosuke]

Sadly, I had the C64.

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

[Rockoon]

Didn't the C64 use Microsofts ROM BASIC? If so then it should have had DEF FN. Every other machine sporting a Microsoft ROM BASIC did.

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

[Njorthbiatr]

But a lot of the changes were for the best. raw_input has been turned into input, for instance. The last thing anyone wants is having a language with built-in runtime errors.

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

[Anonymous Coward]

It isn't that bad, I've got a little Perl script that will make all the changes to "upgrade" v2 to v3.

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

[LifesABeach]

Foolish A/C, try using Google; Python has treads, and so does Java.

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

[fph il quozientatore]

Not that sure --- R is such a clusterfuck that someone managed to write a succesful 150-page book about the different ways in which you can shoot yourself in the foot with it.

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

[Creepy]

Properly programmed assembler should always be as fast or faster than C++ and C, but out of order execution is nearly impossible to program these days. In any case, interpreted languages with Just In Time (JIT) compilers can outperform static compilers, but in practice they rarely do outside of controlled environments, at least in my experience. I've seen SmallTalk (Squeak I believe) absolutely smoke a compiled Windows program, but it was demo'd by a SmallTalk guy that probably wrote everything that is advantageous to SmallTalk and disadvantageous to Windows intentionally just to show off how a JIT can be better than a compiled program if conditions are right.

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

[histreeonics]

(Early 1990's anecdote:) C++ was not fully compatible due to stricter type checking and namespace rules. I found the differences beneficial and made my crew use C++ just as a stricter C. We only used polymorphism when it looked like it would simplify the if-then-else implementations otherwise needed.

Re: No

[Austerity Empowers]

It was, is and will always be useless for a certain domain of programming in which some of us live. We're also the same group of people who continue to use C, in spite of the fact that it does not have every new feature that some CS prof thinks is essential. In fact we prefer to not have that stuff, it makes everything more difficult for us.

However I know many people in finance and business functions who use Basic exclusively to this day, and probably will for some time to come. I'm not sure Python works for them.

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

[DrXym]

No it would not have killed both versions. Other projects have managed breaking transitions far more quickly and without wasting nearly a decade supporting two code bases with the subsequent confusion and stagnation that goes with it.

Re:No

[ArcadioAlivioSincero]

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.

Well the standard retort to that is "unit tests!!!11". It's like they think implementing something yourself what a compiler would do for you for free is supposed to be satisfactory. Eventually, your unit tests will need unit tests if we take this argument to it's logical conclusion.

The good news is that PEP484 gives Python3 "type hints" so that, theoretically, one could develop a tool that does exactly what a compiler does with respect to checking types. If I'm not mistaken, pylint already does this. Better late than never. I guess the "Unit Tests Will Solve Everything" crowd were wrong after all.

Re: No

[goose-incarnated]

It was, is and will always be useless for a certain domain of programming in which some of us live.

That's not was GP claimed. GP claimed it was useless in the real world, not that it was useless for certain domains.

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

[beelsebob]

Heh, "as long as you don't do janky shit like the things you listed."

Yes... because using malloc is "janky shit".

Re:No

[Jeremi]

Other projects have managed breaking transitions far more quickly and without wasting nearly a decade

Can you name some? In order to make the comparison fair, you should limit your examples to other popular programming languages that made a successful breaking change, since invalidating large, established codebases of user code is precisely what makes such a change so expensive.

Re:No

[goose-incarnated]

No it would not have killed both versions. Other projects have managed breaking transitions far more quickly and without wasting nearly a decade supporting two code bases with the subsequent confusion and stagnation that goes with it.

Which programming language made changes that broke the last ten years worth of software that was written in it, and survived? Perl?

Re:No

[Archangel Michael]

x86 is a perfect example of backwards compatibility both helping and hindering.

It helps adoption, and hinders progress. In the process, it is a stagnation of a large installed base. Eventually, progress happens anyways, and the large installed base misses out on advancements elsewhere and eventually goes away.

My main PC isn't running x86, it is running ARM(my Phone). I have an x86 PC, but it is fairly specialized to doing tasks built around x86 legacy stuff.

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

[DrXym]

Swift would be one recent example and provides a migration tool. But all languages have breaking changes at one point or another.

And besides, someone using Python 2.x is not compelled to move to 3.x but it can be made clear there are no new versions of 2.x and 3.x is where all development lies. It really isn't rocket science.

Re: No

[slazzy]

There's some truth to that in that both are easy to learn, and slower to run. However python is quite powerful - it can do almost anything. Basic was quite limited.

Re:No

[serviscope_minor]

Yeah janky. It's leak prone, not type safe and doesn't respect the pre or post conditions of your types :)

Re:No

[MightyYar]

Others who agree with you wrote mypy which is basically a lint-style checker for type. While I do get the occasional bug when a function supports more than one type - len() on strings and lists, for instance - for the most part the strong typing catches most mistakes, so I don't bother with the added clutter of static typing everything.

Re:No

[DrXym]

Look at the history of Cobol, Fortran, C, Java, Ruby etc. They all contain breaking changes in the language specification or the APIs from one version to the next. Some are substantial, some are not. People deal with the changes and move on.

The differences between Python 2 and 3 are relatively minor at a language level so there is no real excuse for prolonging 2x for ANOTHER decade and the inordinate amount of effort required to do so. Also 2to3 meant most code could be ported with relative ease. Ah but all the Python impls like PyPy, Jython etc. chose to hedge their bets and implement around 2.x and now it's a millstone. In the context of this article where it asks if Python will become the dominant programming language, the answer is perhaps it might have been if it didn't have its head up its ass for 10 years. All of this was avoidable.

Re:No

[goose-incarnated]

Swift would be one recent example and provides a migration tool.

When Swift made the breaking change the amount of software written in Swift was not even a rounding error. The amount of apps broken by the Swift change is so small you can't even measure it accurately.

OTOH, the breakage between Python 2 and 3 would have broken tens of millions of lines of code.

Re:No

[MightyYar]

I think you have it backwards - by supporting both versions they have managed to do what few other languages have: increased in popularity while correcting defects and inconsistencies in the original design of the language. I still tend to write for both v2 and v3 in my scripts - it's not hard - but you can pretty much ignore v2 now and be in good shape unless you have a dependency on some very niche library.

Re:No

[goose-incarnated]

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

Also, C took the const keyword from C++, and then broke it.

Re:No

[goose-incarnated]

These imperfections are completely outweighed by its superb readability/understandability/clarity, and the ease with which it can be learned.

Those attributes, in any profession, are not the ones that career-folk care for. They are highly desired by amateurs in every field, but not by professionals in the same field. This applies to all professions, not just s/ware development.

Re:No

[DrXym]

Swift is now the defacto development language for iOS so yes the changes impact a lot of code, first from 2.2 to 3 and from 3 to 4. The difference is Apple & the open source stewards basically said "here's a migration tool, use it or stay put". They aren't vacillating and dithering about their choice.

But like I said, every language and platform goes through this. The language evolves, gets standards, changes, deprecates stuff, introduces new APIs, removes old ones. Python made a bad choice to string out 2.x so long because it entrenched itself even deeper.

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

[Wycliffe]

Which programming language made changes that broke the last ten years worth of software that was written in it, and survived? Perl?

Perl is backwards compatible as well. There is a Perl 6 but it's pretty much dead in the water because it breaks backwards compatibility with the thousands of modules on CPAN. It's very hard for a programming language to get a high adoption rate. In order to become a popular language it has to bring something new to the table that existing languages don't have. This is doubly hard for an existing language that breaks backwards compatibility because it is also competing with it's older versions which already have an ecosystem. That's why backwards compatibility is so important. It allows you to get the existing userbase for free.

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

[Jamu]

I think it depends on the language. You'd want it in C. But what about high-level languages? All control commands can be replicated with gotos, but look at the reverse, shouldn't all high-level languages have a specific control statement instead?

Re: No

[K. S. Kyosuke]

In the Dartmouth/ANSI/Microsoft BASIC era. Quck Basic didn't run on any machine available to me in the 1980s behind the Iron Curtain.

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

[butzwonker]

They should have call/cc if they can afford it. But that's not easy to implement and has perfomance implications.

Re:No

[butzwonker]

JIT-compiling these days [...] potentially run faster than static-compiled programs

Argh, not this phrase again... potentially but never really.

Re:No

[beelsebob]

Sure - in C++ there are better options. In C though, you don't have new available. It's completely normal for a C program to contain uses of malloc.

Re:No

[angel'o'sphere]

The correct rebut is: there are no stupid questions, only stupid answers.
I believe you just gave one.

Re:No

[phantomfive]

Furthermore, it doesn't even need to be a superset. As long as you can make calls between functions written in each language, that's good enough. Separating your code into .c and .cc files isn't a problem.

Re:No

[bondsbw]

You don't have to loosen your definition of "janky" too much for basically all of C++ to fit.

Re:No

[TimSSG]

You made a great argument to support the use of COBOL. Tim S.

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

[sl3xd]

There is a Perl 6 but it's pretty much dead in the water because it breaks backwards compatibility with the thousands of modules on CPAN

Many would say that Perl 5 is pretty much dead in the water as well.

Perl 5 & 6 always appeared to me as the case study which lead Python to co-develop both 2.7 and 3.x simultaneously.

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

[StikyPad]

Python is quite powerful - it can do almost anything. Basic was quite limited.

That claim doesn't even make sense. It might be more difficult to perform certain operations in BASIC (or Python, for that matter), but neither is "more powerful" than the other.

Re:No

[SCVonSteroids]

Python has completely stepped on it's own dick

Yes but, with a dick that big, it would be hard not to step on it at some point.

Re:No

[Chewbacon]

Swift is working on that, too. All the cool languages do it.

Re:No

[doom]

I went with R, myself. While it's not entirely buzzword- compliant: it's oriented toward keeping the data-set in memory and so is not "Big Data" in vanila configuration, but there are people working on ways around that, and anyway memory gets bigger all the time.

Re:No

[doom]

Perl6 may yet triumph. Yeah, there's fewer cpan libraries, but there's a lot less need for them: a lot of common needs have been moved into the core language.

(And before you "do one thing and do it well" types get started, you need to focus on the fact that no one really does that, including unix, and sometimes the monolithic strategy wins.)

Re:No

[randallman]

Are you asserting that it's OK if it compiles? I'd rather have a program halt in production than have it silently fail, corrupting data or some other type of silent failure. And if you want to have the program keep running and log errors, that's simple exception handling/logging.

Re:No

[doom]

Can't imagine what you're talking about. By any reasonable standard, perl5 is doing okay, and in any case progress hardly stopped because of the perl6 project (rather there was an infusion of new blood in the core dev team). Perl6 was effectively developed in parallel with perl5 development.

And if perl5 doesn't seem like the only game in town any more, that has a lot more to do with a backlash from the CS snobs than the perl6 project.

Re:No

[PCM2]

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

Admittedly I haven't looked at the standard in a long time, but last I heard, all of this is platform dependent. As in, if you're programming C on multiple platforms and making the assumption that a char is the same size as an int, you could be in for a rude awakening at some point.

Re:No

[StikyPad]

C maps remarkably well to ASM, and with compiler hints and optimizations that don't exist in ASM, well-written C typically runs as fast -- and often faster than -- hand-written ASM. If there were any significant performance advantages to ASM, it would be used far more often in performance-critical applications, but there aren't, and it's not.

Re:No

[swillden]

I just corrected your assertion. Python *is* strongly typed.

RabidReindeer's assertion, not mine.

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

[swillden]

Are you asserting that it's OK if it compiles?

Obviously not. Did you read my post?

Re:No

[swillden]

Others who agree with you wrote mypy which is basically a lint-style checker for type.

Cool. I'll have to check that out.

However, I think my biases incline me in the opposite direction. Rather than dynamic typing with static type-linting, I prefer strong static typing with ubiquitous type inference. The code ends up looking much the same, I think, but I think the latter is always likely to be more thorough. Plus, it eliminates the need for most run-time typechecking. That's a minor to trivial issue in practice, but I hate systematically wasting cycles.

Re:No

[Wycliffe]

Perl 5 & 6 always appeared to me as the case study which lead Python to co-develop both 2.7 and 3.x simultaneously.

The case study as in they are doing the exact same thing as Perl? Perl is also co-developing 5 and 6 at the same time just like Python but, just like Python, they are having a hard time getting people to adopt the new version because the old version still works just fine.

Re:No

[h4ck7h3p14n37]

I have an x86 PC, but it is fairly specialized to doing tasks built around x86 legacy stuff.

Aren't modern day Intel x86's really RISC processors emulating the x86 instruction set?

Re:No

[Just Some Guy]

As a Python programmer, I use types and check them before it runs.

Re:No

[swillden]

Though I don't work in your field so I hesitate to offer an opinion, I think there would be really significant value in C++. If you haven't, you should take a look at the classic Barton & Nackman book on Scientific and Engineering C++. They use a bit of template magic to construct a system of types that essentially teaches the compiler to perform unit analysis. Multiply a mass times a distance and try to assign it to a force variable? Compiler will balk. Try to multiply matrices of incompatible dimensions, compiler will flag it. I don't know if it would solve actual problems, but its pretty cool.

Re:No

[Maury Markowitz]

> For data science, R is the future

OMG. I trained in physics and recently had to do a little physics again. I found the code I needed in R. It was completely indecipherable. R is basically the PERL of math languages - write-only gobblygook with lots of one-off syntax that does special things so that the original authors could save a couple of keystrokes.

Re:No

[Maury Markowitz]

> would have broken tens of millions of lines of code

PRODUCTION code no less.

Re:No

[goose-incarnated]

As a Python programmer, I use types and check them before it runs.

So, you perform a totally optional and currently experimental static analysis that may or may not cover most (or even some) of the code, and which doesn't affect the production of the program at all? You seriously think that that sort of thing is what we mean by "type-safety"?

Re:No

[Maury Markowitz]

> it is as slow as molasses in execution speed, and has terrible multithreading capability. So what

Well;

"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"

You've just pointed out two perfectly good reasons to use a compiler. The original post is a false dichotomy.

And considering the vast majority of compiles go through CLI tools, notably the entire Linux stack where you actually compile just about everything at least once, that last bit of the OP is just bigotry.

Re:No

[trg83]

The idea of adding such a significant feature in a non-major release is one of the reasons I shy away from Python. Their version management seems very out of sync with much of the rest of the software world.

Re:No

[andreasgonewild]

The unfortunate thing about mypy is that the whole idea breaks down in combination with Pythons imports since you now have to import every mentioned type to get the benefits, leading to circular imports in no time at all. As much as I hate writing header files, at least it beats trying to fix circular imports in Python. Java gets that part right from my perspective, as does Haskell; they don't give a damn who imports what when, leaving one problem less to solve.

Re:No

[MightyYar]

Ugh, that sounds awful. I think I'll just keep checking types in my code :)

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]

There is always code coverage and being sure you have 100% code coverage before shipping. But how likely is that? And if you do catch the bug there at the tail end of development, how expensive is it to fix?

Re:No

[Darinbob]

I would agree there. I like Python, but it's a pain to make something portable with it. v3 has nice features, but can't use them because v3 is not as commonly installed on all the computers where this is going to run. Most language designers and standards committees do manage to make things backwards compatible when there are newer version.

Re:No

[Darinbob]

That would have killed off all but the most die hard Python fans. 18 months is an amazingly short period of time for this. I mean that's only 3 password changes away! How to you get the entire world, everyone who uses Python, including those who don't even know who Guido is and aren't a part of the Python socia/compliance network, all switch over in 18 months? Including updating all tools everywhere that use Python or work with Python? It would be easier to fork the bitcoin block chain than this.

Re:No

[Darinbob]

Swift has a very tiny installed base, with few critical systems based upon it. Python has been growing steadily for two and a half decades! You don't just make a few phone calls and get the world to switch over like you can with Swift.

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.

Re:No

[beelsebob]

I mean, that is the definition of strong typing.

Javascript is weakly, dynamically typed, since it allows the wrong type to be passed all over the place, and does runtime conversion with some unpredictable results
Python is strongly, dynamically typed since it does not allow the wrong type to be passed around, but does that disallow step at runtime.
Objective-C is weakly, statically typed since the compiler is the only thing that does type verification, but messages can be sent to pretty much any object of any type you like.
Swift is strongly, statically typed since it does not allow the wrong type to be passed around, and does that disallow step at compile time.

Re:No

[Just Some Guy]

Given that I'd used Python for a couple of decades without experiencing significant type errors, I find that using optional, well supported and semi-official static analysis still has something nice to offer. But frankly, I feel like you're moving the goalposts. Python's had strong typing basically forever. It now has official support for typechecking. No, it's not identical to static compilation but it's a far cry from totally lacking type safety.

Re: No

[Maury Markowitz]

Atari BASIC had the ability to GOTO/GOSUB on a variable name, so you could GOSUB CLEARTHESCREEN, which helped somewhat. It also let you make arbitrary ON statements like GOTO 1000+(10*COUNTER). The downside was the locations were not cached, so branching performance was very poor.

Re:No

[serviscope_minor]

You don't have to loosen your definition of "janky" too much for basically all of C++ to fit.

Eh, if you say so. Sure C++ has warts, but personally I find modern C++ very pleasant to use. It's concise, easy to read, statically typed and parsimonious with resources. Pretty good combo.

Re:No

[RabidReindeer]

Please don't ascribe the virtues of an IDE to a language. There is a Python plugin for the Eclipse IDE (actually more than one, I think), though offhand, I cannot recall what, if any popup help you get.

Java does have the advantage that the language is designed to be auto-documented, and that information is easy to feed to an IDE. Python tends that way, but since it doesn't keep as tight a rein on things, I don't know how much IDE support is presently available.

Re:No

[RabidReindeer]

You could start a major flame war on the subject of C++ templating. It's a powerful tool, but it's very easy to cut yourself.

Actually, if you want really strong compile (and run) time checking, the winner is Ada. It not only rigorously enforces type conformance, it also asserts domain and range validation on everything. If I define a type in ADA named POSITIVE_INTEGER and give it a domain of 1..INFINITY, assigning a negative number or zero stops the whole game on the spot.

Re: No

[K. S. Kyosuke]

I'd say that binding variables to establish proper scopes is very important, but that just the Schemer inside me. Experience shows that in a decent language like Scheme, the class of bugs occasioned by the extant primitive type checkers in Pascal and similar languages (as opposed to, say, something similar to Idris et al.) and the class of bugs that are not caught by basic logical and coverage tests that you ought to have anyway have a very small, if any, intersection. (A cynic might say that Pascal prevents bugs by virtue of not allowing many desirable programs, so whenever you're forced to do the program in something else instead, it's a "I didn't cause a bug" point scored for Pascal. :))

Re: No

[K. S. Kyosuke]

Are you sure it wasn't two characters on the C64? Not that it's that much help, but you still only have 64 KB of memory for both code and data, so there's that.

Re:No

[david_thornley]

Don't forget the additional reserved words. "class" sounds like a good C variable name in a University class registration system.

Re:No

[swillden]

True. I tend to discount Ada because I've never actually seen it outside of an academic environment, but it definitely provides very powerful typechecking.

Re:No

[petermgreen]

True you can change the typing of a variable at every assignment

And more importantly you can pass any type to a parameter, store any type in a data structure and so-on.

True when you come to actually do some maths you will probably notice that what was supposed to be a number is not in fact a number. When you come to call a method you will probably notice that your value was not in fact an object of the correct type. You then have to spend ages working backwards to figure out how the value of the wrong type got stored in the data structure in the first place.

(still python is much better than certain other languages where passing a string where a number was expected or a number where a string was expected is likely to blunder on producing broken results)

Re:No

[brantondaveperson]

thus, like Java, can potentially run faster than static-compiled programs.

And yet, it never actually does.

Re:No

[brantondaveperson]

it becomes economical to statistically analyse the code and alter it based on workload

While that *might* be true in very specific use-cases, I'd wager that the overhead of monitoring the workload in order to properly inform some optimisation algorithm, would defeat any minor gains that the optimisation might have delivered.

The trouble with all these arguments around bench-marks, and theoretical performance gains of dynamically compiled languages, is that the advantages simply never show up in real life. Game engines are written in C++, almost exclusively, and those guys are on the cutting edge when it comes to performance. Why are they not using Java?

Re:No

[brantondaveperson]

It matters very little today.

Actually, the opposite is true. Today, nearly a majority of computing tasks are carried out on battery powered devices. Performance gains of even a few percent directly translate to battery life, and since computers aren't really getting any faster anymore, we need people to look harder at performance. The choice of using java (ok, Dalvik, or whatever google decided to call their stolen version of java) on a mobile device is exactly why we need quad-core monster devices with massive batteries. If they'd done the work to design an API in a fast language, like C++ or something, the global energy savings would not be insignificant. They would have been a couple of years, at least, later to market - and that might have killed the entire project - but the fact remains.

Car analogy: Energy is expensive. Build efficient vehicles.

Re: No

[brantondaveperson]

Well, they add new keywords from time to time, which can break existing code. But it's pretty rare, and nothing a search-and-replace can't fix.

Re:No

[djinn6]

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

Since this thread talks about Python 2 and 3, I'd say the similarities are enough that just running the 2to3 tool would get you working Python 3 code. The real difference from C/C++ is the Python interpreter's inability to run both Python 2 and 3 code at the same time, where as your C++ library can be linked with a C library and produce a complete binary.

Re:No

[Pseudonym]

C maps remarkably well to ASM [...]

It maps well to 1975-era ISAs. Modern ISAs... not so much.

Re:No

[Pseudonym]

Haha, comment is a user story.

Re:No

[Pseudonym]

I don't know if there ever was a time in history when one programming language was dominant. If there was, those days are long gone.

Current practice is that almost all nontrivial software projects are multi-language. This trend will grow for the forseeable future.

Re:No

[Pseudonym]

Python has completely stepped on it's own dick by making v3 scripts incompatible with v2.

I remember when they said that of the libc5 vs libc6 changeover. Then it was C++9x vs C++1x (which thanks to certain LTS Linux distributions still isn't entirely behind us).

Python had to make a clean break because it was impossible to JIT-compile Python v2 into efficient code due to its broken variable semantics. The problem was that Python v2 was a victim of its own undeserved success, so the migration to v3 was painful and expensive.

Haskell has the right attitude: "Avoid success at all costs."

Re:No

[Pseudonym]

In order to make the comparison fair, you should limit your examples to other popular programming languages that made a successful breaking change, since invalidating large, established codebases of user code is precisely what makes such a change so expensive.

C++11

Re:No

[Pseudonym]

Not that sure --- R is such a clusterfuck that someone managed to write a succesful 150-page book about the different ways in which you can shoot yourself in the foot with it.

R is a terrible language with great libraries. I would heartily recommend R for any statistics job. Just don't try to write any programs in it.

Re:No

[Pseudonym]

Making white space significant is python's biggest flaw.

I see this claim a lot, but I don't buy it at all. There are lots of languages with significant whitespace (e.g. Haskell, makefiles) that nobody complains about (for that reason).

Anyone who claims that significant whitespace is Python's biggest flaw has obviously never tried to use Python on a big project. Lexical syntax is easily the least flawed thing about Python.

Re: No

[Darinbob]

I used SML for awhile, which is a strongly typed language with dynamic typing. Ie, you do not need to declare types but you will still get warnings and errors at runtime that your types are wrong. This was very baffling to me at first until I started to catch on to what was happening.

Re: No

[DrXym]

Just search any C or C++ specification and "breaking changes" and you will find breaking changes. C and C++ might be at the conservative end of the scale but even they manage to break stuff and occasionally deprecate things. In addition, while it might be nice that C/C++ doesn't change as much as Swift, it also means the language accumulates a lot of crap, some of which is horribly unsafe.

So conservatism in one way actually makes the language more dangerous and crufty in another.

Re: No

[K. S. Kyosuke]

Correction: you don't need to write tests for trivial things; more complicated functional, coverage and performance tests will already exercise the trivial cases. So you only write pointy tests, not pointless ones.

Re: No

[K. S. Kyosuke]

There's delimited continuations.

Re:No

[RabidReindeer]

thus, like Java, can potentially run faster than static-compiled programs.

And yet, it never actually does.

Because you "know" it can't.

Some of us have seen actual numbers and benchmark code.

I optimize for a living and one of the first things you learn when you go to boost performance is to get hard measurements and to never, ever optimize prematurely.

Because the bottleneck is almost never where you "know" it's supposed to be.

Re:No

[RabidReindeer]

You have the right intuition, but intuition is dangerous. It's true. For really, really short one-shot code segments, the overhead of launching a Java VM is ferociously expensive, much less running monitor functions. Might as well crack walnuts with a hydraulic press.

However, as you scale up, the overhead remains more or less fixed and becomes less and less of a percentage of the overall workload. If your optimization mechanisms are any good, you eventually reach a tipover point where the overhead more than pays for itself. The benefits mostly show up in long-running and frequently-executed processes which are usually what you find in servers and the bulk of the JVM optimization functions are geared towards that environment.

I'm not in the gaming industry, but I would be cautious about a flat assertion that all games are written in C++. At least at one time, I think that there were some gaming-specific programming languages and some development environments that were designed specifically for game functions and have had years to get tuned even without machine assistance. Moreover, I think it unlikely that games are going to see a lot of shifting workloads - although that's more of a "know" thing than a measured fact - and repeated dynamic recompilation isn't necessary or useful in such cases.

I do know of one game that definitely is written in Java: Minecraft for the Raspberry Pi. The Pi is not a powerful computer by modern standards, so running Java, much less a computer game in Java on it is no small accomplishment. I've worked with mainframes that couldn't host a JVM. OK, they were really old mainframes, but still....

The conceit from the knee-biter crowd that Java is slow needs to die. I've worked with video editors, complex GUI design apps and IDEs (both Eclipse and the Arduino IDEs are Java apps) and never felt the difference between Java-based products and products written in other languages. I'm not saying that Java is the solution for all problems.

I'm not into one-size-fits-all. Leave that to the religious and political crazies. I use Java, Python, assembly language, even Fortran and COBOL, LISP, Perl and more, depending on what works best for the problem at hand. I'll happily defend any of them, and I hope I'd be just as happy to admit their respective flaws. Because if you cannot admit flaws as well as strengths, you're an ideologue and an ideologue is just an idiot with an agenda.

Re:No

[goose-incarnated]

Given that I'd used Python for a couple of decades without experiencing significant type errors, I find that using optional, well supported and semi-official static analysis still has something nice to offer.

"Semi-official" is still not "official". It's hardly well-supported if the maintainers call it experimental?

But frankly, I feel like you're moving the goalposts.

I did not. I did not say "Python does not have strong typing", I said that Python type errors are only determined at runtime, which they are. You are trying to make this into a "python has strong typing/python has weak typing" argument when it isn't.

The argument is "Type Errors Are Useful Before Runtime". I'm not going to argue about whether Python has strong typing or weak typing because it doesn't matter. The type error only happens at runtime, hence the typing that python has is about as useful as a chocolate hammer.

Re:No

[Marxist Hacker 42]

And yet, amazing amounts of spaghetti code come from both.

Re:No

[Shirley Marquez]

Perl is also capable of being used as far more than a scripting tool. Some of us do use it for real programming. It just never caught on for that in the same way that Python has, perhaps because of its reputation for being unreadable. (Just about any computer language can be used to write code that is hard for humans to read, but Perl offers a particularly rich wealth of ways to do that. It's also possible to use Perl to write beautiful and expressive code.)

Re:No

[Marxist Hacker 42]

Eclipse seems to me to be an IDE written by hackers for hackers and unsuitable for anything other than hacking.

Re:No

[Marxist Hacker 42]

That has much more to do with the programmer than the language, in my experience

Re:No

[mysticgoat]

Perl is the only programming language that supports writing poetry that will compile properly: Black Perl. Also google on the Annual Perl Poetry Contest.

A good way to judge the quality of an applicant for a programming job is to give him some discrete task from your company's problem space and half a day to develop a perl script solution. Then have a couple of your better programmers evaluate his work--- not on whether he finished the task, but on whether they would be comfortable picking up the work where the candidate left off.

Perl gets dismissed because so much garbage has been written in it. But the reason why so much garbage has been written in Perl is because that's the best that Joey ---you know Joey, that kid in the mailroom who has been learning to program computers--- could produce. And that POS actually works so here it is 20 years later and we are still using it.

And Joey? He left the mailroom job after a couple of years and now he's some kind of High Mucky-Muck in IT at Corporate HQ.

Don't judge a computer language's goodness by the amount of garbage that has been written in it. Any decent language will allow an idjit to write bad code.

Do judge how limited a language might be by the number and type of arbitrary rules a programmer must deal with. No programmer should have to be concerned with meeting some arbitrary whitespace convention, not while he is actually working on the code. He, or better yet some apprentice programmer, should make the code look pretty after the problems are solved. "While coding, just code."

Oh, fsck Python. There are more important things to think about than levels of indentation.

Re: No

[mysticgoat]

A lot of that time was spent waiting for stuff to be developed. FOSS is usually faster and always produces a less buggy product than commercial software houses can do. But Windows had a 25 year head start, and it took roughly five years for Ubuntu, et al, to catch up and take the lead.

Now if you want to do anything useful on the web you will be relying on Linux products like Apache, and if you want to be addressing the universe of desktop computing, you will need to do it with a Linux box that can be kept up to date with the latest advances in FOSS. Torvalds once said that Linux is not out to destroy Microsoft; that will happen as an unintended side effect. And that's what's happening.

Re:No

[silentcoder]

The MeerKAT and SKA radio satelite projects do all their work in python.
According to a talk I attended by their chief programmer - there is a very simple reason. They did the math - even though C-code would run faster, the time they save on developing new code and bugfixing old code is so big that - to get the results on parsing some multi-terrabyte dataset is actually FASTER in python than in C !

Because contrary to your claims - python is fantastic at rapidly developing extremely stable code.

Re:No

[silentcoder]

A good python library will take ALL of them - and handle it correctly depending on the type it received. A good python function should accept ANY compatible data in any compatible type - and know how to deal with different types it may encounter.

Some tasks only ever make sense on a list - so only implement list code.

But if the task could, also, in a sensible way be done on a dict - then you damn well implement support for a dict and ensure your code checks which type it is and uses the right iterator.

Good python devs never let the user of a library try to guess what the library accepts - they tries to cater for whatever the users needs.
Consider this class I wrote:
https://github.com/ajventer/py...

Notice how it will work correctly regardless of whether the input is a list, an arbitrary sequence of parameters or even an arbitrary string - it will parse the data, and construct it into a generic format for use in internal calculations, and fail cleanly if the provided data cannot logically be parsed into an understandable sequence.

That's how python is supposed to do it. As long as the data is compatible with the processing function, all compatible types should be accepted.

Re:No

[swillden]

I don't buy it. Well, sure, I buy the comparison with C, but not with (modern) C++ or Java.

Re:No

[slashdotwannabe]

Please burn your computer and forget you ever thought you knew anything about programming. People like you are why we can't have nice things.

"computers we have these days" = -1020451

"overwhelming amount of computing tasks" = -9.1093822E+14

"well within reason" = "OMG shoot you now"

"C++ or any other fast and obtuse language." = "OMG shoot ME now"

Re: No

[squiggleslash]

Possibly, but DEF FN was kinda useless, you were limited to a single expression, rather than an algorithm.

Re:No

[silentcoder]

Yeah, those astrophycisist types, the best in the world at looking at stars, but we all know they suck at adding up numbers right ?

Re:No

[swillden]

Yeah, those astrophycisist types, the best in the world at looking at stars, but we all know they suck at adding up numbers right ?

Apparently I wasn't clear. It was the comparison with C, which is very weakly typed and absolutely worse than Python for building complex systems, that I was criticizing, not the astrophysicists. They were comparing C vs Python on the basis of performance, and I'm sure that Python is a better choice than C for them, for exactly the reason they state: the performance gained by using the weakly-typed C language would be far more than offset by the stronger type safety and higher abstraction level provided by Python.

If they were comparing Python to Java or C++, and if their problem were complex enough to require many millions of lines of code, then I'd say they were wrong. But they weren't, it isn't, and they aren't.

That said, at various points in my career I've worked with brilliant physicists, and they're generally not terribly good at writing software. Not that their code doesn't work, but it lacks the discipline needed in large, complex systems. That's okay, though, because they don't generally try to build and maintain large, complex systems. Scientific and engineering software work, though very sophisticated in many respects, generally focuses on relatively small problems. There are exceptions, of course, but in those cases the teams generally hire some software engineers to free the physicists up to focus on physics.

Re:No

[silentcoder]

Well I have had some dealings with them (and the university that supplies many of their staff) over the years, and they don't generally let phycisists write code. They have a dedicated coding team - who works very closely with the other teams to translate requirements into code.
The analysis software tend to be once-offs and not hugely complex pieces of software (many, of course, are minor modifications of previous ones)

The big and complex part is the code to keep all those hundreds of dishes synchronised. Interferometery relies on perfect synchronicity between all your recievers (be they dishes or lenses). The maths to combine their data is easy - the maths to ensure every one of the dishes point at the same thing, at the right angles relative to each other, and communicates with the servos that actually move the things, that's the really cool stuff they write - and this is still early days. When SKA is complete - it will be several thousand dishes being kept in synch with each other.

Re:No

[brantondaveperson]

Well, that's a very good point. The first rule of optimisation is that you'll always get a surprise.

However, in many cases performance has to be designed into a system, which isn't quite the same thing as 'premature optimisation', but it's a case of choosing algorithms sensibly etc.

But, back to the point, please show me the real-world java program that outperforms the equivalent real-world C++ program.... Because I design and write high-performance software for constrained environments for a living, and we would never use Java in a million years. But, if it could outperform the C++ that we do write, well, that would make me think again.

Re:No

[Bengie]

100% code coverage is considered a code smell. Almost always means you've forced it and probably aren't doing proper testing. The masters tell the laymen to strive for 100%, but they also face-palm when they see it actually "accomplished."

Re:No

[Bengie]

Yay, crashing at run time for something that could have been trivially tested for at compile time.

Re:No

[shutdown -p now]

Except that the trend is the other way around - Python is growing faster in the data science niche than R.

As for Python 2 vs 3, regardless of how the transition was handled, it is over now. Everything that matters is on Python 3. At best you could argue that it was a temporary setback, which delayed Python domination.

Re: No

[shutdown -p now]

Later BASICs added full structured programming. The problem is that the core of the language was still designed before then, and it showed. For example, because drawing primitives like LINE and CIRCLE were there long before user-defined procedures and functions, they remained statements with special syntax that was different from function invocation.

Re: No

[shutdown -p now]

Traditional BASIC (of the era when it was dominant) was not dynamically typed.

Re:No

[shutdown -p now]

Have you tried using a modern Python IDE? They normally do some form of type inference to do exactly the kinds of things that you're asking for, and they're pretty good at it.

Re:No

[swillden]

You think C is weakly typed..? o_O

Yes. It could be strongly typed if it weren't so trivial to completely subvert the type system -- in many cases accidentally. Worse, C almost requires programmers to regularly subvert the type system. C++ technically has the same problems, but C++ written in a modern style that eschews all old-style casts and takes advantage of template metaprogramming to build very precise custom type semantics can easily avoid all of those issues.

Re:No

[RabidReindeer]

Sigh. Make me work for a living.

It's always best to do one's own research, as it helps to avoid being fed cherry-picked reality. But, if you insist, here's some stuff I cherry-picked from Google.

The first one is very interesting because it dates all the way back to 1998, when JIT Java was fairly new, but the relative timings are quite comparable, given similar constraints:

http://www.javaworld.com/artic...

Much more recently:

https://benchmarksgame.alioth....

Your Mileage can Definitely Vary, however. I found benchmarks indicating that the "Java" (Don't call it Java or Oracle's lawyers will swarm you - it's Dalvik) on Android is significantly slower.

Some of my own impressions of relative performance are dated, I think. The Gnu compilers have added some very aggressive optimizations in recent years.

The Debian benchmark seems to indicate that raw C (gcc) is on average about twice as fast as either Java or C++. My suspicion is that a lot of modern C++ coding is not only using virtual methods, but taking advantage of string and dynamic memory managers that were not part of the original C++. There is a cost for using pre-packaged solutions, but in an era where machine time is cheap but programmers still cost $10K a year even in India, shops generally favor "Git 'R Dun" over hyper-optimal performance.

I've always been partial to the definition (I think by Alan Kay) that Java is "C++ without the mace and knives". I find Java to be less stressful because I don't obsess about what raw machine code will be produced, and the rigorous compile-time checking means that I can devote more time to worrying about the high-level design. However, a JVM is a greedy thing, so there are still times when I prefer C or C++. Then again, there are times when I prefer Python, Perl, or PHP.

In the end, it's less about language and more about intelligent design. I once encounted a perfectly horrible C++ program that used a very sparse array with a widely-distributed working set. Virtually every computation triggered a page fault; I've seen cases where "efficient" sorts and searches were totally unsuitable because the data was in worst-case form. For performance, the choice of language is less important than how it's used. And above all, measure instead of simply "knowing".

The reason why I take such umbrage against the "common knowledge" that Java is slow is because that knowledge is largely based on old-time interpreter implementations, where on average, an interpreted instruction would take about 10 times longer than its native-code equivalent because a lot of the code being executed wasn't the app, it was the interpreter. JIT-compiled code has no interpreter overhead, so it's primarily limited by the optimization capabilities of the JIT compiler and the tuning settings (small code, slow code vs. fat code, fast code, for example). For lightweight apps, the overhead of launching a JVM, to say nothing of the overhead of doing the JIT compiling is obviously not worth it. For something that launches, runs 24x7 and doesn't restart for weeks at a time, those considerations are fairly trivial - assuming there's enough RAM. If you have dynamic load-balanced re-compiling, then the overall performance is likely to be better than for a static-compiled app.

But juggling instructions tends to only give you about an extra 10% boost, and on the whole, I prefer enough headroom for that not to matter. What makes or breaks most systems is the app itself. I knew of one where a single switch setting could single-handedly bring an IBM mainframe to its knees if set improperly. No compiler in the world could have helped that.

Re: No

[smithmc]

Aw, 26 functions oughta be enough for anybody. -- Bill Gates

Re:No

[LifesABeach]

Actually I didn't, it ranks as #4. FORTRAN's Format statement is were bottle necking occurs, hence position #4.

Re:No

[michael_wojcik]

Really hoping /. runs a story with the headline "Is Betteridge's Law Reliable?".

Or for that matter, "Are Posts that Just Cite Betteridge's Law Worth Making?".

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:

[K. S. Kyosuke]

That's true, but the more applicable your language is to different problems, the less likely is it that in a large compound program, you'll run into needing a nasty inter-op between two parts of your program. Although having a nice FFI is still a must, of course.

Re:Betteridge says:

[dreamchaser]

Pretty much everything on /. is clickbait and/or slashvertising since the acquisition.

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:

[ls671]

I agree with you but anyway; nobody should ever need more than 640K programming languages.

Re: Betteridge says:

[GNious]

Studying CS, one group went to an exam on a paper about how .NET is a programming language and never mentioned C#.

They passed, and when asked about it, the teachers said there was no difference.

Re:Betteridge says:

[Rockoon]

To.... rule them all?

Thats called LISP.

Unfortunately every time it would be a benefit to use LISP, there just never seems to be a compiler behind it (see Nyquist, built on XLISP, built on a LISP interpreter)

Re: Betteridge says:

[K. S. Kyosuke]

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

Re:Betteridge says:

[fustakrakich]

since the acquisition.

Which one?

Re: Betteridge says:

[110010001000]

Surely you mean LISP, not Lisp.

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:

[drinkypoo]

They passed, and when asked about it, the teachers said there was no difference.

I had an IT boss once who thought Centrino was a family of CPUs, and not a marketing name for bundling a Pentium processor together with Intel wireless. He did get let go eventually...

Re: Betteridge says:

[Xest]

C# isn't the only .NET language though, so why assume when talking about .NET that they have to mention C#? It could've just as well have been any .NET language implementation.

Are you sure they weren't referring to .NET IL? It's possible that it's you or the students that didn't actually understand the question here.

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:

[oh_my_080980980]

Only if you are moron who doesn't know what those languages are used for...

Re:Betteridge says:

[fnj]

the dominate language

The word is "dominant". "Dominate" is a verb. "Dominant" is the adjective.

Re:Betteridge says:

[fnj]

Why would we want just one programming language?

Nobody with any sense believes we should, but the present proliferation of a bewildering Babel of way too much programming language proliferation is not the ideal either. After one or two programming languages, to a small handful at the most, it becomes impossible to comprehend them, let alone master them.

Re: Betteridge says:

[GNious]

No, they were talking about programming in the .NET language, it's structure, how to define classes, methods etc ...

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:

[K. S. Kyosuke]

Well, in their defense, they were somewhat (but most likely unintentionally) correct in the sense that the .NET CLI defines a language of sorts in terms of requirements and limitations. Someone once described the "common runtime" features of .NET jocularly as "you can run any language as long as it can be easily transformed into C#".

Re: Betteridge says:

[ranton]

No, they were talking about programming in the .NET language, it's structure, how to define classes, methods etc ...

That sounds a bit nit-picky to me. In my workplace we generally refer to our VB / C# programmers as our .Net group. When in architectural discussions we will say something like "this should be written in .Net" frequently. I probably refer to C# as "the .Net language" more often than I refer to it as C#.

I find it more useful to discuss languages as part of a technology stack which is why I generally refer to the C# language as .Net most of the time. If I am specifically talking about differences between VB and C# I will call that out but otherwise I am just talking about the technology stack as a whole.

Re: Betteridge says:

[Xest]

I think this used to work well, but there's been a divergence in recent years, such that the languages are evolving very much separately to the framework. It used to be that a new .NET version would typically come out with a new C# feature, but now the C# language versions and hence features are evolving very much separately from the framework, and in fact, we even have multiple frameworks with .NET Core and so forth.

As such it's becoming a little more dangerous to link the two I tend to feel, and ever more important to make sure we talk about the language and the framework separately and explicitly.

Re: Betteridge says:

[TechyImmigrant]

Surely you mean LISP, not Lisp.

Yeth,

Re:Betteridge says:

[angel'o'sphere]

To learn more how computers actually work? To learn more how YOU mind actually works? To learn more about how to tackle a problem from different points of view?

If you can not do at least one command line shell, one compiled language, some variation od SQL/OQL/HQL and at least one language that follws or emphasizes a differen paradigm than your main language you are like a musician who can only play one instrument.

Re: Betteridge says:

[zifn4b]

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

Is the issue that it's not a compile time language? If that's what you require for sanity then yes, you should retire to maintain your sanity. You see NodeJS is to Chromium as Java is to JVM as C# is to .NET runtime. In fact, you could lump PHP in there too. If you're not keen on compile time languages decreasing in popularity, you should have retired a long time ago I hate to say. It's just the trend that the industry followed, friend.

Re: Betteridge says:

[zifn4b]

Studying CS, one group went to an exam on a paper about how .NET is a programming language and never mentioned C#.

They passed, and when asked about it, the teachers said there was no difference.

.NET is a technology stack. The .NET Runtime is the "virtual machine" that all MSIL runs on. There are many .NET languages, C#, F#, VB.Net, even Python. Each language compiles down into MSIL (byte code) similar to Java. The .NET Runtime then compiles the byte code down into machine language based on the CPU architecture. Teachers who don't have a basic understanding of this have no business teaching students about it. It's not particularly hard to learn about. One only need pick up the Jeffrey Richter book. It's a pretty quick read and you will be very educated about what goes on under the hood afterwards.

Re: Betteridge says:

[zifn4b]

Well, in their defense, they were somewhat (but most likely unintentionally) correct in the sense that the .NET CLI defines a language of sorts in terms of requirements and limitations.

Sorry, that position is not defend-able. The only way that statement could be considered partially true is if they were referring to writing MSIL, which you most certainly could do, however I'm nearly certain that's not what they meant. They're just an unqualified instructor in that subject matter and are making themselves look incredibly dumb by attempting to teach subject matter they are obviously not educated about.

Re: Betteridge says:

[zifn4b]

That sounds a bit nit-picky to me. In my workplace we generally refer to our VB / C# programmers as our .Net group.

No that's not nit-picky. I would be common to see two different platform teams in a company like the .NET team and the Java team. I think what you're getting hung up on is Java is used to refer to both the platform (JVM) and the language. They are often used interchangeably but they are not the same thing. For example, in your example, you might find a Scala programmer on the Java team. Why? Because it's a JVM language.

Re: Betteridge says:

[ranton]

I think what you're getting hung up on is Java is used to refer to both the platform (JVM) and the language. They are often used interchangeably but they are not the same thing. For example, in your example, you might find a Scala programmer on the Java team. Why? Because it's a JVM language.

Considering we don't have a Java team, or anything on the JVM platform, I don't think I'm getting hung up on that. I do agree though that we would refer to a JVM team in the same way we refer to a .Net team. But that has more to do with the fact the .Net platform is not significantly used outside of C# and VB (and even VB use is marginal). That is not the case with JVM.

Re: Betteridge says:

[K. S. Kyosuke]

That's why added "unintentionally".

Re:Betteridge says:

[doom]

angel'o'sphere wrote:

To learn more how computers actually work? To learn more how YOU mind actually works?

Yup. All us programmers are acutely aware of the need to understand cognitive science. That's why langauage wars are a thing of the past: we just wait for the social scientists to verify the claims (faster dev, lower maintenance, etc), and go with what they say.

... at least one language that follws or emphasizes a differen paradigm than your main language you are like a musician who can only play one instrument.

But what about a mind that can only recite a single slogan?

(John Coltrane totally sucked: he never played anything but sax.)

Re:Betteridge says:

[angel'o'sphere]

First of all: I did not say staying to your roots sucks.
Secondly, Coldtrain played other instrunentfs before he settled on sax.
Thirdly, there is nothing wrong to seek insight or depth in what you do best. After all he studied enough other instruments/playin gstyles to be later recognized as the inventor of "sheets of sounds".

Re: Betteridge says:

[trg83]

Third party here...no, I think the issue is that NodeJS is REALLY NOT a language, but is rather a framework and approach for writing JavaScript.

Re: Betteridge says:

[zifn4b]

Third party here...no, I think the issue is that NodeJS is REALLY NOT a language, but is rather a framework and approach for writing JavaScript.

Actually, you raise an interesting point. Node.js really does muddy the water but that doesn't make it illegitimate. I'm not exactly sure what Node.js the term specifically refers to in their stack. Chrome V8 Javascript engine and Javascript are two distinct entities. JavaScript as you pointed out is a language. Said language is interpreted, meaning it requires a runtime. Chrome uses the V8 Javascript engine. Node.js also uses that. JavaScript is interpreted by other technology in Firefox, Safari and IE/Edge. Node.js I suppose you could say hosts the V8 Javascript engine and glues it together to make it work from a console application. Where one ends and the other begins would require some further investigation. But what's the point? Do I really need to understand that to spin up a REST service? No.

FWIW, I'm an old gray hair programmer too. I started on the Vic 20 and shortly after the C64. Just because Node.js is different doesn't mean it isn't a real programming stack. In fact it is part of what is referred to as the MEAN stack. Whether you want to admit it or not, a lot of today's mobile apps are written in this fashion minus Angular/ReactJS/Ember/etc. sometimes for a more thick client experience. Ever piece of software has a different set of needs and you must select the right tools for the job to get to market quickly and effectively.

Also, to criticize MEAN would be to criticize LAMP. There are many long-lived commercial web applications running on that stack too. I just get the sense that the naysayers here are people that are pining for the days of assembly language or C/C++ programming. Look, don't get me wrong, those compile time languages have their applications, for example gaming. I spent quite a few years programming in them. C++11 has made strides to adopt functional language programming semantics to be more like a modern language but these types of languages are not meant for spinning up web or mobile apps. They're just not. Hell, Microsoft didn't have a way to spin up a web application in C++ until Cassandra and that was only a few years ago. I think it's now called the CPP Rest SDK. Very late to the game. About 10 years ago, I worked at a company that was bought by another company. The buying company had decided to invent their own HTTP server in C. They absolutely could not keep up with Apache and IIS and were always running into problems and eventually scrapped it in favor of industry standard tools.

People who suffer from NIHS always lose. Hey I've re-invented a few wheels in my days too. Even though it's a lot of fun, I can objectively say it's pointless especially today if someone has already done it perfectly well. Don't be an elitist douche.

Re: Betteridge says:

[trg83]

Elitist douche? I was just trying to correct misinformation as someone who has coded JavaScript inside and outside of the Node stack. Roughly, Node is to JavaScript as Ruby on Rails is to Ruby.

I think you have somehow misinterpreted my pedantry on terminology as a bone to pick with the JavaScript community. Not so.

Re:Betteridge says:

[brantondaveperson]

many of the advantages of the older language are becoming moot.

Except that inefficient software in datacentres directly translates into your power bill.

Re: Betteridge says:

[zifn4b]

Elitist douche? I was just trying to correct misinformation as someone who has coded JavaScript inside and outside of the Node stack. Roughly, Node is to JavaScript as Ruby on Rails is to Ruby.

I think you have somehow misinterpreted my pedantry on terminology as a bone to pick with the JavaScript community. Not so.

Being a pedant for the sake of being a pedant is the definition of an elitist douche. But carry on. I don't care.

Re: Betteridge says:

[Marxist Hacker 42]

I've never seen a bigger pile of spaghetti code than NodeJS- and that's coming from somebody who remembers inserting three NOPs every other instruction to facilitate JMPS insertions just in case I needed to spaghettifi something.

Re: Betteridge says:

[Marxist Hacker 42]

The issue is that it encourages large and complex client-side processing combined with really bad programming practices that are hard to debug and maintain.

Re:Betteridge says:

[Marxist Hacker 42]

I wish Cmdr Taco would come back and write a series of memoirs on "How to sell your hobby website and retire"

Re: Betteridge says:

[michael_wojcik]

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

"all-level"? What the holy fuck is that supposed to mean?

I suspect you have no idea how COBOL has developed since the 1985 standard, but your vague handwaving is incomprehensible, so I can't be sure.

This is one of the many problems with programming-language wars, of course: not only do most participants lack a good argument, they're not even capable of articulating their poor arguments.

Re: Betteridge says:

[michael_wojcik]

Oh, look. A child who thinks history is irrelevant.

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

[fennec]

No.

Can you just stop?

No.

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

Re: Betteridge's law of headlines

[doom]

You libertarians need to wake up and look at the way the world actually works.

The Democratic Party needs to understand the lessons of the British elections.

The Boston Redsox are going to screw-up again this year.

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

[fph il quozientatore]

Curious that you are writing this on a website where replies to a comment are identified only because of indentation, and no one has ever complained about that.

Re:No, because meaningful whitespace

[Anonymous Coward]

Except that any sane programmer already indents their code by exactly the same rules in addition to wrangling with braces...

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

[superwiz]

Braces didn't win over whitespace because of C's readability. They won over because C won over and then Java used em so not to confuse all the struggling C++ programmers. If you can't handle a slight change in how scoping is expressed, you have no business having an opinion on which programming language to use. You'll do what you are told.

Re: No, because meaningful whitespace

[K. S. Kyosuke]

("about *your* lack of diversity", sorry.)

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

[SuperKendall]

Say, what are those odd symbols at the end of every one of your sentances...

Huh. Seems like some kind of visible symbology to separate concepts is useful after all.

Re:No, because meaningful whitespace

[sjames]

absolutelycorrect.Idon'tknowwhattheyp[osablycouldhavebeenthinking.Weneedtoeliminatealluseofwhitespaceimmediately.

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

[vtcodger]

"Whitespace which has meaning is just nasty"

So, unfortunately, are zillions of easily mismatched, hard to read, bracket pairs. Whitespace is widely (nearly universally one hopes) used to make code readable because bracketing is only readable by machines and perhaps a very few, very odd, people. Python simply makes readable use of whitespace mandatory and throws out a lot of the bracket pairing.

It's a tradeoff

That said, Python has some other problems -- speed, threading, and a number of niche issues that occasionally rise up to bite one. But as a first computer language or an only language for folks who make their living doing something other than programming, there's a lot to bet said for Python.

And it's not like everyone else's favorite languages don't suck in a few (often more than a few) ways.

Re:No, because meaningful whitespace

[religionofpeas]

Whitespace between keywords is fine. C requires that too. We're talking about using white space to define program structure.

Re:No, because meaningful whitespace

[Anonymous Coward]

Using whitespace and tabs for flow control...how fucking sloppy can a language get?
Python is the shittiest programming langauge in the world.

Re:No, because meaningful whitespace

[thp4]

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.

If you have wrongly-balanced curly-brace code (or missing curly braces since you expect it to be only one statement), it's just as likely to fail compiling or do something you didn't expect (think Apple SSL "goto fail"). Space-/indentation-based block definitions and curly braces are as powerful, any proper editor will help you indent your code. The advantage of indentation-based blocks IMHO is that it results in some consistency (no "holy wars" where to place the opening/closing brace and if/when to leave out braches, etc..) and easier readability. In practice, "a stray tab instead of spaces" is a non-issue, Python will fail loudly and you fix your editor settings, done.

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.

Most of my coding time isn't spent copy'n'paste-ing code from the web. Readability matters more, since most time is spent reading code. Adapting the code from the web to your own environment by having go to through it might very well be a good thing. If you copy'n'paste C/C++/JavaScript/Java code from the web, you also want to fix the indentation of the pasted code since it's probably in a different style than what current project you're working on.

Re:No, because meaningful whitespace

[sjames]

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;}

Re:No, because meaningful whitespace

[dinfinity]

where replies to a comment are identified only because of indentation

No, they're not. They are 2-dimensionally visually nested by borders and include a link to scroll to the parent post.
Try disabling the border on #commentlisting li.comment.full, #comments .full

no one has ever complained about that

Beta made it worse and everybody complained about that. And rightfully so.

Re:No, because meaningful whitespace

[fph il quozientatore]

Oh, I refer to the old interface (which I am still using). That had no visual markers apart from the indentation. So basically they added visual markers in addition to the indentation, and everyone complained.

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

[Ihlosi]

If you have programmers working illegible code

Should be 'writing illegible code'.

Re:No, because meaningful whitespace

[Rockoon]

So basically they added visual markers in addition to the indentation, and everyone complained.

Because its still not good enough.

Re:No, because meaningful whitespace

[Rockoon]

Sane programmers have even more rules for indenting than python.

Unfortunately Python has decided that being a sane programmer is not compatible with its indentation rule, which is the only rule allowed in the Python world.

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

[religionofpeas]

Good example. After fixing the #include, that code can be compiled. For generated code, that could be an acceptable way to format it. For human readability, I can run it through a pretty-printer with my favourite settings. I can copy/paste it into any other project, and it would still work.

Now try pasting a piece of python code, and see if the whitespace survives the HTML formatting.

Re:No, because meaningful whitespace

[BenJeremy]

Mismatched braces are not all that hard to sort out. Easier than Python's scheme, much easier.

Modern code editors even display matching braces, and some provide more extensive visual indicators.

As already mentioned, copy-pasting code is also terrible for Python, simplicity for C/C++/Java/C#. Copy-pasting as the old joke goes, 90% of the job (With Experts Exchange long before StackOverflow came along)

Re:No, because meaningful whitespace

[religionofpeas]

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

You could have an editor compare indentation with bracket pairing, and notify you of a discrepancy. That way you can verify both.

Re:No, because meaningful whitespace

[bill_mcgonigle]

Is there no standard python module to fix this? I mean, just preprocess and feed the stupid space stuff to the tokenizer.

Perl has all kinds of alternate formatting modules, but its users tend to he less devotional from what I've seen.

Re: No, because meaningful whitespace

[DrXym]

Braces won over other forms enclosure like begin / end because they're terse and easy to parse. Other languages contemporaneous with C would been far more verbose. From a convenience standpoint it's easy to see why braces won. That said, C really screwed up by making them optional for single statement blocks.

Python uses indentation for blocks which in theory is is even more terse than putting braces around blocks. On the flipside it imposes a coding style and line continuation over multiple lines is a really ugly hack.

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]

I used to prefer tabs for indentation for that very reason (setting my own width) but I eventually gave up the fight and went with four spaces. It seems fairly common.

Re:No, because meaningful whitespace

[mfearby]

Of all the bizarro made-up crazy languages out there, this has to be one of the silliest :-)

Re:No, because meaningful whitespace

[Anonymous Coward]

It is however a problem if you have much communication between processes. Per default the multiprocessing module will pickle/unpickle the transmitter information. And this is catastrophic for performance. It is possible to send e.g. arrays without pickling them but you have to jump through some hoops to do it.

We are currently considering using mpi4py instead sinde it has support for transmitting objects implementing the buffer interface without any pickling. And because we like the MPI data model and the mpi4py implementation. And it allows us to run stuff on our cluster out of the box.

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

[Sneeka2]

I would say that Python enforcing the one true standard is actually a good thing. I don't need to waste brain cycles on deciding how to indent most things; the interpreter forces me to stick to certain basic constraints. My editor automatically runs a PEP8 style checker on it and enforces the rest where there's wiggle room. No more holy wars to fight in this area (well, except for arguing on /. about why that's a good thing...).

I find it easier to get used to the default, which is very sane in the case of Python, than to bend the language to my personal whims.

Re:No, because meaningful whitespace

[barbariccow]

If you are passing an object.. you can directly use ctypes, you know? or XML...

Or if you're cool, you can even use mmap, which is typically how I'd share data in C anyway..

Re:No, because meaningful whitespace

[ceoyoyo]

Re:No, because meaningful whitespace (Score:?)
by Anonymous Coward on Monday June 12, 2017 @09:16AM
I consider that a feature actually. Use tabs for code. When you copy and paste something from the web you have to go through line by line and convert the spaces to tabs. That forces you to go through that code you just downloaded off the web line by line....

Actually, you can almost always do a search and replace for multiple spaces, but don't tell that to my summer students.

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

[Hognoxious]

I'll take "nasty but I can see it" over "nasty and invisible" any day.

Re:No, because meaningful whitespace

[fnj]

I would go so far as to state that Python's design is stupid in that it doesn't just flag all hard tab characters in the text as ERRORS. This would complete eliminate the potential for criticism. As it is, the criticism that invisible characters represent a fatal weakness is NOT entirely specious, and it is unfortunate because it is so unnecessary.

Re:No, because meaningful whitespace

[barbariccow]

Now try pasting a piece of python code, and see if the whitespace survives the HTML formatting.

Sure, I'll play. You can write obtuse code in any language. Here's same program in python (without whitespace!)

lst = [(x % 5 == 0 and x % 3 == 0 ) and ("Number = %d FizzBuzz" %(x, )) or (x % 5)==0 and ("Number = %d Fizz" %(x,)) or (x % 3 == 0) and ("Number = %d Buzz" %(x,)) or ("Number = " + str(x)) for x in range(101)]; print ('\n'.join(lst));

Re: No, because meaningful whitespace

[histreeonics]

As a software manager I (with some reluctance) switched to spaces-only as each engineer had their own preferred editors and some did not handle tabs well. Dealing with 3 or 4 people editing the same files became much easier after that. Kinda like Python, its crappy but if it is what it takes to get people working together then it has some merit.

Re:No, because meaningful whitespace

[barbariccow]

should clarify: Doesn't NEED whitespace*

Re:No, because meaningful whitespace

[twistnatz]

You could try to configure your favourite text editor so that tabs are substituted with 4 (or whatever) spaces. In my experience that is enough, and if you cannot manage that then maybe you should find a different line of work.

Re:No, because meaningful whitespace

[sjames]

Even worse is a situation where convention specifies a use of whitespace so the human can read it but the compiler sees an entirely different structure. Perfect for creating a nearly invisible bug. If the compiler/interpretor also uses the whitespace to decide, at least it will do what it appears to do.

Most projects large enough to have more than one person on them already set conventions for structuring, commenting, ets. Why not include whitespace conventions?

Re:No, because meaningful whitespace

[sjames]

No because C code is easily structured to LOOK like it says one thing when it says another. Now try and find the bug.

Re:No, because meaningful whitespace

[sjames]

Now, mis-indent something in C. See how long it takes someone else to figure out why the code seems to not do what is plainly written.

Re:No, because meaningful whitespace

[sjames]

Find the bug. Better yet, hand it to a co-worker to find it.

Re:No, because meaningful whitespace

[Sneeka2]

Python doesn't force specific variable casing, though it does have strong recommendations. So your beef might be more with specifics of Rust (which we're not talking about here) than Python.

Putting that aside, you do have a point in general, but then again... a language will always enforce certain things. Use of parentheses, spaces, braces, keywords, function calls... you name it, your language has some requirement for it. Whitespace is just one of those things, and personally I find it somewhat silly to single it out as the one thing to complain about and dismiss a whole language for.

Not having to worry much about code formatting styles amongst different developers because it's virtually impossible to write code which doesn't conform to the standard isn't a bad thing.

Re: No, because meaningful whitespace

[Sneeka2]

And mixed tabs and spaces in "brace languages" will sooner or later mess up formatting when handing the code back and forth between different developers, so you're sooner or later confronted with the issue anyway and need to get your editors in line. Well, Python editors are already in line because the language demands it...

Re:No, because meaningful whitespace

[goose-incarnated]

Find the bug. Better yet, hand it to a co-worker to find it.

Bug found in less than a second after I put it into file tmp.c:

cat tmp.c | indent

Now, try to do the same thing with misformatted python.

Re:No, because meaningful whitespace

[Austerity Empowers]

The whitespace issue makes me nauseous. The lack of strong typing makes bugs.

Re:No, because meaningful whitespace

[sjames]

Why, if it's misformatted, it's an actual bug, not just a visual flaw.

OPf course, with a program more complex than fizz-buzz, you might have a hell of a time deciding if the indent is wrong of the brackets.

Re: No, because meaningful whitespace

[jon3k]

Everyone keeps talking about this problem but I've still never seen it in practice, directly or indirectly. Every shared codebase in the world is based on dozens or hundreds of internal conventions, but somehow we think we can't manage to avoid mixing whitespace?

Re:No, because meaningful whitespace

[goose-incarnated]

Why, if it's misformatted, it's an actual bug, not just a visual flaw.

OPf course, with a program more complex than fizz-buzz, you might have a hell of a time deciding if the indent is wrong of the brackets.

I might, but my odds are better when I can run the program through indent than when I can't because the whitespace is significant. Face it, if you have the same problem in python, you're shit out of luck.

Re:No, because meaningful whitespace

[Jezral]

Absolutely agreed. Significant whitespace is an abomination. The semantics of the code shouldn't change depending on whether it was copy/pasted between codebases, emails, or even office documents.

Re:No, because meaningful whitespace

[sjames]

No, I'll just have to do the same analysis you will when you decide which is wrong. OTOH, the python is less likely to have been checked in defective since the whitespace error should make it flunk a unit test on the spot.

Re:No, because meaningful whitespace

[goose-incarnated]

No, I'll just have to do the same analysis you will when you decide which is wrong. OTOH, the python is less likely to have been checked in defective since the whitespace error should make it flunk a unit test on the spot.

And the C or C++ defective code would *pass* the unit test? The odds for bugs getting checked in are higher in the python case, not in the static+strongly typed languages case.

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?

Re:No, because meaningful whitespace

[sjames]

If someone screwed up the indentation years ago, it would have passed the unit test just fine (if there was one then).

But if you're really hung up on a visible character top decide the level, just use an editor that makes tabs visible.

Re: No, because meaningful whitespace

[Sneeka2]

I'll agree with jon... this hasn't been an issue in practice for me in the last decade+, so is not a very convincing argument as far as I experience it. And especially when the language insists on correct whitespace, it's more likely that everyone is on the same page to begin with, and that issues with whitespace manifest immediately with a broken program rather than lingering undetected for a while.

Re: No, because meaningful whitespace

[0111 1110]

F90 discarded white space significance in 1990.

Interesting. This happened only about a year after I took my first formal programming course at university. So my first formally taught programming experience was with a language that refused to compile if you accidentally typed a space at the end of a line. I found the constant bugs due to this so annoying that I dropped the course in the first couple of weeks even though programming is one of my favorite activities in the world. To this day I have never touched Fortran again.

Luckily the C/C++ era was fast approaching and I loved and continue to love that language for its efficiency and concise logical structure. It just makes sense for me and feels right. For me the choice of language is mostly about personal preference. More a matter of taste than anything. Although for performance critical tasks I would hope any competent programmer would drop into C/C++ or even ASM for critical inner loops.

There are a couple of language types I'd really like to see though. One would be a compiled-programs-as-objects language that is 'object-oriented' but with objects that can run and be useful on their own and not only as a component of another program. Another would be a language that is more friendly to code self-modification at runtime to better implement genetic algorithms.

Re:No, because meaningful whitespace

[goose-incarnated]

If someone screwed up the indentation years ago, it would have passed the unit test just fine (if there was one then).

But if you're really hung up on a visible character top decide the level, just use an editor that makes tabs visible.

Or I could, you know, run the code through indent to make it conform to the company's guidelines. Of course, I can only do that if it isn't written in Python.

Remember your original "example" of having all the code on a single line? Remember how easy it was for an automated process to format? Tell you what - find a way to instruct a computer to turn the following back into the original source:

def fizzbuzz(n): if n % 3 == 0 and n % 5 == 0: return 'FizzBuzz' elif n % 3 == 0: return 'Fizz' elif n % 5 == 0: return 'Buzz' else: return str(n)

Using braces gives me options that don't even exist with python

Re:No, because meaningful whitespace

[BenJeremy]

WTF are you talking about? First off, most editors will re-align code to the user's preferences. I set up my editors to do exactly that, and whether I'm debugging code or simply working on making changes to existing code, the first thing I do is reformat.

No "mis-indentation" at all there. Everything lines up exactly as it should because the code is easy to parse (both by humans and machines).

So the first time I hit return in the middle of misbehaving code, everything lines up and I can immediately spot the problem.

Can't do that with "mis-indented" Python code. You can't do that at all.

Re: No, because meaningful whitespace

[goose-incarnated]

And mixed tabs and spaces in "brace languages" will sooner or later mess up formatting when handing the code back and forth between different developers, so you're sooner or later confronted with the issue anyway and need to get your editors in line. Well, Python editors are already in line because the language demands it...

The non-python programmers can run indent. The python programmers will have to figure out the mess on their own.

Re:No, because meaningful whitespace

[nasch]

This seems painfully obvious to state but there's a big difference between whitespace and those other things you mentioned: you can't see whitespace.

Re:No, because meaningful whitespace

[goose-incarnated]

No because C code is easily structured to LOOK like it says one thing when it says another. Now try and find the bug.

Like I pointed out above, it takes less than a second to find a bug that is due to incorrect formatting. Because, you see, indent works on non-python programming languages.

You keep saying "Now find the bug" and I keep saying "cat src.c | indent". What don't you understand about "Python indentation errors cannot be caught nor fixed by any automated process"?

Re: No, because meaningful whitespace

[nasch]

Is your point that it's better that things break if the whitespace is wrong so that the whitespace is always right? Isn't it better if things don't break if the whitespace is wrong, so that then there is no such thing as wrong whitespace?

Re:No, because meaningful whitespace

[waveclaw]

A good programming editor has the ability to make 'whitespace' characters visible somehow. IMHO, lack of that feature is one of the criterion for being good or being suitable for programming. (Yes, you can also write War and Peace in notepad.exe if you really have to.)

VIM has 'set list'.

Sublime shows whitespace on selected text.

Atom has the editor.toggle-invisible setting (and lots of packages to add menu option for it.)

Visual Studio has CTRL + R, CTRL + W Menu: Edit -> Advanced -> View White Space

In EMACS you have to write a little lisp code.

At the end of the day this is about as annoying as finding the missing semicolon in ALGOL-style code.

Re: No, because meaningful whitespace

[jon3k]

If it screws up the code it won't pass a build test and won't get merged, so the question is based on a false premise.

Re: No, because meaningful whitespace

[angel'o'sphere]

Sorry,
but this discussion over whithe space usage in Python is pretty pointless.

If it would use { and } or BEGIN and END, people who discuss about its usage of white spaces would not use the language anyway. They simply would find another reason why they don't like the language.

The only mistake Guido made is that he allows space and tab being mixed as leading intro and treats a single tab like a single space.

He should have made one of both a syntax error. (I believe there is a compiler/interpreter option to disallow tabs)

I for my part like the white space usage which makes Python executable pseudo code. But I hate the idea that methods need an explicit 'self' variable as first parameter.

On the other hand I only used Python once for a job interview. I wrote a prety complex program, downloaded stuff from the internet, extracted data from the HTML pages, calculated some means and other things, and plotted a graph, uploaded the results to a different web site, etc. However the interviewers where fair and gave a list of libraries to use for which task, otherwise I never had made it in the timeframe they gave.

Bottom line I had something like 250 lines of code, about 15 functions doing the releevant steps, programmed in 4h.
I was the only one who had a nearly perfect program. I had never programmed in Pyton before.

Re:No, because meaningful whitespace

[Wraithlyn]

Or, on the other hand, perhaps it is just as valid as any other parsing requirement? Language commands need some form of context

So what, all forms of context are automatically equal? Because you say so?

Well I'm sorry, but all forms of context are not automatically equal, and we may consider the pros and cons of each. Using invisible characters to control program flow is a shitty design decision that favours conciseness over readability. Code should not fail because of something you cannot see.

Everyone is entitled to their own opinion, of course.

Re: No, because meaningful whitespace

[nasch]

That's a fair point, but in other languages if the issues linger undetected, that means they're not really issues, because they only way it could be an issue is if it's causing a problem for a human.

Re: No, because meaningful whitespace

[nasch]

What false premise?

Re: No, because meaningful whitespace

[angel'o'sphere]

That said, C really screwed up by making them optional for single statement blocks.
How can that be a screw up when clearly a single statement is not not a block? Cough, cough, cough ...

      if (c) v = something;

If you are scared about programming errors due to misplaced or missing braces then write one liners like above. Problem solved.

Re:No, because meaningful whitespace

[angel'o'sphere]

Basically every code editor can display white spaces, it is probably even easy to find in the settings.

Re:No, because meaningful whitespace

[angel'o'sphere]

Every IDE contains an editor.
I find such posts as yours simply idiotic.

Whitespace IS visible, and the interpreter will happily point out where you (or your editor) screwed up.
In Python? No. Either the code can be interpreted then it runs, but gives the wrong result ... or it is a recognized error, and no one is complaining about the later. All hate the former.

Re:No, because meaningful whitespace

[angel'o'sphere]

You accidentally left a few superflouvious space chars, e.g. in the condition of the first if and the final return :)
You waste so much space, man!

Re:No, because meaningful whitespace

[angel'o'sphere]

You are both idiots.
This is the endless argument always given in this stupid war.

As long as no one knows what the program actually is supposed to do, there is no bug. Both ways of formatting it either in C or in Python just make the program run just fine, but with different results.

Who am I to decide which result is correct and which program is buggy?

Re:No, because meaningful whitespace

[ceoyoyo]

Every IDE contains an editor.
I find such posts as yours simply idiotic.

Hey old friend! Still don't read posts hey? If english is not your first language it's understandable, but you really shouldn't criticize then. Let me rewrite my post for you, slowly.

OP said "Maybe I'm using the wrong editor...."

I said (edited for the angels): "You're using the wrong editor. [It's probably part of] an IDE? IDEs are evil."

By the way, I find most of your posts pointless, and the others demonstrably wrong. I *think* you managed to score both on this one:

Whitespace IS visible, and the interpreter will happily point out where you (or your editor) screwed up.
In Python? No. Either the code can be interpreted then it runs, but gives the wrong result ... or it is a recognized error, and no one is complaining about the later. All hate the former.

Python gives an IndentationError exception when you have whitespace the interpreter can't parse. It points out the exact location. So if you slip in a space by accident (because you should be using tabs) then the interpreter helpfully points out exactly where it is so you can delete it.

You've never actually used Python, have you?

Re:No, because meaningful whitespace

[dinfinity]

Oh, I refer to the old interface (which I am still using).

So am I. There are borders around expanded comments. End of story.

Re: No, because meaningful whitespace

[sl3xd]

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.

Every version control system I've ever looked at considers whitespace to be significant, so we have the same problem in every language - if not during development, then while merging code.

As a result, every coding standard I've ever seen (both open source and corporate) is explicit (and detailed) in how indentation is to be used, and every text editor worth using is able to easily convert indentation to the required form.

If anything, I appreciate that Python will break quickly - before somebody commits their code and causes a merge headache down the line.

Re:No, because meaningful whitespace

[sjames]

Tab is just another character, right? So why not use it?? Just make your text editor show it as a visible glyph (there are several that can do that IIRC).

Re:No, because meaningful whitespace

[sjames]

Can't do that with python where a tab is mis-placed, can't do that with C where a brace is mis-placed.

Re:No, because meaningful whitespace

[sjames]

And why don't you understand that tab is just another ASCII character. Drop a few braces in C and you'll have a similar problem.

Re: No, because meaningful whitespace

[SoftwareArtist]

Lots of languages use significant whitespace. C and C++ do, for example. They're just less consistent about it than Python. For example, the preprocessor uses line breaks to indicate end of line, unlike most of the language that uses semicolons. And you can't put a line break in the middle of a string literal, because that's another place where it's inconsistent and treats whitespace as significant. Even things like having to write "vector<vector<int> >". Notice the space I had to insert between the two >'s? Without that, some compilers interpret it as the >> bit shift operator.

There's nothing wrong with significant whitespace, as long as it's done consistently and produces readable code. Python does it well. C++ does it badly.

Re: No, because meaningful whitespace

[doom]

Also, natural language is NOT a good model for programming languages

How do you know?

That's a serious question.

CS geeks keep acting like they've got some lock on The Truth, but if they've got anything to back that up, I haven't seen it yet.

Re: No, because meaningful whitespace

[doom]

Every version control system I've ever looked at considers whitespace to be significant, so we have the same problem in every language - if not during development, then while merging code.

True, but the fact that our diffs are broken is not actually a good reason to break everything else in the same way.

Re:No, because meaningful whitespace

[BenJeremy]

First off, a brace misplaced is far different from taking perfectly good code and copy-pasting it to find all of the scoping has been screwed up (Python) - and modern IDEs have no issues showing you where a missing indent it, which isn't happening with Python.

I'm curious, are you strictly a Python programmer? You seem to have a lot of emotional investment in this issue. Personally, I make my living from C#, Javascript and a smattering of something called Progress ABL - in my previous job I've also heavily used C/C++ and some PHP. As a robotics mentor I use Java, and as a hobbyist, I do use Python. I've also done BASIC, Pascal, Forth, COBOL, EDL, ActionScript, LUA, and even wrote my own scripting language back in my Xbox hacking heyday (for MXM). It's only 35 years of experience talking here, and I've written code on everything from DOS Edlin to modern IDEs. I know what makes me productive, and what I've observed the countless developers (both young and old) that I've mentored both professionally and for FIRST robotics.

Listen, maybe you are just trying to be facetious, maybe you are being outright disingenuous, but you simply cannot rationalize the concept that misformatting in Python is in any way no worse then something similar in C code. Misformatted Python code can happen with perfectly legitimate code when performing a simple action of transferring the text... C does not suffer from this flaw. DOES NOT SUFFER. If we are talking about code that has been badly written? Well, that's a different beast than what people here are complaining about - but even so, it is far easier for a modern IDE to still recover much of the scoping based on context, whereas Python requires an incredible amount of inference when the whitespace integrity is lost - so much so, that a moderately complex program might be impossible to untangle.

There is a reason why most modern languages have explicit scoping delimiters.

Re:No, because meaningful whitespace

[doom]

A good programming editor has the ability to make 'whitespace' characters visible somehow.

Sure, but then they all also have good features to track opening and closing braces (and those are actually turned-on by default, there's no somehow like the elisp code I use to make tab characters red).

I'm more sympathetic to the argument that with Python you have to be careful with moving blocks around because you need to adjust indentation when you change logical levels.

If we actually were to settle this argument, it would take some social scientists studying frequency and impact of programmer's errors.

Re:No, because meaningful whitespace

[angel'o'sphere]

You seem to have the same reading conprehension problem you accuse me for.

Python gives an IndentationError exception when you have whitespace the interpreter can't parse.
Obviously.
And if it can parse it, but the intendation is wrong nevertheless, it executes it.
Hence the rant of the Python haters in this thread.
I quote it again for you, if you read it slowly you migt grasp that we both said the same thing:

Whitespace IS visible, and the interpreter will happily point out where you (or your editor) screwed up.
In Python? No. Either the code can be interpreted then it runs, but gives the wrong result ... or it is a recognized error, and no one is complaining about the later. All hate the former.

IDEs are evil
No they are not. They are just a tool chain in one Application that happens to contain an editor. Which you probbaly just configure like your favourite one if you cared to RTFM or simply open the settings.

Re:No, because meaningful whitespace

[sjames]

Python is one of many languages I use or have used including C, Java, PHP, Javascript, FORTH, FORTRAN, Pascal, and various assembly languages. I find IDEs annoying personally. I prefer vi, make, and friends.

I GENUINELY don't get why ASCII 0x7b and 0x7d are fine but 0x09 makes people go ape shit. Next we'll see calls for trigger warnings at this rate. Just look how many people were 'triggered' by my fairly calm first posting on the topic. It's just not that hard. Gaining or losing a tab in python is no worse than, for example, losing a closing brace in C and the compiler just points you to the last line in the source file as the error.

I do find Python to be particularly expressive and fast to develop in.

Re:No, because meaningful whitespace

[tender-matser]

if(((i%3)||(i%5))== 0) printf("number= %d FizzBuzz\n", i)

man operator(7) and get rid of all those cock-sucking parentheses.

They clutter your mind and if your brain isn't able to cope with simple levels of precendence, you're worthless even as a janitor; and indenting is not the cure for your disease.

You won't be able to grasp the difference between 'or' and 'and' even with copious whitespace, syntax highlighting.and blinking.

Re:No, because meaningful whitespace

[Pulzar]

I set up my editors to do exactly that, and whether I'm debugging code or simply working on making changes to existing code, the first thing I do is reformat.

I bet people love collaborating on projects with you.

If you've never run into the case of someone writing:

if (a == b)
  a++;
  b++;

...and then trying to figure out how can b be incremented without a incrementing as well... then you just haven't work on other people's code quite enough yet to appreciate the point.

I don't know quite how I feel about Python's solution yet (I've only been actively using it for a few months), but it does make it very obvious *how* things are going to run, vs. what the author intended. Good or bad, it does make it easier to debug in some situations.

Re:No, because meaningful whitespace

[andreasgonewild]

There are plenty of differences between threads and processes. It's clearly one of the niftiest multiprocessing-libraries around, but there are plenty of things that just can't be passed between processes; which is where you'd use threads instead. Pretending the problem isn't there is never going to work, this is a major limitation in CPython.

Re:No, because meaningful whitespace

[sjames]

Actually I just pasted in an example and stripped the white space. I didn't give a damn about the parentheses at the time (cock sucking or otherwise).

Re:No, because meaningful whitespace

[goose-incarnated]

And why don't you understand that tab is just another ASCII character. Drop a few braces in C and you'll have a similar problem.

No, I won't - indent, grep, diff and all the other tools I use (including the compiler) will show me a blank spot where the missing brace should be. With python the missing character is invisible, you twit. It is literally not visible.

Besides, you're moving the goalposts. You kept saying "Now find the bug", and I showed you how common tool sactually do find the bug. These tools can't work with python because python syntax depends on invisible characters.

Re:No, because meaningful whitespace

[sjames]

The tab is literally just another ascii value. Why would any of those tools have a hard time 'seeing' it?

this is a test$
^I^Ihere be tabs$
$

From vi after telling it :set list

Re:No, because meaningful whitespace

[BenJeremy]

We have organizational coding styles. Typically, I match whatever the style is, reformatting isn't an issue.

This is how professionals work.

As for your example, I use scope delimiters, always. In the past 20 years, I have not had a team mate who has not adopted this rule themselves. It just makes sense, but in any event, it is clear what is going on (I usually parse code in my head when reading it), regardless of indentation, but again, reformatting quickly sorts out that indentation issue, doesn't it?

My early professional years were in embedded systems programming (Assembly, C, C++), and understanding the way a compiler generates code, particularly calls into libraries, meant I also became familiar with compiler operations. There is an elegance to using proper scoping delimiters - both from a compiler perspective as well as a readability issue. Python's form hearkens back to a darker age - I'm reminded of the spate of so-called 4GL languages that tried to do everything for you, and failed to keep up with changing technology in the process. Loose-formed ideas of passing parameters and changing means of representing scope... inconsistency born of creating a scripting language from scratch without regard for actual parsing rules.

It's clear some people are fanatics about Python... and that's fine. Will it become dominate? No. In my world, where people make serious money building applications for multi-billion dollar companies, Python isn't even a speck - and we dabble in a lot of different programming languages. C# is becoming more dominate at my current company, and there simply is no downside to that. We have a good ecosystem (Nobody will bring the company down here on their first day) and good practices. If Python meets a need, I'm sure we will use it... but there are far better choices available for most of the applications we need to develop here.

Re:No, because meaningful whitespace

[mfearby]

This is usually trotted out by people who 1) haven't tried it or 2) remember FORTRAN.

But FORTRAN suffered from both too much whitespace significance, AND NOT ENOUGH.

Bear in mind that a good lint tool can find whitespace inconsistencies.

I cobbled together a simple Python script once for some reason or other (can't remember anymore) and it was OK I guess, but so many languages have C-like syntax that I prefer those generally, which is why I tend to do mostly c# and javascript these days. Using whitespace for block separation just annoyed me and I didn't like it one bit. Programming languages are a dime a dozen and I see no need to add Python to my resumé.

Re:No, because meaningful whitespace

[goose-incarnated]

The tab is literally just another ascii value. Why would any of those tools have a hard time 'seeing' it?

Let me repost so that you can read it again:

You kept saying "Now find the bug", and I showed you how common tools actually do find the bug.

I don't need a special editor, or enforced (meaningful) whitespace to take your program-all-on-a-single-line and turn it into well-formatted code. I can use a program that does that. When your python code is mangled you have no tools to unmangle it.

Re:No, because meaningful whitespace

[david_thornley]

Bu-but doesn't everyone love makefile syntax?

Re: No, because meaningful whitespace

[david_thornley]

Braces also stand out more. "begin" and "end" look like any other reserved word or variable name. I prefer to have the program structure easier to see.

Re:No, because meaningful whitespace

[sjames]

So, your special program can actually comprehend the code and replace syntactically meaningful characters if I should remove some (or throw some in)? You're still hung up on the 0x09 character being somehow different simply because the tools you happen to use treat it in a particular way. Stripping the tabs from a Python program is like stripping the braces out of a C program.

All that while extolling the virtues of a utility program that simply enforces a visual formatting rule on C code that is already intrinsic to Python.

Re:No, because meaningful whitespace

[superwiz]

It is however a problem if you have much communication between processes.

If you are passing too much information between tasks, they will be slowed down regardless of whether the tasks are processes or threads. There will be significant slowdown in having data travel from one processor's L1 cache to the other processor's L1 cache. In fact, it is so slow that you may as well think of information travelling from one processor to the other processor ar travelling through a (very fast) network and architect accordingly.

Per default the multiprocessing module will pickle/unpickle the transmitter information.

I never saw that as a problem, but I do believe that the underlying process of pickling is open to being modified.

Re:No, because meaningful whitespace

[superwiz]

How about a programming language that doesn't force your programs to fit a model?

yes, because uniform api with pluggable implementation depending on the needs is bad thing, right? Oh, brother.

Good thing it was all planned out to add the GIL, and that it wasn't just some limitation that is hard to get rid of.

I don't see it as a limitation. I see it as an advantage. You don't need any processors talking to each other before they each one of them can decide to throw out small chunks of memory back into its unused pile.

how could one threading model be perfect for them all?

It's not. It's why there are 2 models. Same api: that's the advantage. If a thread becomes more CPU bound, you plug in one implementation. If it becomes IO bound, you plug in the other. So you are free to optimize per-thread IO or CPU performance... whichever one is more open to optimization.

Re: No, because meaningful whitespace

[Pig Hogger]

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.

The whole idea of using white space for context means that you do not have to reformat your code, ever.

Re:No, because meaningful whitespace

[superwiz]

NO, it doesn't. I has a problem of becoming popular and being used by a lot of people who don't know what they are talking about.

Re:No, because meaningful whitespace

[superwiz]

Not understanding the difference between how to treat CPU-bound threads vs IO-bound threads is a problem between the ears -- not a problem of your programming language.

Re:No, because meaningful whitespace

[Pig Hogger]

Moof!

Re: No, because meaningful whitespace

[superwiz]

Yes, line continuation is an ugly hack. But, in practice, it's rarely necessary because the language discourages long lines and has enough mechanisms to make them unnecessary.

Re: No, because meaningful whitespace

[superwiz]

Try this for measure:

for(i = 0; i < something; ++i)
if (expr1)
if (expr2)
do_this();;
else
do_that();
Proper C. Totally readable... of course.

Re:No, because meaningful whitespace

[eddeye]

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.

Well there's your problem. Only heathens use spaces to indent. Switch to tabs and bob's your uncle, problem solved!

Re: No, because meaningful whitespace

[superwiz]

What makes you think I didn't notice it? It's was just a demonstration for the guy who thought that 1-statement blocks without parenthesis were readable. Oh, and I like Python. I've used it since version 1.2.

Re:No, because meaningful whitespace

[Rockoon]

Meanwhile its a rare language that asks you to bend.

There is a reason other languages dont do it. Why dont you address them?

Re: No, because meaningful whitespace

[angel'o'sphere]

Indentation would not change the double semicolon error.

Re: No, because meaningful whitespace

[michael_wojcik]

Precious few programming languages don't make whitespace significant in some contexts.

intmain(void){return0;} is not valid C.
classFoo{staticvoidMain(){return;}} is not valid Java.
programfooendprogramfoo is not valid Fortran 90.

I don't think whitespace is syntactically significant in APL, but it's been a long time. In any case, most (textual) programming languages use whitespace at least as a delimiting lexical construct in some contexts, because most of them employ character sequences that are not self-delimiting, and whitespace is the obvious delimiter.

Re: No, because meaningful whitespace

[michael_wojcik]

Brackets as scope delimiters also have the advantage that they're easy for tools to match. Textual delimiters are easy to read, and avoid the mass-of-terminators problem often seen with LISP, for example; but they can be difficult to pair when reading code.

That's particularly true with ALGOL- and Pascal-style begin/end pairs. The form-specific scope delimiters in languages like Fortran ('90 et seq) and COBOL (85 et seq) are more helpful; in modern COBOL, the reader knows that an end-if will terminate the innermost if, an end-evaluate the innermost evaluate, an end method[1] the method.

And of course these form-specific delimiters also help the compiler identify errors. Too many closing brackets in C and you have code outside a function, and the parser will complain, but it doesn't know which closing bracket was wrong. But a COBOL compiler can say "you have an end-if here, but your innermost control structure is an evaluate, so this line is clearly wrong".

But on the other hand it's trivial for an editor to provide the "highlight matching punctuation mark" feature, and easy to implement bracket-counting when you're writing an ad hoc script to do some sort of source-code analysis.

Either beats whitespace for block-scope definition, for anything that's too long to fit on screen. While I appreciate the argument that code structure should be apparent to human readers, trying to enforce that in the language causes more trouble than it saves.

[1] It's a bit unfortunate that some of COBOL's scope keywords are hyphenated and others are phrases, but in practice it's easy enough to learn, especially with syntax-coloring editors.

Re:No, because meaningful whitespace

[michael_wojcik]

You're using the wrong editor.

You're fixing the wrong problem.

Yes, sometimes a system is sufficiently better that it's worth the cognitive load, opportunity cost, and psychological cost of switching tools. But it's a high bar. "Switch tools" requires very strong justification.

Re:No, because meaningful whitespace

[ceoyoyo]

I don't know... an editor that screws around with your text without telling you, and doesn't have an option to turn it off? That sounds like a good problem to fix with high priority to me.

No

[grungeman]

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

As soon as ...

[tgv]

As soon as it runs in the browser.

Boys, start investing in octocore CPU and RAM manufacturers.

"Native" C# Developer

[mmdurrant]

I learned my chops in the .NET ecosystem. Then I got turned into a quasi-Openstack developer.

Python is pretty cool. The lack of a real type system makes me write a lot of assertions I don't want but ultimately protect me from stupid mistakes later on.

It has reasonable syntax and with map/filter/etc you get most of what you get out of LINQ... I think it's great.

Re: "Native" C# Developer

[plopez]

Good compilers protect you too and you don't have to write boiler plate code.

Re:"Native" C# Developer

[NotInHere]

Python has a type system, its in fact quite strong (as opposed to a weak type system like that of javascript or bash), but its not static, its dynamic.

Re:"Native" C# Developer

[superwiz]

Well, apply got killed first. But that's only because Guido is scared of lambdas. Granted, most developers don't think in tensors. But turning programs into abstract algebra exercises could have been a rubicon. For now, it remains outside of the reach.

Re:"Native" C# Developer

[Entrope]

Right. So when you do typical high-level operations -- working with databases or network connections -- you often have to convert types, and the compiler has no way of telling you when you missed a required type conversion. You just get a runtime error, and then you need to trace back to find where the badly typed value started to be badly typed.

Re:"Native" C# Developer

[gweihir]

Python is pretty cool. The lack of a real type system makes me write a lot of assertions I don't want but ultimately protect me from stupid mistakes later on.

That is as it should be. OO and in particular, polymorphism is not all it is cracked up to be. Limit it yourself whenever needed.

Re:"Native" C# Developer

[tbannist]

Remember kids: Thoughtless design is bad design. It's why lambda's are completely borked.

If prefer the aphorism: "When you fail to plan, you plan to fail."

Re:"Native" C# Developer

[dkasak]

Note that you two are not discussing the same kind of "type" here, even though they share a word. Dynamic type systems can be regarded as static type systems where all values have a single type. However, Python has been gaining optional static typing capabilities . See mypy, PEP 483, PEP 484 and also the typing and typeshed) modules.

Re:"Native" C# Developer

[angel'o'sphere]

You just get a runtime error, and then you need to trace back to find where the badly typed value started to be badly typed.
Which is obvious from the stack trace.

Re: "Native" C# Developer

[Entrope]

It seldom is, because Python variables are untyped. You need to take back to figure out where the value (not the variable) came from, and why the value has the wrong type.

Re: "Native" C# Developer

[angel'o'sphere]

Variables in Python are typed. You simply have not to declare any type.
A variable is either null or has the type associated of the value it holds.

If you have trouble to follow a stack trace, you should ask a friend/coworker to help/teach you.

With a stack trace of x lines it should not take longer than x seconds to find the spot of the mistake. I find it usually on a first glance.

Re: "Native" C# Developer

[Entrope]

If you don't know programming, don't try to pretend. Variables are typed if they are constrained to only contain values of a particular type. Values have a runtime type that may be narrower than their variable's type. C-family languages have typed variables. Python does not.

Stack traces do not tell you the life history of a value. It may have been wrong in a function called somewhere else entirely, then gone into a container that got sent to a different thread or process, maybe altered by some type-agnostic operation, and only caused a problem long after the root cause occurred. Congratulations on only working with toy code, such that the stack trace tells you everything you need to know.

Re:"Native" C# Developer

[piojo]

The problem with relying on those assertions is that only code paths you run (or have test coverage for) will get the benefit. The problem with test coverage is that the tests can be wrong. I upgraded python code to a new version of python and the library, and doing similar work in C++ wouldn't have meant I didn't need to test each function, but I could have fixed a lot more of the problems before running the code. And while I think python is well suited to scripting, that experience showed it's a liability for maintenance.

Wrong on all accounts

[Anonymous Coward]

Python is the fidget spinner of programming languages. Python devs are an uppidy bunch who have no idea of the benefits of other languages. Saying the "compiler gets in the way" shows their level of ignorance on this.

Re: Wrong on all accounts

[K. S. Kyosuke]

Not to mention that the compiler doesn't actually get in your way in many Python-like-ish languages that actually have one, such as Common Lisp or Chez Scheme. In fact, Chez Scheme could probably teach a thing or two to Python devs about implementation craftsmanship and quality.

Re:Wrong on all accounts

[K. S. Kyosuke]

Many don't know compilers have BOUNDS checking built in, or overflow - I guess one gig rocket exploded because of an overflow.

One might argue that the Ariane 5 incident was primarily due to lack of testing. Checking the bounds during the flight and not knowing what to do when they're violated during the flight would have been no better than overflowing during the flight. (Maybe saturation arithmetic would have worked for some situations?)

many devs don't understand classes or inheritance

Most of all the devs don't, unless they've done Smalltalk or CLOS and read Touretzky's book on inheritance systems. Or did you mean just using them? To wit, many people don't understand cars but they still use them. Mostly because they don't have to.

Many so called Devs can't do real debugging or single step diagnosis

You mean Hoare triples with the latter? Almost nobody does it these days.

Re: Wrong on all accounts

[butzwonker]

Chez scheme is awesome, AFAIK it's the fastest full-fledged scheme implementation, and I really hope that Matthew Flatt rewires Racket to use it as a backend implementation (if I understood his announcement correctly).

Re: Wrong on all accounts

[KGIII]

I just want to point out that I love these threads. I am not a programmer, but I have programmed out of necessity. I have one formal class in C, and that was in 1987, I think. I'd eventually hire competent programmers. I learned a great deal from them, as my time spanned the glorious days from about '91 to '07.

I read many of these threads, with great interest. I usually have a few more tabs open, so that I can look up terminology and investigate unfamiliar things. It was great to be able to work with some true masters of their craft. Eventually, I was pretty much forbidden to touch my own code - an agreement easily reached. After all, if I could do what they had done, I'd just have skipped the middleman and done it myself.

Each time a thread comes up with this as the content, I move one step closer to getting more proficient. I have kinda sorta taken up Java as a hobby. Don't blame me, I asked Slashdot and that's the answer they came up with. ;-)

Anyhow, my point is to express gratitude. I realize the thread is stale and this comment is well below the fold, but I am grateful. Just because I am old, doesn't mean I want to stop learning. These threads, specifically the content created by those who comment, are both motivational and informative.

When I was still working, I had the chance to work with graybeards from a bygone era. They were so good that it was an honor to give them money. It was even more an honor when they helped me to understand things better, increased my intellectual curiosity, and they would actually listen and, mostly, behave when we had clients in. If I'd been well behaved, they would even wear shoes. They sure as hell weren't going to wear shirts with collars.

They were heady days, as the tech changed and compute cycles became less expensive. Developers and engineers kinda remind me of semi-wild horses. If they listen, that's probably because they respect you. However, they thrive when given their freedom and encouraged to run. Give them their lead and their head lowers and you can experience the figurative ride of your life.

I'm not sure how many of those still exist. Given my experience, that was once the norm. Today, it seems less likely. Today, they seem to largely have an abstract knowledge, at best. There are exceptions, I speak only of averages and have my obvious limits of not seeing everything.

It's not easy to explain? When I hired experts, I asked them what best practices were. When answered, I went further and asked why those were the best practices. I asked how they learned those best practices. I asked what the results would be, if those best practices weren't followed.

I'm, again, not a programmer.

Today, it seems that most have stopped asking why those practices are the best practices. They'll do it, but they don't seem to care why. They don't seem to want to ask deeper questions. They don't know the things that some of you appear to know, and that's probably because they've never thought to ask. They know that to do X, you do Y. They may not even understand X or Y.

It's a bit like seeing the difference between a craftsman and a construction worker. I admit my bias, but I think I was fortunate to be in the best era for computing. Many universities barely had a CS department, and fewer had such at a graduate level. Then again, there weren't a whole lot of traffic engineers and not a whole lot of people in the field of modeling traffic.

Anyhow, it was great to be there. It was an honor to work *with* them. I always try to use the word 'with,' by the way. I owned the company and I was certainly the boss, but they didn't work for me so much as they worked with me. Without them, I'd have gotten much less accomplished. Without them, I'd still have to work.

It's great to read these threads, and to see the exchange of insights and observations.

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

[buddyglass]

For sure, doing UI and/or numerical stuff in Java isn't great. Could definitely see Python taking over those situations. My point of reference is that of someone who's done Java and Ruby dev, but not Python per se. I find that when working with Ruby code I make stupid mistakes that a Java IDE+compiler would have caught immediately. I also find that refactoring is actually easier in Java land due to all the things most popular Java IDEs do for you. Renaming things, changing includes, etc.

Re:eh

[Ambassador Kosh]

I normally use an IDE when writing Python code. I like having things like a working debugger when I can just set breakpoints and inspect variables along with having things like command completion. I used to use PyCharm but a while back I switched to using Visual Studio and I have really liked that. I tend to use the Intel python distribution with Visual Studio for development under windows and once the software works I deploy it to Linux servers for the heavy lifting.

The C++ based simulator I work on also works on Windows and Linux without any problems and Intel Parallel Studio can profile a Python application and the stuff that it calls. This makes life much better when working on HPC software that is controlled by Python to find out where problems are.

Re:What it is used for?

[Hognoxious]

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

What is a "dominant" language?

[Bearhouse]

Because if we're talking about stuff that's used everywhere that would be C in its various iterations plus Java...

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

[K. S. Kyosuke]

What you're asking for is called "a non-decidable type system". Shen already has it if you want it. So does Haskell if you try hard enough with extensions. Ultimately it works about as well as your unit tests.

Re: Lol

[bn-7bc]

Ok I know this is slashdot but still, Wghat yoy do with yoy bodely fkuids, and with what person/persons you decide to have sexual encounters is up to you, but I for one feil to se the relevance in a discusion about programming. If i'm missing somthing I apreciate feedback Have a nice day

Re: Lol

[K. S. Kyosuke]

but I for one feil to se the relevance in a discusion about programming

Genetic programming? ;)

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.

Re:Lol

[barbariccow]

vim<ENTER>

q1

y1<UP>

p

p

p

q

q2

@1@1@1@1@1@1@1@1@1

q

q3

@2@2@2@2@2@2

q

@3

False equivalence.

[Lanthanide]

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

Re:What it is used for?

[jandersen]

I think Python should be seen as a scripting language: a language whose purpose is to tie together the real applications, rather like bash and ksh. Python has a lot of packages or modules (or whatever they are called), many of which seem well suited for scientific or engineering purposes; it is my impression that most are written in C or C++ for speed. 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.

I think you are less likely to find applications in Python - it is quite possible to do, and I have seen some, but just like you wouldn't normally write applications for general consumption in bash (although you can), Python isn't really the obvious choice either, IMO. Perhaps it is exactly because scripting languages are so good for ad hoc work - you get to expect that everything must be equally easy to achieve, but many things are simply complicated by nature, so the advantages of using Python become less prominent.

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

[discord23]

Every python debate ever summarized in two comments:
>> Has it solved its threading issues yet?
> No, but you can call fork
Really now

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

[tomxor]

I duno... was Basic good in that it introduced a lot of people to programming? yes it was a terrible language, but it's a foot in the door.

I have mixed feelings about Basic becaus on the one hand it was very easy, on the other hand as soon as you need any structure it makes programming look awful and as my first language it did put me off quite a lot, I then revisited programming much later. I think python is a massive step up though, and a language without boilerplate and compilation is probably worth it for an introductory language, because lets be honest those things are not fun.

Re:Yes and for bad reasons

[drinkypoo]

I duno... was Basic good in that it introduced a lot of people to programming? yes it was a terrible language, but it's a foot in the door.

It's good in that it could be implemented on the kind of computers that schools could afford. Although, if you think about it, the Apple II (which was the early dominant computer in education here in the states, at least) was more than capable of running a visual editor, so schools could have at least used a BASIC editor that would autogenerate line numbers for you, which would have made the whole thing a lot more accessible.

BASIC isn't a great language in any form, but it's adequate. You can get stuff done in it, I've seen real work done with BASIC. For example, are you familiar with the Omniremote module that gave high-power IR to Palm devices? The creator laid the groundwork analyzing IR using the Amiga 500's onboard hardware in the version of Microsoft BASIC that shipped with the system.

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:Depends on the future

[tepples]

Whether enough people can be bothered to install the runtime to run said code.

If you distribute a C program as source code, how many people can be bothered to install a compiler? Or if you distribute a C program as a Linux/x86-64 executable, how many people who currently use something other than Linux/x86-64 can be bothered to install a Linux/x86-64 virtual machine?

Re:Depends on the future

[djinn6]

1) Whether enough people with little to no programming experience feel the urge to create code.

Yes, the amount of work that is waiting to be automated is enormous, and the number of people who are semi-technical is huge. If a programming language can connect the two, it will be very popular.

2) Whether enough people can be bothered to install the runtime to run said code.

Py2exe takes care of that on Windows. On Linux it's pre-installed.

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.

When your software engineers cost $100,000 a year and your machines cost $200 a year, you have to be running very large workloads for performance to matter. And while those aren't uncommon, there are far more programs that aren't performance-sensitive (whether measured in lines of code or their productivity or the number of programmers).

And C++ isn't even the biggest competitor to Python, that role belongs to Javascript.

Re:Depends on the future

[Opportunist]

That's why you usually distribute a C program as source for Linux and executable for Windows.

Re:Dominant where?

[Anonymous Coward]

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.

I hope not

[Quakeulf]

I've only used the Pythons for slite scripting in Blender 3D, but the syntax feels too subtly error-prone for me to feel comfortable to deal with. At least the C-langwitches and Java/Script are easier to scan in that regard.

Re:I hope not

[goose-incarnated]

I really hope not, Phyton is an ugly language, widely adopted or used doesn't say anything about the language being good.

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.

What nonsense is that? someone who says something like that has never really done any real development and is just a hack..

That's the problem with python - because someone can pick it up in a weekend the majority of the users are the weekend warrior types, which in turn means that the majority of the design decisions are for people with no aptitude for programming.

In a nutshell, this is why python is so popular.

Why the hell are you a slave to an IDE if you're using a compiler, how does the writer of the article do it's refactoring or test driven development. I don't buy for second he/she does everything by hand.

The odds are high that the author does TDD in order to catch errors that the compiler would have caught (wrong types in function calls, for example). They aren't unit-testing their application logic, they are integration-testing their call interface.

Re:I hope not

[BlackPignouf]

Javascript easier to scan than Python? You must be trolling.

Re:I hope not

[Quakeulf]

Well, maybe it's my familiarity with it, but no brackets, man.

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.

I hope not

[SuperDre]

I really hope not, Phyton is an ugly language, widely adopted or used doesn't say anything about the language being good.

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.

What nonsense is that? someone who says something like that has never really done any real development and is just a hack..
Why the hell are you a slave to an IDE if you're using a compiler, how does the writer of the article do it's refactoring or test driven development. I don't buy for second he/she does everything by hand.

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.

Re:Ruby

[Wdomburg]

When performance is a significant consideration there's JRuby.

Re:Ruby

[kwerle]

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.

(0..10).select{|i| i % 2 == 1}.map{|i| i**2}

I dunno - to me that looks almost identical - mostly just a little juxtaposed. Is it just me?

I've spent about the past decade doing Rails, am currently stuck in javascript, and may return to Rails or move to Python (which I did casually around the turn of the century).

Re:Ruby

[BlackPignouf]

The order is different, which might become more apparent with nested comprehensions and chained Enumerable methods. For brownie points, you could have written (0..9).select(&:odd?).map{|i| i**2}, which brings us back to Ruby's TIMTOADY against Python's zen ("There should be one — and preferably only one — obvious way to do it").

BTW, Python's range(10) has 10 elements (between 0 and 9), so it's equivalent to (0...10) or (0..9)

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:What it is used for?

[oakgrove]

I use Python along with Selenium for website automation and testing. I prefer it over Java in that regard as it is much faster to develop in and doesn't require as much "infrastructure". No compiling, no mandatory OOP, no need for an IDE, etc. Of all the things in that particular niche, I've found Python to be far and above the best.

My biggest complaint other than indentation

[Anonymous Coward]

I code in Python these days more than I do my preferred language of C++.

Most of my work is creating libraries that are pipeline building blocks for facility code. It drives me nuts when I have to refactor Python.

In C or C++ the compiler would error wherever the types, arg count, and other things have changed. Python you literally need to know every line of code you have deployed that may be affected otherwise you won't know until code runs and throws up all over itself.

This is compounded with Python not having types esp for function args. Also if you have a lib that while it doesn't directly interact with another lib, instead it's passed objects via an intermediate lib then holy shit you really can't find code that is affected by a changes.

And that's just for trivial things like adding a new type, adding removing args, renaming functions, adjusting classes.

Re: My biggest complaint other than indentation

[K. S. Kyosuke]

It makes sense to check for argument number, because calling a non-variadic function with a different number of arguments is never right. And languages like Scheme and their compilers can already do this well. But types (of arguments)? Seeing as Python is rather "objectey", that wouldn't probably make a lot of sense. Perhaps you're just providing a substitute value sometimes. Well, admittedly, that would be *technically* (behaviorally) the same object type, but I'm not sure that anyone has devised usable object type checking yet to account for this.

Re:My biggest complaint other than indentation

[gnupun]

This is compounded with Python not having types esp for function args.

Maybe you need to update your Python version. Latest Python supports optional types:

https://docs.python.org/3/libr...

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.

The answer is no

[oakgrove]

I really like Python. I find it faster to develop in, more flexible, and more ubiquitous than just about any other language. However, maybe 20 years ago when the world was simpler, it would have had a better chance at some kind of dominance. These days though, there are just too many niches it doesn't work in. Can't make first class apps for iOS or Android, can't use it natively to manipulate the DOM in a web browser. It's not as easy to use server-side like PHP. And on and on. Yes, Python can be used in all those roles if you bend and twist it enough but in most cases, there is a better domain specific language that people just default to.

Personally I find Python to be peerless for system administration and automation. Even better than bash. I understand it's good for statistical and scientific programming too. That's it's place. Not "dominance".

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:The answer is no

[angel'o'sphere]

Can't make first class apps for iOS or Android
https://kivy.org/#home

Re: The answer is no

[tepples]

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

Every reasonable source code editor I've used will highlight the start of a literal block (?>) and the end of a literal block (<?php). It's little different from highlighting """ in Python.

Re: The answer is no

[barbariccow]

It's not a highlighting issue. In my experience of dealing with other people's horribly written code, it is most common through a file being "included" which closes it, but the code continues thinking it's still open. If you are dealing with either file by itself, the highlighting is perfect. It's when they combine, often associated with error cases (like, you assume "!value" means you are including it as a template, and not that the value is null, etc).

Sorry if that's not clear, but I've had that happen on.... well..... I think maybe every single PHP codebase I've had to inherit over the years.

Re:The answer is no

[oakgrove]

I don't really see that as first class though. You'll always be a step behind the official API waiting for the next version of kivy to drop. And the official docs and support expect you'll be using one of the "blessed" languages so when you aren't, you can expect little bits of friction everywhere. That said, I like kivy and its spiritual predecessor sl4a. The latter actually got me into Python.

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

Re:modules

[phantomfive]

I like to write libraries in C, then use SWIG to make them available in basically every language. It's the most portable way to do things.

Re:What it is used for?

[superwiz]

All of them. Don't underestimate a Python programmer generating the code previously typed by a dozen code monkeys.

Wheel re-invention

[DrYak]

or, in other words :

Congratulations, you've successfully re-invented Perl (and bash to some intent).

More seriously :
yes, Python seem to be the current popular "glue code" language.
Like Perl and shell-scripts before it.
(and some BASIC dialects at some point in time in the microsoft ecosystem).

Re:Wheel re-invention

[vtcodger]

"Congratulations, you've successfully re-invented Perl"

Guido von Rossum has said that Perl and Python are pretty much the same language. And that seems correct. I don't see a lot of difference in coding in either language. But I personally prefer Python because when I can't remember syntax, I'm more likely to get Python right on my first guess. And I find Python to be a bit more readable six weeks or six months later. I think I have a lot of company on that.

"(and bash to some intent)."

Why would anyone want to reinvent the unix shell or any of its deformed children? About the best you can say for the shell is that it isn't as awful as IBM's OS/360 JCL. But few things other than the US Internal Revenue code, are.

But yes, Python scripts can (mostly) replace shell scripts

Re:Wheel re-invention

[drinkypoo]

Why would anyone want to reinvent the unix shell or any of its deformed children?

Now that we have lots of RAM, Unix's cheap process creation makes shell scripts haul balls. If what you're doing is making changes to many files, Perl (or whatever) may still be faster, but often the difference is irrelevant anyway.

If you can do a job with a very small shell script, it's still often easier than doing it in perl or what have you.

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:Wheel re-invention

[vtcodger]

Seriously, I don't really have any problem with **SHORT** shell scripts. I actually use them fairly often. But if there is anything other than trivial logic involved, shell scripting is the road to eternal damnation. At least it seems so to me.

Re:Wheel re-invention

[prunus.avium]

Congratulations, you've successfully re-invented Perl

Not quite. More like "Made a readable version of Perl." There's a reason Perl tends to be disqualified from any "obfuscated code" contests.

Python seem to be the current popular "glue code" language.

See OpenStack for a perfect example. It's just "glue code" around various virtualization packages.

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.

Re:Perl...

[vtcodger]

You go around beating people/things with snakes, and you'll have PETA to answer to.

Re:What it is used for?

[Anonymous Coward]

It also fills the "People who wish they could get the job done in Common Lisp in reasonable time but there are simply not the right libraries available" niche pretty well. As much as it pains me to admit it: Libraries do matter to the extent that if I have to choose between a nice macro system and a healthy ecosystem of high quality libraries for my application domain, I always choose the latter. Hence, I choose Python over Common Lisp.

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.

Not a single bad word about Python

[Nahooda]

I work as a software developer and I'v known a lot of other developers now. Whenever the conversation is about programming languages it will sooner or later turn into a flame war such as 'I hate language X' or 'Language Y is the best'. I've heard practically any programming language out there being criticized by experienced senior developers... with one exception: Python. No developer I've ever met criticized it. Anybody seems to love it. And rightfully so.
Besides Pascal it's one of my favourite programming languages: It's easy to learn, it's used in a lot of sectors and it seems to replace some of the older languages: In High Performance Computing it _seems_ to be slowly replacing Fortran and in systems administration it takes over the role of Perl as configuration language. Furthermore, it's used in Gaming as a scriping language (Blender Game Engine), it's used for Plug-Ins and configuration in many many Applications, in Web Development, in combination with R it's the de-facto standard in Data Science.
I sincerely hope, that Python will become more popular.

Re:Not a single bad word about Python

[dyfet]

For me, Python is the language I hope the other guy used if I have to maintain their code. That is, it's often easier to read and comprehend directly, and feels less convoluted to maintain a large code base in.

Re:Not a single bad word about Python

[histreeonics]

Your developers probably never had to deliver industrial systems where a bug requiring a update can kill a product line and maybe your company. Runtime is way too late to discover a programming error, the lack of static type checking removes one of the handiest tools for preventing those. --- I spent a month trying to get python to do the things that are easy to do in C++ and was never satisfied with any of it. Tuples are great, everything else was toy-like or was beyond proving correct. --- Once upon a time microsoft basic did not have syntax for declaring variables. A large program I was coerced into writing in MSBasic had some weird non-reproducible behavior. When MS finally added declaration syntax I declared all my variables and discovered some misspelled names, which were the source of those non-reproducible bugs. ---- If python adopted *optional* static type declarations it would be vastly superior to what it presently is. In the meantime all of its good novel features have been ported to C++ via libraries, which shows how vastly more capable C++ is. --- As per someone else's comment, when you realize you've made an architectural mistake you have to laboriously places that might be affected by it, where in a statically typed and declaration heavy language like C++ there are easy reliable tools to do a comprehensive "where used"/ --- And then there is the awful programming advice such as "prefer large flat classes over deeply structured ones". That is farking insane, one ends up using naming conventions to indicate structure instead of using structure to indicate structure. I can see that the poor performance of nested structure in Python makes that a performance issue, but that is something that should be apologized about rather than lauded. ((slash dot is removing the whitespace I used to indicate separate thoughts, apparently their engineers aren't Python fans}).

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.

Re:Ok, I'll bite...

[angel'o'sphere]

I already can C++, Java, C, various assemblers, etc. p.p.
Obviously I mostly google for languages 'I don't know yet good enough' and actually I don't google for the language but for a tool/library: how to parse html to extract data with Python? That points me to useable libraries, but not to a Python tutorial.

Re:Ok, I'll bite...

[gustygolf]

Switch statements. Did you know they use a glob like expansion in the cases?

No, I did not. I was not even aware that Perl had a switch statement -- apart from the broken Switch.pm module that was accidentally introduced to core in Perl 5.10.

That means that a switch statement is horribly slow, even if your are using all constants. This means you should use a completely different syntax in Perl called the "given ... when" which provides the utility of a switch statement without the utility of being able to type it like a switch statement.

And the given...when syntax (along with smartmatching, which it is based on) is experimental/deprecated too, and has been that for many years. Unless you are talking about Perl 6?

Frankly, I've never used them, and I've been coding in Perl since... 5.6 or thereabouts? I mean, 5.8 was probably out already, just that Debian still had an older version...

There's 100's of other examples where Perl has decided it needs its own definition for something other programming languages agree upon.

I don't really think so. The one big stumbling-block seems to be scalar/list context, which doesn't exist in other languages AFAIK. Apart from that, I can't really name any of your hundreds of examples.

Oh, maybe threads.

Re:Python is doing well, but JS is ahead.

[JasterBobaMereel]

Javascript is a web scripting language, that can be used as a general scripting language ...not really comparable

C/C++ is used in all these industries..and more
Your Python interpreter is written in C/C++ ..
The operating system you are running your Python interpreter on is written in C/C++

Reduced tool complexity = econonomic beneifts

[sjbe]

Why would we want just one programming language?

It's reasonably obvious why we have multiple programming languages but your question has a serious answer. There would be HUGE advantages if it were practically possible to consolidate on one programming language. The economic benefits would be massive. Any time you can reduce the complexity of the tooling you use to make products it reduces cost, reduces errors, makes training easier, and has lots more knock on benefits. In many cases the benefits of minimizing tool complexity (less languages in this case) can be larger than the optimization benefits from using a specialized tool. To use a non-programming analogy, think about Alton Brown's "no uni-taskers" rule. Specialized tools or specialized languages have their time and place but one should avoid them if practically possible.

Now in the real world we're highly unlikely to ever see a single programming language dominate all forms of programming and for very good reasons. But that's a different question than why we would want such a state of affairs. Having multiple languages has advantages but having a single language makes life SO much easier in many important ways.

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.

Re:Reduced tool complexity = econonomic beneifts

[oh_my_080980980]

Ummm Binary, Assembly....so no....

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:Reduced tool complexity = econonomic beneifts

[nasch]

His rule is only one single task item allowed in the kitchen: the fire extinguisher.

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.

Re:Reduced tool complexity = econonomic beneifts

[Pig Hogger]

We're only going to reduce errors if it's a programming language that makes errors harder to make.

I worked with Pascal & Delphi for at least 15 years, and despite having made to “make errors harder to make” (with enforced structure & strict type checking), there are still many ways for bugs to creep in such a language

Give Nim a chance

[sky_khan72]

If you really like your indentation this much, give Nim, https://nim-lang.org/ ,a chance. It looks and feels like python but it is statically typed and compiled language at least.

Re:Give Nim a chance

[gweihir]

How can it look and feel like Python if it is statically typed? Not being statically typed is one of the most important features of Python. Not so easy to handle, but powerful in the hands of an expert.

Re:Give Nim a chance

[sky_khan72]

It has type inference and some more. Have you seen the snippet on it's frontpage ?

Re:Give Nim a chance

[gweihir]

I know what "statically typed" means and at that time I am not interested in yet-another-niche-language. I have done real work in around 20 different languages by now and none of the "magic" languages that do the same as some of those that have proven themselves over time but "better" have ever lived up to that claim. And of course, I am quite able to embed C if I need performance.

Re:Give Nim a chance

[Pig Hogger]

Lol, I took a look at it, and it looks like the child Pascal would have had if he married Python

Re:Give Nim a chance

[sky_khan72]

Is that a bad thing ? Yes, Nim is love child of pascal family (pascal,oberon,ada) languages and python mostly but has some genes from other languages too. It also supports templates, generics and AST macros... It compiles to C/C++ and Javascript so it is easy to bind these too. IMO, It is very pragmatic. Although I have not done anything serious with it yet, I really like it.

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.

Re:I don't think so

[fluffernutter]

I don't really get what is wrong with having to do type checks manually. If you name a variables like total_widget_count and widget_count and then do something like total_widget_count += widget_count, who cares if it is int, long, double, or float when you just want to add two numbers together? On the other hand if you want to pass a parameter that can be an int or a list of ints then it performs a functional purpose to check the types, so why wouldn't you want to do it manually at that point?

Re:I don't think so

[gweihir]

The thing is that for a while strong static typing was hailed as the one true "silver bullet" that would right all wrongs with code. Of course, that is nonsense, as all the other "magic solutions" that have come before and after are, but this thing is stills strong in many people's minds. The thing that most of these people do not understand is that Python actually has strong typing in the sense that everything has an exactly defined type and that you can determine that type at run-time. It is just not a static-type (i.e. type of the variable), but a dynamic one (i.e. type of what the variable contains). The other thing these people miss is that while static type-safety determined by a compiler sounds nice, it turns out that you find basically all dynamic type-errors in any testing that deserves the name anyways, because testing for type-errors is far less difficult than testing for implementation errors. Hence what the compiler can do is not really worth much, but that is not readily obvious to most people.

Altogether, strong dynamic typing is very nice indeed, but is is not really a thing for beginners. But real-world size projects and the code that comes with them are not for beginners either.

Re:I don't think so

[david_thornley]

I tend to think of specifying lengths of integer and floating-point types as premature optimization, but there's advantages to static type checking. You mentioned a parameter that can be an int or a list of ints (which is something C++ handles well), but if somehow the parameter winds up being something else in Python something unexpected could happen, whereas in C++ if it winds up being something else that's a compile error.

Re:I don't think so

[fluffernutter]

Yes I realize that, and that's why I wouldn't use Python for a driver. I'm talking about a website back-end.

I'm puzzled

[EdZep]

I'm a hobbyist programmer. 8 or 9 years ago, I decided to check out Python, working on a Windows box. I wrote a client-server Spades card game to play on a wifi network.

I enjoyed the coding. Having the right environment to run the code seemed to be a challenge. I set up all of my family members' laptops to run the game (including a 3rd party library). But, I never distributed it further, because it seemed impractical to expect the average computer user to have or to set up the environment... and not get into a support nightmare.

That experience led me to marvel as Python became even more popular. I suspect there's something I missed, or, maybe Python has evolved. This seems like a good opportunity to have someone set me straight. What am I not getting?

Re:I'm puzzled

[fluffernutter]

You are missing something. There are packages like py2exe that will compile python in a regular executable.

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.

Re:It Depends

[fluffernutter]

Except by reading these comments, Python could never be the right tool for the job, so how the heck are people managing to get so much done with it?

Dominant?

[aglider]

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

Re:Dominant?

[BaronAaron]

FTFA

"created by analyzing how often language tutorials are searched on Google"
"The more a language tutorial is searched, the more popular the language is assumed to be. It is a leading indicator"

I don't know if I buy that personally.

Re:Dominant?

[aglider]

Pr0n is dominant in the web, then!

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:Should disallow mixing tabs/spaces

[sl3xd]

Just flag an error as soon as indentations are detected that are not the same style.

To hell with Python. EVERY language needs to do this.

In every software development project whitespace matters - regardless of language.

I'm sick of having to guide every junior programmer through fixing the merge issues they've caused by not using the project's indentation style.

Eventually, the developer starts to understand that while the language doesn't care about whitespace, the version control system does.

Then the developer moves on to greener pastures, and I get to do it all over again with the next clueless graduate.

Re:Should disallow mixing tabs/spaces

[spitzak]

I would allow tabs followed by spaces, too many programmers want to use that.

What it should enforce is:

- the indentation cannot have a space before a tab (so any indentation is m tabs followed by n spaces where either number may be zero). So space,tab would be a parsing error.

- Any change is considered an indentation change. So tab is a different indentation than 8 spaces. This will turn any mixing of characters that look like the same indentation into parsing errors

- In the few cases where it matters a different indentation can be split into whether it is an increase or a decrease by by having the number of tabs take precedence. More tabs means more indentation no matter how many spaces are lost. This removes any need to define how wide a tab is.

Re:Should disallow mixing tabs/spaces

[doom]

Time to look for a pasture of your own, eh? (Just kidding.)

When I'm in charge of a project, I set things up so that code check-ins need to pass a style-check-- this doesn't have to be done by the compiler.

Re:Should disallow mixing tabs/spaces

[stooo]

Good point. Although a warning should be enough.

Re: Clickbait is clickbait

[turp182]

I prefer to hone mastery for a specific set of tools. I could switch up, but the wideness of today's frameworks means it takes at least at couple of years to be an expert.

I am learning iSeries at a very low level, to help people get off of them. Both interesting and frustrating (regarding DB design and ancient programming practices).

Re:No, not for a long time.

[vtcodger]

Being as the world seems to be heading toward "thousands of languages but when people need to communicate, they'll use English and/or Spanish and/or Mandarin" I'm not sure defaulting to ASCII is that big a deal. Of course, you can't really write East Asian languages very well in ASCII. But are there Kanji (to use the Japanese term) based programming languages?

(BTW, A few years ago, I was treated to the spectacle of two Chinese in a Chinese take out place in Vermont struggling to communicate in different Chinese dialects then finally giving up and switching to English -- which neither spoke all that well.)

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

Wow

[fluffernutter]

I can't believe the hate for Python. Many of you people talk like a large website could never be built it in when the fact is that many large websites have been and continue to be built with it.

Re:Wow

[oh_my_080980980]

Unlike Perl.....

Re:Wow

[fluffernutter]

I'm aware of some small websites in perl but no large scale ones. Perl is a brutally messy language to do anything in, but it fills a really useful spot if you're a sysadmin and you need something more than bash or ksh.

Surrounding code blocks with brackets is very ugly. The one respite you get from them is if you can prune your block down to one statement then you don't have to put the brackets, but then inevitably you need to add one more statement temporarily so you need to surround in brackets just to add the statement and remove them again when you go back to one statement again. When you work in python for awhile you come to see how awkward brackets are.

Re:Wow

[0100010001010011]

I'm aware of some small websites in perl but no large scale ones.

I hope you're joking or you're really lacking some self awareness.

Re:Wow

[fluffernutter]

Well it's not something I have gone out to research.

Re:Wow

[0100010001010011]

(Hint, check the URL)

Re:Wow

[fluffernutter]

Slashdot is in perl? That's cool.

Re:Wow

[furry_wookie]

>aware of some small websites in perl but no large scale ones.

Ever hear of a little website called "Yahoo!"?? Yep, perl.

Re:Wow

[fluffernutter]

To be fair, these were never amazingly dynamic websites. Yahoo was a hierarchical directory and slashdot is a basic comment site. That said, there are MVC web frameworks for perl and I'm sure they work fine to create a site of any size.

Re:Wow

[Anonymous Coward]

booking.com, amazon.com, bbc.co.uk, imdb.com, duckduck.com big enough for you? ;-)

http://blog.builtinperl.com/post/5-major-websites-that-use-perl

Re:Wow

[djinn6]

Well he did say large scale. /. is not that large.

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:Overconfident bullshit

[fluffernutter]

I feel this is the strength of Python. The fact that thousands of people are out there exactly like you, saying things like "Yes Java is better for so many things, but I use Python for X and it really works for me well there". Being a jack of all trades but master of none can make you very popular, and that's why it is one of the top languages now.

Re:Overconfident bullshit

[ooloorie]

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

The thing is that if that's a Java project, you can probably rewrite it in a better designed language and cut that down to 10 classes and 10 kloc. Java is just horribly wasteful of programmer time, creates tons of unnecessary complexity, and is wasteful of computer resources on top of that.

Re:Overconfident bullshit

[H0p313ss]

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

Yup... and that's a small project. It's been a long time since I worked on any project smaller than a million lines of code.

I'm sure there's some people who can manage millions of lines of code spread across tens of thousands of files with vi, but it sure ain't me.

Re:Overconfident bullshit

[lorinc]

The thing is that if that's a Java project, you can probably rewrite it in a better designed language and cut that down to 10 classes and 10 kloc. Java is just horribly wasteful of programmer time, creates tons of unnecessary complexity, and is wasteful of computer resources on top of that.

Sure, everything can be rewritten with a sed oneliner. However, none of this is going to be maintained very long, which is the true value of some critical programs.

Re:Overconfident bullshit

[ooloorie]

Sure, everything can be rewritten with a sed oneliner. However, none of this is going to be maintained very long, which is the true value of some critical programs.

There is zero evidence that Java is any easier to maintain than other safe, statically compiled languages.

Re:Scripting, fine. What about GUI's?

[vtcodger]

Yes, Tcl/Tk is built in and there are modules for other graphical libraries. GUI code is still tedious, annoying, buggy and a general PITA, but I think no more so than in other languages.

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

Dominant but not the only language

[donbudge]

A lot of the responses have been disengenous. The author included C++ in the article to indicate there is a need for other languages in different scenarios. You don't write device drivers in Python, I'm sure. Also, the only people complaining about the whitespace are the ones who are comfortable with other languages and haven't tried Python sincerely. If you are trying to publish an article, are you going to ignore indentation? New people entering programming with Python don't have an issue. The indentation is natural to them.

Re:Dominant but not the only language

[fluffernutter]

I came from a Java background, and surrounding code blocks with brackets always seemed needlessly messy to me. Especially when you have a single statement block without brackets that you need to add another statement to. Now you have to surround with brackets just to add a line to the block. Once i found out about Python I found myself using it as much as I could, because not having to worry about brackets to add a line ever was a great feeling of liberation for me.

Re:Dominant but not the only language

[barbariccow]

You don't write device drivers in Python, I'm sure

Holy crap I wish that were true. You'd be surprised some of the awful interfaces for hardware devices I've had to deal with, thanks to the abomination that is FUSE (which allows.... that's right.... you can write device drivers in USERSPACE, in ANY LANGUAGE :(

Error reduction

[sjbe]

We're only going to reduce errors if it's a programming language that makes errors harder to make.

Error reduction is multi-factorial. It's not merely language design though you are correct that that is a significant consideration. Factors like how well trained individuals are can play a major role. It is easier to teach best practices and how to avoid problems if all the teaching can be focused on the problems with a single tool. Asking people to generalize best practices across multiple languages makes training harder and errors more likely.

Of course this is all moot because we don't live in a world with just one programming language and probably never will. But there would be benefits to it if somehow we could make it happen.

Re:Error reduction

[0111 1110]

Factors like how well trained individuals are can play a major role.

What about intelligence? Does that play any role? Is a programmer with an IQ of 78 but with more training more valuable than a programmer with an IQ of 150 but with less training?

Do more intelligent programmers make fewer careless errors? Not sure about that. But they would seem to have greater potential to write elegant and beautiful programs that I could be proud of having paid for. What I would want is clever programmers who can build beautiful and efficient machines.

Re:Error reduction

[angel'o'sphere]

"More intelligent programmers dont't make fewer mistakes, they make more intelligent mistakes."
One of my profs used to quote that, don't remember from whom he had that quote.

Re:Error reduction

[sjbe]

What about intelligence? Does that play any role?

Is this a rhetorical question? I said sources of errors are multi-factorial. I made no effort to enumerate all the factors and there are indeed many beyond simply language design. Certainly intelligence plays a role. That's not however an acceptable excuse for making or choosing programming languages that needlessly complicate a task or add expense however.

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.

It can never attain more than 50%

[guruevi]

You can't make Python the dominant language because half of it has to be implemented in C in order to get it to work properly.

That and lack of clear program structure definition (braces) will make sure it will always be a scripting language like PHP.

Re:It can never attain more than 50%

[david_thornley]

Historically, the dominant language has usually been one that can fill all roles above assembly language. At one point, Unix programmers pretty much had to be competent in C, and that created a network effect, in that people would program in C because they knew almost everyone else could read and understand it.

Since we've pretty much freed most developers from having to write in the system's language, it's questionable whether we'll ever get another dominant language. There will be popular ones, but none will be dominant.

Please do

[Danathar]

So the number of programmers in Lisp, Forth, and COBOL go down even more. Which will mean I can learn those and make a KILLING in $$$

Depends

[TheOuterLinux]

The future is more likely to be server APIs while everyone turns into over glorified interface designers. Schools are teaching Python for calculations the same way they used to teach BASIC. But, there's no money it and quite literally because of its license. So, it will be C and Python on desktop and PHP and HTML5 on servers. I wish more people liked Python because it's a whole lot easier to modify. People complain about speed with Python, but imagine having to edit or add variables in C and then recompiling it just to run it every time; it would take longer. On top of which, Visual Basic and M$ want you to use C#, which then prevents or causes problems with cross platform compatibility. Blender is all Python and it works just fine and people use it for all kinds of things, including having a built-in game engine.

Re:Dominant where?

[barbariccow]

I've never had a problem merging anything since I stopped using subverison... and cvs... and copying files to NAME_DATE_STRING..... https://git-scm.com/

Javascript?

[Zobeid]

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

Re:No, not for a long time.

[barbariccow]

For python2, if you don't set one in site.py (which you should). Python3 defaults to utf-8 (which again, can be changed with one line in a "config file")

But learning that all text isn't ASCII and that "encoded" vs "decoded" data are different is one of the BIG challenges for a lot of folks to learn python3, or change from 2 to 3.

Wasn't hard for me, having many years prior to learning python with other languages where I CHOOSE to blatantly ignore any non-ASCII encodings! bwahahaha!

Insignificance

[Roger W Moore]

F90 discarded white space significance in 1990.

F90 pretty much lost all significance. The only people I'm aware of using Fortran still in my field are older theorists who learnt F77 and still use it. If you are willing to update you programming language knowledge chances are you would not upgrade to F90 given the prevalence of C++ and Python.

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:Python is doing well, but JS is ahead.

[barbariccow]

which can bypass GC and do C/C++-level

That's exactly what we need. A larger attack surface. Didn't we have an article the other day about having to click 3 times and hover over a link that you opened in an email from a stranger which executes powershell?

As someone with horizontal nystagmus

[blind biker]

I fucking hope not

Idiot children with their idiot silver bullets

[0xdeadbeef]

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.

This is the stupidest statement I've seen on Slashdot in recent memory that didn't come from a Trump voter.

TDD is a crutch for catching duck typing errors, and test that verify you haven't fucked up your interfaces are far more useless boilerplate than even the most "enterprise" Java code that isn't also using TDD.

Old Men Yell at Clouds

[0100010001010011]

Yes. It already has in a large number of places.

Re:Old Men Yell at Clouds

[iggymanz]

no it won't, it is not a business language (lacking the needed libraries). It is hilarious to watch the data scientists make decades old newbie errors importing business data from java systems into python based analysis

Re:Old Men Yell at Clouds

[0100010001010011]

(lacking the needed libraries)

And what libraries are those?

Re:Old Men Yell at Clouds

[iggymanz]

even the infrastructure for using/transporting/persisting its Decimal class (I'll give it some credit for at least having that) around properly. But the broader answer would be the stuff java ee has that python libraries don't.

I hate Java by the way

Re:New language

[barbariccow]

If only someone could invent a new language.A derivative of Python, but using braces, that compiles to regular Python.

You already have it! Try this code out:

from __future__ import braces

If you're not aware, "__future__" contains future features and importing them changes how the file is processed.

"can't quickly refactor code, which is necessary"

[PmanAce]

IDEs allow this, usually much quicker than by hand.

No Python does not have actual threads

[Anonymous Coward]

Python threads have a global interpreter Lock which effectively means one thread can run at a time and they take turns. This is not threading in the real world .

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

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.

Re:No Python does not have actual threads

[MightyYar]

The processes/threads would need to communicate in some form or fashion. That has not been the bottleneck for me so I've never tried to "solve" it (other than trivial stuff like splitting the dataset into bigger chunks). But you are not restricted to the default pickling/unpicking - you can use whatever scheme you dream up for communication. The point is that you don't need to dig this deep unless the communication becomes your bottleneck, and when you do need to optimize communication, there's nothing stopping you (and there are many solutions floating around out there).

sometimes you want threads

[Cajun Hell]

CPU bound threa[d]s *should* be processes

When you reasonably can, totally. By all means, try to break your problem up into processes. I'm all for replacing multithreading with multiprocessing when you can, because not only does it mean you get to use python, but it means there's a whole bunch of synchronization problems that you're never going to have to deal with. Faster coding and fewer bugs. Who doesn't want that?

But when you can't, you can't. If you're creating and destroying lots of processes and having to pickle lots of stuff into several megabytes to move over pipes to depickle, that's expensive and ugly, too. Sometimes, threads are the correct answer. And cpython really does have a problem with that.

Re:sometimes you want threads

[superwiz]

If you're creating and destroying lots of processes

No. Because that's not how you treat CPU-bound tasks regardless of whether they are threads or processes. If you need CPU-bound tasks, it's because you have already have coarse granularity of data and your data can be processed by a pool of worker threads. The situation you described is that of IO-bound threads. And I specifically said that you treat CPU-bound tasks as processes and IO-bound tasks as threads.

Need to suck more

[theendlessnow]

Java is a dominant language. Python needs to suck more to make it even into the top 10.

Maybe Php?

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.

Marginal improvements are costly

[sjbe]

His rule is only one single task item allowed in the kitchen: the fire extinguisher.

Not even that. He used the fire extinguisher to make a desert.

I don't actually agree with Alton on this as a hard and fast rule even though I used it as an example. It's a good principle but there are sometimes good reasons to own and use a special purpose tool. Special tools are indicated when they save substantial labor and/or do a substantially better job than a more general purpose tool. For example I own a mandoline in addition to my knives. My knives are more general purpose tools and can do everything the mandoline can do and then some, but for some tasks the mandoline is SO much faster and accurate that it easily justifies me owning one even though I don't use it often.

Same deal with programming languages. Use the best general purpose language you can get away with and only bring in specialty languages if the net benefit to doing so is substantial either in time saved or quality of results. Don't let perfect be the enemy of good in search of marginal improvements that will probably cost more than the benefit received.

Re:Marginal improvements are costly

[nasch]

Agreed, it depends on how much better the tool is and how often you'll use it. If you make eggs for breakfast every day and you have some tool that makes that easier or better and does nothing else, that seems totally reasonable.

And I love that he made ice cream with a fire extinguisher.

Bullish on Python

[steveha]

I predict that Python, already popular, will become even more popular in the coming years. "Dominant"? Eh, you decide.

First of all, you guys moaning about white space? Just get over it, or go sulk in a corner or something. Python has always been the way it is, it's not going to change, and most people just don't care, or even like it. There are various "lint" tools for Python and any of them can complain about tabs (and most or all of them do by default). And I have been programming in Python for as long as Git has been around, and I have never had a "nightmare" merge caused by tabs and spaces. You're selling a problem I've never seen in the real world.

Those of you complaining about static typing? It's now available as an option. Python supports "type annotations" that have no meaning at runtime, but can be used by "lint" sort of tools to do static type checks. Large companies like Google and Microsoft were starting to require comments with type annotations and rolling their own static checking tools, so the Benevolent Dictator for Life ruled that Python should gain a built-in standardized way to do it.

"But both of the above suggest running a lint-like tool... it should be in the compiler." Well, sorry, but I am definitely willing to live with having the lint be optional. C used to be that way, you know, and your IDE or CI system can enforce use of the lint tools if you care.

"But the GIL! It's so awful!" Actually, spinning up multiple processes, or running code on a GPU, are both good solutions for many or most problems. Also, there is a serious project to remove the GIL, called "the GILectomy", being run by a Python core developer named Larry Hastings. Check YouTube for his lectures on it and how it's doing. He has made progress recently so there is hope. I'll say it again, multi-process is not bad at all in Python, and I have a bunch of production code that spins up about 30 processes at a time to do embarrassingly parallel tasks, so I personally don't care that much about the GIL, but you can't say nobody is working on it. It just turns out that the GIL is a really efficient way to solve a bunch of problems, and every attempt so far to remove it has made Python really slow.

With the major complaints mentioned, let me now mention some reasons for increased growth of the language.

The major growth area is in sciences. If you are studying astronomy, and probably most other sciences, Python is the single best language you can learn. SciPy is great: you can write pleasant Python code and it runs at FORTRAN speed, because the guts of SciPy are old (well-understood and well-debugged) FORTRAN libraries. I was able to go to the SciPy conference a few years ago and I learned that scientists who are abandoning wacky or proprietary languages are all converging on Python to gain the benefits of SciPy. For example, all the people working on the data from the Hubble space telescope all use Python now (instead of IDL, the original language when the Hubble first launched).

I would go so far as to say that for the sciences, Python will "dominate". It's achieved first-mover advantage, and it's still improving so it will be difficult to displace. (For example, a library called Pandas offers data frames, an idea copied from R. If Python successfully copies all the best parts of it's competition it will continue to dominate in science.)

Also, as a Python developer and as someone who has gone to the Python conference for years, I am seeing signs that the split between Python 2.x and Python 3.x is finally about to end, with most people finally moving to Python 3.x. The latest release of Python 3.x has much more excitement around it than any previous release. It now uses less memory, yet runs faster, than Python 2.x; and it has some nifty new features for async code, as well as a new language hook that PyCharm uses for debugging 50x faster than previous Python versions. My own company has started the switch to 3.x and we are far from alone.

So Python is a

restrict in C99

[tepples]

Is Fortran faster than C99, when C gained the restrict pointer qualifier? A lot of Fortran optimizations that C used to lack are based around different aliasing rules, and the restrict qualifier hints to a C compiler that pointers passed as arguments do not point to overlapping memory.

Re:restrict in C99

[serviscope_minor]

Is Fortran faster than C99, when C gained the restrict pointer qualifier?

I believe so. The difference is less, of course, but I seem to remember reading that FORTRAN is still a bit stricter in some places. I don't know it well enough to regurgitate what I read, but it sounded right at the time.

Re:restrict in C99

[shutdown -p now]

It is, because real world C compilers never learned to fully utilize the power that restrict gives them, and the popular libraries generally haven't picked up its use (I don't know if one of these is the cause and another is the effect, or if it's concurrent and unrelated).

Re:restrict in C99

[tepples]

Have you or anyone else in your organization filed bugs against GCC and Clang about obvious optimizations that aren't getting applied to output compiled from source code that correctly uses restrict?

Re:restrict in C99

[shutdown -p now]

No, but then I (or anyone I know directly) am not using gcc for things where it would matter.

And from what I've seen, the people who do care are mostly already using Fortran for those scenarios, and they don't really see any particular reason to switch.

You Get What You Pay For

[AnalogDiehard]

My assessment of python is "you get what you pay for". And I don't mean that in a good way.

I've been a systems engineer for 25+ years with experience in many software languages including modern ones like C#. I do not have a high opinion of python for many reasons already stated.

I'll add that online references are a PITA, in that many are downright wrong. I actually ran into a simple code segment that our interpreter couldn't execute.

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.

Re:Static vs Dynamic

[samwhite_y]

I realized I have a bit more to say on this topic. Since static languages tend to be associated with large projects, they also tend to have the following characteristics when compared to dynamic languages.

* Significantly longer class names and method names with the class and method names providing a bit of documentation as to their usage.
* Deeper name-spacing nesting. Typical dynamic project might go two deep, a typical mature Java package may be 6-10 deep in nesting package name-spacing.
* More investment in boiler plate classes for serialization and logic and some of the classes and variables may exist only to improve the structure and readability of the code.
* More investment in providing structured interface points between modules with declared interfaces providing a declarative model for interaction.
* A general design goal of limiting and validating what is allowed when using an API instead of adding flexibility and forgiving small defects in using an API.

I point this out because the debate between dynamic and static is not just a difference in choice of languages, it is also a choice between the general approach to writing code. In the old days, it was a debate between Perl (dynamic) and Pascal (static). Today it appears to be between Python and Java.

Re:Static vs Dynamic

[Pseudonym]

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.

This is a crude way of saying that the compiler doesn't accept code with certain classes of bug still present. Those "up-front costs" are, in reality, costs shifted from later in the development cycle.

Re:Static vs Dynamic

[Pseudonym]

Deeper name-spacing nesting. Typical dynamic project might go two deep, a typical mature Java package may be 6-10 deep in nesting package name-spacing.

That's very much a Java thing. I've never seen that level of nesting in C++, or Haskell, or ML, or pretty much any other statically typed language designed for large-scale.

Re:Static vs Dynamic

[djinn6]

I wish Python would give you the option of specifying types and let me omit that information only when I want to

Does this do what you want?

Re:Static vs Dynamic

[samwhite_y]

Good point. I have not done C++ coding in the last decade. But it does make me wonder what a C++ project looks like when in brings in 100s of open source libraries into its build and 10s of libraries produced by others in the organization.

Re:Static vs Dynamic

[Pseudonym]

Good point. I have not done C++ coding in the last decade. But it does make me wonder what a C++ project looks like when in brings in 100s of open source libraries into its build and 10s of libraries produced by others in the organization.

In most programming languages, namespaces are somewhat independent of filesystem directories.

C++ libraries are usually very good about using a distinguishing top-level namespace, with nested namespaces only if needed (e.g. if it's a big library with major subsystems, or following Boost, a "detail" nested namespace for implementation-specific detail which clients should not use). So, for example, suppose you want to use cpp_redis in your project. The top-level namespace is cpp_redis. In Java, that would have to be be org.cylix.redis or something.

Now to be completely fair to Java, there was a good reason for this design decision. Java was designed for grabbing possibly untrusted code and all its dependencies from across a network and running it locally on the same VM. Tying the namespace system to DNS makes names globally unique by default. In a language like C++, you can control all your dependencies and their namespaces at compile time. In Java, you can't.

the snake will die

[doom]

Programmers will get bored and jump on some other fad. They need an exuse to re-write the standard libraries every few years, because they've got no ideas but they like to feel like they're doing something.

I mean-- in today's multiprocessor big dada cloudy future one must choose a language that optimizes the resource functionality-functionalism tradeoff to reduce downtime and maintenance costs while maximizing stock market confusion and venture capital infusion.

Re:the snake will die

[sl3xd]

Programmers will get bored and jump on some other fad

I agree with the sentiment in general, but Python is well past the point of being a fad -- maybe it would have been considered a fad in 2000, but since then we've already seen a number of fads come and go since then (PHP, Ruby on Rails, Groovy & Grails, Node.js, golang, and Scala to name a few).

Even Perl seems to have finished its time in the sun, and is on its way into obscurity.

Re:the snake will die

[doom]

Even Perl seems to have finished its time in the sun, and is on its way into obscurity.

Eh. It went from being the one language to being one of a bunch of languages, but the news of it's death has been greatly exaggerated.

Shortlived, if ever

[sdinfoserv]

1960 question: "will COBOL become the dominant programming language"?
1965 question: "will RPG become the dominant programming language"?
1970 question: "will FORTRAN become the dominant programming language"?
1975 question: "will BASIC become the dominant programming language"?
1980 question: "will C become the dominant programming language"?
1985 question: "will Clipper become the dominant programming language"?
1990 question: "will Visual Basic become the dominant programming language"?
1995 question: "will ColdFusion become the dominant programming language"?
2000 question: "will C++ become the dominant programming language"?
2005 question: "will PHP become the dominant programming language"?
2010 question: "will Java become the dominant programming language"?
2015 question: "will Ruby become the dominant programming language"?
The answer is wait a while, and it will change......

News of our death

[drolli]

are highly exaggerated.

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.

Programming languages should ban tab characters

[presidenteloco]

from source code files.

i.e. Should not parse.

Problem solved.

Language

[DrYak]

I don't want to write a {...complex...} algorithm {...} in any kind of shell script.

Yup, that's why I put in parenthesis in my answer.
In your specific case - I suspected - you need at least some more advanced logic available.
(Whereas I've seen bioinformatics pipelines where all the "gluing" could be handled in bash, specially given its support for native regex, arrays, hashes, integer math and filtered expansion of variables [ NOTE: this monster even has a functionnal tcp/ip lite stack ]).

But over all, python just happens to be the current popular language to glue such things together.
Move a few years back, and the exact same could be said of Perl, Java (though JNI seem to be a mess to get right in a portable manner), .NET, VisualBasic, Lisp, Lua, etc.
Move a few years into the future, and maybe Ruby or Javascript will get popular traction. Or something else (Go or Rust - though the later is really more system-oriented and less likely).

Heavy lifting is done with a low level language (C/C++ mostly. Or FORTRAN in your situation as for other engineer and physicists. Or assembler a couple decades back),
and the higher level language "du jour" is used for the glue and control.

Hell

[DrYak]

But if there is anything other than trivial logic involved, shell scripting is the road to eternal damnation.

Meanwhile, somewhere, some devil is abusing bash' "/dev/tcp/" virtual device to implement a fully functionning web server...

Not rusty enough

[hackel]

Python just isn't rusty enough for my taste...

Actually, I've only played with Rust so far, but what I've experienced already really makes me want it to take off...

Python as Dominant Language

[Slicker]

Python is becoming the dominant "Academic" language. It's clear as it adheres to how a human most ideally likes to model his/her designed processes. However, Python suffers the same ills as Java. It's really just Java 2.0 -- conventional Object-Orientation has failed in its goals. The wikipedia criticisms are very high level summary (https://en.wikipedia.org/wiki/Object-oriented_programming#Criticism) -- there is plenty else well documented.

However we are faced with a dilemma: we now have a generation of programmers trained and habituated in that one method of framing problems: OO. Most of them struggle (usually cannot) frame problems or design solutions in non-OO ways. This hinders their ability to think differently or to see solutions or more efficient design potential. They often don't understand or even think much about OO modeling for its fundamental limitations to size and performance. I am speaking from experience working with so many people over the decades and also having been an OO evangelist in the early 2000s.

I like the string and array functions in Python and the clear readability is nice. It does hit some of my pet peeves with its less conventional use of certain characters and terms, worse than Pascal did back in the 1980s but those are superficial things.

That said--Javascript's object model is true to the machine and I predict it will be (and is already becoming) the new C language. Python cannot be a systems language--it is functionally incapable for the same reasons as for Java. Javascript is much closer.

Python's standard documentation is incomplete and could be greatly improved. For example, it doesn't explain how to extract and translate text in strings but just finding patterns (or at least it didn't last time I tried to use them). This doesn't matter to most python developers because they focus on broad high level logic using libraries built for them and just accepting the limitations perpetually found within those libraries. This is the problem with C# and .Net. Regular expressions not only reduce hundreds of lines of code for pattern identification, extraction, and replacements/reogranizations, but also enable dynamic pattern building. To do this without regular expressions requires that you practically reinvent regular expressions. Regular expressions are one example of a computationally complete tool (Turing Complete for idol worshipers). Nearly all OO library objects or systems of objects I've come across have clearly not taking computational completion into account or even show any awareness of its importance.... they just ad hoc for a select set of use cases that its builders thought most useful or likely.

I think UnIx small tools and pipes are a more promising start for a solution to the problems for which OO was envisioned and the problems OO created. I've put a fair amount of thought to this over the years. It seems to me that providing a singular stream through each for data and control would be the best improvement, instead of data and error. Data would be pure data on which operations occur. Control would be a sectioned stream with parameters, history, and results (including errors). If one tool in a chain recognizes an error from a prior tool then it can try to intelligently accommodate... or use parameters to know how to behave on such contingencies. Intelligent behaviors could include seeking other tools to cure the problem or even computing process flows between sets of tools to cure problems. Intent could be issued.

to be an expert

[Dareth]

Used to be you needed 20 years of daily use to be an expert. What is that in "IT Years"?

Re:to be an expert

[turp182]

I've read 10,000 hours to be a master on an instrument.

That's about 5 years.

IT is more complicated, there is more to know to be fully rounded.

With regards to IT, using my MS focus:
1. C#, 1 year
2. .Net Framework, 2 years
3. SQL/SQL Server, 2 years
4. UI environment of preference, 1 year (optiional depending on):
5. Specialty, service frameworks, ORM, ETL - 1 year at least per

Assume 50% learning time while actually using the techs (learning and not using doesn't count), that's 12-14 years.

I'm at 17 years of this, with 2-3 years of iSeries analysis and conversion experience.

That's my 3 cents.

good tools

[Dareth]

Real programmers don't even need input tools like keyboards. I'm typing this post right now with nothing but my tongue, a couple wires, and a 9 volt battery.

Yes...

[spongman]

...as soon as they finish rolling out Python3.

Multi-processing != threads

[goombah99]

it's closer to a fork and copying the program several times in memory.

Re:Multi-processing != threads

[MightyYar]

Not the entire program - only the portion that needs to chew on the data you are going to pass it. I mean, it depends on how you do it, but it need not run the entire program in every process.

Re:Multi-processing != threads

[MightyYar]

I never disagreed - even called it a wart. But it's not exactly crippling.

Re:Python is doing well, but JS is ahead.

[K. S. Kyosuke]

It's not an attack surface to any greater extent that rented VM instances on hypervisors are in data centers already are.

Re:Python is doing well, but JS is ahead.

[K. S. Kyosuke]

Your Python interpreter is written in C/C++ ..

Unless he's a PyPy user...

Windows license required?

[tepples]

Would it be enough to build said executable with MinGW and test it in Wine? Or are a Windows license and a PC with enough RAM to run Windows in VirtualBox in Linux required?

Re:Windows license required?

[Opportunist]

What? You don't tell me gcc still can't cross-compile for Windows!

Re:Windows license required?

[tepples]

build said executable with MinGW

What? You don't tell me gcc still can't cross-compile for Windows!

It can. That's why I mentioned MinGW. The problem comes when someone who primarily uses GNU/Linux and doesn't regularly use Windows tries to distribute a Windows executable built with cross-MinGW that has been tested only in Wine, not in Windows. It may inadvertently depend on implementation-defined, unspecified, or undefined behavior that differs between Wine and Windows.

No. Heck No.

[WillAffleckUW]

Not going to happen.

Now, go back to using Algol like a good sheep.

Baaaaaaaah.

No and not ever

[rhyous]

Look, python is a hybrid of a scripting language and a programming language. It is a scripting language first. No scripting language has ever become highly used and stayed highly used except one. Javascript.

Why? Not because it is an awesome scripting language. JavaScript is about the worst language out there. Javascript is only popular because it happens to have a monopoly. There is no other option for coding in the browser today. Even TypeScript compiles to JavaScript.

However, that is about to change. With WebAssembly, JavaScript will no longer have a monopoly and you will see TypeScript compile to WebAssembly instead of JavaScript, then you will see Java and C# and other languages soon be able to compile to JavaScript. Even Silverlight could make a return by compiling to WebAssembly. By I digress, this isn't about JavaScript.

The top programming language is Java. It won the Android App market. The next are C#, PHP, and C/C++ (not really in that order, just as a group). Python, Ruby, etc, isn't even in the ballpark. In Enterprise, the top two options Java and C#.

But Tiobe says python is getting huge? OK. Tiobe's algorithm is quite complex, but that doesn't mean it isn't extremely naive.

Java, C#, PHP, and others have very advanced documentation. Also, they have tools that help developers get word done with less Google searches. For example, Java and C# users Google search far less that devs for other languages. For example, the initial search might be on Google but from then on, the search is on MSDN or we are browsing the docs. Also Visual Studio's tools and add-ons allow for looking at a library, its methods, and what it does without a google search. Some VS tools will decompile dlls, so we don't even need to google what a library does, we just read it. Also, NuGet packages are searched for in Visual Studio.

Python only the other hand, is primary being used in academia, especially by students in their early college years. The early college years are the highest peak of google searching a language will get. That makes its supposed popularity extremely skewed. It only looks popular because it used by new students that have to Google search for every little step. Also, the tooling for python is sub par, which causes more google searches than Java or C#.

Also, WordPress alone leads to more PHP development than Python will ever see.

As soon as Academia moves on from it's current favorite language, and Academia always moves on, Python's inflated hype will be long forgotten.