What Programming Language For Linux Development? 997
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?"
C or C++ (Score:5, Informative)
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? (Score:5, Informative)
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 (Score:4, Informative)
Mono [mono-project.com] could make the transition very easy for you, depending on what your doing.
What do you want to develop? (Score:5, Informative)
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.
Vala (Score:1, Informative)
Checked out Vala? Its syntax is similar to C#, but it performs somewhere between C/C++. It uses the gobject system to implement object oriented behavior and has bindings for many core open sournce libraries like gtk.
Re:C/C++ (Score:3, Informative)
As for C/C++ IDEs I've tried and disliked both KDevelop and Anjuta, Eclipse/CDE and Sun's netbeans based stuff are quite nice, but my poor little laptop doesn't like them.
I ended up settling with Code::Blocks, it's lightweight and native (C++/wxWidgets) and supports all the de-factor features.
Re:English. (Score:3, Informative)
There are some languages that legitimately aren't going anywhere any time soon. This is especially true on *nix platforms.
C, C++, Common Lisp, Java, Perl5, Bash scripts. They were here 10 years ago, and they'll be here 10 years from now.
This is all true however... (Score:5, Informative)
... it is also pertinent to note here that the GNU standards document, section 3.1 [gnu.org]: "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:Learn C and Python (Score:5, Informative)
"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:C or C++ (Score:2, Informative)
Sophisticated graphical applications are no fun to write in C.
I for one would recommend Python, Ruby, or Java for desktop apps that a user interacts with graphically.
And C for low-level system tools (kernel drivers, compilers, and modules that need to interact with hardware directly).
Re:I like Python (Score:3, Informative)
There's a standard: It's spaces.
From http://www.python.org/dev/peps/pep-0008/ [python.org]:
Re:A valuable skill (Score:4, Informative)
And you're stuck GPLing everything or paying for a license before you do any development. Stupid and shitty.
Re:Learn C and Python (Score:5, Informative)
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:
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 (Score:4, Informative)
Trolling? I'll bite.
Free: http://pythonide.blogspot.com/search/label/spe [blogspot.com]
Free: http://die-offenbachs.de/eric/index.html [die-offenbachs.de]
Free: http://docs.python.org/library/pdb.html#module-pdb [python.org] (and included with Python)
Commercial, but excellent (my team uses it): http://www.wingware.com/ [wingware.com]
Commercial: http://www.activestate.com/Products/komodo_ide/index.mhtml [activestate.com]
If you really love Visual Studio for some reason: http://www.activestate.com/Products/visual_python/index.plex [activestate.com]
If you love Eclipse: http://pydev.sourceforge.net/ [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 (Score:5, Informative)
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:This is all true however... (Score:3, Informative)
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:Learn C and Python (Score:4, Informative)
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 [python.org]. 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:C or C++ (Score:2, Informative)
I have mass-deployed apps written in Python on Linux, and it works just fine, if you do things correctly. In fact, the Redhat base distribution includes desktop applications that are written in and require python.
An example is the popular package management tool called: Yum.
I do not recommend python at all for desktop apps. Python is especially itchy about dependencies. Unless you have access to the computers in question and don't plan to mass deploy your applications.
No matter what language you write your application in, you will need to use SDKs and libraries for a graphical application; these will involve many dependencies.
What's nice about Python and Perl is most conventional Linux distributions include it by default.
Even Java has the disadvantage of your users having to have a JRE installed.
You will need to build packages for your application for easy installation, no matter what language you write for, for Linux you would generally build a RPM, which would declare the proper RPMs for Python packages and system libraries that you need installed to run your app.
If you write your program in C, you will need many libraries to program efficiently, in addition to all the common graphics libraries, as the C language includes very little, and it would be a headache without some major SDKs to help.
If you know of a few C libraries, or a C framework that makes it very easy to write sophisticated desktop apps without having to constantly re-invent the wheel, I would be very interested.
In the mean time, C as a language is lacking. While there are some good tools for it, there's not really a good answer to a simple elegant framework for desktop apps that provides about everything you need.
Re:Java (Score:3, Informative)
This is generally only true if you let the Java VM use *FIVE TIMES* as much RAM as a C program. Java needs that much RAM to do efficient garbage collection. Using less than that causes more collection cycles to run, slowing everything down.
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.
Re:This is all true however... (Score:5, Informative)
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 [wikipedia.org] (not to be confused with RIAA). Sensibly written C++ will automatically release memory when it is no longer used.
Re:Java (Score:3, Informative)
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:This is all true however... (Score:1, Informative)
...Object-oriented? I hope you mis-typed. You're confusing C and C++
C is a well-designed low-level portable language which any other language can bind to.
C++ is an unholy beast of a language which will mire you in all sorts of errors the fault of which can be placed squarely on the language designer.
Re:I like Python (Score:3, Informative)
If you're looking for a language that will allow you to write clean code, and accomplish complex projects quickly and easily, Python is the way to go; the white space convention may seem odd at first (I certainly was very suspicious of it), but after a couple hours you'll find it quite comfortable, and you'll only get one indenting error for every ten semi-colons you would have forgotten in C, so it's ultimately a big time saver.
OK, I gotta call you out on this one.
I'm sure I've forgotten a semicolon, but I certainly can't think of a time it's happened. If it does, it prevents compilation. That's important. It's not an invisible mistake. Can you think of even one situation where forgetting a semicolon would still result in code that compiles? I wouldn't be completely surprised if there is, but I can't think of one, and if it exists it's an edge thing.
If you mess up indentation in Python, there's a real good chance it'll still run, but do something different. That's a serious issue.
Look, I'm not ragging on Python, it's got way too many people that love it and have accomplished really nice stuff really fast for me to say it's a bad language. Just, maybe it's nice in spite of the whitespace stuff.
Re:This is all true however... (Score:3, Informative)
You know, you can write object-oriented assembler or c if you want to ... do a search and you'll find all sorts of stuff - people have been doing it for decades.
For example, there's no reason why you can't stick function pointers in an ordinary c struct, and then proceed to use it pretty much as you would any conventional class. You just have to remember to explicitly pass "this" - a pointer to the struct - as one of the parameters, rather than have it implicitly passed (or you can have a macro do it for you behind the scenes).
Actually, on the current c project, you'll find my code littered with stuff like "this->yadda_yadda_yadda." Works fine.
Re:Java (Score:3, Informative)
Almost, but not quite. The GNU C library, for example, will use mmap to allocate larger requests [gnu.org], and, when freed, will give that memory back to the system and allow the process to shrink.
Re:I like Python (Score:4, Informative)
According to: PEP 8, Style Guide for Python Code, each indent should be four spaces.
http://www.python.org/dev/peps/pep-0008/ [python.org]
Re:This is all true however... (Score:3, Informative)
You probably don't need to create your own refcounting scheme now that Boost shared_ptr is being folded into the official standard. It uses atomic instructions (or optionally, plain old integer) and custom deleters, so it can cover virtually any use-case, or be easily adapted to your own.
You can partly solve cyclic references using weak references. As long as you have some top-level entry into the cycle, that can be the strong reference, and the pure cycle can be a weak reference, and you're pretty much set.
Re:Java (Score:3, Informative)
if you use 300 MB in a C program, it will *always* use 300MB forever after too.
Depends on what you mean by "use." If you mean it will have mapped that much into its memory space, that's usually true if the allocator is sbrk() based. mmap() based allocators, on the other hand, can return the memory to the OS.
However, "use" even in the sbrk() case doesn't mean you've used 300MB of RAM. If you never touch it again, it'll be paged out to swap or, if the allocator is written in this way, not have any memory backed to it whatsoever (one can use mprotect() to indicate a range of memory has no access permissions, for example). Yes, those 300MB will be in your address space, but address space != memory.
Read "The Art of UNIX Programming" (Score:2, Informative)
Re:This is all true however... (Score:3, Informative)
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... (Score:3, Informative)
"there's no reason why you can't stick function pointers in an ordinary c struct" Actually, I think the Linux-kernel does this.
The language is irrelavant but the Art is not (Score:3, Informative)
Re:This is all true however... (Score:3, Informative)
Re:A valuable skill (Score:3, Informative)
If you don't distribute then how is using GPL tools for internal development illegal?
troll much?
Re:This is all true however... (Score:4, Informative)
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:Yep, RAII is where it's at (Score:3, Informative)
Why, did gcc drop objc? It seemed to work well when I played with it a while ago.
Choose languages for you, not the platform (Score:3, Informative)
Other people have expressed this in different ways, but:
If you want to achieve a level of excellence beyond the average programmer, learn a number of languages well. If you are developing on Unix, learn at least:
If you had asked about developing on any other system than Unix, I'd have dropped the requirement for shell script programming.
The benefit of learning more than one language is that it leaves you with the ability to consider a problem from more than one point of view, gives you insights into effective and powerful methods, and lets you choose the right tool for the job.
There is nothing more painful than a multi-hundred-line C program that should really be a 20 line shell script or a 300 line shell script that should really be a 500 line Python program. Especially when it comes to maintenance.
Once you have started learning the languages, take care to get to know the associated tools; the profilers, the debuggers, tools like ltrace, strace, valgrind, lint checkers, and so forth. Then research the available libraries for those languages (CPAN for Perl, Boost for C++, etc.)
Oh, and when I say learn a language, I mean use it to write a non-trivial, useful program that you intend to use regularly.
Re:This is all true however... (Score:2, Informative)
The key thing here is that C has a well-defined stable ABI that you can use to interact between different versions of a compiler, even different compilers. In C++ it is possible to do this on some level (look at COM, for example), but this does not work at the larger level.
Looking at Qt3 (don't know if they've fixed this in Qt4), but the interfaces don't have virtual destructors. They can't fix this as it will break program ABI, and not having it opens up to bugs (derived destructor not being called when deleting a pointer to a base class).
And don't get me started on the number of string classes there are, that don't work well with each other that you have to convert back and forth between.
Re:That's what he said! (Score:2, Informative)
Re:A valuable skill (Score:1, Informative)
This cannot be true -- think about it.
"you're stuck GPLing everything" -- the GPL covers distribution, not use or even development.
"or paying for a license before you do any development" -- like I said, when you want to distribute, but not before.
Stupid and shitty FUD, maybe.
Re:There is no such thing as C/C++. (Score:2, Informative)
"C++ suffers from a rather poor reputation because most people don't really know it"
As I've seen about 15 serious bugs in an array class generated by a very experienced C++ developer, I would say that it has a rather poor reputation because only Bjarne and possibly a few others really know it.
Of course, with generics followed up by closures in Java, it might be the case that we need another language that *really* cleans up the C/C++ mess, without introducing too much complexity itself (the downfall of almost all the scripting languages that came after Java).
Re:Why not start with assembly language? (Score:2, Informative)
Hmm...
I cut my teeth on 32 bit assembler on an ICL 4/72 mainframe (similar to an IBM 360 in architecture) with a massive one Meg of main memory.
I think I had most fun with 32 the bit ARM II Risc processor, but I found 8 bit 6502 rather tedious.
I have also done COBOL, FORTRAN, and C, amongst several other computer languages.
But my preferred language is now Java, preferably 1.6 or later (1.7 is still in development).
Why Java? Because I can concentrate more on the programming logic side rather than worry so much about memory resources, it has a lot of library support, and it runs on most real operating systems as well as those marketed by Microsoft.
My preferred development environment is Linux, and I started programming a couple of years before Unix was invented - yes, I'm over 50.
-Nivag