On 27.01.2016 12:16, Nick Coghlan wrote:
On 27 January 2016 at 03:35, Sven R. Kunze <srku...@mail.de> wrote:
I completely agree with INADA.
It's like saying, because a specific crossroad features a higher accident
rate, people need to change their driving behavior.
No! People won't change and it's not necessary either. The crossroad needs
to be changed to be safer.
Umm, no, that's not how this works
That's exactly how it works, Nick.
INADA uses Python as I use crossroads each day. Daily human business.
If you read his post carefully, you can discover that he just presented
to you his perspective of the world. Moreover, I can assure you that
he's not alone. As usual with humans it's not about facts or
mathematically proven theorems but *perception*. It's more about
marketing, little important details (or unimportant ones depending on
whom you ask) and so on. Stating that he has a wrong perspective will
not change anything. Believing that Python is treated unfair will not
change that either.
Most people believe what they see. When they see a "FUNCTION CALL", it's
the same in every language. Why? Because it looks like a function call (
name + parentheses ), it's called "function call" even if it's
implemented completely differently. It even doesn't matter if we use
commas, 'def', return types, etc. Because people understand the bigger
concept, so that is what people want to compare.
Average Joe doesn't care and does not understand. He looks at the
benchmarks. That is something he can understand. "While performance is
not a matter when choosing first language, slowest of three makes bad
impression and people feel less attractive about Python." << just like that
Not saying that INADA is an Average Joe, but I think you get the idea.
- developers contribute to
community driven projects for their *own* reasons. Nobody gets to tell
them what to do unless they're paying them.
Bit off-topic.
Micro-optimising a poor algorithm won't deliver macro level
improvements because macro level code uses things like space-speed
trade-offs to improve the algorithmic efficiency (as in the example of
applying functools.lru_cache to a naive recursive fibonacci
implementation).
I completely agree, Nick. :) But that isn't the issue here.
Victor's work on FAT optimiser is interesting because it offers
opportunities to speed up even code that is already algorithmically
efficient, as well as making CPython a better platform for
experimenting with those kinds of changes.
Exactly. :)
More generally though, much larger opportunities for improvement lie
in persuading people to *stop writing code*, and instead spending more
of their time on finding and assembling code other people have
*already written* into solutions to interesting problems. *That's* the
kind of improvement that turns enormously complex problems like facial
recognition into 25 line Python scripts:
https://realpython.com/blog/python/face-recognition-with-python/
Interesting post. :) Thanks.
Btw. I completely agree with you on the "improve programming education",
but not everybody can do it; and not everybody wants to learn and to
practice it properly.
Best,
Sven
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
