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

It doesn't matter as long as it's on Linux

[alain94040]

First, let me start by saying that the definition of an experienced programmer is that they don't care about the particulars of any given language. Experience means they have seen many languages come and go and they will continue to adapt.

That's the long-term skill that will keep putting money in your pocket. Coming out of college, it's important you know that.

That being said, congratulations on sticking with Linux in a Windows world. Purely from a job perspective, there might be more jobs on the Windows platform, but they are also more boring. So your school is doing the right thing by exposing you to as much Windows IT as possible, and you are doing the smart thing by escaping to the better side.

To answer your question: Linux is not so different from a programming point of view, but it has a set of standard libraries and utilities that can be combined in many amazing ways. I'm old-fashioned, so I still program in C++, but what I would also recommend that you explore are some of the fun scripting languages like Perl. I wouldnt' particularly recommend more modern and high-level languages on purpose: they hide too much of Linux, so what's the point for you?

Learn about true modularity: whatever it is that you are trying to build on Linux, someone already did 90% of the work. You just have to build up from there. Algorithms are the same on Windows and Linux, but that mindset makes all the difference.

Re:It doesn't matter as long as it's on Linux

[Goaway]

The you probably have either not used it much at all, or else you have used it far too much.

Re:It doesn't matter as long as it's on Linux

[DiegoBravo]

>> First, let me start by saying that the definition of an experienced programmer is that they don't care about the particulars of any given language.

That maybe true at some extent, but remember that the definition of an experienced software architect (or corresponding title) has a lot to do with using the right tool for the current situation. Of course what's the right tool is not too easy to decide... more often than not, it is just the one that you (and your team) feels more comfortable with, and almost never that new fancy technology that suddenly turned popular in all the blogs.

Now the original question... developing "for Linux" almost always means automatically developing for any platform (almost any language "for Linux" is open and available everywhere.) The only "linux-specific" exceptions maybe are the kernel and drivers(using C/ASM), but I think you're just thinking of standard use of the languages. From that point of view, the original question turns irrelevant, and you can just select any open language for other desired features; typically application domain, learning curve, fan club, etc...

regards,

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.

Re:C or C++

[mysidia]

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:C or C++

[CSMatt]

Mono has to play catch-up with Microsoft's .NET framework, and is usually a full version number behind. There are also some patent concerns with parts of .NET, especially the non-standardized parts like Windows Forms. The free Java implementations had the same problem until Sun's release of the official Java under the GPL.

So yes, you can develop for Mono if you wish, but be prepared to always have to use an older version of C# and everything else related to .NET if you want full compliance.

Re:C or C++

[mysidia]

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:C or C++

[EvilRyry]

That's only if you need features from the latest versions of MS.NET, mostly in the cases of porting existing applications. Mono is a strong platform in its own right and perfectly suitable for developing Linux applications.

And you do NOT need to use an old version of C#. The compiler is C# 3.0 compliant and they plan on adding C# 4.0 support shortly after it is released.

Thanks for playing.

Re:C or C++

[ThePhilips]

I second. I'm pretty appalled on how clueless new young programmers on resource management.

N.B. As I was taught 15 years ago, programming is art of resource management. That was my teacher's way of saying the famous "algorithms + data structures == programmes," but pitching that all programs all the time use system resources (CPU, memory, files, etc) and your programs will always be as good as your understanding of the resources.

C, if nothing else, teaches how to manage resources and resource management skills are pretty much what defines a good programmer.

After you have grasped on how all stuff is managed and how it really works under the hood, Perl becomes irreplaceable tool at helping managing them very easily. Perl documentation is excellent on telling you precisely what Perl does and how much of what overhead the given code has.

I bring up resource management because it feels stupid that every time pure Java/C# programmers have problems they come to me: most questions amount to "we do this but whole system explodes" (because e.g. they have tried to allocate and object for 0 ... MAX_INT). And when you tell them that you have to eventually free the memory, they act surprised since they have thought that Java/C# handles that all for them and they expect it to e.g. automagically clear the list which keeps references to all the object which code doesn't intend to use anymore. This is primitive template example, but happened more than once to me.

Understanding resource management is quite tiresome and for smaller projects is overkill. But for anything large enough you have to know it and you have to understand it. I haven't seen a single large Java project written solely by pure Java programmers: very very likely that they have number of ex-C folks on the team. I guess the same goes for C# and Python.

Knowing C and Perl - not as languages - but as tools to work with system resources is invaluable knowledge. Learning another way to express your thoughts gives you nothing (I know probably more than 20 languages), but the very and most important is the knowledge of the system resources and how to work with them properly. Some standard libraries (e.g. Java) had put abstraction level way too high to allow to learn about system resources and to write efficient programs.

I like Python

[pembo13]

Works beautifully in Linux and Mac, and well in Windows. May not be the best if you're building CPU intensive apps however.

Re:I like Python

[19thNervousBreakdown]

I don't like Python. Not one bit, but I'm willing to admit that my dislike is mostly aesthetic, which has prevented me from really exploring it, so I can't debate its pros and cons with any pretense at having made an informed decision.

That said, the idea of using whitespace as syntax ... well ... Oh God, I can't lie, it's horrible. But. But! There's ways around it. Ideally a code editor would make line-leading whitespace visible while keeping the rest invisible. Once you get more than one person working on a project, different indentation preferences (expand tabs to spaces vs. not) it's ridiculously easy to have weird mistakes creep in.

Anyway, that's completely the opposite of what I meant to say. A little thing like syntax shouldn't be enough to stop you from getting to know a language. Hey, it's easier to give good advice than it is to take it, and as I understand Python makes a lot of things really easy.

That said, Linux is C, and if you use that or C++ you'll never run into one of those situations where you have to step outside (or rather, below) the library to do what you want to do, which can get nasty quick.

Re:I like Python

[LaskoVortex]

That said, the idea of using whitespace as syntax ... well ... Oh God, I can't lie, it's horrible. But. But! There's ways around it. Ideally a code editor would make line-leading whitespace visible while keeping the rest invisible. Once you get more than one person working on a project, different indentation preferences (expand tabs to spaces vs. not) it's ridiculously easy to have weird mistakes creep in.

Look, this is everyone's biggest beef with python if they are not yet proficient at it. Somehow, we have come to believe that whitespace is sacred and that a language shouldn't tell us how to use it. I'm not sure how to convince you otherwise except this: don't knock it until you have tried it. Once you really delve into the language, you will wonder why anyone ever would program in any other language for general purpose programming.

Now, to more directly address your whitespace concerns:

• You won't miss your whitespace freedom--in fact you impose your own whitespace rules on the code you right already. Python formalizes and enforces this good habit via syntax.
• Since whitespace is syntax, you can use very standard tools to normalize it across a module in a couple of fractions of a second. Differing whitespace habits will never be a problem if you normalize whitespace before you begin coding on a collaborative module.
• You won't mind the whitespace enforcement. In fact, after you go back to code you wrote a few months prior, you will be happy that something forced you to have consistent whitespace. Whitespace enforcement and other features of the language will shift your habits towards writing more reusable and maintainable code.
• You will forget, for the most part, that whitespace enforcement is even part of the syntax once the language becomes second nature to you. In other words, you will so habitually use whitespace correctly (because you are forced to by syntax) that you will not even realize that you are using it as you code. All of the sovereignty over your whitespace that you thought was important to you will disappear because you will forget about its existence.

So give it a try and quit spreading FUD to all of those people who want "control over their whitespace". There are bigger things to think about, like whether you or someone else will be able to comprehend or reuse your code in six months.

Re:I like Python

[he-sk]

There's a standard: It's spaces.

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

The most popular way of indenting Python is with spaces only. The
second-most popular way is with tabs only. Code indented with a mixture
of tabs and spaces should be converted to using spaces exclusively. When
invoking the Python command line interpreter with the -t option, it issues
warnings about code that illegally mixes tabs and spaces. When using -tt
these warnings become errors. These options are highly recommended!

For new projects, spaces-only are strongly recommended over tabs. Most
editors have features that make this easy to do.

Re:I like Python

[CSMatt]

import antigravity

Enough said.

Re:I like Python

[19thNervousBreakdown]

It's not FUD, and it's not my whitespace that I'm worried about. I'm an absolute nazi about getting it right (tabs for indents, spaces for alignment!).

One issue with it is, it's a pain in the ass to get most code editors to leave it alone. Granted, that's a flaw in the code editors, but it doesn't change the reality that if you sit down at some terminal that you haven't carefully configured, editors do all kinds of funky things to your whitespace. Expand tabs to spaces. Strip blank line indentation--I know Python ignores that, but it's still a pain in the ass sometimes. Changes indent levels because of a line continuation. Whatever. Cut/paste code, all sorts of things that you can't see changes. It only gets worse when working with someone who isn't anal about their whitespace, or is anal in a slightly different way.

Whitespace is a great tool for expressing the intent of your code. That said, the intent doesn't always match the rules perfectly. Sometimes, on a continued line you might want to line the next one up with the open paren on the function call. Sometimes you might want to line it up with the second open paren. When your language doesn't care about that, not only are you free to express that "this line is a part of this function call" but if you don't like it, you can run it through a code prettifier. Try that with Python, and you could end up changing what your code does which is, in my opinion (I stress that's my opinion, we're talking about liking a language here, not whether it's good) is just plain wrong.

Look, this argument is total flamewar territory, which is why I'm trying to keep it in terms of liking rather than objective quality. These are my reasons for not liking it, you gave your reasons that you do like it, and that's fine, but I've done enough work in it to know that I don't care for it. Far be it from me to try to convince someone otherwise if they want to program in Python, I just hope it remains the only wide-usage language that cares about the stuff and that I never have to work on a project that uses it extensively (although SCons is the bomb diggity, I love that one).

Re:I like Python

[kaens]

4 spaces. Not 5. 5 is right out.

Re:I like Python

[cowmix]

That'a reminds me of something else I like about Python.. its language is documented.

Re:I like Python

[Jason Earl]

Just for your information, Python isn't picky about spacing inside of open parentheses (or brackets) so you are free to express yourself there. I used to feel the same way as you do about whitespace as syntax, but now I actually appreciate it.

The real advantage to whitespace as syntax is that everyone has to follow the same rules, and the rules are sane. I once worked in an environment where the Perl hackers that wrote the original code didn't believe in indenting at all (they all used nano as their editor). Collaborating with people that don't believe in indenting at all is quite difficult. After that, I was glad to use a language that requires some indentation.

