Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Simplicity vs. Doing It Right

by jplindstrom (Monsignor)
on Oct 13, 2002 at 09:45 UTC ( [id://204879]=note: print w/replies, xml ) Need Help??


in reply to Simplicity vs. Doing It Right

Using a module is not only about reusing code. It's also reusing knowledge about the problem domain.

This is good, because if you don't know how to solve the problem in the first place, how do you know what you need to know to not do something stupid? Well, you don't. Sometimes that matters, sometimes it doesn't. But as time passes, things change, and it usually ends up being imortant because things never stay as simple as they seemed at first glance.

Using a module is also reusing experience. A module probably (hopefully :) has time in production, which means someone else already encountered the first real-life, non-standard-compliant, oh-that's-how-we-really-do-things-here practical problems and solved them.

I see this all the time with co-workers doing stuff in C or C++. Like writing your own mail parser (for a mail-to-db gateway). One program breaks constantly (ok, now, a year later it's a bit more stable after n fixes) because all of a sudden a weird mail format makes its way to the mailbox, or we switched mail server and the program doesn't know how to POP anymore because it made some unnessecary assumption about something.

And all the time I think to myself "find a library", "I know a module that does that", and "don't implement that yourself, it's already been done!"

The problem with other languages that we don't have with Perl isn't that there are no libraries available. It's that a) people can't find them, and b) people can't try them before buying them, so they don't try them.

/J

Update:Typo.

Replies are listed 'Best First'.
Re: Re: Simplicity vs. Doing It Right
by dws (Chancellor) on Oct 13, 2002 at 17:22 UTC
    Using a module is not only about reusing code. It's also reusing knowledge about the problem domain.

    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.

      I think your initial list is an oversimplification. Either the coder in question takes the time and energy to read and to understand the relevant HTTP RFC, or he copies code from somewhere else. Which is more Cargo Cultish? Maybe it would be simpler (for some value of simple) to post this message by telnetting to port 80, but I'm using a web browser.

      Update: Fixed a punctuation bug.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://204879]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (7)
As of 2024-03-28 13:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found