Are scripting languages the wave of the future?

ITworld.com |  Development 1 comment

When Robert Martin talks, programmers listen.

XP! Patterns! UML! Java! C++! OOD! SE! For most of the last 30 years, Martin has worked full time at the center of modern programming practice. His specialties and concerns have been exactly those of the silent majority of professional developers: How do I use STL? Should our team practice extreme programming? Which analysis methodology is effective?
Throughout his career, Bob has been a working programmer himself, informing his "outreach" as an author, editor, publisher, manager, entrepreneur, pundit, and trainer.

Last week, Martin talked to ITworld.com's Cameron Laird and readers in the ITworld.com Interviews forum about the programming languages of the coming decade and other topics. Here's an excerpt:

ITworld.com: Does language make a difference? Your emphasis on code hygiene and expressiveness is welcome. Why, then, do we spend so much time working in C and C++? If an organization comes to you with a coherent set of requirements, and says it's willing to trust you about what language will help it best meet its goals, what advice are you likely to give?

Robert Martin: Language certainly makes a difference; but any language can be written well.

I don't mind C or C++. There are certainly cases where those are the best languages for the job. DSP code, if not written in assembler, is probably best written in C. Hard embedded realtime apps are well done in C++. And many Web apps or MIS/IT apps are nicely done in Java.

However, I think there is a trend in language that will become more and more evident as the decade progresses. I think we are seeing an end to the emphasis on statically typed (type-safe) languages like C++, Java, Eiffel, Pascal, and Ada. These languages force you to declare the types of variables before you can use them.

As this decade progresses I expect to see an ever increasing use of dynamically typed languages, such as Python, Ruby, and even Smalltalk. These languages are often referred to as "scripting languages." I think this is a gross injustice. It is these languages, and languages of their kind, that will be mainstream industrial languages in the coming years.

Why do I think this? Because these languages are much easier to refactor. What's more, they have virtually zero compile time.

As an industry we became enamored of type-safety in the early '80s. Many of us had been badly burned by C or other type-unsafe languages. When type-safe languages like C++, Pascal, and Ada came to the fore, we found that whole classes of errors were eliminated by the compiler.

This safety came at a price. Every variable had to be declared before it was used. Every usage had to be consistent with its declaration. In essence, a kind of "dual-entry bookkeeping" was established for languages. If you wanted to use a variable (first entry) you had to declare it (second entry). This double checking gave the compiler vast power to detect inconsistency and error on the part of the programmer, but at the cost of the double entries, and of making sure that the compiler had access to the declarations.

With the advent of agile processes like extreme programming (XP), we have come to find that unit testing is far more important than we had at first expected. In XP, we write unit tests for absolutely everything. Indeed, we write them before we write the production code that passes them. This, too, is a kind of dual-entry bookkeeping. But instead of the two entries being a declaration and a usage, the two entries are a test and the code that makes it pass.

Again, this double-checking eliminates lots of errors, including the errors that a type-safe compiler finds. Thus, if we write unit tests in the XP way, we don't need type safety. If we don't need type safety, then its costs become very severe. It is much easier to change a program written in a dynamically typed language than it is to change a program written in a type-safe language. That cost of change becomes a great liability if type safety isn't needed.

But there is another cost: The cost of compilation and deployment. If you want to compile a program in C++, you must give the compiler access to all the declarations it needs. These declarations are typically held in header files. Each header file containing a declaration used by the program must be compiled by the compiler. If you have a program with N modules, then to compile just one of them you may have to read in all N header files. With a little thought you'll realize that this means that compile time goes up with the square of the number of modules.

1 comment

      Add a comment

      Post a comment using one of these accounts
      Or join now
      At least 6 characters

      Note: Comment will appear soon after you have activated your account.
      Obscene/spam comments will be removed and accounts suspended.
      The information you submit is subject to our Privacy Policy and Terms of Service.

      ITworld LIVE

      DevelopmentWhite Papers & Webcasts

      White Paper

      HP NonStop SQL Fundamentals whitepaper

      This whitepaper offers a detailed look into the fundamentals of HP NonStop SQL solutions. See how this system delivers unprecedented levels of application availability with fail-safe data integrity and meets the needs of enterprises with large-scale business critical applications.

      White Paper

      Nebraska Medical Center case study

      See how the Nebraska Medical Center implemented a SQL solution to make information more readily available to streamline operations, improve patient care and facilitate medical research with an enterprise solution running on HP NonStop servers.

      White Paper

      Concepts of NonStop SQL/MX

      For DBAs and developers who are familiar with Oracle solutions and want to learn about NonStop SQL/MX, this whitepaper provides an overview of the similarities and differences between the two products-with a specific focus on implementation.

      White Paper

      6 Things Your CIO Needs to Know About Requirements

      If your organization is not predictably successful on technology projects, there is likely an issue in requirements. CIOs must take action and own requirements maturity improvement. There are 6 main things a CIO must know about requirements.

      Webcast On Demand

      User Experience Monitoring

      In this webinar, you will learn hints & tips for improving end-user response times from Forrester Research analyst, Jean-Pierre Garbani.

      Sponsor: Nimsoft

      See more White Papers | Webcasts

      Ask a question

      Ask a Question