The Dolphin Development Roadmap

Forum,

We're in the process of the making the formal decision to switch to
Smalltalk--more specifically, Dolphin.  There are a few features absent
from D6 that I would like to see in a future version, and I was
wondering if the these features have made it into the development
roadmap.

1. Any plans to implement full (or even partial) hosting of .NET,
similar to VW's DotNet Connect?

2. Any plans to introduce the notion of a "data environment" as an
integral component of the IDE, much like Visual Studio does?  It would
be nice to have in the System Folder something like Data Enviornment,
where one could devolop schemas, do a bit of modeling, test
connections, etc.

3. What about 64-bit executables (through Lagoon)?

4. With the advent of Windows Vista we'll all be wrestling with XAML.
Any plans to support XAML in Dolphin?

5. As an Eiffel programmer, I rely on the Design-by-Contract approach
to programming, which is a formal semantics offering preconditions,
postconditions, and class invariants.  I'm curious to know if Dolphin
will eventually embrace an assertion mechanism.  I have enclosed a link
to an academic paper on the subject:
http://citeseer.ist.psu.edu/cache/papers/cs/24743/http:zSzzSzdis.um.eszSz~jmolinazSzLCC95009.pdf/design-by-contract-in.pdf

6. Any plans to incorporate into the System Folder something like
"Documentation Generator" for documenting applications?

Thank you.

Eric

<[hidden email]> wrote in message
news:[hidden email]...
> Forum,
>
> We're in the process of the making the formal decision to switch to
> Smalltalk--more specifically, Dolphin.  There are a few features absent
> from D6 that I would like to see in a future version, and I was
> wondering if the these features have made it into the development
> roadmap.

Like many (if not most) software companies, we tend not to make public
announcements of the detailed features of future releases until we at the
tail end of the development cycle. As I'm sure you can imagine, there are
many good reasons for this. Therefore we will only comment in very broad
terms.

>
> 1. Any plans to implement full (or even partial) hosting of .NET,
> similar to VW's DotNet Connect?

Clearly the ability to host .NET code and/or to execute on the .NET runtime
(CLR) would be important features of any future release of a Windows
development tool.

Bear in mind that both Dolphin and .NET provide good support for COM
interop, and so you can easily host .NET in Dolphin using COM today.

>
> 2. Any plans to introduce the notion of a "data environment" as an
> integral component of the IDE, much like Visual Studio does?  It would
> be nice to have in the System Folder something like Data Enviornment,
> where one could devolop schemas, do a bit of modeling, test
> connections, etc.
>

No. The IDE is easy to extend, however. All the source code is supplied with
the system, and it is feasible for any individual developer to understand it
and extend it.

> 3. What about 64-bit executables (through Lagoon)?
>

This would be a longer term goal.

> 4. With the advent of Windows Vista we'll all be wrestling with XAML.
> Any plans to support XAML in Dolphin?

Dolphin's MVP framework fundamentally separates pure "view" functionality
from application and domain logic. In a sense we have always regarded view
definitions as markup rather than code. It is still not clear to us,
however, how and when XAML would be supported in Dolphin.

>
> 5. As an Eiffel programmer, I rely on the Design-by-Contract approach
> to programming, which is a formal semantics offering preconditions,
> postconditions, and class invariants.  I'm curious to know if Dolphin
> will eventually embrace an assertion mechanism.  I have enclosed a link
> to an academic paper on the subject:
> http://citeseer.ist.psu.edu/cache/papers/cs/24743/http:zSzzSzdis.um.eszSz~jmolinazSzLCC95009.pdf/design-by-contract-in.pdf

Hmmm, some might say there is a gulf the size of the Grand Canyon between
the philosophies of Smalltalk and Eiffel :-). Generally speaking we believe
in minimal formality (because formality is a barrier to change) and
design-by-test. To be honest though, I personally am not interested in
getting into a debate about the relative merits on one approach over
another. You will certainly find many that are, but to me it is a religious
argument and therefore defies consensus.

We have no plans to add the kind of facilities described in the paper, but
Smalltalk is almost uniquely extensible so if you want to go down that route
you wouldn't necessarily need a dependency on us. Go for it.

