Skip to main content

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.

Comments

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.
Unknown 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
jjinux 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).
jjinux 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.
jjinux 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.

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within Tunes.org , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and jabber.org. Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p