Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

491–500 of 573 posts

Re: Perl 7 is going to be Perl 5.32, mostly

#491

Earlier quoted context omitted.

Both. Perl is around 20x slower than C for common tasks, while Python is around 133x slower than C for common tasks like looping, depending on what you're doing of course. Perl is the ultimate mockup language in that you can crank out code very fast and get good bug free results. It lets you write in the way you think where other programming languages force you to write a specific way. Ofc you can get good at Python,…

I don't think your performance numbers are very accurate. I've done a bit of Perl and a lot of Python and they're fairly comparable in most cases. Python is lightning fast for a lot of scripting tasks and I generally use very few libraries for day to day tasks because the Python stdlib is so good. Unless you're doing something really simple with Perl command line switches that operate over an entire file, I'd bet Per…

> I don't think your performance numbers are very accurate.

Food for thought.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Perl 7 is going to be Perl 5.32, mostly

#492
post #48

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. And on top of that, the sigils, refs, and `wantarray` systems means that fig…

I think that criticism that by learning perl one doesn't get any transferable concepts is bit unfair. Though I no longer program in perl, some of the things I learnt using perl has been useful later too. To list here are some of the "concepts" that I learnt using perl: regexes, some aspects of *nix system programming (fork, zombies, signal handling etc.), modular code organisation (writing/using perl modules), code documentation (aka PODs) imbibing importance of documenting the code. True learning some other language (say Java) would make familiar with other concepts (say OOP) but perl has its fair share of concepts that one can pick by programming using it.

Re: Perl 7 is going to be Perl 5.32, mostly

#493

Earlier quoted context omitted.

I wrote a lot of popular web apps in Perl, some that appeared in NY Times and Time mag. I quit around 2010 and went over to php which is easier. Wrote a great app and built a successful software biz around it. I think 2010 may have been when Perl 6 felt hopeless and there was no clear leadership or direction in the community. Mod_perl was the sh*t back in the late 90s for super high performance web apps on Apache. Th…

Perl’s lunch was eaten more by Ruby IMO. The bifurcation happened as the Perl programmers that wanted a more traditional OOP system picked up Ruby and the folks writing Bash++ oftentimes went to Python. These days it seems like Ruby is where Perl was in 2010.

    These days it seems like Ruby is where Perl was in 2010
It's more "mature" than "abandoned" IMO. I think it's in a solid place. A lot of Rubyists have moved on but so far, that's OK with me.

Unlike OP's experience with Perl, most legacy Ruby and/or Rails codebases are not too disasterous.

Re: Perl 7 is going to be Perl 5.32, mostly

#495

I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven. I…

> it is not the notorious "write only" language that many troll it to be I dispute that. I have worked with many languages, and Perl has always been one of the hardest to remember due to non-standard symbol abuse and a few strange semantics. There is a reason it has that reputation. Even writing it isn’t easy. I can describe the Python syntax after years of not using it. Perl? No way I remember it.

The problem is that it takes a lot of skill to write elegant Perl. The easy way is the one that produces write-only crap.

Re: Perl 7 is going to be Perl 5.32, mostly

#496

Earlier quoted context omitted.

Do you mean faster to write, or faster to run, or the combination of both?

Both. Perl is around 20x slower than C for common tasks, while Python is around 133x slower than C for common tasks like looping, depending on what you're doing of course. Perl is the ultimate mockup language in that you can crank out code very fast and get good bug free results. It lets you write in the way you think where other programming languages force you to write a specific way. Ofc you can get good at Python,…

Don't forget about PyPy, which may well be faster than Perl (I haven't compared them) or Cython if you're stuck with CPython.

Re: Perl 7 is going to be Perl 5.32, mostly

#497

Earlier quoted context omitted.

> it is not the notorious "write only" language that many troll it to be I dispute that. I have worked with many languages, and Perl has always been one of the hardest to remember due to non-standard symbol abuse and a few strange semantics. There is a reason it has that reputation. Even writing it isn’t easy. I can describe the Python syntax after years of not using it. Perl? No way I remember it.

The problem is that it takes a lot of skill to write elegant Perl. The easy way is the one that produces write-only crap.

The problem with any language like this is that you have to work with others, and if others produce write only code that's your problem, too.

Re: Perl 7 is going to be Perl 5.32, mostly

#498
post #299

Amazing. I literally first installed this on my laptop over 10 years ago. (Using Parrot)

If it was using Parrot, you probably installed Perl 6 (at the time, now known as Raku).

Ah you're right, it was 6. Amazing to see Perl still going after all this time!

Re: Perl 7 is going to be Perl 5.32, mostly

#499
post #128

Earlier quoted context omitted.

> How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter? With an asterisk: method(*array)

Right, which I sorta kinda get why coming from C - a *something is the thing pointed to by that something. How is that more understandable than @ vs \@ without knowing the language? My guess is it isn't.

Python is "relatively" consistent about * and being used to expand or contract arrays and dicts, respectively.

   a, *, b = [1,2,3,4]
   def foo(*args):
   bar(*[1,2,3])
all do "what you'd expect" from the single concept that "* is sort of pattern-matchy for an array".

But the more important bit is just that you don't have to prefix variables with @ and $. Python is optimized for writing code that acts on variables, while perl is optimized for code that acts on strings. While strings are certainly a common data type, most code isn't modifying strings directly. So optimizing for that case doesn't make a lot of sense.

Re: Perl 7 is going to be Perl 5.32, mostly

#500
post #435

Earlier quoted context omitted.

> A few years later one of the newer employees on the customer support team started spouting off about "python" and how it was so easy to learn. He was always blabbing about terms I'd never heard of like "generators", "list comprehensions", "decorators", etc. I looked them up and learned they were just abstract constructs with fancy names that are supported in most any language. So I just figured he was some idiot th…

> You don't see how this is the same thing? No.. but feel free to explain. With my friend that left for google, I was annoyed at him somehow thinking python was advanced just because he was using stuff you could do in any language only he thought more highly of it because of the names. He saw the light of having a clean syntax, I did not, but now I do. If you look at the history of python, it is an "engineered" langu…

> All of the lexer and parser code in perl5 are purely custom and intertwined.

I had given myself a torture by taking a look at perl5/toke.c [1]. Among dozens of lexical analyzers I've ever seen, it is the only tokenizer that uses a probablistic estimator to determine the extent of the current token (grep for the comment "this is terrifying, and it works"). Perl 5 is my go-to language for counterexamples in programming language grammers and syntaxes.

[1] https://github.com/Perl/perl5/blob/blead/toke.c

Post reply on HN