Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Programming Reductionism: When Less Is Truly More  : Page 2

For developers, reductionism as it applies to programming implies improved ease-of-use, greater efficiency, interoperability, and, perhaps soon, language freedom. Platform vendors may not be doing everything alike but they're ending up at the same destination. Find out why Executive Editor Russell Jones is eagerly awaiting the next surge of programming reductionism.


advertisement
The Two Faces of Interoperability
In the end, computer languages all compile to machine code that, for any given processor, uses the same instruction set regardless of the language in which a program was originally written. But there are large and significant differences in syntax, performance, method and function calling conventions, and data types between languages, which makes it very difficult to reuse code built in one language from a different language.

For example, the Windows API runs on a core set of DLLs originally constructed with C, and the functions exposed by those DLLs wasn't particularly suited for use from other, newer languages, such as Visual Basic or Java.

This problem resulted in the creation of middleware standards, the most successful of which have been COM, CORBA, and Java.



COM, Microsoft's Common Object Model, consisted of a rigid set of rules for creating objects, but let languages reuse code built in any COM-compliant language, the most popular of which have been Visual Basic, Visual C++, Delphi, and various scripting languages.

CORBA was the alternative to COM outside Microsoft languages. Several vendors build COM-CORBA bridges that let COM-compliant languages use CORBA-compliant components and vice versa. Despite its flexibility, CORBA never reached the same popularity as COM, primarily because no language appeared that became as popular as Microsoft's COM-based Visual Basic.

Microsoft's approach is to simplify programming by abstracting functionalitybut at the cost of tying the .NET-compatible languages to the .NET Common Language Runtime (CLR)
Java took an entirely different approach, one which basically ignored all other languages and concentrated on making Java code work the same way across a wide range of hardware and operating systems. Because the underlying runtime understood the same data types and calling conventions on every system, it was relatively easy for Java code written on one system to make calls to components written in Java but running on a different hardware platform.

This one-language approach has been phenomenally successful, particularly in larger corporations, which have a huge need to interact between incompatible systems, and among programmers who write "back-end" components. However, because of its C-like syntax, initially poor performance, the lack of a unifying development environment, and, probably most important, its one-language philosophy and ever-increasing proliferation of APIs, Java has failed to attract and hold the bulk of desktop application developers.

Sun and its various partners are working to solve these problems. Java syntax, while perhaps not as accessible as that of some other languages, isn't difficult to learn. Java performance has increased steadily, Java IDEs are improving rapidly, the proliferation of APIs reflects Java's popularity and extensibility, and Sun is incorporating APIs into the Java core platform as fast as possible. In reductionist terms, Java is attempting to simplify programming by eliminating the alternatives.

You can compare the Java runtime to the assembly-line idea; interchangeable parts (runtimes) provide huge increases in efficiency when building cross-platform capable code. But the language you use has to be Java.
In contrast, Microsoft has taken an inclusive approach (at least in regard to language), which is, in essence, that language is simply an interface into a common formatMicrosoft Intermediate Language (MSIL)so it's the runtime code, not the language used to describe it that's important. In contrast to Java, the .NET platform is wide open to any language syntax, including Java's (implemented in .NET as J#). Many language vendors are responding to that inclusionary approach. Languages available or soon to be available for .NET include Delphi, SmallScript, Perl, Eiffel, Fortran, and Cobol.

While it's too soon to comment on the eventual success of this approach, in reductionist terms, Microsoft's approach is to simplify programming by abstracting functionalitybut at the cost of tying the .NET-compatible languages to the .NET Common Language Runtime (CLR). While Microsoft has made the core set of rules for writing a .NET runtime (the Common Language InfrastructureCLI), and one new language, C#, available to the ECMA standards body, the CLI is simply a specification, not an implementation. Even when completely implemented the CLI is nowhere near as comprehensive as the native Windows .NET platform or the core Java platform.

There's an interesting historical parallel here. The Model-T Ford, introduced in 1908, rapidly became ubiquitous, primarily because Henry Ford introduced the idea of the assembly line. By using interchangeable parts, he increased manufacturing efficiency and reduced the price of an automobile to the point where ordinary working people could afford to buy them. However, he also said, famously "The customer can have any color he wants, so long as it's black." Java is similar. You can compare the Java runtime to the assembly-line idea; interchangeable parts (runtimes) provide huge increases in efficiency when building cross-platform capable code. But the language you use has to be Java. It's worth noting that by 1926, Ford was forced to abandon its black-only stance because it was losing sales to other car companies that offered automobiles in color. It's also worth noting that the Model-T was an exceptionally sturdy design, and many of the cars still run today.

We Need Similarity and Simplicity
It's becoming obvious that despite the implementation differences and exclusionary/inclusionary language impulses embodied by Java and .NET, the end results are likely to be highly similar. Learning either platform makes it much easier to learn and work with the other, because both are built on similar object-oriented foundations. The names and syntax may differ, but the ideas are often identical.

Because of their attempts to be all things to all programmers, Java and .NET are necessarily both large and incompleteand both will have to continue expanding to accommodate new technologies.
For example, going back to Strings for a minute, both platforms have a String.Split(splitHow) method that returns an array of substrings from the original string that are delimited in some way. In .NET, the splitHow argument is a character or array of characters to use for the delimiters; whereas in Java, the argument is a regular expression containing a pattern that specifies how the method should search the string for the delimiters. The reductionist process, approached from two different directions, has yielded similar results.

Similarity, however, does not equal simplicity. Because of their attempts to be all things to all programmers, Java and .NET are necessarily both large and incompleteand both will have to continue expanding to accommodate new technologies. For example, the Java platform recently expanded to include XML-processing capabilities, a feature that was originally built into .NET, which has the advantage of being conceived a few years later than Java. But .NET is not exempt from the expansionist urge either. .NET expansion plans are already under way, because Microsoft needs to shift many basic functions out of COM and into .NET, including the underlying Win32 API itself.

Fortunately, as soon as you learn a core subset of either platform, learning more becomes increasingly easy, because the classes and functionality available with either platform are much more consistent internally than was the case between older APIs, and build heavily on other classes in their respective frameworks.

Eventually, new problems, new ideas, new hardware, new APIs, and the sheer size of these platforms will give way to a new attempt at programming reductionism. Maybe in the next surge of reductionism "word" will become a native language concept. I'll welcome the change.



A. Russell Jones is the Executive Editor at DevX. Please reach him at rjones@devx.com
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date