[JOB] Perl Software Developer and Database programmer

[Lusercop]

On Thu, Feb 23, 2006 at 12:37:25PM +0000, Andy Armstrong wrote:
> On 23 Feb 2006, at 11:36, Lusercop wrote:
>> What a good reputation to give Perl. Some of us work hard to rebut the
>> reputation that Perl looks like linenoise. Some others seem to want to
>> constantly undermine it. You and Andy are doing a very good job of the
>> latter!
> Perl does sometimes look like linenoise. If you don't like that  
> aspect of Perl why not check out another language rather than living  
> in denial?

I'm perfectly capable of writing readable perl, thanks. I'm also capable
of writing linenoise. I have programmed in several other languages. My
current employer's codebase happens to be in Perl.

In another post in this thread someone (I can't remember who, and the thread
has got too long and involved for me to find out) talked about interview
candidates discussing the downsides to the language. In this case, a
downside to Perl is that if you're not careful enough, it can turn into
linenoise.

Don't get me wrong I like Perl, and I do enjoy the occasional bit of golf
and in my case, shaped programming (bet you didn't know that the sigils
are separable from its referent with whitespace, for example). However,
people who use things like operator overloading (which can be neat) or
separating the sigils from their referents in production code shouldn't
be programming. I can see very few uses for the kinds of operations that
you have been talking about that couldn't be better done in other ways.

(Or perhaps you really want to use Tcl and uplevel/upvar for what you're
trying to do).

>> Yes, agreed. And if you avoid the mantraps, then you're more of a software
>> engineer than a language hacker, neatly bringing us back to where we started
>> the thread.... (go back and re-read my first post in it)
> That's a pretty tenuous implicit definition of both 'software  
> engineer' and 'language hacker'.

Perhaps. I see someone who is a software engineer as writing for
readability and maintainability, and having a better overview of the
whole software development process. If you're using things that could
be conceivably considered mantraps, then how is that writing for
maintainability? I think this implicit definition of software engineer
is perfectly reasonable at this point. I'm possibly being a little unfair
with "language hacker". Of course you can be both. There are sometimes
reasons to do horribly complex operations in order to make your interfaces
clean and neat, and sometimes, it's worth that realising that actually the
complexities that you have to put in to hide a bit of extra complexity at
the interface isn't worth it. Understanding that balance is important.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002