The A-Z of Programming Languages: Bourne shell, or sh

An in-depth interview with Steve Bourne, creator of the Bourne shell, or sh

Steve Bourne

Steve Bourne

Where do you see computer programming languages heading in the future, particularly in the next 5 to 20 years?

You know I have tried to predict some of these things and I have not done very well at it. And in this business 20 years is an eternity. I am surprised at the number of new entrants to the field. I thought that we were done with programming language designs back in the late 70s and early 80s. And maybe we were for a while. We had C, C++ and then along comes Java and Python and so on. It seems that the languages that are the most popular have a good set of libraries or methods available for interfacing to different parts of the system. It is also true that these modern languages have learned from earlier languages and are generally better designed as a result.

Since I was wrong in 1980 when we thought ‘well we are done with languages, let’s move on to operating systems, object oriented programming, and then networking’ and whatever else were the other big problems at the time. And then suddenly we get into the Internet Web environment and all these things appear which are different and improved and more capable and so on. So it is fun to be in a field that continues to evolve at such a rapid pace.

You can go on the Internet now and if you want to write, for example, a program to sort your mail files, there is a Python or Perl library you will find that will decode all the different kinds of mail formats there are on the planet. You can take that set of methods or library of functions and use it without having to write all the basic decoding yourself. So the available software out there is much more capable and extensive these days.

I think we will continue to see specialised languages; such as PHP which works well with Web pages and HTML. And then look at Ruby on Rails. Who would have thought LISP would come back to life. It is fun to be an observer and learn these new things.

Do you think there are too many programming languages?

Maybe. But the ones that are good will survive and the ones that aren’t will be seen as fads and go away. And who knows at the time which ones are which. They are like tools in a way; they are applicable in different ways. Look at any engineering field and how many tools there are. Some for very specific purposes and some quite general.

The issue is what set of libraries and methods are available to do all the things you want to do? Like the example I gave about mail files. There are dozens of things like that where you want to be able to process certain kinds of data. And so you want libraries to do things. For example, suppose you want a drawing package. And the question is: what do you want to use the drawing package for? If you are going to write programs to do that do you write them in Perl or Python or what. So it is going to be driven as much by the support these languages have in terms of libraries and sets of methods they have as it by the language itself.

If you were teaching up-and-coming programmers, what would you say?

First, I would be somewhat intimidated because they all know more than I do these days! And the environments today are so much more complicated than when I wrote code. Having said that software engineering hasn’t changed much over the years. The thing we practised in the Unix group was if you wrote some code then you were personally accountable for that code working and if you put that code into public use and it didn’t work then it was your reputation that was at stake. In the Unix lab there were about 20 people who used the system every day and we installed our software on the PDP 11 that everyone else was using. And if it didn’t work you got yelled at rather quickly. So we all tested our programs as much as we could before releasing them to the group. I think that this is important these days – it’s so easy in these large software projects to write code and not understand the environment you will be operating in very well, so it doesn’t work when you release the code in the real world. That is one piece of advice I’d give is to make sure you understand who is using your code and what they will use it for. If you can, go and visit your customers and find out what they are doing with your code. Also be sure to understand the environment that your program will be deployed into. Lastly, take pride in your code so that your peers and customers alike will appreciate your skill.

Join the newsletter!

Error: Please check your email address.

Tags a-z of programming languages

More about Bell LabsBillCitizen Watches AustraliaCreatorEvolveIBM AustraliaLinuxMicrosoftObject OrientedSpeedVIA

Show Comments