The Joel on Software Discussion Group (CLOSED)

Karel, if you are reading this, give us an example of code using DbC paradigm. I have read both links you gave us in the  last topic and found them interesting.

thanks

wannabe - which topic contained the links you are refering to?

Here's link to info on an interesting new language/compiler that will work as "first class .NET citizen" and plug in to VS.NET IDE.  They claim that it is "the first attempt to bring Design-by-Contract-like concepts into a main-stream language."

http://www.chromesville.com/page.asp?id={DFA00D71-D5A4-40A3-9FD0-251899EB30D8}

> Design-by-Contract-like concepts into a main-stream language."

I guess eiffle is a bit down stream then?

http://www.hello.nl/articles/TheDebuggerisdeadlonglive.html
http://www.hello.nl/articles/Writingbettersoftwarewith.html

"I guess eiffle is a bit down stream then?"

Considering they mention Eiffel in the first sentence on the page I linked I think that, yes, they consider Eiffel to be a non-mainstream language.

Sure, everyone's heard of Eiffel.  But I've never heard of a single real-world project that was developed in Eiffel.  Have you?

I do know of one company that makes storage systems that does all their work in Eiffel; they claim that it's a real competitive advantage because the resulting software is much more reliable. Unfortunately I can't remember what the name of the company is.

I find it kind of amusing that they dismiss Eiffel by saying "first addition of DbC to a main-stream language." Claiming that Chrome is more main-stream than Eiffel is rather disengenuous considering there are probably more Eiffel users than Chrome users at this point in time.

Yes, in their case "attempt" refers to both the bringing of DBC concepts to language as well as their efforts to get enough people using Chrome to call it "mainstream".  ;)

DBC was a term first coined and explored (afaik) by Bertrand Meyer, designer of Eiffel. But I don't really think it's dissing Eiffel to call it non-mainstream.  Eiffel seems to be somewhat like Lisp: an elegant language that academics love but not much used in the real-world. 

Whether Chrome ever becomes "mainstream" is anybody's guess.  But in any case it won't be an academic language.  It's basically an attempt to combine best concepts of C# and Delphi, throw in a few new things like DBC, and give you a language to use for real work.

Wannabeboy,

The margin of this forum is too small to provide you with a complete theatment of DbC. Bertrand Meyer wrote Object-Oriented Software Construction II (perhaps now even III?) and needed 1252 pages. However, this book is not a bigger is better/ more impressive. OOSC II is a classic in software engineering. The Wikipedia and the Wiki Wiki also have useful information.

I will give you a small example of a routine using DbC, written in our own language Carmen (R):

function partMiddle(tt: Text, pos, len: Nat32) return Text
  -- Returns an extract from tt, starting at pos, >>
  -- having a length of len.
  -- Aka: midStr (deprecated).
  precondition
      1 <= pos <= tt.count+1
      0 <= len
      0 <= pos+len-1 <= tt.count
  do
      return tt[pos...pos+len-1] -- implementation
  postcondition
      contains(tt, result)
;

Discussion: contracts are inherited by subtypes; contracts are both executable code and documentation, in fact executable documentation!; contracts can be left out with a compiler switch for better performance (usually not needed, except in hotspots); making sure that preconditions are met is the job of the caller-programmer; making sure that postconditions are met is job of server-programmer; perfect blame management within a team of programmers; when a postcondition is violated there is no point in using a stack trace: the server-programmer has either made a mistake in his implementation code, or had too weak a precondition; code is made as brittle as possible, no attempt to repair mistakes or second guess the caller.

The latter point is important. Make the software as brittle as possible so that bugs are discovered early instead of covered up by usually buggy and badly test-covered exception handling code. Let the code explode in your face, it makes you careful (-8. I estimate that we have fewer than 0.2 exception handlers per KLOC. This style of DbC reduces the number of execution paths enormously.

Not shown in this simple example are intermediate inspections (checks). These are used to assert a condition. These inspections should be used instead of debuggers. If we have a bug in our code (signalled by a violated contract or inspection) we do not fire the debugger; we add more inspections in the code until we find the point where the mistake was made.

Notice that in this example we did no attempt to repair incorrect inputs, such as the caller demanding parts longer than the original input tt. Such repair mechanisms complicate the software tremendously, are never enough to cope with all stupidities people do (thus demanding for even more complexity both in the service and in its existing callers), make it very complicated for anyone to know what the service exactly does, make documentation a nightmare and do not signal the bugs in the caller.

The Carmen-programming language is a blend of Ada and Eiffel, designed for large scale high-integrity applications. Although its syntactic design has resemblance to Python, it actually predates Python by several years. Carmen has many new facilities that make it simple to write correct software. Small programs in Carmen are usually compacter than their Python counterparts, very large programs are much compacter than their Eiffel and Ada equivalents (without leaving out things that make Eiffel and Ada so interesting; I am not making a comparison like that of structured Ada with unstructured Perl) and without giving in on readability.

There is no complete compiler for Carmen yet, because a compiler for Carmen cannot be generated with standard compiler-compilers, so we are writing things ourselves. The language, the libraries, environment and the development method have been developed in pair. At this moment we have a bunch of tools that together allow us to think and write in Carmen.

Now that the birth of a first version of a Carmen-compiler is nearby, I plan to write more on Carmen and language design in my blog.

Eiffel is not mainstream thanks to Meyer's outrageous pricing for his development environment, and the lack of any big or marketing-savvy companies (think Borland of the Turbo Pascal days) offering an alternative implementation. That's the long and short of it, really. If people aren't aware of decent affordable compilers with good IDEs and comprehensive libraries, they just won't use the language. Cf. Lisp.

"These inspections should be used instead of debuggers. If we have a bug in our code (signalled by a violated contract or inspection) we do not fire the debugger; we add more inspections in the code until we find the point where the mistake was made."

This is a very valuable idea. Especially if inspections can be turned on/off at runtime. It allows developers to "store" and accumulate debugging experience in the code itself. In many respects, this is the same with "code a bit, test a bit" approach to development, but better because the code and the test case are grouped together.

This is very interesting, thanks.

"Eiffel is not mainstream thanks to Meyer's outrageous pricing for his development environment, and the lack of any big or marketing-savvy companies (think Borland of the Turbo Pascal days) offering an alternative implementation."

I thought same thing a few years ago when I checked Eiffel out.  There's no way I'd bind myself in to using a single language and IDE when there's not critical mass of other users offering third party add-ons, components, etc.  Especially when it's pretty expensive.

I wonder whether things have changed a bit now with .NET.  You can get the Eiffel plug-in to use with VS.NET for $1500.  Not cheap, but much cheaper than the $5k they want for their proprietary Eiffel IDE.  And much better than a proprietary IDE in my opinion because with Eiffel.NET you could then program using Eiffel as main language while making use of third-party C# components and VS.NET addons. 

The Eiffel site is at www.eiffel.com .  Here's link where you can view a presentation they have on DBC:
http://www.eiffel.com/developers/presentations/index.html

>  Have you?

I guess i think of mainstream as different than popular, but you are more right. I think of it as very influencial and still existing, but that's not mainstream.

Eiffel suffered the same problem as objective-c. You have almost no chance of making a language popular by keeping it to yourself. In both cases that is a shame.

>  "These inspections should be used instead of debuggers.

I am unsure how that works for multithreading problems because you really need to see a lot of call stacks. But in general i agree. TDD works the same here.

Eiffel has had a free compiler for a long time - back in 1996 we used it at our university.  The bigger problem is then the IDE, because working in Eiffel, like any other language becomes cumbersome without a decent IDE to support you.  Just like M$ you have to pay for the IDE.