The Mid-Career Crisis of the Perl Programmer
modernperlbooks.com
modernperlbooks.com
A marketable skill is an investment. If you specialize in one skill it may be very profitable--for a time. Like investing in one stock while it continues to increase.
Diversification is the only smart strategy if you're in it for the long haul. Keeping a portfolio of tried-and-true but also fashionable up-and-comers is the approach I've used to great effect.
As a bonus, it can also improve your skills in your existing languages.
When people (recruiters or otherwise) ask me what I do, I'm a developer. Not a C programmer, not a Rubyist, or any subset of software development. I know how to program, I know how to solve problems, and I know how to learn new languages, libraries or frameworks. Sticking to your guns in an industry as ever-changing, for better or worse, as ours, is a bad idea.
When I was a student, I was interested in trying out tons of new languages. I eventually ended up sticking to Ruby for most of my own projects. At university, we used Java almost exclusively. My two last jobs however, have been C and C++. I'm fond of C, but not a big fan of C++. If I had stuck to Ruby or Java, I doubt I'd have a job as interesting as the one I have now, as those to languages seem to be restricted to web development and things like low quality internal applications used by banks in my area.
(Unrelated: odd, I'd never hear of this guy chromatic before today. I was listening to music by Chromatics, and five minutes before this thing hit front page, I decided to Google the bands name, and I ended up on his Wikipedia page.)
The person in this article needs to adjust the language to emphasize that he knows about the rest of the world outside of Perl, but just happens to have a strong background there.
First, nobody should care that you can "hello world" in more languages.
Second, you don't have any preferences about what tools you use?
I know nobody cares if you can write "hello, world" in many languages, but I never stated that or anything like that, did I?
Some things take time to learn (systems programming, memory management, ... are things you'll have to wrap your head around when coming from a higher level environment, for instance), but hardly any of them are language specific as far as I can tell. Feel free to point out examples to the contrary, although I feel like if it's hard to learn a general concept in a specific language, that sounds like a language design problem.
In many cases being a good programmer in one language means you can learn another language and become a proficient or good programmer in it relatively easily. Some specialization is fine, however, if you really stick to a single language/framework/environment, I think you're staking an awful lot on something that could mostly go away in five years time.
For example, I work in the embedded domain. Ten, fifteen years back, microcontrollers were pretty much king. You wrote software close to the metal, without an operating system, and allocated all memory statically. If you stuck to that kind of development, and refused to learn embedded Linux stuff or dynamic memory management, you'd be unable to find a job today (at least in my area, I can't speak for the entire world in this case.)
I happen to have been doing Perl professionally for a while now and I'd say it would take me at least 2 years to get equally up to speed on another toolchain.
Sure I can write programs productively in other languages, but with my language of choice I don't have to look up dozens of little things a day, avoid common and less common pitfalls all the time, and generally choose the easier path the first time around because I've been around the block a bunch of times.
No matter what toolchain you use productivity at that level is hard to come by, and a lot of it is toolchain-specific. I can competently hack C but someone who's been doing it for 10 years will run laps around me.
So while I'm certainly not married for life to the toolchain I'm using I also think that many people underestimate just how much effort it is to truly become completely intimately familiar with some tool, and how much you constantly gain in productivity for having done so.
The first homework assignment when moving to a new language/stack is to google: "<language/stack/whatever> fucking sucks" and read the first 10 pages or so, you'll get a sense of the pitfalls.
What I'm talking about is the level of toolchain familiarity where e.g. you can look at a given piece of code and know exactly which opcodes it'll get compiled to, what algorithms those opcodes will employ, and by extension how everything else in the system works.
Now I certainly don't pretend to know all of that with Perl, but once you have that level of intimate knowledge that extends way beyond just the differences between similar languages with similar building blocks you'll reach a level of mastery that you don't want to give up easily.
If you accept a job at a new company you might have to start to understand tens of thousands of new lines of code to have a proper understanding of the system you're working with.
Similarly the hairy bits of programming language toolchains are tens to hundreds of of thousands of lines of code that you have to understand to truly know how they work.
My point is that assuming that you can easily transfer that knowledge on a whim just because you can read the syntax introduction of some new programming language is folly.
The toolchain is more complex than most people give it credit for, and mastering it matters.
But the OP was talking about blowing his life savings on a bakery because he couldn't find a job programming in Perl. If you ever find yourself starting to think like that, a big red flashing sign with the words 'Warning: excessive attachment to a particular tool!' should be lighting up in your mind.
No, he wasn't. The article isn't about Perl. The article is about the excessive attachment to novelty and reinvention as practiced in much of the programming world today.
Indeed, and I can say for sure the author of the post has such a low level knowledge of Perl.
When moving to a language you aren't really enthused about, it can feel like all downsides. For me that was having to dive deep into some PHP projects. Although that may have been more to do with the nature of going from Perl to PHP, which really, really felt like regressing to me (PHP sort of feels like a very old, constrained version of Perl). I think the only feature I preferred in PHP was classes, and that point is more than moot now, it's reversed.
You need both, I think. Breath and depth. Excessive depth to the point of self identification as an "x" coder has often correlated with living in an "x" bubble in people I've met.
I have some thoughts on this (which I'm badly composing now due to being in a rush), it's a really important conversation to have (what's the right balance between breath and depth) and frankly depends a LOT on the person/work. I would certainly fucking hope that, to give a strained example, my brain surgeon wasn't just a general practitioner with a hobby :P
It's just like everything else - great programmers will tell you to learn multiple languages to expand your mind. Mediocre programmers will twist that around and use it as rational to flip-flop around without developing any deep knowledge.
I'd actually say that doing so is the easiest way to grow stylistically as a programmer. Each language has their own way of doing things. Some of those things are done really well, others, well, not so much. If you've never dipped your toe outside of the core language pool, it's tough to know just what those things are.
Every language I've ever learned has opened my eyes to a new way of doing things. As a guy who cut his teeth on Python, I'd say that I didn't really "understand" hardcore OOP until I picked up Java. You just don't see that every-noun-is-now-a-class style often in Python. Closures "clicked" when I picked up Javascript, and really deep lambda use didn't really sink in until I picked up Scala.
I had, of course, always used these things in Python, but only on a surface level. Exploring an environment where some small feature of your primary language is the big common feature of another is very eye opening. You pop out the other side with tons of new knowledge and usage patterns.
This sounds really weird to me considering that almost every noun is a class in Python, but that's not the case in Java (primitives are not classes and there's no easy to use meta-class construction).
With production usage, each platform matures through attempts to learn from the past while not forgetting too much before that.
(Sadly, though most everything will be coded in javascript.)
If we really view JS as assembly for the web, I think there's an interesting future.
However I agree that going from Python to Java can seem like hardcore OOP. It's tempting to argue that hardcore OOP is relative, but I like to go by Alan Kay's definition which is pretty easy to prove/disprove.
Bear in mind my most recent PHP experience has been bending wordpress to do my will (taking over a project that's had the designer on the lead), and dealing with an undocumented not-quite-webdav implementation written in PhP that seemed to be overly dependent on apache.
And PHP's design flaws are at the core of the language without the extendability that perl has.
If you enjoy and are skilled at something, you should be able to productively contribute to many different organizations. You'll need to take the set of organizations that you'd like to work at, reduce it to the set where you can get an interview, and then sample the interviewing process until one instance produces a positive result.
Every choice that you make which constrains the addressable set of interviews makes it more difficult to get that positive result.
In my case, when I returned to SF after working in finance for ~7 years, I spent a very difficult year or two trying to find a trading job. The problem is that there are a tiny number of firms at which one might work trading in SF, and a huge number of applicants. At one interview I was told, "You're a great fit but there are a ton of folks out there. I'm going to interview a different person every day for the next two months and then make a decision."
At this point I decided to go back to my roots and become a software developer again. Surveying the market I identified iOS and Rails as having favorable supply/demand imbalances. So I spent 3mo learning Objective-C, Cocoa, Ruby, and Rails, as well as the rudiments of CSS.
I very quickly found work, enjoyed it very much, and have now made my way back to finance, this time as a technologist.
One other thought: Coursera classes are an excellent way to give yourself an additional bit of edge in terms of getting the interview. Taking and doing well on Andrew Ng's Machine Learning class, for example, doesn't necessarily mean that you can do ML vocationally, but it does speak to your willingness and interest in continuing education.
I had a similar tack in my career and have been asking the same questions lately. I wish I had some of the answers.
At this point all I can offer are some coping strategies if you're still thinking about leaving programming (at least for a while):
Buy a cheap house and keep your living expenses low. If you want to leave programming and open a bakery you'll at least be able to keep the roof over your head and food on the table. Who knows, maybe you'll be happier?
I've been thinking about opening a brick-and-mortar retail game shop and writing on the side.
I still keep sharp. I cannot give up programming. I'll read something about sail design, consistency analysis, topology, or constraint propagation and for the next few months I'm knee deep in algorithms and data structures while trying to maintain polite conversation at the dinner table.
But in the morning it's all about configuration scripts and CRUD apps and copy changes in templates.
Other hackers have jumped ship... jwz comes to mind.
The sheer volume of conversations I've had with people in the Bakery scenario is mind boggling. I think most people just get jaded around their mid thirties in any career. It's just some people have the balls to setup bakeries!
Sometimes it pays to be foolhardy (lord knows I have been several times), but painting the picture that all of us who may be dissatisfied with our current mid-level careers as technologists would be successful if we just had the courage to abandon a decade and a half of training and effort to chase something new, that's disingenuous.
You don't need to make a tonne of money to be happy. Move somewhere cheap, keep your expenses low, and have fun running a bakery. You get to interact with more people, get involved in your community, and people can taste the results of your work.
This is making an inverse error. If your current job isn't making you happy, there isn't actually anything that guarantees leaving it will make you happy.
It's incredibly easy to say "move somewhere cheap, keep your expenses low, and have fun" from the outside. I have been perfectly willing to move for a job. I've changed continents, and failing that moved literally across country (vertically mind you) for another. We even moved when we had a house with a mortgage and rented out the house (at a loss) because the housing market sucked in 2008. Moving that much took a huge toll on my family. We basically decided to stop when my second kid entered school, and my wife opened her retail business. Which is to say, it ain't that simple.
Have you started a retail business? I've watched first hand what it takes. My wife works easily 50% harder than I do, for 50% of what I make on a good day. She has finally gotten to the point where she has three part time employees so she can take one day a week off. She cannot simply 1099 contractors, so she has to worry about witholding, workman's compensation, and employee benefits. She has to deal with upstream suppliers, constantly finding new customers, driving business into her shop as well as subsidizing it with external events. She'd be the first to tell you that without my salary backing up the family ... she would have had to shut her doors several times.
In our industry we lose site of the actual cost to run a mom-and-pop business because we can throw up a website for $20/mo and a long-weekend of work. (Isn't that what the basic premise of the Lean Startup is? Throw something economically cheap together to test the idea and bootstrap sales?) My wife's business has kept expenses low. She buys all her equipment second hand off craigslist (she's a potter not a baker so thankfully a lot of failed hobbyists make the supply on craigslist reasonable). I'd estimate her expenses before payroll are close to $2k-$3k/month for consumables and rent. Most months she breaks even after payroll, and doesn't pay herself an actual salary.
If this description sounds remotely appealing, then by all means stop what you're doing and go that. Programming really is that hateful.
However painting it with the rose-tinted glasses of "You get to interact with more people, get involved in your community, and people can taste the results of your work." belies the actual hard work that building a business is. It elides the fact that there will be nights you will lie awake wondering if you'll make enough sales to pay last month's rent ... let alone this month's rent.
For some people that is still better than what they were doing before, but pretending that all you need is a little more gumption ... I don't know a better word for it than 'disingenuous'.
True, but the amount of money required for this is not much. If you aren't picky where, and you have neough saved up to buy a house, you might be able to get by relatively well on $3000 a year in some parts of the world.
> Have you started a retail business?
I have helped.
Part of what you are talking about though is the cost in a more complex society of doing this. Now a bakery is not necessarily a retail business primarily. The most successful bakeries I know do both retail and wholesale baking. I think it would be impossible to get by really on only one side. People who want to buy your bread will come by, but you do not want to make everyone come to your store just to buy a loaf of bread. You have to get it in other stores.
So I don't think it is fair to call it just a retail business.
> However painting it with the rose-tinted glasses of "You get to interact with more people, get involved in your community, and people can taste the results of your work." belies the actual hard work that building a business is.
I think what you are missing though is that both programming and baking are ultimately about creatively making something. I don't mean just artistically. I mean it is about craft and seeing things come to life in your hands. Part of the question is who you answer to and how deep your hands are in it physically.
So no I don't see it as stupid to open up a bakery. As with any business you need to do your planning first, prepare for an extended period without profit, etc going in (and have capital investment of your own to make it work).
Fair enough, I was actually assuming it was basically similar to my wife's pottery business. She has a retail location (studio space) but a good portion of her revenue comes from what would be the equivalent of wholesale sales. She does field trips and after school programs. The two compliment each other, and while you can survive with just a retail location (most of her industry does) ... the fact that all but two of the local pottery shops have shut down in the last three years suggests how difficult that is.
> As with any business you need to do your planning first, prepare for an extended period without profit, etc going in (and have capital investment of your own to make it work).
I'm pretty sure that is the gist of what I was trying to say. The original comment, and the general theme of comments like this, suggests that all you need is enough "balls" to just do it. I'd suggest that most people who actually start businesses to change careers do it because they don't know what they're in for. Anecdotally that seems to be the case from everything I've heard since I first started thinking about running a business. In that context I stand by my assertion that opening a business _simply because_ you're tired of your old career is foolhardy.
Heck, starting a software business and decided to grow to your first hires and worrying about making payroll is just as taxing.
What I meant was that for a disenfranchised programmer perhaps they do need to get out of programming for a while. And if you're thinking of taking a pay-cut to trade for some happiness then one suggestion is moving somewhere cheap. I'm not a guru... it's just the best thing I could think of. I could afford a 650k house in the city or I could afford a 200k one on a commuter line in a less-desirable city. Seems to me that if I needed to take a pay-cut then I'd be better prepared if my costs of living were lower than if I had locked myself into the expensive city house.
But maybe not?
"Just pack up and move somewhere cheaper" is easy advice to give, but it doesn't apply to every situation. Not everyone has that luxury. By the time you reach the mid-point of your career, you may have one or more of a partner, a partner with a professional career, personal obligations in your area, a mortgage, a mortgage you can't get out of without losing a lot of money/credit rating, aging parents, children, ailing family members who live with you, medical conditions which limit where you can live, ex partner with children not willing to move, et cetera. Alternately you may already live very frugally.
When I was fresh out of college, I couldn't have imagined any of those circumstances applying to me or anyone I know. Now I've seen them happen to many of my peers and colleagues.
Second, given the right set of circumstances you could find something wrong with any given suggestion. I wasn't trying to be flippant. Life is complex and I am struggling to find answers to many of the same questions as you.
Best of luck.
Update: also should apologize if my suggestion was in poor taste. I realize it's not the kind if advice that works for everyone.
Actually in my experience it's not. Again about 5 years ago I started my own software company. About a year after that I brought in a friend as a partner. We did consulting for the next few years, and my partner ran into an idea for a product that we couldn't pass up. (We're releasing to our first round of beta-customers this week.) During that time we've had several employees (part-time and full-time), great contracts, not-so-great contracts, and one contract that made me curl up in my bed for a week and refuse to speak to anyone for two days.
My job has still been significantly easier than my wife's over that same period. I've had to deal with maybe a dozen clients, she's had hundreds in the 3 years she's had a retail location. Our operating budget monthly outside of payroll is measured in the hundreds (handful of linodes, github account) her's is an order of magnitude higher. She has to travel extensively around our metro area (we happen to live somewhere with crap public transit so lots of driving), spending some weeks as much as 30hrs in her car alone. I work from home, or when I'm feeling audacious from the park near my kid's school.
Just today she called and told me though that she'd visited a place where part-time employees had to be badged in, and she was incredibly happy to be self-employed seeing that. I've spent the last few days feeling the grass was greener with a salaried job. Knowing your next paycheck is gonna arrive is a really nice luxury. Being able to take two weeks off without having to worry about how you'll make payroll is a really nice luxury.
Listing here for you all the reasons why being self-employed sucks has ironically reminded me that I really am doing this because I want to. So yeah what you're saying overall about finding what need to do and doing that is entirely true for me, but it isn't necessarily "easy". I certainly didn't realize how hard it would be before I started.
What do you tell the interviewer who says: "uh, yeah but your experience is all 1-5 years old. Why haven't you committed to github this week?"
We're just arm-chair quarterbacking chromatic's life with our own experiences informing what play is "obviously" the right idea. I know from personal experience that he's a incredibly insightful intelligent person. I suspect that he has weighed all of these options and hopefully he'll find the best solution for his own life.
Good read, the TL;DR's are spot on :)
embrace the power of "and"
That said... it is used for so many things I can't even imagine it going away in my life time could be said quite easily about Perl as well.
"Fifteen or fourteen or even ten years ago, I might have railed against the inherent unfairness of a cruel and uncaring universe of technology driven by fashion, where technical superiority is less important than buzz, but I've tried these approaches over my career."
The universe, from the perspective of a Perl programmer, is certainly cruel and uncaring. I just don't think it's driven by fashion near to the extent this statement implies (or the pithy TLDRs up top imply, for that matter). The biggest wounds to Perl were probably self-inflicted, but the languages that grew to replace Perl did so by and large because they were doing a better job of solving problems some people had than Perl was, not because the people who were using them wanted to be fadish. There certainly are people who chase programming fads, but they're trailing, not leading, indicators of a language growing.
Lately I've decided to consider IT as a fashion world. My major anxiety is how to clearly see what's "core" and what "fad" and focus properly (and hope I'll be employable by my 50's).
As always, the classics. If nothing else, knowing how to write a compiler (especially including parsers) will keep you employed. Not because you need to write compilers all the time, but the techniques are useful and timeless.
Unix will probably stick around, too. And I'd be willing to bet on strongly typed functional programming (but I might be biased there).
At the time when I decided to learn one of Perl, Python and Ruby as a basic text manipulating scripting language, all discussion of Perl revolved around how Perl 6 was not at all backwards compatable, not usable at the moment, and would replace Perl 5. Given that impression, learning Perl 5 looked like the height of stupidity.
A somewhat related one is the effect that the Perl 6 disaster has had on the reputation of the Perl community as a whole, even if Perl 5 is a very different language embraced by a different segment of the community.
Unfortunately, the term "Perl" has become synonymous with terms like "failure", "incompetence" and "wheel-spinning" for a lot of people.
This isn't the kind of reputation that proves useful when trying to advocate for the use of Perl 5 in new projects, for example. One will end up spending more time trying to explain that Perl 5 is pretty unrelated to Perl 6 and that its development has continued, rather than spending time explaining how it'll be beneficial to use it.
In hindsight, I think it's been very good that Python 3 hasn't been about drastic, immediate change. It has been a very controlled transition that has allowed existing users to remain undisturbed, while simultaneously allowing the language to evolve.
Those who don't need Python 3's benefits today are perfectly able to continue using Python 2.7. Nobody is forced into upgrading, yet Python 2 still remains very well supported.
Those who want or need what Python 3 offers can upgrade when they see fit. We've seen the major libraries and frameworks support Python 3 over time, as demand for this support has grown. It now has a very robust community building around it.
Unlike Perl 6, we've actually been able to seriously use Python 3 for a long time now. While it's clear now that Python 3 is the future, Python 2 users haven't been abandoned, either. Everyone has remained as good as they were before, if not better off.
1) Nearly everybody but you is an idiot, and the rise of Python and Ruby to take over several problem domain formerly dominated by Perl (and having better penetration than Perl in problem domains where other languages, like PHP, are more dominant) is entirely capricious and due to whimsy.
2) You're not understanding something as well as everybody else, most probably the particular problem all those people using Python/Ruby instead of a Perl as their language.
What's more probable, do you think?
PHP began life as the antithesis of "goto considered harmful." The idea to embed a language directly into a mix of HTML/CSS/JS was just profoundly awful. Yet we still bash "goto" as the spaghetti monster. I guess we just can't detect irony today.
To your #1 point, I'm going to have to say there are a large number of powerful, well-funded, well-marketed idiots in this industry. If languages really mattered, we would all be using Scheme, ML, or Haskell or something. People are just now discovering Erlang, thanks to WhatsApp and Facebook. Despite Erlang being a year older than Perl. But Perl didn't make recent headlines for a $19bn sale, so...
Tail call elimination is more about allowing a particular style than anything else. Python encourages a different style, so why should Guido care about tail call elimination?
Most people I have encountered who have chosen a language have done it in a seemingly arbitrary fashion, so no, I don't believe either of your statements.
I used to not like Perl because of having to touch other people's "ascii puke", but I've gotten past that and still think of it as the best language for manipulating text that I've used.
YMMV
People don't need to be particularly stupid to be driven by trends that aren't entirely founded on reason. And preferences can be both subjective and valid.
I don't have a dog in this particular fight (while I worked in Perl for at least five years, I stopped over 10 years ago and moved on), but I think it's pretty much a reasonable claim that Ruby and Python and Perl (and maybe even PHP) are all more or less in the same class in terms of capability. Python and Ruby may have some gains at certain margins (perhaps Python in particular with the focus on clarity in both the language and community), loses in others.
I could try and weasel out, and I kinda will, because that's a bit stronger than I think my argument really is, which is that if something is popular, it is likely to be better. (Well, that's not the entirety of my argument, I'll come back to that for a second.)
When you assert the strong form, like you just did, the argument becomes exceedingly silly, because rephrasing almost ANYTHING short of mathematical formulas or laws of physics as a Universal Truth makes it at least somewhat silly. But when you look at it as a probability rather than as an absolute, yes, you should expect more popular things to be better than less popular things, no? Not necessarily even overwhelmingly so, but more often than not, right? And quite often, when you scratch an argument for why something that has lost (rather than some new innovation) is better than the thing that became popular, often what you find underneath is a mismatch between what the arguer thinks is better and what the people who chose the popular thing think is better. And maybe they're wrong about what's better, or maybe they were right about what was better given certain constraints that Moore's Law or the cloud or whatever has made irrelevant and now they're persisting due to network effects or whatever.
But to go back to the original poster, who's a Perl programmer trying to figure out what to do with himself. I think writing off the popularity of languages that followed Perl as being due to fadishness, rather than actually investigating why people chose to develop new languages, learn them and build tools for them, is putting an obstacle between yourself and learning new things. You may learn that people had bad reasons, or that they had good reasons at the time but you can do something better than what they had to choose from then. But you'll learn new things, rather than closing yourself off to them by writing off new things that replace what you know best as "fads" and people who adopt them as driven by something other than merits.
It's sort of the liberal flip-side of Chesterton's fence -- Chesterton says that you shouldn't tear down a fence until you can understand why it was built, i.e. you shouldn't change something unless you understand it. The converse is that if everyone keeps tearing down a fence, you should understand why before you put the fence back up again.
You may be responding to something that isn't in the article at all.
I first learned Ruby in 2000, mostly because Dave and Andy sent me a copy of the just-published Pickaxe book. There were few reasons to use Ruby in the English-speaking world back then, unless you were a language magpie or had very simple needs and didn't already have a scripting language in your toolkit.
I didn't do much with it until 2004, when Dave told me to check out the nascent Rails. (I'd already failed to convince my employer to cover Ruby in more detail even though many of the clever and insightful people I knew had started to pay attention.) We published the first Rails article anyway, and it was a good thing we did.
Even then, I didn't use Rails seriously myself because it and Ruby offered no benefits and only drawbacks. It was slower and had fewer libraries and worse tools than what I was already using. (Unlike a lot of Rails adopters, I wasn't primarily working in either J2EE or PHP.)
In 2014, even with Ruby and Rails off of their 2007 peaks, the metrics have changed a little bit. Ruby and Rails have better job prospects, in my experience, while the tooling and ecosystem and languages themselves are roughly equivalent. (One's better in some aspects and the other is better in others.)
Funny thing, though. It seems like around here Rails or Django are the old guard--the conservative technologies no one will lift an eyebrow at you using--and things like single-page client applications served by Node.js are the exciting technologies with new libraries and frameworks announced every week.
Some of those will succeed. Some will fail. Given that I'm not 14 or 19 or 22 anymore, that I spend my days working hard to deliver value for clients and/or employers, and that I have other things to do on nights and weekends than sit in front of a computer, where do I focus my time and energy and resources so that I can both get things done well now and continue to be employable for the next fifteen or twenty or thirty years?
That is what the article was about, not calling everything but Perl a fad.
Why is Node.js popular now? Because people want to create web applications that are responsive without requiring the client to constantly poll the server to see if there's new data, and Node.js does that better than existing tools.
Why are NoSQL databases popular now? Because right now, it's a lot cheaper to scale up by buying more computers than it is to scale up by buying better computers, and current relational databases are bad at scaling up that way (compared to other parts of the stack). Now, I think that NoSQL sometimes throws out the baby with the bathwater, and I do think there are cargo cult NoSQL users who are convinced that if they go around throwing out babies they'll eventually get some dirty bathwater. But NoSQL does solve real problems, and (to the point here) those are problems that are really difficult to predict that you'll need to solve from 15 years before now, because you need to know how the economics of buying computer hardware will change in the future.
I don't think it is possible, at this point in the development of these technologies, to future-proof your skills if you want to work on new projects. You can either keep learning the new things, or waiting until other people find out which of the new things are actually going to last and then learn those things. You can use your current skills to maintain legacy systems. Or you can get into something like management, where you can leave specific technical details to other, younger people and focus on broader issues, like relations between your developers and the people they're serving.
Possibly in areas where no serious money is involved, but I haven't experienced this in the big corporate/government world myself. It can occasionally be true, but it's certainly not the rule
A simple example of this would be going with the bloated, more expensive, more error prone product. It may just be that service contracts, existing relationships, available support or even just name recognition (Nobody ever got fired for buying Microsoft...) trump those in some cases.
I think for me it was. The jobs kept coming, stuff kept getting done, I enjoyed myself, I'm proud of most of the code I wrote, and yet, it never felt completely right. Probably because Perl has always been more of a petri dish for idioms than an organized home for them.
> Every programmer who loves Perl should ask him/herself
I think this should read "Every programmer who loves any technology should ask him/herself [...]". Asking this question may be a great way to learn more deeply about the technology. I don't think that Perl is special in this regard.
> Is this a case of Stockholm Syndrome?
Not if the programmer acknowledges there's problems with Perl, but loves it anyway; not if the programmer has experience with other technologies that have different strengths and weaknesses.
I disagree. Just as it allows you to write horrible stuff, you can just as well get your shit together and do it maintainable, robust and nice to the eye :)
And as the author states, you (almost) always have an choice to run other languages, where perl runs. Not really a hostage situation, methinks.
Edit: Not that I particularly like Perl, but neither do I hate it. I think it's somewhat bad reputation stems more from the fact, as described above, that it forces you less to do things nicely and is very accessible to the, let's say, less experiences programmers - so a lot of quickly cobbled together stuff flies around.
Many years of programming practice and SE theory have taught some of us that discipline is not the main concern of most programmers and the higher a level you require of it, the more you will be disappointed. Which means that you tend to get more maintainable results from languages which either require very little discipline to produce good code or those that strictly enforce discipline (e.g. Go).
Sadly, even the code on CPAN (which was built to withstand some scrutiny apparently, or why else would anyone release it to the public) is often so badly written that I wouldn't want to debug or maintain it.
> And as the author states, you (almost) always have an choice to run other languages, where perl runs. Not really a hostage situation, methinks.
In practice you're more likely to find old, hard to maintain Perl code bases that noone is able or wants to rewrite in another language, if you get hired to program in Perl. If there was a realistic choice to use another language, it was likely made already years ago.
Having worked in several corporations now I have to respectfully disagree. My experience is that either the code base was scheduled to be retired (but we all know how that usually turns out: the app is used for at least 3x(abs($retiredate - $now)) + $rand ), nobody could be bothered to keep the system current, or there was always something more important to do (which overlaps a bit with the second point).
Come to think of it, I really can't come up with a situation where you can't replace perl with a reasonable amount of work? But then again, I'm not active in the perl field.
Apparently the math libraries written in fortran back in the day have become such a foundational part of analytics, that nobody really wants to re-implement them.
On the other hand, the API is not something that is subject to change. A lot of software expect this to be stable, like Matlab, R, Octave, Numpy, and a lot of others.
I haven't touched Fortran in 20 years though :) I loved me Pascal except the semi-colon key broke on my keyboards.
Fortran compiler. There are no Fortran interpreters in existence, anywhere, that I've been able to find. For FORTRAN 70, Fortran 90, or any other versions. If someone manages to find an interpreter and proves me wrong, I'd love to hear about it.
That'll show me to rely on my hazy memory of something I read five years ago on wikipedia =)
That said, I'm also not aware of any Fortran interpreters, and it would surprise me if there is one.
(And yeah, 10+ years old Perl code bases might be less than pretty... The environment evolves quickly, for good and bad.)
Please excuse me for being an idiot, but I don't see the problem.
Just because something is locally good doesn't mean there isn't a more optimal good elsewhere.
(For those of you who only know Walter Mitty from the Ben Stiller movie, here's the original short story: http://www.newyorker.com/archive/1939/03/18/390318fi_fiction...)
SV needs to continually reinvent itself, so that VCs can sell their smelly IPOs on Wall St. They needed a new paradigm, so we got Web 2.0. Enter PHP. What is PHP? It's pretty much Perl. In fact, it is Perl. Just a highly shit version, done by monkeys that don't have a clue. Perl 2.0. Facebook, the shining star of Web 2.0, is built on it.
But Web 2.0 isn't new, either. The story of Web 2.0 is how advertising prevailed over technology. Now we're entering a mobile post-web period, where we go back to proprietary lock-in with a cloud twist. It's the 1980s again. But it's fresh on Wall St. Better start learning Objective C. If you believe Android will remain relevant (I personally do not) then keep those Java skills dusted off.
Disclosure: My first and 3rd jobs were slinging perl for dot-coms, one of whom is a still leader in Web 2.0 or Web 3 or whatever we are on now.
PHP is mostly a web templating system, never had much of command-line presence. Perl always did.
I don't think you know what you are talking about.
I hate Perl because of its syntax but I have to be thankful to Perl because it made Matz start Ruby.
That said, your statement doesn't compute: What does Perl has to do with the dot-com crash?!
Perl is all but dead because Larry Wall, Perl's developer, thought it'd be a good idea to let someone else implement his spec for Perl 6. There were some attempts, and you can argue about their success, but the fact that there is no reference implementation is what killed Perl. The Perl community argued and thrashed and screamed about Perl 6, and meanwhile, Python and Ruby developed vibrant communities, and most serious Perl programmers I know simply migrated to one of the new, more developed languages.
I suppose what this guy is really saying is that Perl 5 died around the time of the dot-com bust. But correlation does not equal causation; Perl killed itself.
30 seconds of Googling puts this fallacy entirely to bed:
http://perl.la/ http://www.perl.com/pub/2014/02/perl-today-february-2014.htm... http://moose.iinteractive.com/about.html
I don't agree that Perl is all but dead, but I agree that one of the bigger contributors to the length of P6's 15 year gestation is quite plausibly Larry holding his tongue and commits in relation to compiler implementation.
Fwiw:
* According to Larry (a couple weeks ago) the community told him to stay out of compiler implementation at the start of the P6 project. He complied, constraining his P6 toolchain coding to pieces such as the STD grammar/parser.
* Late last year Larry said he planned to change that, with his main focus set to be optimizations. And in the last few weeks he has indeed begun landing a stream of commits to Rakudo and MoarVM. (So far his commits mostly relate to Unicode handling, which looks set to be a notable P6 strength, but there have been some significant optimizations too.)
* There is a de facto reference implementation: Rakudo/MoarVM.
Python, Ruby? Not so much. On Linux yes, on the other's I very seldom encounter it. Perl is an indispensable tool in the hacker's toolbox.
I use Perl daily. Love it. But, the argument that it's available while others are not isn't really valid anymore except in a few niches. Linux is pervasive, and Python and Ruby are pervasive on Linux systems. In fact, Python is more likely to be available on the two biggest distros because many of the administrative tools provided by the distro are written in Python. RHEL/CentOS/Fedora effectively have standardized on Python as the language of choice for admin tools.
A few years passed and I began to become bored with being a sysadmin. So I started programming and took on some small side projects. I had a much better experience there, so I've been pursuing that path. I've also started taking some stats courses and realized that I love playing with and learning about data. It's something that satisfies my natural sense of curiosity.
So what it came down to was making the time to try these things out. It's cost me a bit in terms of my social life, but I think that it will pay off in long term happiness. :) It doesn't hurt to explore, and you could either discover that your job isn't so bad after all, or you could find something new.
Back in the day, when Flash was the cool thing and you would get an AS3 library for every .js library that you see today, Many AS3 developers looked invincible. Me being one of them. Until Flash died. It just died in a month.
Two things happened. A group that didn't diversify and didn't want to move out of their comfort zone, lost jobs, some became pizza delivery guys. I know a few. They had time, but they didn't leave things behind.
Another group of developers, moved on. Not only away from Flash, but away from anything that seemed slightly in trouble. And you know what? All of these guys are doing brilliantly.
My answer is to work toward a doctoral in computer science. It seems the only way I'm going to get time to give vent to my own inquisitiveness. At the end, I get to do research and mentor the new generation of developers coming up.
What interests me is research into education and learning. I'd like to develop a domain specialty there.
Day-to-day I've lost interest in this or that build system, IDE, programming language, framework, etc. I'm more interested in the specific problem I want to explore. To do that, I feel like I need to pick one language and working environment, then become an expert in it.
I see it a bit as rock climbing : I looks simple, but not everyone can do it right.
So when you think about what you should be doing mid-career: think about what people you have liked working with are doing.
There was never a point where I felt that Perl won't do the job. In fact, many times I came to replace some complex ball of wax written in some other language with simply written Perl code, and everybody slept better afterwards.
Sure, there are many frameworks, and it seems easier to just write a little glue code on top of that - I always resisted that urge. I write my code as minimalist as possible, with the least amount of includes or dependencies. Things work, and my customers are happy. If there is one thing I am happy about later Perl releases is that they fixed threading and it works now as it should.
See profile for contact infos :)
(If Roger ever reads this; you were my boss and treated me horrid. I'm not quite sure what I did, but I think you thought I was the reason the girls despised you? I took a lot of crap from you, but I got more than my fair share out of that hell hole. Yea--It was one for you and one for me. Your attitude helped pay off my student loan--thanks!) Inside Joke--Unrelated to this Perl Programmers predicament.
To the Perl Programmer--good luck what ever you do. You have a good perspective on life, and seem genuinely nice.
Having said that, as a perl programmer, I seem to be hugely in demand for flashy javascript at the moment.
Instead of perl, my tool of choice was Drupal. I built many great things in it, but I just reached a point where I could no longer be passionate about it.
I am different though in that I changed my focus to node.js 5 years ago, because it was something I was excited about and interested in.
I think that's made me a more well rounded programmer, and made me a happier person in the long run.
To the OP, I think you should follow your instincts about Rust. Do it because it interests you not because it's profitable. If you have to take a basically uninteresting day job to do so, you should know that you are in no way different to most of the people out there.
With a bakery you'd at least have someone complement your hard work... and maybe come back in the next day for more.
Programming has no rewards... other than the "lighting" instances. You spend your life in front of a monitor... typing. Yet, we all need money right?
Wow. That's a really big sentence with some amazing accusations:
1. Google is full of vampires (garlic)
2. Datacenters are babies (babysit)
3. Information is owned by the world (world's information) even though it's scraped into a Google index which you can only get to by using Google.
It also greatly bashes on all of Google for making adwords? Yay? I think this kind of snork-snork attitude is the kind of shit I don't miss about Perl Monks and the like. He just sounds hurt and mad.
1. Google is full of vampires (garlic)
Garlic makes your breath stink. People may avoid you after heavy garlic consumption.
2. Datacenters are babies (babysit)
As a metaphor, it's definitely possible to do worse. The systems within the datacenter will need attention. Constantly. People are on call to handle these and other issues. There are many parallels to watching children. Which is why, as a metaphor, it works, at least from his point of view.
3. Information is owned by the world (world's information) even though it's scraped into a Google index which you can only get to by using Google.
What are you even trying to say here? I don't think Google would contradict that they take existing free information and present it to you. Their value-ad is that they make it easy to find what you are looking for, and organize it in interesting ways. That he sees Google as a marketing company that uses this ability to service ads is hardly controversial.
That said, my take on his reply to your original comment is that he really interpreted it as a shit job. I'm not sure if that's just the work at the level they decided he fit at, or is par for the course, but I can see how someone who identified as a programmer may be put off by an interview where they ask "Is it a problem for you to be maintaining code but not writing it?"
This, and my CV says system administrator exactly once, and that ended in 2000. Everything since then has been not system administration. To be pigeonholed into system administration because the mighty algorithm had decreed that the intersection of "Perl" and "system administration" on a CV meant "system administration" did not sit well with me.
After I'd spent a couple of weeks going through phone screens which alternated between "Rah rah! Google! We solve interesting problems! We're changing the world! Work on whatever you want!" and "How do you sort a million phone numbers using the least amount of memory possible?" and that silly ping pong ball question, the recruiters started asking things like "How do you feel about getting handed code without documentation and being responsible for deploying it?" and "Is it a problem for you to be maintaining code but not writing it?"
Then again, I'd accuse myself of making this up if I hadn't experienced it more than once.
Best wishes for your interviews.
Also, Perl's CPAN gives us access to so much it's incredible.
I think Perl is still ahead of it's time and the best days for Perl are still ahead.
That said Python is now getting close to usurping Perl as software superglue.
Perl's used in large projects just fine, with similar problems found in all large projects. The solutions to those problems may be Perlish, but that's just rather than Rubyish or Python-ish, etc.
While you can get the same problems with other languages, its much easier for a Perl project to disintegrate into anarchy even when careful managed.
If that's true, it's a matter of trade-offs, not a clear negative, and it becomes a matter of recognizing those downsides and dealing with them accordingly (whether that be avoiding certain features except where specifically called for, better documentation, or preventing that loss of institutional knowledge).
As you say its a trade off, but IMHO its always better to pick maintainability over efficiencies in design and implementation for most long term projects.
(Not you say can't write maintainable Perl, its just much more difficult than in other languages and requires a solid culture to support it).