This is getting good... On 3/22/16, 10:02 AM, "Gregory J. Ward" <gregoryjw...@gmail.com> wrote:
> >Thinking on it some more, the main issue I have with Python is probably >the object-oriented structure, which moves it even further from a >command-line interpreter. For me, the main benefit of using a scripting >language is that it is close to the command-line, which is where Radiance >(mostly) lives. If you introduce too much structure, you're getting back >to something resembling a C program, and you may as well just write it >that way, instead. > >Perl looks a lot like traditional interpreter shells with the added >benefit of more useful built-in commands and expression evaluation. You >can open a Perl script and read through it like you're reading a sequence >of commands. User-defined functions have a bare-bones call structure and >don't have to be defined before they're used, so they don't interrupt the >flow as you read through the code. Scripting languages need to be easy >to write and easy to read to be useful in my opinion. They don't have to >be beautiful. > >Also, relying heavily on add-on libraries comes at a cost, which is >expanded vocabulary one must learn. We get by in Perl with just one >library for making temp files, I think, and that was added to avoid some >of the system incompatibilities with Windows and is only called in a >couple of places. 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++.(!) >Well, we may need to devise some tests to be sure this is still a >problem, but in the past, Windows would deliver binary files in 128-byte >chunks, meaning that the last chunk might have garbage at the end of it >that was not actually produced by the program that sent it. So long as >the receiving program knows exactly how much data to expect, which is >frequently the case, there is no problem. However, if the receiving >program is counting bytes to see how much data it gets (like rcalc, >total, etc.) then it screws up the results, which is why we've been >sticking with ASCII data in Windows despite the horrendous overhead >translating between ASCII and IEEE floating-point. This was still a problem last year when I was writing the Radiance-OpenStudio stuff, and is a major roadblock for doing large scale analysis with Radiance on Windows, I'm finding. =( _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
