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

111–120 of 180 posts

Re: Dwindling CPAN Releases

#111

Post by bachmeier »

ImaCake wrote: post #88
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…

>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.

I don't think there's any way to avoid that. You could always copy, but then you'd sacrifice performance. You could always make a reference, but then other parts of the language would become really complicated.

Re: Dwindling CPAN Releases

#113

Post by latchkey »

unpixer wrote: post #105
latchkey wrote: post #48

Earlier quoted context omitted.

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.

My first exposure to Perl pattern-matching was a magic regex for parsing CGI input handed down to me by a more experienced coder. "Don't ask how this works."

"Write once, read never" is another good Perl quote someone told me once.

Re: Dwindling CPAN Releases

#114

Post by eiro »

gmueckl wrote: post #66
eiro wrote: post #65

Earlier quoted context omitted.

we waited for them since the very beginning of the millenium, i played with both and here is the difference: DNF is very desapointed and is not the revolution i expected. Perl6 is a game changer and push the idea of "scripting" way beyond i was imagining it (and i played with a lot of langages)

Perl 6 is more than a scripting language. It clearly has elements of a very general high level language that can scale to large program sizes.

true

Re: Dwindling CPAN Releases

#115

Post by hedora »

MichaelMoser123 wrote: post #101
eruci wrote: post #89

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://m…

"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/

"There should be one — and preferably only one — obvious way to do it.”

In practice, perl came closer to achieving this than python.

Re: Dwindling CPAN Releases

#116

Post by hedora »

vultour wrote: post #64
roryrjb wrote: post #55

Earlier quoted context omitted.

Perl is a general purpose programming language. The Perl interpreter and language are stable, it's not going anywhere soon. Perl and its syntax have been around a lot longer than most other languages and is very similar to C, C++, JavaScript and PHP. What do you consider normal syntax?

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.

Is its function parameter passing really more obnoxious than python, which lets you mutate the default parameter across calls:

def foo(bar=Bar(1)):

Unless bar is a primitive type, in which case each invocation gets the same value?

def foo(bar=1):

Perl wears its idiosyncrasies as badges of honor. Python keeps them hidden so they can sneak up on you when you least expect it.

Re: Dwindling CPAN Releases

#117

Post by hobojones »

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 now doing the same in a new Python only project.

I've always tried to look at programming in a similar manner as writing research papers, your ideas are no good if no one understands how they're put to paper. Explicitly stating your intentions is better than assuming the reader knows the subject matter. If something is clever, overly-compact or your reviewer expresses confusion, rewrite it or at least spend an extra line or two in explanation.

At the language level, I miss Perl's handling of regexps and shell commands (which consist of large amounts of this codebase). Python requires a fair amount of overhead to handle both and always feels a little clunky. While I'm far more fluent in Python, I typically reach for Perl when needing to quickly handle log files, automate shell tasks, and prototype ideas. On the flip side, now that Python supports type hinting, function signatures are much more valuable, and overall I feel I can write far more robust tests in Python than Perl. Given that the direction of the project is to move from a collection of one-off scripts that just kept on growing to a tested, maintainable, modular codebase, Python is the better choice.

Re: Dwindling CPAN Releases

#118

Post by lifthrasiir »

isostatic wrote: post #109
lifthrasiir wrote: post #42

Earlier quoted context omitted.

> 4) Is normal (semicolons, braces etc) What was your first programming language? Because what seems like normal to you mostly depends on you.

> What was your first programming language QBasic, then Visual Basic for real programs. Look across a bunch of common languages - Java, Perl, Python, Javascript, PHP, and of course C/C++/C#/ObjC, braces + semicolons. Even Bash and Go have braces.

> Python

    >>> from __future__ import braces
      File "", line 1
    SyntaxError: not a chance
Back to the topic, while I don't think its ranking doesn't generally reflect the actual popularity, the TIOBE index [1] is a good definition of "common enough" languages. So let's see... oh! There are 5--7 programming languages out of top 20 that do not generally use both braces and semicolons! (Python [not-so-strictly-necessary semicolon only], Visual Basic .NET, SQL [semicolon only], Assembly language, MATLAB, Visual Basic and Delphi/Object Pascal [semicolon only]). I also happen to know less popular but well-known programming languages that do not use both braces and semicolons at all (ML, FORTRAN, Lua, Forth and of course all lisps). So please allow me to reword your claim: why should braces and semicolons be normal?

[1] https://www.tiobe.com/tiobe-index/

Re: Dwindling CPAN Releases

#120

Post by a3n »

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!

> Python packaging, which is a complete and utter disaster.

This is a huge barrier to entry for the first time or casual contributor. And when you try to figure it out (or figure it out again), you have to triage all the old and new overlapping documentation.

Post reply on HN