On Thu, 2005-07-21 at 13:45 +0000, Thaddeus H. Black wrote: > 1. Compiled programs (C, C++, Fortran 77, Ada, ...) usually run leaner > and faster than do interpreted ones (Perl, Python, Ruby, ...).
In general, algorithm choice is much more important than language. Also, the language the main program is written in may be of little significance to the program's overall performance if the grunt work is done in libraries written in a compiled language. In the end, the user wants to know if the program's speed and size is acceptable for their needs. The language that the program is written in does not directly answer these questions, and sometimes is even misleading. > 2. Programs written in obscure languages may prove unmaintainable if > the original developer disappears. Besides threatening obsolescence, > this can be a security issue. You've furnished a reason *not* to put the language in the description (if I wrote a package in an "obscure" language and took your point to heart, I'd not want to advertise the fact). Besides, what is obscure? Ruby? Ocaml? Snobol? Fortran? Scheme? How is a user to assess whether these are up-and-coming languages, less popular but still well supported, or completely obsolete? I doubt if most users know the difference. > 3. Programs written in widely used languages (C, C++, Perl, > Python, ...) may work better simply because the programmer had adequate > access during development to high-quality modules and library bindings. A false sense of security at best. You could argue conversely that the more popular the language, the more likely a novice programmer has chosen it to dash off their first programming project and has managed to get it into Debian. And perhaps using an "obscure" language could be viewed as a filter, weeding out the less-motivated and less-skilled programmers. Again, the user cannot use implementation language as a reliable indicator of quality. > 4. With a language come a mindset, an aesthetic and a development > culture. Although one cannot speak in absolutes, generally speaking, > which program would you expect to be more focused and reliable: a > program written in C++ or an alternative written in Perl? (On the other > hand, which of the two programs would you expect to be available > sooner?) Now we're *really* getting touchy-feely. I think we're losing sight of the goal: the user, reading the description, should get a sense of what the package does, whether it is likely to meet their needs, and whether it offers distinct advantages over any of the alternatives. While I can appreciate that some small minority of users out their are aware of the "mindset", "aesthetic" and "development culture" of an implementation language, and therefore have some mild bias towards packages implemented in it, it certainly isn't a primary indicator of whether the package is suitable for a particular use or not. > 5. Some languages are inherently more debuggable (or less bug-prone) > than others. C++ is more debuggable than C, which itself is more > debuggable than Fortran 77. Python is more debuggable than Perl. > Programs written in the more debuggable languages may rationally be > expected to suffer fewer bugs. A more direct measure of this can be determined by a bit of research by the user first: check the Debian bug database, the changelogs, the upstream bug database, the support & development mailing lists. Ask your friends. Is this a good program, or is it a buggy piece of waste product? > 6. Some languages enjoy not only free compilers or interpreters, but > also well written, complete free documentation. It may not seem like > much, but a limited ideological motive may exist to promote programs > written in such languages. We're getting further and further from real user concerns. See my answer to 5. > 7. Some users may want to be able to read parts of the source of the > programs they use---even if they have no intention of contributing to > development. This is Debian, after all. Programs written in obscure > languages may be vaguely deprecated for this reason. apt-get source <packagename> and look it over if you're an aspiring developer. There isn't any better way to get acquainted with the source than to actually look at it. > If it matters, the languages I personally use most on a daily basis are > Perl, Fortran 77, Octave and Bash (also occasionally C, C++ or > Python)---some of which do not rank very well by my own criteria. Octave, what's that? Hm, I guess it must be one of those shoddy deprecated languages. I'll make sure to avoid anything you've written in it. ;) > However, I do tend to avoid publishing things written in Perl, because I > use Perl often and know Perl's nature. As a user, I tend to prefer > software compiled from C/C++. Hence the language in which a program is > implemented is somewhat relevant, at least to me. And "somewhat relevant" is exactly what the debtags aspect "implemented-in" is for, as mentioned earlier. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]