
Perl - the Detroit of scripting languages - petepete
https://speakerdeck.com/stevan_little/perl-the-detroit-of-scripting-languages
======
Mithaldu
Before you comment, please keep the following things in mind:

The talk was held by Stevan Little, the creator of Moose, the person who
experimented in Moe on a modern Perl 5, and the person who is currently
working on a Meta-Object-Protocol that can be put in the Perl core to make
good OO available out of the box, on which Moose, Moo and friends can built.
He dearly loves Perl and has done a lot for it.

This talk is not a blind troll, but a warning, an overview of his past efforts
and ends on a positive note.

Please do not comment before actually reading the entire thing.

~~~
jack-r-abbit
I won't comment then because the tiny tiny print was so painfully horrible to
read I only made a few slides in. He seemed to be making a point though. Just
the presentation was horrible.

~~~
Mithaldu
I agree that the font could have been bigger, especially since some people
have trouble with their vision. However i would also like to remind you that
probably all browsers capable of displaying the slides at all, also have zoom
controls available.

Lastly, i would like to thank you for refraining from commenting on the
contents. That is all i ask from anyone unable to take in the content. :)

~~~
jack-r-abbit
Of course. And by the time I zoomed enough to make the tiny text a comfortable
size, the slides had more than doubled in size... forcing the text (and slide
controls) well below the fold. So now I have to keep scrolling up and down to
read the text and see the slides. Not sure is Speakerdeck is just a crap
resource or this guy just messed it up. Either way, this is a horrible
presentation of thoughts.

------
guylhem
In perl5 :

\- I can have a prototype running in a matter of minutes

\- I have access to a vast library of modules doing everything I need (which
helps the former)

\- I write quick and efficient code

Do I really care about what other people think about the languages and tools I
use? No.

However, I _do_ care about efficiency and results

And, uh, working with a language that has been out for tens of years makes me
believe my time investment is safer than with the fad-du-jour JS
framework/library/whatever.

BTW, Maybe buying a home in Detroit (especially now that it's officially
bankrupt and will hopefully be able to break out of the unions commitments)
would be a good business move? That's a cheap place to bootstrap a business
for sure.

~~~
TylerE
I challenge your efficiency claims.

The benchmarks just do not support. I mean, roughly in parity with Python and
PHP, 20x slower than Clojure on average, 30x slower than Haskell, and on many
tasks 100x slower than C. Over the whole bredth of the Alioth shootout
programs, Perl trades places with JRuby as the slowest tested language.

~~~
guylhem
Most of what I do involves loading text files with fixed width records. A file
is between 500M and 4Gb. Then I do things with these records.

So far I have not found anything faster than perl unpack (1), but I would be
happy to. I plan to investigate Go soon.

Would you have another suggestion?

1 : or marginally faster, with the advantages negated by the time it takes to
write the code. However, a 10x improvement would be very interesting to me.

~~~
mkohlmyr
Well that's great... For your very narrow use case.. It is not however an
effective rebuttal to the points brought up in a more general case.

~~~
mhurron
Wait, you think opening and reading files of various sizes is a narrow case
for a language named Practical Extraction and Report Language?

~~~
TylerE
In the case of arguing for _general_ relevance, yes.

It's like saying: Hey, all I do is bang in nails! The hammer is only tool
anyone ever needs!

------
fusiongyro
> Moe is an attempt to show a way forward, not be a way forward.

I can certainly appreciate the desire to make something fun, either for your
personal edification, or to try to engage the constructive aspect of your
community, I have to wonder: is there enough manpower left in the Perl
community to handle all five-six of these revitalization efforts, while also
continuing the march to Perl 6 and maintaining 25 years of backwards
compatibility? The analogy to Detroit really couldn't be more apt.

In 1998 Perl had a substantial portion of all programmers simply because it
was the best free tool for a wide range of jobs. In 2013 nearly every problem
has a language more appropriate than Perl. You don't have a captive audience
anymore. These days, almost every language is marginal and makes a living by
cultivating a small but fanatical base. In order to play the new game, Perl
has to find a new pitch, and "we finally work like real modern programming
languages" is pretty weak. There are thousands of languages with real object
systems, real exceptions, real functions, etc. Until Perl throws its weight
behind something more interesting and substantial than "backwards
compatibility with filth" and "someday, it might be nicer" it can expect the
current trend of net emigration and a Detroit-like heat death to continue.

~~~
Mithaldu
> In 2013 nearly every problem has a language more appropriate than Perl.

Citation needed. Seriously, please stop making such broad statements based on
your feelings and opinions and instead please make an earnest effort to
separate objective facts from your subjective perception.

And just to address another point: Perl has multiple real object systems that
are inter-compatible (with one small exception), and are considerably more
powerful than the OO of Ruby or Python. The only real complaint you can level
against Perl is that they need to be installed from CPAN; which is not a very
useful complaint since all the useful bits in Perl need to be installed from
CPAN anyway.

~~~
fusiongyro
I'd say the onus is on Perl to be the best language for a niche, rather than
on me to provide a list of niches with languages better than Perl.

Besides that, language appropriateness is necessarily subjective. I love
Prolog and Haskell and use them all the time. My passion for them makes their
thorns seem small and easily avoided, but the reality is that those thorns are
sufficient to keep out a lot of curious people. I didn't really figure out how
to write a Prolog program that handled command line arguments until a month
ago. Prior to that, I would just run Prolog, consult my script and run my
function. Simple enough barrier, but one that would have kept most of my
friends away.

I think you took my "real X, Y, Z" list as a literal insult, which isn't what
I meant. I don't know Perl. I was just referencing the presentation, not
trying to sling arrows at Moose or whatever.

I do think that providing multiple options where most languages have one
option built-in is unnecessary cognitive load. One doesn't "choose" an "object
system" for Python--what benefit would one hope to gain? That the options are
compatible is nice, but it's indisputably more work for everyone than just
having one.

Having what are essentially language built-ins elsewhere available instead on
CPAN is worth complaining about, because if you're going to do things
differently from others, the difference should be motivated by something. That
something in Perl is backwards compatibility and the desire to provide lots of
options. The former is an explanation, not a rationale, and the latter
implies, again, a cognitive cost. When you spend my attention and brain power,
I had better get something in return. "Options" are only worth something if
the alternatives are worth choosing between. In the case of OO, complete
intercompatibility between them suggests the differences are minor; in that
case, why have them?

~~~
Mithaldu
The onus on one making broad statements and presenting them as fact is on the
one making them. Note, i'm not really asking you to prove your statement. Just
that you refrain from making such statements when you don't already carry the
proof and provide it along with the statement.

Also, no, i did not take it as an insult, just as a false statement from
someone with little knowledge of the subject matter.

> I do think that providing multiple options where most languages have one
> option built-in is unnecessary cognitive load. One doesn't "choose" an
> "object system" for Python--what benefit would one hope to gain?

That question is actually understandable and easily answered. Two benefits:

