comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: One Reason Python is not taking over for IDL
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: One Reason Python is not taking over for IDL [message #78759] Wed, 21 December 2011 09:16 Go to next message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Russell writes:

> I'm willing to believe that Python is a better language, but never
> because it's cheaper. I'm willing to pay for a product that works.

Humm. What do we say, then, about IDL 8.x? :-(

Cheers,

David



--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: One Reason Python is not taking over for IDL [message #78760 is a reply to message #78759] Wed, 21 December 2011 09:08 Go to previous messageGo to next message
Russell[1] is currently offline  Russell[1]
Messages: 101
Registered: August 2011
Senior Member
I have rejected Python time and time again, because I find I spend so
much time tracking down compatibility issues. Which is *ALL* after
the nightmare installing the bloody software.

Personally, I think this goes back to the recent surge for Mac OSX.
Scientists are migrating to Mac (and holding onto their IDL), because
you get what you pay for. Sure those things cost more money than
their alternatives (Python v IDL, Linux v Mac), but what you pay for
in dollars --- you make up with ease of use, reliability, and global
infrastructure. I have little doubt that one day, Python will be as
attractive to me as IDL --- and I might begrudgingly join the Dark
Side (such as I'm hired to work in Python-land).

I'm willing to believe that Python is a better language, but never
because it's cheaper. I'm willing to pay for a product that works.

Russell


On Dec 21, 11:33 am, David Fanning <n...@dfanning.com> wrote:
> Folks,
>
> Here is one (probably the main) reason Python is not taking
> over for IDL:
>
>   http://software-carpentry.org/2011/12/it-just-keeps-on-hurti ng/
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.idlcoyote.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: One Reason Python is not taking over for IDL [message #78848 is a reply to message #78759] Wed, 21 December 2011 12:31 Go to previous message
Russell[1] is currently offline  Russell[1]
Messages: 101
Registered: August 2011
Senior Member
I've recently graduated to IDL >8 (specifically 8.1), and for the most
part everything is in good shape. I don't, on the other hand, use
many of the new features and largely still do things "the old
fashioned way" (e.g. using things like the procedural plotting
routines) because I work closely with people who are still using IDL
7.x and we share code. I'm anxious to learn about the new features
(and bugs), when my collaborators catch up!

I did have to change a few minor things --- but all of them are
backwards-compatible. But it was readily apparent what the problem(s)
are/were.

R

On Dec 21, 12:16 pm, David Fanning <n...@dfanning.com> wrote:
> Russell writes:
>> I'm willing to believe that Python is a better language, but never
>> because it's cheaper.  I'm willing to pay for a product that works.
>
> Humm. What do we say, then, about IDL 8.x? :-(
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.idlcoyote.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: reading shapefiles & IDL objects
Next Topic: Re: Problem with the astron database on Mac OS X

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 13:40:18 PDT 2025

Total time taken to generate the page: 0.68989 seconds