On Thu, Dec 22, 2011 at 11:13 AM, Erez Schatz <[email protected]> wrote:
> 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. > > In that case, why one should care what the data type is if no one care how it's used ? To be clear: I don't think Perl is more explicit than Python, just saying that it's not that clear cut. I prefer Python's explicitness, specially in name space management (what's why I frown upon programmers using 'from x import *'). Plus For dynamic signatures etc, Python has *, and **, where one can mix and match declared and dynamic params/named params to his liking. Anyway, no method signatures, $_, etc. are exactly the reasons for my dislike of Perl - pet peeves all over again. > > 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 > Another way to look at it is Debian's apt system vs. Ubuntu's software center on top of it. It's the natural evolution of one of Perl's biggest shortcomings from my POV: Miniscule STD lib (which leads to no stdlibs tests on multiple platforms and extensive docs). Without such features it'll be a real mess (When I've read Gabor's recent question regarding reading a file in modern Perl, my first reaction was: WTF ?) That way, there are also great, cross referenced, indexed etc std docs: http://docs.python.org/ And many (including non-python projects) are using exactly the same tool (Sphinx, maybe I'll give a talk about it), and sites such as http://readthedocs.org/ which auto-build docs on commits etc. When the stdlib is that extensive, used and tested on many platforms, the need for such things is largely muted. Which leaves PyPi exactly where I need it: KISS, repo and dependency management. What will be the next step ? Addind Facebook "Like" or SMS voting for modules ? :-P of Pypi ( > http://blogs.perl.org/users/mark_allen/2011/12/writing-api-clients-in-perl-and-python.html > ), > Python has a great build tool, buildout, which also provides an isolated env for devel, this including packaging it and uploading to PyPI. Guess he didn't know about it. Been using it for quite a while, from simple modules to entire projects/sites. 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. > > No Argument here. Cheers -- Meir Kriheli http://meirkriheli.com
_______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
