Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Some peoples' favorite language is whatever their customers will pay them the most to program in. And others beg to differ as our readers, writers and contributing editors debate a gamut of past and present development approaches.

Positive Results
Years ago, I worked on an implementation for an 8085 CP/M computer that allowed multiple-market research interviewers to enter questionnaire responses using computer terminals. One terminal was designated as the supervisor position and users of this machine were able to pull up reports to see how responses were going.

The 8085 addressed only 64K of memory, and we had used just about all of it. It had no floating-point hardware, and we were only using integer operations until we received a request to add a couple of decimals to the percentages given in reporting. This would have been a nightmare, but I remembered an algorithm from grammar school—long-hand division. It's all integer math and will produce as many decimal places as you please. We were so tight on memory that I had the cursor positioned on the terminal before the computation and popped each digit out as an ASCII byte as it was computed.

After working the full range of languages, from writing boot ROMs in assembly, using business languages like FORTRAN and COBOL, system and application development languages like Pascal, C and C++, Internet languages like Java, and various scripting languages, I have to say my favorite is actually VB/VBA, because the projects where those languages are appropriate typically yield positive results quickly. I'm tired of doing plumbing and tired of large-scale systems with their longer development times and lower success rates.

—Andy Barnhart

Roll Your Own
My favorite language—actually it's more of a favorite architecture—is the one I designed and built myself. OK, maybe it will never be used by anyone else, but it was a great experience. At my alma mater, computer science students are required to take a compiler construction course. I well remember the day, near the end of term, when my compiler came to life. I had worked on it for several days before final exams. I had been working on a very difficult bug for a couple hours, so I decided to take a walk. When I came back, I realized there was no bug—the compiler had correctly identified a bug in my test program!

After that, I read my compiler error messages with more respect.

Compiler design and compiler tools are a lesson in large system design. In the early days of high level languages, building a compiler was an enormous undertaking. Now an undergraduate student can build one during a one-term course. If you've never learned about compiler design, I recommend you pick up a book or take a course. The tools and design techniques do not fit neatly into a functional or object-oriented structure, but they work extremely well together to simplify the overall design and speed up development.

—Hugh Bawtree

Smalltalk
I firmly believe that there are two types of developers: Smalltalk programmers and everyone that wasn't lucky enough to be a Smalltalk programmer. Smalltalk is my language of choice because it is pure OO-you have objects and you send them messages, that is all. In Smalltalk, even classes are objects. Unlike hybrid languages such as Java and C++, two languages I also like, Smalltalk doesn't have a collection of commands that you must remember. When you want to write a loop, you send a message to a number object, and when you want to perform a comparison, you send a message to a Boolean object. I've included examples of both concepts in Figure 1 to give you an idea of what I'm talking about. Smalltalk code is easy to read, when it's written properly, because of its use of named messages—as you see in Figure 1. With the firstName: lastName: message, it's very clear what needs to be passed as parameters.

You can string messages together because a message always returns an object; the default is the nil object, as you see with the "if statement" code in Figure 1. I first invoke the firstName getter operation on the customer object to obtain a string object, the value "Scott" in this case; then I send it the '=' message with the parameter "Bubba," which would return a boolean object (with the value of false) which in turn is sent the message ifTrue: ifFalse:. The ifTrue: ifFalse: message takes two code blocks as parameters, a code block being a collection of one or more Smalltalk statements (one or more method invocations on objects).

Smalltalk is a little strange at first because you need to actually think in terms of objects, not the quasi-object thinking that you do when coding Java or C++. As I said before, in Smalltalk you truly only have objects to work with, and the only thing you can do is send them messages.

Smalltalk has been around since the late 1970s, although it came into its own in the early to mid-1990s, just in time to be squashed by Java. Oh well, chalk that up to imperfect market forces. However, don't get me wrong, companies such as IBM (www.ibm.com) and Cincom (www.cincom.com) are still selling Smalltalk worldwide and open efforts such as Sqeak (squeak.org) are gaining popularity within the object-oriented software engineering community. If you are interested in learning more about Smalltalk, the Smalltalk Industry Council (www.stic.org) is a good place to start.

