My guess is a lot of people will not like it, because the names are not descriptive at all. your idea, however, points to a long standing problem caused by the 'files and folders' paradigm of information management:

• some people use filenames and directory names as a "UniqueID" (eg 20040123_001.pl)
• some people use file and dir names as a "Description" (eg my_convert_to_html.pl)
• some people use file and dir names as a "combination field" (eg conv_html_20040123_ver1_utf8.pl)
• some people use file and dir names with special "symbols" to denote extra meaning, or influence the sort order when listing contents (eg 1docs, _about, !old)

The problem with *all* of these approaches is that they are of diminished used unless you use them 100% consistently, and things can tend to 'break' when you find yourself needing to change a name for whatever reason.

One approach is to use something like folksonomy tagging on your own local files, or use any of the various desktop search solutions. You can also be dilligent about adding metadata to your files (NOTE: some prefer a more neutral syntax, since it can be a lot less annoying if you can use the exact same documentation style in all of your code, regardless of programming language).

All of the approaches mentioned here and elsewhere in this thread, however, are pale vestiges of what could be possible if filesystems were more 'tag' oriented or 'object' oriented than the old-but-popular 'folders and files' paradigm.