
The Mid-Career Crisis of the Perl Programmer - pmoriarty
http://www.modernperlbooks.com/mt/2014/02/the-mid-career-crisis-of-the-perl-programmer.html
======
chaostheory
> tdlr: you should have spent your time learning how to write a CRUD app and a
> mediocre template system, dependency injection framework, and ORM in Haskell
> Rails Erlang Scala Rails Python Node Clojure Julia instead of mastering one
> tool and learning how to solve problems.

This is a general rule for everything. The animals that survive are the ones
that best adapt (well constantly adapt) to an ever changing environment, since
change is the only constant.

This is the one major thing I got out of being a computer science major: the
language doesn't matter and you shouldn't tie yourself to just one language
(i.e. be language agnostic). They drilled into us that we should constantly
learn new languages for both fun and profit.

~~~
increment_i
As a 'hobbyist' programmer who makes his money outside of the software game,
this is something I've really taken note of. And I have to say the programming
tech treadmill is one of the most cringe inducing phenomena I've ever
witnessed - particularly in scripting languages. Software folks tend to see
themselves as futurists in the fast lane, and as a Hacker News-er I tend to
carry myself this way as well. But I kid you not, I can't count the amount of
articles I've come across where the title is 'X tech is the new ish! - so
rockstar lol' and the article is a simple example of http routing or process
spawning. It is SO easy to get caught up in this drivel when you're starting
out as a programmer.

I've since learned to use programming languages to solve problems I care
about. If that makes me the forever-novice then I'm cool with that.

~~~
mrgriscom
I think this phenomenon is an artifact of the media that we as programmers
consume. The easiest way to become an programmer celebrity is to build tools
(languages/frameworks/etc.) for other programmers. Many programmers of equal
skill are out there programming to solve actual problems, but the HN sphere
and like are awash with people programming on programming itself. Which, while
is surely intellectually stimulating, does seem a bit 'meta' and removed from
why we're all doing this in the first place. But people who work on
programming tools get the most press because those topics appeal most broadly
to the audience of their peers. Then people in that audience see those topics
as 'hot' and focus their energy on them. It's a reinforcing cycle. It reminds
me of the ideas in this article: [http://slatestarcodex.com/2014/12/17/the-
toxoplasma-of-rage/](http://slatestarcodex.com/2014/12/17/the-toxoplasma-of-
rage/)

~~~
oinksoft

      > programming on programming itself ... does seem a bit
      > 'meta' and removed from why we're all doing this in the
      > first place.
    

I heartily disagree, and think that tools vs. "actual problems" is a false
dichotomy. Software design/engineering is very much its own discipline. A good
API/framework/whatever can lower defect rates and generally make your software
more coherent and maintainable. That saves time, money, and headaches. We
should absolutely care about the tools we use, because nobody else is going
to, hence "programming on programming." Attributing that to a quest for
"celebrity" is cynical, and I don't see how you can blame programmers for
seeking a good professional reputation by creating tools for their peers.

------
dkarapetyan
I used to think there was an idiomatic way to write code in a given language,
that following conventions and community guidelines was a good thing, that
languages had a natural flow to them and writing against the flow was a bad
thing. These days I focus on solving problems. Idioms, conventions, languages,
etc. are all bullshit. Everything is subservient to solving a problem. Ember
or Angular? Don't care. Ruby or Python? Don't care. C# or Java? Don't care.
Haskell or F#? Don't care. Statically typed or dynamically typed? Don't care.
What is the problem we're solving? Now we're getting somewhere.

~~~
mgkimsal
"Everything is subservient to solving a problem". Correct. And writing good,
clean, idiomatic code _usually_ helps you avoid introducing code-level
problems when trying to solve your "real world" problem.

You're not wrong so much as perhaps just more experienced to the point where
caring about the idioms isn't much of an issue any more, not because idioms
don't matter, but because you're writing code that's good enough. i've found
the 'standards' and 'idiomatic code' to be useful not so much as a benchmark
for "you're 100% wrong if you don't do this" but "you're creating another set
of problems for yourself if you're not careful".

"Ember or Angular? Don't care. Ruby or Python? Don't care. C# or Java? Don't
care"

Well... you may need to care, because one of the problems you may have to
consider is long-term maintenance as well. Using Ruby for "project X" in a
team of 15 .net developers with extensive C# experience, simply because "Ruby
is best for this problem" is probably just trading one problem for another.

~~~
vinceguidry
> Well... you may need to care, because one of the problems you may have to
> consider is long-term maintenance as well. Using Ruby for "project X" in a
> team of 15 .net developers with extensive C# experience, simply because
> "Ruby is best for this problem" is probably just trading one problem for
> another.

I'd like to reiterate this point. At some point, somewhere down the road, a
different programmer than you is going to have to read your code and try to
figure out what it does. If you don't learn your languages well enough to be
idiomatic, then you'll be contributing to technical debt load instead of
helping to pay it off.

