John V. Guttag, James J. Horning: A Larch Shared Language Handbook. Sci. Comput. Program. 6(2): 135-157 (1986)

John V. Guttag, James J. Horning, Jeannette M. Wing: Some Notes on Putting Formal Specifications to Productive Use. Sci. Comput. Program. 2(1): 53-68 (1982)

I don’t understand why you say “never design a language!”. A team can talk about domain specific matters by using a DSL. That may help to form an “Ubiquitous Language”. The team can later decide whether to actually implement the DSL or not. I dont say “always start with a DSL discussion”, but this is just a tool on discussions of the domain.

It seems you mean this: Don’t get lost in the details of implementing a DSL before actually specifying the essential business rules of the domain. I agree on this. But the sentence “Never design a language!” is not leading me to this conclusion. I prefer this: “Never get lost in the details of DSL construction before understanding the business rules in detail”.

You seem to advocate designing the API in detail before anything else. Someone from Bell Labs said: “Desiging an API is designing a language”. So, in that sense, you are also designing a language while you are desinging an API.

Bahadır Konu
http://kurumsalyazilim.blogspot.com/

I know this. I was taught this by reading Wirth in the mid-1980s, and with practice it became second nature to me to write structured code. But almost the only other programmers I have ever worked with who seemed to understand this were Eiffel programmers. Every one else believes that return, break and continue are okay, because although everybody knows that Dykstra considered ‘goto’ harmful they don’t believe he was talking about these other jump instructions. Even Martin Fowler’s otherwise excellent “Refactoring” book contains ten infuriating pages in which he sets up straw man examples of badly-written structured code which he then proceeds to “improve” by returning from the middle of routines. (The final versions are indeed clearer, but it’s because he got rid of the code’s other defects on the way to injecting a bit of spaghetti.) Needless to say, it is tedious to spend one’s entire career reading code written by colleagues, many of whom are great programmers, but who don’t understand that they shouldn’t jump out of the middle of a routine or a loop. I’ve just started working on a new project where all of the code (in Java) was written by a really smart programmer, but … (groan) … I’ve already run into dozens of cases where he returns from the middle of routines. I’ve given up arguing the issue with people, because I’ve never managed to find an article on-line to support my conviction; and OOSC2 disappointingly glosses over the issue, apparently assuming that the issue was settled, once and for all, decades ago.

Is there a good explanation supporting our conviction that break and continue and return are just covert forms of goto?

Certainly there’s little need for nested routines in an object-oriented language. In Delphi, I only ever used them in order to avoid polluting the class’s interface with features that would be needed only by a single routine. Whenever I found myself writing such nested routines, however, it was a pretty clear indication that I ought to extract the implementation of that routine to a new class.

It’s interesting that, in the 21st century, it is now possible in fact to write nested routines in Eiffel. We have in-line agents! Some people believe that adding in-line agents to Eiffel was a mistake because their services are unavailable to the rest of the world. Personally, I like in-line agents; I just wish that there was a more concise syntax for using them. For example, as the article notes, C#’s “Code Contracts” are a clunky emulation of Design by Contract (i.e., clunky compared to Eiffel, although compared to any other DbC emulator that I’ve ever used they are excellent). I find that “Code Contracts” are better than Eiffel’s DbC in one respect, namely that I routinely find myself writing contracts that iterate over collections with ease. With Eiffel I rarely do so. This is because the syntax of C#’s lambda expressions is so convenient. Sure it looked like it came from Mars when I first saw it, but once I got the hang of it I suddenly felt free to write more complete contracts. The syntax of Eiffel’s in-line agents is too verbose. If Eiffel had an operator to simplify in-line agents, then I think a lot more interesting contracts would get written.

Richard Mitchell, James McKim: Extending a method of devising software contracts. In: C. Mingins, B. Meyer (ed): Proc. TOOLS 32, IEEE (1999), give the guideline
“G2 Separate basic queries from derived queries (derived queries can be specified in terms of basic queries)” I find this guideline very useful.

Let me explain my problem on a simple example that I used in my introductory CS course since 1999. Suppose the Implicit Framing Rule (IFR) holds in the following.

class RECTANGLE

feature
width, height, area : REAL

invariant
width > 0
height > 0
area = width * height

end — class RECTANGLE

width and height are basic, area is derived (or “depending on” width and height). We could substitute the invariant

area = width * height

by the postcondition:

area : REAL
ensure
Result = old width * height

The semantics should be the same. In both variants, area is pure. The difference is with assertion checking on: The invariant is checked before and after each routine call,
the postcondition is only checked when area is called.

First, I add a setter for width:

set_width (new_width : REAL)
require
new_width > 0
ensure
width = new_width

The IFR says that only width changes and nothing else. This violates the invariant or the postcondition of area, because one of height and area must change too. I want set_width to keep height and change area. The IFR forces me to add a condition with area, maybe such:

ensure
width = new_width
area = width * old height

It seems that I have to repeat the invariant or postcondition of area in a modified form.

Second, I add a setter for area:

set_area (new_area : REAL)
require
new_area > 0
ensure
area = new_area

The IFR says that only area changes and nothing else. But if new_area /= area, this violates the invariant or the postcondition of area, because one of width and height or both must change too. I have at least three options. Each may be useful:

set_area_keep_width (new_area : REAL)
require
new_area > 0
ensure
area = new_area
area = (old width) * height

set_area_keep_height — similar

set_area_keep_relation (new_area : REAL)
require
new_area > 0
ensure
area = new_area
width * (old height) = (old width) * height

Conclusion: Given a setter for a derived query, the IFR is okay: It forces the programmer to specify which of the basic queries should change.

Given a setter for a basic query, the IFR seems not to be the last word. We can see that if we add more derived queries like perimeter, diagonal and so on, which depend on width and height. A generalization:

class EXAMPLE

feature
basic_1 : TYPE_B1
…
basic_m : TYPE_Bm

derived_1 : TYPE_D1
…
derived_n : TYPE_Dn

set_basic_i (new_basic_i : TYPE_Bi)
ensure
basic_i = new_basic_i
derived_1 = function_1 (old basic_1,…, basic_i,…, old basic_m)
…
derived_n = function_n (old basic_1,…, basic_i,…, old basic_m)
– All basics with old except basic_i!

invariant
derived_1 = function_1 (basic_1,…, basic_m)
…
derived_n = function_n (basic_1,…, basic_m)

end — class EXAMPLE

The explosion of nochange-postconditions is back again. To me, the invariants do not look like theorems that follow logically from axioms. So I wonder whether the theorem-approach may help. With the discarded “only” construct the setter looks like this:

set_basic_i (new_basic_i : TYPE_Bi)
ensure
basic_i = new_basic_i
only derived_1,…, derived_n

With “only”, there is no need to repeat the whole invariant formulas. So I do not see the advantage of the IFR in this case. I would prefer “only”, although it is not ideal to repeat the names of the derived queries.

Am I missing some points?

What about “distinction of basic and derived queries + IFR-variant” with IFR-variant:

“A routine may change the value of a basic query only if the basic query is specified in the routine’s postcondition,
and it may change the values of derived queries.”

This leads to:

class EXAMPLE

basic query
basic_1 : TYPE_B1
…
basic_m : TYPE_Bm

derived query
derived_1 : TYPE_D1
…
derived_n : TYPE_Dn

command
set_basic_i (new_basic_i : REAL)
ensure
basic_i = new_basic_i

invariant
derived_1 = function_1 (basic_1,…, basic_m)
…
derived_n = function_n (basic_1,…, basic_m)

end — class EXAMPLE

Can “derivedness” of a query be inferred from invariants and postconditions? Then there would be no need to distinguish derived queries at their declaration.
“A query is basic, if it is not fully specified in terms of other queries. A query is derived, if it is fully specified in terms of basic queries.”
Can a tool infer from

diagonal * diagonal = width * width + height * height

that diagonal is derived from width and height?

PS.
Great web blog. I got the hint from http://www.dijkstrascry.com. Such website are important as they give insight and that’s what students need more than ever these days.

A better way to support this kind of business logic is a general purpose ‘soft’ computing layer, such as the one we are now using in health based on ‘archetypes’. See for example this online model repository – http://www.openehr.org/knowledge/ . To make this work, a new language was required, but a very general one based on constraint logic – see http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633

- thomas

Thanks for the reference.

While what is not broken does not require fixing, what is broken does. My father used to say, “If it hurts, don’t do it.” At 48, I feel a little liberty to now add a little to his statement:

“If it hurts, don’t do it. If you don’t know why, find out.”

Have the courage to BE CURIOUS!

(Thanks Dad!)