An often overlooked option is to look for a great programmer who knows any other language well and is willing to learn your shop's pet language. Hire him, provide some learning room, and he'll be up to Level Competent in no time compared to the time you need to spend looking for "a great Volvo driver".
Couldn't agree with you more. I've never been a big fan of the "good programmers are rarer than unicorn's teeth" school of thought, since both developers and business folks have their own self serving reasons for believing it, and because it's just not true in my experience. More likely is that there may not be any good programmers available that fit the exact slot they're looking for. If they'd just give a programmer who's 85% of the way there a little time to come up to speed, they'd fill their chairs with competent programmers in a fraction of the time. But instead, they'd rather hold out for a genius with years of experience in their exact little universe - and in so doing, screw themselves out of the much-larger-than-they-think universe of good developers out there.
That is correct, but hiring staff and recruiters speak a different language. At least in my experience, I used to get phone calls that a so and so firm needs a Django developer. While I used Pylons and Python extensively, and probably could learn Django lingo on the job, they wouldn't hear of it. In retrospect we were both right.
I've seen companies that have tried this and failed miserably. While programming languages share a common basis there are significantly different paradigms between say Ruby, C++ and Perl. While a good programmer could probably pick up any of these languages it'll probably take them a few years before their productivity is at the same level as someone of the same ability who has experience in that language.
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.
A few months, agreed. This time drops with each successive language. In addition to learning the language, a developer must learn the ecosystem. Perl and CPAN, Ruby and rubygems, etc.
I'm not talking about learning the syntax of the language, but things like design patterns, maintainability and readability. You need to read a lot of code to understand what works well and doesn't and it's language specific.
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.
That's what I'm talking about, too. Design patterns aren't that hard. Maintainability and readability are obvious, if you've got good examples to follow.
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.
"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."
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.
I am not convinced this is a good point against hiring someone who lacks depth in your language. It assumes that people already on the team have the same ability as the potential hire. This does not reflect reality. Different people learn at different rates. I have seen new people pick things up very quickly and surpass those who have been programming in that specific language for years. I am one, myself, with my present job. It is true there is a ramp-up time, but it varies with the person.
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.
It probably depends on how far the language is from the developer's experience.
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.
Are there good programmers who aren't familiar with the standard paradigms?
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.
That's also a great way to avoid stupid coworkers. If a company thinks you can't get up to speed on a new language quickly enough to be useful, it's probably because their current employees are incapable of doing so.
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).
Arguably Ruby and Python rank just as high, if not higher, on all of the first line, and do so without Perl's cruft and bloat. There's more to a language than just it's syntax, and even if Perl can have some pretty compact syntax - and it certainly can - that doesn't make up for it's weaknesses in other areas.
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.
One nice thing about ruby is that it has quite a few viable implementations floating around. MRI or YARV are probably what you have installed on your computer by default, but if multithreading and sane garbage collection are concerns of yours, JRuby is the right implementation to target. I'm not sure what's wrong with ruby's variable scoping, but I haven't used it for a while, so my memory of the ugly details of the language is a bit dim :)
"One nice thing about ruby is that it has quite a few viable implementations floating around."
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.
I see single-implementation languages as things to fear.
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.
I found Ruby's variable scoping to be quite clean: local by default, unless prefixed to be an instance variable (and a few conventions for statics and constants, I think). I wish Perl had similar scoping rules instead of the layered on later techniques of "my" and "the blessed hash". But I still like Perl :-)
However, the rest sounds like a valid criticism of Ruby.
I'm curious as to what your issue with Ruby's variable scoping is? It seems very straightforward and intuitive to me. Especially compared with Perl's mix of dynamic and lexical scoping.
Ruby's variable scoping relies on the compiler guessing the programmer's intent, as its syntax fails to distinguish between "Introduce a binding of this name within the current scope" and "Assign to the variable bound to this name".
Ambiguity seems, to me, to conflict with the desire for clarity and reliability. Any language which allows a typo in an assignment statement to create a new variable name binding silently is insufficiently safe for my purposes.
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.
"Any language which allows a typo in an assignment statement to create a new variable name binding silently is insufficiently safe for my purposes."
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.
Not part of the core language, is an add on. Nice trick, but Perl - that is to say, the language itself - still has pretty crappy OOP. Or has Moose been adopted as a core part of the language now?
Really, with Perl the distinction "part of the core language" is meaningless. You can install a CPAN bundle for a hardcore Perl in one shell command, or get it all preinstalled. Strawberry Perl for Windows has all the good stuff in a single installer, for instance, and if you're on Unix you've similarly got no excuse.
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.
Quite correct, and it's almost axiomatic at this point that CPAN is Perl's killer app. That said, I wasn't referring to great programmers - I was referring to the language itself.
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
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 sure I'm following your analogy here... You're making a bunch of false analogies.
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).
Clojure is only a Java extension if Java on my machine is an x86 extension. Besides, what's being argued here is that some things should be in the core, not the negativity of an extensible core. I'm somewhat on the fence on the issue. One one hand, it is great to be able to improve your own language. On the other, you are creating/using a forked version of the language, and all the other libraries won't be using your OO -or generic dispatch, or exception or namespace- system, making everything inconsistent.
True - most of what you'd consider "C" is really stdlib and stdio - but nobody would ever say that I/O isn't "part of the core language" because you have to use a library.
>>Namely, [Perl]'s Object Oriented programming that is a bad joke
>>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?)
In point of fact I do know about moose, since, like every other Perl user on the planet, I've been around the CPAN block at this point. And that's just the problem - it's in CPAN, not in Perl itself. I can get an object system just as good (or better) in either Ruby or Python without having to go and download an add on. By itself, Perl - without any modules or extensions or any other crutches - has horrid OOP.
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.
> 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.
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.
> You do realize they all default to lexical variables, and if you want something else, you have to declare accordingly, right?
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.
So your complaint is really that you have to install stuff to get better defaults in Perl? :-)
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. :-)
> So your complaint is really that you have to install stuff to get better defaults in Perl? :-)
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.
> 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.
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.
>>if you compare it to another programming language simply as a language
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.
> Perl is horrible (relative to other choices) for development, it ranks low on readability, refactorability, consistency, dependency evolution.
The flip side is that other languages are tediously verbose, require IDE's, lack flexibility, and need frameworks to accomplish the simplest of things.
Honestly, every language I've ever used it painful without an IDE> I should never ever have a typo in my code. "Oh, I meant to say stackFrame, not stackFram... silly me". If that happens, your dev environment is broken.
The downside of that kind of thing is when you misspell something in the header file and then auto-complete it throughout the code as you write, never noticing the typo until after you've checked it in and your peers start mocking you.
My response was mostly tongue in cheek. But I'm curious... where do you work that required code reviews before every commit? Seems like an awful lot of bureaucracy. For my projects I usually set up post-commit code review systems.
I'm at a startup now. But I think you'll find most of the big shops you know about, like Google and MS, generally practice pre-commit review.
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).
So where do developers checkpoint their work until the official commit?
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.
It is, but difficulty in requiring diligence in such a creative environment is the reason Perl has failed for larger team development.
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.
Reminds me of getting an answer from Tom Christiansen on stackoverflow. Most of his answers follow one of the two typical patterns:
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...
My point was that majority of that answer was completely offtopic. I'm not disagreeing that it catches the mistakes - but that this reminded me of the attitude described in the post above. tchrist might be a known perl person... but this comment was confusing at best - only one line actually relates to the question - "use autodie;". You must be also full of yourself to actually write something like "If you had begun with the standard boilerplate" - where "standard boilerplate" is actually "something I use" - and expect anyone else to actually use it.
Yes answers like this can be off putting but they are steered more towards the teaching you how to fish and are often be more valuable in the long term
BTW... sorry to be pedantic but it was the use warnings and not the use autodie that caught the problem.
> Most of the second line is on the programmers shoulder.
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 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.
I am curious about several things in your second line, mostly the refactorability claim, though. Perl has great testing tools, and its community has embraced them wholeheartedly for a decade* . I find the ubiquity of TDD-like practices among Perl developers make refactoring a dream.
* 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
That language war comment (w/out a reference) was voted to 8 in fifteen minutes... :-)
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...
Because programming is such a study-able thing... except it isn't. Too many factors to take into account, not least individual developer ability/experience/etc.
I'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.
There are Perl programmers who don't use CPAN? Why in God's name would they fail to use CPAN? I worship at the altar of CPAN; CPAN is my life and my oxygen. CPAN is the reason I will stick with Perl until the stars go out and the works of man crumble to dust - except for CPAN, for CPAN is eternal.
In my first job as a Real Programmer (rather than as a tech writer looking for excuses to write code), one of my first tasks was adding features to a script that read a particular kind of XML file. The parser, such as it was, was entirely hand-rolled; if you changed an input file so that it had a space in between tags instead of a newline, the whole thing would break. I wasted no time rewriting it to use XML::Parser.
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 spent the last week struggling with getting a hand-rolled source control monitoring system working, and finally ditching it and using CruiseControl (and getting 95% of what I needed out of the box), I empathize with you.
Have you looked at other language libraries lately? It's hard to find a really useful perl module that doesn't have an equivalent gem or entry in pypi. As much, as I like using CPAN almost every day, it's not something unique to perl anymore. Also, a lot of good stuff that people otherwise use from cpan is in ruby/python by default (oo, logging, testing, threading / multiprocessing, ...)
Some of the crown jewels of CPAN that have been ported to other dynamic languages leave quite a bit to be desired. For instance, last time I was helping a friend with a scraper I was really disappointed in brokenness of the Python port of WWW::Mechanize, and found the Ruby port to be incomplete for my friend's task. Eventually I wrote the parser for him myself and directed him toward another friend who was fluent in Python and Perl who could show him the ropes with Scrapy if he wanted to rewrite it later.
True - there's nothing exactly like www::mechanize, but really, you can usually write what you want with scrapy, beautifulsoup, html5lib, any of the tree/xpath implementations, etc. (I know, because I did, writing a quick form processor + wrapper for common functions in <1k lines for my page scraping needs)
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 ;)
Yes it is. Unlike viraptor I've been using Coro (http://search.cpan.org/dist/Coro/) successfully in production without any hitches and have services (including web apps) that are still running after 2 years without a reboot.
Yeah - definitely, if you can make it work for you. I just run into some situations where I expected it to do a context switch in async block but it didn't seem to (locked up instead)... I couldn't find the reason. Maybe it was my fault, or maybe just some tricky bit was missing from the docs - I don't know. Python-diesel is my default so I just went back instead of digging for the solution too much.
Also, the author fails to note that you can't hire great Perl programmers because the going rate for Perl programmers seems to be about $30/hour, and who can do that? I'll continue to earn my bread and butter in the non-programming trades in order to make sure my daughter's teeth are straight, thanks.
Depending on the nature of the job, yes, it is definitely low. If we're talking freelance, remember that you've got to account for your own self-employment tax and health insurance out of that.
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.
I don't know where you are, but in the UK $30 (so £19) or roughly £160 a day is a very low rate. I would say that, depending on the location, the normal rates are from three to ten times this figure (depending on area of expertise).
[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].
I agree $30 is low but It would be rare in Australia to see $90-$300 for fulltime employment pure development. It's certainly possible as a freelancer or as a more senior role though. Definitely as a consultant of some kind.
Agreed, I was saying $30 is low for fulltime workers. For a freelancer, given that they can only bill so many hours as you say besides other expenses and risk that employees do not have it is simply reckless.
The US is too large to just say $30 is low across the board - $30/hour plus good benefits is quite livable in some areas. In other parts, it's pretty hard to raise a family on $30/hour.
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.
> 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.)
Dude, I live in Richmond, Indiana, and my 14-room house cost me $8000. If this isn't pretty damn close to the cheapest place in America to live, I'll eat my hat and yours alike.
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.
A lot depends on habits, sure. One can develop expensive or inexpensive habits. Ours were mostly inexpensive, I suppose, but I never thought of them that way. Practically nobody I knew had a brand new car, so it didn't seem unusual that we had three old cars instead.
(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.
The median household income in the US in 2008 was $52,029. Probably with health insurance, but still. If $60k is pretty tight, most of the country has it pretty bad.
$60k is claimed to be tight for raising a family of 4. You're looking at households, which are not the same thing at all.
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.
Simple: because I end up creating a number of small scriptlet tools to pass around to other devs on the team, most of which know little about perl, and I want the scripts to just work, on various crufty computers, rather than fall into a dependency hell.
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...
There are many systems with Perl on them that are not on the Internet -- and getting security/IT folks to put CPAN modules on those system can sometimes take longer to do than just writing the functionality yourself.
> One of the persistent rationalizations for not creating new software in Perl is that it's difficult to find great Perl developers.
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.
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.
>> If it's difficult to find great Perl developers, that's because [fewer] great developers flock to Perl.
> I would like to see non-anecdotal evidence for this.
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.
I first learned about serious Perl development working for eToys.com. The web application scaled to a cluster of hundreds of machines and saw extremely high traffic. We had a large team working on it without any problem. The European warehouse management system was also written in Perl and was my baby.
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.
PHP: Embedding your code in your HTML seemed like a bad idea
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.
Yes, you're absolutely right and some of the greatest apps ever written are PHP apps e.g. Wordpress and Facebook. I should add, all the languages above are capable of creating the next Facebook. In the startup context, the most important thing is using what you are most productive in. Longer term you need to think about things like how hard it is to hire Ruby devs or how expensive C devs are or that you'll need 3.4 as many CPU's to run Ruby sequential tasks vs Perl (according to those benchmarks posted anyway).
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.
Can you name a language beside assembly, c and (in some cases) c++ that executes faster than java, in any significant way in anything but very uncommon circumstances?
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 ;)
> Can you name a language beside assembly, c and (in some cases) c++ that executes faster than java, in any significant way in anything but very uncommon circumstances?
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.
> No one is forcing you to use other people's best practices
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.
But in this case of "on the job", isn't your real problem with the employer's best practices and standards? Surely there are lots of people and teams out there writing Java in ways that aren't insanely stupid.
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.
> Surely there are lots of people and teams out there writing Java in ways that aren't insanely stupid.
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.
You can probably find a couple of other languages (ocaml?), but among the languages in common usage today (including perl) java is firmly within the performant bracket.
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've been using AnyEvent for several months now and really like it. It took some work to mentally sync up with it initially, but once it clicked I was happy I took the time.
True. I can't see why anyone learning a new language would choose Perl over Ruby or Python. And yes, I know all about the wonders of CPAN, awesome text manipulation features and all those things that come up whenever people try to defend Perl.
Oh please. It’s been shown over and over that modern Perl is a very pleasant ecosystem to work in, can we spare such childish comments for other websites?
This may be true today, but there is a cadre of developers who will never find out. Perl was our bread and butter 10 years ago, but we moved on when Python and Ruby came to the forefront, and have never looked back. To get people interested in it again Perl can't just be 'pleasant' -- it needs to be better in the way Python and Ruby were better back then.
zoul, I don't think that was a value judgment or a criticism. I think strick's point is that a new programmer is far more likely to pick up Ruby or Python than Perl these days - (s)he's more likely to learn it in school, more likely to learn it for a popular MVC framework, etc.
Speaking from personal experience - after years of using Perl, switching to Ruby was an immensely pleasant and gratifying experience. Many fewer wtfs per minuite, and a largely expanded set of capabilities. Perl may be capable of 95% of what Ruby can do, but learning the special cases and sticking points is a major PITA.
For me, learning Ruby after years of knowing Perl was a resounding "meh." The documentation is substandard compared to Perl's and it doesn't really offer anything that Perl does except for less weirdness in the nooks and crannies and some improved syntactic sugar in some cases (though when I look at Ruby code all I see is "end end end end end").
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.
And a direct result of that - if you have to hack on some recent application, it's much more likely to be written in something else than perl, so you rarely get the chance to learn more. The only one I run into in the last couple of years was octopussy... and that one's definitely not a work of art...
A few years ago I was interviewing people for a Perl programming position. The general level was shocking. Asked to rate themselves, many would give themselves a close to the top rating, where later it showed they had never done OO, didn't know the basics of unit testing, etc etc. Sad state of affairs indeed.
> Never having done OO doesn't make someone a bad programmer
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.
'Most common programming paradigm' it might be, but people's exposure to it will vary by domain.
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?
> 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?
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.
Attitudes like this are why I did CompE instead of CS. Yes you do learn OO in early CS classes, however you can use procedural programming in the real world to get excellent results. It is "bad code", but a lot of coders are interested in results more than "the current landscape of programming".
True, OO is not the only way to code. But if you don't have any experience with it, how can you make an informed decision?
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.
First, it looks like we've hit max depth on this thread, I can't reply to Nicks post (this is probably a sign that I should shut up now :))
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.
HN has a function whereby reply links don't appear immediately, there's a time delay (I think a few minutes) until they appear. The idea is to prevent people replying rashly to a comment that strikes a nerve, and to encourage rational discussion.
I think that's a totally fine and reasonable thing to say. However, I would then say 'I can't find any Perl programmers with the skillsets and domain knowledge I need', rather than 'The general level was shocking ... Sad state of affairs indeed.
This discussion has focused on OO, but my point was that their general level was very low -- it wasn't just a lack of OO experience.
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.
In the absence of information I can freely speculate about your job vacancy.
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.
When I started Haskell (early '99) I touched OO (C++) but wasn't like it much.
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 spent a year or so trying to help a company I was working with hire experienced perl developers to work on existing code. Pretty much all of the candidates were way below the standard required.
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 just hired a great Perl programmer days ago. It took just a few days. I will hire more soon. Compared wih hiring for a lot of other positions it was quite easy.
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.
Great, just what Perl needs: more FUD about Perl. /sarcasm
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.
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.
I like Perl. I am doing my own non-that-plain-stupid-website projects in Perl (for plain websites i am using PHP+Drupal). But I have no projects-for-cash involving Perl at all - looks like nobody is doing it today. And this means I have no real-world experience too. That's bad.
But I still love this language and will continue do own stuff with it. =)
This seems to be a common misconception, but it's still very much a part of the corporate and business landscape. Do some keyword searches on a job search engine - you'll see what I mean...
I started to earn bucks for living doing PHP development. In the beginning I tried to work as perl dev, but quickly realized that wordpress and drupal for freelance is much easier since there so much projects. And even with huge competition with indian/pakistan $5/hr devs, I was able to keep my rate at $50/hr..
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).
You cannor hire great perl programmers for the same reason that you cannot hire great programmers--they are a rare breed and an endangered species. Skills with a particular programming language are not a primary differentiator between programmers. A good perl programmer is likely to be (or make) a good python programmer, C programmer, C++ programmer, LISP programmer, etc.
This argument is invalid because it should hold also for PHP and there's no shortage of awsome PHP programmers. There are additional causes why it's hard to find great Perl programmers.
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. :-)
I've known a few good perl programmers, and a few ok ones, and I know for certain that a lot of perl programmers came out of the dot-bomb days and back then testing just wasn't part of the culture.
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.
QA is a not-automated repetitive (usually acceptance) testing. It doesn't have much to do with unittests and they're definitely not interchangeable. If you compare QA and unittesting... the argument is pretty much misguided.
Ideally, you should have both. And then some more automation. And quick feedback from automated tests.
If you like Test::More you should try out Test::Mini[1]. It's xUnit-style testing like Test::Class but with less syntactic overhead and fatal assertions instead of non-fatal TAP.
