Netcentric View:

Changing Networks Need Functional Languages

By Bernard Cole
iApplianceWeb
(11/29/01, 07:18:52 AM GMT)

The continuing perturbations in the net-centric computing environment are evident in the nature of the programming decisions that face developers, who are still sorting out the complexities and opportunities that new languages such as Java and C-sharp have introduced.

However, more programming decisions have yet to be made. My feeling when I wrote "Is Parallel Programming In Your Future?" was that the basic change would be from the sequential mode of procedural programming to a more highly parallel method of code development, either explicitly through appropriate design tools or implicitly through the use of parallelizing compilers. But, beyond some of the alternatives I indicated there, a number of you responded that there might be some more appropriate choices.

Tony Pedley, senior software engineer at Alsthom Power Conversion, pointed out that in the telecom/datacom environment a better choice might be Erlang, a programming language developed by European telecom companies in the 1980s, which has concurrency built in as part of the language. It also has a number of additional advantages, such as the ability to move processes dynamically across CPU platforms to facilitate load balancing or fail-overs.

If the features of Erlang were exclusively related to its parallelism, it would be of only historical interest, but there is much more to the language than that. The network processor environment is going through changes that may involve more than shifting to just another type of procedural language, one more parallel in orientation. The shift may be to an entirely non-procedural language modality with a more function-oriented programming paradigm.

Some of you may be familiar with functional programming from your university and college years. It's favored by educational professionals who teach the fundamentals of programming using functional languages such as Caml, Scheme, Opal, and Haskell. The main criterion for being a functional language is that it allows programs to be written primarily to perform some task. In a sense, functional programming is a language paradigm that fits somewhere between assembly/machine programming (move a bit to a register, send to accumulator, perform a function) and a low level procedural language such as C that incorporates a number of higher level programming constructs.

Functional languages are being investigated for the network processing environment because they are good at implementing mathematical algorithms -- such as extracting data from a table, performing a calculation and then executing some sort of control function based on that calculation. In many network applications in the control and data plane, a lot of time is spent accumulating tables, calculating results and then forwarding a packet based on the values calculated. In this environment, a procedural language would be concerned with the execution of a specific protocol, where as a functional language would go down one step. The tradeoff is between more efficient control of device resources at a level somewhat higher than machine/assembly coding and but not as sophisticated as high-level procedural code that is easier to write and implement.

What makes a functional language attractive in this environment is that it strictly defines an operation in terms of the function to be performed, not as a set of procedures to be followed with a single object. With a procedural language, process and methodologies and the objects called change depending on the return result from a call.

Because of the perceived benefits, organizations such as the Network Processing Forum are looking seriously at developing a general-purpose functional language with some procedural features specific to this new environment. This effort is underway at a number of companies, such as Agere, AMCC, and Solidum, who each have developed their own functional language implementations.

This work may not be necessary. Fortunately for the requirements of network processing there are already existing languages that are both highly parallel and concurrent, as well as functional. And one of them is Tony's candidate, Erlang, which was introduced commercially in 1991 after ten years of development by Ericsson, the Swedish telecom giant. Erlang has been used to control several very large scale (i.e., hundreds of thousands of lines of source code) telecommunications switching system products that are marketed world wide by Ericsson today. It has also been used to implement countless prototypes and experiments.

Erlang is important in the highly distributed computing environment of most network processor applications because it has built-in support for not only concurrency, but distribution and fault tolerance as well. In addition, like Java, (or rather Java is like Erlang in this respect) this language has a runtime environment (in essence, a virtual machine), which means code compiled on one architecture runs anywhere. The runtime system also allows code in a running system to be updated without interrupting the program.

Everything I hear about Erlang makes it seem the ideal choice. Among other things, it supports extremely lightweight processes whose memory requirements can vary dynamically. Processes have no shared memory and communicate by asynchronous message passing, so it can support applications with very large numbers of concurrent processes. No requirements for concurrency are placed on the host operating system.

Important in the multiprocessor environment of most network processing environments, Erlang is designed to run in a distributed environment and supports creation of parallel processes running on a number of nodes, which perhaps use differing operating systems. Processes residing on different nodes communicate in exactly the same way as processes residing on the same hardware platform. Its error detection primitives can be used to structure fault-tolerant systems. Processes in a distributed system can be configured to fail-over to other nodes in case of failures and automatically migrate back to recovered nodes.

Erlang is extremely useful in the network-processing environment because it allows program code to be changed in a running system. By way of incremental code loading, programmers can control in detail how code is loaded. When bugs are uncovered, only the buggy code needs to be replaced. And last, Erlang processes communicate with the outside world using the same message passing mechanism as used between Erlang processes, allowing it to be used for both communication with the host operating system and for interaction with programs written in other languages.

As always, I still have a lot of questions. In this environment, who needs Java or any other procedural language? What has prevented its much more widespread usage? Is it difficult to use or understand? Why did Java, introduced much later, strike the programmer's fancy and not Erlang, which has most of the important features of that language plus a lot more? Is it functional not enough? Or is it too functional, requiring too much of a shift from the procedural methods to become popular?

Bernard Cole is site leader and editor of iApplianceweb and an independent high technology editorial services consultant. He welcomes your feedback. Call him at or send an email to .

For more information about topics, issues and technologies mentioned in this story go to the flashing icon in the upper left corner on this page or go to the iAppliance Web Views page and call up the associatively-linked Java/XML-based Web map of the iApplianceWeb site.

Enter the appropriate key word, product or company name to list instantly every news and product story, product review and product database entry relating to the topic since the beginning of the 2002.