As I read the book 'LIFE IN CODE:A Personal History Of Technology' by the author named Ellen Ullman, it occurs to me that she has humor (like Ellen Degeneres) and technology bandwidth just short of a Computer Science teacher/professor (Aho Ullman)! This book is not a history of Computers but more of a memoir about her interactions with the computer world and the people who become famous and rich by predicting the future of technology. The book bobs up and down between esoteric philosophical discussion and everyday programming issues. Ellen has immense facility with words. She discusses all sides of the issues very patiently and very rationally before stating her own point of view at the end of the discussion. I have been reading it by jumping into various chapters at random! It would be a useful addition to an old programmer's library who is trying to catch up with the latest happenings or moms who are in sync with today's technology!
There are chapters on cats and robots with complicated terminology that might seem scary at first (Programming The Post Human, Dining With Robots). That brought to mind a one page story I had written in 1982 named '1000 PH' (PH = Post Homosapien) about a nuclear war in the future that wipes out all humans leaving behind wise robots that are programmed 'in the image of man' !! However, my little story does not in any way compare with pages and pages of serious discussion about technology's future in Ellen Ullman's book including spiritual robots. Are all the names in the book of real people (Breazeal, Toughgarden etc)?
[It is hard for me to believe at this stage that robots might one day become independent 'creatures' living and making decisions on their own, independent of the human 'programmer'.]
[It is hard for me to believe at this stage that robots might one day become independent 'creatures' living and making decisions on their own, independent of the human 'programmer'.]
Both of us started in software around the same time it appears from the book. I would like to say that her professional experience mirrors mine except that she deals with a much bigger world of symposiums and conferences and ivy league American universities while I lived in the shadows of IT departments of a few US corporations working on COBOL projects similar to what EU mentions in her book. However, unlike her, I never had the privilege of working on a bug in a business application that has been lying unsolved for over a decade causing much anxiety among the management!!
In the chapter titled Outside Of Time she attempts to discuss the difference between higher and lower level programming languages. Yes, we as computer science students always looked down upon the 'higher' level business applications and hoped to get jobs in systems software doing 'lower-level' stuff designing internals of OS and algorithms and firmware written in assembly language ! Here lower level means jobs that required in-depth knowledge of the insides of the computer unlike the 'higher' level business applications.
Ellen fondly recalls the calamity of Y2K bug in What We Were Afraid Of As We Feared Y2K. The assumption that the applications would not last beyond 1999, implicit in the various business databases that recorded dates with only a 2 digit year was a problem that we faced at the company I was contracting at, at the time! I believe I might have been involved in some part in fixing the Y2K bug at that corporation. I was more used to writing new code than supporting existing software so that was a challenge that caused some nervousness!!And we did buy extra soup cans and a hand cranked radio in case the power went off in the middle of winter in the North East US.
When I explain to non-technical people that I recently fixed an important bug that had been sitting unsolved for a long time, the inevitable cynical question they ask is 'so how has the program been working so far ?' As Ellen explains in Close To The Mainframe ,when she encountered that decade long mysterious bug which printed $0 on a important business report she could not locate the source of the bug initially. So she wrote a workaround program to extract that missing piece of information on a separate report. After burning many neurons, the mistake was found to be in the naming of a variable inside the program inserted by a programmer a decade ago. He/She had erroneously used an underscore instead of a dash in a variable name in a very lengthy Cobol program.
I have lost much hair in solving 'bugs' like that over the years, including the missing 'period' problem where the code falls into the wrong piece of logic causing erroneous results . Therefore, I have put forward the suggestion that IT people use the 1985 Cobol standard rather than the older 1964 version. The newer version allows structured approach using scope delimiters for all statements.
Hope the book gains sympathizers for the balding and graying software people with curved spinal cords who are lost in their own internal world . At the beginning of the book EU informs us that programming is like getting on a train and never being able to get off. I say it is like living with the constant fear of being thrown out of that fast moving train if the programmer cannot come up with a convincing answer to the management's question about why we cannot merge two trains traveling in opposite directions to save money!
Hope the book gains sympathizers for the balding and graying software people with curved spinal cords who are lost in their own internal world . At the beginning of the book EU informs us that programming is like getting on a train and never being able to get off. I say it is like living with the constant fear of being thrown out of that fast moving train if the programmer cannot come up with a convincing answer to the management's question about why we cannot merge two trains traveling in opposite directions to save money!
No comments:
Post a Comment