> From: Georg Mischler <firstname.lastname@example.org>
> Date: March 22, 2016 12:30:46 PM PDT
>> 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.
> There are (at least) two different classes of "scripts" in Radiance.
> Some are indeed little more than a listing of a few commands, and
> in a few cases it looks like they were one-off solutions to a very
> specific problem. Most people will never use those, or they might
> create their own versions. It may or may not be worth to convert
> them, and in some cases the Python version may actually become a
> literal translation without any added structure.
OK, I suppose I would have to see an example of that, preferably something
that wasn't organized around a class. One of the things I have always
disliked about C++ is how you have to dig around in the headers to figure
out what the heck the code is doing. Python at least keeps it together,
but it's still a mess in the sense that the code layout has little to do
with control flow. It's an extra hurdle to understanding I could do
There's still the issue of all the supporting libraries, their many
classes and associated methods.
> The other class are programs like falsecolor or genBSDF, which are
> far beyond that "script" stage. Those are "real" programs in the sense
> that they solve tasks that most people will be confronted with
> regularly. This makes them unlikely to change very significantly over
> time, other than to add features. In those cases, the effort is
> clearly justified to design an object oriented structure and add all
> the bells and whistles most users expect from a complete tool.
Never mind that I just rewrote genBSDF almost from scratch last year when
I introduced rfluxmtx and wrapBSDF with color support, which simplified the
code substantially (and required numerous changes in structure). I was
hoping not to have to do that again, of course....
> You seem to think that object orientation will necessarily make a program
> inflexible. Well, for Java and C++, this is indeed usually the case.
> But it doesn't have to be like that. A well crafted object oriented
> design will make adding features easier, not harder. And Python is one
> of the rare languages, where changing the code is actually fun, and
> not something to be scared of.
> This ease of maintenance is also one of the reasons why those things
> should rather *not* be converted to C. There's simply no need to do that,
> as long as we can delegate the number crunching to other tools.
Certain things are definitely easier in a scripting language, or they
wouldn't be useful. Being able to manipulate strings and build command
lines are the most important facilities. Having some ability to do math
and store arrays are also valuable features. Perl and Python are both
superior to the C-shell in that respect, so I agree with you about the
importance of having a decent language for more sophisticated tools.
However, I don't see how Python is less work than Perl given the examples
I've seen. Why not Ruby? Why not any of the other myriad languages out
there? You have your favorite; I have none. I simply went with something
that was familiar and supported, and don't feel like changing canoes
midstream as the expression goes.
>> 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.
> If you look at Python, you'll find that all that is (or can be) the
> case there as well, just without the uglyness.
As I said, I would have to see a simple example. Your rlux.py ended up
being a bit more complex than its C-shell progenitor... As for ugliness, I
don't really see the differences you do. I have employed languages like
TCL, which I do consider write-only (to use Randoph's term), but Perl is OK
>> Scripting languages need to be easy to write and easy to read to be
>> useful in my opinion.
> But you're still full of praise for Perl...?
I do find Perl easy to read compared to Python, mostly because I don't
have to jump around the class methods or read up on the add-on libraries.
There are plenty of functions in Perl, no doubt about that, but they aren't
such a growing concern.
>> Also, relying heavily on add-on libraries comes at a cost, which is
>> expanded vocabulary one must learn.
> Libraries coming included with the language are not "add-on".
> We won't get any bonus points for reinventing the wheel, or for
> dragging stuff around instead of wheeling it.
I'm not saying we need to reinvent the wheel every time, but we could do
without so many wheels. Perhaps it's just a matter of restraint and paring
add-on libraries to a minimum. I don't know.
>> We chain up to 4 commands in genBSDF, which I guess will translate to
>> call_four() in your library?
> We're going to have a call_many() then, which will accept and chain an
> arbitrary number of commands. Win_popen() already does that.
OK, I guess that would work.
>>>> We'd still have to switch between data format (-f*)
>>>> command options on the two platforms, or suffer significant
>>>> performance penalties on Unix.
>>> Sorry, not sure what you're talking about there.
>> 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.
> That sounds like a severely broken implementation. I can't possibly
> imagine this still to be the case. If there's a test case, I'll check
> it out.
I don't own a Windows box, so it's difficult for me to produce test
cases. I only hear complaints from people about certain commands not
behaving with binary data on Windows, even when it doesn't go into an
intermediate file. In other words, piping the binary output of one command
into another still screws up. Does Windows create a temporary file when it
does this? Maybe if it's on a FAT filesystem (as Randolph mentioned), this
is the source of the problem. It would be nice to track this down.
Although I don't have a ready solution, it would be good to at least
determine the parameters of the problem. (Radiance's binary files are
immune: octrees, HDR pictures, triangle meshes, even binary matrix data --
it's just the raw IEEE floats & doubles that usually mess up.)
Radiance-dev mailing list