http://qs321.pair.com?node_id=279895


in reply to Re: Re: RFC: Seconds2English
in thread RFC: Seconds2English

Mostly, I was thinking: why does everyone want to reinvent wheels when learning? Why not find a wheel and augment it?

The process of augmentation will mean you have to understand the code and the rest of us get the benefit of an improved module.

You say your module has features above and beyond Time::Duration. So patch TD. I'm sure Sean would welcome your patch. Think of it as an exercise in community development.

As for the code: As belg says, look to something like Class::Accessor to obviate that nasty infection of identical accessors. I'd argue against using AUTOLOAD to create accessor. Something like chromatic's loop is much better.
You seem to do a lot of calculation when anything is changed, rather than just when people want things. I'd like to comment more, but your main problems are in your todo list - items 1, 2 and 3. POD is well covered by perldoc perlpod. Tests, you've been given a pointer, and there's an excellent section in "Learning Perl Objects, References and Modules", merlyn's new book. Comments you just need to make the code clearer. It's hard to read with all the references you're using (and, as they're references, you can assign them to temporary variables which (as they're references) affect the original when you modify them). I can't quite see where you work out how long a month is (a fun thing since it varies according to when your period starts). As far as I can tell, it's one of those hard coded large numbers. (sidenote: 31_536_000 is valid perl: the underscores are ignored). You take _is_number from Scalar::Util. Why? It was happy there. You should access your internal bits via methods rather than direct hash access. Makes it easier when I want to write my subclass, and means you can stave off calculations until the methods are invoked, rather than needing calculation up front to make sure that the hash values are always right (well, until I reach in and modify one and they're all wrong).

The general thing is that when code is appropriately commented, documented and tested, if it does what it's meant to do, it's good. Just like the rest of cpan (ha!)

Replies are listed 'Best First'.
The Study of Computer Programming
by Koschei (Monk) on Aug 01, 2003 at 10:10 UTC

    Over the years CS has solved many problems. Many, many problems.

    Yet everyone insists on solving them afresh. Often not even knowing they've been solved. Sometimes, when previous solutions are pointed at, they claim "I was doing it to learn". This begs the question: to learn what?

    To learn how to write a module? Well, that's fairly basic, and the ancestor node of this post failed if that was their intention. No POD, no tests, ergo useless. Perhaps it's an attempt to implement an algorithm. Again, with no tests, how do you know it's working? Aside from a lack of tests, what is new about it? How does it differ from the other implementations around? Was any research done as to what would be a good way to implement it or was it from the top of one's head?

    The world is full of documented algorithms and approaches. It's full of libraries that implement all sorts of things. If you ignore CS, you are doomed to reinvent it, and often badly. And not only that, just think what you could be doing instead. You're effectively dragging down the community when you could be contributing to something and making things better.

    A splendid example is the CGI.pm module. It parses query strings correctly. Now, we've all seen hand rolled query string parsers, and they rarely get it all right. How many of them understand the ';' notation that one can use instead of '&'? How many of them have problems if a key is specified multiple times? People looked at their browsers and saw what they passed their programs. They looked at their programs and saw what they were given. They probably assumed this was the complete range. Did they consult any RFCs? Did they check the CGI.pm source? Did they look in the source for any CGI libraries for other languages? Probably not. Did they have a good reason to not use CGI.pm? Probably not. Is their version inferior? Definitely.

    People forget that CPAN is a vast resource for learning. There's a lot of good code out there. There's also a lot of bad code. It's amazing the value of studying bad code and going "Even I could write that better" and then doing so. Looking at the good code is also good. You can see what they're doing, or try to work out what they're doing and why.

    If you don't do research, how can the art be expected to progress? Are we fated to forever be writing btree and hash implementations from scratch without reference? Or worse, stuck with lots of programs using straight indexed arrays rather than a more efficient structure for no good reason other than not knowing any?

    At a university, you'll study the common data structure and algorithms. Even more amazingly, you aren't expected to just come up with them. You're expected to research. Or maybe your lecturer will just give them to you. In later years, you'll be asked to do things like implement red black trees (for example) and you'll certainly be expected to research. Maybe you'll come across other interesting and useful algorithms while you're researching. At the very least, you'll learn how to research if you haven't already.

    Read magazines regularly. Read perl.com articles. Subscribe to tpj.com. Subscribe to safari.oreilly.com and rent books you'd never pay cover price for. Read journals of societies such as ACM and IEEE. Any decent university library should have an archive of the older issues and these are often just as relevant as the newer ones. Further your art.

    It all comes down to one of the truly important aspects of being a programmer: being able to think. In order to think well, you need input. Do research. You'll learn more.

      Yet everyone insists on solving them afresh.

      I'm exceptionally guilty of this, but I feel I have good reasoning for it.

      The main reason I approach problems already deemed "solved" is to learn. Now you may say that I could just as easily learn from reading how others solved them but I've found narrows one's approach to problem-solving. One becomes set on a particular method of problem solving and unable to approach problems from a different perspective. As an example, consider when most major scientific achievements occur in a scientists career - it is almost always early on when they're not so set about their ways.

      Also too often I notice that after such research, one does not truly understand the subject matter. After studying an algorithm, rarely can one write the algorithm on their own, test it effectively, and improve it for specific circumstances. After creating one from scratch, this is almost always easy. As Richard Feynman once say "What I cannot create, I do not understand."

      The second reason I prefer to start fresh is that the software industry (including open source software) today is a mess. The amount of unecessary complexity that exists today is a major hinderance to anyone trying to learn a new task. Designs evolve in an unconsistant manner over time and result in a lot of unecessary subtleties that cause you to spend more time looking at the tool than the task at hand. I'd like to think that if I can design something from scratch, I can provide the consistancy required to maximize learning efficiency.

      Then again, maybe I'm just suffering from a severe case of not-made-here syndrome :)