SPUG: idioms of late

Fred Morris m3047 at m3047.net
Tue Jan 19 10:55:08 PST 2010


On Monday 18 January 2010 15:39, Joshua Juran wrote:
> [...]
> First of all, let me note that your use of /o does nothing [...]

Let it do nothing, then, but to mark the expression as invariant.

> I hope this sort of critique is what you were looking for.

Sure. Yah, same concerns about "efficiency". There are different kinds of 
efficiency.

They would frown, I think, more on things like "s/x/y/ for @a" where I work. 
Plus my example only included a single (contrived) modification, I didn't 
want to share actual code. In any case, our computational limitations are not 
CPU. I like the pythonic "look" of doing something inside of "[ ]". Of course 
if it smites your eye I suppose (haven't tried it) you could "do {} for @a". 
I am not claiming one is more "elegant" than the other (eliding the implied 
"liking"), just that having programmed in a number of languages, one is more 
pleasing to my eye than the other.

Also $x->{a} = [ f($x->{a} ] does indeed replace the original $x->{a} 
*reference*, just in case someone else needs the reference unmunged somewhere 
else.

I wish preparing SQL statements made more sense in our processing environment, 
but mostly it doesn't for reasons which are complicated to go into. We don't 
write mega-epic perl scripts (or we try not to but accept failure), we try 
and write smaller things which do something and then go away (oftentimes that 
"thing" has nothing whatsoever to do with the database and is very large) so 
preparing SQL statements has limited (f)utility.

Actually I don't know the answer to this: does preparing statements when using 
MySQL+InnoDB do anything to reduce disk I/O, or is it just reducing CPU 
overhead?


BTW, my first language was Pascal, and my second was MACRO-32 running on 
VAX/VMS (I wrote an entire RSTS block I/O emulator engine with interprocess 
locking support for VAX/VMS in MACRO-32, with a management API in BASIC of 
all things). If something really needed to be computationally efficient, I'd 
probably write it with Inline::C... I've done it before.

--

Fred


More information about the spug-list mailing list