| global variables and IDLSPEC issues [message #11537] |
Wed, 22 April 1998 00:00  |
J.D. Smith
Messages: 214
Registered: August 1996
|
Senior Member |
|
|
Martin Schultz wrote:
>
> J.D. Smith wrote:
>>
>> Allow me to elaborate on the situation which would require a more
>> flexible mechanism for importing and exporting main level variables.
> [...]
>
> Thanks! That makes sense indeed.
>
>> And as for the philosophical question of greater power vs. consolidation
>> and organization, I see it as a non-issue. I argue that if the
>> introduction of new features and flexibility makes a program less
>> accessible, they were not correctly implemented. The common backbone of
>> all good programs I've encountered is the hierarchical organization of
>> functionality: a gentle learning curve whose gentleness nonetheless
>> does not impose arbitrary limits on how high the curve goes. I realize
>> this is difficult to implement in the real world, but I don't see this
>> as an excuse. Take as an example the IDL Advanced Development tools for
>> linking with external programs, and even embedding IDL within a custom
>> program. These tools are certainly above the heads of most IDL users
>> (including myself, for the most part), but they are eminently useful and
>> powerful. Most users, however, can be perfectly productive without
>> knowing anything about them.
>
> I certainly agree with you on this. It's just that I seem to know more
> people who struggle with the basics in IDL than with other "plotting"
> software. So there must be a big step before you can gently ride uphill
> on the learning curve. It may be true that one should not temper with
> IDL if one is only interested in producing the occasional line graph,
> there may be other point-and-click programs which are less frustrating,
> but I am convinced that IDL could win many more users if the first steps
> were simpler. If David's book became the standard users' manual and all
> those "but"s were eliminated (the consolidation) that could greatly
> facilitate beginner's access to our favorite software. And although I
> easily admit that I probably know less than 20% of IDL's features, I
> keep wondering why I have to look up all these !X and !Y tags in the
> online help every time I want to produce a plot that looks just a little
> different from others. And sometimes it is really hard to find out about
> "new" features: unless you know the name of the routine you are looking
> for, it can take quite a while before you find it, and if you are not
> sure whether it exists, you may give up early.
I do agree IDL plotting is a mess. I use it for interactive programs,
and quick looks, but for real, publish-quality plots, I use another
package altogether. It is disheartening that getting a fully customised
plot is so difficult in a package which offers so much graphics power,
and I firmly believe this issue could be dealt with. Whether Object
Graphics will provide the solution is yet to be seen.
>
>>
>> I believe IDL *should* focus on consolidating and cleaning their
>> interface, but I don't think they should delay or inhibit the
>> introduction of new features to help achieve this consolidation. As we
>> all know, the simplest program is the one which does nothing at all.
>>
>
> That may be a matter of resources, too. But you are certainly right: if
> there already i ssome code to do what you want, and it's just not
> documented and/or accessible, then release of this should certainly not
> be delayed. And as I understand David and others, there may be a couple
> of things to improve in the OOP part which may be of greater importance
> as well.
>
> Regards,
> Martin.
>
> PS: BTW: do you have an idea how much the results of your speed survey
> could be affected by network speed rather than machine speed? True: not
> too many users may sit right at the fancy workstation directly, so the
> results may well reflect "wall clock time" in a real environment. But
> can one judge the machines from this? Somehow I have a hard time
> believing that so many PC's have faster graphics than an SGI
> workstation.
>
The speed survey results for calculational performance should be
independent of network vs. non-network access since the I/O test, which
could possibly depends on this factor, was removed from the sort key.
For graphics results, it is true that several entries acknowledged being
run over a network, and I documented all of these. Some entrants might
have neglected to tell me they were running over a network. However,
there were many workstation results which seemed legitimate and fell
well below the Pentium 133 machine. So, to sum up, while I can't say
that none of the machines in my survey had better performance than the
current top contender, I can say that the Pentium did beat several
legitimate high-end entries.
JD
--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-4083
206 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
