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+.

  • 2
    I would like to mention that many windows apps are not open source... Often they are packaged with the dependencies they need, even if they are open source. One example is pidgin. You don't have to download gtk separately on windows in order for pidgin to work. You might find including the language on windows does happen when it does require external dependency's though I can't think of any examples at the moment as it seems most strive hard not to require external dependency's. Commented Jun 16, 2011 at 14:17

9 Answers 9


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.

  • Yeah, I think you have a good point here. The *nix culture is a culture indeed. Commented Jun 16, 2011 at 2:25
  • 1
    It also saves time when wondering "hey, in which language Chromium is written?". Commented Jun 16, 2011 at 5:08
  • @macias: The geek in me makes me look at the package's dependencies, where this geek will most often find out the language. In fact, this geek is so religious that whenever he visits a website, he gets annoyed that he can't quickly check what language the unfamiliar tool is written in. If it's <insert unloved language>, this geek runs away, and if it's <insert favorite language>, the geek's prejudice shows.
    – tshepang
    Commented Jun 16, 2011 at 6:53
  • 4
    A practical example about technology that could be a problem is the mono/.NET since Microsoft has a lot of patents in that area and has a long history about being "unfriendly"... Therefore it is not strange that some people would like to know this kind of things to avoid future problems.
    – Johan
    Commented Jun 16, 2011 at 11:15
  • 1
    From a systems admin perspective, what a project is written often dictates which dependencies must be available. Commented Apr 20, 2012 at 4:57

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.

  • 2
    A decent example I'm thinking of is a webapp called redmine. It's written with Ruby on Rails, neither ruby nor rails is usually provided on system by default. Java apps are also like this. Commented Jun 16, 2011 at 14:10

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).

  • Just browsing through the Ubuntu repositories (via Software Center). Almost all of the summaries include the language within the first sentence. I find it kind of funny that most Linux developers seem to be actually developing for other Linux developers instead of users. Commented Jun 16, 2011 at 2:24
  • @j0rd4n not being a ubuntu user can you give an example of a software package? I mean to they really put C in the description of Firefox? I would speculate that some 90% of software on Linux is not meant for end users it's a library. Also... you didn't realize that Linux Developers develop for themselves? it's sad but true... as a perl programmer I digress I've not yet written anything for an end user :( Commented Jun 16, 2011 at 14:30
  • I use ubuntu, with german as interface language, so it will only help few of us, to cite some examples, but I can assure you: In synaptics, the installation tool for new software, I made a test and picked 5 packages - and didn't find a single of them, mentioning the language it was written in. Commented Jun 16, 2011 at 14:35
  • Extending my comment: Often, the software is written for Unix (if you find automake-files and such) and not necessarily produced for linux, but because of the compatibility, available on different unix flavors. Commented Jun 16, 2011 at 14:37

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.

  • The Ubuntu repository has an amazing amount of package descriptions that the first five words contain the language. I'm a developer myself, but I never figured my users cared. I could understand, however, that being open source, it might have more meaning, but are we developing for people or other developers? Commented Jun 16, 2011 at 2:23
  • 1
    @j0rd4n Developers are people, too!
    – Zach
    Commented Jun 16, 2011 at 19:40

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.

  • A general aspect is the libraries used when running the application.

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.

  • Another aspect is the libraries used and prerequisites necessary in order to compile the application.

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.

  • A different aspect is the intention to attract contributors.

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.

  • Finally, there's obviously a lot of bias for and prejudice against some languages.

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.

  • So in both cases you have a pro and a con argument - which isn't satisfying. Compiled code which is closed source is common on windows too, so the performance argument would not distinguish a Linux-program Commented Jun 16, 2011 at 1:20
  • 1
    what? you just made no sense. Pro and con is exactly why you would list the language. If one had only 'pro's, then everyone would use it. And I dont even understand what youre trying to say about compiled code and OSs.
    – phemmer
    Commented Jun 16, 2011 at 1:27
  • I understood your answer that way, that people implicitly advertise the performance, if it is written in C/C++, and that they implicitly advertise the portability if it is not written in C/C++. Which is always a contra argument - either against portability, or against performance - both reasons, not to mention the language. So why is it sometimes this, and in other times the opposite? Commented Jun 16, 2011 at 1:37

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...

  • Why do you call them fools? Why wouldn't they code in the language they like? Which language should they instead use?
    – tshepang
    Commented Jul 3, 2011 at 21:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .