Download Introduction to programming languages /history and more Study notes Computer Programming in PDF only on Docsity!
The A-Z of Programming Languages
(^1) When the table of contents is being read using a PDF viewer, the titles link to the Web pages of the original
- Computerworld, 2008-2010 (interviews with programming language creators)
- Ada: S. Tucker Taft
- Arduino: Tom Igoe
- ASP: Microsoft
- AWK: Alfred Aho
- AWK & AMPL: Brian Kernighan
- Bash: Chet Ramey.
- C#: Anders Hejlsberg.
- C++: Bjarne Stroustrup
- Clojure: Rich Hickey
- ColdFusion: Jeremy Allaire
- D: Walter Bright
- Erlang: Joe Armstrong.
- F#: Don Syme
- Falcon: Giancarlo Niccolai
- Forth: Charles Moore
- Groovy: Guillaume Laforge
- Haskell: Simon Peyton-Jones.
- INTERCAL: Don Wood.
- JavaScript: Brendan Eich.
- Lua: Roberto Ierusalimschy.
- MATLAB: Cleve Moler
- Modula-3: Luca Cardelli.
- Objective-C: Brad Cox
- Perl: Larry Wall
- Python: Guido van Rossum
- Scala: Martin Odersky
- Sh: Steve Bourne
- Smalltalk-80: Alan Kay
- Tcl: John Ousterhout
- YACC: Stephen Johnson
well as supporting run-time polymorphism with the equivalent of virtual functions and run-time type tags.
What prompted the Ada revision in 95?
ISO standards go through regular revision cycles. Generally every five years a standard must be reviewed, and at least every ten years it must be revised. There were also some specific concerns about the language, though generally the language had turned out to be a reasonably good fit to the needs of mission-critical software development. In particular, Ada’s strong support for abstract data types in the guise of packages and private types had emerged as a significant step up in software engineering, and Ada’s run-time checking for array bounds and null pointers had helped catch a large class of typical programming errors earlier in the life-cycle.
Was there a particular problem you were trying to solve?
Object-oriented programming was growing in popularity at the time, though it was still not fully trusted by much of the mission-critical software development community. In addition, the Ada 83 tasking model was considered elegant, but did not provide the level of efficiency or control that many real-time system developers would have preferred. Once the Ada 9X revision process began, a requirements team was formed to solicit explicit comments from the Ada community about the language, both in terms of things to preserve and things to improve.
Have you faced any hard decisions in your revision of Ada?
Every language-design decision was pretty hard, because there were many goals and requirements, some of which were potentially conflicting. Perhaps the most difficult decisions were political ones, where I realized that to achieve consensus in the language revision process among the ISO delegations, we (the design team) would have to give up some of our personal favourite revision proposals.
Are you still working with the language now and in what context?
Yes, I am still working with the language, both as a user and as a language designer. As you may know the newest version of the language, known as Ada 2005, just recently achieved official standardization. The Ada 2005 design process was quite different from the Ada 95 process, because Ada 2005 had no Department of Defense supported design team, and instead had to rely on strictly voluntary contributions of time and energy. Nevertheless, I am extremely proud of the accomplishments of the Ada 2005 design working group. We managed to round out many of the capabilities of Ada 95 into a language that overall I believe is even better integrated, is more powerful and flexible, while also being even safer and more secure.
Would you have done anything differently in the development of Ada 95 or Ada 2005 if you had the chance?
The few technical problems in the development of Ada 95 that emerged later during use were either remedied immediately, if minor, through the normal language maintenance activities (‘we couldn’t have meant that... we clearly meant to say this’). Or if more major, were largely addressed in the Ada 2005 process. From a process point of view, however, I underestimated the effort required in building international consensus, and in retrospect I should have spent more time establishing the rationale for revision proposals before springing them on the panel of distinguished reviewers and the ISO delegations.
Are you aware of any of the Defence projects for which the language has been used?
Ada was mandated for use by almost all significant Defense department software projects for approximately 10 years, from 1987 to 1997, and there were a large number of such projects. In the early years there were real challenges because of the immaturity of the Ada compilers. In the later years, in part because of the early difficulties, there were a number of projects that applied and received waivers to allow them to use other languages. Nevertheless, in the middle years of 1989 to 1995 or so, there was a boom in the use of Ada, and much of it was quite successful.
As far as specific projects, the Apache helicopter and the Lockheed C-130J (Hercules II Airlifter) are two well-known examples. The Lockheed C-130J is particularly interesting because it was developed using a formal correctness-by-construction process using the SPARK Ada-based toolset from Praxis High Integrity Systems. The experience with that process was that, compared to industry norms for developing safety-critical avionics software, the C-130J development had a 10 times lower error rate, four times greater productivity, half as expensive a development process, and four times productivity increase in a subsequent project thanks to substantial reuse. NASA has also used Ada extensively for satellite software, and documented significantly higher reuse than their prior non-Ada systems. In general, in study after study, Ada emerged as the most cost effective way to achieve the desired level of quality, often having an order-of-magnitude lower error rates than comparable non-Ada systems after the same amount of testing.
Can you elaborate more on the development of the Static Interface Analysis Tool (SIAT) for Ada on behalf of the NASA Space Stations IV&V?
The SIAT project was an early attempt to create a browser-based tool for navigating through a complex software system. The particular use in this case was for analyzing the software designed for the large network of computers aboard the International Space Station. It turns out that these systems have a large number of data interfaces, where one computer would monitor one part of the Space Station and report on its state to other computers, by what amounted to a large table of global variables. The SIAT tool was designed to help ensure that the interfaces were consistent, and that data flowed between the computers and these global variable tables in an appropriate way.
Are you aware of why the Green proposal was chosen over the Red, Blue and Yellow proposals at the start of Ada’s development?
The Green proposal reached a level of stability and completeness earlier than the other designs, and Jean Ichbiah did an excellent job of presenting its features in a way that the reviewers could understand and appreciate. Although there were flashes of brilliance in the other designs, none of them achieved the polish and maturity of the Green design.
Did you ever work closely with Jean Ichbiah? If so, what was the working relation- ship like and what did you do together?
I worked on and off with Jean during the final days of the Ada 83 design, and during some of the Ada maintenance activities prior to the start of the Ada 9X design process. Jean was busy running his own company at the start of the Ada 9X process, but did end up joining the process as a reviewer for a period during 1992 and 1993. As it turned out, Jean and I had quite different views on how to design the object-oriented features of the updated language, and he ultimately left the project when it was decided to follow the design team’s recommended approach.
In your opinion, what lasting legacy have Ada and Ada 95 brought to the Web?
I believe Ada remains the benchmark against which all other languages are compared in the dimension of safety, security, multi-threading, and real-time control. It has also been a source for many of the advanced features in other programming languages. Ada was one of the first widely-used languages to have a language construct representing an abstraction (a package), an abstract data type (a private type), multi-threading (tasks), generic templates, exception handling, strongly-typed separate compilation, subprogram inlining, etc. In some ways Ada was ahead of its time, and as such was perceived as overly complex. Since its inception, how- ever, its complexity has been easily surpassed by other languages, most notably C++, while its combination of safety, efficiency, and real-time control has not been equaled.
Where do you envisage Ada’s future lying?
As mentioned above, Ada remains the premier language for safety, security, multi-threading, and real-time control. However, the pool of programmers knowing Ada has shrunk over the years due to its lack of success outside of its high-integrity niche. This means that Ada may
Arduino: Tom Igoe
What prompted the development of Arduino?
There were a handful of schools teaching microcontrollers to non-technologists using a method we called physical computing. We all needed tools to teach that were simpler than the engineering tools that were out there. The Basic Stamp, and later the BX-24 from NetMedia, were okay but they really didn’t match up to the tools we were using to teach programming (Hypercard, Director, and later Processing). Then at Ivrea in 2002, they started to do something about it. They developed Programa2003, then Wiring, then Arduino.
The Arduino developer team comprised Massimo Banzi, David Cuartielles, Gianluca Martino, David Mellis, Nicholas Zambetti – who were the pioneers – and yourself. Who played what roles?
Massimo developed the Programa2003 environment for PIC. It was a simple PIC programming tool on the Mac (most of the Ivrea students were Mac users). It made it easier to teach his class. That, combined with the Processing IDE served as an example for Hernando Barrag´an to develop the Wiring board and environment. Shortly thereafter, Massimo (faculty at Ivrea), David Cuatielles (researcher at Ivrea), and Gianluca Martino (local engineer, hired to develop hardware for students’ projects) developed a smaller, less expensive board, the Arduino board. Working togetther with Mellis and Zambetti (students at Ivrea at the time), they improved on the Wiring model and came up with a board and an IDE that could be used by the outside world. I joined them in 2005, helping to beta test it with another school (ITP has a large student body relative to Ivrea, so we could give it a bigger test), and later, helping to develop documentation. I also introduced the team to some of the early US distributors so we could build a market here as well as in Europe. Nowadays, Gianluca and Massimo do the bulk of the hardware design, Dave Mellis coordinates or writes most of the software, David Cuartielles works on software as well as testing on Linux and maintains the website, and I work on documentation as well as testing, to a lesser degree. We all work together on the direction of the project, manufacturer relations and new development. Gianluca manages all the distributors and his company, Smart Projects, is the main hardware manufacturer. Zambetti has left the core team, but is still an occasional contributor when his professional life allows.
Were you trying to solve a particular problem?
We wanted a tool to teach physical computing, specifically microcontroller programming, to artists and designers, who we teach. The assumptions of those coming at it from a background other than computer science (CS) or electrical engineering (EE) are quite different, and we wanted tools that matched those assumptions.
Where does the name Arduino come from?
Arduino was the first king of the region in which Ivrea is situated. It was also the name of a local bar where students and faculty of Ivrea would congregate.
Were there any particularly difficult or frustrating problems you had to overcome in the development of Arduino?
The biggest challenge hasn’t really been a technical one so much as a cultural one. Most CS/EE people I’ve met have an assumption about how you learn about microcontrollers: first you learn Ohm’s law and Thevenin’s Law, etc. Then you learn about transistor circuits and op amps, then discrete integrated circuits (ICs). Somewhere in there you learn to use an oscilloscope, and a multimeter if you have to, but the scope’s better. Then you’re introduced to microcontrollers, starting with the internal structure and memory registers. Then you learn the assembly language, and by then, ‘of course’ you know C and the command line environment, so you’re ready for, say, CCS C (on the PIC) or AVR Studio. And 90 per cent of this is done on Windows, because 90 per cent of the world runs Windows, so it makes sense to develop there. A large number of people coming to code and microcontrollers nowadays don’t come from
that background. They grew up assuming that the computer’s GUI was its primary interface. They assume you can learn by copying and modifying code, because that’s what the browser affords with ‘view source.’ Most of them don’t actually want to be programmers, they just want to use programming and circuits to get things done. That may mean making an art piece, or an automatic cat feeder, or a new occupational therapy device. These people are not formally trained engineers, but they want to build things. These are the students we teach. It’s their way of thinking for which we designed Arduino.
Would you have done anything differently in the development of Arduino if you had the chance?
I think the biggest change we might have made would have been to standardize the spacing between pins 7 and 8! We’ve gotten a lot of grief for that mistake, but we’ve maintained the non-standard spacing to maintain backwards compatibility of the boards. Mostly, though, I don’t think there is an answer to ‘what would you do differently,’ because when we encounter something we’d do differently, we make a change. The changes are slower now that we have a larger user base to support, but they are still possible.
Why was ‘Wiring’ and ‘Processing’ chosen as a basis for Arduino’s programming language and environment?
Because they were the tools in use at Ivrea (and ITP) at the time, and because they worked better for teaching to our students than the alternatives that were available at the time. Processing in particular had made a big change for art and design schools teaching programming, because the students ‘got it.’ It made sense to make a hardware development environment based on that. Specifically, because Processing was in use at Ivrea and ITP at the time. Programa2003, Wiring, and Arduino all grew from Processing’s roots in quick succession.
How does the Arduino compare to BASIC Stamp, PICs, et. al.? What makes it a better choice?
There are a couple of things we’ve tried to improve upon.
- The Arduino language is a set of methods in C/C++ that makes it easier to understand for beginners. Unlike the Stamp’s PBASIC, it has all the powerful functions of C (parameter passing, local variables, and so forth) wrapped in a readable syntax. PBASIC was readable and easy for beginners, but it was so limited that even beginners quickly hit limits to what they could do.
- The user experience of Arduino is more like consumer-grade user experience. There’s no need to learn about a hardware programmer (unlike the PIC environments), it plugs into the USB (unlike the Stamp). Compiling and uploading new code to your controller is one click. The method names are verbose, and closer in spirit to everyday language than C, assembly, or lower level languages. Ideally, the whole user experience is designed to minimize the time from idea to working device, while maintaining as much of the power and flexibility of the underlying components as possible.
- Arduino embodies what I call ‘glass box encapsulation.’ That means that you don’t have to look at the lower level code that comprises the libraries if you don’t want to, but you can if you choose. The libraries are compiled only when you compile your final sketch. So if you want to modify them, you can. If you want to include non-Arduino-style C in your code, you can. If you want to include raw assembler code, you can. The encapsulation box is still there, but you can see through it if you choose. The higher level controllers like the Stamp don’t include that. And the lower level environments don’t abstract to the same level as we do.
- The board incorporates a serial bootloader on the controller, and a USB-to-serial chip, so you don’t have to think about the supporting computer-to-controller circuit. It’s also got an on-board power jack and a regulator circuit that switches automatically from the USB to external power, again to simplify the shift from connected to the computer to standalone.
- The price tag for the board is reasonable (cheaper than a Stamp board) and the software’s free. We want people to think about computing, rather than see their controller as one
prototypes for a lighting company in Italy. That project made me see how useful a platform it was. I also use it in my teaching. It’s the first hardware platform I’ve used that I feel like I can teach beginners with, and also use in my professional work as well. As for personal projects: I developed a new version of my email clock (a clock that ticks forward for each new email received) using Arduino. I made a cat bed that emails me when it’s taken a picture of the cat; an air-quality meter; a blinking fan sign for my favorite roller derby team; and more. I use it in class just about every day.
Have you ever seen Arduino used in a way you never intended it to be deployed?
Well, it was intended to be deployed in a wide variety of ways, so not really. I guess for me, the one thing I never intend it to be used for is to hurt people or to do damage, so I hope I never see it used for that.
Do you have any advice for up-and-coming hardware hackers?
Patience. Persistence. And frequent showers. I get my best problem solving done in the shower.
Finally, is there anything else you’d like to add?
Thanks to everyone who’s used Arduino! We’ve had a great time working on it, and it’s incredibly rewarding to see people realise things they didn’t think were possible because of something we made.
ASP: Microsoft
ASP is Microsoft’s server-side script engine and Web application framework ASP.NET, used to build dynamic Web sites, applications and Web services
Why was ASP created and what problem/s was it trying to solve?
Active Server Pages (ASP) was initially created to address the challenge of building dynamic Web sites and Web-based business solutions. It was first released with IIS 3.0 (Internet Information Server) in 1996. Creating and updating static Web sites was a very time consuming task that was prone to human error. In order to avoid mistakes, every page would require careful attention during changes. Furthermore, the potential use of Web sites was very limited using HTML exclusively. There needed to be an efficient way to change content quickly, in real time. ASP enabled the easy integration of databases as well as more advanced business and application logic that the Web is known for today.
Explain the early development of ASP.NET. Who was involved, and what difficult decisions had to be made?
Scott Guthrie is one of the original creators of Microsoft’s ASP.NET and, today, is the Corporate Vice President of the Microsoft Developer Division. The early development of ASP.NET focused on developer productivity and enabling powerful, Web-based solutions. The key goal was to help make it easier for traditional developers who had never done Web development before to be successful in embracing this new development paradigm. ASP.NET was a breakthrough technology that fundamentally changed the way developers approached and delivered Web sites – bringing it more in line with traditional software develop- ment. Building a brand new Web application framework was a difficult decision to make, especially since many customers had already adopted ASP. We felt it was the best approach, since it pro- vided customers with one robust and consistent development platform to build software solutions. A Web developer could now reuse his existing skill set to build desktop or mobile applications. When we released ASP.NET, we did not want to force customers to upgrade. As a result, we ensured that ASP would work in each subsequent release of IIS. Today, we still continue to support the ASP runtime, which was included as part of IIS7 in Windows Server 2008.
What is the difference between ASP and ASP.NET and why would developers choose one over the other?
ASP and ASP.NET are both server-side technologies and the similarities basically stop there. If a developer is interested in writing less code, we would recommend ASP.NET. There are a myriad of other reasons too, including:
- Great tool support provided by the Visual Studio family and Expression Studio, which makes developers more productive and working with designers much easier.
- ASP.NET AJAX integrated in the framework, which allows a better end-user experience.
- Breadth of the .NET Framework, which provides a wealth of functionality to address both common scenarios and complex ones too. I would encourage a developer to visit asp.net to find out more. A key thing to consider is that ASP.NET is the focus for Microsoft and we are not making any new investments in ASP. I’d highly encourage anyone to use ASP.NET over ASP.
Given a second chance, is there anything Microsoft could have done differently in the development of ASP.NET?
ASP.NET was created to meet the needs of our customers building Web solutions. As with any incubation or v1 product, the biggest change we would have made is to have more transparent and customer integrated product development – much like we have today. Discussion with customers allows us to be better equipped to make decisions that affect them. For example, ASP.NET MVC (Model-View-Controller) was a request from customers interested in test driven development.
AWK: Alfred Aho
Computer scientist and compiler expert Alfred V. Aho is a man at the forefront of computer science research. He has been involved in the development of programming languages from his days working as the vice president of the Computing Sciences Research Center at Bell Labs to his current position as Lawrence Gussman Professor in the Computer Science Department at Columbia University. As well as co-authoring the ‘Dragon’ book series, Aho was one of the three developers of the AWK pattern matching language in the mid-1970s, along with Brian Kernighan and Peter Weinberger. Computerworld recently spoke to Professor Aho to learn more about the development of AWK
How did the idea/concept of the AWK language develop and come into practice?
As with a number of languages, it was born from the necessity to meet a need. As a researcher at Bell Labs in the early 1970s, I found myself keeping track of budgets, and keeping track of editorial correspondence. I was also teaching at a nearby university at the time, so I had to keep track of student grades as well. I wanted to have a simple little language in which I could write one- or two-line programs to do these tasks. Brian Kernighan, a researcher next door to me at the Labs, also wanted to create a similar language. We had daily conversations which culminated in a desire to create a pattern-matching language suitable for simple data-processing tasks. We were heavily influenced by grep, a popular string-matching utility on Unix, which had been created in our research center. grep would search a file of text looking for lines matching a pattern consisting of a limited form of regular expressions, and then print all lines in the file that matched that regular expression. We thought that we’d like to generalize the class of patterns to deal with numbers as well as strings. We also thought that we’d like to have more computational capability than just printing the line that matched the pattern. So out of this grew AWK, a language based on the principle of pattern-action processing. It was built to do simple data processing: the ordinary data processing that we routinely did on a day-to-day basis. We just wanted to have a very simple scripting language that would allow us, and people who weren’t very computer savvy, to be able to write throw-away programs for routine data processing.
Were there any programs or languages that already had these functions at the time you developed AWK?
Our original model was grep. But grep had a very limited form of pattern action processing, so we generalized the capabilities of grep considerably. I was also interested at that time in string pattern matching algorithms and context-free grammar parsing algorithms for compiler applications. This means that you can see a certain similarity between what AWK does and what the compiler construction tools lex and yacc do. lex and yacc were tools that were built around string pattern matching algorithms that I was working on: lex was designed to do lexical analysis and yacc syntax analysis. These tools were compiler construction utilities which were widely used in Bell labs, and later elsewhere, to create all sorts of little languages. Brian Kernighan was using them to make languages for typesetting mathematics and picture processing. lex is a tool that looks for lexemes in input text. Lexemes are sequences of characters that make up logical units. For example, a keyword like then in a programming language is a lexeme. The character t by itself isn’t interesting, h by itself isn’t interesting, but the combination then is interesting. One of the first tasks a compiler has to do is read the source program and group its characters into lexemes. AWK was influenced by this kind of textual processing, but AWK was aimed at data- processing tasks and it assumed very little background on the part of the user in terms of
programming sophistication.
Can you provide Computerworld readers with a brief summary in your own words of AWK as a language?
AWK is a language for processing files of text. A file is treated as a sequence of records, and by default each line is a record. Each line is broken up into a sequence of fields, so we can think of the first word in a line as the first field, the second word as the second field, and so on. An AWK program is a sequence of pattern-action statements. AWK reads the input a line at a time. A line is scanned for each pattern in the program, and for each pattern that matches, the associated action is executed. A simple example should make this clear. Suppose we have a file in which each line is a name followed by a phone number. Let’s say the file contains the line Naomi 1234. In the AWK program the first field is referred to as $1, the second field as $2, and so on. Thus, we can create an AWK program to retrieve Naomi’s phone number by simply writing $1 == "Naomi" {print $2} which means if the first field matches Naomi, then print the second field. Now you’re an AWK programmer! If you typed that program into AWK and presented it with the file that had names and phone numbers, then it would print 1234 as Naomi’s phone number. A typical AWK program would have several pattern-action statements. The patterns can be Boolean combinations of strings and numbers; the actions can be statements in a C-like programming language. AWK became popular since it was one of the standard programs that came with every Unix system.
What are you most proud of in the development of AWK?
AWK was developed by three people: me, Brian Kernighan and Peter Weinberger. Peter Wein- berger was interested in what Brian and I were doing right from the start. We had created a grammatical specification for AWK but hadn’t yet created the full run-time environment. Wein- berger came along and said ‘hey, this looks like a language I could use myself,’ and within a week he created a working run time for AWK. This initial form of AWK was very useful for writing the data processing routines that we were all interested in but more importantly it provided an evolvable platform for the language. One of the most interesting parts of this project for me was that I got to know how Kernighan and Weinberger thought about language design: it was a really enlightening process! With the flexible compiler construction tools we had at our disposal, we very quickly evolved the language to adopt new useful syntactic and semantic constructs. We spent a whole year intensely debating what constructs should and shouldn’t be in the language. Language design is a very personal activity and each person brings to a language the classes of problems that they’d like to solve, and the manner in which they’d like them to be solved. I had a lot of fun creating AWK, and working with Kernighan and Weinberger was one of the most stimulating experiences of my career. I also learned I would not want to get into a programming contest with either of them however! Their programming abilities are formidable. Interestingly, we did not intend the language to be used except by the three of us. But very quickly we discovered lots of other people had the need for the routine kind of data processing that AWK was good for. People didn’t want to write hundred-line C programs to do data processing that could be done with a few lines of AWK, so lots of people started using AWK. For many years AWK was one of the most popular commands on Unix, and today, even though a number of other similar languages have come on the scene, AWK still ranks among the top 25 or 30 most popular programming languages in the world. And it all began as a little exercise to create a utility that the three of us would find useful for our own use.
How do you feel about AWK being so popular?
I am very happy that other people have found AWK useful. And not only did AWK attract a lot of users, other language designers later used it as a model for developing more powerful languages. About 10 years after AWK was created, Larry Wall created a language called Perl, which
ures and examples; for instance, it translates Figure AWK-program into Figure 1.1. This AWK program allows me to rearrange and renumber figures and examples at will in my papers and books. I once saw a paper that had a 1000-line C that had less functionality than these two lines of AWK. The economy of expression you can get from AWK can be very impressive.
How has being one of the three creators of AWK impacted your career?
As I said, many programmers know me for AWK, but the computer science research community is much more familiar with my theoretical work. So I initially viewed the creation of AWK as a learning experience and a diversion rather than part of my regular research activities. However, the experience of implementing AWK has greatly influenced how I now teach programming languages and compilers, and software engineering. What I’ve noticed is that some scientists aren’t as well known for their primary field of research by the world at large as they are for their useful tools. Don Knuth, for example, is one of the world’s foremost computer scientists, a founder of the field of computer algorithms. However, he developed a language for typesetting technical papers, called TEX. This wasn’t his main avenue of research but TEX became very widely used throughout the world by many scientists outside of computer science. Knuth was passionate about having a mathematical typesetting system that could be used to produce beautiful looking papers and books. Many other computer science researchers have developed useful programming languages as a by-product of their main line of research as well. As another example, Bjarne Stroustrup developed the widely used C++ programming language because he wanted to write network simulators.
Would you do anything differently in the development of AWK looking back?
One of the things that I would have done differently is instituting rigorous testing as we started to develop the language. We initially created AWK as a throw-away language, so we didn’t do rigorous quality control as part of our initial implementation. I mentioned to you earlier that there was a person who wrote a CAD system in AWK. The reason he initially came to see me was to report a bug in the AWK complier. He was very testy with me saying I had wasted three weeks of his life, as he had been looking for a bug in his own code only to discover that it was a bug in the AWK compiler! I huddled with Brian Kernighan after this, and we agreed we really need to do something differently in terms of quality control. So we instituted a rigorous regression test for all of the features of AWK. Any of the three of us who put in a new feature into the language from then on, first had to write a test for the new feature. I have been teaching the programming languages and compilers course at Columbia University, for many several years. The course has a semester long project in which students work in teams of four or five to design their own innovative little language and to make a compiler for it. Students coming into the course have never looked inside a compiler before, but in all the years I’ve been teaching this course, never has a team failed to deliver a working compiler at the end of the course. All of this is due to the experience I had in developing AWK with Kernighan and Weinberger. In addition to learning the principles of language and compiler design, the students learn good software engineering practices. Rigorous testing is something students do from the start. The students also learn the elements of project management, teamwork, and communication skills, both oral and written. So from that perspective AWK has significantly influenced how I teach programming languages and compilers and software development.
AWK & AMPL: Brian Kernighan
We spoke with Brian Kernighan – a figure who helped popularise C with his book, co-written with the creator Dennis Ritchie, The C Programming Language and con- tributed to the development of AWK and AMPL
You maintain you had no part in the birth of C, but do you think the language would have been as successful as it has been without the book?
The word is not ‘maintained’; it’s ‘stated accurately’. C is entirely Dennis Ritchie’s work. C would have done just fine on its own, since as a language it achieved a perfect balance among efficiency, expressiveness, and power. The book probably helped, though I think more in spread- ing the language early on than in its ultimate acceptance. Of course, it helped enormously to have Dennis as co-author, for his expertise and his writing.
In the ten years since you launched The Practice of Programming, a separate book written with Rob Pike, has the way programmers operate changed enough for you to consider amending any parts of the publication?
Programming today depends more and more on combining large building blocks and less on detailed logic of little things, though there’s certainly enough of that as well. A typical program- mer today spends a lot of time just trying to figure out what methods to call from some giant package and probably needs some kind of IDE like Eclipse or XCode to fill in the gaps. There are more languages in regular use and programs are often distributed combinations of multiple languages. All of these facts complicate life, though it’s possible to build quite amazing systems quickly when everything goes right. I think that the advice on detailed topics in The Practice of Programming is sound and will always be – one has to find the right algorithms and data structures, one has to test and debug and worry about performance, and there are general issues like good notation that will always make life much better. But it’s not clear to me or to Rob that we have enough new good ideas for a new book, at least at the moment.
What advice do you have for young programmers starting out? Would you recom- mend a grounding in COBOL like you had, for example?
Every language teaches you something, so learning a language is never wasted, especially if it’s different in more than just syntactic trivia. One of Alan Perlis’s many wise and witty epigrams says, ‘A language that doesn’t affect the way you think about programming is not worth knowing.’ On the other hand, I would not suggest COBOL as a primary focus for most people today – I learned it as part of a summer job and long ago, not because it taught me something new (though it did that as well). No matter what, the way to learn to program is to write code, and rewrite it, and see it used, and rewrite again. Reading other people’s code is invaluable as well. Of course all of these assume that the code is good; I don’t see a lot of benefit in reading a lot of bad code, other than to learn what to avoid, and one should, of course, not write bad code oneself. That’s easier said than done, which is why I stress rewriting.
Who would you consider to be the icons of the programming world?
For purely parochial reasons, I think of people who I know or whose work I know well. Ken Thompson and Dennis Ritchie changed my life and yours; we would not be having this conver- sation without them. People who created major languages would also fall into that camp, for instance we all regularly use languages created by Bjarne Stroustrup, James Gosling, Larry Wall, and Guido van Rossum. And of course there are super-icons like Don Knuth and Fred Brooks. But this is a personal list; there are many others whose work has been influential, and your list would surely differ.
Bell Labs has produced some of the most influential figures in the world as far as IT goes – does it still maintain its relevance in your view? What could it do to better its acclaimed past?
Bell Labs was an astonishing place for many decades, though it fell on somewhat hard times
Bash: Chet Ramey
Bash, or the Bourne-Again Shell is a Unix shell created in 1987 by Brian Fox. Ac- cording to Wikipedia, the name is a pun on an earlier Unix shell by Stephen Bourne (called the Bourne shell), which was distributed with Version 7 Unix in 1978. In 1990, Chet Ramey, Manager of the Network Engineering and Security Group in Technology Infrastructure Services at Case Western Reserve University, became the primary maintainer of the language. Computerworld tracked down Ramey to find out more
How did you first become involved with Bash?
In 1989 or so, I was doing network services and server support for [Case Western Reserve] University (CWRU), and was not satisfied with the shells I had available for that work. I wasn’t really interested in using sh for programming and csh/tcsh for interactive use, so I began looking around for a version of sh with the interactive features I wanted (job control, line editing, command history, filename completion, and so on.) I found a couple of versions of the SVR2 shell where those features had been added (credit to Doug Gwyn, Ron Natalie, and Arnold Robbins, who had done the work). These were available to CWRU because we were Unix source licensees, but I had trouble with them and couldn’t extend them the way I wanted. Ken Almquist was writing ASH, but that had not been released, and there was a clone of the 7th edition shell, which eventually became PDksh, but that did not have the features I wanted either. Brian Fox had begun writing bash and readline (which was not, at that time, a separate library) the year before, when he was an employee of the FSF. The story, as I recall it, was that a volunteer had come forward and offered to write a Bourne Shell clone. After some time, he had produced nothing, so Richard Stallman directed Brian to write a shell. Stallman said it should take only a couple of months. I started looking again, and ended up finding a very early version of bash. I forget where I got it, but it was after Brian had sent a copy to Paul Placeway from Ohio State – Paul had been the tcsh maintainer for many years, and Brian asked him to help with the line editing and redisplay code. I took that version, made job control work and fixed a number of other bugs, and sent my changes to Brian. He was impressed enough to begin working with me, and we went on from there. I fixed many of the bugs people reported in the first public versions of bash and fed those fixes back to Brian. We began working together as more or less co-maintainers, and when Brian moved on to other things, I still needed to support bash for my local users, so I produced several local releases. Brian and I eventually merged those versions together, and when he moved away from bash development, I took over.
Did you work with Brian Fox before becoming the primary maintainer of the lan- guage?
Brian and I worked together for several years before he moved on to other things. The versions through bash-1.13 were collaborative releases.
What is/was your working relationship with Brian like?
Our working relationship was very good, especially considering we met in person only once, in
- We were heavy users of Unix talk and ntalk, which allowed real-time two-way communi- cation over the Internet back then, and made good use of email and the occasional long distance phone call. We still stay in touch.
What prompted the making of Bash in the first place?
When Richard Stallman decided to create a full replacement for the then-encumbered Unix systems, he knew that he would eventually have to have replacements for all of the common utilities, especially the standard shell, and those replacements would have to have acceptable licensing. After a couple of false starts (as previously mentioned), he hired Brian Fox to write
it. They decided early on that they would implement the shell as defined by the Posix standard, and used that as a specification.
Was there a particular problem that the language aimed to solve?
In bash’s case, the problem to be solved was a free software version of the Posix standard shell to be part of the GNU system. The original version of the shell (Steve Bourne’s version) was intended to overcome a number of the limitations of the Unix shell included in versions up to the sixth edition, originally written by Ken Thompson.
Why did you take over as the language’s primary maintainer three years after Fox created the language?
Brian wanted to move on to other things, and I was a developer willing to take it on and experienced with the code. Brian and the FSF trusted me with the program’s future.
What prompted the writing of the GNU Bash Reference Manual and the Bash Reference Manual?
Any good heavily-used program needs good reference documentation, and bash is no exception. I originally wrote the documents to support my local users, and they were folded into official releases along the line.
Is there a strong relationship between the original Bourne Shell and the Bourne- Again Shell?
I’d say there is a linear relationship: the original Bourne Shell was very influential, the various System V shell releases preserved that heritage, and the Posix committee used those versions as the basis for the standard they developed. Certainly the basic language syntax and built-in commands are direct descendants of the Bourne shell’s. bash’s additional features and functionality build on what the Bourne shell provided. As for source code and internal implementation, there’s no relationship at all, of course.
What prompted the language’s name: why was a pun created on the Bourne Shell?
The FSF has a penchant for puns, and this one seemed appropriate, I suppose. The name predates my involvement.
Have you faced any hard decisions in maintaining the language?
The hardest decisions are the ones dealing with compatibility: how compatible to be with the versions of sh existing at various points throughout bash’s history; how compatible to be with the features from the Korn shell I considered valuable; where and how to differ from the Posix standard, and when to break backwards compatibility with previous bash versions to correct mistakes I had made. Some of the features implemented (and not implemented) required a lot of thought and con- sideration – not how to implement them, but whether or not to invest the resources to do so. Most of the bash development over the past 15 years has been done by one person.
Are you still working with the language now?
I am. In fact, the next major release of bash, bash-4.0, should be out sometime this (Northern) summer.
What is the latest project you have used it for?
I mostly use bash for interactive work these days. I use it to write some small system adminis- tration tools, but I don’t do much system administration any more.
What is the most exciting piece of code (that you know of ) ever written in Bash?
That’s hard to say. Lots of interesting projects have been implemented as shell scripts, or sets of shell scripts. I particularly like the various versions of the bash debugger that were implemented completely as shell scripts. That’s pretty complex work. I’ve seen entire Web servers and other surprisingly
