On Coding XIII: Retrospective.

I published the first installment of On Coding on September 11, 2016.  It seems a bit surreal that this thread is over a year old — but all good things must come to an end.  I really enjoyed writing these posts; they helped me organize my thoughts about my own personal coding history.

But there are some loose ends I’d like to tie up.  I’ve had brief forays into other languages — too brief to devote an entire post to any one of them.  I’ve mentioned a few of them here and there, but I’d like to take the opportunity to include them all in one post.

Before doing so, I should mention that Processing is my most recent programming adventure.  But I have written so much about using Processing in the context of my digital art course, I don’t feel the need to devote a separate post to it.  And I feel I might bore you, dear reader….

The first is PASCAL, which I first learned while taking an undergraduate programming class.  Other than the course, I only did a few other things with PASCAL.  I did write a routine that printed out 4 x 4 magic squares — I was really into magic squares back in college.  I also dabbled with computer graphics and geometrical inversion — I recall giving a talk where I discussed geometrical inversion, and I split the screen so on one side you saw lines tangent to a conic section, while on the other side, you saw inverse circles tangent to the inverse limaçon.

While in graduate school, I had a one-year stint filling in for a faculty member at a nearby college, and I taught a data structures course using PASCAL.  Now, I would never think of PASCAL as a go-to language for any particular purpose.  It’s still around, but not nearly as popular as it was then.

The next is LISP*, which I used while teaching at a summer program during graduate school.  This was a parallel version of LISP written for the Connection Machine, a state-of-the-art supercomputer in its day.  It had literally thousands of different processors, each very simple.  But because of the sheer number of processors, the speed of the Connection Machine merited it the designation “supercomputer.”

The language was quite similar to LISP, except that many functions had parallel versions which could be executed on each processor.  I can’t recall much of what I did on the Connection Machine, but I do remember programming Conway’s Game of Life on a 1000 x 1000 torus.  Of course I can do that on my laptop right now in Mathematica, but at the time, it was a real feat!  Remember, that was back in the day when Mandelbrot sets were calculated pixel by pixel and computers were so slow you could actually see the pixels march right on by….

Chronologically, Maple — a direct competitor of Mathematica — comes next, sort of…I used Maple around the same time as LISP*.  I seem to recall the only reason I played around with it was that I had a house-sitting job for a few summers, and there was a computer I could use which had Maple on it.

I recall finding Maple really useful, but there was a bit more syntax than with Mathematica.  I really like Mathematica‘s fundamental data type — the list, just like LISP.  But I think part of the reason I’ve stuck with Mathematica through the years is that most places I’ve been have supported it — and being free is a big advantage.  I know Maple has changed a lot since I last used it, so I don’t feel I’m able to say more about a comparison with Mathematica than what I’ve already said.

Jump ahead a few years to C++.  I can’t remember exactly when I started learning it, but I was teaching at a small liberal arts college, and a colleague who usually taught an algorithms course was going on sabbatical.  I was really the only other faculty member at the university qualified to teach it, and so there it was!  The students in the course knew C++, so I needed to learn it, too….

Well, I should say I learned enough to write code for an introductory algorithms course, which means I didn’t have to dive too deeply in.  I can’t say I used C++ for much after I taught the course, except I remember writing some routines to do financial planning.  You know, like if you have different investments at different interest rates for different numbers of years, etc., how much will you have when you retire?  (Being a mathematician, I thought it insane that I should pay someone else to do my financial planning, so I read everything I could on the topic and did it myself.)  But I haven’t used C++ since.

Last — and perhaps least — there’s Java.  I learned Java was when I was applying for a job teaching mathematics and computer science, and the language taught was Java.  I had never written a line in Java before, and there was some concern that I wasn’t qualified.

So I wrote a little interactive game based on some puzzles I created, which was really quite nice, if I must say.  The only way to show you know how to code in a language is to code, so I did it.

It was rather unpleasant, though.  What I needed to do was really just algorithmic, and the object-orientedness of Java and the need to precisely define data structures really got in the way.  I hope never to write another line of Java again.  (Incidentally — long story — I was offered the job but turned it down.  Saved me from teaching Java….)

And I think that’s about it!  If I can leave you with anything after this series, it’s GO CODE!  Learn as many different types of languages as you can.  The best way to learn is to find something you really want to do, and then go for it.

Remember, my first programming language was Fortran — using punch cards.  Running batch jobs.  Today, you’ve got laptops and the internet.  The only limit is your imagination….

 

 

On Coding I

