[Prev][Next][Index][Thread]
Synergy between Skill-driven design and Dylan?
> I am afraid I my preference for procedural thinking does
> not step from my OOD thinking at all - I was not born
> object-oriented and had I been, it would certainly be detrimental
> to functional thinking.
> Like most of us, I was raised on procedural languages, corporate
> databases and structured analysis and design. When I became
> acquainted to Smalltalk and C++ I liked the modularity and
> entity-driven approach. I missed then - and still do -
> the fashionable trend among methodologists to ignore system-wide
> functional decomposition, as if that was something unclean to do.
This sentence holds the core point of Skill Driven Design (SDD)
(see also http://www.skilldesign.com):
Deliver methodologists a method including tools
for system-wide functional decomposition,
In your first email you expressed that UML fails to approach the
problem of functional decomposition in an object-oriented way.
I think that UML is an answer to Object Oriented Programming (OOP)
in class-based languages like Smalltalk and C++ to provide
Object Oriented Design (OOD) methods and tools.
The class-based focus is repeated in the sentence
> "Meditate on classes and thou shall know their interfaces" etc.
This is different in Dylan:
"In Dylan, classes do not establish scopes at all. Since methods
in Dylan are not attached to the classes they name, they dont
have any privileged access to the slots (instance variables)
of the class.
Instead, modules are used to establish separate namespaces with
import/export control. Not only does this eliminate global name
collisions (names can be renamed as they are imported), but
separate modules can provide separate interfaces to the same
variables. This is simpler and more flexible than C++s
categorization of access into public, private, and protected
buckets."
(quote from http://www.dylanworld.com/advocacy/Competitive.html)
The above statement
> "Meditate on classes and thou shall know their interfaces" etc.
can be changed through Dylan to the following one:
"Meditate on functions and thou shall know possible arguments.
All objects are first class, including numbers, classes and
functions. This means that all these objects can be used as
arguments to functions."
There is an interdependence between Object Oriented Design (OOD)
and Object Oriented Programming (OOP). During the design phase
Dylan People can not use traditional CASE tools. In my opinion
your Skill Driven Design (SDD) and Dylan can generate a synergy.
To summarize
- UML/C++ both are class-based
- SDD/Dylan offers the possiblity that both,
the coding language and the design method,
are focused functional.
I prefer SDD/Dylan because
- SDD applies system wide a method for
functional decomposition
- Dylan is a language which provides an
implemenation with an functional focus
For functional decomposition thinking and Dylan as programming
language to provide a synergy effect advantage, because of
its ability to load functionality dynamically:
Using a quote from
http://www.dylanworld.com/advocacy/Competitive.html
>>>>>
C++ has the well-known fragile base class problem, where even
additive changes, such as adding a virtual function to an
interface class, requires all clients to be recompiled. The C++
compiler optimizes interfaces beyond what is useful, mapping
virtual functions to small integers so the clients can use simple
table indexing for polymorphism. Unfortunately, this optimization
means that adding a virtual function changes the indexes of all the
following virtual functions in that class and all subclasses. This
has caused much trouble in the industry, with SOM, for example,
being required to use a C interface to hide the virtual function
calls from the clients.
Dylan gives the programmer control over this problem. Dylan
supports cross-library inlining and optimization, but only for
classes and functions declared to be sealed. When flexibility is
more important than performance, the programmer can unseal a
class or function. This allows dynamically loaded libraries, or
the main program to add new subclasses or new polymorphic methods
to the interface item. The Dylan runtime dynamically optimizes the
polymorphic dispatch for unsealed functions, producing acceptable
performance, but the result is a degree of power unmatched by any
other language.
<<<<<< end-of-quote
===============================================================================
> I was not aware so far of the potential audience waiting for my
> method in Dylan - I will take that into consideration. I was
> thinking about adopting Python as an educational platform (to
> assess designs and to initiate managers to OO).
Dylan is good language where the following abstractions are helpful
Data Abstraction (use classes)
Functional Abstraction (use function with multiple dispatch)
Control Abstraction (use defined iterators)
Syntactic Abstraction (use macros)
===============================================================================
> Is Dylan as simple and easy to learn or is it a heavy
> multi-paradigm platform like C++?
> From the attached code I find it more cryptic than python but also
> more versatile. Python is single paradigm (procedural and OO). Dylan
> seems to suggest a hybrid approach. That traditionally suggests
> usability but also a shallow learning curve.
If someone can handle to distinguish the abstraction level
Data/Functional/Control/Syntax I do not believe that it is
difficult to learn Dylan. For me it was difficult to get
aware of these different levels and to thing in term of
collections.
What do you mean by "single / multi-paradigm platform"?
I can handle the distingushing between
Smalltalk as a single-polymorphism language
and Dylan as a multi-polymorphism language.
But what is "single / multi-paradigm platform"?
===============================================================================
> I was disappointed to see that Dylan's approach to iteration was wuite
> old-fashioned. However, I also saw something about iteration protocol
> that returns a set of functions... Is this mechanism anything like the
> STL?
On your page http://www.skilldesign.com/cpp/3/1/11.html
you have a Generic Algorithm Example. Let me describe a similar
situation
From a vector of widgets we are search a widget which belongs
to a specific class.
This is coded in Java as
while(iter.hasMoreElements() {
Object actual = iter.nextElement()
if (actual instanceof Button) {
resultVector.addElement(actual)
}
}
In Dylan you can write:
let result-vector = choose(my-vector, <button>, test: instance?);
This seems very similar to what you describe with the template for
find_if. What is old fashioned at this point?
===============================================================================
> Is Dylan compiled or interpreted?
Quote from http://www.double.co.nz/dylan/tips/editandcontinue.htm
With Functional Developer 2.0 it is possible to do what is commonly
called 'Edit and Continue' of a program that you are debugging.
This means you can pause a running program in the debugger, edit
method definitions, frames, or any part of the program, and
dynamically recompile those changes into the running program. You
can then continue the program from where it was paused and it will
use the new definitions.
This is useful for interactive development of programs. You don't have
a lengthy compile and link process - just a quick compilation of the
changed features - and you can continue without having to re-enter any
state to get back to where you were.
You can use this feature of Functional Developer when running a program
in the debugger by editing the source of the program, selecting the part
of the program you edited and choosing Project, Compile Selection from
the menu. A very fast compile will occur of just the portion changed and
the program will continue running.
Some things to be careful of:
1.Don't edit and recompile a method that you are currently
stepping through in the debugger. Functional Developer appears
to get confused in this instance.
2.Editing a DUIM frame or pane does not affect instances of that
frame or pane that are already created. So adding panes to a
frame won't cause them to magically appear unless you create a
new frame.
3.Make sure you are doing this with projects compiled as
'Interactive' (otherwise know as 'Loose') compilation mode.
I use this a lot when exploring GUI designs. Because of point 2 above you
need to do something special for the main frame of the application. I
create a project that starts up a frame with a single button in it.
Pressing the button creates the main frame of the application.
When I redefine aspects of the main frame, I close that frame down, and
press the button in the initial frame to re-create it. In this way I
don't have to keep stopping and recompiling/relinking when changing the
main frame.
Often when developing an application I find I spend most of my time
developing it inside of a running application and using this dynamic
compilation feature.
===============================================================================
> Is it proprietary or public domain? Does it have an independent standard?
> Does it have reasonable implementations on all platforms (Windows, Unix,
> Mac, VxWorks etc.)?
answered by a copy from http://www.double.co.nz/dylan/introduction.htm
Two main implementations of Dylan compilers or interpreters are known.
They are:
Functional Developer
A compiler and development environment for Win32 based operating
systems (ie. Windows 95, 98 and Windows NT). Applications are
delivered as executable files and/or dynamic link libraries. Full
access to the Win32 API is provided along with a portable user
interface framework called DUIM (Dylan User Interface Manager).
There are two editions available - the basic edition and the enhanced
edition. The basic edition is free for personal use while the enhanced
edition provides additional features in the development environment.
A number of additional libraries are available for separate purchase,
including COM, ODBC and CORBA support - including a POA compliant
CORBA
orb that can be distributed with your applications with no runtime
royalty fees.
Gwydion Dylan
An open source implementation of a Dylan compiler and interpreter.
The
compiler compiles Dylan code to C code, which can then be compiled
using
your favourite C compiler. The compiler and libraries are written in
Dylan
and it provides an excellent example of a large body of Dylan source
to
examine and learn from. A number of platforms are supported, primarily
Unix
based, but more platforms become available as people provide ports. A
port
of Gwydion Dylan for the BeOS operating system is also available.
===============================================================================
> Does its performance justify use for real-time and embedded applications?
The straight forward semantics of Dylan allows the compiler to determine
the appropriate flexibility at every function call, producing a thigter
code than C++. A production Dylan Compiler can produce code whose
performance is comparable to well-written C++, but without the manual
optimization performed by C++ programmers
If necessary Dylan allows a high level integration of C++
===============================================================
Following question I have forewarded to info-dylan@ai.mit.edu
Perhaps you may subscribe.
> Is its GUI library platform independent?
> Is it used commercially?
> Has any heavy-weight administration adopt it? (DOD,
> What kind of applications are typically written in Dylan?
> What kind of people are typically using it?
> How long has it been in existence? What is the current version? Is it
> stable?
> Is it used anywhere as educational language (first OO language?)
> Finally, what hard evidence can you bring to support your claim that it has
> a great future?
Follow-Ups: