On 21 December 2011 23:10, Meir Kriheli <[email protected]> wrote: > There goes the neighborhood ....
> So Perl is explicit in that regard, while Python is implicit, hence the next > section shouldn't be that conclusive. In the sigils regard, you could argue that Perl is explicit while Python isn't, however, this only tells you what datatype is a variable, not how it's used, what it (should) contain, etc. Then you have no method signatures, the $_ variable, DWIM, contexts, and so on, which means a lot of Perl isn't specified out unlike in Python. > Like mentioned above, it's not that clear cut (sigils). > > Plus, in Python, the culture leans heavily towards duck typing, I don't care > what a variable (object) is, all I care is it's behavior. I Don't care if > it's a file, all I care is that it can read() and write(). When needing to > slice something, don't care if it's an array, all I care it can actually > slice, eg: String can do it too). That's the same in Perl, and probably in other dynamic languages. You can slice hashes, arrays, strings, you can open sockets, files, streams, and so on. > > In that regard Perl is more explicit than Python. That's actually good news, since most of the complains about Perl is that "you can't read it" because of all the DWIM and implicitness. I'll be happy to quote you on that :) > > Regarding CPAN etc, Python has PyPI, Ruby has gems, Node.js has npm etc. > That's a solved problem long time ago. Having a repository does not mean a problem is solved. For instance the CPAN, for all it's benefits is, at times, feels like a wretched hive of scum and villainy rather than the greatest software repository we think of it, and its never a solved problem, because even if every module in there is a work of art, you now have so many of them it's mind-boggling to figure what fits your needs, so we now have annotations, ratings, metacpan search engine, cpantesters, while still suffer from different installation standards, and other funky shenanigans. So, just having a repo isn't solving anything, and the current state of Pypi (http://blogs.perl.org/users/mark_allen/2011/12/writing-api-clients-in-perl-and-python.html), npm (http://mikkel.hoegh.org/blog/2011/12/20/trouble-in-node-dot-js-paradise-the-mess-that-is-npm/), et al can show it takes time (but not just, e.g. CTAN), and demands a very dedicated communal effort in self-enforcing quality standards to reach something that is half-usable to very usable (depends on who and when you ask) like CPAN. > > From my point of view today there's no real advantage for one dynamic > language over the other, it's a matter of petty preferences (but hey, > they're mine petty ones ;-) ). Actually, that was the premise of my original answer, there are many stages of consideration before you even get to X vs. Y issue. I've worked in a startup that had a GUI product written in Perl-Gtk, which was then scrapped for a Windows-C++ one because they couldn't find good Perl guys, but could find many excellent Visual-C++ programmers. I worked in another place where they scrapped a Perl project for Python because there were a lot of Python guys there, and most places don't even consider Perl, Python, Ruby, and their ilk, but hit the much more available PHP/Java/.NET pool. -- Erez Stop software patents _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
