Synergy between Skill-driven design and Dylan? 
Author Message
 Synergy between Skill-driven design and Dylan?

Quote:
>         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.*-*-*.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

Quote:
>    "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.*-*-*.com/ )

     The above statement

Quote:
>    "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.*-*-*.com/

     >>>>>
     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

===============================================================================

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)

===============================================================================

Quote:
>    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"?

===============================================================================

Quote:
>    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.*-*-*.com/
     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?

===============================================================================

Quote:
>    Is Dylan compiled or interpreted?

     Quote from http://www.*-*-*.com/

      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 de{*filter*}, 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 de{*filter*} 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 de{*filter*}. 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
...

read more »



Sat, 16 Nov 2002 03:00:00 GMT  
 Synergy between Skill-driven design and Dylan?

---------------------- Weitergeleitet von Peter Robisch/LANGEN/DE/BULL on
30.05.2000 09:14 ---------------------------




Kopie:
Thema:    RE: Synergy between Skill-driven design and Dylan?


to "Synergy between Skill-driven design and Dylan?" forwarded to

Peter,

Your description of the Dylan concept sounds intriguing. When I am free of
my current pressure, I'll attempt to download the free version and
experiment with it.
"Single paradigm" languages attempt to reduce all the problems in the world
into a small set of symbols, thus forcing the designer to decompose the
domain to only a certain type of units (e.g., classes, functions, rules
etc.) allowing only a predefined type of connections among them. Smalltalk,
for example, has no built-in control structure and no free functions because
it supports only the object-oriented paradigm. In such language, you must
emulate the units/connections of another paradigm (e.g., in Smalltalk, while
and if-else are library functions). C++, Ada and Eiffel are multi-paradigm
platforms. C++ supports the procedural paradigm (functions),
data-abstraction (classes), OO (substitutability during run-time among
objects of different classes and Generic (same, during compile time).
In this respect, Dylan seems to be multi-paradigm. I am not sure it supports
data-abstraction in the common sense of the word. Its concept of binding
functions to objects seems to suggest a unique paradigm that I have yet to
comprehend.
Does Dylan handle multiple-polymorphism (also called "multi-methods" -
e.g., intersection function between two shapes of two unknown types) in a
natural way (i.e., without having to introduce a "double dispatch" mechanism
or the "visitor" pattern)?
The example I bring in my STL foils is from the C++ standard library. I was
relieved to see that Dylan can operate in a similar - and quite readable -
way! The Java example is awful - there you have the weaknesses of being
single paradigm!
     Avner.



Sun, 17 Nov 2002 03:00:00 GMT  
 Synergy between Skill-driven design and Dylan?

Quote:
>      "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)

  I'm curious about this.  I've looked at Dylan in a cursory fashion on a
couple of occasions, and I don't remember seeing this difference in thinking
when reading/playing with it.  For me it came across as "yet another OO
language", one with some nice features mind you, but it seemed the thought
patterns were largely similar or the same as Obj-C.

  Here you imply that this is not the case and that it is possible/correct
to think using another pattern.  Did I read you correctly?  If so, what is
the difference, and why does it manifest itself in the language?

Maury



Sun, 17 Nov 2002 03:00:00 GMT  
 Synergy between Skill-driven design and Dylan?

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).

I assume this quote is from the man you're corresponding with.  He
might be interested to know that Guido van Rossum, the creator of
Python, has said publically that Dylan is "...everything Python is
plus so much more..." (December 1999 issue of /Linux Journal/, pp.
113-114).

Gail Zacharias
gz -at- functionalobjects.com



Sun, 17 Nov 2002 03:00:00 GMT  
 Synergy between Skill-driven design and Dylan?

Quote:

>Does Dylan handle multiple-polymorphism (also called "multi-methods" -
>e.g., intersection function between two shapes of two unknown types) in a
>natural way (i.e., without having to introduce a "double dispatch"
mechanism
>or the "visitor" pattern)?

Yes, Dylan handles multi-method polymorphism, as well as
multiple inheritance.  Although Dylan is not exactly like CLOS
(Common Lisp Object System) you can find more published
about CLOS than about Dylan.  There's a fun book, The Art
of Meta-Object Programming, about the richness of CLOS;
Dylan is simpler than that, but it's good reading anyway.


Sun, 17 Nov 2002 03:00:00 GMT  
 Synergy between Skill-driven design and Dylan?

Quote:
> See:

> http://www.gwydiondylan.org/mtr-on-dylan.txt

  Interesting from a "personal perspective" sort of way, but it's missing
any discussion of the topics themselves.  Got anything with a little more
meat?

Maury



Tue, 19 Nov 2002 03:00:00 GMT  
 Synergy between Skill-driven design and Dylan?

Try:

  Sigh.  Try as I might I cannot get *&^&^% Outlook to reply in plain text,
and when I switch it by hand I lose all quoting.  Grrrr.

http://www.fun-o.com/resources/advantages.phtml
http://www.fun-o.com/resources/benefits.phtml
http://www.fun-o.com/resources/white-paper.phtml

  Thanks Rob, this is exactly the sort of thing I was looking for.

Maury



Wed, 20 Nov 2002 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. ANN: Skill-Driven Design language and compiler

2. Analog Design Engineer-BIPOLAR/BICMOS/CAD SKILLS A MUST

3. a technological society requires visual literacy skills as well as verbal skills

4. Need to Design a Pulse Generator for Driving an Array of LEDs

5. event driven verilog simulator design

6. Responsibility-driven design

7. Software Design using Dylan

8. Design Pattern in Dylan

9. Language Design (Re: Dylan type-safety )

10. Dylan Design Note Archive

11. Design Patterns (was Re: Dylan's Future?)

12. DYLAN DESIGN COMMENTS

 

 
Powered by phpBB® Forum Software