A bite of Python

The phrase "increasingly ubiquitous" doesn't make sense. Something is either ubiquitous or not. There's no such thing as increasingly infinite, for example.

It's best to avoid passive voice, but sometimes that requires difficult thinking about who is taking action. In this case, who is causing Python to be deployed in more computing environments? How about this revision:

"With increasing frequency, software engineers and system administrators are choosing Python, because the language is easy to learn and productive for developing large, complex applications."

I'm not sure that's how I'd explain Python's popularity.

>That's why the need for assertions to check that invariants hold. >No, you need proof.

You might need proof, but it doesn't mean you'll get it. In most languages in common use (e.g. not Coq and co) and for any larger than trivial program "proof" is impossible.

So, we'll continue to need all the tools we can realistically use, including assertions, unit tests and others.

>So you're saying humans are fundamentally incapable of establishing the logical validity of what they assert by themselves? This contradicts historical evidence that people have done this for well over 2 millennia, using various methods and tools.

This particular question is not even wrong in the context of the discussion. I don't usually throw around the term "troll", but you're either trolling or being alternatively naive on principle / too pedantic.

I any case, whether people are "capable of establishing the logical validity of what they assert by themselves" for trivial things or for narrow domains, the absolutely have not been able to manually do it, or do it fast enough to be practical, for software programs, especially any non trivial one. Even the best programmers introduce bugs and have behavior in their program that they didn't expect.

Which is also why even the best programmers use assertions. It's not some obscure feature relegated to newbies or bad programmers. It's a standard practice, even in the most demanding and hardcore programming environments, from the Linux kernel (which uses the BUG_ON assertion macro) to NASA rocket code.

Or I could turn "troll mode" on an answer on the same vein as the question: if "people have done this for well over 2 millennia, using various methods and tools" then they haven't been doing it "by themselves" any more so than when using assertions (which is also one of such "tools").

And of course, I haven't anywhere stated that "humans are fundamentally incapable of establishing the logical validity of what they assert by themselves".

The gist of my comment would be merely that humans are bad at establishing the logical validity of their computer programs by themselves -- for which there is ample "historical evidence".

>Some errors might be easier to fix or have less disastrous consequences than others, but a correct program is one that has no errors, so I don't see where the spectrum is.

The spectrum is obviously in that correctness is not black and white, and all non trivial programs have bugs in practice. Those programs with few and far between bugs are more correct than others.

Or, in other words: http://chem.tufts.edu/answersinscience/relativityofwrong.htm

As someone who works in support, customers (at least the ones I support) REALLY need a clear and obvious crash to understand something's wrong. That really forces them to "do something differently" and/or look for help. You're correct in that it's not a good user experience. Neither is chaos.

You can find explanations for both those questions in the design FAQ.

The explicit self came from Modula-3. https://docs.python.org/2/faq/design.html#why-must-self-be-u...

The explanation for len is a little lacking. https://docs.python.org/2/faq/design.html#why-does-python-us...

Guido once explained further in an email to the mailing list. I've forgotten some of it, but the gist is that he didn't want anyone to accidentally create or override a .len() method to do something other than tell the number of elements in the container.

And... almost everything is a method. Even ``len(obj)`` is just sugar for ``obj.__len__()``.

I'm inclined to agree that python isn't the "clearest and friendliest". I've been using it a while, and I still find myself looking up how to do X, when it should be obvious. I like python, but I'm amazed at how people love it.

I have to maintain a codebase of php/perl/java/python. "Pythonistic" programming seems to encourage finding the shortest/fastest way to code things at the expense of clarity.

Plus dependencies can get headachy. This might just be the code I have to work with, but while better than perl, in my case its harder to maintain than java or php, (the global scope thing in python seems to get me).