[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Plea for IDL 2000 (was: a plea for more reliable mathematical routines)

In article <MPG.124804e8864d03df9898ec@news.frii.com>,
>> [Arno:] 
>> I definitely disagree. It is inferior to Java, Python, C/C++ [...]
> [David:]
> I mean, honestly, that fact that IDL is still selling as well
> as it does is not a testament to what a great language it is.
> It is a testament to how hard it is to write something like
> it that can beat it in the marketplace. [...]
> Somebody has to be looking at the ol' man and thinking
> "I can do better than that." Perhaps that somebody is
> you, Arno. [...]

Sound to me as if Dave Stern should take this as a wakeup call and
lock himself into the garage for a while ;-) Seriously: RSI has the
source code, so for them it would be a head start to come up with a
more modern version of IDL -- let's just name it IDL 2000 (although
it might be a little late for this). Who really needs more features in 
IDL as it is? Why not consolidate all forces and give the old lady
(why "man" David?) a rejuvenalization? Start from scratch and rebuild
the language, but leave the general syntax (arguments and keywords,
comma seperation) untouched, so it would be somewhat less hard to
convert old programs (of course even better would be some kind of 
conversion tool which would be helpful enough if it could convert
90% of the code and mark the remaining 10%).

As a start, here a short list of fundamentals that I would like to 
see changed:

* Data types: The default integer should be 32 bit (if not even 64),
   so you would get rid of many problems with loops and array indices.
   For reading of binary files, a 2 byte integer should be kept as

* Mathematical routines: well, see the thread. But definitively, they
   should all operate on DOUBLE as default and -- if at all -- allow a
   /SINGLE keyword in case one runs out of memory with DOUBLE arrays.

* PLOT and the likes: should also operate with DOUBLE values. There
   should be a solid 2D object oriented model together with a successor
   of the direct graphics routines (which are still useful to create
   real quick overview plots and maybe even for publication quality 
   plots exactly because of the lack of interactivity!).
   All the keywords should be cleaned, e.g. it should be possible
   to call PLOT with an /OVERPLOT keyword (i.e. the same as OPLOT)
   and you should definitively not need an /ADVANCE keyword for
   MAP_SET. Also (as I remarked about a year ago) it should be more
   intuitive e.g. to turn of axis labels (would you have ever thought
   of TICKFORMAT='(A1)' on your own?). AND: please get rid of these
   annoying character units (e.g. MARGIN)!

* SMP (symmetric multiprocessing) is becoming more and more of a 
   standard, so IDL should support it.

* Foreign language support in the vector fonts would also be on my
  wish list (but please don't go as far as Windows where you always
  have to access the system's control panel to change from ',' as
  decimal notation to '.' if you exchange data with colleagues in
  an Excel spreadsheet). It would just be nice if one could e.g.
  write "o for an o-umlaut (perhaps it would be great if the Tex2IDL 
  interface would become some integral part of IDL. TeX is extremely
  powerful in formatting equations etc., and it is much more intuitive
  to write 'A_3' or 'A_{3,2}' instead of 'A!L3!N' or 'A!L3,2!N'.
  Also, TeX is fairly wide spread so people would not have to adapt 
  to yet another formatting syntax.

* The image routines should be standardized and not consist of a mixture
  between procedures and functions as it is now.

* In order to achieve more consistency between the object oriented graphics
  and direct graphics, one should perhaps think of adapting the GNUPLOT
  approach: there you call a bunch of SET commands to specify the plot
  style, and then the PLOT command becomes much shorter. In principle
  one could map the object structure with its view, plotwindow, axis, etc.
  onto a hierachical structure which could be used in the same way by the
  direct graphics routines (probably direct graphics would in the end
  be only another interface for what in fact is object graphics?). 

Once again: I really think IDL as we know it has reached its maturity a
while ago, and now it's time to think of the future! Of course RSI still 
needs to support the current IDL version and its users, but I really think
they should give their development team a new direction.

Have a good day,


[[     Martin Schultz   Max-Planck-Institut fuer Meteorologie    [[
[[                      Bundesstr. 55, 20146 Hamburg             [[
[[                      phone: +49 40 41173-308                  [[
[[                      fax:   +49 40 441787                     [[
[[     martin.schultz@dkrz.de                                    [[