On Saturday, Sep 21, 2002, at 01:41 US/Pacific, RP C987342 wrote:
[..]
>> That solve you then need to resolve what 'performance' really
>> means - are you counting cycles? at the code monkey end or the
>> cpu end???
>
> cpu end.
p0: first off thank you for forbearing on the bit of tongue in cheek -
as there are people who are more concerned with the 'time to market'
rhetoric - and consider that an imperative 'metric of performance'.
> Being a Java/C++ programmer mostly, I find perl very interesting
> mainly as it lets you do a lot in short time. But I find Perl as
> more as a declarative kind of programming language than the
> procedural ones like c/c++/java - In Perl you write *what* has to be
> done and in C/... you also write *how* it has to be done. And since,
> Perl lets you do one thing in many ways (for eg, two regular
> expressions
> can define same language), some of them might be better than the
> others - which one to choose.
p1: this is an interesting perspective on how you see perl
as being distinct from the other languages you have coded in.
Where as I come from the more traditional side of c and /bin/sh
and hence view it in twin cases of
1.a - an imperative scripting language
{ imperative both in the computational model, as well
as the fact that you just have to have it in the bag
of basic tools you need. }
1.b - a whole lot simpler to prototype in than the usual
type
compile
debug
re-type
models that come with C/C++/Java/....
except of course when one finds that one has wandered into
needing and using perl modules....
> In java, I would be careful in choosing a vector vs arraylist.
which you should keep with you in perl - as you work out
how in detail you wish to be about what types of data structures
you really want to use - and when you wish to manage the problem
and when you do not want to manage the problem
> In c/..., arrays have fixed length. In perl, when I say
> my @arr = <STDIN>;
> I do not (or cannot?) specify the length of the array even when
> I know it has only 15 elements.
this is a feature or bug of allowing dynamic scoping and sizing
of variables...
As a general rule of thumb I try to avoid the
my @list = <FH>;
constructs - for the 'uncontrolled' problem you are presenting.
In a 'well behaved' environment of course it will only have
15 elements - in this case 15 lines of data.... what you will
find useful is the while iterative style
while(<FH>) {
# do what must be done here
}
let's say you wanted to control for ONLY 15 lines you might have
my $index=0; # so we do not initialize IN the loop... 8-)
my $max = 15; # allows this to change and the while to stay the same
# code maintenance v. actual loop efficiency
v. mem usage ???
my @list = ();
while(<STDIN> ) {
chomp; # take off the silly eof for this system
if ( $index++ < $max ) {
push(@list, $_);
} else {
die "we do not take more than $max lines of input \n";
}
}
Remember that in C/C++/Java - you would also need to
make sure that you do not attempt to address a memory
space 'beyond' what was malloc'd - and would of course
have some similar structure to check that you are not
attempting to go beyond the end... eg something like:
if ( ! this.isTop() ) {
this.add(item);
} else {
throw this.isFullError;
}
> So, what I want is about such issues in Perl, if any, that I have to
> be aware of when writing programs in perl.
given your basic high level of understanding about coding you
will probably find
http://perl.plover.com/FAQs/Namespaces.html
a very useful starting point as to how to 'scope' your variables
in a way that doesn't spend un-needed time doing stuff with them...
one of the things you will find useful is
perldoc perl
will get you the current 'perl documentation' index that came
with the version of perl that you are using....
in particular you will want to feel at home with
perldoc perldata # data structures
perldoc perlsyn # syntax
perldoc perlop # operators and precedence - mostly boring but...
perldoc perlfunc # builtin functions
perldoc perlvar # predefined variables
perldoc perlsec # security related issues
as the basic documentation of the basics - some of which will as noted
above - be mostly boring in that you already understand the basic data
types and the way that other languages prevent you from doing the
sillies.
I'm sure you recall the need to check input prior to calling things like
sprintf(buf, format, input);
before there was snprintf(3) that would put no more than n bytes of
input
into buf - you will, as you noticed above, that perl will allow you to
do things that are, well, not as safe...
as previously noted
perldoc perlstyle # for the general perl coding style guides.
The two most important rules are
- be consistent
- be nice
since, the former allows you the excuse when you need it,
"it seemed like a good idea at the time to just do it that way,
since we just needed to get it out the door...."
and the later, the chance to laugh at your youthful indiscretions.
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
