> 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".

You totally misread me. I'm not saying you should use OO to be a good programmer. I'm saying you should know it.

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.

>But if you don't have any experience with it, how can you make an informed decision?

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.

For me to hire you for a senior web Perl programming position, I expect you to have experience with OO, that's all there is to it.

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.

What if your theoretical candidate on senior web Perl programming position knows about formlets, for example, and used them successfully?

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?

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.

The key word was "theoretical"; or are there really competent Haskell programmers that hasn't done OO? :-)

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. ;)