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.
Perl 7 is going to be Perl 5.32, mostly
541–550 of 573 posts
Re: Perl 7 is going to be Perl 5.32, mostly
#542Earlier 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.
Re: Perl 7 is going to be Perl 5.32, mostly
#543Earlier 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 :-)
Re: Perl 7 is going to be Perl 5.32, mostly
#544Earlier 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.
Re: Perl 7 is going to be Perl 5.32, mostly
#545Earlier 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_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
#546Earlier 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.
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
#547Earlier 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.
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.
Re: Perl 7 is going to be Perl 5.32, mostly
#548Earlier 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.
Re: Perl 7 is going to be Perl 5.32, mostly
#549Earlier 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…
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
#550Earlier 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, 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.