—Scott W. Ambler

Smalltalkers of the World Unite!
Although it's now a long time since I did anything with it, I nominate Smalltalk—I still haven't come across anything quite like it for being able to transfer thoughts into computer code. It's not just the language: It's the wonderful browser environment, the libraries, and the culture of writing clear, well-designed code as quickly as anything else can crank out spaghetti. When the participants at JavaOne were extolling how Java was so much more productive than anything else, I needed a brown paper bag. Oh well, back to sorting out my classpaths …

—Martin Fowler

MVC
Epiphany is a widely used term in literary studies to describe what happens to a character when he suddenly perceives the true nature of a person, situation or object. In the 17 years since I earned my computer science degree, I can only say with certainty that I've experienced two epiphanous software development experiences. A chance meeting with Dr. E.F. Codd, the IBM researcher who originated the relational database model, at a book-signing after I got out of college spurred my interest in several of Codd's enthusiasms, such as relational algebra and relational calculus. My next epiphany came when I began building more complex (that is, object-oriented) applications and discovered the Model-View-Controller (MVC) paradigm.

Although MVC has its roots in Smalltalk, it's really more of a way of partitioning the design of interactive software than either an algorithm or language construct. The goal of MVC is to divide the functionality of an application into three logical categories: the "model" that contains the internal workings of the program (the algorithms), the "view" or visual display that shows the user the state of the model, and the "controller," which is how the user changes the state or provides input. Even by today's standards, MVC is still an influential concept. According to Erich Gamma in Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995), "looking at the design patterns inside MVC should help you see what we mean by the term pattern." Doug Rosenberg and Kendall Scott (Use Case Driven Object Modeling with UML, Addison-Wesley, 1999), likewise acknowledge how closely Model-View-Controller maps to their innovative Boundary-Entity-Control approach to analysis and design.

—Roger Smith

The C++ STL
I'll never forget the exhilaration I felt when I encountered the C++ Standard Template Library. Of course, I'd been following the C++ standardization efforts at a distance, and as Mike Vilot said, "there would be blood in the streets" if it didn't provide at least a string class. I'd also seen the stolid, low-level C-based dynamic array and string classes in P.J. Plauger's The Draft Standard C++ Library, (Prentice Hall, 1994), but the STL was different, unlike the other models of C++ class libraries that I was then familiar with.

What struck me most was its sheer concentrated power. It sorted, did permutations, generated sequences of elements for testing and so much more. Yet all the code fit in a small directory (there being obvious comparisons with large bodies of code that just manage to generate GUI components). And its integrity—at the core, the STL code re-invoked itself, making use of functions available for use from user-level code, unlike most system-level code, which reserves "special" mechanisms for its own internal use. When working with assembler code long ago, I'd realized that opportunities existed for re-implementing parts of an algorithm—for example, finding only the integer dividend instead of both dividend and remainder when dividing might yield extra efficiency under certain circumstances—but I had never before seen "modular algorithms," such as partition made available as a subalgorithm of quicksort. However, what really won my heart was the STL's resonance with standard C and C++ coding idioms. The copy algorithm, for example, was almost exactly the one-line loop of strcpy through which most beginners are introduced to the dangerously compressed elegance of C and C++, with pointers extended to iterators.

The STL did postpone the promulgation of the ANSI C++ Standard, at the same time as some momentum was lost due to Java's emergence as a competing focal point, due to maintaining the integrity of the C++ standard by re-architecting the whole under its influence; string became a template class, the iostreams facilities too, and exotic extensible mechanisms for locales were crafted. I still get dizzy when I think of trying to implement the extensions to templates that were added to support what are now the ANSI C++ standard template algorithms and container classes: partial specialization, for instance. (So much for the C++, C and Unix school exemplifying a tradeoff favoring implementation simplicity over user capability!) However, the ability to use templates to compile a solution as directly tailored and efficient as possible for your particular application in its particular environment remains a unique feature of the C++ language.

Today, the full promise of the STL is still being delivered on, with, for example, the Generic Graph Library (www.lsc.nd.edu/research/ggcl); I've long used the code for graphs as my standard "litmus test" of data structures implementations. Just as the STL uses the concept of iterators to bridge containers and algorithms, so the GGL uses the concepts of vertex, edge, visitor and decorator to bridge graph structures and graph algorithms. Finally, the structure of the GGL feels like it can bear the complexity required. The architecture of the STL in the standard C++ library also has succeeded—where a thousand sterile papers never could—in expanding the horizons of C and C++ programmers to include the beauty of abstract type systems and a more applicative style.

—Christine Bouamalay

Show Me the Money!
Whenever I'm asked what my favorite programming language is, I simply answer, "whatever language my customer will pay me the most to program in." I really don't care if its object oriented, procedural, high level, low level, symbolic or even functional. When someone is willing to pay me lots of money to use a language, it becomes my favorite.

Many of my colleagues would recoil in horror at my mercenarial attitude towards programming languages. What kind of programmer goes around selling his skills to the highest bidder? A programmer who has a family, a mortgage, car payments, wants to retire above the poverty line and enjoys the occasional hockey game. A programming language is just another tool.

Actually, this mercenarial attitude protects the customer's interests. If the customer is willing to pay me a premium to work with a language, then that customer must perceive an advantage to using that language. Many programmers who only argue the academic merits of their favorite language overlook other factors that influence the choice of a programming language. Many engineering firms still have large portfolios of Fortran code because Fortran does its job extremely well. Many companies want to minimize the number of languages and tools they support. And many companies need to be able to easily hire talent, therefore choosing their tools and languages based on the skills of people readily available.

OK, really now, what is my favorite programming language? None of them. While IT is a great industry to earn a living in, the tools leave a lot to be desired. Case in point: While I've made a ton of money designing and programming systems in C++, Bjarne Stroustrup must have been hauling in big cases of that strong Danish beer to all the C++ standards committee meetings.

—Steve Adolph

Duct Tape
Languages are tools, so it's difficult to select a favorite because each one brings to the table the strengths and weaknesses reflecting the compromises made by its designer. That said, Perl would have to be my favorite language. Someone once suggested that Perl serves as the duct tape of the system administration world, and the duct tape analogy is particularly apt when you consider the similarities between duct tape and "The Force" of the Star Wars saga. Consider: Perl has a light side and a dark side, and it holds the universe together.

Perl's light side: gazillions of existing system administration tools, ready for you to download and adapt to your needs. In addition, Perl serves as the lingua franca of system administrators, much as all aviators understand English. The dark side: While Perl doesn't completely deserve the "Write Once, Read Never" label hung on it by its detractors, there is no gainsaying the fact that understanding Perl code requires an eye for detail. Although Perl is no COBOL, it is readable if you take your time. In spite of this, three out of four administrators recommend Perl for whatever ails your system.

—Warren Keuffel

The Logical Choice
Prolog engages the mind in a way that is qualitatively different than any other language. PROgramming in LOGic consists of writing a series of assertions and propositions, letting the runtime generate the valid conclusions, and using side effects for input and output. Beautifully concise and easily optimized to lightning speed, Prolog is crippled by its association with passe AI techniques, its non-procedural programming model, and the ascendancy of the user interface as the central problem of system development. When I wrote a lot of Prolog, I would work on a bench overlooking the shores of La Jolla. I don't know which I remember with more fondness: looking up to see dolphins surfing the waves or writing expert systems (in longhand) that I knew would run the first time I typed them in.

The algorithms to create and exploit binary space-partitioning trees are simple, practical, and with behavior that is profoundly nonintuitive. Given a complex geometry, pick any face and extend it into a plane, sort the rest of the geometry into that which is "in front of" or "in back of" that plane, splitting intersecting faces. Recurse on the two resulting sets. The result is … well, Castle Wolfenstein 3D, which was to the graphics in competing PC games what Star Wars was to Logan's Run. The follow-up to Wolfenstein was a little diversion called Doom, and the BSP (binary space partitioning) has been the core data structure of video game graphics ever since.

So the next time you frag some low-ping buster who is camping over a regen point, give thanks to the magic of hierarchically partitioned convex subspaces.

—Larry O'Brien