1\. More expressive power for example. Perl has Roles that function in a way
unmatched by most other languages (i say most because i don't know all
languages, i honestly don't know one that has roles as good as perl). They
make it possible to share methods among classes without needing to resort to
base classes and diamond inheritance issues, while still retaining full
introspection capabilities. Another system implements most of the sugar, but
leaves out some really complicated features in order to make it much faster.
Yet another provides the most speed by implementing the core in C. This makes
it a bit harder to debug, and less portable, but if you need massive speed,
there you go.

2\. The ability to try out different things and work out in real life
situations which features are needed and which ones are dead ends. This
ability is amplified by the ability to simply extend your object system by
writing more Perl. In comparison, Ruby has an ubiquitous one, but when they
desire to change it, they cannot easily test the changes large-scale in real
situations, and even if a change is undoubtably positive, they still have to
convince Matz first, and then implement it in C.

> indisputably more work for everyone than just having one.

Actually that is disputable. In the past it was the case, yes. But nowadays
they have converged on the same syntax and present themselves identically to
consumers. That means porting between different systems is trivial, and people
using a class don't even notice changes. And that is not just fluff. The perl
community has been doing this actively, for example here:

[https://github.com/rjbs/Email-
Sender/compare/52fcbbb9b6a1c4a...](https://github.com/rjbs/Email-
Sender/compare/52fcbbb9b6a1c4a0b54a031f9eb211c77c6ba8dc...0708a1582dfea1677741134d5ac9939032d04a06)

I'm not going to comment on your last paragraph because you wrote it while
having decided that what you wrote before is actual fact and it is thus very
flawed. Please stop doing that and use more question marks.

~~~
fusiongyro
You imagine that programming is more objective than it actually is. Time will
probably sort that out.

I appreciate your examples. I do think they would have been a better place to
begin.

As for cognitive load, it is a thing. Converging on a single syntax will
certainly reduce it, but as long as there is choice there is some. I do wonder
to what extent you can have meaningful variation within the same syntax.
Clearly it works for Perl and Perl users--I'm not trying to argue from first
principles that it is impossible or stupid, only that it has a cost and that
costs must have benefits or they are unnecessary. You apparently see some
logical fallacy in that, but there isn't one. You just know the benefits and
see the costs as reasonable. There's nothing wrong with your position on that,
but you should have taken my words as an invitation to share what you know
rather than blandly issue orders, a singularly unhelpful kind of discussion.
An invitation was my intention, and I am sorry that I failed to convey it
adequately.

------
veesahni
For me, the biggest pros for Perl were it's extreme expressiveness and the
power of CPAN. However, it wasn't without it's warts - odd threading, weird
sub signatures, faked OO, etc .. I've spent a lot of time explaining the
nuances of these warts to others, which only made me realize how serious these
issues are.

I was sold on the promises of this thing they were calling Perl 6, that was
supposed to break backwards compatibility and "fix all the things" in one
shot. I followed it for a couple of years and then something happened...

Somebody pointed me to tryruby.org - I discovered a language that was more
expressive than perl, followed similar values (i.e. There's more than one way
to do it) and opened me up to a new world of meta programming. I embraced &
absorbed it and today it's my weapon of choice for most of what I would have
reached out to Perl for.

~~~
Mithaldu
You got two things wrong there:

> weird sub signatures

No core signatures, but modules on CPAN that make signatures available.

> faked OO

The OO in Perl works almost identically to the one in Python, and i assume
Ruby is similar too. The difference is that OO syntax sugar is implemented in
core in Python and Ruby, while in Perl it is implemented in Perl directly and
available on CPAN but in core.

There's nothing fake about it.

As for your conclusion: I have the strong suspicion that the difference lies
less in the language itself [1], but more in the fact that with tryruby you
had a modern learning resource available that taught a good coding style;
while pretty much all Perl learning written before February 2012 are mainly
based on material originating in the early 90ies. [2]

[1] The main Ruby implementation doesn't even have multi-core-capable threads,
but uses something that's basically a VM-level event system:
[http://en.wikipedia.org/wiki/Green_threads](http://en.wikipedia.org/wiki/Green_threads)

[2] [http://perl-tutorial.org/](http://perl-tutorial.org/)

~~~
veesahni
> The difference is that OO syntax sugar is implemented in core in Python and
> Ruby, while in Perl it is implemented in Perl directly

I see what you mean. However, that syntax sugar is what people are used to
from other OO implementations. Lacking that sugar meant that I found myself
regularly explaining the workings of blessed hashes.

~~~
Mithaldu
Yes, that is true. I only meant to correct your use of fake. In the past OO
was a holy pain in the behind in Perl. However, nowadays that has changed
considerably, and with Moo [1] we have a reliable, pure perl, fast, and easy-
to-use sugar layer for OO. :)

[1]
[https://metacpan.org/module/Moo#SYNOPSIS](https://metacpan.org/module/Moo#SYNOPSIS)

~~~
veesahni
I'll check out Moo :)

------
simias
Dozens of slides of memes, curses and buzzwords. The state of communicating on
the internet in 2013.

Can someone more patient than I am tell me if there's some actual content in
there?

~~~
mahmud
tl;dr: _& nbsp;_

The talk might have been different, but there is nothing of substance in the
slides.

~~~
davidw
I haven't even looked at these since it doesn't interest me, but I think
posting slides is kind of bizarre: if they're done properly, there _shouldn
't_ be anything much of substance in them.

~~~
mst
Generally at this point the only reason I post slides at all is for people to
leave open and click along while they're watching a video of the talk.

------
antitrust
A few thoughts:

Trends come and go, but it's the general purpose languages that remain.

Perl seems to fit in that space that was occupied by the various BASICs in the
1980s, meaning that it was the best glue for everyday tasks. It's quick to
write, has the right tools, and plays well with system tools.

In general, in my experience, it's the quality of staff and not the tools that
makes the difference. Good management, coders and business-side analysts make
a much bigger difference than what language you use.

In general, in my experience, few experienced Perl programmers use vanilla
Perl. Almost all of them rely heavily on libraries and write code according to
their own knowledge of what's most efficient.

Be wary of the world of trends in programming. It is as fickle as trends in
education, interior design or nutrition. Then again, I'm still waiting for the
Pascal comeback.

------
jimmytucson
Perl is actually far from abandoned and I would venture to guess (based on no
facts and figures but my own personal experience) that there are more lines of
Perl in production today than Python or Ruby combined.

But how can that be?! Building a large scale application with Perl would be
like building a F111A Aardvark out of duct tape! Quite simply, because Perl is
the perfect duct tape. Too many people (knowingly or not) think of Perl as a
crappy version of Python when it's actually shell scripting on steroids.

You see, way up here, where projects are constantly in development, paradigms
are constantly shifting, and people are building new and exciting things, Perl
is an unwelcome high school acquaintance who shows up at the party and makes
everybody feel awkward and bad. But way down there, where people are just
trying to keep Sputnik up and running until the Soviet Union collapses, Perl
is a rock star! If it's too "small" for Java but too "large" for .ksh -- guess
what, use Perl.

In my opinion, if you want a scripting language with function signatures,
little to no support for UNIX commands, real object orientation (Moose), yadda
yadda yadda... just use Python. No one's going to blame you. Larry Wall's not
gonna feel bad. You have a right to your impact gun and bolts.

Just leave my duct tape alone.

------
dj-wonk
To add two different thoughts:

* Perl is widely used and has inspired many other languages. These are not small accomplishments.

* How many major revision bumps can a language undergo before it loses its identity? How many breaking changes are allowed before it becomes something else? Perhaps the name is about something more than the language as crystallized at any one point in time? But how do you convey that to the community as the language changes?

~~~
Mithaldu
To the last point:

I'm fairly sure that the identity of a language is defined by its teaching
materials.

Up until 2012 all Perl teaching materials were largely based on text written
in the early 90s. And as well, any newbie program tended to look like it was
almost Perl 4. This was in spite of there being a concensus and strong effort
to push among the active Perl community that modern Perl was the way forward.

Then two things happened: The books Modern Perl by chromatic and Beginning
Perl by Ovid were written. I used these two books to teach newbies and their
code is nothing like the code of newbies of old.

If these two books reach enough penetration, they will change the identity of
Perl.

~~~
VLM
"Modern Perl by chromatic"

I have a copy on my desk and this cannot be emphasized enough that one inward
facing book on what boils down to style and good taste, has already had more
impact on the language than the last two decades of outward facing
comparisons.

Insert forest and trees analogies in that we've got way too many presentations
over the decades about how one individual tree needs trimming or fertilizing
or bonsai treatment as compared to how our neighbors orchard does the same,
but not enough real forestry management presentations.

------
williadc
tl;dr - the author wants someone to re-write Perl 5 and CPAN to add some
features he likes and remove some features he doesn't like.

~~~
nmcfarl
My tl;dr - The author says people are currently writing "perls" that add
features that he likes and remove features that he doesn't like - and he would
like us all to consider them all the perl not just the one binary. IE the
future of perl is many runtimes, that are slightly incompatible.

~~~
Mithaldu
> IE the future of perl is many runtimes, that are slightly incompatible.

That is already the reality of Python and Ruby. ;)

~~~
dragonwriter
> That is already the reality of Python and Ruby.

And, Common Lisp and Scheme and Java and C and C++ and SQL and Pascal and
BASIC and C# and JavaScript and ... pretty much every language that is (or
ever has been) both popular enough to have interest enough to support multiple
implementations and not proprietary to a single vendor.

------
PleaseBeSerious
I switched languages 6 months ago. I now make more than I did as a Perl
developer for 7+ years.

------
codeboost
The reverse sounds nicer :

Detroit - the Perl of cities :)

------
ape4
I like the "bikeshedding" idea.

------
runn1ng
I can't wait for Perl 6.

</irony>

~~~
mjolk
Whose irony tag are you closing? I looked at the page source and couldn't find
an opening irony tag.

~~~
runn1ng
<irony>

^^ here you go.