Re:I like Python

[Blakey Rat]

It's not FUD, and it's not my whitespace that I'm worried about. I'm an absolute nazi about getting it right (tabs for indents, spaces for alignment!).

One issue with it is, it's a pain in the ass to get most code editors to leave it alone. Granted, that's a flaw in the code editors, but it doesn't change the reality that if you sit down at some terminal that you haven't carefully configured, editors do all kinds of funky things to your whitespace. Expand tabs to spaces. Strip blank line indentation--I know Python ignores that, but it's still a pain in the ass sometimes. Changes indent levels because of a line continuation. Whatever. Cut/paste code, all sorts of things that you can't see changes. It only gets worse when working with someone who isn't anal about their whitespace, or is anal in a slightly different way.

If this is seriously a problem for you, you're bordering on Obsessive-Compulsive Disorder. And I'm not even kidding around; you actually care whether a blank line is tabbed or not?

If you could get past the OCD, your life would be a whole lot easier if you just let the editor do the tabbing and spacing for you. And you'd work better with others, to boot.

Re:I like Python

[tylerni7]

I know know what the fuss is about brainfuck, it's a bit annoying, but as far as esoteric programming languages go it isn't that bad.

If you like using whitespaces, you should love whitespace!

Re:I like Python

[19thNervousBreakdown]

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:I like Python

[19thNervousBreakdown]

I know a whole lot of really good programmers. That I know of, none of them have tabs set to 8 characters. Most use 4, some use 3. I prefer 2.

Can you change how many spaces a tab is worth in that feature? I can't see it being realistically useful if not. That also doesn't solve the situation of different people with different tab expansion working on a single project.

You can argue all you want that "this is the way tab is" which is great in theory, but completely ignores the reality of how people work. And yeah, people should change how they work if they're working on Python, but it seems a little odd that one language has all these new rules that most editors don't have great configuration options for.

I just don't get the huge benefit of it. Forcing code to be readable? If they didn't use whitespace as syntax, you could run it through tools that fix it up automatically! Plus any programmer that's so lazy that they don't get that right is going to write pretty shitty, undisciplined code, and it's not going to get better in Python. The drawbacks seem to seriously outweigh the benefits.

Is there any other benefit to it I'm not thinking of?

Re:I like Python

[Amazing Quantum Man]

<VOICE type="Jean-Luc-Picard>There are FOUR SPACES!</VOICE>

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/

Language you need to be proficient in.

[Salo2112]

Hindi.

Re:Language you need to be proficient in.

[Anonymous Coward]

I am not having hear of the language insightful, please telling me where it is I can learned of it.

Regards,
Anonymously Cowarding

Re:Language you need to be proficient in.

[Linzer]

Well, go to India and see how little truth there is to this. Real Indians speak English. Of course, they also speak Marathi or Kannada or Tamil or Bengali and so on, but the lingua franca is English, not Hindi.

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.

Re:How much do you want to learn?

[erikina]

No, and due to the lack of momentum, I doubt it ever will be. But you can add C++ to the Gnome. Gtkmm is quite complete, or you can call Gtk+ methods fine.

Re:How much do you want to learn?

[FishWithAHammer]

Yeah! I mean, it's only used in the most widely used desktop environment. And it's only leaps and bounds better than the usual drek.

Why not stick with C#?

[Anonymous Coward]

http://www.mono-project.com/

Re:Why not stick with C#?

[lilomar]

Hm, OP mentions that he already knows C#, but would like to develop on linux. Parent mentions that with Mono, C# is an option for developing on linux, even providing a helpful link. Parent gets modded down.

Sigh. Sometimes /. gets to me...

Learn C and Python

[volsung]

C will give you a good base for learning how the system calls and libraries work, but Python is a lot more fun and better for any program where being close to the metal is not important.

And seriously, if you use a decent text editor, in a few weeks you'll forget Python's indentation conventions ever bothered you.

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:Learn C and Python

[imbaczek]

I've worked professionally with a hammer and it was totally unusable. We've had 4 finger smashes a week. Hammers are absolutely unusable on real world projects; worse, they're counter-productive due to that finger crap.

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.

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:Learn C and Python

[martin-boundary]

That's a bad reason for not blockifying single line ifs. You could just put { } around the statement on the single line, ie write if ( ) { } all on one line, or even if ( ) { }; in case your editor has trouble with indentation. You'll get the same benefits, the compiler will do the right thing, and if later some idiot decides to expand the conditional statement, they won't forget to add the braces.

Re:Learn C and Python

[tomhudson]

That's a bad reason for not blockifying single line ifs. You could just put { } around the statement on the single line, ie write if ( ) { } all on one line, or even if ( ) { }; in case your editor has trouble with indentation. You'll get the same benefits, the compiler will do the right thing, and if later some idiot decides to expand the conditional statement, they won't forget to add the braces.

I like my code clean and concise. If some idiot (your term for them) is stupid enough not to either add braces to blockify the statements or use the comma operator to keep it as a single statement, they'll learn quickly enough. In a modern editor, if you cut-n-paste the code, it will adjust the indent accordingly, and it will be painfully obvious where they went wrong.

... and those extra semi-colons "just in case" are also ugly.

I belong to the school of thought that holds that if it looks ugly, it probably isn't done right. At the office, I'm not ashamed to have others review my code - it's cleaner, more of it fits one one screen at a time, so you can get a quicker grasp of it, etc. Those benefits outweigh the risk of an incompetent coder having a brain fart.

Remember, the purpose of source code is to communicate intent - first, to the compiler, second, to you and anyone else reviewing it. The compiler doesn't care, but people aren't compilers.

Heck, I've seen people who are so unsure of how the language works that they blockify the contents of their case statements, put a break after the last statement in a switch, and braces around every one-line else clause because they're not *sure* as to which "if" the compiler will think it belongs to. These same people always end up being the ones who have code that is indented so much that most of the action takes place in the right-hand margin, and they also indent every parameter that far as well, rather than let it word-wrap, or clean up their code. And they've done so much drag-n-drop of code that it's a mishmash of spaces and tabs.

They inevitably learned on Windows. They feel they need an IDE with auto-suggest, templates for almost every type of project, and built-in "project management" because they can't write a make file to save their lives ... when deprived of Visual Studio, they fall back on compiler shell scripts rather than ask for the nickel tour of "make", or *gasp* buy a book and read it!

Clean, concise code - it's not just good looking, it's cheaper to debug and maintain.

Re:Learn C and Python

[615]

... and those extra semi-colons "just in case" are also ugly.

En garde!

To me, omitting syntax that isn't strictly necessary is a form of premature optimization. It takes more work to determine whether a statement needs to be terminated with a semi-colon than it does to subconsciously terminate _every_ statement; it takes more work to translate between the block and inline form of an if-statement as code evolves; it takes more work to rearrange case statements if some include an implied break.

I used to strive for "compactness" in my code. When I realized how much keeping track of all my own formatting rules and exceptions was costing me brain cycles (plus the aforementioned issues), I switched to striving for consistency.

Mono

[reSonans]

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

Re:Mono

[SirLurksAlot]

This is being modded as flamebait but it is actually a valid suggestion considering that the OP is coming from a MS background. Mono will allow the OP to ease their way into development in in a 'nix environment without having to jump in headfirst with a language or languages that bear little semblance to the tools they're already using. It's all well and good to suggest that the OP start learning C, Python, Perl, $_nonMSLanguageOfChoice but looking at it practically it makes more sense to transition more slowly.

It is also worth pointing out that the parent didn't say anything inflammatory like "Don't, just stick with MS and .NET," or "Linux is for phags!!!!1" They simply offered another option with the suggestion that they start with something familiar. Disagreeing with someone doesn't mean your mouse should instantly jump to the flamebait or troll options.

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.

C/C++

[erikina]

C/C++ are the languages you'd want to go for. They can do *everything*, have great support, are fast etc.

Take a look at Qt and Gtk. They're the two big GUI toolkits. I personally like Qt more, it's better documented and much easier to get running in Windows (and macs). As for the python, there's nothing wrong with its indenting. The problems of the language are much deeper. No language is going to be perfect, it's a tool .. just use it.

As for IDE's, if you're coming from a MS background take a look at the latest netbeans. It's a little slow (fine on new hardware though) and a bit better than Eclipse for C/C++ support.

Re:C/C++

[dkf]

C/C++ are the languages you'd want to go for. They can do *everything*, have great support, are fast etc.

Let's be honest here. C and C++ are very fast indeed if you use them well (very little can touch them; most other languages are actually implemented in terms of them) but they're also very easy to use really badly. They're genuine professional power tools: they'll do what you ask them to really quickly, even if that is just to spin on the spot chopping peoples' legs off. Care required!

If you use a higher-level language (I prefer Tcl, but you might prefer Python, Perl, Ruby, Lua, Rexx, awk, bash, etc. - the list is huge) then you probably won't go as fast. But unless you're very good at C/C++ you'll go acceptably fast at a much earlier calendar date. It's just easier for most people to be productive in higher-level languages. Well, unless you're doing something where you have to be incredibly close to the metal like a device driver, but even then it's best to keep the amount of low-level code small and to try to get to use high-level things as soon as you can.

One technique that is used quite a bit, especially by really experienced developers, is to split the program up into components that are then glued together. You can then write the components in a low-level language if necessary, but use the far superior gluing capabilities of a high-level language effectively. I know many people are very productive doing this.

Re:C/C++

[drspliff]

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:C/C++

[martin-boundary]

You have a good point, but don't forget that C/C++'s (potential) speed gain is not just about writing faster functions, but also about controlling exactly the memory layout of the program. Even if Java or Python is using the same third party libraries as you might use in C, the data will still be wrapped in ungodly layers of memory management garbage. With a higher level language, there's no fine grained control of memory that can ensure that what's needed really fits in L1 or L2 cache.

Re:C/C++

[barton]

I agree about learning how to use libraries, I would also highly encourage you to learn how to use Linux its self. Knowing how the Kernel and the shell interact, and learning to use the shell well will give you a tremendous amount of power.

Linux is tremendously well written, as is bash. Unix, and by extension Linux, has a very good design philosophy. Learning them well will teach you far more about programming Linux than learning a particular programming language.

Re:C/C++

[dch24]

In case you didn't catch the reference:

http://www.cryptonomicon.com/beginning.html

THE HOLE HAWG OF OPERATING SYSTEMS

Unix has always lurked provocatively in the background of the operating system wars, like the Russian Army. Most people know it only by reputation, and its reputation, as the Dilbert cartoon suggests, is mixed. But everyone seems to agree that if it could only get its act together and stop surrendering vast tracts of rich agricultural land and hundreds of thousands of prisoners of war to the onrushing invaders, it could stomp them (and all other opposition) flat.

It is difficult to explain how Unix has earned this respect without going into mind-smashing technical detail. Perhaps the gist of it can be explained by telling a story about drills.

The Hole Hawg is a drill made by the Milwaukee Tool Company. If you look in a typical hardware store you may find smaller Milwaukee drills but not the Hole Hawg, which is too powerful and too expensive for homeowners. The Hole Hawg does not have the pistol-like design of a cheap homeowner's drill. It is a cube of solid metal with a handle sticking out of one face and a chuck mounted in another. The cube contains a disconcertingly potent electric motor. You can hold the handle and operate the trigger with your index finger, but unless you are exceptionally strong you cannot control the weight of the Hole Hawg with one hand; it is a two-hander all the way. In order to fight off the counter-torque of the Hole Hawg you use a separate handle (provided), which you screw into one side of the iron cube or the other depending on whether you are using your left or right hand to operate the trigger. This handle is not a sleek, ergonomically designed item as it would be in a homeowner's drill. It is simply a foot-long chunk of regular galvanized pipe, threaded on one end, with a black rubber handle on the other. If you lose it, you just go to the local plumbing supply store and buy another chunk of pipe.

During the Eighties I did some construction work. One day, another worker leaned a ladder against the outside of the building that we were putting up, climbed up to the second-story level, and used the Hole Hawg to drill a hole through the exterior wall. At some point, the drill bit caught in the wall. The Hole Hawg, following its one and only imperative, kept going. It spun the worker's body around like a rag doll, causing him to knock his own ladder down. Fortunately he kept his grip on the Hole Hawg, which remained lodged in the wall, and he simply dangled from it and shouted for help until someone came along and reinstated the ladder.

I myself used a Hole Hawg to drill many holes through studs, which it did as a blender chops cabbage. I also used it to cut a few six-inch-diameter holes through an old lath-and-plaster ceiling. I chucked in a new hole saw, went up to the second story, reached down between the newly installed floor joists, and began to cut through the first-floor ceiling below. Where my homeowner's drill had labored and whined to spin the huge bit around, and had stalled at the slightest obstruction, the Hole Hawg rotated with the stupid consistency of a spinning planet. When the hole saw seized up, the Hole Hawg spun itself and me around, and crushed one of my hands between the steel pipe handle and a joist, producing a few lacerations, each surrounded by a wide corona of deeply bruised flesh. It also bent the hole saw itself, though not so badly that I couldn't use it. After a few such run-ins, when I got ready to use the Hole Hawg my heart actually began to pound with atavistic terror.

But I never blamed the Hole Hawg; I blamed myself. The Hole Hawg is dangerous because it does exactly what you tell it to. It is not bound by the physical limitations that are inherent in a cheap drill, and neither is it limited by safety interlocks that might be built into a homeowner's product by a liability-conscious manufact

Comment removed

[account_deleted]

Comment removed based on user account deletion

What do you want to program?

[Hapless Hero]

That is the first question you should ask yourself, actually. ;)

One thing you might learn, from a tinkering-with-Linux point-of-view, is shell scripts. Surprised no one mentioned them yet. They aren't really "programming" in the sense of creating apps, but they are fun and a cool part of Linux.

Re:What do you want to program?

[mebrahim]

Why do people usually underestimate shell scripting? Shell scripting is a real scripting language by which you can even create GUI apps for a modern desktop environment like KDE.*

* for example using kdialog

A valuable skill

[MathFox]

Now Microsoft is on the way down and Apple and Linux are moving up:

learn to write cross-platform applications

It isn't that hard, just pick a programming language that's available on both Linux and Windows and try to write programs that work on both Operating Systems. It can be done with some care!

Re:A valuable skill

[siride]

With good libraries or a language runtime, you shouldn't have to make any system calls. And the few times that you do, it can be wrapped in a thin abstraction layer within your program.

Re:A valuable skill

[Jerry]

Exactly, and the best tool to do that with is QT4 from Trolltech.

Using their new, free, Qt-Creator GUI RAD IDE one can write source once and compile for either Linux or Windows.
Qt-Creator is available for free on both platforms.

With careful use of compiler defines one can also, with the same code, write against Oracle and PostgreSQL in the same source and compile on either platform without changing a line of code.

Compile in the static mode and you won't have to worry about missing libraries.

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:A valuable skill

[RiotingPacifist]

If you don't distribute then how is using GPL tools for internal development illegal?
troll much?

Re:Java

[samkass]

I second Java. It's very fast, very portable, well-supported, scales from embedded to enterprise, has great IDEs, is open source, and has a huge body of libraries, sample code, and support.

I'm not sure why you call your fear of Java "healthy". Fear of any particular technology is unhealthy-- it prevents you from making rational decisions about them.

None.

[grapes911]

Focus on techniques rather than specific languages. Make sure you develop a strong foundation and new languages will be easy to pick up later. For a student, the foundation is way more important than a particular language.

Re:None.

[david.given]

Damn straight. Focusing on one language will cripple you. Learn as many languages as you can; you'll be a better programmer for it. Learning Smalltalk taught me about OO. Learning Forth taught me about code factoring and reuse. Learning assembly taught me C (and learning C taught me assembly). Learning Python taught me about the joys of good libraries, and learning Lua taught me how awesome a tiny, fast scripting language can be. And learning Haskell taught me how much I have still to learn.

There are a lot of *very cool* domain-specific languages out there, most of them written in the 80s and 90s --- not much has changed in the world of programming languages in the past decade! --- and they're well worth a look. Even if you never write any production code in any of them, they'll teach you huge amounts.

I See Your Problem

[Nom du Keyboard]

I see your problem. Instead of C# they should have been teaching you Visual Basic.

[Ducks rocks, stones, brickbats, flames, gunfire, flying fanboys, Steve Jobs, and moderately sized precision guided asteroids]

Not only does that let you write in Visual Studio as effectively as C#, but you with very little extra effort you can expand that to also write and maintain Microsoft Office applications including Access written in Visual Basic for Applications, legacy applications written in Visual Basic 6/5/4, and Visual Basic Script based code. And that gives you a wide field of expertise dealing in a lot of the existing code already out there.

Re:I See Your Problem

[Watson Ladd]

He should learn Algo 68. Then he should implement a compiler for it. That will teach him how to program.

C, Java and Python.

[rjh]

This question is remarkably easy.

The UNIX API is written in C. If you don't know C, you won't be able to understand UNIX system calls.

Beyond that, learn Java and learn Python. You yourself say you have a "fear of Java." Sounds like a pretty good reason to learn it. Likewise, you say you're not sure about Python's use of indentation. Sounds like another good reason to learn it.

It is usually good practice to learn one new language a year. These recommendations should be seen as beginnings not endings.

My final bit of advice is to learn PROLOG, LISP, Haskell or Erlang. And by 'learn,' I mean 'become fluent in.' These languages are radically different from anything you've experienced before. Learning how to think differently about problems will make you a much better programmer, regardless of what language you ultimately wind up using in the private sector.

Re:C, Java and Python.

[TheRaven64]

My final bit of advice is to learn PROLOG, LISP, Haskell or Erlang

If the original poster ignores every other post, and every other sentence from your post, and just reads this, then they will have the correct answer.

Learning `Linux' means learning POSIX / SUS. Then it means learning whatever library you use on top of these. It's not an interesting problem. Learning Prolog, Lisp, Haskell, Erlang, FORTH, and Smalltalk will teach you how to think about writing code, even if you never use any of these languages to write a real application.

How about

[smittyoneeach]

"all of the above"
You really should have a good grasp of the concepts of programming languages, so that you can work with the bulk of projects that come your way.
A little scripting, a little functional, a little procedural, a little OO, all combine to make Jack a versatile hacker.

Re:English.

[Chandon Seldon]

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.

There is no such thing as C/C++.

[loufoque]

As usual, people are talking of "C/C++".
However there is no such thing. There is C, and then there is C++. They are very different languages.
C++ suffers from a rather poor reputation because most people don't really know it, and because most code that has been written in it is really C-ish (C with classes) or worse, Java-ish (as if C++ was about OOP...).

Anyway, my point is that it's a language that needs to be learnt separately from C altogether.
It's both as low-level and as high-level as you want, bringing you the best (or worse, depending on how you use it) of both worlds.

Re:There is no such thing as C/C++.

[mgiuca]

Another person complaining about the use of the term "C/C++". I hear this all the time, "it's so ignorant when people say C/C++".

Well perhaps it isn't an ignorant lumping-together of two distinct programming language, but a mention of the common ground between the languages, or shorthand for "C or C++".

For instance, I might say, "You should never dereference a null pointer in C/C++". Here I am not naively referring to C/C++ as a language. I am merely saying that you should never dereference a pointer in C, or C++ -- take your pick which language I am referring to because my statement applies to both.

I could just as well say "types are computed at runtime in Perl/Python", for the same reason.

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

[tomhudson]

C - absolutely. C isn't going away any time soon, and it works on ALL platforms, not just linux (and in many cases porting to bsd is just a recompile and a few extra headers). You'll also have to learn to write your own make files - not a hard job.

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

Everything else is just "for this type of app, these are what most people use ... pick whatever you feel most comfortable with."

Re:This is all true however...

[GreyWolf3000]

Everyone programming for Linux should start with C until they have a solid understanding of how the Von Neumann architecture really works. Once you "get" virtual/physical memory, compilation of C into IL, IL into assembler, and how linkage works, start toying with POSIX threads. Once you really understand the tradeoffs and performance implications of things like dynamic binding and certain aspects of object oriented programming, you can move up to something like Ruby or Python and *really* understand not only what you are doing, but what that interpreter is doing for you.

Re:This is all true however...

[lamapper]

Great post...

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

I remember for years C being considered faster on systems than C++, although I believe over the years the gap, if there still is one at all, has narrowed? What is true, someone share it with me as I am curious? Are there any incompatibilities when using C++ and migrating to different Operating System environments any more like their use to be in the dark ages?

Can you compile C++ down small enough to use in embedded devices or does C++ still pull in libraries that are not needed or too big? My guess is you can exclude the libraries that you do not need, correct? (Not trying to start anyone flaming, I honestly do NOT know.)

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

I know there are Ruby on Rails camps and Python advocates, however does not PHP still run faster than either? (Take the same programmer, writing code with expert knowledge with all three programming languages, would not his final product , from a strictly performance issue in PHP be faster than Ruby or Pythong?)

Considering that PHP was written with the web in mind and delivering web pages...do you really want anything else from strictly performance issues?

Granted I understand that you can probably prototype in other languages much faster...

Also your feel dirty comment, is that because of the ease in which a poor programmer can create unstructured code? If so would it not be the fault of the programmer and not the language specifically? (i.e. Assembly for the 8088, ..286, ..386 and IBM Mainframe made me feel dirty sometimes with they way you were forced to branch, but it was fast...and no I am far from an expert Assembly programmer.

Also from a modularity, library, procedure / function, object perspective, if you have been coding in any of them PHP, Python or Ruby on Rails, would you not have a significant library built up where the library issue becomes a non-issue?

FYI, personally I do not have a preference and simply choose what is convenient for me to use that will get the job done, period. I honestly do not know the nuances between them...and I am sure that there are some.

I do not have any Ruby on Rails or Python experience and am looking forward to learning more about them. To date I have been able to do everything I need to do with scripting and PHP...so my knowledge is very limited and I admit that freely. Further my Perl knowledge has been with simple scripting only, I have not had a 8 hour a day, 5 day a week Perl coding job.... Further when competing in an ACM Programming contest at college, of the 40 programmers who competed, I was 20th...so I have no delusions I know I am an average programmer and am okay with that. I always get the job done one way or another regardless.

Funny off-topic story...the ACM Programming contest: I finished my first problem in a little over 2 hours. A friend of mine who placed, with his team representing our university, second in the world at the international contest in a previous year, finished his first program and had it judged correct in 27 seconds. (Since he had already officially represented the University twice over the years, he was ineligible for that years team and was competing just for the fun of it.) They give you the programming packets and allow you to look at them 10 minutes before the official start time, thus when the clock started he started typing and he was much, much faster typist than my 30 wpm with 5 mistakes, lol. I have nothing but respect for all of you who can put me to shame with your incredibly fast and excellent programming skills. As f

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

[molarmass192]

You're stoking one hell of a flame war here but here's my $0.02 ...

C vs C++ ... there used to be (ie. mid-90s) a very slight advantage for using C in terms of speed, but it's probably narrowed to the femtosecond range on todays CPUs. I like C++ but I stay away from a lot of the stream methodology. I use C++ as an OO C.

PHP vs Python ... same thing as C vs C++. PHP used to be faster, however Python under mod_python is slightly faster than PHP under mod_php. I've used both, and once you get over the wanna-be-COBOL indent thing, Python is more programmer friendly than PHP and Ruby IMHO.

All that aside, I've done some Objective-C work lately and I think I might like Obj-C over C++, due solely to the really nice init/release/autorelease mech for memory allocation. However, for server side, rock solid 5 9s uptime, I'm still a believer in Java.

Re:This is all true however...

[Tacvek]

Embedded device toolchains often let you use a subset of C++ that includes part of the the STL, since EC++ does include an STL Subset.

However, there is no real reason for that, as full C++ can work just fine, assuming a good C++ implementation. I'll admit that on a micro-controller, you might have severe issues with C++ (because even a tiny bit of unnecessary overhead in unacceptable on those), but somewhat less constrained applications full C++ is definitely possible. (Even though many people refuse to believe it, because of major misconceptions about C++ code size and speed, caused by some early and very poor quality compilers and libraries.)

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

[tomhudson]

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

WRT "man" - actual conversation from work last week with regard to "man 2 send" - the c function for sending via a socket:

Me: "Look, instead of asking me all the time, just look it up."

Co-worker: "What website?"

Me: Use "man". It's already in the man pages on your machine.

Co-worker: "How do I do that?"

Me: "Try man man. Read the result."

Two weeks ago, it was "ps" and "kill" (though not "kill -9" :-). Next week, I introduce "apropos", and grep to filter out yucky results. ... kids nowadays ... they think "mc" is a "low-level" tool. I shudder at the thought of teaching them how to make a commit to svn from a terminal .... it's like they can't read ... I have to "white-board" every explanation, or threaten to lart them. Or make them drink the coffee.

Like naming conventions. "I know what UPPERCASE and lowercase are, but what's TitleCase? What's camelCase?" At least they grokked type_name_t for types, UPPER_CASE_IS_FOR_MACROS_AND_CONSTANTS, lower_case_for_functions(), TitleCaseForClasses,camelCaseForMethods() - AFTER I drew a picture of a camel and pointed out the hump (my camel book stays at home). Then gave some more shit over misusing leading underscores (short version - don't).

Then we got into the whole history of "do you precede a class name with a "C" for "Class" or "T" for "Type", and how Microsoft used "CClass" to avoid naming conflicts with their competitor, who was using "TClass", and it doesn't really matter - use your initials for all I care - just be consistent (also lets us know who to blame, if they're too cowardly to include a \blame comment :-)

Re:This is all true however...

[mR.bRiGhTsId3]

Makefiles are easy, Makefile.am(s) are easy. configure.acs are where the pain is. Every time I have to do anything with them, I feel like I want to cry and then end up cutting and pasting a whole bunch of junk from some other configure.ac.

Re:This is all true however...

[Anonymous Coward]

Everyone programming for Linux should start with machine code! Then after that, they should learn assembly. Only after mastering this can they begin to appreciate the power of Fortran! Finally, once they have mastered Fortran, C will finally make sense. Then, 5 years of steady C development, where they achieve Nirvana-like (the band, not the state of mind) understanding of C if they begin by handwriting the C compiler in Fortran and then transitioning it into C once the compiler is able to self-compile!

Then, only then, can you even begin to consider Object Oriented Programming. This should be jumped into arm-pit hair-first. Learn Java first -- Sun designed it to be object oriented to a fault. Then slam on the breaks, realize it's crazy, and start taking concerted steps back until you get to C++, which is C with only a modest amount of caffeine added.

Once all of that is done, you too can begin to program in Ruby or Python, Perl, or Bash scripts. That way, you will have a solid base of high performance programming to throw away when you move into the more heavy duty interpreter languages.

Or really, lets just damn it all to hell and learn Lisp -- functional languages is the way of the future. We can't all bother to learn what the computer is doing. If I program in a fancy-pants language like C, I might have to bother to learn how to write threads, locks, and all that crap to make my programs run fast. In Lisp, I have so little control over what's actually happening, I can just blame someone else when my program is slow.

Yeah. Learn Lisp first.

Re:This is all true however...

[computational super]

C - absolutely.

Another thing that C has going for it is that virtually all Linux apps are written in C. So, if you ever want to install anything from source, and something goes wrong, you'll be glad you know a thing or two about C so you can figure it out (and even submit a patch that ends up being applied to a big, established project like WINE - that's a pretty awesome feeling, let me tell you). All *other* languages interpreters are written in C - it's always worthwhile once you've gotten comfortable with a language like Java to sit down and write your own interpreter in C so you can really get a good feel for what it's actually doing.

So, yeah, I second the parent. Definitely C.

Re:This is all true however...

[BlueCodeWarrior]

...C++...

The problem with C++ is that it's a crazy, crazy language. At first, it was just a superset of C, but now there's all kinds of stuff...it's mutated into a totally different kind of thing. C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.

Also your feel dirty comment, is that because of the ease in which a poor programmer can create unstructured code? If so would it not be the fault of the programmer and not the language specifically? (i.e. Assembly for the 8088, ..286, ..386 and IBM Mainframe made me feel dirty sometimes with they way you were forced to branch, but it was fast...and no I am far from an expert Assembly programmer.

The problem with PHP (and I code mostly in it for a living) is that it wasn't 'designed' at all. Originally it was just a pre-processor, and it's grown into a full blown language from there. This is all well and good, except that there's no sort of continuity to it at all. Naming conventions? (isset vs every other 'is' function starting with 'is_', etc) Who needs them? OO? Sure...ish. PHP is great for getting things done, but I certainly feel dirty after coding in it.

FYI, personally I do not have a preference and simply choose what is convenient for me to use that will get the job done, period. I honestly do not know the nuances between them...and I am sure that there are some.

Always a good way to be.

Re:This is all true however...

[tomhudson]

...Object-oriented? I hope you mis-typed. You're confusing C and C++

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:This is all true however...

[Jeremi]

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

I've done just a bit of Obj-C programming, and I didn't see much advantage of init/release/autorelease over plain old C malloc()/free(). What I mean is, under C, I have to remember to free() each object that I malloc(). Under Obj-C, OTOH, I have to remember to [release] each object that I alloc (or retain). In either case I need to remember to explicitly execute a cleanup/release action to match the allocate/retain action, and if I don't get it right, the object is (effectively) leaked. That means I have to manually check every code-path to ensure that each of my ref-count-incrementing actions is matched by exactly one ref-count-decrementing action, which is tedious and error-prone. It's actually even worse than that, as Objective C has several different conventions regarding how system APIs handle ref-counts... some of them will have ref-counted the objects they return and expect you to [release] the objects when you're done with them, others don't... so it's quite easy to do the wrong thing.

Compare that to C++, where I can (and do) use templates to create a reference-counting system that automatically frees objects at the appropriate time, and no explicit calls to free()/release()/decrement_ref_count()/whatever-you-want-to-call-it() necessary, ever:

void FooBar()
{
MyClassRef myRef(new MyClass); // MyClassRef constructor increments the new object's refcount to 1
MyClassRef anotherRef(myRef); // MyClassRef copy constructor increments the object's refcount to 2
/* anotherRef's destructor executes here, decrements the object's refcount to 1 */
/* myRef's destructor executes here, decrements the object's refcount to 0, and so the object is auto-deleted */
}

With that system, there is almost no way for me to mess things up(*). I don't have to remember explicitly to call any sort of (release) or (dealloc) function for each object I create, because it is guaranteed to be called for me by the destructor of the last Ref object.

So I must be missing some key insight about Objective C's memory management system, because even with reference counting it seems almost as error-prone as C's manual memory management.

(*) One way to still mess things up would be to create cyclic references, i.e. A refs B and B refs A. But that's a problem for any reference-counting scheme, and the solution is either to avoid cyclic references or go with a full-blown garbage collector.... and I've yet to find that I need to do the latter.

Re:This is all true however...

[Jeremi]

The problem with C++ is that it's a crazy, crazy language. At first, it was just a superset of C, but now there's all kinds of stuff...it's mutated into a totally different kind of thing. C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.

That's all true... but I think you're missing something: all of that crazy stuff was added to C++ because it is useful. Of course, any given program will probably only need a small subset of those features, but for the programs that really do need feature X, having it available in the language is a big time-saver.

I've done a good amount of both C and C++ programming, and these days when I need to write in C I generally end up writing a fair amount of code to manually re-implement functionality that I would get 'for free' in C++.

I'd say C++ is a lot like English: a big, overgrown, complicated, mess -- and damn useful if you want to get things done. (If you care more about elegance and simplicity, there is always Esperanto, for whatever good that does you)

Re:This is all true however...

[setagllib]

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:This is all true however...

[quenda]

Everyone programming for Linux should start with machine code! Then after that, they should learn assembly.

Thats all very well, but only after they have a thorough grounding in writing microcode. How can you appreciate and optimise machine code, without knowing how it is implemented?

Anything below microcode is a hardware problem.

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

[bug1]

all of that crazy stuff was added to C++ because it is useful.

If you want crazy stuff that was put there to be useful then why not use perl ?

ducks

Re:This is all true however...

[Wolfbone]

Or really, lets just damn it all to hell and learn Lisp ... I can just blame someone else when my program is slow.

Nope!

http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf

http://portal.acm.org/citation.cfm?doid=1143997.1144168

http://www.eecs.berkeley.edu/~fateman/papers/lispfloat.ps

Yeah. Learn Lisp first.

Good idea. :) I know /you/ were only joking but Lisp has been held back by a ton of widely believed (and massively ironic) mythology and it is very sad. The only thing really wrong with it is the lack of stuff written in/for it because of its grossly undeserved reputation.

Re:This is all true however...

[CBravo]

It would be bad to _not_ know C. It's like driving a car and not knowing about car mechanics. Maybe it won't be your last or most used language. I would be weird to only know perl, java or c++. And while you are at it somewhere in your future, start with it so you won't 'doh' yourself too much. The only drawback is that it won't learn you good style unless you get a good course/book (c can get ugly).

My final goal would be to know a half a dozen languages and be prepared to learn a few of the other two dozen. Call it job security/flexibility. If that is your goal, it is good to understand the hardware (since all programming languages cannot do more than the hardware allows). C is pretty close to the hardware and gives you a better feeling for what hardware can do (and I can't think of alternatives that are a better choice). Although I love assembler, I cannot recommend it. I can recommend to learn about compilers though.

Re:This is all true however...

[Anonymous Coward]

and these days when I need to write in C I generally end up writing a fair amount of code to manually re-implement functionality that I would get 'for free' in C++.

Odds are you're ignoring one of the true fundamental virtues of programming: Reusability.

You see, when you have a rock stable ABI, like C affords you, you can create these things called "Libraries", which future products can then depend on, often times even in other languages like Python and Java. And those products can then be depended on, and so on and so forth until you have a whole working system.

I laugh every time I hear someone say something like "Oh C++ has [blah] "for free"". No, you don't have it for free, someone else just coded it, stuck it in your fat C++ library and now 10 years later people bicker about whether it was actually the right approach to standardize so much of this crap, when so many different "standard libraries" are so totally and hopelessly incompatible.

C's standard library is so spartan that you can write your own "standard library" full of goodies like lists and queues and trees and other time savers, and you never have to get into such arguments to begin with.

Or, if you're incredibly lazy, you can use some of the community maintained, amazing C libraries that already exist. My personal favorite happens to be GLib, but anyone who's written enough code in C to have an opinion on the subject has probably written one of their own or come across one they like as well (such as eGLib in Mono, the Apache Portable Runtime Library in Apache, and the list just curls on...)

So yeah, all of that stuff was added to C++ because it was useful... Just as long as you're working on one project, with one version of [OS], with one compiler...

Re:This is all true however...

[Lennie]

"[Nicole] Kidman was trying to shake zombies off the bonnet of her Jaguar when the car spun off the road."

The first time I read this, I thought it said botnet and thought: I didn't know there were botnets with Mac OS X (Jaguar).

Re:This is all true however...

[Lennie]

"there's no reason why you can't stick function pointers in an ordinary c struct" Actually, I think the Linux-kernel does this.

Re:This is all true however...

[Adam Hazzlebank]

This is absolutely, Object Orientated programming is not a language feature it's a programming methodology. Certain languages have facilities that help support that methodology that's all.

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:This is all true however...

[Hurricane78]

Hmm... I have a completely different point of view.
I program stuff *once*. Including all the things you mentioned above. I abstract them into levels where memory management, linkage, and threads do not matter anymore.
That's why I'm programming in Haskell, O'Caml and Python. In my eyes, Haskell is the perfect middle point between machine code and human logical thinking.
If I would have to write in C, the first thing I'd do, would be to write libraries that do the low-level stuff for me, so I can concentrate on the pure algorithms.
But someone did this already. And they did it really well. So well that you lose no freedom, except when you *want* to interface with hardware (eg drivers/os).

So why reinvent the wheel... again... and again...?

And I really understand what I am doing, without knowing the low level stuff. Because I'm writing algorithms, and user interfaces, and data structures. Not drivers.
So please stop being so arrogant. ;)
Your style has its place. But when you follow the whole philosophy of CS, it should be a minority by definition. :)

Re:This is all true however...

[msclrhd]

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:This is all true however...

[BlueCodeWarrior]

I did learn C++, back in the day when it was a superset...but I stopped, because I didn't really like it.

I mean, how the hell can you write a program these days without OOP,

Honestly... I don't really like writing most things in OO style. I tend to find that most of the time, OOP is just done for OOP's sake, and it's much easier to just program in a procedural manner. A lot of "OO" code is just procedural code in OO clothing.

However, sometimes, it does make sense. Quite a bit of the coding I do is OO code. But that's usually because I'm working with other people who write in OOP style first.

exceptions

I don't like exceptions. It could be that I've been exposed to too much bad Java code, but again, I've found that most of the time, a try/catch block is wrapped around the smallest amount of code that it needs to be. Is

try { func(); } catch (Exception $e) { die("Died calling func: " . $e->getMessage(); }

really better than

#define TEST_ERROR(f, msg, ...) if(0 == f(__VA_ARGS__)) { fprintf(stderr, "Fatal error: %s", msg); }
TEST_ERROR(func, "Error calling func")?

generic containers/algorithms

Nice. But hardly neccesary.

user-defined data types

structs?

I mean hell, C can't even deal with strings in any reasonable way.

For your value of 'reasonable', anyway. I'll admit that it requires a tiny bit of extra knowledge compared to other languages, but it's certainly not difficult, and follows pretty logically from C's core ideas.

Re:This is all true however...

[Wolfbone]

Yes, as the experiments clearly show: as long as you write tiny numerical computations and programs that require code-as-data anyway.

Those papers do not show, and their authors do not state, that such a qualification is justified...

toy examples aren't going to convince anyone.

...and if they had, they'd have made laughing stocks of themselves:

http://www.lispworks.com/success-stories/raytheon-siglab.html
http://www.franz.com/success/customer_apps/eda/amd.lhtml
http://www.franz.com/success/customer_apps/data_mining/itastory.php3 (also: http://www.itasoftware.com/careers/l_e_t_lisp.html?catid=8 )

etc.

Re:This is all true however...

[Wolfbone]

It is the absence of the qualification that requires justification.

Why would the Lisp compiler do well on 'small' examples, like the C compiler does, but underperform it on 'larger' examples? Perhaps there are reasons to expect such behaviour but rather than answer a comp. sci. illiterate like me, if you really believe the authors of those papers have been making such serious errors I think you should write your own paper. And if you haven't got the time or inclination to do that, perhaps you could at least explain your criticisms to these fellows: http://books.google.com/books?id=8Cf16JkKz30C&pg=PA21&lpg=PA21 They appear to have used similar reasoning - toy examples and extrapolation - and it looks like they're embarking on a major project to make a better performing R-like system with Common Lisp. But if Lisp really doesn't scale up well, that could turn out to be a futile ambition and a horrible waste of time of course.

but with excerpts in #3 like: ... I can only guess that ... the performance penalty of Lisp must have been significant.

Our QPX search engine is engineered for speed, speeds that must not be lower than using C and where huge amounts of data must not be bigger than packing them in C structs. Still, QPX is very complicated, and driven by individuals who write large bodies of code. Lisp allows us to define a wide variety of abstractions to manage the complexity, and at the same time we get the speed we want. Once QPX is compiled, one cannot easily tell the machine code from the machine code compiled from C.

(from the other ITA link)

Of course you may have guessed right about ITA's case anyway (and undoubtedly there do exist situations in which Lisp is inadequate for performance reasons - even C is sometimes) but whatever the reasons ITA have for using C and Java as well, there are no similar excerpts in #1 or #2 (or in other examples) and it seems to me they are hardly 'toy' examples.

I am not trying to knock Lisp

Sure - you're just knocking the papers I linked to - and it seems to me that is just as well considering there are at least some anecdotal 'real world' counter-examples to your Lisp performance worry stemming from your (possibly justified) criticism that extrapolation from those papers' findings is, at least logically, invalid. I have always found Lisp easily adequate performance-wise for my own use - but that's just anecdotal too of course.

Re:This is all true however...

[andhow]

Compiler optimization uses static analysis to find program invariants which allow the compiler to remove run-time overhead, thereby achieving efficiency. To do this, the analysis must examine all possible control flow paths. Increasing the size of a program can only add more possible executions to examine so, almost by definition, making a program bigger can only hurt optimization. When a program is small enough, you can express practically any invariant in the world in predicate logic, use weakest preconditions to derive necessary conditions for these invariants to hold, and throw the resulting implication to an automatic theorem prover! But of course this method doesn't quite scale. To see a classic example, look at automatic parallelization. They have had it solved for toy examples for years!

... your (possibly justified) criticism that extrapolation from those papers' findings is, at least logically, invalid.

If you have ever worked with static analysis, my criticism is vacuously true.

Please try to keep up.

[John Hasler]

Erlang and Haskell, of course. Just the other day here Intel told us all how only functional programming can save Moore's law.

Re:Java

[Matheus]

I was also curious about your "healthy fear of anything Java"
Really? You are way too young to be developing "healthy fears". Java, like *every other language, has its issues but there is nothing abnormally nasty about it to treat it like a plague. Specifically relating to your .NET experience Java is a significantly more mature language than C#. You are more likely to get better performance and stability out of Java's virtual machines just because they've had more time to be beat up by a vast community of developers. M$ did a good job of getting C# out the door but like any child it has some growing up to do.

As many of these posts have mentioned: Don't limit yourself. Try everything. Obviously for Linux purposes knowing C (and a healthy amount of Bash scripting and Perl) is useful purely because the OS is built on it BUT for developing applications on top of it many languages have benefits depending on what you are trying to implement and so eliminating anything from your list will hurt you in the long run.

"Free your mind and the rest will follow"
-En Vogue

Re:Java

[binarylarry]

That's because you can get within a few percentage points of native code performance with Java's VM.

Most of the people who are hesitant to use "managed code" are old codgers, elitist fruits and brainwashed newbies who have to be forced into new paradigms, instead of being genuinely interested in new trends.

It's best to avoid types.

C first, then whatever you want

[darkwing_bmf]

C first. It is the lingua franca of the Unix world. Even if you don't use it for yourself, you have to understand it because so much is written in it. And if you don't understand it, no one will take you seriously. One of my first Linux installs was so I could teach myself C cheaply and I needed a free, as in beer, compiler.

Then after that, any language that you think might be interesting. Try multiple languages. I personally like Ada and there's a free GNAT Ada compiler for Linux.

Fear of Whitespace

[bitspotter]

I just started learning Python a couple of months ago (I come from a Perl/PHP web development background).

Really, get over the whitespace-indentation thing. It's such a small thing to get hung up on compared to how much more powerful, elegant, and flexible the syntax is (for starters). That, and it encourages you to indent source code properly anyway.

IndentationError

[ksw2]

If something like indentation is a show-stopper for your choice of language, then you are missing the point.

Computer languages are about data structures and idioms for manipulating them efficiently. In contrast, whitespace is a cosmetic, superficial thing.

Yes, I adore Python. (I wish I had paid attention to it ten years sooner than I did.)

Fortran or Assembler

[www.sorehands.com]

REAL PROGRAMMERS SPEAK IN UPPER CASE.

Real programmers program in FORTRAN. If it can't be done in FORTRAN, then write in assembler. If it can't be done
in assembler, it's not worth doing!

http://www.sorehands.com/humor/real1.htm

LOLCODE

[Anonymous Coward]

Develop in LOLCODE:

http://lolcode.com

"HAI WORLD" Example:

    HAI
    CAN HAS STDIO?
    VISIBLE "HAI WORLD!"
    KTHXBYE

I'm doing contract work right now, and won't my client be pleasantly surprised to see the project completed in LOLCODE... ROFLMAO!!! I can haz milestone payment?!?

Indenting code

[photonic]

From the summary:

I'm not too sure of what I think of Python's use of indentation to delimit blocks.

Have you ever actually tried using python? I am very much in favor of capital punishment for everyone who doesn't properly indent his code in other languages anyhow, so being forced to indent in python wasn't really a problem for me. I do not understand why people keep bringing up this argument, there are valid reasons why python was designed this way and it is something you get used to after 5 minutes. And if you really insist on using braces, you can still use them:
if button_pressed: #{
launch_missiles() #this line must be indented but slashdot does not allow me to
#}

Re:Indenting code

[kabloom]

this line must be indented but slashdot does not allow me to

A very good reason to use a language that delimits its blocks explicitly. C will work great even in forums that lose their linebreaks. (Perl too? I don't use it enough to know.)

Re:Indenting code

[photonic]

This says more about slashdot than about python. If you want to copy complete programs, you always download the source files themselves, so you dont have this problem. There are plenty of websites that contain code snippets (the online python manuals, various blogs, ...), which do preserve the indentation which can be pasted directly into a python interpreter. There might be some annoyances sometimes, but if you write your own code in a decent editor the forced indentation is more a blessing than a curse.

Programming for Linux?

[narcberry]

Your first problem is thinking a programming language is for linux development, and perhaps another is for windows development.

What you should actually be asking yourself is, what is the problem I'm trying to solve, not what is the os I can use.

Your question as stated has a million unquantifiable answers (heck, if you don't have a problem to solve, ASP.NET is just fine on linux). Ask the right question, what programming language should I use to solve problem x, and now you will get intelligent answers, and at least one remark about turing complete languages are all turing complete.

/rant off

Tabs are EVIL

[pem]

If you can't configure your editor to auto-convert tabs to spaces, and you can't find a different editor you can work with and you can't keep your hands of the tab key, then you can't work for me...

Re:Tabs are EVIL

[nschubach]

Therein is YOUR problem, not mine. Tabs are evil only if the programming language makes them evil. Tabs are a highly efficient way to program and keep indentation. It allows developers to view the code a bit more in their preferred style so it's easier for them to read (2 spaces, 3 spaces, 4 spaces or I've even seen 8 spaces.) Not using tabs makes it more difficult to edit the code or share code. If you create a template of code that's indented using spaces, you pass me a piece of code that doesn't look right with my code and is harder to read in the overall scope of things. Also, if you use formatting to show your intentions in the program you probably need to rework your program to better make sense or make use of the language constructs.

When I get a source file indented with spaces, I then waste time converting these spaces (and the alignment specific readability) you made. I say alignment specific readability because you thought it would be more readable to put all your arguments on a line of their own and hit just enough spaces to line them all up just right so it's readable for YOU on YOUR screen. Now I get your code and it only uses up 25% of my screen width and I now have to scroll up and down more because of your style.

By using spaces (and according to your post "tone"), you are essentially telling me that you are an arrogant programmer only thinking of your own stylistic ways and methods and that you will never work well with other people unless they do it your way. Even then, you will likely criticize that person for spacing something wrong. You strike me as a micro management type person.

Ideally, my perfect language/editor would format the file as it was loaded. Source code would not rely on indentation to function properly and line feeds would be meaningless. Each source file would be saved compressed without formatting. Each developer could open that file and it would format to their style.

Re:Java

[FishWithAHammer]

Managed code performance is good enough for essentially anything aside from high-performance video games (and even that isn't far off).

"Java is slow" is a stupid old myth. Does it not occur to you that JIT compilers compile to native code?

Re:Java

[FishWithAHammer]

Specifically relating to your .NET experience Java is a significantly more mature language than C#. You are more likely to get better performance and stability out of Java's virtual machines just because they've had more time to be beat up by a vast community of developers. M$ did a good job of getting C# out the door but like any child it has some growing up to do.

Rampant bullshit. You'll get somewhat better performance out of HotSpot than the Microsoft or Mono CLRs--not that much better, but definitely better--but in almost seven years of using .NET regularly (I started in March '02), the CLR has not been the cause of a single crash in anything I do. "Good job of getting C# out the door" my ass, you troll, it's been just shy of seven years since its release!

(And if you want to be taken even remotely seriously, drop the childish "M$" crap.)

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:Java

[modmans2ndcoming]

It is more mature, but C# fixes a lot of what is wrong in Java (lack of automatic boxing of primitive types anyone!).

To compare them, they are both completely adequate for the same problem domain. Also consider that Java 2 was a reboot of Java so you kind of have to go off of that as your starting point, with that taken into consideration, you really only have a few more years of maturity for Java.

Why not start with assembly language?

[Joce640k]

...it's the only way to be sure.

Re:Why not start with assembly language?

[that this is not und]

I am mostly an Assembly Language programmer and it can teach some bad habits. I don't generally trust anybody else's code, so end up coding up everything from scratch. It's a solitary practice. That said, 'pointers' and other things that seem weird and remote to many people are painfully obvious if you started out in Assembly.

Bare hardware and real memory addresses rule. However, a bare-metal assembly language programmer will mostly work with embedded controllers in this day and age. Yay for the little 8 bitters and even the 4 bitters. There are still billions being deployed.

Re:Why not start with assembly language?

[johny42]

Right, and don't even start with this computer platform until you've mastered the Turing Machine!

Re:Why not start with assembly language?

[kmsigel]

>I am mostly an Assembly Language programmer and
>it can teach some bad habits. I don't generally
>trust anybody else's code...

I find that (not trusting other people's code) to be a good thing, no matter what language/platform you are using. I use assembly, C, and C++ for embedded and desktop programming. To the greatest extent possible I write all code myself.

For x86 embedded work, that means writing the MBR (and everything else on up) myself. For Win32 work, that means using a basic application framework that someone else wrote (and I've spent 13 years fixing and improving) and doing pretty much everything else by myself. (To be fair, I also use the IJG library for JPEG encoding/decoding. The IJG library is good stuff.)

Re:Why not start with assembly language?

[Lumpy]

assembly is for pussies.

real programmers fire up a hex editor and enter the hex codes into the file directly.

No, I'm not kidding. I know of two that work on enbedded hardware that would program a 6802 processor completely in hex on a keypad from memory. they did it so much they never wasted time testing things by writing it down then converting to hex. they just went... "let's try this!" and started typing away..... it was amazing.

Re:Why not start with assembly language?

[Jeppe Salvesen]

It's better in the long run to write unit tests for your code, than spending time re-implementing what others have done for you.

Re:Why not start with assembly language?

[VGPowerlord]

I find that (not trusting other people's code) to be a good thing, no matter what language/platform you are using. I use assembly, C, and C++ for embedded and desktop programming. To the greatest extent possible I write all code myself.

So, you take the time to rewrite things like stdio?

Re:Why not start with assembly language?

[Nivag064]

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

Re:Why not start with assembly language?

[mathew7]

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.

In your case it probably is not valid, but the problem of new SW is that they seem to forget everything about resources. This is especially true to those MS IDE/tools users that have never seen/studied assembly. And with java and C# (never used it actually), it seems that pointer operations (which is the hardest for new programmers) seem to disappear.

Re:Why not start with assembly language?

[kmsigel]

What you say is catchy, and sounds like it should be true, but it isn't.

When great programmers are creating truly great (and novel) applications the time to learn, fix, and modify someone else's code to do what you want it to do is similar to writing your own code. And in the end, if you are a great programmer, the code you write yourself will be better than what you found and then had to fix/modify.

Of course I'm not talking about re-writing a TCP/IP stack, a NIC driver, a graphics library, a thread scheduler, or the like. I did all of those things in part because I enjoyed it (I was sort of on a sabbatical) and in part because I knew it would pay off for me in the long run (I've already used my embedded OS on two substantial projects).

But this myth that whatever you are doing must have 90% of the code already written somewhere "out there" is just that, a myth. Yes, if you are doing something boring that is 90% just like a bunch of other things that other people have done then maybe that's true. For what I do, it is not true.

Re:Why not start with assembly language?

[Hognoxious]

A good software developer is like a skilled mechanic or manufacturer. He knows which pre-existing parts to use when fixing or creating a car.

A great software developer builds new kinds of cars. If existing parts were sufficient for that task, he isn't building something new.

Unfortunately, pointlessly rewriting something can cause a programmer to think he's in the second category, when in fact he's barely in the first. This does happen, I've cleared up the resulting mess more than once.

If existing parts were sufficient for that task, he isn't building something new.

Not at all. You can create something new from a combination of existing components. Conversely, if you reinvent the wheel, it's still just a wheel.

Re:Java

[Zan Lynx]

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.

APL

[cpscotti]

APL for sure... its easy to learn, fast and extremely useful!

Re:Java

[alanwj]

The reason to fear Java doesn't really have much at all to do with any merits of the language itself. The reason you should fear Java is that it doesn't really add anything to your resume to distinguish you. There are, frankly, a LOT of extremely mediocre programmers on the market, and a common attribute they share is that they only know Java.

That said, DO learn Java. Not knowing how to use one of the most popular tools in your field is also not a smart idea. Just don't by any means think that your education is done.

For what it's worth, here are the four major things I look for when interviewing programmers.

1. Do you know C? (whether you are going to be programming in C is irrelevant)

If you don't know C, you probably have very little understanding of how computers work. C is language you can depend on to be on pretty much every platform; C is the language external APIs and foreign function interfaces are specified in; C gets the job done when all your layers of abstraction fail you.

2. Do you know a functional language such as Lisp, Scheme, or Haskell?

Programming in a functional language changes the way you think about programming in general. Programmers that understand functional programming generally are able to produce better solutions to problems even in imperative languages. Structure and Interpretation of Computer Programs is available online for free. Read it today and improve your skillset.

3. Can you write a compiler from start to finish?

The theory surrounding language parsing (automata, state machines, regex, grammars, etc) is fundamental to computing. In fact, computing itself is usually defined in terms of it. Once you understand it, you find you apply it all the time.

The ability to translate high level languages into optimized machine instructions requires that you understand your platform at every level. This is important because it lets you understand the tradeoffs you are making when you choose one tool or method over another.

4. What is your current personal project?

What your project is doesn't matter all that much, as long as you have one. Good programmers are usually always working on some personal project that excites them.

Don't write off the Java *platform*

[ChrisWong]

I know you hate Java, but do reconsider. Since you have established your .NET skills, you will probably cover the vast majority of the universe of software job opportunities if you can add Java to the list. Of course there is a lot valid stuff outside of .NET and Java, but those are the dominant players, professionally speaking.

You won't be locked into the Java language. The Java ecosystem is much larger than that: the Java class libraries, of course, but also Spring, Hibernate, J2EE, the Apache goodies, Eclipse, debuggers, profilers, monitoring etc. If you expect to integrate your software with a future unknown codebase -- perhaps by acquisition or merger -- there is a good chance it will be Java-based.

Ruby, Python, JavaScript and other languages do run on the Java JVM, but I suggest taking a look at languages that really sprung up from Java, like Groovy and Scala. Groovy appeals to the dynamic typing camp, and Scala to the static typing camp. The advantage with these languages is that they integrate into the Java platform just about as well as the Java language itself. You can write real Java-visible classes in these languages that integrate seamlessly with the rest of the Java platform, including annotations, generics and enums. Other languages can run in the JVM and call Java classes, but it's likely a one-way street. Java classes cannot call, say, a JavaScript class (JavaScript has no classes!).

My own experience has been with Groovy, which claims Smalltalk, Ruby and Python as its inspiration. It's much more productive, powerful and readable than Java. Yet it integrates well with all things Java. And yes, it's production code deployed on Linux.

This question isn't about Linux.

[SanityInAnarchy]

Yes, you're going to make things harder on yourself if you try to use C#, or Visual Basic, etc.

And yes, knowing C will help. A lot.

But the answer is the same, no matter what platform you're on. The answer is, "It depends what you want to do."

For instance: It helps to know C, but if you'll be doing, say, web apps, it would be ludicrous to be doing it in C. If, on the other hand, you're doing things with hard realtime requirements, C might be the upper end of what you'd use. And there's all kinds of things in between.

Re:Java

[snowgirl]

On top of that, it doesn't take much juggling to get your app to run on multiple platforms.

One would think, right? But it's actually NOT that much easier to get your app running on multiple platforms. I shall describe to you three projects that I wrote in C, Java, and ObjC respectively.

The first app was written in C, it was a webserver. It actually was really easy to port, because I used basic C libraries. About the only problem was that on Solaris, I had to include some libraries that I didn't on the other *nixes. The other *nixes? Linux, OpenBSD, and Mac OSX. It all worked like a charm, no cross platform issues. I have no doubt it would have run just as fine on SFU (services for Unix) on Windows, or if one had the right compiler, like djgpp, it would work just fine as well.

I wrote a raytracer in Java for a graphics course. I already had the vector class, which took care of most of the code, so most of was super easy to write. Just make a vector, cast the ray, just a bunch of math that I had already written into Vector and Matrix libraries. There was just one problem. How do you draw a pixel in Java? Oh yeah, that's right, there is no way to do it. Some implementations allow you to do a drawRect() of size 0,0, but others interpret that as a "draw nothing"... thus in order to actually draw my image correctly across Linux, OSX, Solaris, and OpenBSD, I had to draw 4 times as many pixels as I had to, by doing a drawRect large enough that it would actually draw something on each one of the OSes. And these are all POSIX systems? WTF?

Last, I got sick of the performance of my Java raytracer, as well as the inconsistent undefined behavior of drawRect() with a height/width of 0,0. So, I ported my raytracer to ObjC. I started with the vector library, things went fast, and easy. It also worked perfectly on OSX, Linux, OpenBSD and Solaris. It used SDL for the graphics (which actually has a defined behavior that allows one to draw one and only one pixel). And the standard POSIX thread library to make it multithreaded to draw even faster.

Point of all of this: The LIBRARY SPECIFICATIONS are the most important thing to be defined across the board. Any unspecified behavior in your library results in being able to write code that won't work on a different implementation of that same library. Also, without a Java VM, the java raytracer wouldn't run on that system, which means it is no better than requiring the ObjC library, and SDL library.

Lern LOGO!

[ArcadeNut]

I hear it's going to make a comeback as soon as they add support for DirectX 10!

PEN DOWN
FORWARD 10
TURN RIGHT
FORWARD 10
TURN RIGHT
FORWARD 10
TURN RIGHT
FORWARD 10

Re:Java

[binarylarry]

Java was designed for networked applications.

It shows because the Java stack and libraries written with it rarely have built in flaws that allow computers/servers to be compromised.

So there's one reason and it's a big one if you think about it.

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.

Does it matter, though?

[Gazzonyx]

I thought that the operating system doled out the memory... that's the reason that once Firefox uses 300 MB of memory, it will always use 300 (on windows, I haven't bother to check under any other OSes). So, even if the JVM deallocated the GC'ed memory, Windows will keep that chunk of memory earmarked in case the JVM asks for it again. All that being said, you are correct, everything is a time/space tradeoff and the logical choice is usually to trade off space for time.

Re:Java

[skeeto]

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.

Re:Java

[QuasiEvil]

I don't define myself as "hesitant" to use manage code, I define myself as "where's my pointer?" You're right, I'm generally skeptical at best of new trends. My job isn't to be trendy or try new stuff - it's to solve problems in something standard, efficient, and sustainable. C has proven a language capable of nearly every practical task thrown at it for the last 30 years. It is easily the most portable ever created. Why would I want to switch?

Yes, there are those that say I shouldn't be tied to a programming language, because they come and go. That's absolutely true, but I see no reason to use new tools if they offer no substantial advantages to my problems over the old toolsets.

I'm sorry, I can manage memory and manage pointers. I do not need to incur the penalty and nuisance of using java. C very closely resembles how the underlying machine works (at least for Von Neumann architectures), and I think that's a very good thing for programmers.

Re:Java

[dacut]

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.

Re:Java

[wtarreau]

"Java is slow" is a stupid old myth. Does it not occur to you that JIT compilers compile to native code?

Ahah ? You should tell that to people who develop applications delivering only 1000 pages per second on a 8-core machine where equivalent plain-old C easily delivers more than 10000 pages per second on a single core of the same machine. Surely the GC is at fault, everything related to object management is at fault, the memory footprint voiding all cache efficiency is at fault, in summary, the language is at fault.

An yes, that's what I see in enterprises.

I think the real problem with Java developers is that they have been told that what they did was fast, and they believe it. But let's face it : when processing an HTTP request burns ONE JOULE there is definitely a problem. No wonder why datacenters are filling that fast...

Everytime a Java developer tried to prove me wrong, he showed me he was able to reach performance levels I was able to reach 10 years ago on an obsolete machine. "Look: 500 pages per second on this small 4-core xeon !". Well, I do 2000 on my 2.5W, battery-powered Geode computer, and that is small.

So please stop spreading bullshit about efficiency of such things, there are people who believe you and now we find their crap sucking all the power of datacenters.

Read "The Art of UNIX Programming"

[astro-hillbilly]

Read "The Art of UNIX Programming" by Eric S. Raymond (Addison Wesley). Then you will know.

Re:Java

[dacut]

"Java is slow" is a stupid old myth.

Java is still glacially slow at startup. Even before you get to the JIT stage, it has to decompress the JARs, extract the class files, validate them, and then start executing the bytecode (or incur a JIT compilation cycle and then execute native code). Validation can take a fair amount of time -- doing so requires each method to be simulated (making sure the stack stays coherent no matter how a given instruction is reached, for example) -- though the Hotspot JVM lets you disable this. A fully native application, on the other hand, just maps the files into memory, applies relocations (if that's even necessary these days), and then starts executing.

For server code, I don't care about Java's startup time. I'm usually checking out a number of database connections, catching up on logs, and doing a zillion other things which make the JVM startup tasks insignificant. For a small command-line utility, on the other hand, the difference is very noticeable.

Also, even in native code, Java is performing a number of extra security and boundary checks which equivalent C code usually doesn't have. I consider this a feature.

RUBY ruby RUBY ruby RUBY!!!

[fluido]

I completely share your disappointment at Python's usage of indentation as syntax. I gave python a deep review when it appeared, around '97 or '98. I was fascinated by the concepts, I could see there was some important element of progress in it. But I concluded that I could never use the language because of the indentation problem. It was (and is) unacceptable that I would end up changing the logic of a program by inadvertently deleting an invisible tab. It is the duty of the editor to fix the right indentation of my code, and it is an invaluable debugging tool to press tab in my Emacs screen and find out what the right indentation should be. This is obviously impossible if it is the change of indentation itself that marks the end of a loop or of an if clause. Really really really impossible to adopt.

I had hopes that the Python developers would eventually give in and allow the (maybe facultative) usage of a reserved word for closing loops and clauses. This has not happened. Worse: it has become a matter of pride, a distinctive aspect of the language.

I went on with my mostly C with limited Java usage. Until in 2005 I decided to give Ruby a try. From that moment, all my projects have been written in Ruby, with substantial C inserts. After writing almost 100.000 lines of Ruby code, I am more awed than ever about the qualities of the language. It goes without saying that you use keywords to close loops and clauses in Ruby (either the end keyword, or C-like curly brackets, at your choice.)

A few reasons for giving Ruby a try:

• Ruby is from the same generation of Python, only newer. Same zeitgeist, better implementation.
• Ruby comes from Japan, where it is developed with typical pragmatic attitude. The language contains what is useful, often with more than one possible alternative (you can create your own distinctive style).
• Ruby implements the object-oriented paradigm in a full, no-compromise way, which is at last capable to deliver the results (in terms of ease of coding and adherence to thought processes) that were promised by the theoreticians.
• Ruby has a lean, very efficient way of including C code. it is really possible to have the best of both worlds. If you need to use a C library, it is easy to write your own bindings, provided they have not already been written by someone else.
• Ruby is very net-aware. Generic tasks can be implemented in a few lines of code.

You should take great care to distinguish between Ruby and Ruby on Rails. The first one is the language. The second one is an application based on the language. While it is obviously good that RoR gained such a notable momentum, it must be remembered that Ruby is a language as of itself, with great qualities that can be harvested even if one does not use RoR. I, for one, do not use RoR.

That's what he said!

[pjt33]

What is C other than a slightly higher level assembly language than nasm?

Re:That's what he said!

[eneville]

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.

Re: Quality of generated code

[Douglas Goodall]

I was one of the longer holdouts, writing assembler long after C compilers got really good. This went on until the day I used the compiler switch to see the generated assembler code coming out of the compiler. Addressing modes I was aware of but had never bothered to use were accessing carefully aligned data items in a structure referenced off a base register. Several times I still wrote better code for specific routines, but overall the code generators are fantastic these days. If the profiler says you are wasting too much time in a specific routine, it might make more sense to find out why the compiler is not optimizing correctly, rather than counting the cycles of hand written code. Knowledge of assembly can help you use the C compiler more efficiently, but we are long time past the point where we should be coding large amounts of code, "by hand". Smarter people than I have spent hundreds of man years on the code generators, and I for one would like to leverage off that work.

Re:Java

[IkeTo]

import slashdot.reply; public class Reply { public static void main(String[] args) { try { I hate Java for one single reason: to express any idea you need 3 times as much code. } catch (Exception e) { and the whole idea of checked exception is simply silly. } } }

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.

Web Software...

[g4b]

I disagree. PHP might have been advisable 5 years ago, atm. it is wiser to stick to Python, Java or Ruby on the Web Platform. After Django and co. nobody really considers PHP to be a wise call.
On the Front End again things like Laszlo or better GWT (Java written Forms for HTML translated in pure JS) are worth looking.

Basicly coming from a Windows world and knowing .Net I however don't understand the problems with Java. Especially for Servers and in near future for games and 3d web-apps (not applets, but java hot-start apps) Java will and is the way to go. Also learning the strength of eclipse is in my eyes a very good step for each coder.

The indentation problem of Python is just something you have getting used to. After getting used to it, you start to love it. After loving it, you start to write python apps even where you are not supposed to...

Re:Yep, RAII is where it's at

[brainnolo]

Actually he is mentioning Linux. GNUstep is a really good platform for experimenting with Objective-C. It should be stable and full-featured enough for the needs of learning. I started coding Objective-C on that about 6 years ago. Over time I switched to Mac, which of course provides me with a more stable environment for Objective-C programming, yet GNUstep was very useful and I guess it evolved since I last used it.

Platforms where C does not work

[tepples]

C isn't going away any time soon, and it works on ALL platforms

C doesn't work on Xbox 360 XNA; only C# works for that. C doesn't work on smart phones that use J2ME MIDP; only Java works for that. C doesn't work for the client side of web applications; only JavaScript and ActionScript work for that. C doesn't work for the server side of web applications installed on shared hosting; generally, interpreted languages whose names start with P work for that. In general, C compilers targeting sandbox virtual machines such as these aren't high-profile, if they exist at all.

Re:Yep, RAII is where it's at

[Curtman]

Obj-C is Ok, but locks you into Mac-only development.

Why, did gcc drop objc? It seemed to work well when I played with it a while ago.

Children these days...

[Hurricane78]

I input the data straight into the bus, by using eight Morse keys at 4 Hz.

Now get off my lawn!

Re:Children these days...

[rrohbeck]

A buddy of mine in university had to toggle the boot loader back into an old HP machine's core (yes, real core) after he blew it away through a programming error (no memory protection of course.)
It took him well over an hour. Everybody was much more careful about single stepping through potentially hazardous area of their code first after that. Good times... uncontrolled access to the lab building so we had pizza and beer in there.

Re:Children these days...

[Master of Transhuman]

I once worked on a machine with 40K of core - REAL magnetic cores! - where you had to toggle the machine code - which was in ASCII! - into the machine from a front panel. This was an RCA 301 from back in the '60's that an idiot friend of mine had installed in the late '70's to run his father's department store. The box was THIRTY THOUSAND POUNDS of hardware. The flooring had to be reinforced to hold it. The wiring was a rat's nest. It used nine tape drives and actually had a COBOL compiler that required hours of multipass compilation to compile a program with a couple thousand lines in it.

There was a hard drive that never worked - it held 10MB, the disk was about three feet wide, and it took a 30HP motor to spin it.

Data input was via punch cards, until we got a card-to-tape input device.

My advice: don't try any of this at home.

Choose languages for you, not the platform

[James Youngman]

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:

1. Shell programming (not just how to type Unix commands)
2. A proper scripting language (Python or Perl or, perhaps, Ruby) to use when that shell script would otherwise be reaching 100 or so lines
3. A systems programming language (C is the best choice here, though you can probably get by with C++)
4. An object-oriented language (e.g. Java or Python or C++)
5. LISP or Scheme
6. Any functional language (there are a number of candidates, pick something a friend uses if you need help learning one).

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:Java - A healthy fear

[BitZtream]

I too have a healthy fear of Java, but that is changing.

I feel it VERY important to state that Java apps as a general rule are bloated crap.

I also feel it VERY important to state that Windows apps as a general rule are bloated crap.

I used to avoid Java like the plague due to the slow bloated feel of the apps I had used. Fortunately, recently I was forced to write a Java servlet because a library for that I wanted to use was a java library and it was the only one with a license acceptable to the project I was working on.

In the course of writing the Java servlet I came to learn that Java and the JVM aren't the problem, its just the poorly written apps that I've seen. I meantioned Windows above because it suffers from the same misconception to most non-techies (techies have their own more legitimate reasons for disliking it). Most Windows (and Java) developers suck. They aren't developers, they are people who wrote an app for some other reason. Whatever that reason my be isn't important. Whats important is that we see a lot of crappy Java and Windows apps because those are things that lots of people have easy access to. Pretty much EVERYONE has a Windows machine of some sort they can use, and most of those Windows machines hava JVM. Since you can easily setup a Windows or Java development machine for little to no cost or technical ability, the barrier to entry is low enough that those non-developers can write bad apps that give the language (or OS) a name as a poor performer, when in reality, 99% of the time, the app is the issue, not the engine under it.

I write this post as a former Java hater, who now maintains a servlet that services hundreds of thousands of hits a day, certainly not the biggest web app by any standard but it is a high performance application doing image manipulation in 'real time' for its end users. I still think you should learn C (C++ is good as well, but do C first IMO and you stand a better chance of using object oriented languages properly rather than abusively), but if you are a good programmer, Java can be an excellent language and runtime enviroment to build on. I would not have wanted to write my web servlet in C or C++ in this case.

So for the Java haters, just think about why you hate Java. Do you hate it because of the shitty apps you've used, or because there REALLY is an actually problem with it?

What are you doing?

[Secret Rabbit]

Most (?) programmers have this thing about languages. They program in different ones until they find one they really *really* like. After that, EVERYTHING is about that language. Unfortunately, this is ridiculous.

Every language has its strengths and weaknesses. Every programmer has certain levels of competency with the different languages. Every project has its requirements.

In other words, pick the language that best meets the requirements of the project FIRST. THEN look at your competency in that language and come to the conclusion whether to proceed to the next best language, or use that one.

Btw, I once learned a language to do a project *while* *working* *in* *industry*. If you aren't able to do that, or don't want to do that, then this industry probably isn't as compatible with you as you think.

But, if you want my opinion based on my experience: learn as many languages as you can. The more languages you learn, the better you will be overall. You'll be surprised just how different you have to think in any given language to get the job done.