Unless you're doing big enterprise consulting. That's an entirely different
sport.

------
bane
Learn to be a "programmer" not a "X programmer".

I recently sat down to learn Python a bit. Inside of a week I had useful code
up and running. I'm sure it was non-idiomatic and I'll laugh from
embarrassment a year from now, but screw it, it works, and real people ship.

The last code I wrote before that was in Java. I had to relearn it after a
decade of non-use. Real people ship.

More recently I wrote some more Python code, it's all hacky and terrible, I
can feel it, but you know what, it shipped and has kept a half-dozen people
employed for another few months. Real people ship.

Most recently I had an issue to solve, not wanting to fight Python's 2.x's
stupid typing issues, I hacked it out in Perl. The solution shipped. Real
people ship.

GSD (get shit done) and move on. It doesn't really much matter what it's
written in. It's all bits and bytes, 1s and 0s in the end.

Real people ship.

(also, don't work for free)

~~~
douche
On GSD:

You do this for long enough without ever cleaning up after yourself, and
you're left with a massive, steaming pile of garbage that you have to then
support and maintain. Maybe you're lucky enough to be able to write fire-and-
forget code, but in my experience, writing hacky terrible code to ship
something just means that I'll have to spend 3-5x time on the phone
troubleshooting with a customer, analyzing logfiles and then writing the code
the right way in the end, than if I had just done things right to start with.

~~~
vinceguidry
It depends on the setting. If you're working in corporate world where the
amounts of money flying around dwarf your considerable hourly rate/salary,
then what they're paying you for isn't the quality of your code, and what
you've written will probably just be thrown out after it's served its purpose.

If you're having to maintain your own code long-term, absolutely. But that's
not every job. It's good to get a feel for what's required from your boss and
to keep in mind that the requirements can change from project to project.

------
brudgers
Next time there's a "How do I freelance?" Ask HN, please use this;

 _If you find a good client, you treat him or her like a combination of the
Pope, the Queen, and the Dalai Lama, because a trustworthy client who pays you
on time and doesn 't argue over little details of the contract is better than
gold._

~~~
mooreds
That happened to me. The client was so good that I became an employee!

------
allendoerfer
I do not want to sound to harsh here, but seriously you are requesting a bit
much. Judging by your choices of words, you realize it yourself ("special
snowflake").

The system works a certain way, you do not want that, fair enough. You then
continue how you do not want that consulting thing either. So you go back and
basically say, that you want to be hired by a company, which produces a
product of your interest. They should use a technology that does not advance
while there are other choices, which would lure in coworkers, who are
interested in using it.

It does not matter whether Perl is technically a reasonable choice. There are
other more important metrics for a company. When you get hired as a programmer
you got to program. If you want to make bigger choices, stay your own boss.

I get, that it is hard to move on from a beloved community and something that
defines yourself. But really, I do not think, that Lua, Ruby, Python - you
name it - or even PHP are so different, that you could not use some of those
20.000 hours of experience productively in them. Also, you can go back to Perl
anytime.

I think you wrote that rant, because you were faced with making a decision and
wanted to wallow in memories of the good old times. I hat this once on a much
smaller scale when I switched from PHP to Python. As many people already
suggested: Identify yourself as a programmer not a Perl programmer. You will
highly increase the likelihood of getting into an environment that satisfies
you when language choices is not important to you anymore.

------
toadi
Actually the company I founded start 2000 and was quite succesful used perl.
Off course I wrote the MVP in it. I loved perl.

When I sold it due to personal reasons I was not yet ready to retire. In that
time and especially in Europe buy-outs were quite modest. I started doing
consultancy until I would have a new idea and start working on that one.
Indeed the golden cage of consulting can be dangerous. I'm already consulting
5 years and didn't start anything new.

I don't consult as a programmer anymore. I implemented Agile in my own company
and now I'm an agile coach in large enterprises. Programming I still do in my
freetime just to keep me sharp.

But here in Belgium 99% of the projects are CRUD projects so I'm not really
missing out on anything. Most of the times senior developers go to architect
roles not because they want to stop coding but because they're tired of
writing CRUD code.

~~~
zura
I don't know, I guess it requires a different mindset/discipline. I can't
imagine myself happy doing agile coaching. Here in Georgia 99.999% of projects
are CRUD, that's one of the reason I work remotely for more than 8 years now.
Mostly, C++ related work.

------
swatow
disclaimer: I've never written a line of Perl.

When I look at the programming world, my primary instinct is that if something
is popular, then there must be something good about it. Take JavaScript. In
spite of its limitations as a language (the worst of which is not having a
canonical OOP style) there is no easier way to create a single GUI for 3
platforms, as JS. I could make similar comments about Python and C++.

I don't really understand the point of view that using [old language] is an
indication of really knowing how to program. Apart from some minor details,
all imperative and OOP languages are fundamentally the same.

~~~
Mithaldu
Javascript is the worst example you could've picked. The only thing "good"
about it is that it is implemented in every browser on every platform, and as
such available to every programmer of every age. The language itself is
actually quite bad, which is why you get so many people trying to make
languages that transpile to it.

~~~
swatow
Reading in context, I was talking about languages holistically. You can't
entirely separate a language from its context, e.g. JS is the only scripting
language that runs in browser (as I highlighted in my original post).

And do people transpile to JS because the language is bad, or because the
interpreter and runtime are good?

~~~
ghubbard
The former.

------
zzzcpan
Not much changed over the years. Chromatic is still praising Moose and other
bad ways to code.

> Moose is probably the singular reason there are any significant new projects
> in Perl in 2014.

There is another side of that story: Moose is probably one of the things that
contributed to Perl's decline, along with modern Perl, Perl 6 and overall
focus on all the wrong things.

Anyways, I wouldn't take chromatic's words too seriously. Learn Go guys :)

~~~
pmoriarty
What's wrong with Moose, modern Perl, and Perl 6? What makes them "the wrong
things"? How did they contribute to Perl's decline? What are "the right
things"? What should the Perl community have focused on?

To me it seemed like a bunch of Python and Ruby fans came out of the blue and
started endlessly chanting "Perl sucks", or "Perl is line noise", and that
apparently was enough to turn a lot of people away from Perl and on to the
newcomers.

Sadly, these chants often came from and were directed at people who'd never
used Perl themselves, or didn't know much about it at all. So it was really a
case of the blind talking to the blind.

Not that I love Perl. It's got some warts. But so do Ruby and Python, and
every time I try to pick either of them up, I notice a ton of things that are
as bad or worse than Perl. And that just makes me sigh.

~~~
zzzcpan
> To me it seemed like a bunch of Python and Ruby fans came out of the blue
> and started endlessly chanting "Perl sucks"

I think that was a side effect of experienced Perl developers publicly
explaining why Perl was not that good and why they chose another language.
Others respected their authority and started repeating and so on. So, the
bigger problem was: experienced developers were fed up with Perl for various
reasons and started to speak up. And they were not wrong.

Many years ago there was a perl compiler, but at the time when everyone was
moving towards virtualization and ease of deployment was particularly
important - it got abandoned. Performance and memory consumption were never
considered as problematic either, but they always were. Even simple log
processing was not viable for anything, but personal homepage sized logs. It
was very disappointing for many people.

As for Moose, etc., Perl had a perfectly good object system. Everyone knew how
to bless a reference and make it into an object. It was hard to abuse it,
nobody encouraged OOP, things were good and manageable. And yet, community
decided to go farther into OOP, promote Moose, promote new syntax features,
promote new ways to build modules. Things got messy in the process. Perl still
didn't address any real problems, but it was a pretty much new language and a
burden on everyone. Suddenly people found themselves in a position, where they
needed to decide of whether they want to learn all the new things in Perl or
not and learn some other language instead.

> But so do Ruby and Python, and every time I try to pick either of them up, I
> notice a ton of things that are as bad or worse than Perl.

I don't see them as alternatives to Perl. I think they are in decline too.

~~~
chromatic
_experienced developers were fed up with Perl for various reasons and started
to speak up_

This is also the P6 problem.

 _Many years ago there was a perl compiler..._

... but it never worked very well. Certainly it didn't save memory and it
rarely saved much startup time.

 _Perl still didn 't address any real problems..._

I think there's something like the Expression Problem in programming language
design. How do you allow people to solve new problems and explore new patterns
and paradigms in a language without encouraging them to create a series of
incompatible forks (Tcl, Lisp, Common Lisp, Forth, Smalltalk, heavily macroed
or otherwise preprocessed C or C++), limiting the scope of your language to
small or relatively isolated projects (Lua), bringing ideas into the core
library where they slowly bitrot (Python, Perl), or facing a dramatic rewrite
(Perl, PHP)?

For better or worse, Perl's answer in the past few years has been to prototype
new ideas on the CPAN, let the community use them and reimplement them and
compete, and eventually enable them with the minimal core support possible.
The strategy is decent, but it's not fast and it relies on the ability to find
people willing and able to do this work in the Perl core.

~~~
zzzcpan
> How do you allow people to solve new problems and explore new patterns and
> paradigms in a language without encouraging them to create a series of
> incompatible forks

Maybe through many tiny DSLs on top of a small and stable core language.
People seem to be ok with DSLs, but not so much with constantly changing
language and growing feature set.

~~~
chromatic
Sure, that's the approach that a homoiconic or Forthy language takes. It works
well, though it takes a lot of effort and foresight to make sure that multiple
little languages can interoperate.

------
jqm
I'm sure there is good perl and good perl programmers.

But, having spent a portion of the last several months going through 3000+
line perl scripts written by a person with no formal training who had figured
out just enough to hack something together but not enough to efficiently use
functions, nor to maintain the code they wrote, I'm feeling less then
sympathetic with the OP and perl in general....

------
staunch
Anyone who has had the experience necessary to master Perl has serious chops
as a programmer.

------
andsmi2
+1 for reminding me about mumps.

------
jkot
There are money to be made in Perl, but mostly on old code maintenance.

~~~
pre_action
s/Perl/software development/

~~~
crpatino
I am biding my time and waiting for the 2038 bug to come along. The cool kids
of that age will probably never have seen a compiler (any compiler) before,
and I am going to line my pockets like it's 1999. ;)

------
michaelochurch
To me, this isn't really about Perl. It's about the multifurcation of
programming in general. We have ourselves a shitty industry, and whether
you're in-house or a consultant, you engage with its nastiness and aggressive
anti-intellectualism on a regular basis.

It's hard to get the good consulting jobs without establishing yourself as a
specialist. Clients don't want a smart generalist who'd like to try herself
out with machine learning; they want the 20-year expert (and for only $120 per
hour!) But, if you specialize and get unlucky (and a lot of it _is_ luck,
because factors other than quality influence which tools win and which don't)
you end up having loaded up on skills that no one needs. At the top levels of
talent, the people who are _actually_ able to evaluate it have better things
to do than to judge others. So you need credentials, blurbs on the CV,
credibility, etc.

 _...you 're not dealing with VCs who underpay you and dangle ever more
diluted RSUs in front of you for that 1% chance of an acquihire payout that'll
slightly pay more than if they'd paid you a market rate for the start..._

Here's why the VCs and career executives won. They spent as much time getting
good at office politics as we did at Perl or Haskell or Clojure or machine
learning or computer vision. The difference is that office politics is a
transferrable skill. The stuff we learn is much more powerful at advancing the
state of society, but if the industry turns against us, that time is "wasted"
from an economic standpoint. It's not _actually_ wasted; it has still made us
better at our jobs, but it doesn't make us better _on paper_ , which is what
matters if you're a consultant in a rough economy who needs to eat.

Eventually, the VC model will break. What's interesting about it is that the
numbers (in funding amounts) appear large, but the expectations mount so fast
that these companies are actually being run on a shoestring budget (relative
to what's expected by Year X, and because the rapid-growth expectations pretty
much mandate a next round of funding rather than a stable let's-get-some-
revenue strategy). A $5 million investment seems like more than you'd need,
until you realize that you're going to need 25 more people to appease your
investor-boss and that's going to put you in front of investors again,
depriving you of the time or freedom to do anything else (like build a
business, maybe?) in about a year.

 _How do you keep programming fresh?_

That's a hard one, because humans tend to create pyramidal structures and what
that means is that there are fewer positions for 10-year programmers than
fresh grunts who are still excited by the CRUD projects, and at 20 years...
you're either doing R&D in an AI research lab usually with a "Fellow" title
that is VP-equivalent and therefore gives you a right to be old... or you've
moved into a management role... or you've missed at least one boat.

At 7 years, you've learned everything _general_ you need to know for 99% of
corporate programming. Sure, there's the treadmill of new frameworks and new
dresses on old concepts, but you're pretty much maxed out unless you can
convince business types that you're something other than "just a
programmer"\-- perhaps a machine learning expert or "data scientist", perhaps
an architect, perhaps a Dir/VP-equivalent elite programmer ("Principal" or
"Distinguished" or "Fellow") who has the clout to work on what he wants,
perhaps a manager, perhaps a founder. The good news is that, for most of us,
it's not actually that hard to do. Not all "business types" are morons, and
many are good at what they do and make your life easier-- if you can convince
them that you're a cut above the commodity programmers who "deserve" to be
corporate subordinates.

The problem is that, while learning office politics is a lot easier than
plenty of technical things that we gladly learn just for the challenge, it
_is_ a huge distraction, and those lessons often come at random when you'd
rather be learning other things. If you expect a 40-year career working only
on hard technical problems, you're not going to get one, because the days of
Bell Labs are over and, anyway, modern academia is far more political than
most corporate jobs. You're going to have to learn the politics of business,
because (channeling Trotsky) you may not be interested in political fights,
but they are interested in you.

~~~
chromatic
_To me, this isn 't really about Perl._

Exactly. (I believe I wrote that explicitly the previous time this was
posted.)

Part of the problem is that programmers believe we're special snowflakes and
can't possibly be seen as fungible Taylorist cogs. Another part is that we
chase language and library fads more than we pursue deep domain knowledge.

Deep domain knowledge, of course, includes a good understanding of business in
general.