If you’ve been following along for a while, you’re well aware of my passion for coding.  I firmly believe that all students should learn basic programming in at least one language, if not more.  My hope is that by seeing how the computer may be used to create digital art, some readers will embark on a lifelong coding journey.

To help put this in perspective, I thought I’d share my personal coding journey.  I’d never thought about my programming experience in chronological order before, and realized that talking about my journey could help others on theirs.

My particular journey began during my senior year of high school.  Here was state-of-the-art technology at the time:

352px-TI-30_LED.png
Photo by D. Meyer, Wikipedia Commons.

This was new technology.  Complete with LED display.  I still remember a game I’d play.  It’s maybe not as amusing now as it was then…but take your TI-30, and multiply the numbers 96, 169, 13, and 337.  Then add 1.  Turn your calculator upside-down — and it spells “Shell Oil”!  This is the only one I can remember, but I’m sure I must’ve made up a few more.  (OK, I didn’t remember all the numbers, but I did remember the 96 and 169, and easily figured out the other two.)

You might be wondering — if the hand-held calculator didn’t come out until my senior year, what did we do before that?  Well, we learned trigonometry using tables of numbers.  If we needed a value which wasn’t in the tables, we figured it out using linear interpolation.  Same with logarithms, and any other numerical calculation.  Tables, pencil, paper.  Try to imagine it!

There wasn’t anything in the way of personal computers then, either.  That’s why I think novice programmers today have it so easy!  Download Python, and ask the internet how to do stuff.  No problem.

When I was a senior in high school, some of us took a bus to a local university to learn Fortran.  (Though not the most common computer language today, it is widely used in disciplines such as physics because of its speed in doing numerical calculations.)  There were no computers in high schools.

And get this.  We used punch cards.  Which looked like this:

Blue-punch-card-front-horiz.png
Photo by Gwern, Wikipedia Commons.

You needed one card for each line of code you wrote, which you created on a sort of typewriter.  Then you put your cards in a stack, and took them over to the card reader.  Your cards were read, your program was executed, and after a few moments, you got a printout of what you told the computer to do.

Now this line of code took about 10-15 seconds to type in Sage, and printed out the numbers from 1 to 10 on my screen:

for i in range(10):  print i+1

No getting on a bus, punching cards, etc.  It’s truly amazing how far technology has progressed since those years, and also very wonderful that learning basic programming is so easy now.

I remember really enjoying the way you had to think in order to write computer programs. So when I went to college, I took a programming course in PASCAL my very first semester. Carnegie Mellon was on the forefront of what is now called “computer science,” but at the time, it was not a well-established discipline.  In fact, when I was an undergraduate, you couldn’t be a computer science major — you had to be an applied math major in the computer science track!  Of course that’s all changed now.

Naturally I enjoyed this course, too.  Like Fortran, PASCAL is a procedural programming language — in other words, you’re essentially writing procedures and routines that execute statements in a particular order.  It was probably the most popular procedural language before C came along.  There are other types of computer languages as well, and we’ll get to them when they appear in the chronology.

I took two other computer courses which also used PASCAL, and liked them, too.  These courses were more intense and involved using a lot of data structures, such as arrays, linked lists, binary trees, etc.  But again, in the days before PCs.

So to do your assignment, you had to go to a computer lab.  Then sit down in front of one of these.

Heathkit_computer_H88.jpg
Photo by Arthur G Korwin Piotrwoski, in the Wikipedia Commons.

And no — there was no mouse, no touch-screen, no windows — just a keyboard you used to type lines of text on a TV-like screen.  And no — it’s not even a computer!  It’s a terminal.  What that means is that there was just one large computer, called the main frame, with many terminals linked to it.  When you wanted to run your program, you had to get in the queue — the main frame could only compile one program at a time.  Then the output would be printed to your screen.

I still remember my first (and last!) all-nighter finishing a programming assignment.  I put it off, and waited until the night before.  And so did a lot of other people.

What that meant was the queue was long.  So you had to wait — maybe 15 minutes or so — for your turn.  This was for just executing your program once.

If you made a spelling mistake — say typed “BEING” instead of “BEGIN,” which I do now and then when I’m typing fast — you waited 15 more minutes to try again.  A short program which might only 20 minutes to complete when the main frame wasn’t so busy took several hours….  I will say I never did that again!  I learned my lesson.

So know you see why I think it’s so easy to learn programming today!  And why all students should….

There’s lots more to the story, and I’ll come back to it now and again.  It’s been fun thinking about those days of emerging technology!