What is simple and clear about Python? Overloading, decorators, coroutines, dynamic typing, strong reliance on exception handling for control flow, a boatload of basic types, deep class hierarchies, eval, massive standard library, schism between 2 and 3, eggs vs wheels, pip vs setup vs easy install... it's really a pretty complex language with a deep ecosystem.
* Overloading: Is this a reference to default values for arguments? Or PEP 3124? If the former, then I think that this is itself a great example of simplicity and clarity in python.
* Decorators: I grant that they're hard on a debugger; I wish that there were a slightly more sane way for the control flow to play out. However, syntactically they're super clear.
* Coroutines: What's the problem here? I prefer Twisted's deferred model, but I have no problem with coroutines.
* Dynamic typing: I mean, if this is a religious issue, then I don't want to offend, but seriously: especially for newcomers, the type system in Python is simple. And clear.
* Exceptions as part of control flow: And why not? Exceptions are a part of ordinary human logic. Why do you regard them as unclear or complex?
* Boatload of basic types: I can do with a few fewer exposures of "low level concepts" in types (ie, int, float, double, decimal), but it's not that bad.
* Deep class hierarchies: I'm not even sure what to say to this. It seems like an objection to OOP generally.
* eval: I think we all agree that eval introduces opacity and complexity, but do you prefer it be removed?
* Massive standard library: Compared to other languages of a similar age, Python does an awfully good job at providing One Obvious Way to use the standard library to do what (and only what) you want.
* schism between 2 and 3: Hear hear.
* Eggs vs wheels: Yeah. Fuck.
* pip vs setup vs easy_install: Yeah we get it. Packaging is a problem.
Overall, I think Python is simple and clear. If I had to pick an objection, none of the ones you raised makes my list. I'll probably go with the syntax for the "type hints" system. And the GIL. And the varying definitions of "is" across implementations.
But all in all, it's pretty darn simple and clear.
It's a bit of cognitive load. It's not clear whether or not [1,2] + [3,4] should equal [1,2,3,4] or [4,6].
Keeping track of that, (oh wait, this is a numpy array, not a python list...) and things like that expand the amount of the language that a programmer must keep in her head at any one time, and are the definition of complexity.
There's no known silver bullet for the complexity / power tradeoff, which is why we get so many cool languages!
Is there some language where [4,6] is the output? That strikes me as serving some use case that I've never come across. Whereas having two lists and wanting to end up with one list with all the elements is a very common need.
I believe it would be in Matlab, as [1, 2] + [3, 4] would be considered matrix addition, in which one adds elements in corresponding places. Numpy (as mentioned in the GP) probably does similar.
I've used Nim, for a period of a few months. I didn't feel it was semantically that clean, just extremely terse. It has an enormous number of features. Some make good advertisement but are not implemented in a comprehensible, well-documented way(e.g. "parallel"). I was able to trigger a compiler regression the first time I used Nim because my first code, as one might expect given the large featureset, strayed from the idiomatic path. Plus the community had developed a careless attitude towards each other where any nastiness got a pass. I saw several flame wars go down in that IRC, bitter arguments that my friends looked at and shook their heads at. One said, "somebody should have been banned long before it got there."
I do have one good thing to say about it, though: it made systems type stuff fun. It has a featureset of "gradual affordance" that lets you implement something now and optimize later. That part is admirable, and most like Python. The next time I feel inclined I'll be looking at D, though - it's a more mature ecosystem, in several respects.
Plus the community had developed a careless attitude towards each other where any nastiness got a pass. I saw several flame wars go down in that IRC, bitter arguments that my friends looked at and shook their heads at. One said, "somebody should have been banned long before it got there."
Thank you, it's good to be warned. My main reason for liking Python was that the community was so friendly; having used other languages where you say anything and get shot down it's a deciding factor for future choices.
Of course there are blunders in Python. It's an old language by now. But a great deal of what makes Python really easy to use is that a lot of thought has gone in to getting many of the essential details right.
For instance, take comparison operators - by having < and == work across all the built-in types (including sequences), it's really easy to compare and sort stuff. Which is essential to writing terse and efficient algorithms.
Python language (ditto Perl, Ruby..) uses Babylonian approach, while the languages with more fundamental building blocks (like say Scheme, Haskell..) are more like Greek approach.
So Python it is not simpler as a language per se, but it is simpler to mold onto the problem. At least that's my explanation why people (myself included) like to use it, despite well understanding there are more elegant (mathematically) languages out there.
You really could make such a list about every language out there. I think Pythons simplicity is as much about the code written by the community as it is the language itself. How many other languages have as broadly revered third party libraries as sqlalchemy or requests?
Comments
What is simple and clear about Python? Overloading, decorators, coroutines, dynamic typing, strong reliance on exception handling for control flow, a boatload of basic types, deep class hierarchies, eval, massive standard library, schism between 2 and 3, eggs vs wheels, pip vs setup vs easy install... it's really a pretty complex language with a deep ecosystem.
* Overloading: Is this a reference to default values for arguments? Or PEP 3124? If the former, then I think that this is itself a great example of simplicity and clarity in python.
* Decorators: I grant that they're hard on a debugger; I wish that there were a slightly more sane way for the control flow to play out. However, syntactically they're super clear.
* Coroutines: What's the problem here? I prefer Twisted's deferred model, but I have no problem with coroutines.
* Dynamic typing: I mean, if this is a religious issue, then I don't want to offend, but seriously: especially for newcomers, the type system in Python is simple. And clear.
* Exceptions as part of control flow: And why not? Exceptions are a part of ordinary human logic. Why do you regard them as unclear or complex?
* Boatload of basic types: I can do with a few fewer exposures of "low level concepts" in types (ie, int, float, double, decimal), but it's not that bad.
* Deep class hierarchies: I'm not even sure what to say to this. It seems like an objection to OOP generally.
* eval: I think we all agree that eval introduces opacity and complexity, but do you prefer it be removed?
* Massive standard library: Compared to other languages of a similar age, Python does an awfully good job at providing One Obvious Way to use the standard library to do what (and only what) you want.
* schism between 2 and 3: Hear hear.
* Eggs vs wheels: Yeah. Fuck.
* pip vs setup vs easy_install: Yeah we get it. Packaging is a problem.
Overall, I think Python is simple and clear. If I had to pick an objection, none of the ones you raised makes my list. I'll probably go with the syntax for the "type hints" system. And the GIL. And the varying definitions of "is" across implementations.
But all in all, it's pretty darn simple and clear.
For any given line it's hard to know if it will raise and if so what type of exceptions.
I do like in Go that if an error can occur there will be a return value for it. Makes you much more aware of when things might go wrong.
With python it seems to be more like "find out at runtime" our "read the docs and source for every function you call"
Overloading means that + does this: [1,2] + [3,4] == [1,2,3,4] and this: 1 + 2 == 3
What is the problem with that? Number + Number = number list + list = list str + str = str
It's a bit of cognitive load. It's not clear whether or not [1,2] + [3,4] should equal [1,2,3,4] or [4,6].
Keeping track of that, (oh wait, this is a numpy array, not a python list...) and things like that expand the amount of the language that a programmer must keep in her head at any one time, and are the definition of complexity.
There's no known silver bullet for the complexity / power tradeoff, which is why we get so many cool languages!
Is there some language where [4,6] is the output? That strikes me as serving some use case that I've never come across. Whereas having two lists and wanting to end up with one list with all the elements is a very common need.
I believe it would be in Matlab, as [1, 2] + [3, 4] would be considered matrix addition, in which one adds elements in corresponding places. Numpy (as mentioned in the GP) probably does similar.
Ah, ok, thanks. Right, matrix math is is the use case I was looking for.
Yes, python.
we are talking about Lists, not arrays from an unrelated library which has to be installed first. what you've done there is simply dishonest
In [1]: a = [1,2]
In [2]: b = [4,5]
In [3]: print(a+b)
Out [1, 2, 4, 5]
Is there some language where [4,6] is the output?
Yes. Python:
For extra fun: but, of course:In R:
[1] 4 6
[1] "array"
I think you just made GP's point for him.
Python's syntax is simple and clear. But that's about it.
If you put the syntax on top of well-thought-out semantics, you get something like Nim ( http://nim-lang.org/ ).
I've used Nim, for a period of a few months. I didn't feel it was semantically that clean, just extremely terse. It has an enormous number of features. Some make good advertisement but are not implemented in a comprehensible, well-documented way(e.g. "parallel"). I was able to trigger a compiler regression the first time I used Nim because my first code, as one might expect given the large featureset, strayed from the idiomatic path. Plus the community had developed a careless attitude towards each other where any nastiness got a pass. I saw several flame wars go down in that IRC, bitter arguments that my friends looked at and shook their heads at. One said, "somebody should have been banned long before it got there."
I do have one good thing to say about it, though: it made systems type stuff fun. It has a featureset of "gradual affordance" that lets you implement something now and optimize later. That part is admirable, and most like Python. The next time I feel inclined I'll be looking at D, though - it's a more mature ecosystem, in several respects.
Thank you, it's good to be warned. My main reason for liking Python was that the community was so friendly; having used other languages where you say anything and get shot down it's a deciding factor for future choices.
Of course there are blunders in Python. It's an old language by now. But a great deal of what makes Python really easy to use is that a lot of thought has gone in to getting many of the essential details right.
For instance, take comparison operators - by having < and == work across all the built-in types (including sequences), it's really easy to compare and sort stuff. Which is essential to writing terse and efficient algorithms.
Here's a helpful video from Feynman that kinda explains it: https://www.youtube.com/watch?v=YaUlqXRPMmY
Python language (ditto Perl, Ruby..) uses Babylonian approach, while the languages with more fundamental building blocks (like say Scheme, Haskell..) are more like Greek approach.
So Python it is not simpler as a language per se, but it is simpler to mold onto the problem. At least that's my explanation why people (myself included) like to use it, despite well understanding there are more elegant (mathematically) languages out there.
You really could make such a list about every language out there. I think Pythons simplicity is as much about the code written by the community as it is the language itself. How many other languages have as broadly revered third party libraries as sqlalchemy or requests?
The offside rule. Just like futbol's.