These notes are also available in PDF.
Ryder, Barbara, Soffa, Mary Lou, & Burnett, Margaret (2005). ACM Transactions on Software Engineering and Methodology 14 (4), October 2005, p. 431-477.
Multitasking and Concurrency
There were a few questions on this topic, so I've grouped them together. I will note that I don't study concurrent programming much (it's primarily an OS issue), so do not take my answers as authoritative. Note, also that Wikipedia has some good notes on these issue.
Can you give an example of Concurrent programming? Would parallel programming be a subfield of it?
Concurrent and parallel programming are closely related. I expect that it matters a bit who is doing the defining, but I tend to think of concurrent programming as more of a MIMD-style parallelism (that is, each process may be executing different instructions), while parallel computing also admits SIMD-style parallelism.
I knew semaphores were effective in controlling synchronization but I hadn't really heard of many other languages using concurrency. What is message passing concurrency and monitor concurrency? The diagram eventually brings them together into object oriented programming languages. Does that mean the both styles of concurrency are used simultaneously or they are used separately?
It's generally not a good idea to use more than one style of concurrency simultaneously. Message passing is a relatively low-level technique, in which coordinating processes send messages to each other to control resource usage. Semaphores are one technique for controlling usage. Monitors are a bit more abstract.
When discussing about "Control Abstraction" (p.438) the authors mention that top-down design and structured programming make software simpler and easy to understand or to modify. Can you give examples of the two mechanisms to show how the above claim/conclusion is achieved?
Structured programming bears close resemblance to goto-less programming. It relies on control structures, such as loops, if-then-else statements, case statements, and the like. Structured programming also relies on subroutines (procedures). It has the obvious advantage over goto-centric programming: You can trace control flow; when you make a change in one place, it is obvious what code is being effected; you can often deal with parts separately.
Top-down design is a design principle or strategy that supports structured programming. It involves repeatedly breaking the problem up into smaller, independent parts. If the parts are independent, then you can understand them separately and modify them separately.
The article shed a lot of light on how software engineering design has given rise to the addition of new features in programming languages. This made me wonder about the extent to which new software engineering designs have influenced the refining of programming languages to get rid of features which have been made obsolete because of the discovery of better software engineering techniques (e.g goto statements).
I'm not sure whether or not that's a question or not. Certainly, the refinement of many languages is to incorporate those kinds of ideas. However, other refinements also come directly from the languages community (most typically, type-related issues, but certainly a lot more).
It is obvious how most of the tools which programming languages provide are helpful to professional developers. Which do you feel, as an educator, is most helpful in an enducational setting?
I'll need to get back to you on that one.
The paper mentions an award-winning article by Perry titled "The Inscape Environment" which emphasized that the specification and design of exception handling is integral to good system development. Why then is it that when an exception occurs in most Windows programs the program terminates (as though exceptions are not handled at all)? Is this a case of plain laziness on the programmer's part or is there a more profound problem?
There's evidence that most programmers leave exception handling
(or the equivalent, such as checking return values for certain functions
in C, such as
open) until the end of the program development
cycle, and then run out of time. This programmer tendency is one of the
reasons that Java requires you to handle exceptions. It can also be
quite difficult to handle exceptions. For example, if you are trying to
write a file, and you get an exception that the file system is full, what
should you do? So, some of it is programmer issues, but it's also a
problem with the increasing complexity of systems and the wide variety
of exceptions that can happen.
In the section describing data abstraction the author talks about the need to organize programs into modules "led to the development of language support for abstract data types." While objects, interfaces and access rights do make it easier to abstract away elements of working with data, couldn't abstract data types be done with function calls and structs? Is the advantage of things like access rights that they enforce by rule what would otherwise be convention? Or is there more to their use?
It depends on how abstract you are. If you want a fully abstract queue, you need a way to separate interface from implementation (hmm ... there's that interface) and you also need it to be polymorphic. It's hard to support polymorphism with objects or something similar.
I thought the article was interesting in explaining the symbiotic relationship between software engineering and programming languages beginning with language features. First, the design of structured porgramming language constructs was influenced by the research of the early combined research community. Second, the programming language design community was providing the tools for software reuse. Third, the issue of inheritance was addressed by both the programming language design and software engineering. Fourth, the issue of reliablity of code. The emergence of object-oriented programming in the 1980s and 1990s happened around the same time when the software engineering community was concerned about how to design and build large, modular systems from pieces with clearly defined interfaces using teams of programmers. Next, the software engineering and programming language community heavily influenced the concepts and the notation used to express concurrency in programming languages.
It was also interesting to note that the main influence of visual programming was more on new language properties than on new language constructs.
You seem to have summarized more than you're reflected.
On page 437 the article states, "During the 1960s, indiscriminate transfer of control was believed to cause difficulties and errors in writing and understanding programs". What exactly is 'indiscriminate transfer of control'?
The author talks about aspect-oriented programming and explains it a little in terms of its handling of exceptions, but I'm still confused as to exactly what aspect-oriented programming is. Can you give a better definition of the concept of aspect-oriented programming?
It's a different way of modularizing a program than we're used to.
In general, it involves putting common code in a single place, rather
than spreading it throughout the program.
For example, you might want to insert debugging code. Rather than
putting a bit of debugging code in each method, you write a separate
module that says (approximately)
when these procedures
are called, print this before executing the procedures). You
can then make changes (such as turning off debugging for one set of
procedures) in one place, rather than scattered throughout the
program. Note that aspect-oriented programming might be an interesting
topic for a presentation.
This is sort of unrelated, but what are the various ways companies and people that create languages make money off of their work? Although it sounds like a lot of languages may not be created for the purpose of money, is there a standard way in which creators benefit from their work?
No, there is no standard way in which people benefit. Most langauge designers seem to do it altruisticly, or simply develop a language for their own benefit and then share it with others. Some designers make money from selling a compiler or consulting services. When big companies release languages, it's primarily for the auxiliary benefits they derive.
C, Forth, and Perl were all clearly designed by a single programmer (or perhaps two, in the case of C) who wanted a language for a specific purpose, and then thought it appropriate to share more broadly. Fortran and COBOL were designed by committee to meet perceived needs. (And, as I've mentioned, Fortran was also designed to sell computers.) I expect that most Microsoft-developed languages exist, in part, to help ensure that more software is written for Microsoft platforms.
I had a hard time understanding what the important messages were from this article. It was helpful in that it seems to outline some of the important features of a language (e.g. Portability, strong typing, abstraction, exception handling, etc.) but it seems to go much too far into detail to try to prove that these developments in computer languages are closely tied to software engineering. The part I had most trouble understanding was the portion on Types. I didn't really understand what makes a language type safe and whether type safety refered to primitives or to new types created by the users, or both. Does type safety help in ways other than to make programs more reliable? What is the purpose of casting if not to bypass type-safety? If we could also elaborate on how records, structs, and classes contribute/harm type-safety, I think it would be very helpful.
I have types on the syllabus for much later in the semester, so I think we'll leave most of the discussion until then.
The project is quite sucessful to attribute different contributions on one side to the other. The project considers many features on both sides; on programming language side, there are Data abstraction, Modules, Exception, etc. On the other side, there timeline of development, chart interaction, visualization, etc. I thought the result of the project is predictable, as there are mutual impact.
The grammar of this is a bit iffy, and it seems more like a summary than a reflection on any key point.
I usually create these pages
on the fly, which means that I rarely
proofread them and they may contain bad grammar and incorrect details.
It also means that I tend to update them regularly (see the history for
more details). Feel free to contact me with any suggestions for changes.
This document was generated by
Siteweaver on Sun Apr 29 11:27:50 2007.
The source to the document was last modified on Sun Feb 4 21:02:16 2007.
This document may be found at