Perl 5's OO system could use some more syntactic sugar. It leaves a little too much of the detail exposed.
On the plus side, Perl 6 should be out sometime this decade, and it addresses this. (IMO, P6 goes a bit too far the other way, though, with a full-blown C++-like public/private system. But even so, it's nicer than P5.)
Perl's memory management is its worst feature. A running Perl process never gives memory back to the operating system after it's been garbage collected, but reserves it for itself. For some reason it seems that it looses track of some of the memory it's reserved for itself as well.
In practice this means that you can't just leave a perl process running as a daemon or whatever, but rather have to constantly spawn new processes which just do one little thing, and then end.
The situation in which I first saw this was with a mod-perl based CMS. The processes were growing out of control and would eventually consume all of physical ram and swap and bring down the machine. We solved it by causing Apache to kill a child with a memory footprint of more than a certain size.
Anyhow, I think the OO syntax of Perl is a little funny and overexposed, but perfectly useable. The memory management stuff on the other hand is pretty durned annoying.
That sounds like a GC leak to me. Perl 5 uses reference counting GC (ugh), so any circular references that aren't broken by hand with "undef" never get recycled. That's yet another wart that's due to be fixed in Perl 6.
I think the "never return memory to the OS" thing is construed as a feature, on the basis that long-running processes are going to cycle through an allocate-release, allocate-release pattern, and frequent OS-level allocation can get expensive. That, and Perl 5 was originally written back in the days when most *nixen were using brk(2), which didn't let any program return allocated memory to the OS. (Yay for mmap!)
Discussion (6)
sub new() {
my $self = {};
$self->{NAME} = undef;
$self->{AGE} = undef;
$self->{PHONE} = undef;
bless $self;
return $self;
}
#How retarded is that???
Perl 5's OO system could use some more syntactic sugar. It leaves a little too much of the detail exposed.
On the plus side, Perl 6 should be out sometime this decade, and it addresses this. (IMO, P6 goes a bit too far the other way, though, with a full-blown C++-like public/private system. But even so, it's nicer than P5.)
Perl's stupid lexer is the worst thing about it. It must be the most exception driven lexer ever.
Perl's memory management is its worst feature. A running Perl process never gives memory back to the operating system after it's been garbage collected, but reserves it for itself. For some reason it seems that it looses track of some of the memory it's reserved for itself as well.
In practice this means that you can't just leave a perl process running as a daemon or whatever, but rather have to constantly spawn new processes which just do one little thing, and then end.
The situation in which I first saw this was with a mod-perl based CMS. The processes were growing out of control and would eventually consume all of physical ram and swap and bring down the machine. We solved it by causing Apache to kill a child with a memory footprint of more than a certain size.
Anyhow, I think the OO syntax of Perl is a little funny and overexposed, but perfectly useable. The memory management stuff on the other hand is pretty durned annoying.
That sounds like a GC leak to me. Perl 5 uses reference counting GC (ugh), so any circular references that aren't broken by hand with "undef" never get recycled. That's yet another wart that's due to be fixed in Perl 6.
I think the "never return memory to the OS" thing is construed as a feature, on the basis that long-running processes are going to cycle through an allocate-release, allocate-release pattern, and frequent OS-level allocation can get expensive. That, and Perl 5 was originally written back in the days when most *nixen were using brk(2), which didn't let any program return allocated memory to the OS. (Yay for mmap!)
[who used to agree:]
The OO stuff is a mess, it's true, but on further consideration it's not the worst thing.
D'A