. . .
It is true that we do not see CASE-tools being used very much, but we do see tools go beyond ASCII and still be very popular. What I am thinking of is the visuals environment, like those produced by MS.
You might be interested in looking at work done at Oxford and Chalmers U. on graphical notations for describing hardware architecture, in particular networks of functional units. The interesting thing was that the notation mapped essentially 1-1 onto expressions in an application-specific language built on top of Haskell. One variant, called Lava, was adopted for use by Xylinx (?sp), an FPGA house. At least part of the reason it worked was that the functional units were combinational, which is nicely compatible with a (stateless) pure functional language. In a similar vein, you might look at a heterogeneous simulation system called "Ptolemy"/"Ptolemy II" developed by Prof. Edward Lee at Berkeley. The system supports, among others, simulation models based on Finite-State Automata, Kahn Process Networks and Token Flow Networks (a generalization of dataflow). The user interface is graphical, using drag&drop to populate the functions and dragging to interconnect. I was experimenting with it as a tool for prototyping computations to be performed on massively-parallel networks of functional units, similar to FPGAs. One really interesting fact to come out of the experiments was that the EEs understood immediately what was going on (it looked sort of like circuit and logic diagrams). The difficulty was with the software people, who insisted on viewing the functional units as little stateful processes, so they started suggesting mechanisms for synchronization and communication -- all that complexity. I found myself siding with the EES -- the dataflow model was simple, and design for performance could be based on indicators such as length (latency) versus width (parallelism) of the network. -- Bill Wood bill.wood@acm.org