Prev: FAQ 6.16 How can I do approximate matching?
Next: FAQ 4.4 Does Perl have a round() function? What about ceil() and floor()? Trig functions?
From: bugbear on 11 Jun 2010 11:11
Peng Yu wrote:
> On Jun 9, 12:18 pm, Charlton Wilbur <cwil...(a)chromatico.net> wrote:
>>>>>>> "PY" == Peng Yu <pengyu...(a)gmail.com> writes:
>> PY> But I doubt that having multiple ways of doing the same thing
>> PY> really give us any advantages over other languages.
>>
>> The culture in which Perl has developed for the past couple of decades
>> embraces "TIMTOWTDI" - "there is more than one way to do it." See the
>> entry in the glossary of Programming Perl, 3rd ed., on page 1005.
>>
>> Other languages' cultures prefer that there be one correct way to do
>> things; if that's what you prefer, then you'll probably be happier with
>> another language.
>
> According to Programming Perl, more than one way may not always be
> better. But I just don't see more than one way is better at all.

Doesn't matter. For backwards compatibility reasons
I strongly doubt that "surplus" features are going
to be removed from Perl, even if we could
design/agree an elegant and efficient minimum spanning set.

BugBear
From: hymie! on 11 Jun 2010 11:12

In our last episode, the evil Dr. Lacto had captured our hero,
Peng Yu <pengyu.ut(a)gmail.com>, who said:

>my @lines;
>my $limit = 3;
>for my $line(0..$limit-1) {
> $lines[$line] = <IN>
>}

>####or
> my @lines;
> push @lines, <IN> for 0..2;

"push" is a shortcut for the above function. Are you saying that there
shouldn't be a "push" function? Or that the "push" function should have
been specifically written to disallow its use for reading lines from stdin?

>#####or
> my @lines = map <IN>, 0..2;

Are you saying that there shouldn't be a "map" function? Or that the "map"
function should have been specifically written to disallow its use for
reading lines from stdin?

>####or
>my @lines;
>while (<>) { push @lines,$_ if($.<4) }

Are you saying that there shouldn't be a "$." variable? Or that the "$."
variable should have been specifically written to disallow its use for
reading lines from stdin?

--hymie! http://lactose.homelinux.net/~hymie hymie(a)lactose.homelinux.net
-------------------------------------------------------------------------------
From: ccc31807 on 11 Jun 2010 13:25
On Jun 11, 10:54 am, Peng Yu <pengyu...(a)gmail.com> wrote:
> One drawback of having different way of expression to do the same
> thing like this is that it make the source code hard to be analyzed
> (suppose, e.g., people want to study source to discover some redundant
> code and do re-factoring).

In a recent thread, 'to RG - Lisp lunacy and Perl psychosis', we have
these examples.

Example 1, by me:
if ($sec{$k}{'xlist'} !~ /\d/)
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
elsif ($sec{$k}{'xlist'} eq $sec{$k}{'crs_id'})
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
else
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$sec{$k}{'xlist'}}
{'site'}; }

Example 2, by Ben Morrow
my $seck = $sec{$k};
my $xlist = $seck->{xlist};
my $id1 = $seck->{id1};
my $fack = $fac{$id1};

if ($xlist !~ /\d/) {
$fack->{location} = $seck->{site};
}
elsif ($xlist eq $seck->{crs_id}) {
$fack->{location} = $seck->{site};
}
else {
$fack->{location} = $xlist;
}

I write the kind of stuff in Example 1 every day, I'm comfortable with
it, I can read it, and (to me) it's clear and unambiguous. To Ben
Morrow, it's 'unreadable'.

Question: do you get clearer, more readable code by allowing
developers to work within their comfort zone, or by forcing all
developers to use arbitrary standards with which they not be
temperamentally suited?

People have different learning styles, some are visual learners, some
are auditory learners, some are haptic learners, and so on. When we
teach, we take all learning styles into account and we don't force one
style on every student.

More to the point, Perl is an open technology, which everyone is free
to use as he sees fit. Damian Conway, in his book 'Perl Best
Practices', make the point that there is no one right way to do
something, only ways that have proven useful and other ways that
aren't so useful.

I think you're beating a dead horse. Perlistas tend to be
individualistic, like the language, and you can't convince them to be
communitarian. If you like to dictate policy, learn and use Java.

CC.
From: Christian Winter on 11 Jun 2010 14:21
Peng Yu wrote:
> According to Programming Perl, more than one way may not always be
> better. But I just don't see more than one way is better at all.

