Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
you good afternoon our next talk is designing poetic api's by Eric rose Eric works at Mozilla and by his own account right to way too many Python libraries please give a warm welcome wow thanks for packing it out in here guys as a fantastic well today
we're going to take a look at psychology and anthropology and the history of our own field and hopefully figure out how to write more beautiful api's so before we get started I have a confession to make which is that I am NOT a poet unfortunately I
know but poets and programmers we have a lot in common we both deal with very precisely formulated language and we both make up new terms in fact programmers do this all the time whenever you name a variable or coin new function you're essentially making
up a new piece of language it's this invention of language and the mental processes that go on with it then a key to writing excellent ap is it's vital that we create new language with care because the language that you use influences the thoughts
that you can think have you ever had anyone tell you you should go learn Lisp and go learn Haskell it'll change the way you think about programming yeah well there's something to that as it turns out there's this old psychological theory called
the sapir-whorf hypothesis and how it goes is the language that you speak determines in limits the thoughts that you can think and assume is shaking your head there yes this has fallen out of fashion lately but there was some evidence or at least anecdotes
in its favor for a while for example take the case of ildefonso a Mayan man who was born deaf into a poor family and so they didn't have a lot of resources to invest in things like sign language training or lip reading and so he was actually brought up
without language he didn't acquire language until he was 27 years old and during this early period of his life he couldn't do math with quantities beyond 10 for obvious reasons but now that he has the language for and he's received training he
can do just fine you can calculate with the best of him because he has the language for it now so this strong sapir-whorf hypothesis which I'm still getting bitter looks from sumana about has been disproved by counterexample and you can reconnect to do
this just as a thought experiment here we are in Montreal a bilingual City and satisfying translations are possible when I came into the airport I wanted to grab a sandwich I got in late I went to subway the guy was making my sandwich spoke French I spoke
English we used French words and English words and regardless of the language we used I would have gotten the same sandwich out afterwards pitkin Stein writes some some pretty down and dirty philosophy now you can translate that that very precise german into
english and the arguments still make sense or at least the same amount of sense they did before but but they're still a flavor to each language right who hasn't accused a colleague of oh you're writing Java and Python knock it off you're writing
Python in standard X or in standard ml Python naturally makes you reach for hash tables functional languages make you solve things in terms of map and fold JavaScript everything's a closure and this is the weak form of the sapir-whorf hypothesis which
I dare you to say at five times fast and I think it does hold the language that you use influences the thoughts do you think now I'm getting nods thank you so the bounds of this influence have been marked out experimentally for example in English we don't
have a whole lot of good words for colors in the red orange range now if you show an English speaker a bunch of color swatches they can certainly distinguish between them visually but if you then distract them with a card game or something and bring them back
later they won't be able to remember a swatch you ask them to remember if it didn't have a handy name in their language so it seems that having a symbol for something a word for something makes it mentally lighter weight when you draw a symbol like
red over a bunch of details like well 632 672 nanometers in wavelength it acts like a mental abstraction you can kick all the details out of your head and say that mental space for higher-level pursuits like building sentences with the word red abstracting
out symbols is the root of all human language but it's also the root of all software engineering now the pointer software engineering what differentiates it from just hacking around with spaghetti code is making software intellectually intelligible by
finding good abstractions so let's talk about api's in creating an API you make up your own symbols and their meanings functions variable names data structures and with the names and semantics that you choose you shape all future thought about that
system remember ildefonso couldn't get above the number 10 until he had the words for it when you make a good API you give those who come after you including your future self those numbers after 10 letting people think the thoughts that they couldn't
before for example let's take a look at your lib to vs. requests right so URL lib to is pretty horrendous labour boasts it's hard to do common things part of that is because it has a greater scope than just HTTP but I'm picking on it requests a
third-party library has become a rapid de facto standard because it introduces this brilliant new symbol called the HTTP request and I think this is even more brilliant because apparently some people have already heard of this abstraction and had it in their
heads already so one thing you can do is ask yourself what would a naive user imagine my API should look like if there are already existing symbols out there just make them work that's easy one now it's silly to try to turn good design into a process
that you can follow or a formula you can apply but I've gone ahead and taken a swing at it anyway there's some requests code for comparison so today I'm going to give you seven rules of thumb that you can use as a checklist it may not give you
a good design for free but it will guide you along and it will keep you from falling off all the worst cliffs so the first principle is something not to do don't be an architecture astronaut my first step in designing a new library is actually to not design
a new library it's all well and good to try to do good design in the abstract but design is basically imagination and imagination is little more than hypothesizing and you know from history what happens when you hypothesize without continually bringing
those hypotheses back down to earth and testing them against reality you end up with alchemy rather than chemistry right it can be academically interesting it can be visually impressive lots of sparks and bright colors but when it comes down to it it's
just a self-consistent system of nonsense not of a lot of practical value they didn't get any gold out of that lid so to bring our efforts back and anchor them in the realm of science remember that the best libraries are extracted not invented what this
means is you should have one hopefully even two or as many as you can can swing applications that already do what your library is going to do and then you take the bits of them there in common and you factor them up into your library for example i wrote a
plug-in called knows progressive plugs into the popular test framework knows and its purpose in life is to display a progress bar and fancy trace backs and just generally make output easier to grok now it makes use of a lot of terminal escape codes for things
like colors and bold and positioning and the code looks something like this there's lots of terminal set up kind of intertwined with the operative code lots of abbreviations for different term info strings and there are raw raw term cap names like sgr
zero not very friendly things an RSC the f2 key of looking aside to the documentation to figure out what they mean every time I'd have to do some formatting I would think oil share was a decent abstraction around this so I would have to look at it all
the time and this is the magic point when you have a real useful program with a library struggling to get out that you should come down from orbit and start thinking about library design in this case i ended up extracting the terminal handling into a library
called blessings and i want to use it as the first example of our extraction process so the first thing to do is dump everything out of the workbench what sort of things out the library to do well we want to print some text it's formatted and we want to
print some text maybe at a location like the bottom of the screen with the progress bar is and then snap back to what we were doing up by the trace backs what tools do we have well we've got everything that's native to the language we've got functions
with optional herbs and positional args we've got decorators those are fun context managers and classes will let you do inheritance but we also have common patterns that come from the culture and from the things that the library encourages again week sapir-whorf
sequences they can for loop around iterators and mappings then we shake the workbench up and we see if we can find some good pairings between these things what guides you in this consistency you have the entire technical and cultural weight of the language
[ ... ]
Nota: se han omitido las otras 4.693 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.