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

*Subject*: Plea for IDL 2000 (was: a plea for more reliable mathematical routines)*From*: m218003(at)modell3.dkrz.de (Martin.Schultz(at)dkrz.de)*Date*: 16 Sep 1999 08:24:48 GMT*Newsgroups*: comp.lang.idl-pvwave*Organization*: Deutsches Klimarechenzentrum, Hamburg*References*: <7r90g4$rqb$1@nnrp1.deja.com> <37D82EA9.BA62A369@wellesley.edu> <7r9jbl$aem$1@nnrp1.deja.com> <37DCCE9A.F1AC4BF1@zedat.fu-berlin.de> <MPG.1246a891f3c895e19898eb@news.frii.com> <37DE1600.5E99BDE4@zedat.fu-berlin.de> <MPG.124804e8864d03df9898ec@news.frii.com>*Xref*: news.doit.wisc.edu comp.lang.idl-pvwave:16574

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 SHORT. * 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 -- [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[ Martin Schultz Max-Planck-Institut fuer Meteorologie [[ [[ Bundesstr. 55, 20146 Hamburg [[ [[ phone: +49 40 41173-308 [[ [[ fax: +49 40 441787 [[ [[ martin.schultz@dkrz.de [[ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[

**Follow-Ups**:**Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines)***From:*Theo Brauers

**Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines)***From:*David Fanning

**References**:**ODEPACK***From:*ushomirs

**a plea for more reliable mathematical routines***From:*Richard G. French

**Re: a plea for more reliable mathematical routines***From:*ushomirs

**Re: a plea for more reliable mathematical routines***From:*FIT

**Re: a plea for more reliable mathematical routines***From:*David Fanning

**Re: a plea for more reliable mathematical routines***From:*FIT

**Re: a plea for more reliable mathematical routines***From:*David Fanning

- Prev by Date:
**Re: a plea for more reliable mathematical routines** - Next by Date:
**Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines)** - Prev by thread:
**Re: a plea for more reliable mathematical routines** - Next by thread:
**Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines)** - Index(es):