Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
GUI Builder limited to Windows platform (LONG)
I wanted to post a response I received from Mark Goosman, the IDL Product Manager, about my concern that the new GUI Builder is meant only for the Windows platforms. As far as I can tell, they have no plans on extending this functionality to other platforms. For a company that makes cross-platform compatibility one of its main selling points, I think this is inexcusable. Does anyone else agree? I probably wouldn't even use the Builder myself, but I know a lot of groups that are just beginning to develop widget programs, and this tool would be invaluable to them. Anyway, here is Mark's response. I've prefaced my comments by % (pun intended). First, I want to thank Mark for taking the time to send me a very thorough response. ====== Response from RSI's Mark Goosman, IDL Product Manager ======= Dave: Your Email to Jennifer Lodder was forwarded on to me. We are a small enough company that Email to just about any account finds it's way to a rightful recipient. I understand, and to a certain extent, share your comments regarding the IDL GUIBuilder being limited to the Microsoft Windows platforms. There are several issues that went into this decisions. The primary decision was the additional effort required to support the IDL GUIBuilder on all supported IDL platforms. This would have required development and testing on each of the Motif versions of Sun, HP-UX, SGI, IBM/AIX, DEC Unix, in addition to the Macintosh. We also have some very verbal OpenVMS customers who expect the same level of support. This level of resource is beyond the scope of Research Systems and would have prevented us from releasing IDL 5.2 in a reasonable time frame. We also had a large number of other major features for IDL 5.2 that could not have been implemented had we not limited the IDL GUIBuilder to the Windows platform. I'm not sure if you've seen the total list of new features for IDL 5.2 but we've added several new data types (16 bit unsigned, 64 bit signed, and 64 bit unsigned), support for several new data file formats (HDF-EOS, DICOM, PNG, DXF, and others), very large files, and several other features requested by our user community. % So it really boils down to a question of priority. Either get % version 5.2 released, or spend resources implementing the Builder % on other platforms. Tough decision. My first question would be: If % supplying a GUI Builder for the platforms that use IDL is "beyond % the scope of Research Systems" then why was the Builder created % for the Windows platforms in the first place? And my next question % would be: How many other platform specific tools (and perhaps % upgrades!) will we have to look forward to? We are finding that most Unix users of IDL do have access to Windows machines. The recent addition of FlexLM support to IDL for Windows means that anyone with an Unix floating license can set up IDL for access on their Windows platforms. This offers a solution to a large percentage of our Unix customer base. One major goal of the IDL GUIBuilder was that the generated code be cross-platform compatible. % No. I would agree that most Unix users have access to Windows % machines, but it is not true that most Unix users have floating % license; at least not here at UCSD, where this is definitely % not true. For a group such as ours, floating point licenses % are much more expensive, so upgrading the licenses would not % be an acceptable option. One other major aspect of the decision was the demand for GUI development tools on the Windows platform compared to the same market for Unix. There are several major companies offering these types of tools (Microsoft Visual Basic, Symantec Cafe, etc). There are, however, fewer products for Unix users reflecting less of a demand. % If this is the kind of reasoning that RSI's marketing used to % reach these decisions then we are really in trouble! The demand % for GUI builders for Visual Basic, C and Pascal reflect a need % for such tools by those creating commercial applications that % they intend to market. My impression is that most of the users % of IDL are writing in-house applications for their own research % purposes. The software is to be used locally, and not distributed. % There is absolutely no reason to assume that those users of IDL % using Windows machines have any more need for a GUI Builder than % those who use Unix machines. % % So as I now understand it, what it *really* boils down to is % "market demand". Any decision on new features and functionality in IDL is based on providing the best solution to the IDL user community. I hope it is apparent that RSI makes every effort to prioritize resources in a way that makes IDL most effective in solving the needs of our users and customers. % Don't get me wrong. I love IDL, I would be a great salesman for % it. But it concerns me when I see a company begin to favor support % for one platform over another, based on an analysis of "market % demands". This is the first time I have seen this with RSI. I % have seen this many times with other companies, and the results % are always unfortunate for those who don't happen to be using the % most common platform/hardware/software/etc.. If RSI decides to % support a particular platform, then SUPPORT it! % % Thank-you for your valuable time; I really appreciate your % very thoughtful response. % % Dave Please let me know if you have any questions or additional comments. Best regards, Mark Goosman ******************************************** Mark Goosman IDL Product Manager Research Systems, Inc. 4990 Pearl East Circle Boulder, CO 80301 USA Tel: 303-413-3966 Fax: 303-786-9909 Email: mgoosman@rsinc.com WWW: http://www.rsinc.com ************************************* -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ David S. Foster Univ. of California, San Diego Programmer/Analyst Brain Image Analysis Laboratory foster@bial1.ucsd.edu Department of Psychiatry (619) 622-5892 8950 Via La Jolla Drive, Suite 2240 La Jolla, CA 92037 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
> I hope it is > apparent that RSI makes every effort to prioritize resources in a way > that makes IDL most effective in solving the needs of our users and > customers. Is this the opinion of the users and customers on this newsgroup?
Re: GUI Builder limited to Windows platform (LONG)
Hi Dave, The GUI builder is slick, but it doesn't really save you any time programming (as long as you can type more than 10 words a minute). It can't hide the nuts and bolts...only make them look like something else. In a previous incarnation, WIDED (which is certainly not a fair comparison, considering how much work has gone into the GUI builder), I would use a lot to get a quick look at how my widgets would appear on the screen. But, I would still go back to simple programming for the final product. (A bug in the READF in the beta version made me stop using 5.2b regularly, but I suspect that I'll still continue to write from scratch even with the corrected release). On your remarks about platform independence, when I first used IDL (version 1) it only came in VMS flavour ....not very platform independent! And since RSI is a company, they surely must pitch for 'the market'.....after all, they're not gn-doing it for free. I don't believe they ever supported BE? And, strictly speaking IDL is not really platform independent - they only provide versions for most of the common operating systems. Moreover, you know that any serious code must be 'nudged' to run on different platforms (I'm particularly annoyed at the moment by having to try to get rid of a bunch of DOS calls in an old programme I'm updating). I would not be surprised if VMS was dropped in the near future (but hopefully NASA/Goddard is loud?). If Jobs doesn't keep the iiiiiiiiiiiii-mprovements to the Mac, then that could quite easily fall by the wayside. Neither, of course, would be a big deal if you're not using either OS (and at least 95% (depending on how you define 'users') aren't). What is somewhat disturbing is the transition from UNIX as being the mainstay of IDL to Windows, which the introduction of the GUI builder is obviously signalling. But, if UNIX isn't paying the bills, and you've got a 450 MHz Pentium II with 1/2 a gig of memory and 50 gigs of space then you rule the world...at least in my little mind. -Pete Riley
David Foster wrote: > > I wanted to post a response I received from Mark Goosman, the > IDL Product Manager, about my concern that the new GUI Builder is > meant only for the Windows platforms. As far as I can tell, they > have no plans on extending this functionality to other platforms. > <long response snipped> I wanted to follow this up with a sincere apology to Mark Goosman. It is important that everyone know that his reply to me was a personal communication, and he did not intend to have it posted for the world to see. After a discussion with him I realize that I should have responded to him personally, and then perhaps posted the results of this exchange. Posting his reply without his permission was a serious breach of netiquette and I apologize. After talking with Mark I have a better idea of how hard it is for RSI to prioritize development efforts given limited resources. And to be fair, I am much happier having support for Dicom, unsigned integers, etc. etc. in IDL 5.2 than I would have been with a GUI builder for my Unix box. Sincerely, David Foster ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ David S. Foster Univ. of California, San Diego Programmer/Analyst Brain Image Analysis Laboratory foster@bial1.ucsd.edu Department of Psychiatry (619) 622-5892 8950 Via La Jolla Drive, Suite 2240 La Jolla, CA 92037 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
In article <Y8v22.7529$q15.230893@news.san.rr.com>, "Pete Riley" <uk2@scibernet.com> wrote: > Hi Dave, > stuff deleted > But, if UNIX isn't > paying the bills, and you've got a 450 MHz Pentium II with 1/2 a gig of > memory and 50 gigs of space then you rule the world...at least in my little > mind. > > -Pete Riley > I was unpleasantly surprised when I was not able to get a piece of high-end electro-magnetic software for a DEC Alpha. It was made for WIntel, and other Unixes, but not for DEC. Similarly, the software we use for 3D magnetic modeling is first released for WIntel and only then for the Unix boxes. Puzzled, frustrated, I inquired. And the answer was simple enough, as if they were quoting Mr. Gates from his Economist article (a couple of months back). Any PC running WIntel will run their codes. But each Unix vendor's Unix is different, and requires additional programming effort. Thus in some sense, the Unix machine vendors have placed themselves in that unenviable position, with all of their best versions of Unix. Thus, for commercial written software, WIntel may be the platform of choice, and the workstations are left to internally written software. Possybly the only thing that can bring Unix back to favor with the software developers is Java. At a recent Plasma physics conference (Maui, Hawaii :-)) one company was showing a modeling code written in C and the front end in Java. Actually, written in F90, translated and compiled into C. My two breaths Mirko -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Re: RSI's Priorities (was: GUI Builder...)
Brian Jackel (jackel@danlon.physics.uwo.ca) writes: > However, I'm watching recent developments with objects and > object graphics with some dismay. All of the data analysis > and display that I've needed to do has been easy to accomplish > without any of these newfangled object thingies. Seriously, > I've managed to maintain some moderate sized programs without > using objects. Given the existence of objects it is quite > likely that I'll get around to using them eventually, but I > can't help but see this as a choice between > > New bells and whistles at $1500 a pop or > Freeze development and deliver an ``IDL Classic'' at > $500 per head. Objects have absolutely revolutionized the way I write programs. I think they will have as big an effect on me as widgets did when they were first introduced. I don't think I've written a program for pay in the last six months that didn't have at least one object in it. And I especially like them with direct graphics. They are fast, they print nicely, and they are unbelievably powerful. Could I do the same thing without objects? Probably, if I were clever enough. But objects just make it so darn easy. :-) I cast my vote more more bells and whistles like this one! Cheers, David ---------------------------------------------------------- David Fanning, Ph.D. Fanning Software Consulting E-Mail: davidf@dfanning.com Phone: 970-221-0438, Toll-Free Book Orders: 1-888-461-0155 Coyote's Guide to IDL Programming: http://www.dfanning.com/
Andy Loughe wrote: > >> I hope it is >> apparent that RSI makes every effort to prioritize resources in a way >> that makes IDL most effective in solving the needs of our users and >> customers. > > Is this the opinion of the users and customers on this newsgroup? I've rather mixed feelings on this subject. RSI has always been very helpful with regard to bug reports. They are still making enhancements to IDL that I find useful, such as 16-bit unsigned integers, PNG support, and keeping up with CDF. However, I'm watching recent developments with objects and object graphics with some dismay. All of the data analysis and display that I've needed to do has been easy to accomplish without any of these newfangled object thingies. Seriously, I've managed to maintain some moderate sized programs without using objects. Given the existence of objects it is quite likely that I'll get around to using them eventually, but I can't help but see this as a choice between New bells and whistles at $1500 a pop or Freeze development and deliver an ``IDL Classic'' at $500 per head. My vote would certainly be for the second option. -- Brian Jackel
"Pete Riley" <uk2@scibernet.com> writes: > On your remarks about platform independence, when I first used IDL (version > 1) it only came in VMS flavour ....not very platform independent! Actually, I remember using IDL on a PDP/11, before we got our first VAX. I guess that must have been version 0. ;^] > And, strictly speaking IDL is not really platform independent - they only > provide versions for most of the common operating systems. You're right, of course. However, with a little bit of care, it's actually not all that hard to write code that works on all the platforms that IDL supports. I've come to expect that we can distribute code to an international community using a wide variety of different computers, without having to distribute different versions for different architectures. I think we should commend RSI on the number of things that do work across platforms. William Thompson
In article <364DDB7F.C8531805@io.harvard.edu>, Martin Schultz <mgs@io.harvard.edu> wrote: > David Fanning wrote: > >> Brian Jackel (jackel@danlon.physics.uwo.ca) writes: >> >> [...] >>> >>> New bells and whistles at $1500 a pop or >>> Freeze development and deliver an ``IDL Classic'' at >>> $500 per head. >> [Long comments omitted so my new client will let me post!] Frankly, I just pulled down the objects manual and the 5.1 changes manual the other day for the first time, to try to see if it was a better way to write MPEG movies than I was using (should I cross post to that thread?). Applying Occam's razor (the one that slits your throat if you try doing things elegantly when you already have three job titles and a family to boot), I will probably decide to make do with what I know how to do instead.... but I'm intrigued. Maybe next time. More to the point, the folks here who _do_ have time all prefer objects, and have written some very powerful analysis tools built around them. (See, for example, http://orpheus.nascom.nasa.gov/~zarro/idl/maps.html .) And they're even scientists.... and even got their degrees more than 10 years ago. Guess I'll go with the opinions of those who write the most and best code here. Joe Gurman P.S. And on the subject of MPEG movies and 3 x m x n arrays (why did RSI have to make that the default for MPEG_PUT if you want color?), I'm spoiled by a machine that's fast enough that I don't really have to worry about the speed difference between intelligent and silly index ordering. Now that's spoiled. P.P.S. And yes, sigh, scientists do work weekends. I understand Ken Burns used the "The intellect of man is forced to chose / Perfection of the life or of the work" line of Yeats in his show on Frank Lloyd Wright. I wonder if he used the next line: "and if it take the second must refuse a heavenly mansion, raging in the dark." -- Joseph B. Gurman / NASA Goddard Space Flight Center / Solar Physics Branch / Greenbelt MD 20771 / work: gurman@gsfc.nasa.gov /other: gurman@ari.net Government employees are still not allowed to hold opinions while at work, so any opinions expressed herein must be someone else's.
Brian Jackel (jackel@danlon.physics.uwo.ca) writes: > Another important issue is that most of us researchers > don't have much experience with object oriented programming. > If I give some IDL code to someone who knows Fortran/Pascal/C > they can probably see what's going on and make whatever > changes they need. But objects? Forget it. Again, life > is short and procedural programming works well enough for > most of us. > > Hmmm, I'm sounding like an old codger now... Brian, I've been known to feel a little old from time to time too, but I can assure you that the people who want you to think object oriented programming is hard are all after your job and are at least 10 years younger than you. :-) It is NOT hard. In fact, the wonderful thing about it is just how EASY it is. Sigh... I've really got to get this next book finished. The only thing that prevents me is knowing that anyone who spends a hour reading the book and learning about objects will soon be writing programs that are about 10 times better than mine. :-( You're right, Brian. Object programming *is* too hard. I wouldn't even look into it. :-) Cheers, David ---------------------------------------------------------- David Fanning, Ph.D. Fanning Software Consulting E-Mail: davidf@dfanning.com Phone: 970-221-0438, Toll-Free Book Orders: 1-888-461-0155 Coyote's Guide to IDL Programming: http://www.dfanning.com/
Brian Jackel wrote: > [...] One other common thing among scientists: they work on weekends ;-) Martin. -- ------------------------------------------------------------ ------- Dr. Martin Schultz Department for Engineering&Applied Sciences, Harvard University 109 Pierce Hall, 29 Oxford St., Cambridge, MA-02138, USA phone: (617)-496-8318 fax : (617)-495-4551 e-mail: mgs@io.harvard.edu Internet-homepage: http://www-as.harvard.edu/people/staff/mgs/ ------------------------------------------------------------ -------
David Fanning wrote: > Brian Jackel (jackel@danlon.physics.uwo.ca) writes: > > [...] >> >> New bells and whistles at $1500 a pop or >> Freeze development and deliver an ``IDL Classic'' at >> $500 per head. > > Objects have absolutely revolutionized the way I write > programs. I think they will have as big an effect on me > as widgets did when they were first introduced. I don't > think I've written a program for pay in the last six > months that didn't have at least one object in it. And > I especially like them with direct graphics. They are > fast, they print nicely, and they are unbelievably > powerful. > > Could I do the same thing without objects? Probably, if > I were clever enough. But objects just make it so darn > easy. :-) > > I cast my vote more more bells and whistles like this > one! > > Cheers, > > David > > ---------------------------------------------------------- > David Fanning, Ph.D. > Fanning Software Consulting > E-Mail: davidf@dfanning.com > Phone: 970-221-0438, Toll-Free Book Orders: 1-888-461-0155 > Coyote's Guide to IDL Programming: http://www.dfanning.com/ I claim that this newsgroup is biased !! Sure enough, personally I rather take it as my own fault that I have *not* been using objects in IDL yet -- there are just always so many things that have to be finished on time that I never get around learning about them (in fact, I haven't even fully digested all the information that David gives on widget programming in his book yet ... sigh ... if I only had time to improve my EXPLORE program ... end sigh). But: e.g. in our research group there about 10 people using IDL, and 1.5 of them participate in or even read this newsgroup. Most others (and I would say that's probably typical for scientists) have some basic knowledge in programming (sure, FORTRAN (=f77) mostly), but not much beyond that. They are quite happy if they can use e.g. a readdata.pro to retrieve some ASCII data from a file, and they rejoice when they learn about the where function. Most programs written in our groups start out as 5-20 lines of code, hand-tailored for one specific plot. And most programs stay that way, too. I am already happy if my colleagues make use of some of the library routines that I have written or gathered from various sources, but if I were ever to tell them: "Here's this perfectly handy and powerful routine, and it's even object-oriented!" they would just thank me very politely but never speak to me again ;-) There once was a german chancellor who said "Entscheidend ist, was hinten rauskommt" (free translation: "it's the plot, stupid! [not the program]"), and he sure was right on this one. But if David ever writes another book on object oriented IDL programming techniques, I may well become one of his customers! Best regards, Martin -- ------------------------------------------------------------ ------- Dr. Martin Schultz Department for Engineering&Applied Sciences, Harvard University 109 Pierce Hall, 29 Oxford St., Cambridge, MA-02138, USA phone: (617)-496-8318 fax : (617)-495-4551 e-mail: mgs@io.harvard.edu Internet-homepage: http://www-as.harvard.edu/people/staff/mgs/ ------------------------------------------------------------ -------
Robert S. Mallozzi wrote: > I agree - objects and pointers greatly increased IDL's > functionality and ease of use. They, as widgets did, take > IDL to a new level. I often find myself thinking, > what's the best way to handle this data...use a pointer, of > course. In fact, it's interesting to think of how I ever > got along without them :-) > > Also, I feel there is no doubt about it - object programming > is, in most cases, far superior to the "old" procedural method. > Code reuse is one of the great advantages - write the object once, > then *forget* about the internals, and just use it. That said, > of course there is still the need for fast development and > analysis, and objects might not be useful for this type of > "quick and dirty" work. Pointers are definitely handy, especially for getting large amounts of data between widgets. As for objects, well... Perhaps the problem is that most of my work is "quick and dirty"! For example, I've just finished deblurring some satellite images. This required 1) Figuring out how to read in a peculiar data format 2) Cleaning the data and calculating statistics 3) Trying several different deblurring algorithms 4) Creating a bunch of figures for a report The whole process was very interactive and iterative. Now I'm (sort of) done and have a set of working routines and some example scripts. It might be nice to go back and clean everything up, but time is short. Sure it could be nicely packaged with objects, but I can't see how objects would have helped me during the development phase.* Another important issue is that most of us researchers don't have much experience with object oriented programming. If I give some IDL code to someone who knows Fortran/Pascal/C they can probably see what's going on and make whatever changes they need. But objects? Forget it. Again, life is short and procedural programming works well enough for most of us. Hmmm, I'm sounding like an old codger now ("In my day, all we had were zeros and ones, and sometimes we didn't even have ones!"). Ten years ago as an undergrad I'd learn new programming and scripting languages just because they were cool. These days I'm more interested in physics, and just want tools that work. There does seem to be a clear distinction between people involved in 1) Research/analysis 2) Development of ``production'' level code For what it's worth, I'd say every one of the half-dozen IDL users in our group fall into category 1. Brian Jackel *A general ``image'' object might have been useful, but I'm not sure how a sufficiently generic thing could be created. A satellite image is a completely different beast from the image produced by an all-sky camera. I'll just stick with a 2D array, and do whatever pruning is required on a case-by case basis.
In article <MPG.10b6b35a5dca0660989722@news.frii.com>, davidf@dfanning.com (David Fanning) writes: > Brian Jackel (jackel@danlon.physics.uwo.ca) writes: > >> However, I'm watching recent developments with objects and >> object graphics with some dismay. All of the data analysis >> and display that I've needed to do has been easy to accomplish >> without any of these newfangled object thingies. Seriously, >> I've managed to maintain some moderate sized programs without >> using objects. Given the existence of objects it is quite >> likely that I'll get around to using them eventually, but I >> can't help but see this as a choice between >> >> New bells and whistles at $1500 a pop or >> Freeze development and deliver an ``IDL Classic'' at >> $500 per head. > > Objects have absolutely revolutionized the way I write > programs. I think they will have as big an effect on me > as widgets did when they were first introduced. I don't > think I've written a program for pay in the last six > months that didn't have at least one object in it. And > I especially like them with direct graphics. They are > fast, they print nicely, and they are unbelievably > powerful. > > Could I do the same thing without objects? Probably, if > I were clever enough. But objects just make it so darn > easy. :-) > > I cast my vote more more bells and whistles like this > one! I agree - objects and pointers greatly increased IDL's functionality and ease of use. They, as widgets did, take IDL to a new level. I often find myself thinking, what's the best way to handle this data...use a pointer, of course. In fact, it's interesting to think of how I ever got along without them :-) Also, I feel there is no doubt about it - object programming is, in most cases, far superior to the "old" procedural method. Code reuse is one of the great advantages - write the object once, then *forget* about the internals, and just use it. That said, of course there is still the need for fast development and analysis, and objects might not be useful for this type of "quick and dirty" work. Regarding the recent discussions of the cost of IDL, it is a bit disconcerting that the price of the software really prohibits me from getting it for home use, and I believe is restricting the possible widespread use that IDL might enjoy if it was lower cost. I think stand-alone IDL executables would certainly be a step in the right direction for increasing the user base and thus (hopefully) reducing the cost of the software. If people could see the power of IDL without having to buy the interpreter, it seems to me that there would be some developers that might say "Gee, now that I see how powerful the language is, maybe I should think about buying it to do some development...". So, how about it, RSI - give us the capability to distribute IDL executables for the world to see! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~ Robert S. Mallozzi 256-544-0887 Mail Code ES 84 Work: http://www.batse.msfc.nasa.gov/ Marshall Space Flight Center Play: http://cspar.uah.edu/~mallozzir/ Huntsville, AL 35812 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~
In article <gurman-1411982301570001@goodgulf.nascom.nasa.gov>, gurman@gsfc.nasa.gov (Joseph B. Gurman) wrote: > In article <364DDB7F.C8531805@io.harvard.edu>, Martin Schultz > <mgs@io.harvard.edu> wrote: > >> David Fanning wrote: >> >>> Brian Jackel (jackel@danlon.physics.uwo.ca) writes: >>> >>> [...] >>>> >>>> New bells and whistles at $1500 a pop or >>>> Freeze development and deliver an ``IDL Classic'' at >>>> $500 per head. >>> > [Long comments omitted so my new client will let me post!] > > Frankly, I just pulled down the objects manual and the 5.1 changes > manual the other day for the first time, to try to see if it was a better > way to write MPEG movies than I was using (should I cross post to that > thread?). Applying Occam's razor (the one that slits your throat if you > try doing things elegantly when you already have three job titles and a > family to boot), I will probably decide to make do with what I know how to > do instead.... but I'm intrigued. Maybe next time. > Unfortunately, it takes much more than a weekend to appreciate the usefullness of OOP. I was fortunate enough to have enough liberty at my previous and current place of work, to have had the time to learn the rudiments of what (I think) is the proper way of OOPing. On a related thread, while the programming features of IDL are growing, I would hope that the interactive features would do the same. Insight may be one attempt, but still very limited. The ideal, as I see it, would be a GUI type tool, where you would click and drag data to appropriate functions (or use some of them to create the data). If input were necessary, a dialog window would pop up. The interface would be able to compile user functions and procedures, and create rudimentary, non-intelligent input/output dialogs for them as well. Since data analysis is typically a sequence of actions, each action may be represented by connecting lines between data objects (I am talking here arrays and vectors as objects, nothing fancy), and the functions that operate on them. A time sequence of these connections would then be transformed into an IDL program for the user to tweak. It seems to me that all of this should be implemented in IDL or Java. (I have never programmed in Java). That should make it platform independent. Now how 'bout that?! Off I go to implement this!!! Yeah right :-) cheers, Mirko -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Just a few thoughts while I'm waiting for an IDL program to finish executing: I've been using IDL since 1986, when it was at V1.0 and graphics output meant a Tektronix terminal and an HP plotter (I had to write my own workstation display and Postscript drivers, before RSI came out with them). I have used IDL as my primary programming and data analysis environment since then (even during the dark days at work where using IDL to do something was essentially forbidden because of all of the development effort in IRAF/STSDAS). I have developed something of a love/hate relationship with IDL over the years. I love the ability to work directly and interactively with my data and do things with one line of code that would take many in other languages; I can appreciate the power and simple beauty of the WHERE function; and I can respect the utility of widgets. However, some things drive me crazy. It seems with every major release, much of my code and the code in libraries I use (like the Astronomy User's Library) breaks because RSI changed a keyword, changed the functionality of a procedure, or altered the behavior of some feature. The utmost worst time I ever had with IDL was with widgets. It got to the point that every minor release changed the way widgets behaved, breaking code right and left. It seems to me the same has been happening with objects. They were implemented before they were really well thought out. I would never recommend IDL for mission critical work unless its use was frozen to a specific version. It's just not safely backwards compatible. Cost is also a factor, and it hurts the further widespread use of IDL in more than one way. I myself cannot afford the $1895 for a Windows or Linux license (yes people, the price is going up after January 1, not down), and that doesn't factor in the cost of maintenance contracts. I know more than one place where IDL is still at version 4 or so, because the cost is just too high. And of course, when people start using new features like objects, these places are left out, unable to use other's code, futher souring there relationship with IDL. Give me a stable, moderate cost environment and I'll be happy (well, content). What we need is a Turbo Pascal sort of thing (low cost, does the job) to shake some sense into RSI. Volume, volume, volume! And don't get me started on dongles... John Krist ------------------------------------------------------------ -------------- The opinions expressed above are my own and not necessarily those of my employer (STScI) or its employer (AURA) or its employer (NASA) or its employer (the Government) or its employer (me). Oops, I guess they are!
In article <72evlf$116$1@nnrp1.dejanews.com>, mirko_vukovic@notes.mrc.sony.com writes: > Puzzled, frustrated, I inquired. And the answer was simple enough, as > if they were quoting Mr. Gates from his Economist article (a couple of > months back). Any PC running WIntel will run their codes. But each > Unix vendor's Unix is different, and requires additional programming > effort. > Thus in some sense, the Unix machine vendors have placed themselves in > that unenviable position, with all of their best versions of Unix. > Thus, for commercial written software, WIntel may be the platform of > choice, and the workstations are left to internally written software. And, shortly speaking, it is almost complete nonsense. Almost any decent Unix program compiles on many flavours of Unix. There is more than enough Software to run on, e.g. Dec, HP, AIX, SGI and Intel-Unix, where you don't get a Win-version. In general, if you have one unix-version, porting it to another flavour of unix is very little effort. If I remember correctly, a programmer of Informix wrote about the port to Linux: "Basically, it was just a 'make'.." Peter -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~ Peter "Pit" Suetterlin http://www.uni-sw.gwdg.de/~pit Universitaets-Sternwarte Goettingen Tel.: +49 551 39-5048 pit@uni-sw.gwdg.de -- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- Come and see the stars! http://www.kis.uni-freiburg.de/~ps/SFB Sternfreunde Breisgau e.V. Tel.: +49 7641 3492 ____________________________________________________________ ______________
In article <72ndn1$ror$1@nnrp1.dejanews.com>, mirko_vukovic@notes.mrc.sony.com writes: > Since data analysis is typically a sequence of actions, each action > may be represented by connecting lines between data objects (I am > talking here arrays and vectors as objects, nothing fancy), and the > functions that operate on them. A time sequence of these connections > would then be transformed into an IDL program for the user to tweak. > It seems to me that all of this should be implemented in IDL or > Java. (I have never programmed in Java). That should make it platform > independent. Sounds a bit like Khoros, which also has a graphical programming frontend. Peter -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~ Peter "Pit" Suetterlin http://www.uni-sw.gwdg.de/~pit Universitaets-Sternwarte Goettingen Tel.: +49 551 39-5048 pit@uni-sw.gwdg.de -- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- Come and see the stars! http://www.kis.uni-freiburg.de/~ps/SFB Sternfreunde Breisgau e.V. Tel.: +49 7641 3492 ____________________________________________________________ ______________
In article <72kkbt$1258@ds2.acs.ucalgary.ca>, Brian Jackel <jackel@danlon.physics.uwo.ca> writes: > There does seem to be a clear distinction between people > involved in > 1) Research/analysis > 2) Development of ``production'' level code > For what it's worth, I'd say every one of the half-dozen > IDL users in our group fall into category 1. Brian, I do wholehartedly agree. I'm also from group 1, and really don't have a need for all those fancy things. Even widgets are a very rare thing for me.... I'm not quite shure what the people at RSI are aiming at. E.g., have a look at mathematica. When I first heard of it, it was a tool for doing analytic mathematics. Imagine my face when someone told me he is using it for data visualisation now. Same for IDL, it looks like they want to make some sort of visual basic out of it. Together with the prices, this makes me heavily think about switching to ANA or Midas. Peter -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~ Peter "Pit" Suetterlin http://www.uni-sw.gwdg.de/~pit Universitaets-Sternwarte Goettingen Tel.: +49 551 39-5048 pit@uni-sw.gwdg.de -- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- Come and see the stars! http://www.kis.uni-freiburg.de/~ps/SFB Sternfreunde Breisgau e.V. Tel.: +49 7641 3492 ____________________________________________________________ ______________
Mirko , mirko_vukovic@notes.mrc.sony.com writes: > On a related thread, while the programming features of IDL > are growing, I would hope that the interactive features > would do the same. Insight may be one attempt, but still > very limited. For me, the real benefit of the object orientation is actually during interactive use. The fact that objects are globally accessible and encapsulated makes it much easier to mix fully developed, 'production' code and new routines which are still at the brainstorming stage. I still do a lot of ad-hoc programming for one-off cases, but anything that does get used more than a few times quickly migrates from being a 'temp.pro' file to a full-blown widget, especially if there are parameters I want to play with interactively (and these can be algorithmic parameters as well as functional ones). Not surprisingly, other people are much more willing to use my routines if I provide them in a packaged form with widget front ends, and now I can use those widgets myself while mucking about at the command line with the same data. I like IDL and try to evangelise it in my lab. RSI deserve credit for staying multi-platform in a non-trivial way and they do seem to try and address users' concerns. Prices are always emotive, and personally I would love to see a cheaper way of distributing completed applications, but on the other hand I am aware of the dangers of insufficient cashflow to small businesses who are trying to innovate and I also can't help wondering how much of the price of IDL is made up of fixed licensing fees for things like OpenGL that can't be reduced. My biggest worry is that there is a tendency for known bugs to persist forever. My favourite whinge is the lack of tools to monitor memory usage, but the immortal contour plot problems and the non-drawing of large offshore islands in direct graphics are other examples of hugely annoying issues that seem to have been simply ignored on the way to implementing sexier new features. There are similar unncessary limitations built into the current object graphics routines (the IDLgrTrackball object is the least object-like object I've ever seen and a total pain in the arse to use), and I fear that they too will be ignored or left to web-archives of known workarounds to sort out rather than being fixed properly. Such casual disregard for 'minor bugs' is less of a problem in a community of IDL gurus who are essentially programming for themselves, but tilts the learning curve to unnecessarily steep angles for novice and casual users, which makes life harder for both myself and the RSI sales force. Struan