The history of computer programming is in part the history of moving away from bit flipping a la "Add S to T if T0=1 (multiply step)". More people get more done faster when working at a higher level of abstraction. For what applications is such register-centric work still worth the investment in development (both in training the programmer and in developing the programs)?
Your objection is that you find it harder to read without the braces, so others who find it easier to read without the braces should not talk about readability? Hhmm...
Re:What is *your* idea of Python and its future?
on
Ask Guido van Rossum
·
· Score: 2
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
Twenty years ago, many of the tasks that Python is used for currently had to be done in entirely in C because the hardware they ran on was so much slower. Now, Python is used in very computationally demanding applications (bioinformatics, high-end animation, and many more) as a glue for software written in C, et. al. With hardware speeds doubling every 18 months or so, five years from now, programmers will have 10 times as much computing power available to them. With the "performance issue" an order of magnitude less important, what applications do you think Python will be used for then that it might not be now?
The story of big-time pro sports since the late 70s is that salaries have grown much faster than inflation, and there has been constant pressure on revenues to catch up. Anything that any of the big sports leagues can touch, they will charge a big premium for.
babbage writes: "the thing I like most about Perl (for one) is that it is *intentionally* messy, just like human languages. You can tell that a linguist came up with it. Complex problems simply don't always map well against simplistic solutions."
This misleading analogy (from a linguist, who should know better) needs to be buried once and for all. That the English word "language" is used to refer to both English and Perl does not make them examples of the same thing. Computer languages control Turing machines; human languages are a very different animal.
I work for a small technical shop. When I evaluate potential new hires, a key factor is how much management/training they will take, socially and technically. We routinely hire people whose technical skills require intensive triage, because once we've taught them how to code, they kow how. But a person who doesn't know how to:
deal graciously with others of diverse personalities and backgrounds
take responsibility for getting work done
keep turmoil in their personal life out of their work life
understand the business problem a technical task is meant to solve and see their craft as a means to that end
is worthless for our business. And such knowledge has a strong positive correlation with age.
Some businesses need technically brilliant people so much that they can afford to tolerate poor social engineering and personal maturity. Most would rather hire competent grownups.
There is no rule. My current favorite programming guru, Martin Fowler, argues that the best way to deal with legacy code is to start rewriting as soon as possible--that you rewrite it in order to understand it. Fowler argues that the paradigmatic programming activity is refactoring, which he raises to something not far from a methodology. His version draws somewhat on Extreme Programming (XP), mainly in the emphasis on testing and continuous improvement. His choice of examples seems to fit the scenarios I encounter: a mix of manageable and mightmare legacy code with regular start-from-scratch projects.
You might pay particular attention to his habit of writing unit tests before he does anything.
Slashdot Mirror
The long thread starts here and continues well into August.
The history of computer programming is in part the history of moving away from bit flipping a la "Add S to T if T0=1 (multiply step)". More people get more done faster when working at a higher level of abstraction. For what applications is such register-centric work still worth the investment in development (both in training the programmer and in developing the programs)?
Your objection is that you find it harder to read without the braces, so others who find it easier to read without the braces should not talk about readability? Hhmm...
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
If you could ask the Open Source community for one contribution to Python's continued development, what would it be?
With Computer Programming For Everbody on the back burner, what is your sense of the current state of Python in education?
Twenty years ago, many of the tasks that Python is used for currently had to be done in entirely in C because the hardware they ran on was so much slower. Now, Python is used in very computationally demanding applications (bioinformatics, high-end animation, and many more) as a glue for software written in C, et. al. With hardware speeds doubling every 18 months or so, five years from now, programmers will have 10 times as much computing power available to them. With the "performance issue" an order of magnitude less important, what applications do you think Python will be used for then that it might not be now?
For a great short piece on this issue as it applies to Amazon, see this NYT article.
This misleading analogy (from a linguist, who should know better) needs to be buried once and for all. That the English word "language" is used to refer to both English and Perl does not make them examples of the same thing. Computer languages control Turing machines; human languages are a very different animal.
- deal graciously with others of diverse personalities and backgrounds
- take responsibility for getting work done
- keep turmoil in their personal life out of their work life
- understand the business problem a technical task is meant to solve and see their craft as a means to that end
is worthless for our business. And such knowledge has a strong positive correlation with age.Some businesses need technically brilliant people so much that they can afford to tolerate poor social engineering and personal maturity. Most would rather hire competent grownups.
You might pay particular attention to his habit of writing unit tests before he does anything.