Tuesday, May 31, 2016

Visions of the Future; part 2; You Don't Really Need a Debugger

So, I've learned enough about VBA to write a few subroutines with variables. A subroutine is what the programmers, or coders, call one little part of a program. These little subroutines were excel macros. 
I didn't know what a macro was for a long time. A long long time. I would read the word "macro" and immediately think of "macrobes", a scientific sounding term in the CS Lewis space trilogy that I don't think has a title for the whole trilogy. A "macro-title", you could call it, like "Lord of the Rings". I quite enjoyed the Lewis series, most of it, even the religious elements; because he reworked Sunday school stuff into fun science fiction elements.  Unfortunately the Sunday school stuff took over the series in the end. Much like the Microsoft part takes over and ruins all the cool stuff that Microsoft almost develops. There, I brought it all back. It was no digression after all. Macrobes, cool, "Macros" why called so?  
But eventually I learned what macros are and had lots of fun recording macros and looking at the code - You can record a macro in excel or word, and then go look at the automatically generated script in the Visual Basic editor. You can find the Visual Basic editor by employing super secret hacker methodology, going into the excel or word options menu and clicking an option in one of the menus. You'll immediately know when you go into the visual basic editor because you go from the newfangled ribbon layout of the later versions of excel to a layout looks like Windows 3.11. I think they've probably kept the old-timey look of the editor because the only people that use it are my age, and we don't like things to change. 
The editor is fun because not only can you look at the generated script, you can change it just as easily as you can rewrite an email. And you can add things to the macros or subroutines  like variables, which I learned from the Dummies book. I'm just old enough to admit that I found the dummies book helpful, and just young enough to feel embarrassed when I admit it. 
And Ive learned just enough about variables to write some macros that Ive used at work, but read just enough online to know that my coding is incredibly lazy and sloppy and jury-rigged. I constantly attempt macros based on ideas I have that are always slightly beyond my actual programming abilities, which due to extreme mental laziness I consistently overestimate. So whenever I have trouble with public variables, which I always do, I just slop the data into some corner cells somewhere in an unnamed sheet that I may later delete because I've forgotten about the slop and end up wondering what the hell happened to my previously kind of working macro until I go back and rework some lines and accomplish nothing or make everything worse until I remember the slop data and think I can just use a public variable and it doesn't work so I redo the slop sheet and put a note to myself not to delete them and delete the note later when I find copies of the same file in two folders and keep the newer one without checking the change history. And I write bad comments that I never understand later, during the long debugging/utilization process.  And I do not practice good file management/ organization techniques.  So I have grown very accustomed to the "Send Error Report?" Message box. It's one of the most reliable results in my macros. 
Having achieved this level of VBA knowledge, wherein I am constantly in "debug" mode in the Visual Basic editor, I decided to try web programming, the glamour child of the programming world; using html, css, JavaScript, all three coding languages with no debug mode at all, just a stab in the dark guessing game. I wanted to have a neat website, you see.  So where my bad programming with VBA results in error messages and yellow highlighted lines, the inept JavaScript programming results in a blank. It just doesn't do anything, and I end up looking through my handiwork in total confusion, looking for semi-colons and curly brackets, as illustrated in this week's pic:

Please note that I couldn't remember the names of any real laptop making companies nor what the back parts of a computer look like. 
After finally getting the script to do something, I have to get it to do what I actually envisioned it to do, which means inserting an endless series of "alert" boxes in an effort to pinpoint the parts where the written code has diverged from my inner vision. My inner vision can swing right by brackets and misspelled variables without a trip up, this is one of the marvelous things human brains can do. We can run a preposterously illogical program in our heads, we can compile almost anything, no matter how sloppy it's written. 
I easily picked up JavaScript from free iPhone apps, because it's comparatively easy if you know a little C.  It uses C type script, which Ive learned from a beginners guide that my wife got me, that I didn't think would be useful but thought would be fun and it turned out both. When I say easily picked up, of course, I mean just enough to write web pages that do things that are somewhat related to what I wanted them to do like the shadow of a cone is related to the taste of ice cream. Still making the hand shadows and waiting for that sweet taste of functionality

No comments: