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

131–140 of 180 posts

Re: Dwindling CPAN Releases

#131

Post by perigrin »

cure wrote: post #110
MichaelMoser123 wrote: post #101

Earlier quoted context omitted.

"There should be one — and preferably only one — obvious way to do it." That is a python design principle https://en.wikipedia.org/wiki/Zen_of_Python Now there are multiple (sometimes very confusing) ways to import stuff in python, so I am not quite sure if this principle is being followed. https://realpython.com/absolute-vs-relative-python-imports/

The other place where this principle is completely ignored is when it comes to Python packaging, which is a complete and utter disaster. There are many different ways to package Python, none of them are feature complete, and the result is an absolute maintenance nightmare for those of us who have to maintain tools that have Python dependencies. Perl got packaging right, there's one way to do it, and it just works!

There isn't one way to do it in Perl (EUMM, Module::Build, Module::Build::Tiny, Module::Install etc), we just tried to make sure that they all interoperated cleanly. And we have things like the Toolchain Summit to make an emphasis on that.

Re: Dwindling CPAN Releases

#132

Post by alexpotato »

hobojones wrote: post #117

I work on a large, legacy codebase (the oldest modules date from the mid-nineties) that's slowly being rewritten from Perl into Python. A handful of developers have been involved with the project from the beginning. Looking at the long term contributors, readable or un-readable code seems to be more about the person than the language. Unsurprisingly, the person who produced the most unreadable, unmaintainable code is…

> Looking at the long term contributors, readable or un-readable code seems to be more about the person than the language. Unsurprisingly, the person who produced the most unreadable, unmaintainable code is now doing the same in a new Python only project.

I would totally agree.

I learned Perl after first learning Basic(and Visual Basic) then Java.

Coming from Java meant that I always tried to use clear variable names, good comments, broke my code into small and simple functions etc. I repeatedly had people say to me "Wow! I didn't know you could do that in Perl!"

A lot of Perl's bad reputation came from sysadmins and other busy folks who either weren't familiar with good syntax or were in a hurry and basically were playing Perl Golf to get things done quickly. This is probably where the line "Perl is a write only language" came from.

I will concede that Python and it's forced indenting leads to much easier to read code for beginners. That being said, trying to understand what's going on with advanced Pandas usage written by Numpy wizards is no walk in the park either.

I also totally agree that the Perl one liner is still my go to even though I do everything else in Python these days.

Re: Dwindling CPAN Releases

#133

Post by cygx »

Izkata wrote: post #129
gmueckl wrote: post #54

Earlier quoted context omitted.

Wait, what? Perl 6 is real, released and essentially stable. The ecosystem for the language is also evolving at a good pace.

It seems that the most advanced implementation doesn't yet have all the Perl 6 features in the spec..?

The written specification wasn't being kept in sync with the implementation and has been relegated to the status of 'design document'. The language is nowadays defined and versioned through its test suite, and there have been two releases (v6.c in Dec 2015 and v6.d in Nov 2018).

Re: Dwindling CPAN Releases

#134

Post by blihp »

latchkey wrote: post #48
tus88 wrote: post #19

It's interesting. I started Perl in around 2005, and moved entirely to Python in 2014, exactly when it reached it's peak and started to decline. Seems I wasn't the only one.

Now I feel old, I started with Perl 4 around 1992-1993. There wasn't even a CGI query args parser library yet, you had to roll your own.

Nah, you're still a youngster. Got Perl 1 via Usenet in 1988 when there wasn't even a web yet.

Re: Dwindling CPAN Releases

#135

Post by freedomben »

roryrjb wrote: post #95

There's so much negativity in this thread. I think that a big part of Perl's decline is exactly because of people's attitudes. I don't actually write any Perl now, but to me it's a beautiful language, I always enjoy working in it. You can abuse it in the wrong way like every other language. If I was to suggest using it in the day job there would be uproar probably. But just because I like Perl doesn't mean I want to…

Yes, thank you. Perl was an absolute earth-shaker back in it's day. Even still it's a fantastic language for string manipulation. Much of Ruby's beauty, expressability, and powerful string processing is thanks to inspiration from Perl. It's disappointing to see people crapping on such a venerable language.

Re: Dwindling CPAN Releases

#136

Post by jwr »

_rrnv wrote: post #9

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

This isn't as much of a joke as it sounds.

I've just written a utility I needed in Perl. I tend to think about some things in the long term, and this utility is something I want to be able to run 10 years from now.

[it's a concistency checker (hasher) for file archives, to find out if the bits in your copy are really the ones you put there, important for multi-GB photo archives — see https://github.com/jwr/ccheck]

I do most of my programming in Clojure, which has excellent backwards compatibility and takes a long-term perspective. I still run some unmodified Clojure code from 8 years ago. And yet for really long term stuff, I would much rather write it in Perl. It has been around for a very long time, is very mature, and can be expected to last, even if it isn't the latest fashionable trend.

Take a look at the various programming languages+environments around you: there will be very few where you can expect to be able to run your code even 2-3 years from now, much less decades later.

Re: Dwindling CPAN Releases

#137

Post by vague_irssi »

FranOntanaya wrote: post #23

I wish someone poked irssi devs to support other languages. I basically learned Perl just for it.

irssi has support for perl, python, js, tcl and lua(very alpha) https://irssi.org/modules/ None of those other modules are as featureful as the perl module and are looking for people who are interested in developing them further :)

Re: Dwindling CPAN Releases

#138

Post by TylerE »

isostatic wrote: post #130
TylerE wrote: post #124

Earlier quoted context omitted.

Python only postdates Perl by 3 years.

Perl5 - which is what people refer to as "perl" - came out in 1994. Python3, which is incompatable with python2, came out in 2008.

Way to move the goal posts into separate area codes.

If you're going to judge python by python3 you should at least hold perl to 5.020

Re: Dwindling CPAN Releases

#139

Post by mattbillenstein »

mfontani wrote: post #70
mattbillenstein wrote: post #40

Earlier quoted context omitted.

That is not normal.

All the "big" Perl codebases I've worked with were as readable as I'd have expected any "big" codebase to be, if not better. What was your experience like?

25k lines of spaghetti garbage - all in one file.

Re: Dwindling CPAN Releases

#140

Post by joosters »

SmirkingRevenge wrote: post #90
trabant00 wrote: post #49

Earlier quoted context omitted.

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 w…

FWIW, you can 'lock down' a hash so that reads or writes of non-existing keys will cause a fatal error. Not only does this stop autovivification on 'writes' to a hash, but it will also help catch typos in your code just reading from the hash: e.g. if you accidentally wrote

  $foo = $bar{Autovivication}
instead of

  $foo = $bar{Autovivification}
in your program, it will abort instead of returning an undefined value :)

See Hash::Util for details.

Post reply on HN