| Re: Undocumented functions in IDL [message #83345] |
Fri, 01 March 2013 06:08  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
timothyja123@gmail.com writes:
> I have to disagree entirely. I hear the I dont care about how it works I just want to get the job done over and over from scientists I work with. The problem is they end up writing code that takes them longer to finish then is almost impossible to maintain. I would hardly call that a triumph. When I'm asked to do something they are often amazed at how fast I can accomplish it. My problem is not with IDL itself its that SOME of the people that use it as wasting more time
trying to work on maintaining horrible code than investing the small amount of time to learn how to do things properly to begin with.
I'm just saying that as someone who has spent my entire career trying
(and mostly failing) to get scientists to write more elegant and
maintainable IDL programs I am beginning to appreciate, as my career
winds down, why this quest was so very, very hard. At the end of the
day, whether an IDL program is fast or elegant matters much less then
either you or I wish it would. What matters is whether a Ph.D. was
earned, a scientific result arrived at, a paper written, a career
advanced. Who cares in the end how much time was saved or wasted? It is
all part of the work we do.
Sure, choose 10 IDL programs at random and 9 of them will be awful. But,
almost every one of them will work and get the job done. (Although, God
knows, I often wonder how.) I'm probably going soft in the head. After
so many years spent engaging the enemy at every turn, I'm beginning to
feel friendly towards him, starting to appreciate his ferocious skills.
Let's just say it makes me hopeful that you "disagree entirely," since
then the fight will go on and maybe there will be a few more well-
written and elegant IDL programs in the world. But, I'm turning my
attention elsewhere. I've other battles to fight. Right now, for
example, I'm trying to get my ultralight backpack under 12 pounds for a
trip of a life-time to the wilds of Patagonia. I'm pretty sure, when I
talk to my grandchildren about my accomplishments later, this trip will
come to mind much sooner (and be a hell of a lot more interesting to
them) than how many wonderful IDL programs I've written. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Undocumented functions in IDL [message #83355 is a reply to message #83354] |
Thu, 28 February 2013 20:30  |
wlandsman
Messages: 743
Registered: June 2000
|
Senior Member |
|
|
On Thursday, February 28, 2013 10:52:42 PM UTC-5, timoth...@gmail.com wrote:
> ; The reason for doing this is so that if a user has their own
>
> ; STRSPLIT in their local user library, their version will superceed
>
> ; this one. RSI does not recommend this practice, but it is
>
> ; allowed for backwards compatability reasons. ...
>
>
>
> This seems a bit messy.
It's definitely messy, but I am not aware of other examples like it,. Thirteen years ago, RSI was overeager to respond to a user complaint that the new STRSPLIT function name stepped on an existing user function name. The solution of having a STRSPLIT wrapper around a new intrinsic function STRTOK() made things permanently more messy, but the mistake has not been repeated as far as I know.
But the situation could startle a user, unaware of the undocumented STRTOK(), who wrote a simple function
function strtok,x
return,x
end
and then finds
IDL> print,strtok(3)
7
I'll leave the question of why strtok(3) -- or strsplit(3) -- has a value of 7 as an exercise for the reader.
--Wayne
|
|
|
|
|
|
| Re: Undocumented functions in IDL [message #83424 is a reply to message #83348] |
Fri, 01 March 2013 07:43 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
On Friday, March 1, 2013 6:09:29 AM UTC-5, timoth...@gmail.com wrote:
> I have to disagree entirely. I hear the I dont care about how it works I just want to get the job done over and over from scientists I work with. The problem is they end up writing code that takes them longer to finish then is almost impossible to maintain. I would hardly call that a triumph. When I'm asked to do something they are often amazed at how fast I can accomplish it. My problem is not with IDL itself its that SOME of the people that use it as wasting more time trying to work on maintaining horrible code than investing the small amount of time to learn how to do things properly to begin with.
There are often priorities *other* than having one's code run as fast as possible.
Thank you for your interest in IDL.
CM
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
