[clean-list] Clean and scientific programming

Fabien Todescato f.todescato@larisys.fr
Thu, 30 Aug 2001 14:48:38 +0200


Siegfried Gonzi writes :

> Please: what do you use Clean for (I mean real world problems).

Dear Siegfried,

I am a software engineer with a practical background in traditional software
development techniques and tools - ADA/Pascal/C/C++/UML...- and a light
academic background in functional and logic programming. Although scientific
programming is not not much of a concern to me, I nevertheless send you a
resume of my use of Clean for real world applications.

I am working in the field of automated test of electronic equipements, and
these last few years my activities were :
- designing and implementing class frameworks for the developement of test
programs
- designing algorithms and building programs to automatically generate tests
programs
- building programs to help electronic engineers analyse or debug test
programs generated by 3rd party tools
- building programs to help electronic enginners analyse electronic board

Until a recent period, C++/STL/UML were my main develomement tools. I have
indeed developed a few automatic test generator programs using C++, designed
with UML/Booch using the Rational Rose CASE tool. These programs do not rely
much on numerical computations but rather use tree-like symbolic data
structure, and a few graph algorithms, to perform electronic board circuitry
analysis. Developing such programs with C++ was a tedious task : no
automatic memory management, no pattern matching on symbolic data
structures, rigid parsers constructed with LEX and Yacc. Especially memory
management was always to be handled with ad-hoc techniques and accounted for
a non-negligible percentage of the development effort.

I undertook as part of a bigger project - now almost defunct - the
development of a rule-based computation engine for automated electronic
circuits analysis, in Prolog. At some point the Prolog code began to be
difficult to extend, and I decided to switch to Functional Programming. An
internet search brought me to Haskell, and then to Clean. Working on
Windows2000 and NT4.0, I was naturally drawn to Clean, all the more so as
the setup and use of the Compiler and IDE was especially easy, and efficient
standalone executables in native code were generated. Using Clean, I was
able to build and demonstrated an efficient working prototype, a task that
undoubtedly I wouldn't have been able to carry out using C++.

I have also used Clean to build two moderately-sized applications now
beta-tested before their use in production, now coming very soon. One is an
automatic debugging tool that analyzes and transforms test programs
generated by a - not too perfect - 3rd party automatic test program
generator that we have to use, because it is tied to the proprietary tester
hardware. The other is a GUI-based application that helps test engineer
interactively analyse huge automatically-generated test programs.

I definitely consider these applications to be real world. They process real
world data and solve practical problems of economic importance - at least to
my company -. Also, these programs rely on the use of some non-trivial FP
techniques.

There is no doubts the use of Functional Programming brought a lot of
benefits in the construction of these applications, some of which I can list
below.
- The automatic memory management, and the pattern-matching on tree-like
data structures allows for a clean formulation of symbolic computations
- The terse syntax and compositionality of FP allows for the very concise
expression of sophisticated algorithms
- The construction and evolutions of the various parsers needed is almost a
child's play using monadic parser combinators.
- Lazyness allows for elegant modularization of some algorithms.

Also, the use of Functional Programming brought its share of problems.
- Lack of skilled developpers
- Lack of methods and notations supporting programming-in-the-large software
engineering practices
- Lack of libraries and software components considered now standard in other
programming systems
- Problems of memory performances arising from an incorrect use of lazyness,
or space leaks

For the 2nd project especially I sweated to build my GUI and have a not-too
hairy software architecture, a task that I would have found easier using
traditional Object-Oriented techniques. The other parts of the program,
however, suited nicely the FP paradigm.

As a rapid conclusion, I would highly recommend the use of Clean - at least
on WinTel platforms - for the development of any kind of compiler-like tool
performing sophisticated analysis and transformations of highly structured
symbolic data. There is no doubt in my mind as to the superiority of Clean -
and FPL in general - over languages like C++/JAVA/C#, a superiority however
that might be counterbalanced by the lack of libraries. ML-like languages or
Haskell are certainly good choices too.

When it comes to develop moderately to highly complex stateful interactive
applications, with a GUI, I would not highly recommend using Clean, even
considering the clever design and ease of use of the ObjectIO library.
Languages directly supporting the Object-Oriented paradigm might be better
suited to the task, especially if they come equipped with a modern GUI
library.

Best regards, Fabien TODESCATO

PS.If you allow me, I would say that one of my wet dream is that the Clean
language be equipped with a direct support for the object-oriented paradigm,
as for example in OCAML, or Oz.