devxlogo

Programming Reductionism: When Less Is Truly More

Programming Reductionism: When Less Is Truly More

eductionism is an ongoing attempt to explain complex ideas in terms of a relatively few simple or primitive ones. As such, reductionism is the heart of programming. Over the past few years, there’s been a huge increase in the amount of reusable code conveniently available to developers, primarily because both Java and .NET package large blocks of functionality into their respective platforms. In other words, both platforms reduce the amount of code that a programmer must write to accomplish a task.

Characters, Strings, and Words
Take something as simple as a string. A string is nothing but an array of characters.

This?is?a?string

Of course to a computer, these “characters” are just numbers. Without going into the complexities involved in translating a particular number to a particular character, it’s been relatively easy to teach the computer the concept of character. That is, “characterness,” to a computer, is nothing more than a particular interpretation of the “meaning” of a number.

But the computer’s connection to human language stops at this primitive character level. When told to treat the byte sequence above as a string, the computer easily translates it to a series of characters; however, to humans, the string is also a sequence of “words.” Unfortunately, it’s much more difficult to teach a computer the concept of “word” than of “character,” because words don’t fit neatly into bits and bytes. Sure, you can teach a computer that a word is a string of characters delimited by white space or punctuation, but the computer has no concept of words as discretely important by themselves. People though, insist on seeing strings as collections of words.

Java and .NET are strikingly similar in many ways, which may mean that reductionism in programming inevitably tends to produce similar results.

Over the years, countless thousands of programmers have written code countless thousands of times to take a string and split it into individual words, or to search within a string for a word, or insert a word, remove a word, check the spelling of a word, reverse a word, capitalize it, lower-case it, compress it, squeeze it, translate it, randomize it, turn it into a number, a date, a time, a symbol, a path, or a filenameand each and every one of those programmers had to learn how to deal with the string as…words.

Although it’s long overdue, the gods of platform design have finally realized that by including concepts such as “words” as fundamental capabilities of the platforms themselves, they could make programming a good deal easier for everyone. And that’s what we’re seeing today. Reductionism. Taking common tasks such as “split a string into words” and putting functionality to accomplish them directly into the platform. It’s not a new concept, but the fact that it’s becoming ubiquitously available in the most common platforms is new.

Java and .NET now handle such things natively. As the level of capability between languages (or platforms) grows toward equivalency, the platforms themselves tend to become more and more alike. Java and .NET are strikingly similar in many ways, which may mean that reductionism in programming inevitably tends to produce similar results. Whether that’s true or not, it brings up this question: Does the fact that the two platforms are so similar indicate that we’re reaching the pinnacle of the reductionist process? I thinkno, I fervently hopethat it’s simply a plateau at which language designers have gathered in preparation for the next surge of reductionism.

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.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist