Why You Can't Hire Great Perl Programmers
modernperlbooks.com
modernperlbooks.com
You don't want this job - just move on.
It's key that you do have people who are already good with the language on the team for them to learn from, but if that's in place, a genuinely good developer is going to be able to pick up on the new paradigm pretty easily.
Understanding the Ruby way of doing things is different from understanding Ruby. Understanding when to use meta-templates in C++ is something you only learn by reading a lot of templated code.
After a few months you'll probably have only worked on a single code base on a tiny part of a project. You've no-way of understanding the ramifications of your design decisions will have on the project in 2-3 years time. You need to see multiple projects go from design stage to long term maintenance to understand issues such as where bugs get introduced, how code decisions impact maintainability, etc.
Sure, it may take a couple years for a developer who's absolutely stuck in the mud. But a good developer already knows multiple languages, already is familiar with multiple paradigms, and is capable of meta-cognition to recognize what the new patterns are, how they are useful, and apply them.
Very true - and that's why truly good programmers will promptly take it on themselves to read as much code in a given language as they can get their mits on after having learned it's basic concepts, syntax, and so on. Precisely because every language comes with a sizeable corpus of lore, best practice, idioms, and other such things that are the closest things programming has to an oral tradition.
For some people, different paradigms do not present challenges; they are just different approaches to the same problems. It might be easier for people who dabble around in multiple paradigms to adapt to the new language.
The people on the team have a great advantage over a new hire: they know more about the business and the codebase.
I can imagine it will take a developer only familiar with ruby, python & js quite a while to become productive in assembly language.
However, a good developer that knows e.g. python, php & c really well (moreso if he generally know *NIX really well) will probably not take an inordinate amount of time to become productive in perl.
I went out of my way to study functional, OO, logical and assembly programming just so I wouldn't be trapped in an imperative mindset.
And I don't really consider myself to be any too great, because I know that there's so much more to learn and I won't live long enough to learn all the things I want to.
Perl is horrible (relative to other choices) for development, it ranks low on readability, refactorability, consistency, dependency evolution.
For small tasks, Perl is my language of choice. Of course, there are no small Java programs - every data structure requiring a separate class, and every class (in some shops) requiring a separate source file, etc.
A small amount of Perl can get much done. I like being able to write small functions with clearly defined inputs and outputs, even if a routine has multiple outputs (suck on that, java!). Contrast with the 500 line java subroutine with 100 separate variables blendered around (no clear data flow) written by some apathetic slob.
I have only had one project large enough in Perl to justify OOP techniques, years ago. I've given up trying to persuade The Management to use Perl. It's just too much easier to find java work, especially here in the wilderness (Sacramento area).
Namely, it's Object Oriented programming that is a bad joke, it's weak-ass multithreading, the fact it's a walking memory leak, it's attempt to shoehorn two completely different variable scoping paradigms into one language, it's vast and bewildering array of special cases and exceptions to it's own rules....I could go on and on.
Disclaimer: I have used a great deal of both Perl and Ruby.
That's not nice all in my opinion.
I don't want "choice" concerning what implementation of my language to use. Unless I have some strange, specialized need, I want one implementation that is guaranteed to work. I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost.
The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on.
The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that.
There are good things about Ruby but dueling implementation breeding uncertainty is not one of them.
We definitely have different points of view then. I see single-implementation languages as things to fear. Software projects die, sometimes suddenly. The genius in charge might get hit by a bus, a particular implementation might violate the wrong company's patents, or the owner of an implementation might see an opportunity for profit. When you have options for language implementations, these risks are at least mitigated.
Unless I have some strange, specialized need, I want one implementation that is guaranteed to work.
I'd love guarantees of perfection too, but I've never seen one. I'm guessing that if I ever did see a guarantee of perfection, I wouldn't be able afford the software it was attached to. Software Engineering, like every other field of engineering, is about tradeoffs. Sometimes they're difficult tradeoffs, but it's your job as a professional to inform yourself and make the best decision you can.
I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost.
The point of garbage collection is that it allows you to focus on other things first, and then come back and look at your memory use. Even in a language running on a really advanced GC, like the Oracle JVM, you can't ignore your garbage. You need to close files when you're done with them or you will run out of file handles unnecessarily. You need to keep track of your heap use or your program will thrash and your GC will have problems. There's no silver bullet, but being informed about the details of your platform will help you.
The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on.
Forks are based on common code. We're talking about separate implementations, with different teams and different goals. Nobody working on YARV cares whether ruby interacts well with java libraries. JRuby developers do care. Different teams, different focus. I don't think a winner is going to pop out, and I don't see why one is needed. I do think a better GC for non-JVM ruby would be really good, and somebody probably will make a compliant ruby implementation that has one, but that won't hurt anything. If it's an overall better implementation people will move to it, and YARV will probably go into the background.
The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that.
The thing about C++ is that it's a standard, not a piece of software. There are dozens of active implementations focusing on the embedded space, windows, solaris, and other platforms. No one implementation is the best for all purposes, and a professional chooses the correct tool for the job.
There are good things about Ruby but dueling implementation breeding uncertainty is not one of them.
Is anybody really feeling uncertain about ruby's future because it can run on the JVM as well as running in a less dependency-encumbered environment? I can see people being unhappy about the most common ruby implementation having a crap GC and really bad threading support, but having people working on their own ruby implementations is only going to improve the situation.
Well indeed, the point isn't some much single-implementation languages as language in which I, the naive user, do not have to choose between implementations.
>> Unless I have some strange, specialized need, I want one implementation that is guaranteed to work.
> I'd love guarantees of perfection too..
Hold up. I would hope my language doesn't imply 'perfection' but "least-common-denominator-works". I was too strong with "guaranteed" but works in the "fairly normal" use-cases is good.
Even in a language running on a really advanced GC, like the Oracle JVM, you can't ignore your garbage.
Wait, who's "you" here. I the poster stand by the claim that I, the naive developer producing something really simple like a GUI to, say, move one file really shouldn't worry about GC. I the advanced developer producing something like an object-database indeed have to worry about GC.
- I would note with a Ruby instance copying one very large file from one to place another, you do have to worry about the GC, since MRI never gives memory back to the system, EVER. One of the founders of Twitters personally described to me discovering this to his horror, WELL into Twitter's period of trouble. Not at the start... and this was someone dealt DAILY with the system. DAILY...
Forks are based on common code. We're talking about separate implementations, with different teams and different goals.
I call BS here. What common code exists between Rubinius, YARV and company????? Seriously, I've been slackly following Rubinius for a while and unless they've added something recently, they have no common code. Rubinious has been trying to create a common test framework but that doesn't imply any common code. My impression is Rubinious doesn't even use the YACC code from YARV/MRI. Prove me wrong, it's happened before...
In a lot of ways, Rubinious' common test interface highlights the dead end of Test Driven Development as well as it's negative impact on Ruby. Software tests can't in themselves prove SHT, I mean they can't prove the equivalence of anything.
The thing about C++ is that it's a standard, not a piece of software.*
Well, that is indeed a good point. But the point highlights the problems of Ruby, which has nothing like a common standard.
However, the rest sounds like a valid criticism of Ruby.
I don't claim that Ruby and Python have security holes form this behavior, but people rightly criticize PHP's register_globals for similar reasons.
Um...Perl has exactly this problem. The only difference is that it's worse because the variable in question gets created as a global variable of the local package - which is naturally visible to anything else that wants to see it, btw.
This is exactly why they created "use strict", and underscores the "Perl philosophy" in an elegant nutshell - instead of fixing the underlying problem, just create a hack around it and expect everyone to "know" that they should use it as a best practice.
We fixed it in Perl 6, and I created a patch for Perl 5 to make strict default. I wish it had been the default behavior, but at least strict is available (and has long been a recommendation in every credible tutorial and online forum).
Note also that ECMAScript has recently introduced a similar strict mode.
irb(main):001:0> x = 0; xs = [1,2,3]; xs.each { |x| puts x }; puts x
1
2
3
3 ruby-1.9.2-p0 > x = 0; xs = [1,2,3]; xs.each { |x| puts x }; puts x
1
2
3
0
=> nilEvidently not everyone has kept up with Moose (released back in 2007, part of the Perl renaissance, can be learned in a few minutes.)
Really. "Core language" is kind of twentieth. Moose is very well-established in the Perl community. That's as core as it gets.
So is DBI, Perl::Critic, cpanminus, perlbrew, Dist::Zilla, Perltidy, and (depending on your version) autodie. That's why my definition of a great Perl programmer includes pervasive use of the CPAN--you're restricting yourself unnecessarily if you avoid it.
I'm not sure I understand why basically having to patch your language to get a feature that others have out of the box is not seen as a weakness of that language.
Now, we can talk about Perl + CPAN and all the jazz you find therein, but that's a different discussion. My point is, taken by itself, the language Perl does not have an especially good Object system, especially if you consider Ruby and Python the competition.
"So is DBI, Perl::Critic..."
What's your point? Database bindings and lint like code checking are not features every developer - or even a good chunk of the developers out there - are going to need, or have use for. By that logic I could point out that Perl still wins no points because Ruby and Python - and just about every other contender out there - has their own equivalents.
I'm not referring to CPAN or the the gobs of stuff in it - I'm referring to the language itself And while we're on CPAN, much of the popular and useful material in CPAN has equivalents in Ruby and Python that are every bit as mature and useful.
* assembly is weak because it lacks pointer arithmetic
* C is weak because it lacks a proper OO
* Java is weak because Clojure is an add-on
* Ruby is weak because Rails is a separate download.
I assume nobody really believes any of this meme-noise.
Compared to C it is. That's why they invented C.
> * C is weak because it lacks a proper OO
Compared to C++ or Java it would be - that's why they invented them.
> * Java is weak because Clojure is an add-on
Not sure I'm following your analogy here.
> * Ruby is weak because Rails is a separate download.
Have I been saying anything about web frameworks at any point?
You're making a bunch of false analogies. Compared to nothing other than itself, Perl is Perl. That's fine. It's axiomatic. Compared to other options, however, it does have some glaring shortcomings.
Not false at all. Substituting FP for OO, the Java install "lacks" Clojure. So extensibility is a weakness? If so, then every gem is a sign of a defect in Ruby The Language (an absurd conclusion).
>>Disclaimer: I have used a great deal of both Perl and Ruby.
You haven't used Perl lately -- then you would have known about Moose. Perl's OO is now arguably much cooler than the OO of alternative scripting languages...
Your point about variable scoping is really strange. Or stupid. Could you elaborate?
(Threading do suck, imho. But so it seems to do for most other scripting languages?)
As far as scoping goes, I shouldn't have to explicity declare a variable lexically scoped - and I can't think of any other language where I do. Only Perl - and only because it's visibly hacked in after the fact, along with a number of other features.
Threading is not great for Ruby or Python either, because they use green threads - but Perl has problems bigger than that with it's threading.
Really? I can think of a few: How about C, C++, Java, Lisp, and Javascript? (Yeah, technically javascript is function scoped if you declare it with "var", but you have to do that to prevent it from being global).
You do realize they all default to lexical variables, and if you want something else, you have to declare accordingly, right?
>Lisp
Is a beautiful language, and primarily a play-toy for academics with a handful of real-world applications. While we're at it, which Lisp? Ansi Common?
> Javascript
I believe it is exactly this quirk in Javascript's scoping that is a major complaint of many developers - although I don't know much javascript and can't speak with authority here.
I don't understand your argument. You have to explicitly declare lexical variables in those languages. Ditto for Perl:
$ perl -e 'use strict; sub x { $i = 0 }'
Global symbol "$i" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.Sorry, but that is hard to take seriously.
>>I shouldn't have to explicity declare a variable lexically scoped
Are you saying you don't like strict? Without that, you're fscked if you spell a variable name wrong in the same way, twice... (I really don't get that not all scripting languages have strict.)
I've avoided threading in scripting languages as the plague, but I tend to agree with you as far as I've read. :-)
No, my point is that if you compare it to another programming language simply as a language, it is basically missing a major feature. If you take Ruby, Python, and Perl, and line them up next to each other simply as languages, Perl is at the bottom of the pile on it's own merits where OOP is concerned.
> Are you saying you don't like strict?
Even if I use strict, good software development practice would dictate using a lexically scoped variable at all times unless I really need something else. That's one of the reasons lexical scoping is the default in so many languages at this point.
Reminds me of a Larry Wall quote: "I don't really know much about Python. I only stole its object system for Perl 5. I have since repented."
Really, Perl's native OO stuff just lacks syntactic sugar. "Bless" is admittedly weird. And you have to write "new" yourself. If you get over those 2 things, it's really quite the same as everything else.
Perl is extensible by design. Your "point" of refusing to accept that is just strange. If you can't handle it, use something else.
>>good software development practice
As __david__ noted, you're just strange here.
Variables really should be declared, as I noted before, just because of spelling problems. That is good software practice.
Edit: I might be missing the point re "strict", but you can't explain it to either __david__ or chromatic, either. :-) And it seems your "point" about downloadable extensions is that you don't have anything to complain about without that arbitrary limitation.
I think you're missing my point entirely. And I can "handle" it just fine since I've been using Perl for years now.
>Variables really should be declared, as I noted before, just because of spelling problems. That is good software practice.
Again, you're missing my point completely.
The flip side is that other languages are tediously verbose, require IDE's, lack flexibility, and need frameworks to accomplish the simplest of things.
Language-memes. Less fun than they used to be :)
No language requires an IDE, either.
Come to think about it, the same can be said about Objective-C
Second, to fix the typo, fix it in one place, and click->"rename" and it renames it everywhere else.
Last, if your IDE has spellchecking support, it will let you know that part of your name does not exist in the dictionary.
Open source projects often will do post-commit review. The review process is viewed as friction, and they don't want to block contributors due to the review process.
I personally prefer pre-commit review, although post-commit is a legitimate option (one I admittedly wasn't thinking about at the time).
Either:
The smarter ones have to maintain a second source control archive (unless they are allowed to make personal branches, in which case the "public commit" is really just a merge, and probably a good thing),
or
the dumber ones just work without a net, loosing changes, and/or having to manually back out edit and test sessions that didn't go as well as hoped.
Oh, and I just realized I'm replying to the same guy about this.
Early, and often, that's how. Surely you don't forbid a dev from saving his/her work (where it's backed up) and keeping a stream of "undo" checkpoints in the repository until only after somebody else had a chance to look it over???
Now, it does make sense to have a review before merging a development branch to a release candidate, but not to block check-ins/commits in general.
OK, so I've known senior staff who did want to have just this sort of restriction, and I found it foolhardy then, as well.
I was once praised for the readability of my Perl code by a junior teammeate, and immediately scolded by the best Perl programmer on the team with "yeah, because he makes it look like C code".
Don't get me wrong, I like perl, I just think its unique characteristics make it a poor choice for complex, long-term software, which is where the most money is, and thus the most people/candidates.
1. an extended regex to do what you want in every encoding known to man, extended to use cases you never mentioned, taking 10+ lines to replace one character with another (with occasional angry remark about random other language where "it's impossible to do that")
2. "it doesn't work, because you're not using my standard boilerplate" - followed by 20+ line boilerplate setting a lot of different things where most of them are not even remotely related to the question... because everyone should be using his boilerplate...
BTW... sorry to be pedantic but it was the use warnings and not the use autodie that caught the problem.
Train-and-blame is a poor and ineffective way to ensure quality and consistency. Good engineering designs quality and consistency right into the system. It's possible, for example, to write ugly, unreadable code in Python, but the language design itself strongly pushes you toward writing elegant, readable code.
The language design itself strongly pushes you toward indenting the way Guido indents. The rest (effective decomposition, good naming, testing, intelligent default behaviors, algorithm choice, comments and documentation) is on the programmer's shoulder, as it is in every language.
* The very first Perl release in 1987 actually had a test harness which eventually grew into the modern TAP system, but the 'testing revolution' in the community dates to 2000 or so
Edit: 17 after an hour. Try writing a language flame without references to studies or anything about e.g. Python in a Python discussion -- and see how the votes go...
*Not really**
**This is called sarcasm.[1]
[1] http://en.wikipedia.org/wiki/SarcasmI'm not shocked that you like to troll language wars, I've been a kid myself. (And if you do this after 30, please don't tell me -- I'd like to keep some illusions about humanity.)
What do shock me is that this kind of sh-t gets upvoted by so many on HN. I have lost a lot of respect for a couple of open source language cultures, the last year or two. Which is damn sad.
In my second job as a Real Programmer, I had to add features to a script that parsed scripts in the Informix Perform Screen language. Again, this was hand-rolled. I wasted no time rewriting it to use Parse::RecDescent.
I think simply knowing where to look things up puts you in the top half of professional programmers. Possibly the top quartile.
Having just re-read "A Deepness in the Sky", I really want to make a programmer-at-arms reference.
You will rarely find an exact port of some other foreign library that will work exactly like you expected the original to work. That goes both ways - for example there's loads of async frameworks in python, but it's really hard to find a good one in perl. Sure - there's AnyEvent and POE, but they're just bizarre monsters compared to much cleaner simple solutions like diesel. There's Coro... but that's a longer topic than I'm willing to discuss here ;)
PS. For my Coro webapps I use Continuity (http://search.cpan.org/dist/Continuity/) & Squatting (http://search.cpan.org/dist/Squatting/)
The last time I did any serious freelance software work, five or six years ago, I started out charging $80/hr, and was still selling myself short.
[Edit - any time I see "daily rate" I think of contracting - £160 a working day as a salaried employee is probably on the low side, but nothing exceptional].
Maybe I'm just a terrible screwup, but in 2004 I qualified for EIC and left programming entirely because the bottom had fallen out of the Perl market. And I've never gotten benefits.
And no, $60K is pretty tight for a family of four anywhere in the US.
That's... not true. I came from a family of eight who never had more than $50k income (no health insurance), and I don't remember ever even having to think about it. We had multiple cars, a large-ish house, etc.
This was of course not in a city, but it's not the cheapest place in the states either. (After a bit more googling, I may have to retract that last statement. If it's not the cheapest place in the US, it's awfully close.)
Sure, back in the olden days growing up 20 miles from here on the farm, we didn't have squat, either. But seriously, my daughter's braces cost $5200. No joke. Maybe it's just that I can't survive on a diet of Marlboros and PBR any more, having seen something of the world, but $60K would simply not be enough.
(Five of us kids had braces, by the way; and five of us had glasses, and one had hearing aids. I know none of those things are cheap.)
...Anyway, I seem to have dragged you into a rather off-topic discussion. Sorry about that.
According to the table at http://www.infoplease.com/ipa/A0884238.html (which claims to be using census data; I tried digging through the census website for this information but actually finding it there is a pain) as of a few years ago 27% of households had 1 person. 33% of households had 2 people. You will note that adds up to 60% of the households. So the median household size is 2.
Households with at least 4 people (the ones that $60k is claimed to be tight for) make up, according to the same table, about 23% of households.
It would be interesting to look at the income distribution for such households, since _that_'s what would be relevant to the concern you're raising; I would expect their median household income to be somewhat faster than $52k, though possibly not a huge amount more. If you can figure out how to get this data from the census website, I'd be really interested.
Now, if I were building an application in a defined environment, that would be different.
Maybe I should demand a better working environment? I took the money instead. (I make considerably more than the $30/hr quoted elsewhere in the comments) This means I have to cope with a lot of crap, but it does provide for a family...
One of the persistent rationalizations of Perl mongers is that Perl still has that much of an edge.
If it's difficult to find great Perl developers, that's because less great developers flock to Perl (if at all, maybe current great Perl developers are people who have learned Perl some time ago). It is that simple.
Perl in its days used to be a great language for those who looked for a "creative" one to learn, and allowed to do things other languages didn't. PG has said Perl was a language for hackers.
Nowadays, there are way more options if you are looking for a learning experience, and I dare to say that many alternatives are way more rewarding than learning Perl, and have a much better effort/learning ratio. In the same time you are memorizing what value every standard function returns in what context, you could be composing functions in Haskell or building massively concurrent Erlang systems. Heck, even the humble Javascript allows you to perform mind-bending dynamic feats. Other languages offer multiplatform support (native, Java, .NET) which Perl lacks.
I would like to see non-anecdotal evidence for this.
Heck, even the humble Javascript allows you to perform mind-bending dynamic feats.
It's also borrowing features Perl has had for years. Hm.
Other languages offer multiplatform support (native, Java, .NET) which Perl lacks.
That definition of "multiplatform" differs from mine. Perl 5 runs on more platforms than the CLR and JVM do.
In theory. In practice, if it runs on one JVM, it runs on any JVM. No questions asked.
Perl is full of, "Oops, that crashes on Windows" traps. If you know where they all are, you can avoid them, but it's hard to be sure you've found the last one. The fact that the camel book has a section with tips for porters is telling.
There's a big difference between Java's robust guarantee of portability and perl's "best effort" philosophy.
I have Perl code from a decade ago that still runs on VMS. Can you show me similar Java code?
The fact that the camel book has a section with tips for porters is telling.
The Camel book is a decade out of date.
No non-anecdotal evidence for this, sorry. It's just a result of thinking about what Perl offers and what current languages offer. I know Perl quite well, you know.
>> Heck, even the humble Javascript allows you to perform mind-bending dynamic feats. > It's also borrowing features Perl has had for years. Hm.
Right. Just like Perl borrows features from other languages.
>> Other languages offer multiplatform support (native, Java, .NET) which Perl lacks. > That definition of "multiplatform" differs from mine. Perl 5 runs on more platforms than the CLR and JVM do.
My comment is not about platform themselves. It was more about: "I need to hook this Java/.NET library" and then there are languages where you can just switch platform (interpreter or compiler) to interface such a library natively.
See, Chromatic, when I met Perl I was amazed by its capabilities and progressed to read advanced books about this language. But nowadays, after meeting other languages, I regret my time spent with Perl, and I wouldn't recommend such language to anyone, just like I wouldn't do that with C++, another language in which I have progressed to what I think is almost "wizardry".
After a lot of time spent in learning different languages, I do think that there are languages not worth learning. It may sound arrogant, but I think so, and I think that experienced developers have the right to think so and make newcomers spare time.
Do you think Perl is worth learning? You are entitled to that. Don't I think it is? I'm entitled too. And both of us are entitled to share our experience.
After seeing what Perl can do in terms of development speed, maintainability and speed of execution I've never looked back. I've worked on a ton of great projects since then and today I run my own startup with a tiny team, a tiny cluster and we serve over 600 application requests per second all from modperl, nginx, apache and mysql.
I've seen languages come and go over the years and here's what I've thought:
Java: In the late 90's I wrote a few java apps thought it was a cool language. But I didn't like that it was proprietary. I also had the opportunity to ask Steve Balmer about the Visual J/Sun lawsuit while I was at Credit Suisse. The whole thing just turned me off and I moved on. Thankfully I did, because today it's still dog slow to develop and to execute and now it' belongs to Oracle.
PHP: Embedding your code in your HTML seemed like a bad idea and still does.
C: I've seriously considered switching to C for web apps over the years, but the performance gains haven't justified the increased complexity and added time to code or prototype.
Ruby: I first dabbled in Ruby in 2005 but realized it was Perl in the early 90's and that startups are risky enough. I still eye it keenly, but it just can't touch ModPerl's performance and stability and more importantly, it's availability of libraries. It will one day though and then I may just drop everything and join the party.
Javascript on Node.js: This is the most exciting development and web languages since Perl simply because you can write asynchronous apps (single thread that handles 1000000's of clients concurrently) in a high level language. I'm already using Node and am REALLY looking forward to more libraries being available and to them being more stable. Things like db drivers, crypt libs, date, html and text manipulation libs. Node is the way of the future.
It's a terrible idea, but it does have the advantage of giving you a good way to separating the wheat from the chaff. Solid PHP programmers never (or very, very rarely) embed PHP code in HTML.
A word about benchmarks: The mostly don't matter unless you're at Facebook scale and trying to eek out another 3% profit margin or unless you're running a widget (or similar) business that relies on massive app volume for distribution with very thin margins. If you're a 2 person show writing a regular app like a dating site, classified ads site, etc, then by the time you're doing any kind of volume, you're going to be so massively profitable that you really won't care about these benchmarks. Also these days people and their time are way more expensive than hosting fees.
Thankfully I did, because today it's still
dog slow to develop and to execute and
now it' belongs to Oracle.
Nobody says you have to like java, but unsubstantiated anti-language propaganda doesn't really add much to the conversation (as perl user you should be the one to know ;)
The VM is great, but the Java community's "best practices" are insanely stupid. It doesn't really matter how fast your VM is when web requests are going through a couple dozen filters or getting serialized/deserialized to XML.
This is only true if you only work on your own code or you call all the technical shots.
Part of working with other people is coming into agreement on how things are done. When you're working on someone else's code, you play by their rules. Nobody forces you to do this, but if you don't you're generally not someone most programmers would want to work with, professionally or privately.
This tends to occur on the job when you get something dumped on you with a time constraint. Your options are to use other people's practices, argue that yours are better (which usually requires a restructure and pushes back the time constraint), or quit. Nobody forces you to go for the first option but the second two are the more difficult paths.
Teams can use even the most pristine language and introduce a lot of dumb ideas and practices into it. I think you're beating up on the language unfairly.
This is true. I know of a number in Java and a lot more in JVM languages. To be clear, this isn't about my work since I rarely have to write Java and my coworkers are smart so the code is relatively good.
> I think you're beating up on the language unfairly.
J2EE was a travesty. Java class hiearchies are ridiculous. The codification and practice of design patterns is excessive. XML gets used all over the place for all sorts of things. None are required for the language, but they're encoded into the best practices of the community. The whole point of best practices is to help people avoid dumb things, but somehow the Java community got it wrong. I blame the consulting industry and the design goal of trying to protect people from themselves.
If you love Java, are super productive in it, and your programs blow everything else away, power to you. I know two guys who love Java and are faster than I am at implementing an algorithm even with the LoC advantage I get in my preferred languages. The language is what it is with advantages and disadvantages. My inability to get over its flaws shouldn't hinder your joy of programming.
Have you tried AnyEvent or Twiggy for Perl?
That's a shame, but that's the way it is.
And Python certainly has its own feel. But again it's not really any more powerful than Perl and offers nothing but an alternate simplified syntax. Programming in Python makes me really miss Perl--I always feel like I'm speaking baby talk instead of full blown English. Really elegant baby talk, but baby talk none the less.
I really doubt this is unique for Perl though.
Unit-testing is a bit less forgiveable.
Well given the current landscape of programming, yes, it does make them very bad programmers. If you haven't explored the most common programming paradigm, you're a bad programmer, or a 1st year student.
Would you say that someone who has been coding embedded systems for 30 years in assembly and minimalist C is a bad programmer just because they've never done OO? Despite the fact that for what they're doing it might be a bad choice, and they've specialised into an area that is vastly different from what you might expect as the norm?
If all that's been doing for 30 years, then probably, yeah. They might be good at their job, but an overall good programmer? Maybe they were great 30 years ago, but if they haven't raised their head to look around at the evolution in the industry and kept up with newer trends and developments, the level of skill atrophy would be quite large.
edit: also it depends on what type of programming you're supposed to do. This particular case was for web development, and in that world I would say OO is quite a fundamental concept.
Of course, the answer is "by utilizing experience of others" or "comparing my efforts to others' efforts".
That's how progress works, I was told.
Sorry, I was not very clear in my first post. The job was advertised clearly being on a web system, looking for experienced developers. I don't have a copy of the ad any more, but I'm quite sure it specifically stated OO as wanted experience.
My main point with the first post was to highlight the disconnect between the level they graded themselves at, and the level at which they actually were. If I'm talking with someone claiming to be an experienced Perl web developer, I'd expect, among several things, they would have OO experience.
(If anyone's interested in the end of the story -- we gave up on trying to find a senior person, and instead went with a guy who did not have much experience at all, but came across as very keen to learn. It worked out very well).
edit: oh, now I have a "reply" link under Nicks post. oh well, too late.
Formlets: http://hackage.haskell.org/package/formlets and then http://groups.inf.ed.ac.uk/links/formlets/
Does he still need to be proficient in OO?
What if your candidate knows much about your current problem domain? Do you still prefer someone who doesn't know a bit but proficient in OO?
Good knowledge in some other area would have made it a lesser issue that they didn't have OO experience, but they were generally lacking knowledge across the board.
Your proposed salary was low, your offering uninteresting, etc.
Myself, I crossed Perl and Python (and Ruby, and Smalltalk, and Lisp and many others) from list of languages to discriminate good programmer from not so good one a long time ago. They just did not get used in anything I consider interesting or important (but I still prefer domain knowledge - so lisper with relevant past is still interesting).
Right now I would use Haskell (or even stronger typed language like Coq or Agda) as a requirement, and my proposal would include DSeL for problem domain with Perl backend (if Perl is that necessary).
I will get much less resumes initially, those resumes will be of higher quality and my employee will produce a tool that allow me (us as a team, actually) to retarget our product to another backend quickly if we need to do so.
Actually, I specifically searched for a language that wasn't OO but provide all the benefits of OO when I found Haskell. The standard library back then was about twenty or less modules.
I don't really match against most of my colleagues right now, they done much more OO than me.
So, until recently I was really competent programmer with Haskell experience in useful programs that hadn't done OO. ;)
I came to the conclusion that this was probably a question of maturity. I think experienced perl developers are now an enclave of older programmers who've stuck with it and are now entrenched experts. They're all too expensive.
There seems to be a generation gap, presumably where everyone ran off and learnt ruby or python, as perl 5 was perceived to be stagnant, for whatever reason.
I think what remained in the available salary bracket was either people who weren't very good, or were too new for it to show either way. Anecdotal, of course, but it reminded me of other job markets I've seen entering the first phase of an eventually near terminal decline.
I picked him out of 40 people. Most of them didn't really know Perl well, but the code of the people that did stood out very clearly.
There are different measures of greatness. Using exclusively the most modern Perl idioms is one measure. Another measure is getting shit done. Another is writing code that can be read by the average Perl programmer.
IMHO the second two of those are way more important than the first one [edit: note I did not claim that any of them are mutually exclusive]. The author of the blog post is pushing a good agenda (promoting modern Perl) but doing so with tactics that end up adding more harmful FUD to Perl's already shaky reputation.
How so?
If Perl can't survive the honest admission that a lot of people writing Perl aren't great programmers, that the design of the language encourages people to be able to write baby Perl and still get their work done, and that the existing core Perl community needs to find these people and encourage them to improve their skills, then Perl doesn't deserve to survive.
"the group of people with a little bit of knowledge (likely due to ad hoc experimentation and intuition based on previous familiarity with another programming language or Unix culture or just copy and paste osmosis from a barely-working heap of sticks left by the previous maintainer) dwarfs that smaller group of experienced programmers."
I think one of the reasons there are a bunch of people with just a "little bit of knowledge" is that there are a bunch of gigs where that's enough. I also think that its a tremendous mistake for people to take these types of jobs if they have any personal ambitions to reach that "experienced programmer" level. Unless your personal situation dictates that you have to.
But, the trick is that the ad-hoc experimentation and intuition is a necessary first step to moving to the next level. I'm personally interested in figuring out what you need to really grok in a particular programming paradigm/language to be a really great hacker using that paradigm/language.
But I still love this language and will continue do own stuff with it. =)
Now corporate - probably, but I was doing freelancing work, not full time employee. Nor I had any product to sell to corps (this is what I want to try tho eventually).
That's the comfortable niche that they enjoy. Why would they want to lower their salary bracket building web forms?
But do mediocre Perl programmers really not use Test::More? (-: Hell, even I do! :-)
Testing has been central in Perl for most of a decade. I browsed "Intermediate Perl" recently (I'm outsourced and will train a few newbies the coming weeks), and already that beginners' book did a good overview of testing (mocking objects, etc).
Let me note that the author isn't exaggerating when he claims "Modern Perl" is really good. :-)
Edit: Grammar.
Not misunderstand me, writing tests for published modules was expected, but with everything from scripting to websites unit testing wasn't that common at all.
It wasn't a big problem either, because when the perl shop got serious, it ramped up the QA, and even possibly had a less buggy product than today, because QA can be brutal, and unit testing can be LAZY and misguided.
Testing fanboys flame me all you want, but I was there, this was common, we walked to work both ways uphill, but built the foundations of the web you see around you.
Ideally, you should have both. And then some more automation. And quick feedback from automated tests.
Yes, but I wrote "Testing has been central in Perl for most of a decade."
I was mostly doing C++ at that time, but when I looked at Perl again a few years later -- testing was like air; everywhere.
>>Testing fanboys flame me all you want
Nah, I found "religion" after the dot-bomb, too. :-)
[1]: http://search.cpan.org/~pvande/Test-Mini-v1.1.1/
edit: link
It is easy, powerful, has lots and lots of support (I'm going to add Hudson integration tomorrow for some stuff.)