ฝัง
- เผยแพร่เมื่อ 5 ส.ค. 2024
- PyBay 2016 Keynote
What I've learned from being a maintainer and core developer for the past 15 years. Thoughts on channeling Guido, stability, hyper-generalization, Sturgeon's law and egativity, evaluating submissions, inability to predict the future, user centric design, treating mature code differently, believing in or doubting your predecessors, lever arguments and completers, problems of too many choices, implementation details, how much to document, needs of the standard library versus the needs of users, code that is dead on arrival and how PyPI changed everything, orthogonality, importance of skill and expertise, consistency and foolish consistency, optimization and premature optimization, security tautologies, argument ordering, operator abuse, avoiding race to implementation (we can all write working code), the naming of parts, economy of force and complexity balance, feature creep, developing for others, over reliance on Guido, great minds don't think alike, preference for compactness, and aversion to deprecations. What it means to be completely reliant on long term unpaid volunteers.
Bio:
Raymond has been a prolific contributor to the CPython project for over a decade, having implemented and maintained many of Python's great features. He has been instrumental in modules like bisect, collections, decimal, functools, itertools, math, random, with types like namedtuple, sets, dictionaries, and in many other places around the codebase. He has contributed to the modification of nearly 90,000 lines of code in the CPython repository, and has made over 160 changes in the PEP repository.
Raymond has also served as a director of the Python Software Foundation, and has mentored many people over the years on their contributions to the python-dev community. He's also well known for his contributions to the Python Cookbook, and shares many pieces of Python wisdom on Twitter. He received the Distinguished Service Award at PyCon 2014 for his exceptional contributions to the python community.
speakerdeck.com/pybay2016/ray...
- วิทยาศาสตร์และเทคโนโลยี
Mr Raymond is a great speaker....
Good ethical suggestions in general. Thank you.
The most funny thing for me in this talk was that i remember myself when I was learning unit testing a while back and thinking to myself who (think lot's of dirty words) decided it was a good idea to do AssertLessThanEqual in this way. And now I see how Raymond made it, and damn... it was so logical!
I really appreciate the insight of his experience. I hope to see more such talks. These are not usually available from the world
Great talk. Thank you for sharing.
he says "fair enough" more in this video than i have said in my entire life.
Funny and interesting as always, great stories. Great speech!
Awesome
This advice applies to just all software projects. I joined a company and in my first month someone told me, "aah you're only working on low hanging fruits". Boy, it's humility to buy time and understand what's going on, than to turn things upside down the first week.
good one
fair enough
Nice talk, but I think it's not good to not show the slides when he presents his case stuies. So now I have to scroll back to where the slide is shown and have to remember the lines to understand what he says.
I can do print("hello world") in Python when do I start?
You already did it
I have heard this before.
Great talk.
i'm a junior programming in python and i know 30+ modules of python, i think that python is the best programming lenguage for learn how to program and in the lenguage that you can be more productive than others programming lenguages, i live in dominican republic and thanks to python i have learned much things, since networking at automate task, is amazing, i love python because now i can understand how the hacking works!
Eliander Perez Come back to this comment in 3 to 5 years, read it and delete it.
jokes on you - what's with the elitism. Everyone goes through their own learning curve. What matters is that he likes Python and he's doing something useful with it.
@@andyd568 some people have shoved C++ and C so far up their ass that they cant see anything else
My python has six eggs...
32:45 that's a yikes from me, dawg
37:20 hits keep coming
Dont turn python into C++
"how did hellen keller's parrents get back at her"
well both of her parrents died so... show up?
"rearrange the furniture"
"making a large number of small improvements would destroy the flowergarden. you're not a flower garden trampler are you?"
that started mean, and then it just got meaner.
the problem of the commons is that it isn't any one person's flower garden. when it becomes common property, then one person painting a mural becomes graffitti to the previous resident.
we get it old man, you don't like change. you don't need to repeat yourself, or express it in a verbose manner.
"so you aren't going to take my code and refactor it so it looks a little nicer to you"
looks a little nicer can be a sift from unintelligibility to intelligibility, or vice versa. your complaint is simply the reverse. someone else has to read your ugly code which is old. or you have to be dispossessed of authorship and read something new. neither are truely bad. one of them will probably work better than the other. one will likely be easier to read and maintain.
take for example new features. if you have a low amount of complexity by reusing mental models, the refactor might be more intelligible than the old code. alternatively if you are going for performance, taking people's mistakes and reducing the error can improve the code base as a whole by the part.
when your ego is making you prefer one bit of code to another, and you can't fully recognize and praise other's work, it is time to step away. we all have aesthetic preferences, but our personal preferences of style are not mechanical optimums.
"we all have OCD" you said that to python programmers.
"when everything is neat and orderly you have more confidence, fair enough?" no. neatness and orderliness is not capacity to solve a problem. imagine not neat vs unneat of the same thing, but a pristine car body without tires, vs a junker going down the road. which is the better car?
is a car a vehicle for transportation, or is there an ideal form of a car?
is it better to fly a cesna around, or be a member of a cargo cult?
function or form.
if form, how do you distinguish an identify correct preference and disposition towards one style vs another?