If you think obfuscation is the preserve of Perl, or even scripting languages, think again.

As friendly competition, or art form, sure it's cool. The first obfu I ever saw was

short main[] = {
277, 04735, -4129, 25, 0, 477, 1019, 0xbef, 0, 12800,
-113, 21119, 0x52d7, -1006, -7151, 0, 0x4bc, 020004,
14880, 10541, 2056, 04010, 4548, 3044, -6716, 0x9,
4407, 6, 5568, 1, -30460, 0, 0x9, 5570, 512, -30419,
0x7e82, 0760, 6, 0, 4, 02400, 15, 0, 4, 1280, 4, 0,
4, 0, 0, 0, 0x8, 0, 4, 0, ',', 0, 12, 0, 4, 0, '#',
0, 020, 0, 4, 0, 30, 0, 026, 0, 0x6176, 120, 25712,
'p', 072163, 'r', 29303, 29801, 'e'
};
[download]

And the power of the preprocessor has been exploited since to staggering effect.

But if you cannot see the distinction between fun and work in any field, the problem is not the tool, but the user.

But if you cannot see the distinction between fun and work in any field, the problem is not the tool, but the user.

<ot>

In fact, the problem is that as of how this society is built more or less worldwide, work is not fun. Far from being... actually the little anarchist in me (for various reasons too long to be exposed here I don't really consider myself to be an anarchist) shouts out loud that work doesn't work being it mostly a tool of coercion, out of a bunch of similar and connected ones, for a privileged set of people to keep vast masses under control, without even letting them know thanks to the anesthesia given by some common bourgeois myths like:

• work makes man noble¹;
• arbeit macht frei.

In fact I disdain (the bourgeois conception of) "work", but whenever I bring this up people tend to just thing: so you simply don't want to work. Funnily enough, in my working experiences I've always been greately appreciated and at times even considered a stakhanovite², but that's not the point: some people think that a better society can actually exist, and that it is worth to delve resources to bring the current ones towards it. As far as I'm concerned, when I'm optimist I think: well, maybe in a distant future I will never see... But what I regret, cotemn and feel like fighting with all of my forces is the conception brought forth by the hype they're selling us, and I say "selling" because we have to pay for it, and precisely that this is the best of possible worlds and that we're "free". People may happily disagree with me and as this is a matter of personal opinions I won't insist for big, and pointless, fights are to get out of a similar discussions: what saddens me is that they most often don't get it a priori of disagreeing. I expect quite a lot of downvotes already.

<ot>

---

¹In Italian it's spelt like "il lavoro nobilita l'uomo" and I don't know if it's just as widespread abroad, but I expect some simple variation of it to be.

²In the loose sense of the word, as is commonly used in Italy, don't know elsewhere.

Woe! Now there's an interesting sidetrack. If we had an OT section, I'd be happy to follow you down it for as far as we could go before hitting the inevitable deadend. And happier still to see it, thereafter, dissolve into the bit bucket.

For the sake of this discussion, let's restrict the definition of work as those activities we pursue in order to keep a roof over our heads and food in our bellies. Whether you have fun whilst doing it or not.

There is, and has to be in the majority of cases, a distinction between what we do at our own instigation, to our own criteria, and for our own pleasure. And that which we do for others, for payment, whether we enjoy it or not. The difference is consequences.

If a weekend truck racer forgets himself and start charging around our motorways and city streets at the same speeds and with the same attitudes and goals, as he employs for fun on the weekends, the consequences are likely to be as horrific as they are inevitable.

Code posted on PM, whether in a obfu or code section, or as a demonstration of syntax or algorithm in response to a SoPW, has none of the responsibilities or consequences of code written for $work. If an obfu takes parameters and fails spectacularly if those entered are out of range. Boo hoo. If a genetics algorithm fails to check its inputs, runs for 12 hours before before producing garbage, you're going to have a frustrated and angry genetisist, but mostly no great harm done.

If you fail to verify the parameters to a drug dispensor, someone could die, but writing obfus with the same care and consideration as you would take for the drug dispenser is pointless. Writing every piece of code you post as an answer to a SoPW as if it might be used in the control of a nuclear powerstation is equally pointless.

The responsibility for any code has to lie with the persons and organisations deploying that code, not those constructing it. Whether salaried or commissioned, individual programmers have a responsibility "best endevours" to those paying them, but the final responsibilities (for testing and sign-off), lie with those whom deploy that code for profit. And outside of government organisations, all commercial code is ultimately produced to create profit. If an individual programmer screws up, regardless of how badly, predictably, or with what consequences, they made a mistake. If the company or organisation deploys that screwed up code into the field, they have shirked their responsibilities for putting appropriate testing, QA, and review procedures in place to ensure safety commensurate with the application of the code.

If a fitter on the production line of your local multinational car company over-tightens a brake nipple and it subsequently fails under pressure, he made a mistake. If the failure under pressure occurs as the vehicle approches a busy intersection, because no system integrity pressure test was performed, the company is at fault, not the fitter.

If the test was performed and it still fails in the field? Once is force majeure. Once in 100,000 vehilcles is probably force majeure. Three times is probably liable.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Yes, I do know that other languages have obfuscation contests.
I would stand by what I said about what the community views as cool bleeds into the communities practices at work.

With Perl, I always get the feeling that maintainability is seen as a bolt-on afterthought that has only a very small impact on the languages design (its feature set and syntax). Don't be surprised if the average user does the same.
- Paddy.

--
    Debugging is twice as hard as writing the code in the first place. 
    Therefore, if you write the code as cleverly as possible, 
    you are, by definition, not smart enough to debug it.

    —Brian W. Kernighan, co-author of The C Programming Language and the "K" in "AWK"

I would stand by what I said about what the community views as cool bleeds into the communities practices at work.

It is (or was, I don't keep track of such things), 'cool', to wear trainers without laces, but I never saw a marathon runner, nor sprinter, nor footballer, nor even a local jogger adopt this form of cool. 'Cool' is doing the opposite of what our parents did or want us to do. Or the same as the celebrity we admire. Or doing different to that group of people we wish to distance ourselves from.

Cool is subjective, transient, divisive. Cool is undefinable beyond a small group of like minded people. Using it in a discussion to 'tar' a whole community with a single, personal perspective is emotive, irrational, oneupmanship. Ie. Seriously uncool.

With Perl, I always get the feeling that maintainability is seen as a bolt-on afterthought.

Maintainability cannot be "bolted on", just as it cannot be designed in. It has little or nothing to do with statement-level or block-level syntax or semantics.

It has everything to do with good algorithms and their clean and concise implementation; clear abstractions and clean interfaces; complexity management and the reduction of interdependencies. Good design at the application level, and formalised documentation and working practices at the project level, are always far more significant in the costs of ongoing maintainability than statement level syntactic choices of a given language, or of the language choice itself. Always.

... [Yet another smart quote from a smart person, quoted out of context to support an undefined opinion]

Quoting smart people does not make you smart.

And here we get to the crux. When you say so little and imply so much, you are most often concealing your own preferences, rather than conveying a supportable argument. The implication from all the things you are not saying, is that you consider Perl's permission of idiomatic construction to be clever and therefore unmaintainable.

That is akin to arguing that the componentisation of manufacturing, eg. large scale integration of transistors into ICs in the electronic industry, is unmaintainable when compared to say discrete component constructions from 30 years ago. And to some extent you are correct. A single failing transistor in an IC is impossible to replace, so maintainability is lessened. However, ICs are far, far more reliable than discrete circuits, so the need for maintenance is far, far less. Overall, we have a win.

A similar analogy can be drawn between 1970s, normally aspirated, mechanically-timed and ignited car engines when compared to todays fuel-injected, variably-timed, multi-valved, electronically ignited engines. In the 70's and early 80s, I (as an amateur) was perfectly happy to undertake rebuilding a car engine at home with simple tools. These days, I wouldn't know where to start. However, modern engines are far more reliable, require far less maintenance, and have much longer service periods than those old ones. Again, an overall win.

Perl's idiomatic constructs allow the concise representation of high level algorithms in a few short statements. Just as one statement of C represents many lines of assembler, so one line of perl can take the place of many, many lines of C. To argue that the use of idiomatic Perl is 'too clever' and therefore unmaintainable, is to argue that assembler is more maintainable than C.

I've seen people argue that

for my $thing ( @groupOfThings ) {
    if( $thing <= SOME_CONSTANT ) {
        $thing = $thing * SOME_CONSTANT;
    }
}
[download]

Is "more maintainable" than

$_ <= SOME_CONSTANT and $_ *= SOME_CONSTANT for @groupOfThings;
[download]

because, they argue, at some point in the future, it might be necessary to do something extra within the body of the loop, and then the maintenance programmer would have to reconstruct the loop to the second form. That would be a 'bigger change', therefore 'more' or 'harder' maintenance.

I say rubbish. If it becomes necessary to re-factor the latter concise form into the former, then the algorithm has changed significantly. And the issues of maintenance--what other effects that change of algorithm will require and what knock on effects that has on the wider code-base--are far more important that the small effort required in performing the refactoring.

One of the things that is conveyed by the concise form is: this is a single cohesive step in the algorithm. And that of itself is valuable information to the maintenance programmer. Spreading that single, cohesive step over several lines in order to accommodate future changes that may never happen, discards that information and potentially raises doubts in the maintenance programmers mind.

My favorite cookbook often starts the SAUCE section of recipes with:

• Make a basic rue using 50 grams of butter.

  If you do not know what a rue is, or how to make one, you're stuffed right there. Except, if you look up the index of the book, it shows you how to make a basic rue, along with 20 variations. There is no need to reiterate this information in every recipe that uses it, because you can go look it up. After a few times, you don't need to, so now all the extra space that would be taken up by expanding that information in place everywhere it is used, would be redundant.

  This is an exact analogy of perlish idioms. The first few times you encounter them, you have to look them up. And then, you don't have to any more.

  ---

  Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

  "Science is about questioning the status quo. Questioning authority".

  In the absence of evidence, opinion is indistinguishable from prejudice.

  "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."