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

Hi Velu,
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";
I like more the old style because I never need to pass file handles to other subroutines, and the old style is shorter. 


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.
Thinking better, in production I check if a file was opened successfully, but I make very many dirty short programs that do different things that need to be ran only once maybe, and I don't do that check in those programs. Other situations in which I don't always check for errors, even in production, is when I use other functions like unlink(), because sometimes it doesn't matter if the file was not found and it couldn't be deleted.
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 never used prototypes in the subroutines I make, maybe with the exception of Catalyst actions, because in the perldoc I've read that the recommended way is to not use prototypes. And I never felt that I need them.
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


I do that, but I can't say that I like it.
Using a comment like #[ ... ] would be good at least for the fact that we will be able to jump easily from the beginning of the comment to its end, but I don't like it because it is not standard, it is not used in other languages, and this makes perl more different. Beeing more different would mean that it would be harder to learn by the beginners, and this would mean a smaller number of perl programmers in the futures, and the companies don't like when they need to use a language that's used by very few programmers because it would be harder to find employees easily. At least it is good that Larry had chosen the dot as a class separator as in most languages. 


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.
Well, this was not a problem some more years ago when there weren't too many good languages to choose, but now a programmer that's not very good might choose PHP or Ruby or Python instead of perl, because they might be simpler to learn. There are very few extraordinary good programmers that don't care if a language is a little bit harder to learn, because they care for ease of use, support and speed. 


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.
Perl has support for SOAP, but as I said, it is not compatible with the one used in Java or .net, even though there is a module that should make it compatible. 


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?
Maybe not, I don't know, but if there are a million programmers in .net and a million programmers in Java and only 10000 in perl, maybe the programmers in Java could care only to create compatible programs with Java because it is enough, and same thing for those in .net, but it is not enough for those in perl. 


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.
As far as I know the Java and .net SOAP formats are compatible, although I am not 100% sure, and yes, it is true that they are compatible because they both are strongly typed languages, and they include information about the data types in the XML generated, while perl can't include this kind of information, because it doesn't care about it.
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.
I try to study the module POE in order to create multi tasking cooperative application thinking that it could be easier than using a multi process or multi threading style, but I find it very hard to understand and hard to include POE in applications that use WxPerl. Most examples are for using POE with Tk and GTK, but unfortunately under Windows they are not accessible for the blind.
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.
On the poe.perl.org page in the FAQ page I've read that Perl6 will have support for events, and maybe creating multi tasking apps will be easier, and maybe the support for threading will be better, but it will need to pass a long time until then.
I also like Win32::GUI but only for very small apps that don't need UTF-8 support.
WxPerl is not so light, but it has many more features than Win32::GUI, and it is also portable, at least partially. And it has UTF-8 support. However, creating multitasking apps with WxPerl is still pretty complicated. I can't compare with other languages, because I have never created multiprocess or multithreading apps in other languages, and it might be same complicated. 

Octavian

__________
View the list's information and change your settings at http://www.freelists.org/list/programmingblind

Other related posts: