On Sat, Feb 21, 2004 at 09:28:54PM +0200, Peter Dimov wrote:
Dave Gomboc wrote:
Besides which, "fs" is difficult for an English-as-a-second-language speaker to look up in the dictionary. I have the impression that some simply don't care about that because English is _their_ first language -- an unfortunate attitude.
Well. It's actually the opposite. Because English is (presumably) your first language, you prefer the non-abbreviated "filesystem" over "fs". From the perspective of someone who doesn't "think in English", the two have pretty much the same inherent value, i.e. they are arbitrary identifiers. A mental mapping translates these identifiers into the entities they represent. Since the extra letters in the longer identifier do not add any semantic value to non-English speakers, they are merely clutter and do not contribute to readability.
Your observation that "stdio" is a _word_ in non-English programmer cultures, and not an abbreviation of "standard input/output", is very much in line with the above.
I'm a non-English programmer. All I can say is that I agree with the above. Altough I understand that "stdio" is and abrevation of "standard input/output", for me it is and it always will be just stdio. I don't need to find a natural-language meaning for that, because the I'm using it only in relation to computers. Similary it is with the filesystem. It is only a term identifying something what have to do with organization of files. Without propert background in computers, it has no natural meaning at all (or very unrelated to the real purpose). Actualy for me, a "file" is most of the time a file on the disk. I learned the meaining of th real-world file quite a long time after I learned a lot about computer files. And I never felt, that I need this information to understand what does computer file mean. What I'm trying to say is that, it does not matter for me if an entity has a very nice sounding english name or if it is just an abrevation for something. The term will denote only that paricular entity and nothing else. I will not try to assign some natural association with the real world. Such an association is many times more confusing then helpful. Now about the long namespaces. I would always prefer shorter, but still meaningful abrevation to a loooooong name. I'm always have to use namespace alias for filesystem. Simply, because to code is much less readable when I would have to use filesystem:: all the time. In the code, more important part is after "filesystem::" (a method name), and long prefix is just a distraction when reading the code. If somebody is reading a code, she/he woudld have to look into documentation anyway, to understand what is hidden under namespace filesystem::. It is very same for abrevation "fs". How can anybody try to understand the code without knowing what's behind the calls? I don't think, that code: the_great_library::sublibrary::specific_part::get_line( the_second_great_library::common_stuf::line(1) ); is any more readable then gl::get_line( sl::line(1) ); First example hides the important parts of the code behind the long prefixes, making the code much less readable. In my code, I try to never use more then one level of namespaces. I don't like global "using namespace" directives, so I'm using aliases for deeper namespace. For example: namespace lambda=boost::lambda; namespace fs=boost::filesystem; That's my 0.5 SKK Regards, Pavol