2 ms·

I very much enjoyed this poem. All the same I think you may have thrown out the abstraction with the bath water. > Does this is-prime routine even deserve a n

by Y_Y 7y ago

I very much enjoyed this poem. All the same I think you may have thrown out the abstraction with the bath water. > Does this is-prime routine even deserve a name? Absolutely. If you saw it over and over you might start just reading it as "is-prime" instead of going through the process of mentally interpreting it each time. But what about similar-looking functions with similar functionality? You want a programmer to go and make you a promise that it has the meaning (if not the implementation) you're thinking about. That promise is the same as "code-hiding".

geocar 7y ago
> But what about similar-looking functions with similar functionality? Even though we're unlikely to need this construction more than once: def is_prime(x): return x in primes(x) This one (or one just like it) appears quite common: def is_in_set(x,y): return x in y But Guido already noticed that! That's why he made an "in" operator in the first place! As soon as our routines become too generic, we're just making APL without arrays, and that's why taste matters so very much. > That promise is the same as "code-hiding". If I can see the implementation at the same time as its usage, then the code is not hidden. Ipso facto. But to expand more on what I mean by this, consider that close() is hiding code: You get all of the bugs in the C library; in the Kernel; all in code you cannot see either because it is locked/compiled, or because it's in a different file you didn't bother to read. And so on. And yet the world didn't stop spinning, and many people use close() every day without knowing or dealing with a myriad of bugs and weird corner cases[1]. So it is that even if code hiding is sometimes bad, it is sometimes less bad than other things we could be doing. [1]: Ha ha, only serious. http://geocar.sdf1.org/close.html http://geocar.sdf1.org/close.html

by Y_Y 7y ago

geocar 7y ago

> But what about similar-looking functions with similar functionality? Even though we're unlikely to need this construction more than once: def is_prime(x): return x in primes(x) This one (or one just like it) appears quite common: def is_in_set(x,y): return x in y But Guido already noticed that! That's why he made an "in" operator in the first place! As soon as our routines become too generic, we're just making APL without arrays, and that's why taste matters so very much. > That promise is the same as "code-hiding". If I can see the implementation at the same time as its usage, then the code is not hidden. Ipso facto. But to expand more on what I mean by this, consider that close() is hiding code: You get all of the bugs in the C library; in the Kernel; all in code you cannot see either because it is locked/compiled, or because it's in a different file you didn't bother to read. And so on. And yet the world didn't stop spinning, and many people use close() every day without knowing or dealing with a myriad of bugs and weird corner cases[1]. So it is that even if code hiding is sometimes bad, it is sometimes less bad than other things we could be doing. [1]: Ha ha, only serious. http://geocar.sdf1.org/close.html http://geocar.sdf1.org/close.html