What Programming Language For Linux Development?

k33l0r writes "Recently I've been thinking about developing (or learning to develop) for Linux. I'm an IT university student but my degree program focuses almost exclusively on Microsoft tools (Visual Studio, C#, ASP.NET, etc.) which is why I would like to expand my repertoire on my own. Personally I'm quite comfortable in a Linux environment, but have never programmed for it. Over the years I've developed a healthy fear of everything Java and I'm not too sure of what I think of Python's use of indentation to delimit blocks. The question that remains is: what language and tools should I be using?"

Comments

C or C++

[Amazing Quantum Man]

The *nix API is in C.

Alternatively, you could look at Perl, as well.

If you're really desperate, you could use Mono, but I wouldn't recommend it.

How much do you want to learn?

[modmans2ndcoming]

C/C++, C#, Objective-C, Java, Python, Perl, [insert language of choice]

All can be used to do Linux development.

KDE, stick to C++ and Python.

Gnome, stick to C and C# and Python.

GNUStep, stick to Objective-C

Java and Perl and any other language you choose can be used as well, but the desktop environment support for them is little to non-existent, depending on the language.

Mono

[reSonans]

Mono could make the transition very easy for you, depending on what your doing.

What do you want to develop?

[kwabbles]

Do you want to develop KDE apps? How about GTK apps? Do you want to submit kernel patches, or create system utilities?

You may want to be more specific, however - C, C++, Perl and Python are pretty much the norm.

This is all true however...

[Narcocide]

... it is also pertinent to note here that the GNU standards document, section 3.1: "Which Languages to Use" strongly advises plain old C for both performance and absolute maximum cross-platform compatibility.

Since operating system and hardware platform independence are both key factors of code re-usability and really what open source software is all about I personally think this is a strong call.

However the parent post is correct in that application intent trumps all. If you are just writing shell tools you never intend to use outside of Linux then PERL is likely fast enough and probably much easier/faster (bottom line: cheaper) for the average developer to work with.

If you're writing web software use PHP, but it will make you feel dirty inside.

Re:This is all true however...

[nsaneinside]

You'll also have to learn to write your own make files - not a hard job.

It's not hard to write a simple Makefile (or Makefile.am), true. And I'll agree that GNU Make does its job -- executing commands based on dependency hierarchies -- very well.

