4 ms·

The article's main point is just that languages have started including much larger standard libraries. Larger libraries save time, but they make the programmer'

• cabalamat 18y ago
  > Larger libraries save time, but they make the programmer's job more "searching for the right function" rather than "writing functions." Yes, and: trying to figure out what the documentation means, etc. Libary documentation tends to be not very good, and libraries themselves are not designed to be easy to learn. I'll illustrate this using Python's SimpleXMLRPCServer, not because it's particularly bad, but because I've been using it recently (It's at http://docs.python.org/library/simplexmlrpcserver.html http://docs.python.org/library/simplexmlrpcserver.html ) 1. Naming conventions. The name of the module is SimpleXMLRPCServer not simplexmlrpcserver; most Python modules use the convention of the module name being in a lowercase, but this one differs -- Python should standardise. Similarly the name of the class is SimpleXMLRPCServer, beginning with a capital -- but some python classes don't begin with a capital. Similarly the naming conventions of methods and parameters should be standardised -- either use underline_separated or camelCase but choose one and stick to it. It's just irritating if there's a parameter called logRequests, and another called allow_none. 2. Documentation not complete To quote the documentation: "If logRequests is true (the default), requests will be logged; setting this parameter to false will turn off logging." Er, where are they logged? It doesn't say. Sure, I could read the fucking code and work it out but I SHOULDN'T HAVE TO. It probably puts it in a file somewhere, but for all the doumcnetation says it could build a factory of nanomachines on the surface of the moon and write the log file there in big 6 meter high letters. 3. interface of library too complicated A library should be a black box that can be potentially big, exposing a small interface to the outside world. That way, by learning a small, simple interface, you get access to lots of functionality. It's quite simple to register a function with the xmlrpc server: def myFunction(aString): return "x" + aString = "x" server = SimpleXMLRPCServer(("localhost", 8000)) server.register_function(myFunction, "myFunction") This is fine, and you can omit the 2nd argument to register_function() if you wish; also fine. But there also a way of registering as functions all (or some) of the methods of an instance of a class, using the call register_instance(). This is more compex than it needs to be and figurung out how to use this function is impossible (for me at least) without extensive examples. However, this function is superfluous -- if I want to expose all the methods of an object as remotely-callable procedures, I can do it myself by making iterated calls to register_function().