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