>
> 6. Any plans to incorporate into the System Folder something like
> "Documentation Generator" for documenting applications?

No. We had this in the past, when we started out, but we don't find it has
value for us. Perhaps because our view of applications/programs has changed,
and we no longer think of them as entities outside of the environment. We
accept that others may want it, but we have to choose where to spend our
limited resources, and there are a number of community solutions in this
area.

Regards

Blair

Blair,

>Bear in mind that both Dolphin and .NET provide good support for COM
>interop, and so you can easily host .NET in Dolphin using COM today.

I do hope you had tongue in cheek when you wrote "easily host" :-), but
I believe your broad answer was sufficiently specific.

>Dolphin's MVP framework fundamentally separates pure "view" functionality
>from application and domain logic. In a sense we have always regarded view
>definitions as markup rather than code. It is still not clear to us,
>however, how and when XAML would be supported in Dolphin.

Yes, I saw that myself, which is why I asked about XAML: It would seem
to fit nicely into the MVP scheme.  Perhaps in the VC an XAML document
could simply be "attached" to the view.  If it's any consolation, I
don't think it's clear to anybody right now exactly how XAML will
integrate.  We're all still running to catch up to the power of XML.

>Hmmm, some might say there is a gulf the size of the Grand Canyon between
>the philosophies of Smalltalk and Eiffel :-).

Some might, but I wouldn't, and I don't even think Bertrand Meyer
himself would either.  Both strived for, and achieved, a pure O-O
language.  Mr. Meyer both borrowed from, and rejected, certain aspects
of Smalltalk during the design of his language.  But if there is a
gulf, it is only the natural one, much like the Grand Canyon (if I may
turn a phrase), that exists between ALGOL-like languages and LISP-like
languages.  As I've said in other posts, I see Eiffel and Smalltalk as
the only two languages that can have proper audience with each other.
I think the academic paper I referenced in my post could indicate that
I'm in good company.  I would agree with you that a debate would be
both fruitless and unncessary in any case.

Once I master Smalltalk and the Dolphin IDE, if I may be so bold as to
say that, then I will probably revisit that academic paper and try to
work the assertion mechanism into a separately maintained image.  A
number of my peers have criticized Smalltalk and its various
implementations as being unable to handle rigorously-defined,
large-scale applications needing high reliability.  I think their
criticisms are too harsh, as the language isn't that far away from the
mark.  An assertion mechansim and the ability to document by digest
would go a _long_ way towards addressing those concerns.  Multiple
inheritance doesn't appear to be as necessary in Smalltalk, as it is
quite adept at reference encapsulation, or "wrapping," more so than any
other language.  The only other issue on the table is information
hiding, but that doesn't appear to be as much of an issue either.

>No. We had this [document generation] in the past...

Ian B.'s goodies, which include a feature to print a class or a method,
among many other things, are great and do well to address the
documenation deficiency in Dolphin.  I do mean to say deficiency in
this case because output to a more permanent, human-readable format is
absolutely essential.  At a minimum, one should expect to be able to
right-click on a class, method, or package and obtain documentation.
But, yes, I see where the community could address this issue.  Ian
seemed to have no trouble incorporating the feature.

Cheers.

Eric

<[hidden email]> wrote in message
news:[hidden email]...
I have been using XAML for the past year on a couple of projects.  It is
just a way to specify a set of objects using markup.  The utility comes from
being able to use it as the glue between that set of objects from the
programmer perspective (function) and the presentation designer perspective
(look and feel).  I can create a pure application behavior model that
exposes actions, properties, and events on the code side, then the designer
can take that and compose the user interface from that functionality.  I
have had the same underlying application semantic exposed in several
radically different ways.  For example I have moved information from the
main window of an application to supporting dialogs and back.  I see no
reason that Smalltalk can not be the application semantic language while
XAML is the layout and UI specification language.  The WPF UI object model
is also VERY good.  It has yet to prove its performance on a wide range of
applications, but it has generally performed well, and is the best UI object
I have seen in 30 years of doing this.  I hope to have time to play with the
ideas of mixing Smalltalk with WPF in the not too distant future, but to do
that I need to bridge .Net and Dolphin.  So far it looks manageable.

