Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Antiquitates - liber I - In memoriam Robert M. Pirsig

by Discipulus (Monsignor)
on Nov 15, 2017 at 09:16 UTC ( #1203451=perlmeditation: print w/replies, xml ) Need Help??

Antiquitates - liber I - In memoriam Robert M. Pirsig

Introduction

This mediation is meant as the first of a short serie about antiquitates: good ancient things, knowledge. The central point of this is to focus on figures and ideas, or better pictures and schemas, that we have in our heads. This Pantheon is something we never speak about but is central in our approach to problems.

Infact while in our past (i'm speaking of the western colture) this pantheon were very homogeneous (geographically speaking but also between distinct social classes) in the current, global and postmodern world is something very variegated and fragmented and almost each one has a pantheon on his own.

Another point of this serie will be the importance of ancient wisdom. I totally disagree with the concept of human progress. I'm not speaking, obviously, of material conditions, but I believe the deepness reacheable by human thoughts has not improved over centuries. Only elements we play with have changed. Our fathers already discussed many still actual questions, useful also for us as programmers. I start here with an example in the near past, just to be kind with you, but other meditations will go far backward in time.

In an era while the organisation of production is even more constrained into fixed binaries, where new methodologies are put in the field to force us to act in a precomputed manner, where technologies too reorganize themselves to be impersonal, becomes even more important to focus on which immaterial bricks are worth to be collected to build the unique construction of our creativity as programmers.

Pirsig's Chautauquas

Pirsig's recent death pushed me to ponder again about the importance of his discourse for my life and for my Perl programming activity. Pirsig is the author of the book Zen and the Art of Motorcycle Maintenance that I read many lives ago but which never disappeared from the background of my mind. Two central concepts still remain from his book as two rocks after thousand years of erosion.

Quality

The first one is quality. Quality, if memory deserves, was what caused the protagonist's brain short circuit as filosophy professor. The research of quality and implicitly his definition, is something central in our lives. Ok but what this can be related to Perl and to programing? Is not maintainability just an aspect of quality? Readability over a clever jumble of hacks is not just another face of this concept? And why we prefer, well we love, Perl if not for a matter of overall quality? Quality of the programmer's activity while coding, not constrained by the interpreter's laws to double sign with blood the laguage way to code. Quality of the produced code in all it's phases: imagination, drawing, realizing, improving, testing and maintaining.

Quality is everyday something less. As the programmer hired after he told the interviewer he was able to cut ten lines of code each day. Quality is polishing the diamond.

But quality cannot be teach. We, well you, can show some incarnation of it. You can cast some light from your own quality and draw a beautiful picture on the white wall of ignorance. You cannot show directly the source of these rays, just the projection. Why? because quality is not a place but a path, a neverending one. Is a driving tension.

Underlying form

The second concept is underlying form. This is crucial concept for the programmer. We solve problems. Solutions must be aware of underlying forms. Problems are occurences of the reality in the platonic world of ideas and forms and even if such abstract world does not exists, it heavily concurs in our understanding and approaching of problems.

Without the perception of something in the background our solution can just be a mere workaround or a color patch. A valid solution to a given, complex problem, can born only from the understanding of underlying forms.

Here the discourse becomes even more actual. We are living in the end of the firts Internet generation. Most of us have born in a totally analogic world and will die, as late as possible, in a totally different world. What about the next generation? Who knows? An anecdote, inspired by real life, can show different aproaches to the same problem.

Generational anecdote

Tizio and Caio are both of the first internet generation. They share the usage of computer at home. Tizio, for fun, put an entry in the file HOSTS for the Caio's preffered website pointing to 127.0.0.1

Some hours after Caio points his browser to the preferred website and he notices a connection error. He then issues a ping to the website name and sees it strangely resolves to localhost. He wonders a bit if the provider has blocked the website so he issues an nslookup to the website domain name and he is happy to see that nslookup returns a valid public IP address. He points the browser to this address and he sees his preferred website again. So he realizes the problem must be at level of local name resolution. He opens the HOSTS file and comment the incriminated entry, adding some bad words addressed to Tizio.

Tizio make the same funny pun in a computer shared with Sempronio, a millennial second internet generation. Sempronio notices the error then tries some other websites and they are ok. Sempronio starts thinking that something is broken within the browser and he installs another browser but, with his big disappoint, the problem persists.
So he opens the Bag Of All Answers website and searches for "preferred_website blocked" and he discovers a plethora of causes that can make a website to be blocked. He reads superficially a bunch of articles without invastigating why governments block websites. After three minutes he modifies the search: "preferred_website blocked solution" and he happily discovers that some software can circumvent the problem.
So he installs a program named after the sligthly modified name of an ancient god, let say Marz. Sempronio does not know but this geeky program uses it's own nameservers and redistributes web requests over it's own network in a peer2peer way, Sempronio just complains it's a bit slow but finally the preferred website shows correctly again in the browser.
So for him it is a happy end (not saying that an international agency intercepts all Marz's traffic and programtically breaks all computers using it, but this is whole another story..).

With the above i dont mean all young people are stupid and all older ones are wise and spot everytime the rigth solution. I dont mean this at all. Just I want to highlight that if you know the underlying form of a web request probably you'll arrive to correct conclusions if experiencing some weird browsing behaviour.

Conclusions

Quoting from Pirsig's book: Although motorcycle riding is romantic, motorcycle maintenance is purely classic. Author's work is full of examples of what he called classical and romantic types. I think such dichotomy is even too much stressed. I'm more in favor of the Humanistic Being, even as programmer. I dont want to be just another thooth in the gear not even knowing if I'm part of a clock or of a motorcycle. Knowing the big picture and to perceive underlying forms can make us better programmers.
An old book by a philosofy professor is worth to read, probably even better to have in the books shelf than an aseptic manual of programing methodology.

Roma 2770 AB URBE CONDITA / 8644 September 1993

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
  • Comment on Antiquitates - liber I - In memoriam Robert M. Pirsig

Replies are listed 'Best First'.
Re: Antiquitates - liber I - In memoriam Robert M. Pirsig
by hippo (Abbot) on Nov 15, 2017 at 09:50 UTC

    That is an excellent meditation and I look forward to the rest of the series.

    We are living in the end of the [first] Internet generation.

    From my point of view, as an aging programmer, I see us more at the end of the second Internet generation. The first generation died in the Eternal September (but perhaps in a true Perl fashion you see that as the zeroth generation). There was an absolutely massive change at that time as it brought precisely those who know not how it works (and have no desire to know) onto the network. For those of us who lived online through it the upheaval was dramatic. There is a worry that this trend, continuing through today and partly at the instigation of those huge corporate entities who drive the net onwards, is leading to a bad place: technologically, societally and philosophically. But I'm an optimist and tend to rail against such doomsaying. We are the real guardians of the net and we will keep reinventing, improving and rejuvenating it for the benefit of all.

      Thanks hippo,

      I'm so young that I never been told about Eternal September.

      This also remember me that I missed the timestamp in my meditation (i'll update it):

      perl -MDateTime -e "printf '%d AB URBE CONDITA / %d September 1993',(l +ocaltime(time))[5]+1900+753 ,DateTime->new(year=>1993,month=>9)->epoc +h/(3600*24)"

      L*

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Re: Antiquitates - liber I - In memoriam Robert M. Pirsig
by syphilis (Chancellor) on Nov 15, 2017 at 12:34 UTC
    Pirsig is the author of the book "Zen and the Art of Motorcycle Maintenance" ...

    Back in my university days (at about the time this book first became widely read), I knew a Zen Buddhist who was addicted to Codeine cough medicine.
    It was felt that he should one day write a book called "Zen and the Art of Habit Maintenance" ... but, alas, that never happened (AFAIK).

    Cheers,
    Rob
Re: Antiquitates - liber I - In memoriam Robert M. Pirsig
by sundialsvc4 (Abbot) on Nov 24, 2017 at 00:27 UTC

    If you want to get right down to the reality of it ... “motorcycle maintenance” is actually quite likely to be the difference between a live motorcycle-rider, and a dead one.

    Just sayin’ ...

    As I drive along the Interstates, here in the USA, I encounter white crosses and plastic wreaths in some of the most damned-fool places, and I will venture to guess that too-many of them are “motorcycle riders.”

      Imagine; my father had another theory: every human being has a limited number of boshes/paps to say in their lives; reached that number they die.

      Just sayin’ ...

      You have been able to go out of place even in a discursive only meditation where no Perl code were involved. Congratulation! It's a new record!

      I really want to get right down to the reality: what your idiotic comment is for? It's a mere provocation? It's a voodoo? Let me link some apotropaic magic just in case..

      This is your "going down to the reality"? Perl is my iron cast pan.. "One of my friends burned his hand tremendously".. This is your concept of quality in answers?

      Can I ask you the favor, yes really a favor, to not comment more my nodes? Have you not understood that prevent newcomers for loosing their time with your many times demonstrated nonsense, it's a big effort for this poor community?

      I try always to be polite and kind with everyone and I just, rarely, downvote bad content, never users as users, but I start thinking your contributions are just provocations to produce flame threads. Is this your contribution to perlmonks?

      Oh gods, may be this the last time I need to answer this way..



      L*

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
        You have been able to go out of place even in a discursive only meditation where no Perl code were involved

        Seems to me that the post to which you're responding is little more inane than my own contribution to this thread.
        Yet my post (rightly) passed without comment - and even attracted some upvotes !!

        As regards reactions to sundial's posts, I'm continually drawn to a section of BrowserUk's sig that says:
        <quote> examine what is said, not who speaks </quote>

        Cheers,
        Rob
Re: Antiquitates - liber I - In memoriam Robert M. Pirsig
by sundialsvc4 (Abbot) on Nov 16, 2017 at 20:12 UTC

    (Obviously, I do not intend to do anything of the sort ...)

    However, as much as I appreciate the oh-so many books who “decry the lack of ‘software quality,’” and then promise to teach the erstwhile book-buyer (or seminar-buyer, or certification-buyer, or what have you ...) “how to do it right,” I think that no one who is part of the profession of creating computer software ever undertakes to produce a work-product that is anything less than what (s)he can be proud of.   If software continues to be perceived to be unstable, or “of inferior quality,” perhaps it is because we are under-estimating the actual engineering challenges that these engineers daily face.   In fact, perhaps we are simply mis-stating the fundamental nature of the challenge itself.

    One of the best books I ever read on this topic was an e-book – I never saw it in print – called, Managing the Mechanism.   The author observed that “computer software is a self-directing(!) machine.”   But even this point-of-view is actually simplistic, because any engineer that works on such a “machine” – in the real-worlds that I deal with – always has an incomplete picture of its actual set of moving-parts and of the other parts which might be potentially affected by any change at all.   When you inject things like timing ... SOAP calls, JavaScript XHRs, race conditions ... you can just about throw your hands up into the air.

    Real people are not producing unreliable software because they want to or intend to, and they very-often find that they cannot “refactor it” make it right because they cannot vouch that the replacement code would in fact perform perfectly in place of what it is meant to replace.

    Simply put – “the solution” is really no different than what it replaces.   It was just developed several-years later, under essentially the same (incomplete) “intellectual conditions.”   The moment you decide to put it into service, you take a tremendous business risk.

    And that, really, becomes “the true decision factor.”   Not an abstract thing like “software kwal-i-tee,” but (lots-of-dollars and lots-of-cents) “business risk.”   How strange that I never, ever, hear this term being used in programming textbooks or “manifestos.™” ...

    I must say, in retrospect, that it has been very ... interesting ... to find myself having focused, for now so very-much of my still-unfolding career ... on still-business-critical code that was once maintained by teams who have been ... (well ...) ... fired.   (Or, quit just before the axe fell.)   Whodathunkit that a person could actually make a career from this?!   :-/

      "(Obviously, I do not intend to do anything of the sort ...)"

      Obviously? It looms as though you replied to the wrong post, again.

Re: Antiquitates - liber I - In memoriam Robert M. Pirsig
by sundialsvc4 (Abbot) on Nov 15, 2017 at 15:33 UTC

    A very entertaining bit of creative writing, this ... but actually books like Zen are mostly good only as entertaining diversion – not an actual testament to “software quality” and/or the actual process of developing, and then maintaining, the stuff.

    (For instance, the candidate who smugly talked about his ability to “remove ten lines of code a day” would never have been hired by me, for exactly this reason.   But, I digress.)

    Computer software can easily have a lifetime in-service of twenty years or more.   (I more-or-less find myself specializing in rehab projects involving production(!) systems of comparable age.)   The businesses that owned the software never stopped doing business, and their business changed its course throughout.   The software had to adapt – but computer software is not very adaptable.   It isn’t “adaptable,” that is to say, unless you design both the software and your entire work-process to make it be more so.   And, quite frankly, a lot of programmers are never taught that in school, and never learn that subsequently on-the-job as they fritter from one pool of momentary excitement to the next, changing jobs every time they become bored.   (Which is often.)

    Programmers spend far more time changing so-called “legacy code” than actually writing anything that is new.   They make their changes based on inevitably-incomplete knowledge of the enormous system that surrounds those changes, no matter how many years they’ve been working on it, and of course no one has knowledge of the future.   In spite of the many pundits who have made a lot of money from “Six-Sigma,” “ISO-nine-something,” or even “Scrum” and “Agile,” maintaining software quality and general maintainability over the course of ever-changing teams and the inexorable march of time is a human process that (IMHO) never actually has access to the level of complete knowledge that these processes call for.   In spite of terms such as “refactoring,” this actually (in my experience) occurs very, very rarely.   The process is intrinsically meticulous, imperfect, and error-prone.   And it has somehow been that way, continuously, for several decades now.   Yet this is actually normal.

      [M]aintaining software quality and general maintainability over the course of ever-changing teams and the inexorable march of time is a human process that (IMHO) never actually has access to the level of complete knowledge that [Agile calls] for.

      That's not what agile calls for.

      > not an actual testament to “software quality” and/or the actual process of developing, and then maintaining, the stuff.

      From a guy who can't write code, talk about it correctly, or delivery anything of quality. Troll on
Re: Antiquitates - liber I - In memoriam Robert M. Pirsig
by sundialsvc4 (Abbot) on Nov 16, 2017 at 20:44 UTC

    And to this entire discussion, I just want to add one more thing:

    Every time that I came upon “smoking ruins” after some part (or the entire) team had either quit or been escorted out of the building, I have never advocated that this fate should have happened to them.   But I sometimes do believe that the teams actually brought-on their own eventual perdition by embracing some “manifesto.”

    I have a pet-name for the Legacy Application:   I call it, “The Beast.™”   The Beast is simultaneously both “the fire-breathing thing that everyone identifies as the source of their deepest problems,” and “the benevolent and essential thing that feeds them all.”   Beleaguered teams often cave-in to outside political pressure to adopt some “manifesto methodology” or another, not realizing that in so doing they have just irrevocably condemned themselves in the eyes of upper management.   Having thereafter dutifully spent an unpardonable amount of dollars on “seminars,” “certifications,” and “professional boot-camps” – at the urgings of these very teams(!) – the bean-pushers finally drop the bomb.

    Unfortunately, the once hard-working teams, by endorsing “a methodology,” endorsed those pundits’ version of “what they had been doing all along,” and their subsequent failure to make-good on the glowing (but, hopeless) promises spelled the end to yet another chapter of their tumultuous career.   They were done-in by their own condemnation of ... themselves!

    Meanwhile, “The Beast™ puffs on.”   It has, after all, seen so many teams now come ... and go.

        Hi chromatic,

        > I think you misunderstand agile development at a fundamental level and I think you don't understand Perl.

        You haven't been much around lately so you seem to be surprised about this "phenomenon".

        Please see Re^4: Do not understand *sundial* for some overview and further links.

        HTH! :)

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Je suis Charlie!

      > And to this entire discussion, I just want to add one more thing:
      Hold on there Columbo, you're full of it. You don't have discussions, you just rant, meaningless, long winded garbage. 100% nonsense. You don't know anything about anything. Go start a livejournal for your brain farts, don't spew them here.

        LanX, your Trumpian obsession with this certain monk is a stain upon this monastery in general, and in particular upon this excellent meditation by brother Discipulus, which you've completely hijacked.

        Your trick to consider preemptively your own post to prevent other monks from trying to clean up your mess violates the spirit of the Monastery rules, if not some specific letter.

        Most pathetically, you appear to be as bitter, obssessed and off-topic as the monk you depise so much and to whom you insist on drawing attention.

        Sad!


        The way forward always starts with a minimal test.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1203451]
Front-paged by Arunbear
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (2)
As of 2017-12-17 01:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (459 votes). Check out past polls.

    Notices?