Attack of the Valkyrie
Why do I work in Java? Because there is too much anger in the world.

In college, it was Pascal. Niklaus Wirth's pretty little teaching language had just a rudimentary I/O library, so I sat in the lab with the other nerds, edit-compile-testing. Time to leave, I had a date. One more compile. Surely it can read in a string, for crying out loud! Wait, one more compile. And another. And another … the only sound in the room was clicking keys.

The sound stopped as the door slammed open. Framed in it was a Valkyrie-female, beautiful and certainly warlike. The nerds stared, openmouthed. A … girl?

Above the door, I noticed, was a clock-I was now 95 minutes late. She smiled sweetly. The other guys felt their blood warming. I felt mine freezing.

"Rick? Rick Wayne! So great to see you. Hey, here's my number. When you get a minute ... call me!"

A swirl of skirts, the slip of paper drifted to the desktop. The door slammed again. Good thing I managed to catch her, otherwise I doubt she would have married me.

Years later, it was C. Pointer bugs. References to deallocated memory. Array overruns. I was so cranky, my superiors gave me my own office—more as a workforce-safety measure than a perk. The pressure was on to get the release disks cut—that night, in fact—and I was the very last obstacle. Edit, compile, test. Crash. Dang. Edit! Compile! Test! Crash. Argh!

EDIT! COMPILE! TEST! Crash.

PUNCH FILING CABINET! EDIT! COMPILE!

Update resumé.

Next it was C++. Better. My demeanor improved to the point that I was given an office near the director. But I was spending way too much time on silly things, like debugging memory problems (still) and trying to get incompatible libraries to link.

Then I downloaded JDK 1.0.2, which changed my working life forever. Sure, it was dog-slow, and they kept changing the class library. But I never had to deallocate an object—when there were no more references, the system garbage-collected it for me. And no pointers. And array overrun protection. A real class library. Woo-hoo!

And, miracle of miracles, when I did manage to screw up, I was presented with a nice exception trace, including line numbers, instead of, oh, say, having the machine reboot. I was hooked, and never went back.

Today, I can even share an office. Paul and I sit back-to-back, and he has no fear. But ever since he inherited that legacy Pascal project, I've been nervously looking over my shoulder …

—Rick Wayne

A Mongrel Language
C++. Is there really any other language worth using? To look at any bookstore's shelves you would think Java already owned the world. (Sorry, but last I heard, Microsoft still owns the world.) It's a great language, no doubt. But if you want power, and control … it's C++ for me.

Admittedly, C++ is a difficult language to master. In fact, it's a difficult language just to learn. But everything really worthwhile requires some sacrifice, and maybe some blood and tears. And, if my program should have a bug (this doesn't happen very often, of course), I can get all the way down to the chip level and really mess with the processor's mind. Can't do that with Java, can you?

I admit I come from an earlier day of programming. It was an era when a program actually ran on a real machine, not a virtual machine. And we didn't have all these "sissy" tools like symbolic debuggers … we just learned to read machine code. More than once I debugged a third-party DLL without any source code, and found the problem.

But, eschewing all further levity, I do have a special fondness for this mongrel language. It reminds me of a Cincinnati chili with all these great ingredients combined to achieve an end greater than just a fast meal. C++ is more than just a programming language. It's a way of doing programming, and I lament that so many using "the other language" haven't experienced the privilege of spending time with this superior programming tool.

—Gary Evans

" Create an object by sending its class the new message"
aCustomer := Customer new.

" Invoking a two parameter message  firstName: lastName:"
aCustomer firstName: 'Scott' lastName: 'Ambler'.

" A Smalltalk if statement" 
( aCustomer firstName = 'Bubba' ) ifTrue: [
	" Do something"
] ifFalse: [
	" Do something else "
].

"A Smalltalk loop"
1 to: 5 do: [
	" Some message invocations on objects "
].

RELATED ARTICLES Wind River Hypervisor 1.1 Released Parallel Pattern 5: Stencil Distributing Work Across Cores Using .NET Other Voices: Knowledge Management Basics Inform System Release Lifecycle Server+client Fusion: An Architectual Proposal		TOP 5 ARTICLES No Top Articles.