Computer Programming and Translation

This one’s for you, Schultzie. Not long ago I was telling a friend about my experience of learning to write simple computer programs in FORTRAN 77, at the age of 13 or 14. This was at the University of New Orleans, where I must have been enrolled in some sort of summer program for kids, can’t remember the details. After we had written our programs, they were entered into a machine that produced punchcards that the computer could somehow decipher. I remember liking the teacher, but my memory of him has blurred: dark beard, plaid shirt. But that isn’t the part I wanted to write about. The important part of this memory is that this almost-forgotten teacher instructed us not to begin writing our programs until we had worked out, using flow charts, every detail of every operation we wanted our programs to perform. We had to draw conceptual maps of our intentions, only afterwards deciding what combination of commands in FORTRAN 77 would best embody them. Often there would be more than one way to express a certain part of the map, though usually one way would turn out to be better (more direct, more “elegant”) than the other. I think this early experience of thinking about language had a distinct impact on my development as a translator. I do believe that a crucial step in translating well—in fact, the step that is hardest to teach—involves being able to conceive of an intention (what you want to say, and how you want to say it) in an abstract way that does not depend on actual words. First you decide – by reading the original – what it is that needs to get said, and then you go looking for the words that will achieve this saying, and if the words you find are not as direct and elegant as you want them to be, you look for others. This differs in a sense from original composition: when you are writing your own text, the words and the thing they are expressing tend to arrive already melded. But even when I am writing my own work, I do sometimes have a sense that the thing that needs saying next is rising up from the depths below the surface of the text, and sometimes there is a lag before the words for it arrive.

Share this!

Comments

  1. waggish says:

    Nina and I love this. Sad to say, neither of us has ever used Fortran: we started with Logo and then moved to Basic and Pascal. And yes, planning that way is wise in comp sci, something that’s sometimes lost on people now that it’s so cheap to compile, run, and test code, which makes for sloppier work. The best programmers I’ve met, in general, have been able to work everything out before so much as typing in any raw code.

    That said, translation is so much more difficult because there’s no ambiguity or nuance or context in code! Those tricky Geisteswissenschaften.

  2. Lauren B. says:

    Weird — just today I was telling my family about this class! My memory was that it was at Tulane. The guy with the brunette beard was a teacher’s assistant. The class was for adults (I remember a math, or was it physics? professor as one of the students, and also a bass player from the N.O. Symphony.) The teacher gave a test one day, and you got the highest grade! (I probably got the reverse-highest grade.)

  3. schultzie says:

    Funny, these day the latest idea is that you shouldn’t overdo the upfront analysis because the act of coding can change the desired outcome – ie the idea is to create the minimal thing that works and then show it to the customer, their feedback may then be that having seen it their requirements have changed because they now see other possibilities. Now how does that relate to your translating practice? They call this Xtreme Programming 😉

    #waggish: no ambiguity or nuance or context in code#
    Maybe not in code but definitely in requirements – the what it *should* be doing!

© Susan Bernofsky 2010-2018. All rights reserved. "Translationista" is a registered trademark.