Re: Python or Perl for a Debian maintainance project?
Hi, Andrew Suffield wrote:
>> Files, for instance, are objects in Perl. Except when they're GLOBs,
>> wait, OK, except when they're references to GLOBs. :-P There's no sane
>> way (one or two less-than-sane ones, though) to write a program which
>> accepts all three of these.
>
> It's your own stupid fault if you use typeglobbed filehandles; there's no
> reason for it.
>
I'd say that it's the language designer's fault to offer three
incompatible implementations of "file". There's no reason for it.
I know, Perl's very mantra is that there's more than one way to do it
-- but that's the point. You do it this way, I do it the other way,
and now my part of the program and yours need to work together. Ugh.
>> There's no sensible way to figure out whether file-thing A and
>> file-thing B refer to the same file descriptor / string-used-as-a-file /
>> whatever.
>
> $a->fileno == $b->fileno
Thank you for proving my point. I _said_ "string-used-as-a-file".
>> Arrays and hashes are not objects.
>Why should they be?
Because you'd want to subclass them by attaching methods, or some other
sort of attribute to them?
>And making numbers objects is a dumb idea
Proof by assertion?
Speaking of dumb ideas, I could say, with at least equal justification,
that Perl's principle of implicitly treating strings like numbers and vice
versa is WAY more stupid, because it directly causes dumb programmer
mistakes. I'm sure (based on your other statements in this thread) that
_you_ never use != when you compare strings in Perl, but others either
aren't as lucky, or decided to use programming languages where that
mistake cannot happen in the first place.
>The point of tie is to make objects look like non-objects. Not the other
>way around. You seem to have missed that point.
No I didn't. The point was that if they were all objects, you wouldn't
need the silly tie() in the first place.
>> Perl doesn't have class variables,
>
>Don't be silly, of course it does. It's just a lexical in the class
>package.
... except that it's not inheritable and you can't easily refer to it from
outside the class, given an object. Some other languages don't share these
problems.
>Classes are a design feature. Not an implementation feature. Define what
>it means for a language to "have classes", and justify why anybody should
>care about that definition.
As a programmer, I could care less about definitions. I care about whether
the way I want to code is a subset of the list of features the language
offers, and how nonintuitive the resulting code looks when I need to
implement workarounds for the features it doesn't offer.
Perl fits _my_ brain admirably well for small code snippets. It fits less
and less well for larger pieces of code.
YMMV.
--
Matthias Urlichs
Reply to: