I don’t think it’s as awful as that; Python is a widely-known, widely-used, and well-documented language and freely available. I worry more about Perl, because it is so easy to create write-only code in Perl and this becomes a maintenance problem.
On the other hand some Unix commands are becoming obsolete. I use awk and csh and wonder how long they will last. Like languages, computing environments change over time. The justification for the various interpretive languages is development speed and (mostly) ease of maintenance; one can probably write most things in Python in 1/10th the time it takes to write them in C, and with modern computers so fast, you may never actually have to write the code in C, or at least put that step off for some time. If your first version is adequate, why fiddle with it? There is some effort at bridging the productivity gap between compiled and interpreted languages. Unfortunately that work has not so far reached scientific and engineering computing. We’re still using FORTRAN for some things! Randolph > On Mar 22, 2016, at 9:48 AM, Gregory J. Ward <gregoryjw...@gmail.com> wrote: > > Real quick: > >> From: "Guglielmetti, Robert" <robert.guglielme...@nrel.gov> >> Date: March 22, 2016 9:37:46 AM PDT >> >> Eh, I respectfully disagree, here. Languages like Python and Ruby are >> making it easy for meatheads like me to write functional cross-platform >> programs that can leverage Radiance tools well, and offer users niceties >> like command line help, threading, queuing, etc. One could write these >> with minimal library support and blow off making functions where they make >> sense and leave one with a very linear, readable (and maintainable) >> program. On the other hand, wrapping a few redundant bits into a function >> here and there makes it cleaner, easier to maintain, and IMO does not come >> anywhere close to the price of admission of writing the same shit in C or >> C++.(!) > > I wasn't arguing against defining your own functions or encapsulation -- just > heavy reliance on add-on libraries. The former just keeps the code neat, > moving repeated or complicated calls to another part of the script. The > latter means you have to go learn about some library you never heard of and > study it to figure out what the script is even doing. Arguments about > obviousness notwithstanding, you can't debug a program you don't fully > understand. > > -G > _______________________________________________ > Radiance-dev mailing list > Radiance-dev@radiance-online.org > http://www.radiance-online.org/mailman/listinfo/radiance-dev _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
