Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
On Friday, March 1, 2013 2:29:42 PM UTC+11, timoth...@gmail.com wrote: > I have a question for the IDL developers about an undocumented functions in IDL. While I'm fairly new to IDL I'm maintaining IDL code that was written before I even knew the language existed. Up until now I had assumed the function was implemented in our code somewhere (due to the IDE not highlighting it) until I went searching for it today. > > > > I find it strange enough that IDL even has hidden functions considering it only has a single namespace. > > Anyway I my question is about the strtok() function. Do you guys have any plain to document this feature? As far as I can tell it has existed in IDL versions for at least 13 years that seems like more than enough time to make sure its stable and after a quick google search it seems like its hardly unknown. > > > > Or should I be using STRSPLIT? What is the difference between the two? > > > > Thanks, > > Tim After some more googling it turns out they are the same thing. One documented, one undocumented. ;+ ; NAME: ; STRSPLIT ; ; PURPOSE: ; Wrapper on the build in system routine STRTOK that implements exactly ; the same interface as STRTOK, but with the STRSPLIT name. ; ; 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.
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
timothyja123@gmail.com writes: > This seems a bit messy. Well, as you say, you haven't been working with IDL long. ;-) 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.")
wlandsman writes: > 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. Ah, the good ol' days! Life was so much simpler then. :-) 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.")
> 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. From what I've read the STRTOK() solution just stepped on another librarys function name anyway. Very amusing.
> Well, as you say, you haven't been working with IDL long. ;-) I dont mean to insult anyone but its already to long :-) I'm a programmer not a scientist and the things I've seen scare me. Not just the language itself but the code produced by people who havent been tought the basic principals of software design. Its sad to think of how much cpu processing time is wasted by such programs. Anyway its been an interesting insight to say the least.
timothyja123@gmail.com writes: > I dont mean to insult anyone but its already to long :-) I'm a programmer not a scientist and the things I've seen scare me. Not just the language itself but the code produced by people who havent been tought the basic principals of software design. Its sad to think of how much cpu processing time is wasted by such programs. Anyway its been an interesting insight to say the least. I think you miss the point about IDL. It was never meant to be a superior programming language. It was meant to be something scientists could use to get their job done. The crappy programs are actually testament to that. How many other languages would allow you to write awful programs that still work? IDL is a triumph, not a disaster. :-) 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.")
> I think you miss the point about IDL. It was never meant to be a > > superior programming language. It was meant to be something scientists > > could use to get their job done. The crappy programs are actually > > testament to that. How many other languages would allow you to write > > awful programs that still work? IDL is a triumph, not a disaster. :-) > > > > 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.") 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.
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.")
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