I find it interesting that many seem to think that Smalltalk is somehow less
reliable than strong typed lanauges because you can get "message not
understood" when in fact it is the most stable environment I have
encountered including Java and .Net.  In all OO languages you can get the
equivalent of "message not understood".  In Java it is called
"ClassCastException" and in .Net it has a similar name.  In both Java and
.Net you can catch exception so they do not crash the application, as you
can in Smalltalk.  In Java and .Net however if you fail to catch all
exceptions (at many hundreds of entry points) your application will crash.
In smalltalk if you fail to catch all exceptions you get a dialog and the
application is still quite functional.  If you are running headless you can
even trap the last chance exception and log the results.  It is far harder
to crash a Smalltalk application than a Java or .Net application in my
experience.  Just another case of Smalltalk doing things a bit different,
bing seen as a missing feature.

I also liked the point made on one of the .Net related sites or blogs that
even though strong typing is seen as making an application more stable it is
really an illusion.  All it does is catch one class of errors, and arguably
the easiest to find in development.  The only way to know if an application
works is to test it.  If you test it properly type related issues will
always be caught.  If you do not test it you do not know if it works even if
all the types line up.

While I would not say that the traditional documentation form is required.
Having a place to put overview information such as category, class, and
protocol and method comments is critical.  Then having a clean way to view
that information is also critical.  In the Squeak browser the class comment
is visible at the same time as the class definition, just as method comments
are visible for the method.  This goes a long way to making the information
current and visible.  It would also be good to have a way to view more than
one piece of this information at a time.  This is where the printed
documentation looks attactive.  But, I have also seen comments that
suggested that there may be more interactive ways of making this happen that
sounded more useful than a linear dump of the information.  One step in this
direction is things like Eclipse method comments as the tool tip when
hovering over a method invocation, or class comments when hovering over a
class reference.  If some of those types of features were added to the
Smalltalk environment I would see less reason for printed documentation.
Then there is the Knuth approach where the code should be embedded in the
nartive about the system instead of the reverse.  When trying to learn a
system that would be ideal, but probably not idea for maintenance.  With
Smalltalk we could do both at the same time!

>
> Cheers.
>
> Eric
>

Michael,

>I find it interesting that many seem to think that Smalltalk is somehow less
>reliable than strong typed lanauges because you can get "message not
>understood" when in fact it is the most stable environment I have
>encountered including Java and .Net.

I do hope my name wasn't associated with the "many" who seem to think
:-).  I think one has to distinguish between two different debates:
strongly typed vs. dynamically typed and strongly typed vs. weakly
typed.  As a strong-typer, I find it far more difficult to make the
case against dynamically-typed languages.  In fact, I really don't
think there is a case (yes, an Eiffel programmer said that).  But
weakly-typed languages should have no admittance into the realm of
software engineering.

But the typing issue is quite apart from the assertion mechanism.  I
fail to see the advantage of the a posteriori approach of Design by
Test over the a priori approach of Design by Contract.  I would prefer
to prevent problems _before_ they occur rather than hope for the best,
after the fact, that I caught them all.  With contractual language in
place, one can _prove_ that classes are designed correctly using the
semantics of logic.  Now, whether the class offers all necessary
features, or calls upon those features in a meaningful way, are
different issues.  We cannot prove that a WORD_PROCESSOR class is a
word processor, but we can prove that, if a feature is invoked to
highlight with a certain color characters m through n, in paragraph p,
on page pg, that the color exists, the characters exist, the paragraph
exists, the page exists (preconditions), and that, yes, the text did in
fact highlight (postcondition).  We can also prove that at no time are
m, n, p, and pg ever negative (class invariant), and impose additional
preconditions that m < n, p < p_count, and pg < pg_count.  If one
wishes to call these assertions a word processor, well then I guess it
is.

>In smalltalk if you fail to catch all exceptions you get a dialog...

The question, really, is "Who gets the dialog?"  Or, more to the point,
"Who would you like to get the dialog?"  You, or your users?

