This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: rat_tank@yahoo.com (Rat Tank)
Newsgroups: comp.lang.perl.misc
Subject: Re: Attitude to Perl in academia
Date: 31 Jan 2003 07:14:00 -0800
Uri Guttman <uri@stemsystems.com> wrote:
> >>>>> "RT" == Rat Tank <rat_tank@yahoo.com> writes:
>
> huh? perl has no typing system as do most other languages. so how can
> you dreive one?
Actually, I think you'll find that Perl does have a typing system,
but it's of the form of languages like ML or Smalltalk; it's an
implicit typing system. The programmer may well not know the exact
type, but the underlying compiler does have a concept of the type of
each symbol, and infers it automatically at runtime from context.
Because the type is hidden, that makes it even more severe that the
Perl typer has PROVABLE BUGS. Such un-typesafeness can result in
garbage casts, and worse yet, regular buffer overflows.
> RT> It is most certainly _not_ Turing complete (trivially provable);
> RT> hence not all algorithms can be implemented in it that you could with
> RT> a Turing complete language like Java or C(++).
>
> that is total crap. i don't know where you learned about state and
> turing machines but it is hard to find a common programming language
> that isn't turing complete. all you need is a single array, a few state
> variables and some simple boolean logic.
I don't think you quite understand the subtle concept of Turing
completeness. Perhaps you'd care to post a simple program (in Perl)
that simulates a Turing machine (plus the other requirements for
Turing completeness). I think you'll find that Perl doesn't implement
the recursive structures required.
> RT> Perl's reference counting system of garbage collection can
> RT> sometimes result in memory leaks, as opposed to the more thorough
> RT> graph traversal employed in other languages.
>
> that is a known thing and can be handled if you know how to deal with
> circular refs. and if you emply them, you should know how to destroy them.
The point of garbage collection is that one shouldn't have to
destroy things manually. This isn't a rare occurence either; Perl
regularly uses circular refs in such common structures as hashes and
arrays, and memory leaks are therefore quite frequent.
===
From: peter@PSDT.com (Peter Scott)
Subject: Re: Attitude to Perl in academia
Newsgroups: comp.lang.perl.misc
Date: Fri, 31 Jan 2003 15:30:04 GMT
rat_tank@yahoo.com (Rat Tank) writes:
>Uri Guttman <uri@stemsystems.com> wrote:
>> >>>>> "RT" == Rat Tank <rat_tank@yahoo.com> writes:
>> RT> It is most certainly _not_ Turing complete (trivially provable);
>> RT> hence not all algorithms can be implemented in it that you could with
>> RT> a Turing complete language like Java or C(++).
>> that is total crap. i don't know where you learned about state and
>> turing machines but it is hard to find a common programming language
>> that isn't turing complete. all you need is a single array, a few state
>> variables and some simple boolean logic.
> I don't think you quite understand the subtle concept of Turing
>completeness. Perhaps you'd care to post a simple program (in Perl)
>that simulates a Turing machine (plus the other requirements for
>Turing completeness). I think you'll find that Perl doesn't implement
>the recursive structures required.
http://search.cpan.org/author/GROMMEL/Acme-Turing-0.01/Turing.pm
Uri was being generous.
===
Newsgroups: comp.lang.perl.misc
Subject: Re: Attitude to Perl in academia
From: Uri Guttman <uri@stemsystems.com>
Date: Fri, 31 Jan 2003 16:30:30 GMT
>>>>> "RT" == Rat Tank <rat_tank@yahoo.com> writes:
RT> Uri Guttman <uri@stemsystems.com> wrote:
>> >>>>> "RT" == Rat Tank <rat_tank@yahoo.com> writes:
>>
>> huh? perl has no typing system as do most other languages. so how can
>> you dreive one?
RT> Actually, I think you'll find that Perl does have a typing system,
RT> but it's of the form of languages like ML or Smalltalk; it's an
RT> implicit typing system. The programmer may well not know the exact
RT> type, but the underlying compiler does have a concept of the type of
RT> each symbol, and infers it automatically at runtime from context.
RT> Because the type is hidden, that makes it even more severe that the
RT> Perl typer has PROVABLE BUGS. Such un-typesafeness can result in
RT> garbage casts, and worse yet, regular buffer overflows.
you are blathering. perl does not do any compiler work at runtime
(unless you call eval). there is compile time and there is runtime. perl
variables can hold any form of a scalar value. the compiler has no way
to change that at any time. as for the claim about the perl typer and
its 'bugs', i never heard of a perl typer. the type of a value isn't
hidden and it can be easily found with a module but it is almost never
needed by the coder. perl (correctly) handles conversions and without
buffer overruns. i don't know where you are getting this misinformation
from.
>> that is total crap. i don't know where you learned about state and
>> turing machines but it is hard to find a common programming language
>> that isn't turing complete. all you need is a single array, a few state
>> variables and some simple boolean logic.
RT> I don't think you quite understand the subtle concept of Turing
RT> completeness. Perhaps you'd care to post a simple program (in Perl)
RT> that simulates a Turing machine (plus the other requirements for
RT> Turing completeness). I think you'll find that Perl doesn't implement
RT> the recursive structures required.
huh? you are bonkers. the stupidest basic is turing complete. and
please don't insult my knowledge of turing stuff. ever heard of the book
'computation: finite and infinite state machines' by marvin minsky? try
reading it sometime to actually learn about turing machines. in there he
shows the smallest universal turing machine (which minsky discovered)
and it only has about 4 variables and 6 states plus the infinite tape. i
think perl can handle that level of complexity.
>> that is a known thing and can be handled if you know how to deal with
>> circular refs. and if you emply them, you should know how to destroy them.
RT> The point of garbage collection is that one shouldn't have to
RT> destroy things manually. This isn't a rare occurence either; Perl
RT> regularly uses circular refs in such common structures as hashes and
RT> arrays, and memory leaks are therefore quite frequent.
perl itself never uses circular references. perl programs may use them
but by far the majority of them don't. circular references are not a
common design requirement and if you think they are, you must be in a
tangled hierarchy yourself.
i am only writing this to make sure others who read this thread don't
fall for your line of hooey. i don't care what you think about perl
(which is way off base) but i do care what others will read.
===
From: Benjamin Goldberg <goldbb2@earthlink.net>
Newsgroups: comp.lang.perl.misc
Subject: Re: Attitude to Perl in academia
Date: Fri, 31 Jan 2003 23:50:26 -0500
Rat Tank wrote:
> Uri Guttman wrote:
> > >>>>> "RT" == Rat Tank <rat_tank@yahoo.com> writes:
> > huh? perl has no typing system as do most other languages. so how
> > can you dreive one?
>
> Actually, I think you'll find that Perl does have a typing system,
> but it's of the form of languages like ML or Smalltalk; it's an
> implicit typing system.
No -- with ML and Smalltalk, every variable's type is inferred *at the
time that the function is typed in*... in other words, at compile time.
At runtime, you must pass a variable of the appropriate type to the
function.
In perl, there is no such compile-time typing. A scalar variable
(something like $scalar), or a scalar element of an array or hash (that
is, $array[$n], or $hash{$key}) has *no* compile-time type attached to
it.
Scalar variables can be simple-scalars (undef(), or a number or a
string), or they can be references to other structurs (a ref to a
scalar, or a ref to a hash, or a ref to an array, or a ref to a
subroutine).
(I'm ignoring dual-type vars like $!, and typeglobs, for the sake of
simplicity)
> The programmer may well not know the exact type,
perldoc -f ref
> but the underlying compiler does have a concept of the type of
> each symbol, and infers it automatically at runtime from context.
I don't think that "infer" is the right term -- instead, say that the
interpreter will *coerce* a variable to the appropriate type.
If you use a string as a number, it numifys the string. If you use a
number as a string, it stringifies the number. If you use a reference
of some sort as a string, it gets stringified. If you use a string as a
reference, it will (if 'use strict' isn't enabled) fetch the appropriate
variable from the symbol table, and thus use the string as a reference.
> Because the type is hidden, that makes it even more severe that the
> Perl typer has PROVABLE BUGS.
Show us one of these "provable bugs" and perhaps we'll believe you.
> Such un-typesafeness can result in garbage casts,
Like what?
> and worse yet, regular buffer overflows.
Show us a perl program where "un-typesafeness" causes a buffer overflow.
[snip nonsense about Turing Completeness, where OP demonstrates his
complete and utter ignorance]
> > RT> Perl's reference counting system of garbage collection can
> > RT> sometimes result in memory leaks, as opposed to the more
> > RT> thorough graph traversal employed in other languages.
> >
> > that is a known thing and can be handled if you know how to deal
> > with circular refs. and if you emply them, you should know how to
> > destroy them.
>
> The point of garbage collection is that one shouldn't have to
> destroy things manually.
The point of garbage collection is to free the programmer from *most* of
the nuisances of freeing things manually. There is no magically gc
which can automatically free *everything* which is unused.
For example, consider this Java program:
public class Foo {
public static void main(String[] argv) {
int unused[] = new int[100000];
do_other_stuff_without_that_unused_thingy();
}
}
If you had a magic gc, it would free up those hundred-thousand ints
immediately, knowing that they wouldn't be used. Instead, they aren't
going to ever get freed until the program exits. To force them to get
freed in a timely manner, you would have to do 'unused = null;' before
do_other_stuff_...().
> This isn't a rare occurence either; Perl regularly uses circular refs
> in such common structures as hashes and arrays,
No, it doesn't.
Show me even one standard module where circular refs are used.
> and memory leaks are therefore quite frequent.
Pfff.
===
From: Bart Lateur <bart.lateur@pandora.be>
Newsgroups: comp.lang.perl.misc
Subject: Re: Attitude to Perl in academia
Date: Sun, 02 Feb 2003 13:22:32 GMT
Pierre Asselin wrote:
>Benjamin Goldberg <goldbb2@earthlink.net> writes:
>>Show me even one standard module where circular refs are used.
>There are such modules in CPAN, for example
>HTML::TreeBuilder. Their documentation warn about the
>circularity and they provide ->delete() methods to reclaim
>the memory.
In such cases, the new tool utility to make references weak, can fix
that. Make the parent reference the child with a normal (hard)
reference, link back from the child to the parent with a weak reference,
and you no longer have to think about it any more.
Weak references were introduced in the module WeakRef, but later, it has
been assimilated into Scalar::Util.
===