Friday, May 18, 2012

Code Reuse has Finally Arrived...Obviously!

I got into a discussion about code reuse with my co-worker, Jarek. I remember reading books on object oriented programming from a few decades ago in which OOP promised to increase code reuse. A lot of people doubted that serious code reuse would ever happen. OOP suggested that code reuse would be possible by reusing and subclassing existing classes. I even remember hearing C++ programmers talk about purchasing libraries of useful classes.

To some degree, this did actually happen. For instance, QT is a wonderful library for C++, and it certainly makes coding in C++ a lot easier. It was even proprietary up until a few years ago. Library reuse also happened via language-specific package sites such as CPAN (for Perl), PyPI (for Python), and a range of sites for Ruby. Furthermore, most languages come with a lot more stuff built in these days. For instance, compare Python's standard library ("batteries included") with that of C.

However, compared to decades ago, there is less of an emphasis on class-level reuse these days. For instance, rather than trying to code classes that will be flexible enough to solve tomorrow's problems, agile programmers suggests you write your code in such a way that you will be able to modify it to solve tomorrow's problems (with an emphasis on tests that will prevent regressions when you modify the existing code).

These days, rather than focusing on class-level reuse, we've achieved reuse via RESTful web services (and variations thereof) as well as via open source stacks. RESTful web services are usually closed source and proprietary. However, they have a lot of benefits. For instance, they're language agnostic. It's also a lot easier to control access to a RESTful Web Service than it is to a class library. This permits good authorization controls and various monetization strategies.

As I mentioned before, another place where we see a lot of reuse is in the open source stack. Just as Taco Bell has a million things on the menu that are all made from the same 10 ingredients, there are a million startups out there all based on the same stack of open source software. We even have a word for it--LAMP. Sure, there are variations of this--PostgreSQL instead of MySQL, Nginx instead of Apache, Python and Ruby instead of PHP--however, the fact remains that a lot of startups are only possible because of the tremendous amount of code that is available for reuse.

Hence, it's clear that code reuse arrived during the last 10-20 years. It didn't come exactly as we expected, but it's definitely here.

7 comments:

Johannes Schindelin said...

It is really funny for a Java programmer who is used to getting a public API for free with every application out there (every .jar is also a library) to hear people bitch about reusability in languages other than Java.

I guess the problem is that people think Java is not a real programming language, or that they think the Java Virtual Machine is slow or something.

Which makes you really laugh once you saw the numbers: what moron could see those numbers and that degree of reusability and still think this is not for them? Hilarious.

Anonymous said...

Johannes Oh really ? I find it funny that you find it funny

Gary Rowe said...

Interesting article. I use Java as my primary programming language and I make extensive use of open source third-party libraries.

These are normally provided by configuration through a tool like Maven which strongly encourages the code re-use that you are writing about. This re-use occurs at both the binary at source level because Maven will provide you with both (if it has been provided by the author).

This leads to the useful side effect of being able to see how someone else solved the problem you have in their support library. And how they converted their solution into something more general through a workable API.

Zandao said...

Once upon a time there was an environment/language called Smalltalk during the 1980'a that made code reuse the way to do everything, but even being a class oriented language, showed us that the best way to reuse was usually by composition instead of inheritance

Shannon Behrens said...

Johannes, when I said that people wondered whether reuse would ever happen, I was talking about programmers in the 1970s. I wasn't talking about the programmers of today.

No one thinks that Java is not a real programming language.

Most people don't think the JVM is slow (anymore).

Shannon Behrens said...

Gary, nice comment. It's true that class-level reuse happens more in Java than in many other programming languages. However, my point still stands. You probably don't have your database in the same process, and you probably don't have to come up with another operating system for every new generation of machines. You probably also make use of RESTful APIs that aren't written in Java.

Shannon Behrens said...

Zandao, your comment is true. However, from what I've heard, Smalltalk didn't have a very good API for integrating with code not written in Smalltalk. That makes it hard to integrate with the wealth of C libraries out there. To some degree, Python is successful because it is able to orchestrate a bunch of C code at a higher level. Furthermore, if I were using Smalltalk today, my guess is that I'd probably still be using a lot of RESTful Web services and external things like MySQL. MySQL has a client library written in C. Hence, it's hard to integrate with MySQL if you don't have a C API for your VM. Of course, I'm not a Smalltalk expert, so I could be wrong about the history of Smalltalk.