Which Programming Language?
In this article, I survey a clutch of popular programming languages and provide some personal opinions as to when it is appropriate to use each of them. I'll also talk about some of the development tools available for each language. Hopefully, by the end of this article, Paul will be in a position to make an informed decision. (A small annotated bibliography is also included).
Let me begin by listing the five contenders: C, C++, Java, Python and Perl. There are, of course, lots of other programming languages; however, references to these five appear more than most, especially in the Linux world.
Before looking at each language in turn, there is one thing we can say about them all: they are general-purpose and can be used for most any programming task. A general distinction is that C and C++ are compiled languages, much like Fortran, whereas Python and Perl are interpretive, like most versions of BASIC. Java is somewhere in the middle; source code is compiled into an intermediate format which is then interpreted.
C has a heritage that dates back to the first versions of UNIX--it was used to write most of the OS. The Linux kernel, together with most other parts of the OS, is also written (mainly) in C. This is not an accident, as C excels as a systems-level programming tool. C gives you complete control over everything you do. Despite the fact that C is a small programming language, the devil is in the details, and all that control comes at a price. You, the programmer, must handle allocation and deallocation of memory. There is also the direct manipulation of memory via pointers and pointer arithmetic with which to contend. This basically rules out C for casual programming. However, if you want to play around with your kernel code or write a device-driver, you had better invest a serious amount of time in mastering C.
The C that comes with Linux is the GNU C Compiler, gcc. Don't be fooled by the commercial vendors (and their flashy advertisements) into thinking gcc is anything but capable. The compiler technology is excellent and very mature. Paid support for gcc is available from several commercial organizations, most notably Cygnus (now part of Red Hat), the maintainers of gcc. Free support is also available; check the GNU Service Directory at http://www.gnu.org/prep/service.html for more details on both types of support.
So, when would you decide to buy a commercial C compiler, especially when gcc comes bundled with Linux? Well, with all the support available for gcc, paying for your compiler can be hard to justify. If you are moving from the Wintel and Macintosh platforms, you may be repelled by the thought of command-line switches and makefiles, not to mention the editing modes of vi. If it is an Integrated Development Environment (IDE) you're after, Linux has it's fair share. Typically, these integrated tools are hosted within a GUI, and the IDE provides centralized and consistent access to the tools you'll use to edit, compile, link, debug and run your code. Example IDE's include KDevelop and Source Navigator. GUI builders also exist, and the most well-known in the open-source world is Glade (see the web Resources sidebar). If you really do like the IDE tools available on your current platform, you can also find them on Linux. One such product is CodeWarrior from MetroWerks, which is also available for the Wintel and Macintosh platforms. Please have your credit card ready.
C has another interesting property. It forms the basis of all the other languages discussed in this article. C++ is designed to be a very close superset of C. Python and Perl are written in C. And Java is a derivative that is, to the best of my knowledge, written mostly in C. To repeat myself, C excels as a systems-level programming tool.
C++ is all that C is and more. The "more" refers to a large chunk of object-oriented (OO) technology included, in addition to better type-safety, namespace support, templates and exception handling. If you are planning a large systems-level project or application, C++ can be a good choice. Its use can lead to code that is more modular and easier to maintain than equivalent C code. Bear in mind that all I've said about C also applies to C++, and all that new technology can be difficult to master. It can also be totally awesome if used properly. Of course, you don't need to use the new features if you don't want to, as C++ does not force them on the programmer. This is especially true of the OO technology, which can be messy if used inappropriately.
Surprisingly, the gcc compiler used with plain C can also process and compile code written in C++, which can make the transition from C to C++ relatively painless from a tools perspective. To ask gcc to compile C++ code, simple invoke the compiler not as gcc but as g++. (You can also rely on gcc's built-in behavior that will compile your code as C++ if the file extension ends in .C, .cc, .cpp, c++, .cp or .cxx).
Something worth considering when looking at C and C++ is the vast collection of libraries available for these languages. If you plan to write some GUI code, you will find plenty of APIs and libraries which are usable within GNOME, KDE and plain X. Much-used libraries include Qt, ACE and Gtk--. If you're really into C++, take the time to check out the Standard C++ Library which is now part of the ISO C++ standard. This library includes the technology known as STL, the Standard Template Library. I was first exposed to STL during an advanced OO course about four years ago and thought it was the coolest piece of C++ I'd ever come across. It's now part of C++ proper, which is to be applauded.
Java, among other things, is billed as similar, but easier, than C++. This is great news for C++ programmers, but does not wash with the rest of us--most programming languages are easier than C++! In fact, some suggest Java is closer to C, with a number of major exceptions; Java is totally object-oriented (i.e., you must program the OO-way), dispenses with the pointers of C and C++, and provides for automatic memory management (which is a huge plus in many programmers eyes).
Of all the programming languages discussed in this article, Java wins the prize for generating the greatest amount of hype and copy. To believe its creator and custodian, Sun Microsystems, Java is all the programming language you'll ever need. Don't allow yourself to be fooled so easily.
Every Java implementation provides a Java Virtual Machine (JVM) that sits on top of the host operating system. The Java code that you write is "compiled" to run on this JVM, not on the host OS, and JVMs exist on all the major platforms including Linux. As the JVM on all these disparate systems is supposed to be identical, operations specific to any one platform are not allowed (at least, that's the theory). The Java Native Interface allows the platform-specific programmer to bypass this restriction.
Ask most programmers who aren't using Java what they believe its biggest drawback is, and the vast majority will comment on runtime performance. In short, it can be poor. Every Java supplier is working on solutions to this problem, and a large number of Just-In-Time (JIT) compilers are available. The JIT technology goes a long way towards improving Java's run-time performance; however, when compared to the run-time performance of equivalent C/C++ code, Java is still (and will more than likely always be) in second place. This has more to do with the design of the language than with the implementations. If you like Java and you wish it could be compiled, don't fret--the gcc compiler will also compile (to machine code) your Java code. Of course, you lose all the Java portability benefits when you do this. You also become part of the experiment, as Java support in gcc is a work-in-progress.
Of course, once you've compiled your Java code (with a Java compiler, not gcc), it should run on any JVM, regardless of platform. So, in theory, the Java-based program you develop on Linux can be shipped in "compiled form" to users in the Wintel and Macintosh worlds. Again, in theory, the program should run identically on each of the target platforms. Of course, you will need to ensure that each of the JVMs you are shipping to support the version of Java you are writing to. Prudent programmers (as well as those that like to keep their jobs) are well advised to test their developed applications on each of the JVM's they target. It's a case of write your code once, compile it once and test it everywhere.
Java is very big with an intimidatingly large (and growing) standard library, which can make it daunting to learn and master. However, Java is interesting because it is highly Internet-aware. If your plan is to write applets for web pages, you will be hard pressed to get better support for your work than that provided by Java.
The standard Java library is full of reusable goodies for the programmer, and includes everything from high-level data structures to GUI toolkits. The most useful of these is Swing technology, which, with the most recent versions of Java, takes on the appearance of a programmer-configured OS/GUI. This means it's possible to have a Windows look'n'feel on top of X Windows or Mac.
Java tools and JVM's are freely available and should come with most major Linux distributions. Sun provides a full set of command-line tools for free download, and a large number of traditional tools vendors are more than willing to sell IDEs based on Java to all.
If, having just read through the last few paragraphs, you get the feeling that I'm not too impressed with Java, then you'd be right. For some, Java is seen as a good step up from C and C++ for general purpose applications development (which accounts for a large portion of its popularity), but it is not, in my opinion, a big enough step to warrant all the excitement. Which, rather nicely, brings me to the final two contenders: Python and Perl.
The great thing about Python and Perl is that what can take pages of code in C, C++ or Java can be accomplished in just a few lines of code with these programming languages. If you need a quick little program to do something useful, both Python and Perl let you produce something that works in no time at all. Like Java, Python and Perl look after memory allocation and deallocation for you. Unlike C, C++ and Java, both Python and Perl operate at a higher level and are often referred to as "scripting" languages.
Python is a cool little language. It is well designed, compact, easy to learn and fun to program in. Python strongly encourages the programmer to program in an OO-way, but does not require it. In my opinion, it is one of the best languages to use when learning OO-programming. The implementation of OO in Python is clean and simple, while being incredibly powerful. The basic Python execution environment is also the most interactive of the five discussed here, which can be very useful (especially when debugging code).
Python gets a lot of stick for giving syntactical meaning to whitespace. For example, if a block of code is associated with an if statement, then the code needs to be indented beneath the if statement in order for the association relationship to work in Python. Some programmers hate the very idea of this. They should just get over it, as the Python method of indentation effectively does away with the need for braces and semi-colons within code, which (if you are an old C-dog like me), takes a little getting used to. But, get used to it you will, and after using Python for a while, you'll hardly ever notice they are missing. Of course, the nice thing about all this indentation is that Python code tends to look quite neat and tidy, regardless of who actually writes it.
Like Java, Python has a large standard library of reusable code. Python is an interactive interpreter, and runs (typically) from the command-line. An experimental IDE, called IDLE, is shipped with the current distribution and provides a GUI-hosted development environment. Although not fully functional, IDLE offers a glimpse of what's to come in the future. Another interesting project associated with Python is JPython. This is an implementation of Python written entirely in Java. So, if your target system has a JVM, you can use JPython to program it. JPython is being renamed Jython, as the JPython people have broken away from CNRI (The Corporation for National Research Initiatives), and CNRI owns the JPython trademark. The Jython people say the new name will grow on you. We shall see.
Something that concerns me about Python is that its creators appear to be positioning it as the modern equivalent of Pascal. This strategy may well cause more harm than good. Pascal was best known as the teaching language of choice, despite its use in some high-profile technologies: when Apple Computer released The Macintosh, its applications programming language was Pascal; and Inprise Corporation use an object-oriented Pascal as the basis of their Delphi RAD tool. Unfortunately for Pascal, the "teaching language" label is a stigma that prevented many from taking it seriously. The same fate may well await Python. Let's hope that doesn't happen.
Many Perl programmers will tell you that if there was no Perl, they would all be programming in Python. The problem for Python is there is a Perl, and it is getting better all the time.
Perl is a huge beast of a programming language. It is perhaps not an accident that the languages logo is a camel. Part of the reason for Perl's size is that in Perl "there's more than one way to do it!" (as their motto says). This is seen as a huge boon to some, confusing to others. Some like Perl's ability to do things in numerous ways, whereas others get hung-up on choosing the "one true way" to do something. In Perl culture, there is no one true way, and the Perl programmer is encouraged to choose the method that works best for them. This freedom to work the way you want to work is one of the reasons for Perl's success.
Another reason is CPAN, the Comprehensive Perl Archive Network. Available on a number of mirrored Internet sites, CPAN provides access to a wealth of reusable modules for Perl, including everything from talking to databases and processing XML to working with GUIs. In fact, nearly every conceivable use of a programming technology has been "CPANed". If you are considering Perl, take a few minutes to look at the list of add-on modules located at the www.perl.com/CPAN.
Perl can be used with the Tk technology (from TCL fame) for programming GUIs. (Python also uses Tk for GUI programming, calling the technology tkInter). Support for other GUI toolkits also exists, most notably a Perl API to Gtk (which is used by the GIMP). Check out CPAN for more details.
Do not be fooled into thinking Python and Perl can't be used to program large, sophisticated applications. In the case of Perl, a little more programmer discipline may be required than for Python. Granted, you are not going to write an OS or device-driver using either of these programming languages, but everything else is fair game. Like Java, Python and Perl fair poorly when it comes to raw execution speed. They are all interpreters, after all. And if performance is critical to you, you'll need to look beyond these languages and go for C or C++. As you might imagine, both Python and Perl excel as tools for the casual programmer.
Most Linux distributions already include these programming languages on their CD-ROMs. (Python is heavily used by Red Hat for system administration tasks, and Perl is a favorite of the folks at Mandrake and Debian). It costs you nothing (other than your time) to try them out and decide which one is best for you. Happy hacking!
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide