
Perl 11 - totalperspectiv
http://perl11.org/
======
btilly
My perspective is that I'm glad that they are entertaining themselves, but
they aren't going to succeed.

It is easy to run a subset of Perl 5 faster than Perl 5. But when you add in
all of the features, beating Perl 5 on speed becomes hard.

It always was the dream to integrate Perl 5 and Perl 6. But cleaning up the
internals of Perl 5 until general people could work on it would be a several
month project that only a handful of people in the world have the expertise to
do.

And even if you did that, how do you reconcile Perl 5 reference counting with
Perl 6 true garbage collection? The two do not cooperate very well, and a lot
more Perl 5 code than you would think relies on things like reliable timing of
destruction. On this issue the community has generally been divided into
people who think that this won't be doable, and people who think that some day
a smart solution will be produced. To date, no smart solution has emerged.

Also Perl 6 was a wonderful dream to entertain people, but its real world
adoption is..limited. Like it or not, Perl 6 is effectively here and is named
Python 3. No, it doesn't look like the Perl 6 people thought it would, but
sometimes that is life.

~~~
rurban
Several misunderstandings. we are not implementing a subset of perl5, we are
continuing the development of perl5, which stopped around 2002. there are much
more features in cperl than in perl5. perl5 is stripping its features, because
they are not able to fix the bugs. cperl on the other hand fixes them, and
constantly adds new features.

we don't entertain ourselves for fun, we do it for the technical necessity,
because p5p is not able to, not willing, left the path to perl6 already, and
broke up all cooperation. we need to fixup all the damage done by p5p, because
nobody else is doing it.

perl6/rakudo is nice concept but not going anywhere. the architecture is just
too broken to be realistically fast enough in production. but who knowns. moar
is nice. and we've seen python 3 in production, and compared to that perl6 is
a godsend.

cperl will not switch to a gc soon, neither will it provide proper lockless
threading. simple goals first, like an object system, types, ffi, async/await,
regexp, match, hashtable, inlining, jit, symbol table, ...

cperl easily beats perl5 in performance, but is investing it into better
security checks. it's the only language with proper Unicode support already.
with the jit and the inliner it will match php7. i.e. not 20x slower, just 10x
slower, which is fine.

it's not a dream, it works and used in production. it is also recommended in
production over perl5.

rperl already matches C++ performance.

~~~
petre
Can I install cperl via plenv maybe? I'd like to test out production code on
it and my prime number crunching benchmark.

~~~
bmn__
[https://perlbrew.pl/](https://perlbrew.pl/) can do it.

    
    
        $ perlbrew available | grep cperl
        cperl-5.24.4
        cperl-5.26.3
        cperl-5.26.4
        cperl-5.28.0
        cperl-5.28.1
        cperl-5.29.0
    
        $ perlbrew version
        perlbrew  - App::perlbrew/0.84

------
nopacience
Perl5 is a great language. For internet and system related tasks it is great!
It was created long time ago and evolved over the years.

One thing is true, it had a lot of advantage over other languages for a lot of
years. However, now in 2018, other languages have also evolved and gained a
lot of traction. One example is javascript/node which is now being used more
and more. For a lot of time, a lot of frontend focused developers didnt really
want to try backend development... specially because backend development was
usually done in another language which was not javascript. So some never
really attempted to do backend development. However when node was released,
that opened a lot of new opportunities for the front end developers.

There are a lot of languages these days and many of them are capable enough to
do many types of projects.

The important thing is, some languages have a bigger concentration of more
capable engineers. One of these languages is perl. The perl programmers are
excelent. They have real close experience with the kernel and systems and
usually have great experience in complex backend tasks. Many are not as great
with front end development. Some are.

Some projects can be done and deployed by 1 single perl developer. The same
project if done in java for example might require more than 1 java developer.

The microsoft language creates a bubble and their developers sometimes dont
know universal technical terms, they only know the microsoftish terms. Ie.
they might not know what a "web server" is, but they know what "IIS" is. They
might now know what a "hash" is, but they know what a "dictionary" is. Perl
developers use universal terms.

Amazingly, javascript, especially ES6 is looking more and more like perl.
Those that know both will agree sometimes it reminds of perl.

There are many projects people dont know about that use perl behind the
scenes. But of course there are not as many perl programmers as there are in
other languages and thats one reason you dont hear much about these projects.

Companies embrace more and more the modern perl development. Java, microsoft,
node, python, ruby, etc are more popular of course. Specially because a lot of
banks use java and they push java via universities. In the past I have seen
labs with SUN machines on universities that teach Java. Microsoft also gives
students free software licenses via universities. Thats another reason
Microsoft and Java are very popular.

~~~
ricardobeat
There are no “universal” terms. You used _hash_ as an example, that’s already
less universal than calling it a dictionary - it’s a _hash map /table_, and
I’ve only ever heard this term from Perl developers.

~~~
rurban
That's because perl developers knew lisp and functional languages before and
therefore avoided the misleading term "map", which is an operator to apply a
function on a vector (=array) or list since the late 50ies. a map vs to map is
misleading.

"table" is shorter than "dictionary" and also describes the structure better.
A dictionary is mostly a book, or a list of keys (/usr/share/dict). prolog
also used the term "table" or "tabling" for its caching of backtrackings, what
we would call "memoize" or memoization via a hash table.

~~~
kazinator
> _perl developers knew lisp and functional languages_

It's a practical certainty that the vast majority do not, and its design (up
to Perl 5, at least) smacks of total Lisp ignorance.

"Map" is used in mathematics as a kind of synonym for "function", especially
from some arbitrary set to another one. If you assign the domain < 1, 2, 3, 4
> to the range < 3, 2, 4, 1 >, that's a map. We can draw it as two bubbles
containing labeled dots, and draw arrows between the bubbles.

This sense of "map" is widely used in computing. For instance "keyboard scan
codes get mapped to characters" or "a coordinate in the abstract canvas get
mapped to the viewport, which is mapped to the screen" or "the temperature
sensor is mapped to GPIO-s 13 to 17."

The "map" in Lisp's _mapcar_ is exactly this sense. The map is the function
that is being applied: _mapcar_ is using the verb sense: take the _car_ of
every cell through the function: i.e. _map_ each domain value to the range.
This is called "projection" or "mapping"; "map" is just the verb describing
what happens to each individual element.

~~~
kod
> its design (up to Perl 5, at least) smacks of total Lisp ignorance.

[https://groups.google.com/forum/?hl=en#!msg/rec.arts.startre...](https://groups.google.com/forum/?hl=en#!msg/rec.arts.startrek.misc/lHdCwSeQM8k/_AR_qcS1E2sJ)

[https://groups.google.com/forum/?hl=en#!topic/comp.lang.clos...](https://groups.google.com/forum/?hl=en#!topic/comp.lang.clos/edcyFOBLMeo%5B51-75%5D)

~~~
rurban
Yes. If Larry knew how a LISP is implemented, many internals would have looked
better. the symtab, the optree, the stack and esp. the lexicals. Just compare
to the ruby internals.

But at least he knew the terminology, and got the concepts right. In
opposition to php and python which failed miserably.

------
nickysielicki
Whenever I need to write a tiny script that tests the bounds of what is easily
done with just awk and Bourne shell, the tool that I next reach for nowadays
is Python. A few years back it was Perl5.

I'm not exactly sure why I started reaching for Python instead. It's so much
easier with perl to do things like backticks to call some utility, or to use
system() and easily deal with its stdout and stdin, and I never have to do a
Google search to figure out how to use a regular expression to process the
output (whereas I almost always need to bring up the doc page for Python's
re).

I think what it ultimately comes down to is tooling and the availability of
good libraries. I call "python3 -m venv venv", do an I'm Feeling Lucky google
search for "XXX library inurl:pypi", and the sky is the limit with how easily
I can make a script that does something relatively complicated. Comparing this
with perl5 isn't even fair. You might find a cpan module that does what you
want, and it might still be maintained, and you maybe can be bothered to
figure out cpanminus, but anyone who has used perl in the last 5 years will
agree, it's nowhere near as easy as it is with python.

Something that makes me optimistic about newer languages is that tooling is
improving a great deal. It also makes me somewhat pessimistic about newer
languages, though, if tooling is the primary aspect of a language that makes
it popular.

I've never seriously tried perl6 but I've seen enough of the language features
to know that I was really excited about it, at least at one point. I hope that
some derivative of perl can rise from the ashes, because I'm too stupid to
write actual lisp programs, but perl allows me to emulate what I imagine lisp
programmers must feel.

~~~
wvenable
I have two experiences telling with Perl and Python. Way back in the day, I
had job doing web development in Perl. I had no say in the matter, it was the
only choice available. And I actually used Perl enough to actually like it! I
mean I understand why people who like Perl really like Perl.

But just a few years after that and I could hardly even read Perl code let
alone try and code in it again.

Python was is opposite; I never coded in Python but I ported a Python product
SDK from Linux to Windows in a few weeks. I could read it. I could write it. I
made more mistakes with indenting than anything else. Even to this day, I
don't _know_ Python but I can muddle my way through and be reasonably
productive.

~~~
nightfly
Tangentially...

My organization maintains a couple of Perl web apps for internal purposes (one
that dates back starting in 1997). We do some occasional
work/improvements/modernizations on these. Mentally switching into "perl" mode
to work on these projects requires tons more effort then switching between our
other Bash/PHP/Puppet/Python codebases. And there are several sections of the
code I've shied away from modernizing because they use esoteric perl operators
that I don't use and don't really understand.

Not to mention that only a few members of our organization are really "fluent"
in perl, and teaching it to the newbies feels almost like a waste of resources
when they can be more productive faster using python which has ample modern
documentation and simpler syntax/conventions and well defined coding
standards.

~~~
ryl00
> Mentally switching into "perl" mode to work on these projects requires tons
> more effort then switching between our other Bash/PHP/Puppet/Python

That's surprising to me. Bash, PHP and perl seem to be closer to each other
than any of them are to python. For example, the use of sigils ($var) for
variable names in Bash/PHP/perl.

~~~
dotancohen
Bash / PHP / Perl superficially look like each other. Python code looks
different.

But Perl has many strange operators and conventions that do not do as
expected, or are foreign to the point of being unreadable to those who don't
use Perl regularly. Additionally, Perl can be made concise (one-liner) to the
point of being unreadable. It's been said that Perl is a write-only language
for a reason.

Contrast with Python, which I've had six-year-olds tell me what a program does
after only a few minutes' introduction to Python syntax. Though to be fair,
Python's List Comprehensions are in fact just as unreadable as Perl is.

~~~
C1sc0cat
I always make a point of documenting any of the more arcane parts of perl with
a reference.

------
wscott
Here is my unrelated to the article perl memory...

I fell in love with perl at school because it seems easier that
sh/awk/sed/etc... After I got a job I still used perl for everything. Perl5
came along and made a bunch of really needed improvements [1]

My problem was that at work they used rs6000 machines running AIX for
everything and perl5 didn't work on AIX. So I couldn't use the latest toys. So
I took time out and fixed dynamic linking so perl5 worked correctly on AIX.
[http://web.mit.edu/darwin/src/modules/perl/perl/ext/DynaLoad...](http://web.mit.edu/darwin/src/modules/perl/perl/ext/DynaLoader/dl_aix.xs)

Then later I got an email from Redhat offering me shares of stock when they
went public. This was because of my perl contribution. That was clearly some
shady scheme so I declared that email spam and threw it away.

1) But yes perl5 is quite a bit more complicated than perl4 and that bothered
a lot of people.

------
CJefferson
I'm always worried when a system seems to have no drawbacks. The strengths of
Perl 5 and Perl 6 and the speed of C? That sounds strictly harder than either
writing Perl 6, or the decades of work put into optimising Perl 5.

What are the limitations which make this achievable?

~~~
hardwaresofton
It's a little bit ridiculous, but you could actually have this if you
transpiled perl to rust :)

~~~
jlarocco
Or just transpiling into C...

~~~
tyingq
I don't think you can transpile Perl. Maybe a subset.
[https://www.perlmonks.org/index.pl?node_id=663393](https://www.perlmonks.org/index.pl?node_id=663393)

~~~
willthechill
RPerl is a Perl 5 transpiler. We started with a low-magic subset of Perl 5,
and are now slowly moving into the medium-magic parts of Perl 5 like regular
expressions and Moo(se) and databases etc.

------
sdegutis
The "Pluggable VMs" goal is just a bad idea IMO. The more generic you make an
interface, the more you ruin it. Tight integration may make certain things
harder, but it allows better control over the pathways for performance
optimizations, and keeps the implementation simple which inherently increases
maintainability. And in practice, only one of these VMs is going to actually
be used by 97% of people, and the other 3% can do the extra legwork themselves
in a maintained fork if it's really that important/beneficial to their niche.

~~~
laveur
Personally when I saw JVM as a VM for this I lost interest. JVM is not how you
make something as fast as C/C++. You want to make it that fast you should be
running it directly on a C/C++ code base. Thats pretty much how Python, PHP,
and other scripting languages work.

~~~
snapdangle
So the sight of pluggable VM backends, which includes JVM, somehow struck you
as a deadly limitation?

Funny, most other languages dream of having their core implementation runnable
on multiple VMs. Otherwise why does every successful language end up with a
separate-and-nearly-equal JVM implementation?

------
snazz
The third goal in particular looks like a bit of a moonshot... they offer
little technical information for how they’d actually achieve it.

~~~
sdegutis
What, "Runtime Performance Of C/C++ Or Faster" ? Obviously they can't rival
the speed of "C/C++" so they're probably going to go with "Faster", which
isn't a real language so it's going to be easy to beat.

~~~
koolba
I’m not familiar with the details but I’d wager they’re referring to JIT
compilation which can exceed precompiled native code as it can (in theory)
account for actual usage patterns.

~~~
jerf
That was a fun theory 15-20 years ago. We've now got piles of evidence it
doesn't work that way. JITs can accelerate slow languages, at a stiff RAM
penalty, but they still remain noticeably slower than faster languages.

Claims to the contrary at this point will require concrete demonstration.
Starting from the union of Perl 5 and Perl 6 is just about the worst starting
point for that goal I can imagine. (Not necessarily because "Perl sucks", but
because any such solution to that problem is probably going to require writing
the language with that goal from day 1, not taking existing languages as a
given. Or, like LuaJIT, cutting things that don't fit. And between Perl 5 and
Perl 6, there are sooooo many "things"....)

~~~
hyperpape
I'm with you about the overall point that Perl5/6 are not going to get C/C++
speed.

However, on the specific point, why do you think the JIT forces high memory
usage? In the case of Java, my perception is that it's the pervasive use of
boxed types everywhere and a standard library that's past its sell-by-date
that drives bloated memory usage.

Maybe my sense of things is a little skewed by my work: I work on server
processes that use gigs of memory. There, the resources for the JVM/JIT itself
usually use vastly less memory than the java objects contained in the heap
(probably 10x, and this is for a monolith with thousands of classes).

~~~
richardwhiuk
It's the pervasive requirement of a dynamically typed language, not the JIT
per say.

~~~
snapdangle
And yet Perl 6 has been droppping their performance floor by enormous factors,
with a lot of room for improvement still.

Everyone always shrugged at me when I explained that Perl 6 was designed to be
_able_ to be fast, with the ability to outstrip Perl and even other languages.

And now that it's happening? They are still shrugging, but its the
uncomfortable shrug of someone trying to shake off an inconvenient truth.

~~~
jerf
"And yet Perl 6 has been droppping their performance floor by enormous
factors, with a lot of room for improvement still."

Considering the literally-unusable performance that Perl 6 has had within
fairly recent memory, getting a lot faster hasn't been that impressive.

Plus, goals aren't results. I'll believe Perl 6 is natively fast when somebody
actually shows it outcompeting, say, Rust, on some _non-trivial task_ ,
written in the native idiom. No fair just sitting there in a loop and adding
integers, which is easy-mode for a JIT. Show me a real program, that I didn't
have to write in a magical subset of Perl 6 to get the performance (a problem
Javascript has, "fast JIT'ed Javascript" is a mysterious and ever-changing
subset, where your performance can be tanked at any moment by the smallest of
changes), and don't tell me about how it's a 100x faster than last year, show
me how it's faster than Rust _now_. Or, heck, just show me beating Go. I'll
believe when I see it. And I _will_ believe it when I see it. I have no
problem with that. But I've seen the whole "as good as or better than C"
claims a lot over the years, and the people making those claims are batting
nearly 0.000. (Rust is pretty much the only language with a chance.)

You seem to believe in the existence of a bunch of people who have somehow
wrapped their identity around hating Perl 6. That's not it; what you're seeing
is that the Perl 6 community burned through their goodwill literally years
ago, and now people are just exasperated when the topic comes up. If it helps
you to identify as some sort of persecuted minority, hey, go nuts [1], it's a
very popular option nowadays, but the Perl 6 community is _years_ past the
point where _mocking_ the potential customers into trying it is going to do
any good. You're going to need hard evidence... really, _really_ hard
evidence, probably rather a lot of it, more than you'll probably think is fair
but such is the hole the Perl 6 community has dug itself into over the
years... to convince people, not mockery.

[1]: Actually I think it's a terrible and very unhealthy idea; you'll find
none of the collected ancient wisdom of humanity will tell you that constantly
nursing a persecution complex is the way to wisdom or happiness. But such is
the zeitgeist of the era.

~~~
petre
> I'll believe Perl 6 is natively fast when somebody actually shows it
> outcompeting, say, Rust, on some non-trivial task, written in the native
> idiom.

If it beats Java then it's fine. I do not expect a VM language to be faster
than machine code. Rust is also overhyped. I did some of my own benchmarks and
Go and D turned out faster than Rust, or at least their maps/associative
arrays are faster that Rust's HashMap. Also, I won't use stuff that is not in
the stdlib in the benchmarks.

~~~
steveklabnik
> I did some of my own benchmarks and Go and D turned out faster than Rust, or
> at least their maps/associative arrays are faster that Rust's HashMap. Also,
> I won't use stuff that is not in the stdlib in the benchmarks.

Rust's HashMaps are intentionally slow by default. You could use a different
hash function with them if you want different properties. That means writing
your own if you don't want a known-good implementation, of course, but this is
expected and not really representative of Rust generally, which uses
associative arrays pretty infrequently.

------
tronbabylove
WebPerl looks cool. I wrote an interactive blog post [1] that guides the
reader through an exercise in scraping log files using a series of Perl one-
liners. I ended up delegating execution to a sandboxed Lambda function on the
backend, but running it client-side would have been a lot simpler.

[1]
[https://andrewstahlman.com/posts/ParetoPerl.html](https://andrewstahlman.com/posts/ParetoPerl.html)

~~~
mst
WebPerl is fascinating, I'm hoping at some point the author talks to the rest
of the perl community so we can compare notes.

~~~
pawelmurias
If we want to be extra crazy it should be possible to combine rakudo.js and
WebPerl to have Inline::Perl5 working in the browser.

------
Insanity
So is this by the same people behind 'vanilla' perl (Larry etc)?

I am assuming not but could not immediately find the information on the
(mobile) website.

~~~
mst
Not at all - and Larry has been working on perl6 for years, so the people
behind vanilla perl5 are a different group again.

The perl11 people are mostly disgruntled kooks who got kicked out of
perl5/perl6 development after yelling at everybody for not instantly believing
everything they said.

Meanwhile, actual perl5 and rakudo continue to progress.

~~~
pawelmurias
Aren't the perl11 projects an umbrella name for a bunch of different projects?
A large part of them aren't done by disgruntled kooks. Only rurban seems to
have some bad blood with parts of the Perl 6 community after his claims about
threads that don't interact with each others where mocked as magical by people
who didn't notice what he was trying to sell.

~~~
rurban
It was niner's project. His threads project was being wrongly attacked, and
nobody cared. It was a very strange and calculated attack, when they launched
their competing VM. I completely agreed with most of the criticism. But I
still think lockless threading would be great to have, as waiting for locks by
far outnumbers all CPU disadvantages with the broken parrot calling convention
and general problems there. People are still fond of Erlang also, and parrot
threading model and implementation is much better than Erlang threads or Go
threads and everything else but Pony's.

It's no bad blood though. Hype-driven development has it's place, see rust and
javascript. Throwing away unique technical advantages for pure marketing
reasons to unite the community against someone else didn't go fine with me. It
was no vilification as in p5p though. It was just silly.

------
willthechill
Hello everyone, I am Will 'the Chill' Braswell, creator of the RPerl
optimizing compiler and co-creator of Perl 11, along with Reini Urban and Ingy
döt Net. I'd be happy to answer any serious questions about the RPerl
technical designs or the Perl 11 project goals. Thanks for your lively
interest and continuing support of the Perl community. Obviously, the rumors
of Perl's death have been greatly exaggerated! :-)

------
User23
For me Perl is (awk|sh)++. It's a great example of the Unix philosphy, which
is, among other things, evolution based on practical experience rather than
top down theoretical design.

~~~
mst
I use perl5 like that, but honestly I sometimes script in Tcl because I'm too
used to applications perl.

For me perl5 is lexical scoping, closures, map/grep/reduce, and an OO model
that steals the best of python (ignoring ruby's crippled OO which involved
failing to steal from smalltalk properly) and then adds a first class
attribute system so you can declare attributes once and not need to re-type
the names to get a working constructor.

ES6 isn't bad, mind - with 'use strict' and 'let' it's close to a usable perl5
apart from the fact that its errors are runtime instead of compile time
(typescript helps there of course) and the OO is still relatively limited, but
I have some ideas using decorators that should bring the best of perl5 OO to
javascript since I've been unable to convince anybody else to steal our
features already

~~~
User23
I like to Joke that Perl is the ugliest most usable lisp ever. The way it lets
you play with the symbol table for all its various namespaces is extremely
powerful. It also exposes dynamic and lexical scopes in a way reminiscent of
Common Lisp.

~~~
mst
Co-signed.

People often complain that I write lisp in everything.

I mostly consider this a feature.

------
tokyodude
I don't understand the love for Perl. I wrote maybe 10k-20k lines of Perl
between maybe 1996 and 2003 and at the time I was happy it worked.

But ... more than any other language I've used it seems the most hacked and
confusing. Global variables abound. Crazy cryptic syntax. Ridiculous scoping
rules with hacked on workarounds.

I really don't get the continued love. Sometime around 2003 IIRC I got
introduced to Python and never looked back. When someone hands me a perl
script I don't look forward to trying to get it to work.

Speaking of which tho even Python now makes me crazy. NPM might suck for
various reasons but at least all deps are installed local to each project. I'm
sure there are secret incantations for doing the same in perl and python but
by default most stuff I download requires global libraries to be installed. If
there is one thing I love about npm is that it defaults to project local
installs and I have yet to run into a project that requires a global install

~~~
SmirkingRevenge
> NPM might suck for various reasons but at least all deps are installed local
> to each project. I'm sure there are secret incantations for doing the same
> in perl and python but by default most stuff I download requires global
> libraries to be installed

No magic required in Python at all for this. Just use virtualenv from your
project directory (don't bother with vitrualenvwrapper).

    
    
        $ virtualenv venv; . ./venv/bin/activate

~~~
tokyodude
IMO it *is" magic because it's not the default.

with npm I have to go through special effort to get anything to install
globally. With both python and perl I've read countless books and websites
over the last 20 years and never once ran into that incantation. They all just
say type

    
    
        install Chocolate::Belgian
    

or

    
    
        cpan Chocolate::Belgian
    

or

    
    
        python -m pip install SomePackage
    

etc..

~~~
doteka
That's just intellectually dishonest, it's part of the official language
tutorial...

[https://docs.python.org/3/tutorial/venv.html](https://docs.python.org/3/tutorial/venv.html)

~~~
tokyodude
Chapter 12!

------
xarope
I used to/still love perl, as it taught me a lot about regexp and hashmaps,
but I have to admit, going back to a perl script written perhaps several years
ago, and I struggle to figure out why I wrote it, the way I did.

Contrast with python (v3), my current preferred prototyping/scripting choice,
and it's still pretty clear about logic builds and data structures.

I'm now trying to decide if I should jump on the golang ship, but the library
ecosystem compared to python seems rather spare at the moment.

~~~
sacado2
You might like go, indeed. At first, when I tried go (just after 1.0 went
out), I wrote a small program with it and thought "meh". Yeah, the program was
doing its job, but the language was pretty boring. A year later, I decided to
improve that program, and that's when I really fell in love with the language.
I could understand everything I had written, even though I hadn't read any go
code for a year, and update it without any hassle. Moreover, my beginner
program was rather idiomatic in the first place. Pretty cool.

But, yeah, python's ecosystem is way bigger, so I tend to use both, depending
on the situation.

------
i_phish_cats
Never heard of webperl... I am consistently amazed every time I hear about an
ultra-complex C/C++ project being made runnable in a browser with emscripten
and wasm.

------
bemeurer
That is a _lot_ of yak shaving to be done

------
zebraman
Not sure if it is me, but for a long time I have kept away from anything perl
of moderate complexity. Package management used to be atrocious - it would be
slow, pull a ton of modules, compile them with the C toolchain, break for
missing dependencies and leave you wondering where the log was. Maybe it's
better now. But I wonder why on earth interpreted languages need mandatory C
bindings.

------
primer42
why...... just let old languages die. We've taken lessons from them, and
grown.

I know there is of are a good amount of financial systems written in COBOL,
but that's because no one has had the guts to rewrite them, not because COBOL
is some amazing perfect language.

And there are a plethora of other important, reliable systems that are still
in perl because no one has had the guts to rewrite them. But I would guess
that there are just as many that have been rewritten to python and ruby. And
many more that have been written for the first time in those languages. And in
the next few years we're going to be in the same place with those sacred cow
scripts written in python and ruby.

I'm not trying to say that code is wrong. But it isn't productive to claim
that we can slap a new version number on a library and claim it's going to
satisfy everyone's hopes and dreams. At some point, we need to let our cows
die, even if they're sacred.

~~~
mst
perl5 has more explicit and reliable scoping and more flexible and powerful OO
than python or ruby, and has had for a decade now. If other languages would
actually take the lessons, I'd've switched.

Recent javascripts have 'use strict' and 'let' (perl5's 'my') but the errors
are at runtime, not compile time, so in terms of maximising productivity perl5
is still my preference - though ES6 is almost an acceptable perl5, and I'm
working on some libraries to bridge the remaining feature gaps since
apparently nobody else actually wants working OO and proper DRY.

------
totalperspectiv
I had no idea any of these existed. And it looks like RPerl recently hit its
4.0 release... kind of looks like Nim.

------
collyw
Wasn't one of the original goals of Perl 6 to be able to run Perl 5 code?

~~~
lizmat
Yes, and in a way it still is.

The Inline::Perl5
([https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE](https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE))
module allows one to embed a Perl 5 interpreter in Perl 6 and transparently
call Perl 5 functionality as if it were written in Perl 6: this basically
makes 99.9% of CPAN available to programs written in Perl 6.

Many Perl 5 modules from CPAN have gotten a native Perl 6 equivalent as well:
[https://modules.perl6.org/t/CPAN5](https://modules.perl6.org/t/CPAN5) .

Earlier this year I tried to launch an idea: [https://www.perl.com/article/an-
open-letter-to-the-perl-comm...](https://www.perl.com/article/an-open-letter-
to-the-perl-community/) . But that met with much hostility
[https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter...](https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter_to_the_perl_community/)
, so I'm not really actively pursuing that.

------
make3
any reason to script with this over python/pypy/node/julia/R/ruby ?

~~~
dsr_
Such a reason would probably start with "I like Perl and have a lot of stuff
written in Perl that I would like to run faster."

------
picduniya
When we think about positive things, how great the world is and how amazing
our life is, we see more proof of it in the real world. What might be
considered normal will be considered great in this point of view. The same way
when we think about how bad everything is and how life is going against us, we
see normal events as being negative and small problems as being gigantic.

------
em-bee
perl 5 and perl 6 unite. news at 11!

