The Mid-Career Crisis of the Perl Programmer(modernperlbooks.com)
modernperlbooks.com
The Mid-Career Crisis of the Perl Programmer
http://www.modernperlbooks.com/mt/2014/02/the-mid-career-crisis-of-the-perl-programmer.html?
171 comments
Did you use any specific technique to identify this imbalance? It's often so difficult to get a realistic picture.
I didn't, it was pretty hand-wave-y. But I do know a fairly large number of people in the Bay Area tech scene so I took stock of what they were saying, in particular around hiring difficulties. Also, I did some tinkering with the things that seemed to have merit from a supply/demand perspective and stuck with the ones that I enjoyed most.
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.
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.
Go to local meetups. You'll see the supply and demand play out right in front of you. How many employers are there, and how big of a group of potential employees are they talking to?
To highlight one thing:
"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.
"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.
It's debatable how much improvement theses language are providing. You see people reinventing the wheel over and over, "discovering" "new" things all the time, thinking of new ways of doing things that will make a 0.0001% difference.. all attached to a "revolution" tag.
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).
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).
> 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).
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).
For me one thing killed Perl, Perl 6.
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.
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.
This is a very real phenomenon.
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.
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.
One subtle problem that I think is potentially relevant is that Classic Perl's version number has to keep incrementing from 5.x; someone who isn't following Perl development sees Perl using the same major version number as it was back in the mid-90s and assumes it's not being actively developed.
Interestingly, this is the same thing that is currently killing Python. The lack of migration towards Python3 is causing major problems.
There's a huge difference between Perl 6 and Python 3. And Python 3 surely is not "killing Python" or "causing major problems".
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.
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.
As someone who strongly dislikes perl (I'm being generous there really), I really don't think python or ruby do a better job at all. Python's selling point seems to just be "the syntax is different", and I honestly can't tell how ruby is supposed to be better than perl at all. It is barely even different.
Well, apply the process of elimination. One of two things is true:
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?
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?
Python is the language designed by a guy that did not understand the difference between tail-call optimization (a general, widely useful optimization) and something he made up as a strawman, called "tail-recursion elimination."
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...
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...
Python was invented by an extremely talented programmer who didn't happen to know one particular thing. It's not the minutiae of theory that make Python so popular, but it's overall design philosophy geared towards ease of use and readability.
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?
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?
Calling it "Tail-call optimization" shows a lack of understanding.
"Tail-call elimination" is no mere optimization, it is an operational semantics that means certain operations happen in guaranteed bounded space instead of unbounded space, and therefore are guaranteed to be possible to execute if some simple initial conditions are met, vs virtually guaranteed to crash the program at arbitrary moments.
I don't see too much different in Ruby, either. I haven't really been exposed to Python, so I don't really know why people use it so much.
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
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
Did I just read a "because it's popular, it's better" argument? Combined with a strawman ("the poster is arguing everyone but himself and other people who think Perl ~ Ruby/Python is an idiot")?
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.
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.
"Did I just read a 'because it's popular, it's better' argument?"
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.
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.
I think writing off the popularity of languages that followed Perl as being due to fadishness....
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.
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.
I highlighted the quote that bothered me; it may not be relevant to your point but I actually think it is.
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.
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.
Why are static site generators popular now? Because not everyone's building a social network for marmots that has to serve 300,000 image macros a second. Plus c'est la même chose.
"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? "
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
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
I think this generally applies in that case: "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."
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.
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.
There are far more possible explanations than the false dichotomy you provide. If you think your suggestion #2 is most likely, then why not help me understand rather than making a completely unproductive, condescending response that provides no insight or value?
Every programmer who loves Perl should ask him/herself: Is this a case of Stockholm Syndrome?
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.
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.
The jobs kept coming, stuff kept getting done, I enjoyed myself, I'm proud of most of the code I wrote
Please excuse me for being an idiot, but I don't see the problem.
Please excuse me for being an idiot, but I don't see the problem.
It's a perception problem.
Just because something is locally good doesn't mean there isn't a more optimal good elsewhere.
Just because something is locally good doesn't mean there isn't a more optimal good elsewhere.
But thinking like that creates what I'll call the Walter Mitty Problem: making a great living, enjoying a loving family, great health, etc., but being unable to take satisfaction from any of that because you're too busy dreaming of being a larger-than-life figure. The better your circumstances get, the more dreaming of even better ones becomes a game of diminishing returns.
(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...)
(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...)
Stockholm Syndrome implies that Perl is bad, no?
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.
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.
> it allows you to write horrible stuff, you can just as well get your shit together and do it maintainable
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.
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.
> 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.
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.
I fell off my chair when I installed R for the first time, and I discovered that I needed a FORTRAN interpreter.
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.
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.
That is not really the reason. The reason is mainly BLAS, that implements some of the most commonly used linear algebra operations (matrix multiplication, matrix solvers, singular value decompositions etc). This is implemented in optimized versions for almost every CPU available. BLAS is written in FORTRAN, but it is not true that it has not been reimplemented. In fact CPU vendors frequently reimplement it tailor made for their CPU.
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.
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.
FORTRAN is an amazing language for some very specific jobs and is still a great tool for a specific job. It's fast does scientific and numerical calculations incredibly fast.
I haven't touched Fortran in 20 years though :) I loved me Pascal except the semi-colon key broke on my keyboards.
I haven't touched Fortran in 20 years though :) I loved me Pascal except the semi-colon key broke on my keyboards.
Picking a(n extremely small) nit (with a fine tooth comb):
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.
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.
thanks. i actually went back and forth between compiler and interpreter and didn't think to look it up.
That'll show me to rely on my hazy memory of something I read five years ago on wikipedia =)
That'll show me to rely on my hazy memory of something I read five years ago on wikipedia =)
It should also be mentioned that when people use Fortran, it is usually because they need the fastest numerical processing available. An interpreter would usually not meet that need. With JIT compilers embedded in interpreters, the difference is blurred, since the result is machine code, unlike traditional bytecode interpreters, that usually are an order of magnitude slower than compiled code.
That said, I'm also not aware of any Fortran interpreters, and it would surprise me if there is one.
That said, I'm also not aware of any Fortran interpreters, and it would surprise me if there is one.
My vague understanding is that Fortran can actually be faster than C in certain numerical calculations because the language doesn't make the same kinds of guarantees. And therefore, Fortran will live forever.
Fortran disallows pointer aliasing and it has some language intrinsics which operate on arrays as a whole, so the compiler can emit processor-specific SIMD instructions. I'm sure that a very clever programmer could use restrict and inline assembly in C to get similar benefits, but you know as well as I do that having the language make these guarantees for you is helpful.
I posted this the last time I saw you making ~ the same point https://news.ycombinator.com/item?id=7316490
(And yeah, 10+ years old Perl code bases might be less than pretty... The environment evolves quickly, for good and bad.)
(And yeah, 10+ years old Perl code bases might be less than pretty... The environment evolves quickly, for good and bad.)
I think you made an interesting point, but IMHO it should be generalized:
> 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.
> 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.
The problem Perl has is that it is the language tied to the first dot-com crash. Prior to the dot-com crash, there was the AI Winter. This is where Lisp died, for almost identical reasons. When a major tragedy happens, someone or something has to take the fall.
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.
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.
This is the first time I have seen anyone blame perl for the dot-com crash.
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.
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.
> The problem Perl has is that it is the language tied to the first dot-com crash. Prior to the dot-com crash, there was the AI Winter. This is where Lisp died, for almost identical reasons. When a major tragedy happens, someone or something has to take the fall.
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?!
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?!
To me it sounds like a distortion of the truth: Perl was instrumental in spurring the modern dynamic language movement, but it in itself is all but dead. Perl (and I mean Perl5) is antiquated, and no modern shop I'm aware of uses it. There are always exceptions, but I don't see a lot of job postings looking for Perl programmers. Ruby, Python, et al, sure.
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.
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.
"Perl (and I mean Perl5) is antiquated, and no modern shop I'm aware of uses it."
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
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
> 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.
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.
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.
Why is it that you see Android becoming irrelevant? And when do you see this happening by?
Android is the new Symbian/J2ME. 7 years ago Symbian looked unstoppable, but look at it now. The same will eventually happen to Android, especially if Google continues down its current path of forced integration with Google+.
Google has a Samsung problem. I think they are in a bad position, such as Sun was with Java or IBM with the PC. They own the platform, but they aren't getting much from it that I can tell. I'm no psychic. But I can easily see Google dropping Android in a few years or Samsung forking it. Won't be good for developers or users.
One thing that's interesting in this context is the Firefox phone and its 100% FOSS web tech stack. I've seen projections of an additional 400 million smart phone users this year and maybe another 600 million in 2015. It seems plausible that Firefox phones will reach 10% of new smartphones by the end of 2015; if that happens I think it's highly likely that the game will change again.
I still write everything I can in perl. A lot of what I do is text manipulation on Slackware boxes. I work for a small company and the only other programmer is part owner. After 20+ years doing consulting, sysadmin, and programming work, the whole idea that what I'm doing isn't the "in" thing, is pretty amusing. I'll be 46 this year and I have gray streaks in my beard.
The thing about Perl that still makes it attractive is the fact that it's available just about everywhere. Go try script something quickly in a large enterprise environment with legacy crap all over covering Solaris, AIX, HP-UX, Linux, etc. and you will be guaranteed Perl is available on all of them.
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.
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.
All of those UNIXen are going the way of the buffalo as the world moves to the web. I haven't seen HP-UX or AIX system in a decade or more. Admittedly, I haven't done contract work in about eight years, which is where I previously saw those beasts (and others; for a short time I specialized in migrating businesses from SCO UNIX to Linux and made a small fortune doing it), but our software gets installed in all sorts of places and we used to hear about those systems pretty regularly...but the mentions of everything other than Solaris on our mailing lists and forums and IRC has slowed to practically nothing, and Solaris is in a slow spiral downward.
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.
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.
Wrote perl web apps since 1998. Now I'm seriously considering "selling everything and living on a beach in Thailand or Belize for a year".
Programming altogether, regardless of the language, lost it's magic touch for me. Sometimes it almost as funny and interesting as it was, but
it's just glimpses from the past.
Suppose this is what mid-life crisis looks like.
Or maybe it's what "burning out" looks like. Worked for my project for the last 8 years now and had too few holidays.
Or maybe people do change and I need to do something completely different from now on. I just have to figure out, what exactly I wish to do.
It's unpleasant and scary situation with no one to get help from.
See if you can find a way to try out other things. After working in IT for many years as a sysadmin, I too thought about baking. I have a friend who works at an established artisan bakery, so he let me come in and work for a bit (payment was in bread, which I had no problem with!) I quickly realized that it wasn't the right path for me and that I had things going quite well for me after all.
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.
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.
As others have pointed out here, diversification of skills is the closest you can get to a guaranteed job as a programmer.
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.
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.
I'm in mid-career now. While I still enjoy writing a really great app that people want to use, applications are mostly CRUD-based and a little dull. It's not the fault of my employer or any for that matter. It's just that fetching and posting data is a core of what organizations do with IT systems. For a while, fooling with new languages and frameworks made the work more interesting. But even that is getting old. I wonder now if there are more uses for computers than just CRUD-based applications. Unfortunately, organizations don't generally give a developer time to explore questions about software use.
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.
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.
I'm currently enjoying web-ui hacking as it's really the interesting part of the CRUD domain now that everyone expects js code to do interesting things.
If I stayed in application development, I'd probably move towards web design. I don't think enough has been done to make interfaces effective, pleasant to use, and intuitive.
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.
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.
Web UI is an interesting problem, but even just building a proper data structure can be very challenging, when the user's environment is complex and one needs to build a simple yet extensive enough tool.
I see it a bit as rock climbing : I looks simple, but not everyone can do it right.
I see it a bit as rock climbing : I looks simple, but not everyone can do it right.
In my experience as a worker bee (not an entrepeneur), after ten years or so you don't really get the best jobs from what is on your resume. You get jobs from people you know and have worked with. Chances are you will be a better fit if someone who knows you recommends you.
So when you think about what you should be doing mid-career: think about what people you have liked working with are doing.
So when you think about what you should be doing mid-career: think about what people you have liked working with are doing.
Programming for the last 30-something years, and the last 20 mostly in Perl. Every few years I got a job with Java or Python, or something of the sorts, and learned new things, but returned to Perl. Every time I returned to Perl, I noticed that my code style changed, improved, and I felt better about my Perl skills. There was not one point where I thought "let's just leave this behind and go with the new kid on the block".
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.
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.
I can give my take on the bakery idea. I worked at a
Bagel shop for a little over a year. It was a horrid job;
but I think my emotionally stunted, wacko, sexually frustrated boss made it worse than it really was? If
you took that waste of space Boss out of the question, running a bakery might be a good move. 1. If you are
not a morning person--forget about it. Getting up at 3:30 a.m. is something beyond jarring, especially if you are
a night owl. 2. Look for a long term lease. 3. Buy
all used equipment. 3. Keep your prices low. 4. Give
away product--get your name out there; product ingredients
are dirt cheap(Sysco). 5. This next line of advise is
more important than the rest. Treat your employees like
you would like to be treated. Your average employee will
most likely be young, strong, and a hard working--if treated
right. If you treat them right--you won't need to put two
hidden cams over the registers and back door. You sound
like a nice guy, so I don't think being nice will be hard.
I would be interested in opening a bagel shop in the Bay Area. I have all the recipes, and working knowledge, and some cash to invest. Respond to this post if you want to
talk about a partnership?
(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.
(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.
If he thinks he has it hard, trying being a mid-aged Perl programmer who ISNT chromatic. ;)
I'm a middle aged perl programmer who definitely isn't chromatic, and it definitely doesn't suck. On the other hand I spent a decade struggling through working inthe health system, then another decade through the university system (for whom I have turned down several pices of work over the past week), so I have a frame of reference.
Having said that, as a perl programmer, I seem to be hugely in demand for flashy javascript at the moment.
Having said that, as a perl programmer, I seem to be hugely in demand for flashy javascript at the moment.
I've been programming for over 7 years now. Learning this and switching to that. I've grown very tired of it... very tired.
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?
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?
I didn't like this bit: "The fact that my degree says Music and not "Computer Science" from Stanford, Berkeley, MIT, or CMU probably keeps me out of computer vision, AI research, and compiler design, however, just as much as it's garlic to the Google recruiters who want me to believe it's an honor to spend weeks answering questions about ping pong balls and sorting phone books for the opportunity to babysit a data center full of machines dedicated to slapping ads on the world's information."
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.
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.
I think we can find less negative interpretations of those.
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.
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.
We can disagree. What I was trying to say with #3 is that it's just an index. You use the index by using Google. If you don't like the index, don't use Google. But they aren't stealing the world's data so ownership doesn't matter. They are indexing it and creating a new bit of information, they own that. You know what I mean? It's just an index and they respect ROBOTS.TXT just like other crawlers (but not all).
I don't think we have a difference of opinion on what Google does, just on what chromatic was trying to communicate. I think he was implying that Google is a bit pretentious in their interviewing when it seemed to amount to a regular sysadmin job from his perspective. It appears what you took from it is an assertion that Google is somehow stealing data and locking it up, and that's a bad thing? I'm still not exactly sure what you took from his text on that subject, your reply seems to be justification of your position, not clarification on what exactly you interpreted and found worth rebutting.
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?"
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?"
I think he was implying that Google is a bit pretentious in their interviewing when it seemed to amount to a regular sysadmin job from his perspective.
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.
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.
Have you ever experienced the Google interview process for SRE?
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.
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.
Strange, I just went through the interview process for SRE at Google, and didn't have any such problems. (And I don't even have a degree.)
It happened to me more than once--and I heard similar stories from other people. It's easy to believe that not all interviews happen the same way, so I wrote "the Google recruiters who want me to believe..." rather than "All Google recruiters".
Best wishes for your interviews.
Best wishes for your interviews.
Thanks. I'm already hired.
I see no reason to ditch Perl. I've been using Perl for years and I use it at my company with little problems. For our SaaS web application Perl is a perfect fit and allows us to code very quickly.
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.
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.
Wow, I had forgotten about everything2 and c2... c2 was the first open-source-ish project I wrote code for.
[deleted]
Incidentally, if you're a decent Perl [on Linux] programmer and work well with teams, my company is hiring in Columbia, Maryland. It's been fairly difficult to find qualified candidates.
Perl 5 is the software equivalent of duct tape or superglue. Great for thousands of tasks you never really thought of and for lashing stuff together but just like you wouldn't use duct tape for building a house, you need to make sure you use Perl for the things its good at.
That said Python is now getting close to usurping Perl as software superglue.
That said Python is now getting close to usurping Perl as software superglue.
The thing about metaphors is after awhile, they breakdown when you attempt to use them for all facets of a subject.
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.
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.
In my experience when Perl is used in large projects it quickly becomes unmaintainable once the original developers move on. A lot of the recent work I've been doing has been migrating Perl projects to languages that are much more maintainable in the long term.
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.
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.
I suspect this is a problem with any project once the original developers move on and there's a break in institutional knowledge about the architecture and design reasoning behind a project. I also suspect it's more of a problem the more powerful the ability of the language to introspect and self-modify. Lastly, I suspect this is also paired with gains in efficiency in the design and implementation phase.
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).
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).
At least in the Enterprise world, the maintenance phase significantly outlasts the design and implementation phase in the majority of projects so any gains in those phases are usually dwarfed by the latter phases. The system I'm currently migrating has been in production for 10 years. The original developers are long gone, as are the generation after that. It's code archeology at its finest.
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).
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).
For better or worse, Perl is alive and well in bioinformatics. Lots of people are trying to change this, but at the moment it's a fact. So if you're a Perl programmer, are struggling to find a job that lets you wallow in the Perl pool, and don't mind capping your earnings around £50k, give bioinformatics a whirl.
In my company, a telco one, Perl is actively used as we have some inheritance of old systems coded in Perl. No chances to change it at a short term basis.
TIL perl is the language most likely be my generations COBOL.
I think that's actually probably gonna be Java.
It will probably be both, and maybe eventually php.
http://www.javainc.com/projects/jperl/
embrace the power of "and"
embrace the power of "and"
I can't even begin to understand how in the world Java will be perl. Granted I don't like it but it is used for so many things I can't even imagine it going away in my life time.
I'm fairly certain the statement is about Java becoming the next COBOL, not the next Perl.
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.
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.
Totally agree with that, let's see what happens in some years.
Bradley Kuhn wrote an article to that effect. http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html
Thanks for that. I'm only 18 months behind in my thinking!
Upvoted just for the TL;DR remarks. Dead accurate.
A note on labeling yourself a "Perl programmer", or an "<insert specific language here> programmer":
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.
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.
I was struck by the same impression: why label or restrict yourself to a single language? And why label all other languages as short-lived, low quality fads? Because that's what reading the two "tl;dr" sections at the top indicate. He's not doing himself any favours with that kind of statement.
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.)
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.)
Well, there's a popular term now for some HR people called T-shaped people. The idea is that you are a generalist that has some deep knowledge in at least one specific area. It's not a bad idea to pick one specialization if you are interested in something.
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.
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.
Why refuse any specialization? Some things take years of experience in a language to get right.
First, nobody should care that you can "hello world" in more languages.
Second, you don't have any preferences about what tools you use?
First, nobody should care that you can "hello world" in more languages.
Second, you don't have any preferences about what tools you use?
Of course I have a preference, but in general you work in teams, and the quality of the code base and standard practices of the group are more defining in how fun or productive something is to work on than the choice of language.
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 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.)
You're right about a lot of this knowledge being transferable, but I think you might also be underestimating just how much useful specialist knowledge you can acquire specific to a particular toolchain, and how much of a step back starting over can be.
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.
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.
That's exactly why it's useful to get familiar with multiple toolchains. If you are pretty comfortable with Ruby and move to Python, you'll have a pretty good idea about what pitfalls you'll encounter in a dynamically typed, interpreted language. Of course there's a learning curve, but it's less intense for languages with similar building blocks.
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.
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.
I can easily switch between dynamic languages, including Perl, Python and Ruby.
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.
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.
Sure. I don't think anyone is saying there's no value in mastering the toolchain.
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.
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.
But the OP was talking about blowing his life savings on a bakery because he couldn't find a job programming in Perl.
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.
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.
> 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.
Indeed, and I can say for sure the author of the post has such a low level knowledge of Perl.
Indeed, and I can say for sure the author of the post has such a low level knowledge of Perl.
I agree completely. This is particularly prescient for me because I finally made the leap from PHP to Ruby with a job I started 2/5/2014 (hold your applause :P). There's a lot to learn, but I actually find myself more happy and productive. Also, I'm a bit of a junky for learning new tools and the like so that's part of the fun.
I think the trend is that generally people are happy with the new language when they learn it because they want to. It gives you a chance to assess the warts of the previous language by seeing a new way to do things (and eventually an appreciation of what they did right but is problematic in the new language).
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.
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.
I think the statement was more like, "a developer uses the right tool for the job, a perl programmer will always use perl". (to the above poster, I hope I didn't misinterpret...)
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
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
I get a sense that some people change languages or frameworks frequently just due to boredom, inability to commit to any one thing or a desire to pad their resume with buzzwords.
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.
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 think you should specialize in programming concepts first and specific languages second. Once you have a deep understanding of lambda calculus, mutable/immutable state, lazy/eager, classes/functions and all that, then first it is easier to approach any language and second you will have a much deeper knowledge of the languages (yes it should really be more than one) you do specialize in.
>As a bonus, it can also improve your skills in your existing languages.
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.
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.
> 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.
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).
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).
You're right, everything is an object in Python. However, what I'm referring to is more on the application design side that you see in the enterprise Java community, rather than the implementation of the core types or builtins.
Hopefully this offends everyone &| starts yet another pointless religious debate: Java was a reaction to C/C++ (language safety); Python was a reaction to Perl's messes; and Ruby is polished Perl. And bonus: Go was a reaction to Java and C++ compiles taking forever.
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.)
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.)
There's hope! With a sufficiently complex caching and verification system, we can deploy chunks of JS that implement interpreters in-browser, last a long time, and can possibly be pre-compiled into an optimized form.
If we really view JS as assembly for the web, I think there's an interesting future.
If we really view JS as assembly for the web, I think there's an interesting future.
I would call Java hardcore class-based/design pattern programming more than hardcore OOP. If you want hardcore OOP try smalltalk or Common Lisp's CLOS.
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.
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.
He does seem unusually determined to remain a Perl programmer. I liked how he threw in the JS renaissance as somehow relevant to Perl because they're both from the 90s or whatever, a bit delusional if you ask me. It's painful to move on from the platform you spent so long mastering, but sometimes you gotta do it.
No i disagree with your interpretation, but that's because I'm a perl guy who is currently doing 60-75% javascript. Both are very pragmatic languages with significant design warts, but with enough useful higher level features to make them fun (unlike say PHP).
singingfish, I'm curious what you have in mind here. I've used each of these a bit and I haven't noticed PHP lacking high level features?
It's not introspective enough compared to the other big dynamic languages, it suffers from a lot of low range developers working on it, the namespacing is a mess (which leads to to the docs although relatively thorough, but a mess). My understanding is that things like CakePHP are an improvement, but given PHP's underlying design a bit of a shim. Don't get me wrong people do interesting stuff with php (especially the pornographers), but it's a kludge. I also don't like the tendency for close binding of code with a real web server that I've observed.
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.
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.
CakePHP is not an improvement, and the fact you'd bring it up sort of shows you don't use the language much if at all...
Yeah should have said 'cake php or whatever' I don't know what the latest and greatest is, but I know cake was one of them not that long ago. But the PHP I've had to maintain recently has had most of the old problems of perl style CGI with the disadvantage of a lack of the extremely good toolchain that perl has.
And PHP's design flaws are at the core of the language without the extendability that perl has.
And PHP's design flaws are at the core of the language without the extendability that perl has.
He is part of the Perl community, that's why. He not only uses Perl, he shapes Perl. Would you (easily) move away from something you helped shaping?
True. I think after learning Perl as a second language, I understood Java (my first language) a lot better. OOp in Perl is a bit of hack. Bust it is transparent and you see what is happening, unlike Java, where it is like a black box.
YMMV, but I found learning C++ to be a lot more valuable for understanding both object-oriented programming as a general topic as well as the JVM and Java specifically.
Any good Perl programmer should be able to adapt to many other languages.
The astute reader will notice that one soon can do s/perl/currentfancylanguage/g and this article is essentially about the b0rked interview culture/hiring process established with some corporations, be it small or big, established or incubated startup.
Good read, the TL;DR's are spot on :)
Good read, the TL;DR's are spot on :)
Thank you! I'm glad someone noticed my attempt to generalize from a specific situation. This cycle seems to continue every few years, but the solution has not made itself apparent yet.
Yes, precisely. And that's scary.
If you enjoy writing open source Web Apps and REST APIs in Perl/Catalyst for the Telco segment: we're hiring! See my profile for contact infos.
How can anyone not like to write "Web Apps and REST APIs in Perl/Catalyst" ?
See profile for contact infos :)
See profile for contact infos :)
aye, perl is still huge in the teleco and networking world. These guys are not without their technical management problems though, and some of them seem resistant to getting someone in to help fix the problems.
So you're saying that they're a "business"?
The particular teleco I'm thinking of ... they'd have way fewer problems if they got an independent person running their technical project management rather than an endless sequence of junior grunts
Colleague of mine is doing Perl for Apple, who apparently still use Perl on the production line.
I do heavy perl based lifting for a company with a similarly high profile to apple. As well as for a few other concerns too. It's certainly not dead if you know where to look/have a good social network.
Many of my fellow students sprouted Perl on their resumes after working at a storage company in Raleigh.
Yeah, EMC uses lots of Perl. Perl is pretty pervasive in plenty of large companies.
This rings true to me because it has echoed a lot what I am going through right now.
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.
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.
[deleted]
The first language I loved was perl, and I'll never forget the good times we had, but when I'm using ruby I don't miss perl.
> For someone whose life obligations preclude selling everything and living on a beach in Thailand or Belize for a year, how do you evaluate a career reaching its midpoint? How do you keep programming fresh? How do you market yourself as someone who solves problems instead of someone who transcribes ideas in the language du jour? Or do you leave programming altogether?
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.
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.
I think this comment actually reflects the point of the article. It's turned into a bun fight in the other comments about marketing yourself, when in reality it's about a developer bored with trends that offer marginal impact to organisations.
Something most middle-aged developers face is that chasing those trends becomes tiresome. The value you add to an organisation has a ceiling. If you're a Stanford Grad working his way up his latest hedgefund, you've got a road ahead of you. For most of us it's different flavours of CRUD.
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!
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!
"For me, the mechanics of budgeting are easy but the psychology of riding the business cycle is difficult." Running a bakery is effectively like consulting except it pays worse.
Starting a Bakery isn't courageous ... it's foolhardy.
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.
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.
Disingenuous how? If the person's goal is to define success by their happiness why not get out of programming if they're not happy doing it?
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.
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.
> If the person's goal is to define success by their happiness why not get out of programming if they're not happy doing it?
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.
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.
Actually there have been studies that have shown that while more money doesn't provide happiness, enough money is a pre-requisite. We're not talking a ton, we're talking enough to pay for food, shelter, and some basic form of entertainment.
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'.
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'.
> Actually there have been studies that have shown that while more money doesn't provide happiness, enough money is a pre-requisite. We're not talking a ton, we're talking enough to pay for food, shelter, and some basic form of entertainment.
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).
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).
> So I don't think it is fair to call it just a retail business.
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.
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.
I see what you mean. It is glib to say that opening a brick-and-mortar business is a walk in the park. However I supposed that if one is interested in such a venture then they would already know that it's not easy.
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?
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?
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.
"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.
"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.
First, big fan of your work. :)
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.
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.
"Heck, starting a software business and decided to grow to your first hires and worrying about making payroll is just as taxing."
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.
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.
If you need to take a break from programming, then take a break, but blowing your life savings on a bakery is not a good way to spend your break time. There are far cheaper ways to have fun and interact with people.
It's not really that foolhardy if there's always a career in CRUD. If it blows up or you decide it's not for you, there's always an option to pick up a contract or go back on salary. You don't really lose if you keep the downside to a minimum and you will gain from experience.
"there's always an option to pick up a contract or go back on salary"
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.
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.
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.