Re: Usability: Technical details in package descriptions?
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
Reply to: