I agree entirely, but let's approach this from the perspective of someone who needs to understand a thin slice of a problem domain in order to solve a problem, and is handed a handful of standard modules that cover a superset of their problem. If they take the code snippets as offered, they risk being on the slippery slope towards Cargo Cultism. If they take the time to grok the modules, they come out better in one way (knowledge and skill), but worse in another (the opportunity cost of the time taken to understand the modules).

The example that started this off is an interesting one to think through. Someone needed to run unit tests through a browser. They decided to write a small web server. (Perhaps they'd seen another example where this approach had been successful. Perhaps they were in an environment that precluded their installing Apache or IIS. We don't know.)

The slice of the problem that they needed to solve was

• Use sockets to respond to HTTP requests
• Ignore requests that didn't originate from localhost
• Parse just enough of an HTTP request to figure out what to do
• Return static HTML or images, or run a Java program that emits HTML, and return the results
• Return a minimally correct content header with the response

This they were able to cobble together in 61 lines. Not pretty, but workable.

If they'd come to me for help, I would have suggested starting with HTTP::Daemon. To use HTTP::Daemon righteously, you need to understand HTTP::Request, HTTP::Response, and HTTP::Status. Status is trivial, but to understand the first two, you need to add HTTP::Message to the mix. It's a common superclass, which adds additional complexity weight. HTTP::Message uses HTTP::Headers, which pulls in URI::URL, HTTP::Date and MIME::Base64. URI::URL subclasses URI::WithBase, with overrides stuff in UNIVERSAL (heads are spinning at this point.)

And I'm leaving stuff out. By suggesting HTTP::Daemon, I've sent someone away with a pretty hefty transitive closure of stuff to read through and understand, if only to know whether or not it applies to their problem.

Are they better off? Maybe yes, maybe no.