These notes are also available in PDF.
Comments on:
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'?
Goto
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.
;
Check with Bobby