But sometimes, I don't want to even think about dependency hierarchies and whatnot. If you want an alternative to e.g., autotools, I'd recommend looking at CMake (http://www.cmake.org/); it can generate build systems (makefiles or IDE project files, for example) for a number of different tools (even Visual Studio!).

And you'll find you'll need perl and bash scripts.

Not sure about the perl one (I've managed to get along fine with sed and grep so far), but a good working knowledge of shell scripting and available tools is essential. `man' or `info' can help with that. ;)

Re:This is all true however...

[GigaplexNZ]

I think I might like Obj-C over C++, due solely to the really nice init/release/autorelease mech for memory allocation.

Sounds like someone needs to read up on the RAII design pattern (not to be confused with RIAA). Sensibly written C++ will automatically release memory when it is no longer used.

Re:This is all true however...

[Anonymous Coward]

True - to some extent...

The second block structured language I learned (long ago) was Simula. I loved it instantly - it just seemed to make sense (although I understood it was not appropriate for some problems I was solving in microcode or assembly or simple applications I was writing in BASIC). Although I didn't use any languages that had a built-in notion of an "object" or "methods" or the like for another couple of decades, my C code (and code I wrote in other languages) looked much more "object-oriented" than most of the other code around me.

When I began using C++ it seemed intuitive for the most part - once the quirks were understood - and made writing OO code easier. C++ added more checks and a consistent framework (your ctor, dtor, copy constructor, etc are pretty easy to identify -- we don't even need a shared coding standard beyond the C++ definition!). C++ is of course full of flaws, and some of those errors the compiler spits out on heavily nested template libraries are, to say the least, excessively obtuse. But, C++ is now quite portable with just a bit of care (you don't have to use every feature your current target platform supports - any more than you have to eat every last bit of food at an "all-you-can-eat" buffet -- and will be a lot happier if you don't try!). Performance, with care, is also quite acceptable for almost all purposes. I'm sure there are better languages, but IMHO, few can compete with C++ for a mix of portability, performance, and productivity - although for each of these individual three points there are many languages that can beat C++ (APL, LISP, assembly, Eiffel, SQL, JAVA etc...).

IMHO, the biggest problem with C is that it doesn't encourage OO - you have to be aware of the wisdom of doing so and arrive at an understandable way of doing so. Therefore, too many C coders who don't care about OO don't utilize it at all in these environments and their code doesn't stand out like a sore thumb. In C++, the messes these coders create would be obvious and the coders would be embarrassed (or bludgeoned) into cleaning up their act.

Some well known OSS projects written in C are crap at the code level -- of course the source of the problem is not C, it is the coder, but in a culture of C++ I really think the peer pressure would have been stronger to write more concise, more easily debugged, more flexible OO like code.

Re:This is all true however...

[brainnolo]

You say that you have only done a bit of Obj-C programming. The problem is that for small programs retain/release is much like malloc/free, but in bigger projects it becomes a life-safer. The conventions are very easy, even if you throw some CoreFoundation object in the equation.

The main difference between retain/release and malloc/free is that with retain = "I (object calling retain) need this object to stick around" and release = "I (object calling release) don't need this object anymore". Instead malloc = "create this", free = "nobody else in this process needs this". You can see yourself that while is usually trivial to determine if an object needs something it is referencing or not, doing so for the whole process everytime you try to get rid of an object is painful.

Note that now the Objective-C runtime offers garbage collection (except on the iPhone), which is of course a good step forward.

Re:Learn C and Python

[mickwd]

"We had on average 4 bugs a week due to the indentation bullshit, each of which took multiple hours to debug."

Any chance you could name the company you work for?

Because I want to avoid your products.

Re:A valuable skill

[FishWithAHammer]

And you're stuck GPLing everything or paying for a license before you do any development. Stupid and shitty.

Re:Learn C and Python

[STFS]

Python is absolutely unusable on real world projects (any project where you aren't the sole developer) due to that indentation crap.

Would you mind repeating that? I don't think the guys developing the following projects heard you:

• A good chunk of Google
• EVE Online
• The majority of YouTube
• Freevo
• A bunch of KDE Software

I could go on... but you get the point.

If your software team is having problems with the significance of white spaces in Python, my bet would be that, no offense, the team was to blame.

The trick is to coordinate the "white space rules" between members of the team. If it can't pull that one off, I wouldn't trust them to write code for a production system anyways.

Re:Learn C and Python

[xant]

Trolling? I'll bite.

Free: http://pythonide.blogspot.com/search/label/spe
Free: http://die-offenbachs.de/eric/index.html
Free: http://docs.python.org/library/pdb.html#module-pdb (and included with Python)
Commercial, but excellent (my team uses it): http://www.wingware.com/
Commercial: http://www.activestate.com/Products/komodo_ide/index.mhtml

If you really love Visual Studio for some reason: http://www.activestate.com/Products/visual_python/index.plex
If you love Eclipse: http://pydev.sourceforge.net/

And for the lazy, "import pdb; pdb.set_trace()" has always been my favorite way to debug python software. Add that line anywhere; get a breakpoint. Make it conditional with an if statement.

Not to mention introspection right down to the bytecode at runtime (there is even a Python module that lets you edit the bytecode at runtime, if you are sufficiently crazy).

In short, you have not used Python for more than 10 minutes if you really think the debugging isn't good.

IHBT. HAND.

Why I hate mono

[Curunir_wolf]

Try it. You'll be soon warning people away from it, too. C# programming is one thing (it's just a language), but the mono/.NET libraries will have you banging your head against the desk before long.

I might have a skewed perspective. When I started working with mono, the big selling point was that we could use all the tools and processes on Windows (our development environment is standardized for the whole company's development department and has years of process development work in it), then deploy applications on our Linux servers (we were even using SuSE). Not so fast. Some of the data access libraries work different (tests that pass on .NET fail on mono). Most of those nifty widgets and reporting tools you're using in Visual Studio won't work at all, because they rely on GDI or other native Windows services/APIs.

We eventually abandoned mono (and .NET for that matter, other than existing production applications), and we are now mainly using Java (it is the COBOL of the 21st century, after all). Deployments on our JBoss servers work exactly the same, whether they are on Windows, or Linux, and so far we have not encountered a single bug that we had to work around because the vendor's response was "Yes, that's a known issue and will be fixed in the next commercial release." (!!)

Re:Learn C and Python

[bledri]

Python is absolutely unusable on real world projects (any project where you aren't the sole developer) due to that indentation crap.

It's fine if you don't like Python and don't want to use it, but to say that it's completely unusable on real world projects is a bit absurd. And while you may find it hard to read, I think it's obvious because if it looks like code is a block, it is. The main trick to read and follow PEP-8, use a decent editor and write unittests.

Re:Java

[anon mouse-cow-aard]

The other bad thing about Java is that if your program ever needs to use 300 MB, it will *always* use 300 MB forever after.

I am far from being a Java fan, but... if you use 300 MB in a C program, it will *always* user 300MB forever after too. free just returns storage to the process heap, for eventual re-use by malloc within the same process.

Re:I like Python

[walterbyrd]

According to: PEP 8, Style Guide for Python Code, each indent should be four spaces.

http://www.python.org/dev/peps/pep-0008/

The language is irrelavant but the Art is not

[horli]

Learn the Art of Unix Programming, because the programming culture is very different to Windows: http://www.faqs.org/docs/artu/ Programming languages are not so different to Windows.