What language do I think in? Part I
What language do I think in? Most people associate that question with their native language, or perhaps a different acquired natural language, of course. I don't have that problem; English is all I've thought in or dreamed in. My high school Spanish never blossomed to fluency, though I still hope to immerse myself in it some day, perhaps this upcoming sabbatical, so as to make the language my own. But so far my Spanish is laughable.
College German was learned much more rigorously and extensively, and I reached a much higher level of proficiency. But that was long ago also, and I don't have as much contact with that language in real life as I do with Spanish. Still, I pick up a little here and there in movies and online, enough to know I haven't totally lost it. And again, I'd love to have the opportunity to immerse myself in the language. But that doesn't appear on the horizon.
Russian? That's a hard one. And I mean that literally. I've been listening to Russian language training audios for about 6+ years. I work with many Russian colleagues, and enjoy what I can learn of their culture immensely. But the language is a struggle for me. Immersion? Probably before German, but after Spanish. :-) But the immersion would have to be much longer to be really effective. I'm game, but I doubt my wife is. :-)
But to a computer person the focus of the question at hand is seldom on natural languages, but rather on the computer language we use when we problem solve. So... what language do I think in? I want to ponder my computer language history in order to understand the answer to that question myself.
Like many from my day in the pre-PC era, I started with BASIC. I found a book in a library to help me understand what I was able to do on the old Teletype console in my high school classroom connected to a mainframe many miles away. I worked through many examples from the book, and of course many of those examples were game related. Playing the games was fun, but it seemed the bigger challenge was programming games. I started with something a little non-traditional: Monopoly. I don't remember how far I got, but I was quite pleased with what I learned and what I could do. What I didn't know at the time was that I needed a better understanding of data structures to better choose how to represent all the data involved in the game. And of course an object-orientated approach would have definitely helped... but I was never that far ahead of the game.
So off I go to college, where introductory programming was done in something called PL/C, a simplified, somewhat too-tolerant form of IBM's PL/I programming language. The reality was my introductory classes really didn't teach me so much as they did help me categorize and formalize what I'd already learned on my own about structured programming, though in a slightly different language.
I picked up a Heathkit Microarchitecture Trainer, basically a breadboard embedded computer, with inputs done through a hex pad, and outputs from a seven-segment display. This was fascinating, and again quite intuitive, but didn't offer much in the way of a stepping stone to more growth, so I set it aside after learning what I could from it. But it did help me form a foundation of understanding programming under tight constraints, be they memory, OS support, or whatever. And of course it gave me a greater appreciation for programming in higher level languages, given that I was working with machine code at this level.
An internship between my junior and senior years taught me that constrained environments were very common in industrial applications at that time. I worked on two sets of projects that summer, one dealing with a couple of mechanical engineers that were automating some processes using PLCs, programmable logic controllers. Ladder diagrams - now there was a strange language. But I could see the structure to it, and that allowed me to help those guys better document their "code". The other projects were a little higher up on the computer food chain, actually running on a "real computer" - a PDP8. Booting that was always a blast:
College German was learned much more rigorously and extensively, and I reached a much higher level of proficiency. But that was long ago also, and I don't have as much contact with that language in real life as I do with Spanish. Still, I pick up a little here and there in movies and online, enough to know I haven't totally lost it. And again, I'd love to have the opportunity to immerse myself in the language. But that doesn't appear on the horizon.
Russian? That's a hard one. And I mean that literally. I've been listening to Russian language training audios for about 6+ years. I work with many Russian colleagues, and enjoy what I can learn of their culture immensely. But the language is a struggle for me. Immersion? Probably before German, but after Spanish. :-) But the immersion would have to be much longer to be really effective. I'm game, but I doubt my wife is. :-)
But to a computer person the focus of the question at hand is seldom on natural languages, but rather on the computer language we use when we problem solve. So... what language do I think in? I want to ponder my computer language history in order to understand the answer to that question myself.
Like many from my day in the pre-PC era, I started with BASIC. I found a book in a library to help me understand what I was able to do on the old Teletype console in my high school classroom connected to a mainframe many miles away. I worked through many examples from the book, and of course many of those examples were game related. Playing the games was fun, but it seemed the bigger challenge was programming games. I started with something a little non-traditional: Monopoly. I don't remember how far I got, but I was quite pleased with what I learned and what I could do. What I didn't know at the time was that I needed a better understanding of data structures to better choose how to represent all the data involved in the game. And of course an object-orientated approach would have definitely helped... but I was never that far ahead of the game.
So off I go to college, where introductory programming was done in something called PL/C, a simplified, somewhat too-tolerant form of IBM's PL/I programming language. The reality was my introductory classes really didn't teach me so much as they did help me categorize and formalize what I'd already learned on my own about structured programming, though in a slightly different language.
I picked up a Heathkit Microarchitecture Trainer, basically a breadboard embedded computer, with inputs done through a hex pad, and outputs from a seven-segment display. This was fascinating, and again quite intuitive, but didn't offer much in the way of a stepping stone to more growth, so I set it aside after learning what I could from it. But it did help me form a foundation of understanding programming under tight constraints, be they memory, OS support, or whatever. And of course it gave me a greater appreciation for programming in higher level languages, given that I was working with machine code at this level.
An internship between my junior and senior years taught me that constrained environments were very common in industrial applications at that time. I worked on two sets of projects that summer, one dealing with a couple of mechanical engineers that were automating some processes using PLCs, programmable logic controllers. Ladder diagrams - now there was a strange language. But I could see the structure to it, and that allowed me to help those guys better document their "code". The other projects were a little higher up on the computer food chain, actually running on a "real computer" - a PDP8. Booting that was always a blast:
- Set the program counter (PC) using the front panel switch register, then
- Insert the dozen or so instructions into the boot-up memory area by hand, also using the front panel binary switch register to encode the instructions. The instructions were a basic boot loader that knew about and could load a more complex boot loader from a paper tape reader.
- Load the starting address in memory to hold the paper tape image into the address register, again manually using the front panel binary switch register.
- Make sure the more complex loader punched on the paper tape that could load the OS from the hard disk drive was in place on the paper tape reader.
- Reset the program counter (PC) to the start of the basic boot loader inserted into memory, and start the program, all again using front panel's switches.
Success was in the form of the paper tape reader starting, front panel lights showing progress in the address registers and program counters. Infinite loops due to mistakes in the manually entered boot loader were visibly obvious from the PC cycling through the same addresses over and over.
Then, my senior year of my undergraduate program, and I had the experience of a lifetime, or at least the first of many:
- Taking software engineering from Dr. Fred Brooks was definitely a "sitting at the feet of a master" learning experience;
- Our chosen project, a "PL/1 to C translation aid" was going to help the department move their well-known, massive molecular modeling program (the GRIP project) from IBM mainframes to more manageable DEC VAX minicomputers, and in the process it would help us move to a more user friendly programming environment; and finally
- We'd have yet another language to learn: the C Programming Language.
Learning a language on my own again was fun... I was driven by our project needs, and not limited by classroom speed (or lack thereof). But it wasn't just learning the language, as fun as that was. It was also learning the YACC front end parser, and the grammars for C and PL/I so as to translate what we could automatically from one to the other.
And I accidentally caught the favor of the great man himself. We needed a good symbol table manager, and one of the Masters grad students was working on one as his project. So I asked Dr. Brooks in class if we could be allowed to use this other student's code in our project. "SOFTWARE REUSE" Dr. Brooks boomed... and off we went on that tangent. Needless to say, his response was yes, and I felt I'd gotten the biggest Attaboy of my life!
That project launched my career in many ways; I definitely think it got me past the front door of Bell Labs in Murray Hill and into what used to be known as USG, the Unix Support Group. I ended up in the Unix Systems Development Lab (USDL), working for a premier C hacker (my manager, physicist Larry Rosler), and surrounded by some of the best people programming in C at that time. Rick Mascitti (who later named C++) was supporting the Fortran compiler, Dave Prosser (later editor of the ANSI C Standard) was handling much of the early Portable C Compiler (PCC) support... I just supported the Common Assembler and tried to drink up what I could.
Two more great lifetime experiences happened in this first job:
- I was able to write the common assembler port for CRISP, the "C Reduced Instruction Set Processor", which helped me see the importance of staying on the leading edge of processor changes, and
- Dave and Rick kept dragging me up to hear Bjarne Stroustrup expound on "C with Classes".
Now, for the more astute language historians, "C with Classes" will be recognized as the beginnings of what Rick later anointed with the name "C++". But here's the problem. At the time, I just didn't get it. Okay, there you have it. Sometimes I'm in the midst of greatness, and I just don't recognize the greatness surrounding me.
That's not always the case. Our first efforts inside Bell Labs to come up with a "standard" for the C Programming Language were also an eye-opener for me. It was my first experience with standards work, but it also was an atypical example. We'd all argue various points in contention, then Larry would turn and look at Dennis Ritchie, who would nod affirmatively, or shake his head negatively, and thus it was to be. My first experience with the equivalent of "Benevolent Dictator for Life"! :-) But at least this time I knew I was sitting among the giants of the language.
Okay, I'm not that far into my career with computer languages, but I've reached the point where I can say that C is my "native language". Perhaps BASIC and PLC were my "baby languages", to be forgotten when I matured and became more broadly fluent. But for sure C was the language I fell back on the most.
More to come, but that's enough for now.
posted by Randy D. Smith @ 1:46 PM
0 comments