More than one way is not always better, but cluttering the
namespaces with tons of seldom needed shortcuts for short -
and only in certain cases efficient - idioms doesn't sound very
appealing to me either.

It reminds me a bit of a discussion back in the old days in
college in the basic x86 assembly language lecture. People were
complaining all over why there needed to be a difference between
long jumps and short jumps. Of course, all of those who complained
also wrote excruciatingly long and complicated code blocks.

The answer from our professor was along the lines of: as
sophisticated as your computer may look, it's only a dumb machine
that knows nothing about how to solve a problem in the best
possible way. For a program to be efficient, it needs to
stick to rules like not jumping wildly all over memory or not
pushing unneccessary items on the stack only to retrieve them
and push them again because the needed value turns out to be
the third-to-last each time that piece of your code is run.
Your job in programming is to come as close as possible to
the most efficient code to solve a certain problem. You can
either, as we do here in assembly language, work close to
the real data and algorithms that the computer runs and
fine-tune what it does to perfectly match the problem. On
the other hand, you could use a higher level language to
solve the same problem and use built-in functions instead of
coding them yourselves, but then you'd have to hope that whoever
implemented those built-ins anticipated your exact needs when
they wrote them - would you risk that to solve a time critical
problem?

He continued to point out that there were some semi-builtins
for often encountered problems in the form of macro libraries,
but it also became clear for everyone, after thinking up all
kinds of shortcuts which might come in handy, that the resulting
language wouldn't really be assembly language anymore and that
there were in fact problems where assembly language was the best
possible means to solve them.

I'd say the same is true for Perl. Its power lies in the fact
that it gives the possibility to work one step closer to the
machine than with other competing languages like e.g. Java, C#
or PHP.

A good example for that is one topic I stumble over in my daily work
quite often: webservices. Perl definitely is not my tool of
choice to quickly click together standardized webservices or
to consume and validate them with graphical output. There are
libraries and apps written in C#, Java and what else that do
that though. However, nearly every second webservice instance
I have to connect to is in some way non-standard, starting from
lacking DTDs to really broken nesting, wrong data types etc.

Those click-and-forget tools all do the same thing in such a
case, they throw an error and give up. With Perl, it's a trifle
to program a filter or proxy that pre-processes the data, checks
for errors and, most importantly, modifies the underlying data to
eliminate them.

Perl, in my mind, is a such a powerful language due to its loose
typing, flexible OOP concepts and simple yet powerful commands. A
variable can contain what both is a simple hash and a powerful object
at the same time, and an XML document can both be a nested structure
and a plain concatenation of characters. Where I have access to one
of them, the other is never far away.

If too many implementation details were hidden, people would use
Perl in the same way as all the library-centered languages, and if
features were inefficient in certain cases, they'd demand to change
the implementation of the feature instead of learning to use the
basics. Perl would be just another Python/Javascript/C# with funny
variable names, arrows and braces (though, admittedly, if one looks
more closely at Java-/ECMAScript implementations, those can in parts
also be quite flexible and allow lots of different ways to do the
same thing).

Seeing that we already have those languages, I for my part love it
that Perl tries to focus on what it does best: let the programmer
decide how to solve simple problems efficiently, give them the tools
to wrap and distribute often needed solutions as classes and modules
and, if some module turns out a gem everyone uses, include it in
the core distribution.

-Chris
From: Peter J. Holzer on 12 Jun 2010 05:54
On 2010-06-11 10:11, Peng Yu <pengyu.ut(a)gmail.com> wrote:
> On Jun 10, 8:32�am, Ted Zlatanov <t...(a)lifelogs.com> wrote:
>> But deciding what will be in the API is a very hard task, and
>> implementing it will be no easier.
>
> Agreed.
>
> I think this is a more important problem than figuring out how many
> ways of programming there are and choosing the best one out of them,

I think you are looking at it the wrong way. You think that just because
Perl provides multiple ways to do something you have to explore all of
them and find out which is best. But that isn't true. You just have to
find one way. And because there are multiple ways, there is likely to be
one way which is very similar to the way you would like to solve the
problem. You don't have to think "Well, I would like to do X, but the
language doesn't let me. But I could do Y and Z and that should do the
same".

Perl is an executable brain dump.


> in the sense that once such choice has been figured out in a given
> context, then just package it into an API then people don't have to
> worry about it in the future.

Have you looked at CPAN yet? A lot of people have packaged stuff into an
API. So you just have to worry about which API to pick :-).

hp

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: FAQ 6.16 How can I do approximate matching?
Next: FAQ 4.4 Does Perl have a round() function? What about ceil() and floor()? Trig functions?