Yet again I am amazed at how working with Open Source and writing about it can be so incredibly rewarding. Even when I switched in and out of self detracting mode (something many readers seemed to appreciate) I kept receiving excellent email's with suggestions, comments or the occasional question.
Of course, the series never really reached the depth I had hoped it would, but then again, it must have sufficed to a degree. I do have some points to address that the rest of this installment will cover (or re-address as the case may be):
One aspect of writing online and working with projects in any fashion is the sheer amount of different perspectives I see. I honestly believe that the differing personalities of people is directly related to (if not proportional somehow) to the variety and implementations of programming languages.
A great deal of readers wrote me to make suggestions or just share their views on programming, programming language preferences and preferable environments. As the series began to draw near a close I began to realize that there is much more beyond the philosophy of programming or the rigid (in some cases not so rigid) syntax of programming, but the direct reflection of the hackers behind languages in addition to those of us whom use those languages.
Seeing this dimension in people it is now quite clear to me where all sorts of different approaches come from and lead to inventiveness within existing languages.
One point I did fail to reiterate in subsequent columns that I made in the first column is that I do not believe and anyone in the right mind would also, that any one single language is the end all solution. I do not argue that there are some languages out there that are bordering on the edge of pure blasphemy. It has always been the case for me that it truly depends on what the goal of a particular project is or where it will fit in with other pieces of what it may be working with. That may be somewhat confusing so let us take a look at some quick examples to further illustrate those ideas:
In this example, we have a project that is not necessarily connected to anything else, so we have a lot of options, we could, literally, choose any language if we knew the user of the resulting application or utility would have everything they need to use it. In this case, we look for the best match to meet the goal. If we wanted to create a very fast small utility, then C, C++ or Perl might be the best language to use, if we wanted the ultimate in speed, I would venture to say C or ASM (or a combination therein) would be the best match.
If the goal was slightly different and I mean just slightly, we might have to shift to a different language. What if we wanted a strong object oriented program, C++ or python might be the answer. If we wanted a great deal of speed but to still retain the built in Object Oriented features then C++ might be the best match for that particular goal.
Finally, for the sake of argument, let us assume that we will be doing massive string handling on a pretty powerful system. Perl would be my first choice, at least as a prototyping language for it's ease of auto-magically handling arbitrary string lengths.
There are occasions when one should or even have to use a certain language. If we are creating a GNOME application for example, it would indeed make sense to use GTK and it's associated tools to build our application. Another time we would be forced to use a certain language would be kernel programming, where C and ASM play a large role.
Unfortunately, it is rarely ever so clear cut. I can speak from personal experience about this because I face it for every project I start. In my case it is almost always a sysadmin tool of some sort, well except for my nefarious screw off programs. So often I must think about how I want to approach a problem and how it would work the best but still be created with a language that other toolmakers use. Now, why should I care? It is Free/Open Source, which means if there is a problem that exists and I miss it (and believe me, I do) then there is a good chance that if someone else wanted to fix it or make a change for the better they can because they will be familiar with the language.
In my case I choose C or Perl almost everytime. I primarily use C when working very close to the kernel or hardware. When building admin tools like quasi greppers, log filters and report generating scripts I almost exclusively use Perl. Both languages are extremely popular (if not necessary) to the audience I happen to cater to.
In both of the aforementioned cases and examples, everything goes when it comes to selecting a language and even the implementation, coding style, commenting style - whatever. Try to match every aspect of the project with:
Following those guidelines will tend to make life a little easier.
It might be a poorly written one, but the intent is always good. The first time I wrote a real program (although I would hardly call it that now) it was not exactly an achievement in programming. it worked, don't get me wrong, it did the job, but it could have been a lot better. Regardless, it was a learning experience. That is what is is all about really. learning, growing and expanding.
A case in point (again), I made what might be considered one of the single most useless programs of all time. It is written in Common LISt Processing (CLISP) and contains a whopping 12 lines of code. I read the entire CLISP tutor and implemented every example and when I finally understood how it worked, I decided to write a recursive CLISP program, my motivation was irony. You see, LISP uses built in recursion in its statements. So, I thought it would be somewhat ironic if I wrote a useless program that was a call to one recursive function. The program runs through ninety nine bottles of beer on the wall, almost instantly the screen is filled with lines of the song.
Hey, at least it is efficient.
Point is, I did it as a learning experience and shared because I felt others might get a kick out of it. I did intend to improve upon it, but I couldn't stop laughing after the "first revision."
One last shot I will fire at the "learn a variety" ideal is understanding the approaches of one language and using them in another. In some cases there is a direct translation. Say you know C++ but not C and are programming in C. You stumble across a linkage method and realize you can do the exact same thing in C++. You have just added to your armory of C++ skills.
Of course, that is a pretty cheap example since C++ is an enhanced C with built in Object Oriented capabilities. Instead look at how CLISP promotes the use of recursion (since internally that is how it works anyway). Understanding this can help one better understand how to use recursion efficiently in other languages or to create built in lexicals using recursion in another language.
Experienced Role Playing Gamers will remember the cardinal rules set out by Gary Gygax in Advanced Dungeons and Dragons when he stated (and I am paraphrasing):
"These books are not rules, they are guides. They show a path but not an absolute way to do things."
As is the New Programmer's Road Map. If at some juncture one decides that using a language I did not even mention (and I did not mention a lot) would suit them best then so be it. Instead the New Programmer's Road Map is a really big suggestion. I believe following it to some extent will round out ones skills, but that does not necessarily mean that a New Programmer should follow each and every suggestion I make. Instead, I would make these ones as a sort of short version:
In my case, it was quite typical of a sysadmin career really. Here is the short short version of what I learned and in what order:
I focused on Perl and C for the most part. As you can see, I sort of do not follow the Road Map exactly, hence why I thought I might share my thoughts with the world at large!
The Road Map missed a few points from the beginning, the most important one not covered in this installment is - what else do I need?.
Buy books, lots of books. You will need them. I cannot really recommend one brand over the other, I have several books from several publishers on C, C++ and Perl (and soon to have Python). All of them have different examples, different approaches and methods. After a time you will even begin to question the material you bought. This is a good thing. If I did not receive an email that questioned something I said here, I would REALLY be scared. If you do not question, you will not learn . . .
Almost parallel to books is online documentation, either on the internet, info, ps, man or whatever. Dig, Dig, Dig. It is there, somewhere. I have found this to be the best way to get the full advantage of any library or call available. Understanding the documentation is an art unto itself. Weeding through the diatribe of one individual can be difficult, but the reward is priceless. Finding that obscure capability you never knew existed is always enlightening.
For those of you just starting down the road, I hope I helped and I wish you all the best of luck.