I don't think Perl is necessarily write-only, but it is easy to produce write-only code in it.
"Although I don't have a ready solution, it would be good to at least determine the parameters of the problem." Does anyone have an example? When I get a bit more time, I could look into it. -- Randolph M. Fritz, Lighting Design and Simulation +1 206 659-8617 || rmfri...@gmail.com On Tue, Mar 22, 2016 at 4:04 PM, Gregory J. Ward <gregoryjw...@gmail.com> wrote: > > From: Georg Mischler <schor...@schorsch.com> > > 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 > without. > > 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 > for me. > > >> 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.) > > Cheers, > -Greg > _______________________________________________ > 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
