[clean-list] RE: Clean and scientific programming

[Jerzy Karczmarczuk]

Brian Wilfley:

> Let me put in a word for a particular type of "scientific" programming
> which Clean ought to be able to handle...
> 
> 1) Small amounts of code to investigate particular algorithms...
> 
> 2) Easily and reliably  modified code.  This is important because the
>    algorithms are not settled or agreed upon.  One needs to try different
>    approaches ...
> 
> 3) The ability to plot results....  This point is
>    crucial.  There seem to be scores of languages that support 1) and 2)
>    above, but that fall flat on this point.  My theory is that a) good
>    plotting programs are hard to write, b) they are especially hard to
>    write in a form that is portable, c) those that exist make the job of
>    plotting as difficult as the job of designing the algorithm in the first
>    place: too many lines of code to make a graph.

> ...I have to confess that the system I
> use most is Matlab.  And a big reason is that 3) above is satisfied.
> The code one writes for matlab is usually short...

> To me the advantage of a system like Clean is that 1) and 2) are well
> served.  But if 3) is not, I'm stuck.
> 
> But not defeated...

My three euro-cents on that (JUST on that).

1. Small amount of exploring/testing code is something which is not so
   dependent on the programming language itself, but rather on the existing
   IMPLEMENTED generics: procedure libraries, universal data manipulators,
   converters, and reusable open chunks of code. This last point actually IS, 
   or may be a language feature. The Matlab vectorized style provides such 
   reusability. The possibility to use matrix slices, matrix reshaping, etc.
   makes the code sometimes really short. Iterators in OO languages (C++, Ruby
   etc.) are also such features. 
   In Clean we have for the moment generic folds, array comprehensions, etc.,
   so the potential is there, but all is soooo general, that not so immediate
   to exploit by potential scientifically-oriented user. Slicing library of
   Thorsten Zoerner needs some work.

2. Ease and reliability go not always together. I found the module system
   of Clean quite reliable, but the typical lazy way of proceeding: test
   a procedure in a () main module; then retrieve from the compiler the type;
   put into an implementation module AND in the def. module, and check again
   (not forgetting to import the module), is sometimes tiresome, and not easy
   to modify, especially if you generalize or restrict your procedure which
   demands other modules to be imported. Sometimes you must fight with a silly
   bug in the type reporting procedures, and correct manually
     .... (Vector a  -> b) ...     into   ... ((Vector a) -> b)...
   etc. Sometimes you realize that something which worked inside the main
   module refuses to compile in a library, because you get stuck in an
   instance of a *generic* constructor (t m ...) with t variable. Sometimes
   you simply don't understand all those anonymous (.) attributes and you don't
   know whether it is better to leave, or to remove them. Sometimes you get
   a message that not all strictness information is exported, and despite good
   friends around you still don't know what do you pay for that...
   Clean is for patient people, with not so weak nerves.

3. Now, this is a problem, and I need that myself. In principle
   making a plotting package is NOT difficult, the devil is in the details.
   The main devilish detail in Clean is the same as, say, with generic plotting
   procedures in C, Java, or any other compiled language:
   Plotting styles, window sizes, fonts, ticks, colours, etc. should be
   configurable independently of the plotted function (whether it is line plot,
   surfacic object, or other kind of visualisation, as iso-maps:contours,
   volumic cross-sections, etc.)

   This is *much* easier in an  environment specifically designed to be inter-
   active. The PLOT data structure in Maple, or "Handle graphic" objects in
   Matlab make it really easy to change ploting attributes without repeating
   the numeric/geometric work done (and of course without recompiling anything).

   Clean interactivity is difficult, and incomplete. Not only the fact the IO
   works under Windows only (no point in reminding that 4 times a week), but
   even there there are serious weaknesses, such as no deep access to the
   drawing context (simply: I have no idea how to convert a Picture into a
   bitmap (or a metafile with plot descriptors), and save it. I know how to
   make a bitmap manually (and how to save it on a file), but this is wrong
   approach.

=====

Jerzy Karczmarczuk
Caen, France