Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
When showcasing applications, Windows and Mac mostly talk about features. Linux applications, on the other hand, have more details about what language was used to write it (and accompanying libraries) rather than features. Why is that?
I could understand knowing the difference between GTK+ versus QT making a difference just because of the desktop integration requirements, but C vs C++ vs Python vs Assembly vs etc.? Really?
For instance: foo is a simple blah blah written in C/GTK+.
I think the traditional Linux user (a geeky tinkerer who actually installed the system by self) does care about such information (what technology is behind this tool?). I am also one of those geeky guys who would, for example, refrain from installing and using a package just because it uses some technology I don't like. Some call this sort of behavior religion of course. Silly isn't it?
Anyways I can think of two reasons:
The packagers are as geeky (if not more) than those Linux users too, so they found it a good idea to add such info.
I think when these packagers put such info on their package descriptions, they are likely doing it as some form of promotion. It works at times (it worked on me quite a few times).
This is just a guess of course.
My sense is it relates to the second of the four software freedoms:
The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
Publicizing the language (or other technical features) supports people's ability to choose, and encourages participation in projects by people who are proficient in those languages.
This may be partially historical. Even in the not so distant past it was usual for individual system administrators to build and install everything that ran on their system.
Notes on what language and libraries were used to implement a tool give a hint to the administrator about how much work that process is going to be for their system.
In this age of ubiquitous and far reaching package management tools this is a bit of an anachronism, but unix culture is conservative in the sense of not throwing out things that seem to be working, so it will be a while before the habit dies.
In extension to jasonwryans' answer:
If you name the language it was written in, the person who receives it can estimate how hard it will be to provide a patch, or to get some insights, or to extend the program.
Of course this only makes sense if you are a programmer.
Where did you see the summaries? In a repository, or a package like .deb or .rpm?
If you build it from source, the information might be helpful to identify, whether you have to install other stuff (compliler, libraries, build-tools).
Unix, and now LInux and the BSDs, have always had a really fractured software base, and a far more diverse hardware base existed in the rather recent past. It was important to know that some software ran in the intepreters you had on your system, or that you could compile the source code. If you don't have a Common Lisp interpreter, or a Tcl interpreter or a whatever interpreter, you didn't want to bother downloading source, only to find out you couldn't run it.
Having a description of what language something was in prevented a lot of wasted time.
When prompted “what is this thing?”, a developer will tend to describe its nature, which for them is tied to the source code, rather that its function. Someone will hopefully rewrite the description to be more user-centric before it ends up on a package, but mentioning the language can still be relevant, for example to extensibility and scriptability, or useful for the opportunity to attract contributors.
From my perspective, such information is essential for attracting new contributors, as well as giving prospective users an immediate idea of how much work it might entail to integrate the application into their system.
Some installations are restricted to a few selected toolkits, like GTK+ but not QT, or vice versa. For an administrator who maintains a system and regularly updates its components over a long period of time, this may solely be a practical and not a religious question.
I.e. for users of a source-based Linux distribution it makes a big difference whether an application is written in C, or in Objective-C, because their compiler needs to support the language in the first place. Other languages may make it necessary to install a huge stack of libraries. The question then is, again, how much work you're willing to accept in order to compile this application.
Most developers have a preference for a small number of languages, or may simply lack experience in other ones. In order to allow a greater number of people to contribute to an application, some projects even split their sources into two different languages (like Wesnoth, Vega Strike, Naev, only to name a few). One of them for the core application (like C or C++), the other one for easy modification (like Python or Lua). Here's a link to a chapter of "The Architecture of Open Source Applications" that describes how and why this was done in Wesnoth.
I'll just say that I've seen horribly inefficient software written in about any language. If you ask me, for efficiency, the code quality of the application is much more important than the language it is written in.
I think a lot of it has to do with performance advertisement. An application written in a compiled language (C, C++, ...) is going to perform a heck of a lot better than one written in a script language (perl, python, ...).
But it also ties into compatibility. An application written in a scripting language is also likely to be more portable across architectures & OSs with little to no modification.
On today's desktop/server systems it may not be so relevant, but for smaller systems ranging from embedded systems to SSD netbooks and tablets, the languages or libraries used by a program can be a make-or-break issue, both due to size and portability considerations.
Regarding size: Adding an interpreter for an additional language, along with all the standard modules and typically-used add-on modules, can easily add hundreds of megabytes to storage requirements. The same goes for library families, especially the ones associated with major desktop environments like Gnome and KDE. What's worse, going from running n to n+1 Perl programs might not add so much to memory usage requirements, since a lot of memory can be shared, but going from n Perl programs and 0 Python programs to n Perl programs and 1 Python program results in a significant spike in memory usage. This becomes even more of an issue when every fool writing free software has their own favorite script/radtool language they want to program in... Perl, Python, PHP, Ruby, JavaScript, Bourne shell, Bash, Csh, ....
Regarding portability: A lot of interpreted languages (as well as library frameworks) make heavy use of features that may be available on big Linux desktop/server systems but not necessarily available on smaller/embedded/MMU-less systems. Dependence on dynamic .so module loading at runtime comes to mind...
