Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

541–550 of 573 posts

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

#541
post #480

Earlier quoted context omitted.

Catalyst was painful to work with in my experience. Just getting it setup was an achievement. Subroutine signatures as routes is an ugly hack.

I like catalyst,s dispatcher. And some of the pain of installing catalyst in the early days resulted in huge improvements to the change toolchain.

I honestly think the Perl community's attachment to Catalyst contributed to Perl5's demise. Mojolicious was a much better bet for the future of Perl.

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

#542
post #152

Earlier quoted context omitted.

Yes, of all the Perl books in my collection Tim Maher's "Minimal Perl" (Manning) is still the one I dip into regularly.

Thinking about this some more, I now feel really sad for anyone who doesn't use perl (i.e., almost everyone). Its immense power at the command line is something they'll never experience. Nothing today even comes close.

Even sadder that no-one will probably now start their programming career, as I did, with Perl as their first language. I feel honoured. At the time it was a toss-up between Java, which my house-mate was using every day to write banking apps at work, or Perl - that funky linguistic creation which granted you magical powers. No contest.

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

#543
post #410
post #399

Earlier quoted context omitted.

Both I would guess. Perl in serial is already faster to run than Python, and as soon as you start using threads Perl blows Python straight out of the water. The only reason that stuff like tensorflow or numpy is not as dog slow as the rest of python is that they are bindings to c(++) or fortran libs. Writing faster is debateable, but Perl has tons of niceties like embedded regex syntax, string interpolation, one-line…

I've been writing Python for a good while now and I haven't seen too many issues between minor versions. As for major versions...well...there's only been one significant change in this area (2 to 3) so I feel like maybe you're hyperbolizing a little :-)

A little. But there were changes from e.g. 2.5 to 2.7 and in the earlier 3.x versions that broke stuff. That never happened with Perl code here.

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

#544

Earlier quoted context omitted.

> Javascript was browser only until 2010 Depending on how you look at it you are at least a decade too late: we Java folks had the Rhino Javascript engine back in the late 1990ies, and it had an interpreted mode since 1998: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) I think it is even mentioned in the Javascript in a Nutshell book by David Flanagan (I haven't read it since then but I studied that book as…

True, I played with Rhino, Jack / JSGI early on, and did a couple projects with Aptana Jaxer around 2009. It was not really an option most developers would even consider, though. Node came out in 2009, and writing server-side JS was still a fringe practice for a couple more years, so 2010 is me being generous to avoid comments on the exact timeline ;) It really picked up mainstream adoption around 2011-2012.

Was Rhino ever anything other than a minefield that you were essentially pigeonholed into using for compatibility reasons or something similar? I have used it before but only because we had specific technical requirements that demanded we run Javascript on a server-side JVM implementation.

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

#545

Earlier quoted context omitted.

I loved Perl back in at the turn of the millennia. My first data science equivalent projects were in Perl. To this day I can not find anything quicker to prototype in. Python is slow in comparison. Perl is great for quickly hacking something together for R&D purposes. Also, if you need to write something custom, Perl runs so much faster than Python and R. I, like many people, stopped using Perl beyond a quick script…

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…

mod_perl was dropped with the release of apache 2.4 in 2012 (that's a major release, apache is not semver). If I remember well, it was kicked out of the apache repo.

mod_python was also abandoned around the same time. It simply stopped being developed and stopped working (it's crashing on python 2.7).

Basically applications stop running inside apache memory with mod_xxx for good reasons (it's unstable and crashing both apache and the app). Languages moved to a FastCGI interface or to have a standalone web server.

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

#546

Earlier quoted context omitted.

That certainly doesn't solve the problem of other people showboating their knowledge of obscure Perl sigils by using those ridiculous line-noise abbreviations in code you're trying to use and understand, so you have to look up each bit of obscure punctuation in its particular context in order to understand the code. If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to u…

If what you're saying is true, then why aren't similar criticisms raised against Ruby? Most of the same obscure variables are also present in Ruby. "If hard-to-read-and-remember syntax exists, people WILL use it" This statement doesn't appear to hold up under scrutiny.

I suspect that Ruby has almost no usage. I've only ever heard of using it in a handful of startups from the valley and it's only Ruby on Rails.

Wouldn't be surprised if Perl had a hundred or a thousand times more developers, it used to be popular in the 90 and 2000s. They are still alive today and commenting about it, even though they're probably working professionally in something else.

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

#547
post #432
post #401

Earlier quoted context omitted.

In Startup Land Rails is still thriving. Check out jobs on Angel.co and HN Who's Hiring.

Is there even a good alternative to Rails? As far as I know, it's still the best option there is for quickly building a MVP on the web if one isn't building a SPA.

Laravel[1] is pretty close, and PHP has some big advantages over Ruby for performance and deployment.

If you had told me 5 years ago that I'd be recommending PHP as an alternative vs. RoR I wouldn't have believed you, but the PHP world has improved in ways that I wouldn't have thought possible.

[1] https://laravel.com/

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

#548
post #524
post #427

Earlier quoted context omitted.

But if it's slow at really basic stuff users will ignore it, surely?

Slow is in the eye of the beholder. Sure, for some applications, Perl blows Raku out of the water. Add in some Moose, and the situation is not so different. YMMV.

On my 4-core i7 Macbook Pro parsing a 20Mb log file with a regex takes 9.4 times longer with Raku than Perl5. That's unacceptable. Adding Moose to Perl5 reduces the differential to 7.1 which is still huge.

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

#549
post #303

Earlier quoted context omitted.

What do you mean by efficient and cheap? It doesn't fare well in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... at least.

There’s something fishy about that report. It says it is presenting the fastest programs, but when I click through to “all perl programs”, there are faster (often by 1-2 orders of magnitude) programs / runs: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... For instance, the page you linked has “pidigits” at the top, and says node is faster, 2.58s vs 3.61. 2.58s is the slowest run of the fastest pidigit…

> There’s something fishy about that report.

No, there really isn't.

> 2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.

Notice column N — 2,000 6,000 10,000.

That's a command line argument passed to each program, controlling how many digits of pi are generated — the workload.

So, 2.58s for 10,000 digits and 1.04s for 6,000.

(And as it says, there can be a cold caches effect on the first measurements.)

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

#550
post #265

Earlier quoted context omitted.

> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.

I speak as someone who has programmed in Perl for over 20 years and at one point was the top poster on Perlmonks. The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age po…

> Perlmonks.

Perlmonks, in my view, is one of the main reasons Perl community went nowhere. The answer to a question should not be, excuse my french, an exercise in who can swing their dick in the most intricate and convoluted way while accidentally answering the question in the most obfuscated way possible.

Post reply on HN