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

I agree with you that thinking about the consequences of one's deeds is crucial. But...

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.

...I see a similar mixup of concepts here as there is in Perl, when it comes to packages, name spaces, symbol tables and classes :) Work can be done - and very responsible and important work - in one's so-called "free time". So, real work does stem from a necessity, but not necessarily the necessity to fill one's belly, i.e. to satisfy basic needs. It might be the other way round: doing necessary things grants the revenue needed to pay the monthly rent.

Today, there's a tight coupling of subsistence and income, of income and work, of work and making money, of making money and business success - and these are acquiesced almost as laws of physics. But then there are lots of businesses whose primary goal is not making money, but satisfying some crucial need of society - think Red Cross. Although moving money and book keeping is necessary for those businesses, they do big work for others not for payment, but because it's necessary to get that work done.

"What we do at our own instigation, to our own criteria, and for our own pleasure" has impact on the society as a whole, and we are responsible for those deeds also, not only for what we craft under another flag than our own.

My work consists in not small amount of research, learning and trying out things, all of which don't give my enterprise immediate revenue; but although this doing benefits my knowledge alone at first sight, it is necessary in the company's context also - even hanging around at PerlMonks. I tend to blur the lines of "business work" and "private work", because I don't care what hat I'm wearing whilst doing what is fun for me to do. Of course my work also comprises tasks that I don't like - but that's no different between tasks at home or at the office.

I'm not sure about the ostensible relations of the aformentioned coupling wrt to cause and effect - I do what I can and accept getting paid for it... I'm more comfortable thinking that I get paid because I work and am having fun with it, rather than that I work because I have to get paid. Freedom often is to be free from wrong perceptions. Still waay to go... ;-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

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

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.

I'm not really sure: while certainly modern engines and other mechanical stuff have several undoubtful advantages over old ones, I think that these tend to vanish when you take maintenance and duration into account.

It's not about the engine... but a pair of years ago while driving my dad's relatively new Ford Focus I happened to have one of my passengers open the glass beside his seat: as soon as he touched the button, the glass fell down like a guillotine. It made such a noise that I reacted angrily, thinking that he had opened the door and hit something: in fact it was winter and very cold, I had just raised the heating to the maximum for a few seconds because the front glass was becoming completely foggy. Well, apart the disappointment for the fragility of the mechanism, I thought in that situation that it would have been fine if there were an emergency one in the form say of a leverage system behind a removable panel in the door just to temporarily cope with such an inconvenience.

Other (counter-)example, not having to do with cars but with refrigerators: here, in our "country house" (it's not, really, but I couldn't come up with a better expression) we have one that has undergone the moving through two houses and is some 35 years old! I bet it's not terribly enviromentally safe, nor efficient nor nothing. But it does work! A newer one we got only few years ago broke down the last month, and to repair it would have costed more than buying a new one.

I think that what's expressed by the former two languages applies to most material devices: they're seem not to be made with duration in mind. Whether this is a circumstance, and a side effect of some other win they may have, or a precise design strategy is debatable. I don't think this could be translated to programming languages, though.

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.

Well, yes: it's called YAGNI in brief, but you surely knew.

If 'cool' is too subjective, transient, and divisive; then feel free to substitute 'fun' in my original sentence, but you might loose that sense of novices looking on at what the masters do and wanting to emulate them.

Maintainance is enhanced by composability and the reduction of special cases - things that can be affected by language syntax.

I'm glad you brought up the IC design example, it enhances my argument. There are many ways to design your own transistor, AND gate, or flip-flop, but the digital designer is NOT given the choice. there are very few types of basic gates at his disposal and through the base uniformity, tested methods of (de/)composition, testing, and training in manufacturability, the designer is freed to make such advances.
On the quote by Brian W. Kernighan, It is about debugging which can be a part of maintenance and writing clever code. I mentioned some very clever coding practices above it. I still think its a fair quote. I am aware of the pitfalls of a poorly used quote back-firing but would rather modify what you said to "Mis-quoting smart people does not make one smart", which causes me to quote rarely :-)

I do not argue that assembler is more maintainable than C, and know that you never said that, it was part of one of your examples. I could however take the first sentence of your paragraph introducing the example to highlight some of our differences of opinion:

Perl's many idiomatic constructs allow the concise representation of a high level algorithm in an unnecessary number of sets of a few short statements.
Furthermore, this is seen as a good thing in the community. I think this goes against maintenance, as does "Do What I Mean" rather than "Do What I Say".


Here are two concrete Perl features that make it harder to maintain Perl programs, not un-maintainable, but definitely harder to maintain:

 * The explicit use of references.
 * The method of passing of arguments into subroutines.

You can't mandate against their use in a style-guide and they can be used so deceptively that they get through code reviews.

- Paddy.