4 ms·
Raymond Hettinger, if I remember correctly, is the person who originally wrote NamedTuple, and he's not shy about reminding people during his talks at conferenc
by jxcl 9y ago
Raymond Hettinger, if I remember correctly, is the person who originally wrote NamedTuple, and he's not shy about reminding people during his talks at conferences. I wonder if his pride or other personal feelings about that particular module could be clouding his judgment over whether or not to optimize it?
- mjburgess 9y agoI think it's more to do with him primarily teaching python (iirc) rather than working on large systems with it. It's the same strain of rant Zed Shaw had of Py3, ie., that its harder to teach than Py2 and thef. bad. Crazy. EDIT: OK, if not primarily teaching, spending a lot of his time teaching it. That's a big part of his motivation + worth knowing that when assessing his arguments.
- WoodenChair 9y ago> It's the same strain of rant Zed Shaw had of Py3, ie., that its harder to teach than Py2 and thef. bad. Crazy. Why is wanting something to be easy to teach crazy?
- mjburgess 9y agoProgramming languages are tools for developers. They are taught in the service of software development. Optimizing for teaching has it backwards. It can be a factor: but to place it higher than startup time is prioritising the one-off teaching experience of a few over the repeated development experience of many. For a tool for development. Crazy, no?
- hueving 9y agoAbility to teach is going to be directly correlated with ability to maintain as a business. It's harder to hire people when the bar for learning the skill is higher. The vast majority of software development is not hitting any kind of scaling or performance bottlenecks. So optimizing for simplicity isn't as crazy as you think.
- mjburgess 9y agoI think python's start up time is going to correlate much more strongly with business success than whether Raymond's 12th slide in his 16th deck requires five minutes more time.
- yen223 9y agoAbsolutely not. Python always had a suboptimal performance story relative to other languages, but people use it anyway. Businesses use Python because it is easy to pick up, not because it's fast
- hueving 9y agoNope, I've never had a project fail due to poor startup time. When it comes to the vast majority of projects, there is no scale so realistically a 5 second startup time is not even an issue for the business.
- Too 9y agoASCII is easy to teach. Problem is ASCII doesn't work for the majority of the world.
- rajathagasthya 9y agoI've heard Raymond tell multiple times that he consults for companies too. In any case, he is a very experienced developer and I don't think your criticism is fair.
- raymondh 9y agoIt would be more accurate to say that I led the design effort. There were dozens of people who contributed to it. Its early history and list of contributors is here: http://code.activestate.com/recipes/500261-named-tuples/ http://code.activestate.com/recipes/500261-named-tuples/ The main "personal feeling" involved is just a sense of responsibility for this code. All of us involved in the optimization business have to make judgments that strike a balance between speed, code clarity, maintainability, and risk of having bugs. For the most part, we want to focus our optimization efforts on things that have a high payoff. For example, we're always having to decide how much of the library to write in pure Python and how much to write in C. If all we cared about was speed, the entire standard library would be written in C (in fact, there is a suggestion for Stefan Bethel to Cythonize the whole library). In the case of the proposed patch, my judgement was that we would be net worse-off with the patch than without (in part because namedtuple costs are typically a tiny fraction of start-up time). Guido disagreed, so I will go forward with the patch. That is the way open source works. This is less of "pride" issue and more of a difference of opinion about whether a particular patch was a net win.