Live data from Hacker News

Dwindling CPAN Releases

perlancar.wordpress.com

171–180 of 180 posts

Re: Dwindling CPAN Releases

#171
post #110

Earlier quoted context omitted.

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.

I stand corrected, thank you :) Clearly, you succeeded in your mission since it feels like there's one way, and most importantly, it 'just works'. Many, many thanks to you and everyone who made that happen!

Re: Dwindling CPAN Releases

#172
post #57
post #34

Earlier quoted context omitted.

It's very hard to know which codebases will grow to be large - every codebase starts out small, and by the time you realise it's going to be big, rewriting into another language is expensive. Better to use a language that can scale to small codebases and large, that can accommodate hackiness and cleanness alike.

Nicely put, but I notice that you avoid names and numbers. How expensive can it be to rewrite a hundred or a thousand lines, if a perl script keeps growing? And what are these languages (you use plural so I do too) that are optimal for every case?

> How expensive can it be to rewrite a hundred or a thousand lines, if a perl script keeps growing?

A hundred lines, or a thousand lines, is not so bad. But where do you draw your line in the sand that you're going to stick to? If you don't insist right at the start on coding to your maintainability standards, why would you make that change when your script went from 30 lines to 100, or 100 to 500 (no doubt always driven by an urgent functional need)? It's always easier to add one more change to the existing codebase; the only point where you'd rewrite is when the codebase becomes literally unmaintainable because no-one understands it, and at that point migrating it is extremely expensive.

> And what are these languages (you use plural so I do too) that are optimal for every case?

I'm not saying optimal (I doubt that's possible), I'm saying pick a language that's adequate for every case. I'm partial to Scala, which was explicitly designed as a "scalable language" that would work for large and small codebases; other ML-family languages (e.g. OCaml) are similar. In my book any language with the ML featureset is more than adequate for large codebases, and any language that has a REPL/interpreter and doesn't require Java-like explicit types is adequate for scripting tasks. (Side note: I've always found it odd that Perl didn't have a first-class REPL, since IME that's one of the biggest natural advantages of scripting languages). If you want to start from the scripting end, Python, Ruby or even TCL offer a level of consistency and least-surprise that let them scale to larger codebases than Perl, though I wouldn't really want to use any of them on a truly large codebase.

Re: Dwindling CPAN Releases

#173

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…

Based on your comments, here are some things you might find interesting:

Recent Perl versions have function signatures.

Have you tried the Test2 test suite? It’s a tremendous improvement over the previous system.

Type::Tiny is an amazing library that provides a rather nice type system.

Re: Dwindling CPAN Releases

#174
post #172
post #57

Earlier quoted context omitted.

Nicely put, but I notice that you avoid names and numbers. How expensive can it be to rewrite a hundred or a thousand lines, if a perl script keeps growing? And what are these languages (you use plural so I do too) that are optimal for every case?

> How expensive can it be to rewrite a hundred or a thousand lines, if a perl script keeps growing? A hundred lines, or a thousand lines, is not so bad. But where do you draw your line in the sand that you're going to stick to? If you don't insist right at the start on coding to your maintainability standards, why would you make that change when your script went from 30 lines to 100, or 100 to 500 (no doubt always dr…

Next question: Code written in which of these languages tend to avoid needing major redesign when a thirty-line script grows unanticipatedly to much, much more?

Re: Dwindling CPAN Releases

#175

I still use perl for handy one liners on the command line. E.g. I had a 1 GB log file where I wanted to generate a histogram of the intervals between certain log messages. I used a perl one-liner to extract the timestamp via regex (regexs are perl's bread and butter), calculate the diff between the previous timestamp (easy because of auto string => double conversion), use the diff value as a key in a hash of counters…

I'm an occasional perler myself and I bet that others or myself would find that code you mention to be useful, at least for the black book of snippets. Would you mind pasting?

Here is the command I used (added linebreaks for clarity):

  rg ''  | \
  perl -MData::Dumper -n -e '
  m/\d{2}:\d{2}:([\d.]+)/;
  if ($last) {
    $diff = $1 - $last;
    print "$diff\n";
    $hist{$diff} += 1;
  }
  $last = $1;
  END {
    $Data::Dumper::Sortkeys = true;
    print Dumper(\%hist);
  }
  '

Re: Dwindling CPAN Releases

#176
post #174
post #172

Earlier quoted context omitted.

> How expensive can it be to rewrite a hundred or a thousand lines, if a perl script keeps growing? A hundred lines, or a thousand lines, is not so bad. But where do you draw your line in the sand that you're going to stick to? If you don't insist right at the start on coding to your maintainability standards, why would you make that change when your script went from 30 lines to 100, or 100 to 500 (no doubt always dr…

Next question: Code written in which of these languages tend to avoid needing major redesign when a thirty-line script grows unanticipatedly to much, much more?

I've seen plenty of Scala codebases grow without ever needing an overall redesign, and don't see why it would be different for any other language. Of course the end state is very different from the start state, and no doubt pieces end up getting rewritten many times over. But being able to incrementally evolve the codebase while keeping it all working is much easier and cheaper than having to rewrite in one go. In my experience you only need a "redesign" when you did too much design up front in the first place; if you always keep code changes driven by concrete use cases and avoid premature generalisation, you end up with a codebase that won't impede future changes any more than it has to.

Re: Dwindling CPAN Releases

#177

Earlier quoted context omitted.

Didn't perl always have multi-dimensional arrays? Just the syntax sugar for them is more recent.

Not quite, references were introduced in perl 5, in perl 4 and earlier had a different method that wasn't quite multi-dimensional arrays but tried to behave that way. $hash{1,2,3} = 10; This actually ends up doing the following $hash{join($;, 1, 2, 3)} = 10; It builds up a single key from the list using the special variable $; as a separator to the elements. With perl 5 you gained the ability to make references which…

hmm, it's been 4-5 years since i really did any perl but i remember it being way more confusing than that. maybe i was just a noob.

Re: Dwindling CPAN Releases

#178
post #96

Earlier quoted context omitted.

What about installing miniconda in your home folder? How ancient is that system?

> What about installing miniconda in your home folder? This is not how you deploy software

You are right, but I interpreted it as a one off manual task. I've used miniconda in that way.

Re: Dwindling CPAN Releases

#179
post #152
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…

Prel is great and has an important role, even today. That being said, I'm a professional dev and we own a decent amount of perl. That codebase is by far the most difficult to work in out of anything we own. New hires have trouble with it (nobody learns perl these days). Lots of it is next to unreadable. I agree that like any other language, perl can be written well and can be written poorly. That being said, perl mak…

I've gone from finding perl an absolute joy to program in circa 2005 to now (2019) where I wouldn't touch it with a barge pole. The sentiment seems pretty natural and common.

Re: Dwindling CPAN Releases

#180
post #87

Earlier quoted context omitted.

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

Highlighting sigil variance was my point, poorly stated.

Perl5 does not have "sigils", BASH, BASIC and Perl 6 have sigils.

Perl 5 has dereference operators, which got called "sigils" by lazy documentation and book authors.

Post reply on HN