Run Perl in the browser with WebPerl
webperl.zero-g.net
webperl.zero-g.net
Perl has it's fair share of syntactic oddities and mistakes, but once you understand the underlying themes and goals of the language,and how a few core differences from almost all other languages inform it's use (statement context!), it comes across as very thoughtfully designed and implemented. That isn't always apparent at first, and some people disagree with the design goals, but it does feel like it makes sense.
Javascript rarely feels that way to me. The more I can rely on only those new features the more I can fool myself into ignoring the ugly warts underneath, but they pop up whether you want them to or not (equivalence testing, null and undefined, etc).
If you stray from a simple web-server with routes, you are relegated to reading Mojo source code to identify how to integrate esoteric middlewares (I'm looking at you, JSON-RPC 1.0 and Azure AD). Weirdly, it shares this "no help off the golden path" problem with Varnish Cache's VCL docs.
However, Mojo is still the most full-featured library out there, and you can easily bend it to your will. Hypnotoad is a process-based worker pooling engine for Mojo; its performance is not terrible and debugging issues is easy.
But, I like Mojo, nonetheless. It's really concise and does a heck of a lot with a vanishingly small amount of code (it's inspiring to see Perl excelling at something pretty modern, honestly).
We used this old framework on a major corporate website I used to work on.
I’ll note that running Perl in browsers has long been possible, if the browser is MSIE on Win32 with Perl installed. I deployed a client-side Perl “solution” at my university in the 90s.
http://docs.activestate.com/activeperl/5.22/perl/Components/...
Prepare for Flash 2.0.
Because some sites/people will implement a new deployment scheme that implements a new layout engine in a canvas, and use that to "prevent plagiarism" or protect data. Think an online retailer preventing price scraping, or some site that gets visions of grandeur about a more multimedia rich experience (like every photographer's website 15 years ago), or wanting to prevent ad-blockers or use dark patterns that browsers finally actively prevent.
There are business incentives for all these, in some cases if not necessarily for the end user, then for a company to trick end-users into thinking they need ("click here and for $10/mo more we'll add our patented anti-scraping/copying technology to your site!").
It's sort of like saying that shipping an interpreted language file is just as hard to reverse engineer as a compiled binary. Sure, you can make the interpreted language harder to read by obfuscating it, but it's hard to compare with straight up machine code or byte code.
In addition, all the obfuscation techniques feed into each other. WASM through a canvas to protect content isn't all that useful if the content is built from JSON which is easily visible. But if that JSON is itself encrypted/obfuscated, that's harder. But determining the obfuscation method from JS code (minified or not) is much easier than determining it from machine/byte code. In both cases enough skill will bypass any mechanism since it's locally running code, but all you have to do is raise the bar high enough to dissuade most. An occassional switch of some underlying obfuscation methodology to make those bypassing have to continuously work at it, and you've got a system that does most of what's needed.
In the end, it's just like door locks. There's lots of technology that can be used, all of it is defeatable in some fashion, but there's things you can do to make it not worthwhile for all but the most determined. In the case of canvas content rendering, I think WASM might be the tipping point that makes this really feasible. I guess we'll see, it's not like there's really any way to stop it (nor is it clear we should try).
Imho they should just fork Perl 6 and continue developing Perl 5.
Perl 6 is a nice experiment and may hold some ground in the future, but is not a practical tool or something in the same space as Perl 5 today. It's very unfortunate naming IMO.
I'm not using it in production, but I think one reasonably could. I suspect we'll be able to start shipping Perl 6 code in a couple of years (my company builds installable applications, and we don't want to maintain Perl 6 packages ourselves, so we need our target platforms to have good packages for Perl 6 available before we can ship it).
Perl 5 gives you a good set of primitives, a lot of flexibility, and then tasks you with using this mix of core types, context, and namespaces to do what you want, how you want. The actual things you need to know to reason about most code you encounter is fairly simple though, and if not immediately known to the average Perl programmer, they'll have a good idea to figure out what it is, and what the usual suspects are for really weird stuff (I'm looking at you, indirect object notation).
Perl 6 has so many core, fundamental things to know, that in any piece of code I might encounter, the number of things that could be in use is staggering. I've read the Perl 6 Synopses, end-to-end, years ago. I remember a lot of what's in there. Hell, I was really excited about those features when reading about them. When I saw them start to be put into practice, that's when it crystallized for me. Specifically, I started having real doubts when I saw Larry implement a solution for Rosetta code in Perl 6 using a sigilless[1] style. What's the point of these? Just to represent special characters, as in the example? But they're also constants, because they have no containers? And there's also defined constants, but those have sigils?[2]
Don't get me wrong. Perl 6 has some (a lot!) of good ideas. I mean, it sort of has to, since it actually has all the ideas. That's the problem. Not all ideas area good, and even if you only selectively implement all the good ideas, they aren't always still good when they are forced to coexist with each other.
At this point I see Perl 6 as a really interesting experiment to see how some of the more interesting ideas work in practice when used in a less opinionated language. I'll probably do some simple stuff in it eventually (I mean, I'm still fairly familiar with it just from following it for almost 15 years), but I don't have high hopes for using it for any professional projects, or for using it on a project with many other contributors. That's okay, I never stopped writing Perl 5, it's what I do for my day job, so I'm not missing it too much.
That said, I still have a very soft spot in my heart for Perl 6. It's an extremely quirky and wonderful language when viewed purely as a language and a thing to play with. That I think it won't ever see professional success is fine. There's lots of things in life that are great without that, and there's lots of types of success other than that to aim for. And that's totally okay.
1: https://docs.perl6.org/language/variables#Sigilless_variable...
2: https://docs.perl6.org/language/variables#The_constant_prefi...
The only thing I couldn't find at first was a good editor for it. I would up with ... IntelliJ. The only minor thing that Community Edition doesn't have is editing CSS, and I can live without it. There's a Perl plugin that does good completion and navigation (Find Uses / Find Definition, semi-intelligent completion).
And that's what I am using now for prototyping.
It's not intellij, but it covers most bases.
There's lots of discussion on HN of languages that see less use than Perl. Often the reason people invest in them is that they think learning the lesser-known/used language might offer them a novel view of development or provide extra capabilities in some niche. It isn't particularly different with Perl, although there is the difference that many devs think they already know what they need to know about Perl even if they've never done anything serious with recent 5.x or 6 (or at all).
> Imho they should just fork Perl 6 and continue developing Perl 5.
[insert "what if I told you" meme here]
[insert "what if I told you" meme here]
I meant rename Perl 6 into something else and develop Perl 5.xxxx into Perl 6....
Forking an existing, newer language just so you can do what amounts to a meaningless, useless major version bump of an existing, established language, is pretty much the exact definition of a breaking change for frivolous reasons.
That doesn't prevent launching a new ship.
> and changing it now would just massively add to the confusion ...
There are two types folks who care about Perl - both are in dwindling numbers. The old-timers -- they never have and will never be confused and clearly understand that there is urgency for that "ship", now more than ever. The new-comers and those have deserted the ship and looking for an opportunity to come back -- they are massively confused as hell right here right now.
There is only one real reason for not launching that ship -- Larry Wall has taken that sailed ship long ago and will not come back (admit his mistake).
To my understanding, he's admitted his mistake. That doesn't mean that after this much time, going back is the best solution. There are major positives and negatives to all options, so at this point people are just letting it stay as it is rather than force it into something that could be even worse. People have had well over a decades to come to terms with the naming, and coming out with Perl 7 (or taking the name Perl 6 back) aren't really going to help with anyone that's already confused.
Perl 5 and Perl 6 are still both advancing on their own paths, it's not like either one was actually stopped because of this.
No, but launching a new ship is a bad idea if your reasons are frivolous. It's a waste of resources. Most people seem to think that resources like labor and trust are magical and grow on trees in community-driven projects (especially when it comes to executing on their pet-projects or desired features), and I can tell you they don't.
> The new-comers and those have deserted the ship and looking for an opportunity to come back -- they are massively confused as hell right here right now.
What exactly is so confusing about "Perl 5 is a stable language that has been in use for decades, and will remain developed, and Perl 6 is a backwards incompatible evolution that is independent". You're saying things like you're "confused as hell" but it's not really hard to figure out, and it's not even clear how hard you actually tried. The Perl.org webpage even literally states "Perl 6 is a sister language, a member of the Perl family, that is not intended to replace Perl 5".
Frankly when people say things like this, I'm often convinced it's not actually out of genuine confusion, but often feigning ignorance to make a point, to the level of being child-like. Computer programmers _love_ making everything complicated (especially over small trivialities that "could" be "fixed" if we "cared enough") -- but "Two similar things share a common family name" is not very complicated, to pretty much anybody.
And here's a counterpoint: I haven't written Perl in nearly 10 years with any regularity, and I recently started a new project because I wanted to write a small web app. Here's what I did: I searched "Popular Perl Web Frameworks" and came across Mojolicious. I then saw it was a Perl 5 framework. Then I followed the tutorial and wrote a web application and I was done. There was no "massive confusion" about it.
> Larry Wall has taken that sailed ship long ago and will not come back (admit his mistake).
People in the Perl community have admitted for a very long time that there were many mistakes made in the development of Perl 6, including the poor naming convention that maybe ties the languages too closely, when they are quite different. I'd say the mistakes are well known, even 10 years ago when things were far different.
> What exactly is so confusing ...
I can see you how you don't understand; unfortunately, you are having trouble understand the other way.
> Frankly when people ...I'm often convinced it's not actually out of genuine confusion ...
It doesn't take you a few sentences away to getting close to name-calling. It is very difficult to listen at this stage.
---------------
> it's not even clear how hard you actually tried.
You are putting me in the wrong camp. I love Perl and I have been using Perl for over 10 years. I am not confused. Perl is Perl5; Perl6 is an experiment that hasn't succeeded yet, And Perl6 is irrelevant to Perl5 from a language point of view (although, not vice versa).
I have students that I want to show Perl to. They, being young and natural, will not put their heart to Perl 5 if Perl 6 is out there -- different alright, but Perl 6 surely is newer and must be the future, right? Then they find the state that Perl 6 is slower than Perl 5 and obviously less mature, so they wait -- by moving on.
I have colleagues and old admins who are looking back but all their current thought are: Perl is dead, how is Perl 6 doing.
> People in the Perl community have admitted for a very long time that there were many mistakes ...
Acknowledged mistakes that have no action/effort of correcting them are not admitted. Sunk-boat fallacy is just a n excuse for not admitting mistakes.
Amen. I’d love to see a rebrand to Rakudo and Pumpkin, where the latter is Perl5 plus some long-overdue backwards incompatible changes, but also 99% compatible.
I think if you start with the state of CPAN and work the problem in reverse you might see what people are wanting.
can fuck right off.
However, nobody new (read: young) will want to learn a language that is not able to receive a major version bump. (notable exception I guess, Python).
A language that can't receive major version bump will be (is?) perceived as a dead language.
Perception does matter. Ads, marketing, etc etc, the world is run by perception.
I'd even go further and say that, in my experience, your mind is likely already decided, as well as the minds of many others, when it comes to choices like this. Whether or not they renamed Perl 5 to Perl 7 or whatever is not really going to make a difference in the long run and no perceptible marketing changes will change that to you... People on places like this website already like to talk about other examples such as how "Ruby and Rails are dead" despite them still being immensely popular and widely used today still... Their mind is decided well before any actual facts of the matter come up, even if Rails has more open bug-reports than they have users. No amount of new marketing will change it meaningfully, because much of the decision is driven by cultural aesthetics, and aesthetically, it's just not cool anymore. We're all prone to it, and unfortunately, it is not always a fully rational or predictable path, either.
Some amount of marketing matters for software projects, a lot of it in fact. But at some point you have to call a spade a spade, and decide when you're just chasing meaningless fads for something that won't happen, based on technical marketing alone.
[1] Which is almost exclusively what everyone 'means' when they talk about this sort of branding/marketing stuff, if you asked me as a FOSS developer. Nobody can ever conceptualize "successful, accomplished, and with a healthy life", because by every measure Perl is a wild success in all these metrics, beyond what most software could ever dream of -- they can only conceptualize "total failure" AKA "dead language" and "wildly successful beyond all measure in all circumstances, forever".
Have you ever actually been interested in a language and looked to see whether it was able to have a major version number bump or not prior to deciding whether or not to pursue it?
It still seems to be a major effort to get people over to Python 3.
Perl5 and Perl6 are the same situation: on first glance they seem closely related, but they're not, end of story. It's been clear for a long time that Perl6 is not a replacement for Perl5, it's a different language from the same creator. It would have been great if it were named something else, but changing its name is something its community would need to do, and won't erase the years of history that already exist.