|
rje has asked for the wisdom of the Perl Monks concerning the following question:
Perl koan n. A puzzling, often paradoxical statement or suggestion, used by Perl hackers as an aid to meditation and a means of gaining spiritual awakening or something.
For the moment, don't think about the obstacles.
Imagine you could plug in Perl (perhaps defaulted to strict mode and built-in with Mo(o|u)(se)?) onto your browser when JavaScript gets too painful.
What possible benefits might that give? Assuming first that JavaScript is difficult for enterprise-scale apps (hence the existence of Dart, and frameworks like AngularJS), it seems that Perl would fill the part -- and has been stable for years, and has a wide user base.
Obstacles aside, can you see the utility and beauty of Perl5 on every browser - not just Opera?
|
Re: Perl koan #2300 (Perl in the browser)
by jeffa (Bishop) on Apr 17, 2015 at 19:27 UTC
|
Aside from the tools made available via CPAN, i believe there would be one benefit, and it would be the same benefit that i would receive if i could replace any language with Perl: Simply being able to handle text processing in one of the most natural ways that any language has offered me. Anytime i find myself having to implement solutions in another language, i always struggle with transforming lists of data into something new.
To be somewhat specific, i believe that URI parsing would be easier, dispatching would be more streamlined and capturing matches from regular expression operations would be less cumbersome. To be even more specific -- being able to plug in Spreadsheet CPAN modules would be heavenly, given the condition that this Javascript replacement indeed handles all of the necessary interactions with the DOM.
As for the definition of Perl kōan, i feel that it should respect the context of Zen, yielding something more along the lines of "a question, or statement, asked by Perl hackers to provoke the great doubt* and test a student's progress in programming." (borrowed from Wikipedia)
* why didn't I learn [language X] instead?!?! (because it just isn't as awesome)
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
| [reply] |
|
|
| [reply] |
Re: Perl koan #2300 (Perl in the browser)
by MidLifeXis (Monsignor) on Apr 17, 2015 at 18:01 UTC
|
| [reply] |
Re: Perl koan #2300 (Perl in the browser)
by sundialsvc4 (Abbot) on Apr 17, 2015 at 23:22 UTC
|
I very seriously doubt that you will displace JavaScript anytime soon on the web browser. And, I personally don’t see Perl as a very good contender because Perl depends heavily (and very successfully) on external, CPAN libraries. Much as I like the Perl language, I candidly do not see it being a good or easy fit for that scenario.
However, I do not recommend writing source-code directly in JavaScript. Instead, I would use a so-called “transpiler” which targets JavaScript, among many other targets. (A “transpiler” is a compiler which produces source-code as its output.) You are now able to write “correct” JavaScript much faster and more-accurately than you otherwise could, because you now have good compile-time checks, strong typing, and many other features of more modern languages. (And if you want to turn the same source-code into, say, a native mobile application for any of several(!) platforms ... you can do so.
A system that I think should definitely be on everyone’s radar right now is OpenFL, and also its base-language, Haxe. (Of course, that is off-topic to this venue.)
| [reply] |
|
|
"I would use a so-called “transpiler”...(A “transpiler” is a compiler which produces source-code as its output.) "
Do you know a transpiler that converts Basic English to Perl code that compiles?
Thank you very much for any hint and best regards, Karl
P.S.: For all with that conditioned reflex: Please see Re: poll ideas quest 2015
«The Crux of the Biscuit is the Apostrophe»
| [reply] |
Re: Perl koan #2300 (Perl in the browser)
by karlgoethebier (Abbot) on Apr 18, 2015 at 13:20 UTC
|
"Whether any existing language could be used, instead of inventing a new one, was also not something I decided. The diktat from upper engineering management was that the language must “look like Java”. That ruled out Perl, Python, and Tcl, along with Scheme. Later, in 1996, John Ousterhout came by to pitch Tk and lament the missed opportunity for Tcl." (Brendan Eich)
This sounds like it was taken into consideration. Fortunately he they didn't choose Scheme.
I remember also that i read somewhere years ago that the so called "upper engineering management" rejected Perl because they considered it as "too difficult".
Regards, Karl
«The Crux of the Biscuit is the Apostrophe»
| [reply] |
|
|
Java being as ugly as it is we should still be grateful it was not supposed to look like Basic.
Besides ... JavaScript doesn't share much with Java anyway. Basically only the things Java inherited from C.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
|
|
I think in 1996 Perl WAS too difficult -- for the browser to embed. Back in the day, it was heavy.
Correct me if I'm wrong, but today, it's durn near svelte. Or, at least, in the same general footprint as all scripting languages. Interpreters are light as a feather, due to support for video driving all the bloat in today's software I suppose.
Heck, there's no reason EVERY scripting language can't be plugged into browsers, all at the same time, into one blob.
| [reply] |
|
|
