I have done some experiments relating to our discussion. The approach to
generate Haskell code from UML class diagrams is not very promising. However
one may define a visual notation of Haskell (this is no new idea of course),
provide better tool support (in particular editor+code generator) and pull
the Haskellers away from vim, emacs or even from the Visual Studio Plugin
"Visual Haskell", that is more a Haskell IDE Integration than a visual
programming environment (great work either way!).

I have described a possible toolchain towards a real Visual Haskell at my
blog:

http://www.steffen-mazanek.de/blog/2007/05/visual-language-howto.html

Best regards,
Steffen

2007/4/14, Brian Smith <[EMAIL PROTECTED]>:

On 4/14/07, Steffen Mazanek <[EMAIL PROTECTED]> wrote:
>
> Brian, but don't you think that you have to write a lot
> of boilerplate code in Haskell?


I have never felt I was writing a lot of boilerplate. There are a lot of
abstraction mechanisms in Haskell to avoid boilerplate.

Second, if Haskell should be more successful in the
> real world there has to be a way of demonstrating
> basic ideas of a big program to "customers". How
> would you do this? Everybody knows UML class
> diagrams, for example. In contrast, nobody knows
> about termgraphs or lambda *g*.


I've never had to show a UML or ER diagram to any business people--usually
they want a slideshow that is far simpler and a little prettier. The fact
that "nobody knows about termgraphs or lambda"  in your group means that you
probably shouldn't be considering Haskell (for the same reason my bosses
always asked me to document everything--"in case you get hit by a bus").

Thank you very much for contributing to the discussion.
> Please assume, that you have to generate the code from
> a model. Further assume, that you have no choice and
> are not allowed to discuss the sense of this approach :-)
> How should the code look like?


I am not sure if you are trying to solve a real problem or not. If you are
solving a real problem, where you already happen to have an EMF model which
you are required to generate code from, then I recommend to just do
everything in Java using the existing tools built for EMF.

If you decide to still keep working in Haskell, and it works out well,
please share your solution because I think many people here will be very
interested. wxHaskell, OOHaskell, and O'Haskell are all starting points for
this type of project.

- Brian




--
Dipl.-Inform. Steffen Mazanek
Institut für Softwaretechnologie
Fakultät Informatik

Universität der Bundeswehr München
85577 Neubiberg

Tel: +49 (0)89 6004-2505
Fax: +49 (0)89 6004-4447

E-Mail: [EMAIL PROTECTED]
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to