It isn't possible to catch everything with Design by Test.  That has
been borne out in the industry many times over.  But it _is_ possible
to catch everything with Design by Contract.  We do it all the time
with Eiffel.  Design by Test is driven by interaction; Design by
Contract is testing driven by specification.  I suspect, as Blair does,
we'll never have consensus.

Cheers.

Eric

<[hidden email]> wrote in message
news:[hidden email]...
Not implying that.

> I think one has to distinguish between two different debates:
> strongly typed vs. dynamically typed and strongly typed vs. weakly
> typed.  As a strong-typer, I find it far more difficult to make the
> case against dynamically-typed languages.  In fact, I really don't
> think there is a case (yes, an Eiffel programmer said that).  But
> weakly-typed languages should have no admittance into the realm of
> software engineering.

Right.  Smalltalk is a strongly typed dynamic language.  While C is a weakly
typed static languge.

I would never advocate test after the fact.  That does not work.  You never
get enough resources to test after the fact, even with the most committed
team.  Test driven methodologies require that the tests be developed before
the system as an executable specification of the desired behavior (macro and
micro).  The only way to verify that an application meets the requirements
(does what is intended) however is to establish in some executable
specification what it should do.  While formal logic has value, I have yet
to see it used to fully specify the total desired behavior of even a small
system.  The Eifel pre/post/invarient model is useful in specifying many
characteristics of a system that should be true, but does not specify system
level behavior as far as I understand it.  You can not say that the satelite
should never crash into the planet in Eifel.  You can state it as an
invarient but I do not believe you could prove it was exhibited by the
entire system.  I doubt that the Eifel compiler can verify that too little
thrust in response to a change in altitude will allow the satelite to
deorbit and crash.  There are modeling languages that can capture/verify
this type of information, but of course only if a human enters them into the
model.

Like all methods developed so far it is useful, but it is not sufficient to
meet all verification requirements of a real system.  On the other hand
automated tests and pre/post conditions also have bugs.  So we double the
size of the development effort by stating the same things 2 times hoping
that if they agree it is doing the right thing.  All we prove is that the
two statements are consistent, never that they are correct.  This
fundamental gap between people and computers has yet to be bridged.  To date
the only way to know if a system is doing the right thing is for a human to
verify that it is what is desired.  What automated tests and formal
specifications do is take care of enough of the details to make that
possible.  Without such methods there are many problems being addressed
today that are beyond the scope of a person to verify.

>
>>In smalltalk if you fail to catch all exceptions you get a dialog...
>
> The question, really, is "Who gets the dialog?"  Or, more to the point,
> "Who would you like to get the dialog?"  You, or your users?

There are many product scenarios where you would not want the user to deal
with a failure, and then you can treat it like the headless case where you
log and/or report the error to service.  But, what I was getting at is the
fundamental difference in how such errors are handled.  In Smalltalk an
error might terminate the thread, but never the application.  If the thread
in error is the UI thread a new one is created after disposing of the old UI
thread.  In Java or .Net an exception that reaches the top of the control
path terminates the entire application.

>
> It isn't possible to catch everything with Design by Test.  That has
> been borne out in the industry many times over.  But it _is_ possible
> to catch everything with Design by Contract.  We do it all the time
> with Eiffel.  Design by Test is driven by interaction; Design by
> Contract is testing driven by specification.  I suspect, as Blair does,
> we'll never have consensus.

I am not convinced that design by contract will catch all miss-behavior, or
that doing so would entail any less effort than providing full coverage of
behavior using test cases.  The pre/post condition approach seems more akin
to unit tests to me, which while useful are far from complete behavior
specifications.

There are some languges such as used in RDD-100 for full system behavior
specification that are based on formal semantics and operate at a much
higher semantic level.  I would think that starting with such a model of
system behavior then proving that the implementation is conformant to the
model would be a more effective method for system level verification.  This
also provides a top down semantic that can drive implementation design and
catch non-conformant artifacts during all phases of development.  The Eifel
approach would certainly be useful in proving that the implementation was
conformant to the formal model of the system.

>
> Cheers.
>
> Eric
>