Difference: MDC (1 vs. 3)

Revision 32005-05-08 - AndrewEisenberg

Line: 1 to 1
	This page is a stub for the Macros with Display Control (MDC) project. As I get more ideas, I'll be placeing them here. -- AndrewEisenberg - 08 May 2005
Line: 21 to 21
	Remember, visual DSLs are only appropriate in some situations. Pure MDA ignores the fact that textual representations are the most concise and easiest way to understand most parts of a program.
Added:
> >	The resultant "display" of the macro need not be graphical at all. Some domains "want" to be displayed as text, but text with a different syntax and semantics as the base language. Each of the "macros" in this world will define some piece or all of a particular domain.

Revision 22005-05-08 - AndrewEisenberg

Line: 1 to 1
	This page is a stub for the Macros with Display Control (MDC) project. As I get more ideas, I'll be placeing them here. -- AndrewEisenberg - 08 May 2005
Added:
> >	A little food for thought from our friend, Dave Thomas: http://www.jot.fm/issues/issue_2003_01/column1 VISUAL LANGUAGES - USEFUL BUT NOT GENERIC Visual Languages are inherently domain specific. They allow domain knowledgeable developers to quickly assemble programs from existing components and well-defined operations. Visual languages offer great leverage when there is a close match between the visual abstraction and the system being modeled. Lab View is an outstanding example in the process control domain. ER models provide data modelers a powerful visual notation for conceptual modeling of the schema. Unfortunately, when one attempts to move beyond the domain level abstraction, one quickly creates large complex visual spaghetti that is impossible to comprehend or debug. This accidental complexity is particularly apparent when one mixes metaphors such as visual data flow and events. However, there are many useful application abstractions that are better modeled as functions, logic rules, differential equations, or set operations. In these areas, the textual functional, logic and procedural languages have proven to be the most expressive solutions. Furthermore most humans have much higher skill levels in using textual languages and the associated tool support such as IDEs, Text Editors, and Outliners. Even in the area of hardware design, developers have moved from using schematics first to using VHDL/HDL first. When does it make sense to use a visual language? How can visual languages be combined with textual languages? Can we make a tool/programming environment that seemlessly integrates the two? Also, the mini-languages (macros?) embedded in the GPL need to be consistent, easy to understand, easy to edit, and fast to manipulate. Remember, visual DSLs are only appropriate in some situations. Pure MDA ignores the fact that textual representations are the most concise and easiest way to understand most parts of a program.

Line: 1 to 1

This page is a stub for the Macros with Display Control (MDC) project. As I get more ideas, I'll be placeing them here.

-- AndrewEisenberg - 08 May 2005

Added:

>
>

A little food for thought from our friend, Dave Thomas:

http://www.jot.fm/issues/issue_2003_01/column1

VISUAL LANGUAGES - USEFUL BUT NOT GENERIC

Visual Languages are inherently domain specific. They allow domain knowledgeable developers to quickly assemble programs from existing components and well-defined operations. Visual languages offer great leverage when there is a close match between the visual abstraction and the system being modeled. Lab View is an outstanding example in the process control domain. ER models provide data modelers a powerful visual notation for conceptual modeling of the schema. Unfortunately, when one attempts to move beyond the domain level abstraction, one quickly creates large complex visual spaghetti that is impossible to comprehend or debug. This accidental complexity is particularly apparent when one mixes metaphors such as visual data flow and events.

However, there are many useful application abstractions that are better modeled as functions, logic rules, differential equations, or set operations. In these areas, the textual functional, logic and procedural languages have proven to be the most expressive solutions. Furthermore most humans have much higher skill levels in using textual languages and the associated tool support such as IDEs, Text Editors, and Outliners. Even in the area of hardware design, developers have moved from using schematics first to using VHDL/HDL first.

When does it make sense to use a visual language? How can visual languages be combined with textual languages? Can we make a tool/programming environment that seemlessly integrates the two?

Also, the mini-languages (macros?) embedded in the GPL need to be consistent, easy to understand, easy to edit, and fast to manipulate.

Remember, visual DSLs are only appropriate in some situations. Pure MDA ignores the fact that textual representations are the most concise and easiest way to understand most parts of a program.

Revision 12005-05-08 - AndrewEisenberg

Line: 1 to 1
Added:
> >	This page is a stub for the Macros with Display Control (MDC) project. As I get more ideas, I'll be placeing them here. -- AndrewEisenberg - 08 May 2005

View topic | History: r3 < r2 < r1 | More topic actions...