Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dwindling CPAN Releases

perlancar.wordpress.com

Post reply on HN
Print view View original

81–90 of 180 posts

Re: Dwindling CPAN Releases

#81

Post by isostatic »

1f60c wrote: post #76
isostatic wrote: post #31

Earlier quoted context omitted.

"too clever constructions which feel smart at the time you come up with them" That's the coder, not the language. Which is more obvious what's happening. print ''.join('%(pre)s%(num)s %(bot)s on the wall, %(nul)s %(bot)s,\n%(tak)s\n' % (lambda c,b: {'pre':['','%s %s on the wall.\n\n' % (c,b)][abs(cmp(c,'Ninety-nine'))], 'num':c, 'nul':c.lower(), 'bot':b, 'tak':['Go to the store and buy some more... Ninety-nine %s.' %…

This is not a fair comparison. You golfed the Python to fit on one line with one-letter variable names, while you took a very literal approach with the Perl code.

That's my point, it's not the language itself that changes readability (although personally I find the lack of visual blocks and statement ends in python a right pain). Perl isn't a "write-only language" unless you want it to be.

I'm not a programmer, I'll bash something out to solve a problem and move on, but in general I find reading other peoples perl far easier than reading other peoples python. Maybe that's because I have more experience with perl, because it's well suited for problem solving.

I avoid cpan and pip as much as possible as it makes code much less portable, and unless the module is available in apt (and thus trivial to deploy) it would have to be really compelling to get me to wrap into a custom deb, but that's because I'm not writing products, I'm writing utilities to help run my network.

Re: Dwindling CPAN Releases

#82

Post by bjornjaja »

oblio wrote: post #47
isostatic wrote: post #31

Earlier quoted context omitted.

"too clever constructions which feel smart at the time you come up with them" That's the coder, not the language. Which is more obvious what's happening. print ''.join('%(pre)s%(num)s %(bot)s on the wall, %(nul)s %(bot)s,\n%(tak)s\n' % (lambda c,b: {'pre':['','%s %s on the wall.\n\n' % (c,b)][abs(cmp(c,'Ninety-nine'))], 'num':c, 'nul':c.lower(), 'bot':b, 'tak':['Go to the store and buy some more... Ninety-nine %s.' %…

Languages are not just platonic, ideal things, living in an abstract world. They are also people, core developers and BDFLs, guidelines, communities, cultures. The Perl culture is overall about being practical but also being clever and leaning towards code golf. The Python culture is overall about being explicit and readable. As usual, YMMV, but that's the impression an awfully lot of people get, so there must be som…

The problem with any language is most people don’t spend time to actually learn it to proficiency. They don’t read the books, just google a quick solution.

Perl is great because it has nuances many languages don’t, for instance sigils which allow the language to evolve safely (adding language constructs won’t clash with vars.) and “magic variables” designed to allow shortcuts like we use in spoken language. But, just like people shouldn’t use much spoken vernacular in writing, a lot of those features are designed for quick “conversations” and one-off scripts. And it should be peer reviewed before publication.

Python is great for many things too, but it’s no C++, and it’s also no Perl.

Re: Dwindling CPAN Releases

#83

Post by ojosilva »

I think Perl was fighting on too many fronts at the turn of the century: web, systems automation, data processing, science and a few more. Today these areas are better covered by other languages that have hefty internet buzz and corporate support behind.

Perl also has no shiny features. It's just extremely dynamic and paradigm agnostic, great at shell interactions and natural at text processing (specially with regexes), good enough at binding C/C++ libraries, has package management built-in (CPAN) and an automated testing culture. Perl basically set the baseline for a lot of today's languages.

Perl5 devs put a lot of focus on making Perl even more dynamic during the 2000s, relying on CPAN/community to fix language quirks and plug in novelties. It worked to some extent, Perl got to the point where it could be written like Haskell, Ruby... During that time it also got a powerful but optional class system (Moose) and reinvented itself as a web language (Mojolicious, Plack).

Unfortunately it all came too late, most Perl5 devs moved to something else or maintained Perl5 code frozen in legacy mode. Fewer and fewer started new projects using Perl. For instance, nowadays I tend to pick a language/ecosystem pair based on these concerns first depending on what the job requires:

- asynchronous event processing, specially network related -- I pick JavaScript/Node.

- real parallel processing and highly performant systems, I'd use Go.

- "we got a package for that" -- Python or JS at the forefront here. It depends on what package I'll need for the job, typically it's not going to be in CPAN.

- great code reuse/portability -- to me JS wins here. And still the only single language for both server and browser.

- compiled hard-packaged binaries: Go, but also Rust, Elixir, Nim, and others can fit the bill.

- code style and paradigm -- a very personal choice, I think Typescript and ES2019 are both great here. Golang and others are also great if I feel like staying away away from OO.

Perl would have a hard time competing in any of these fronts, but it still is one of the greatest for practical extraction and reporting, text or database wise and easily available or pre-installed on many servers out there new and old.

Re: Dwindling CPAN Releases

#84

Post by bjornjaja »

nerdponx wrote: post #79
1f60c wrote: post #76

Earlier quoted context omitted.

This is not a fair comparison. You golfed the Python to fit on one line with one-letter variable names, while you took a very literal approach with the Perl code.

That was the point they were making, that you can write horribly ugly code in Python if you really put a lot of effort into it, and that you can kinda sorta write readable Perl if you put a lot of effort into it.

If one is marginally literate, one cannot read or write coherently.

Re: Dwindling CPAN Releases

#85

Post by jsymolon »

isostatic wrote: post #46
unmole wrote: post #37

Earlier quoted context omitted.

> 2) Is ubiquitous On which systems do you have Perl readily available but not Python?

Which version of python? Perl documentation online applys to versions of perl that are installed. Python stuff is all bleeding edge - you'll research why something isn't working and after 30 minutes find it's expecting python 3.7. The whole concept of "virtualenv" gives me an impression of fragility I don't get with perl.

Wanted to use Python 3 for some processing but the Sysadmin said that only Python 2 was available for that distributions version and "didn't want to frankenstein the box"

Re: Dwindling CPAN Releases

#86

Post by mfontani »

ninkendo wrote: post #74
isostatic wrote: post #31

Earlier quoted context omitted.

"too clever constructions which feel smart at the time you come up with them" That's the coder, not the language. Which is more obvious what's happening. print ''.join('%(pre)s%(num)s %(bot)s on the wall, %(nul)s %(bot)s,\n%(tak)s\n' % (lambda c,b: {'pre':['','%s %s on the wall.\n\n' % (c,b)][abs(cmp(c,'Ninety-nine'))], 'num':c, 'nul':c.lower(), 'bot':b, 'tak':['Go to the store and buy some more... Ninety-nine %s.' %…

This post reminded me that Perl doesn’t even have a concept of a method signature, even so much as showing the number of arguments. You have to look at the next few lines to hopefully see all the `... = shift;` lines to see what you’re actually supposed to send. I mean, a lack of type annotations is normal for a scripting language, but Perl always seemed to go a bit far by not even having a standard way of showing pa…

... but it does, since perl 5.20, which was released May 27, 2014. More than five years ago.

Here's a short example:

    use 5.020_000;
    use warnings;
    use experimental qw;
    # this works:
    say add(2, 3);
    # this dies: Too many arguments for subroutine 'main::add' at ...
    say add(2, 3, 4);
    sub add ($x, $y) {
        $x + $y;
    }

Re: Dwindling CPAN Releases

#87

Post by cygx »

nerdponx wrote: post #78
vultour wrote: post #64

Earlier quoted context omitted.

The most obnoxious parameter passing in existence? The magic variables everywhere? Perl code is an unreadable heap of spaghetti, I’d much rather be figuring out unallocated memory bugs in C then read Perl.

Don't forget sigils. Because the difference between @foo and $foo is obvious, right?

That difference is indeed obvious. The issue is sigil variance.

Re: Dwindling CPAN Releases

#88

Post by ImaCake »

trabant00 wrote: post #49
_rrnv wrote: post #9

Consider this: Perl codebase is reaching perfection and no longer needs releases. After this, we get eternal Perl ;)

From a experienced linux sysadmin point of view perl5 is as good as it gets. I've been searching for alternatives for about 10 years now, at first because my novice self was heaving headaches reading other people code and even my own. I hated perl but I hated everything else even more as I came to know them. No autovivification? Some assignments copy the data and some create references and you need to memorize the co…

>Some assignments copy the data and some create references and you need to memorize the conventions of which does what?

This is a nightmare for beginner coders trying to make sense of Pandas or R subsetting.

Re: Dwindling CPAN Releases

#89

Post by eruci »

There is more than one way to look at it.

I've been coding in Perl for 20 years, I'm a CPAN author [1] and I just published my third CPAN contribution yesterday.

I've written over half a million Perl lines of currently in use enterprise cloud software[2] and I'll keep coding in Perl because I don't like the big snake dictatorship of "There should be one — and preferably only one — obvious way to do it."

[1] https://metacpan.org/author/ERUCI

[2] https://aws.amazon.com/marketplace/seller-profile?id=434e986...

Re: Dwindling CPAN Releases

#90

Post by SmirkingRevenge »

trabant00 wrote: post #49
_rrnv wrote: post #9

Consider this: Perl codebase is reaching perfection and no longer needs releases. After this, we get eternal Perl ;)

From a experienced linux sysadmin point of view perl5 is as good as it gets. I've been searching for alternatives for about 10 years now, at first because my novice self was heaving headaches reading other people code and even my own. I hated perl but I hated everything else even more as I came to know them. No autovivification? Some assignments copy the data and some create references and you need to memorize the co…

Autovivication seemed like a great feature to me, back in the day, when I was getting started with Perl. Working with similar data structures in languages like Python always seemed like a chore.

I had heard a few perl monks criticize it a bit, as an "end run around use strict", but I was kind of dismissive. It turns out, that's a really apt way to describe it. It basically tosses the niceties of use strict out the window, so long as its a hash. And sooo many things are hashes/hashrefs in Perl.

The first time I wasted a day tracking down a bug that turned out to be a well hidden typo in a hash key assignment, changed my mind. Well... maybe the third time.

Post reply on HN