The Pros of High-Level Languages

[ LiB ]

The cost of software is determined by the time it takes to test, debug, modify, and maintain a code base. In a not-too distant past, the programming field was a much more static one. Programming was done in a controlled hardware environment, and things like testability, modification, and portability weren't as important.

High-level languages exist because human time is important. Often the loss of computer runtime efficiency will gladly be traded for actual savings in human labor. The code base for a project using a high-level language might be three times shorter than Java and five times shorter than C++.

Probably the biggest problem with low-level code is that adapting it to different architectures (platforms) can be problematic . If you cut C off from its standard compilers and libraries, it is pretty much incapable of porting to a different architecture. Generally, low-level code has to be rewritten for each specific platform.

High-level languages, on the other hand, are very portable, only needing an alteration to the interpreter or compiler for the new platformor needing nothing at all. Compilation time is usually shortmeasured in seconds sometimes. Human-time debugging on a new platform, especially in a low-level language like assembly, can easily take weeks. This is an obvious trade off.

Another big benefit of high-level languages is reusability. High-level code can be crafted into small components that are easy to use, as well as easy to organize and bring into future projects. Such modularity promotes the creation of formal and informal code libraries. Most high-level languages have particularly great libraries for putting together graphical user interfaces.

Higher-level languages have more human readable words and phrases and fewer abstract symbols, peculiar syntax, and abbreviations. This can make them easier to write and maintain. This makes testing, debugging, and modifying an easier task. Most importantly, it makes reading them easier, a boon for the high turnover world of software development.

Safety in source code is a big issue these days. Many high-level language features have the interesting side effect of producing more secure, bug-free code.

Take, for instance, buffer overruns . A buffer is a device or structure that holds data. Buffer overruns occur when someone overflows a buffer by giving it more data than it can handle. A simple example is a login prompt to a computer or Website. The programmer who develops the login expects that most login names will not be more than eight characters long and gives the buffer that holds the login data enough space in memory to hold eight characters. But then some malicious user comes along and writes 257 characters to the login. If the buffer and input login haven't been specifically designed to handle such a case, the software will fail. Worse, it could allow the user the ability to write data somewhere besides the login prompt.

CERT (the Computer Emergency Response Team ) reports that a majority of bugs and exploitable holes in software (majority meaning as high as 80 percent) are caused by simple buffer overruns. This type of exploit is very common because manually coding pointers and garbage collectors can be a very buggy and error-prone enterprise. High-level languages normally take care of these tasks automatically for the programmer. Taking away the manual process of handling pointers, automatically handling garbage collection, and assigning memory allocation of variables at runtime makes it difficult to cause buffer overruns.

My favorite feature of high-level languages is that they are easy to learnso easy, in fact, that they are often considered fun. High-level languages are particularly suited for applications in which:

The main focus is to connect existing components.
A GUI is required.
A lot of string manipulation is required.
You expect the application's functions to evolve rapidly or change quickly over time.

[ LiB ]