Re: Perl Pros and Cons: Syntax and Modules (Was: Larry Wall Talks, Perl and Lua)

Hi Octavian,
Allow me to bottom post to digest your message in small bits.

> Well, one of the biggest advantages of perl is that there are more ways to
> do something,
Agreed, I have quite odd ways myself. I call the first argument of
method calls by different names in different classes. This is allowed
and reminds me of what I'm coding. In a sequencer package I might call
it $track where as in a queue, it would be $queue rather than $self or
$this. in class methods it is $kind, for me, giving output like:
bless $track, $kind;

> however this can be one of the biggest disadvantages
That's true, too, but again people differ in what they prefer, so
sometimes flexibility is a very good thing. Though Lua doesn't have map,
I like the fact that I can do:

function push(a, b)
        for i, elem in ipairs(b) do table.insert(a, elem) end
        return # a
end

and then:

function map(f, t)
        local new = { }
        for i, elem in ipairs(t) do push(new, { f(elem) } ) end
        return new
end

To have both Perl's push and Perl's map. 
Personaly, though I admit everything can be done without them, I'm a big
fan of grep, map, zip, reduce, Ruby's times and so on. I even use
lexical closure rather than mini objects. In my perl script the example
that regexp matches in a map and assigns the result to a hash, doing 5
line of Lua in 1 line of PErl, is a good example of that. I even think
it is clear, if you know how map and grep work. 

But many, many folks who aren't either Lispers or scripters don't. Java
doesn't really support functional programming and neither does C++, C#
and many conventional imperative languages.

> For example, I admit I use the old and not recommended way of defining file 
> handles
Why is that? I use the new method and like it. it is clearer not to have
to have those global or local variables, passing of file handles to subs
is much easier, and I really find it neat that once those variables are
cleaned up, the files are closed as well. It is as easy as saying
open my $outFile, ">", $fileNa or die "$^E in writing to $fileName\n";

> and I use to die() or warn() only if necessary.
Does that imply that you rigorously check for errors, or rather, that
you don't even if you should? I think die is better than no error check,
since it ensures that the script doesn't do anything nonsensical. It
would be better to really gracefully recover from errors, which i do use
in larger scripts. e.g. if no file was found, use a default file or let
the user retry.

> Perl 6 will have subroutines with the same name and different signatures, 
> <snip>
> however I don't know if it will be so clear.
I sort of disagree. I've wished for quite a long time that Perl  had
named arguments. If it was just flat lists and list context for
subroutine arguments, then everything would be great. But not being able
to explode an array as a list when your sub is prototyped as taking
scalar arguments is annoying. NOt being able to use an array ref when a
prototype requires a true array, rather than a list, is doubly so.

> I also don't know why the commenting style used by most programming languages 
> with /* ... */ was not good
I like the hash, it is brief and easy to type. YOu can comment
multi-line blocks with 

=pod
code here
=cut 
The pod documentation is part of the language syntax, after all.

> Perl seems to want to make everything as different as possible, making it
> harder to learn and understand.
But it also makes very cool things possible in so doing. If it hadn't
regexp at the level it does, or not the functional programming support,
then it would be a different language. reading Hugher-order Perl has
taught me functional techniques that are quite useful outside of Perl as
well. I do agree it is hard to pick up for newbies, diminishing its
success. It took me months to properly understand references and
object-orientation where as geting the basics right in something like
Ruby is quite easy.

One of the reasons why I like Lua is that the whole language is so clean
and simple, that one can memorize pretty much it all, and be sure of how
the code being run works exactly. There are very very, few built-ins.

> If someone knows Java, he could learn C# easier, or vice-versa, but he won't
> learn perl as easy.
But then again, Perl is a clue language, a scripting language and
dynamically typed. C# and java aren't, they are ment for large scale
software development. While you can do that in Perl, it was not really
designed for it the way Java and C# are. I was doing, am still often
are, console apps that manipulate files, read directories, parse text
etc... ANd the productivity boost from Java to PErl was simply amazing.

> Java/.net/PHP programmers prefer SOAP services for example, <snip>
> [Perl folks] they consider XML RPC or other systems better.
At a personal level maybe. But once you are doing software for a living,
it is  a matter of what the specs say. And then it is about libraries. I
believe Perl has soap support in ppm, so not using it when you ought to,
is the wrong kind of laziness. I only know XMLRPC myself, from PHP
coding, and like the simpplicity.

> SOAP works fine in perl also, but only if the SOAP client is made in perl
> and the SOAP server is also made in perl, because it uses a different XML
> format than .net or Java, and well, the web services were invented exactly
> for making different programming languages collaborate easier.
True, but are all the MS XML specs and those of Sun exactly compatible?
How are objects passed from one machine to another remotely, does it
imply a very traditional strongly typed object oriented system that all
languages are forced to follow? From what I've heard MS tools are very
easy if you are only willing to interface with other MS tools, services,
software and languages. But once you try something else, a lot of the
IDE support and convenience is gone. But this is just stuff I've heard
and reasoned about, I don't know enough of NET to be able to offer but a
tentative guess.

Perl 6:
> how compatible will be the tens of thousand modules on CPAN with it...
It should, there's a Perl 5 compatibility mode.

> Until then... I find it pretty hard to create multi threading applications in 
> perl
I second you on that, I have never liked the threading model.

> create binary executables that doesn't allow others to see the code,
Encryption is possible,  I believe, at least using source filtering. But
no matter which dynamically typed bytecode language you have, the
bytecode is always readable so is this security really necessary? I
think debug builds of Java apps even have the variable names. I'm sure
Perl 6's bytecode compiler will actually work properly, and if there's
encryption for Parrot code, then it will also work for Perl 6.

> I think these improvements are more important than changing from $array[1]
> to @array[1]
I think you've raised a valid point. However, I think Perl 6 has the
potential of changing the threading, and as for the GUI stuff, if it
attracts more people on board, chances of someone doing proper SWT
support do increase. I've been quite happy with WIn32::GUI but it is not
cross platform and neither exactly unicode.

-- 
With kind regards Veli-Pekka Tätilä (vtatila@xxxxxxxxxxxxxxxxxxxx)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila
__________
View the list's information and change your settings at 
http://www.freelists.org/list/programmingblind

Other related posts: