Slashdot Mirror
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?"
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.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
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 could make the transition very easy for you, depending on what your doing.
Light the blue touch-paper and retire immediately.
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.
Just disrupt the deflector shield with a tachyon burst.
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.
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.
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.
-- The act of censorship is always worse than whatever is being censored. Always.
... 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.
"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.
There's a standard: It's spaces.
From http://www.python.org/dev/peps/pep-0008/:
Free Manning, jail Obama.
And you're stuck GPLing everything or paying for a license before you do any development. Stupid and shitty.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
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.
You don't think enough... therefore you better not be!
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.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
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." (!!)
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
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.
Some privacy policy Slashdot.
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.
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.
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.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Almost, but not quite. The GNU C library, for example, will use mmap to allocate larger requests, and, when freed, will give that memory back to the system and allow the process to shrink.
According to: PEP 8, Style Guide for Python Code, each indent should be four spaces.
http://www.python.org/dev/peps/pep-0008/
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" by Eric S. Raymond (Addison Wesley). Then you will know.
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.
If you don't distribute then how is using GPL tools for internal development illegal?
troll much?
IranAir Flight 655 never forget!
Why, did gcc drop objc? It seemed to work well when I played with it a while ago.
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.
C is a means of actually controlling what your application is doing and knowing how it's doing that. With interpreters its not so easy to tune things. To a large extent the Java/Perl interpreters often bottle neck when dealing with extremely large hashes, some times the interpreters can do good things with memory managers, but then again, the APR has one of these to use also.
Why UNIX?
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.
"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).
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