Comment by pdonis | Hacker News Reader

Comment by pdonis | Hacker News Reader

Parent Full thread

> In my experience writing reusable code, unless you're writing a library, is usually a waste of time.

In the sense you're using "library" here, the Unix utilities are libraries--more precisely, they are library functions; the whole set of utilities is the library. So McIlroy was a library/framework writer.

> Most code, even when written with intent to be reusable -- isn't.

I more or less agree with this; but fortunately, you don't have to look at "most" code to find code that is reusable. As witness, once again, the Unix utilities. Or, for that matter, the Python builtins and standard library that I used to build the Python versions of the "word count" program.

Moreover, even if you're in Knuth's position and don't have a good base of reusable code to draw on already, it still makes a big difference how you proceed from there. Do all app devs write big monolithic apps? I believe pg once wrote an essay about bottom-up vs. top-down programming, leaning heavily towards the former.

(largely agreement here, can't say much about Knuth, though)

The essay: http://www.paulgraham.com/progbot.html ?

I think a lot of everyday reuse (by factoring commonly used code) happens at a level of programming which neither fits application nor library development but writing small tools to automate ad-hoc tasks (e.g. by scientists, admins, etc.) Environments like Python, the shell, or Lisps seem to be more suited to this kind of development than, say, Java.

In the case of the example, I could easily imagine that the "isolate words in input text"-part will turn out to show up again, and then one would factor it out to a function. When the first text containing unicode soft hyphen characters is encountered, only a single shared function has to be updated, and all little scripts using it will benefit!

A function extracting the text from xml-documents, skipping a configurable set of element types, might find similar reuse, etc.

Just an aside: I'm not familiar with Python, what I found disappointing was the mix of chained object method invocations and "outer" function calls - since replacing the built-in string class seems to be frowned upon, I was wondering how the example script would look like using pipe[1] :-)

One question about the Python code: is the first call to sorted needed, and if yes, why?

[1] http://pypi.python.org/pypi/pipe

> The essay: http://www.paulgraham.com/progbot.html ?

Yes, that's the one I was thinking of. Thanks for finding the link!

> the mix of chained object method invocations and "outer" function calls

Actually, you're right, I could have factored out the part that builds the dict of words vs. occurrences into its own function, so that the entire pipeline would be a single chain of calls. Now that you've put the thought into my head, I may go back and do that. :-)

> I was wondering how the example script would look like using pipe[1] :-)

That would certainly make the Python look more like the shell script. :-)

One of the constraints I imposed on myself when writing the Python version was to only use what comes with it--built in functions/syntax and the standard library, with no third-party packages, similar to how McIlroy only used "built-in" Unix commands that came with every Unix system.

> One question about the Python code: is the first call to sorted needed

You're right, it isn't. I've pushed an update to the github repo fixing this (in both versions).

> Now that you've put the thought into my head, I may go back and do that.

Just did it. :-) Factored out a "uniq" function in both versions, so the "pipeline" function is now a single chain of method invocations (with the slicing at the end). Which means it could actually be put in the "if __name__ == '__main__'" stanza, but that seems less readable to me.

Reply on news.ycombinator.com