Schoolhouse Rock and Programming

by | February 6, 2019

Schoolhouse Rock and Programming

Jeff Summers

February 6, 2019

This is Day 6 of the >100 Days of SwiftThe Swift Journey and then catching up on subsequent episodes. I am going to perhaps show my age here, but I remember as a kid getting up on Saturday mornings and while my parents slept my brother and I would watch cartoons. Besides things like Super Friends, Bugs Bunny, and Jonny Quest which were classics in their own right, the memory that sticks with me the most was the episodes of Schoolhouse Rock.

These were the precursors to music videos with education incorporated into catchy lyrics and animation. There probably isn’t a kid in this country who saw Schoolhouse Rock that could not sing at least one of the songs that taught us about things like numbers, how bills became laws, and proper sentence structure. I have to admit; these memories and jingles have helped me on more than one occasion in my life whether it was describing how our government works to trying to explain why three is a magic number.

So as my journey to learn Swift reached the part where we are learning about functions, my mind drifted back to Schoolhouse Rock. Perhaps it was just the word function that triggered my memory, or maybe it was that package of Hostess Ding Dongs I ate during the lecture that brought to mind Conjunction Junction and Schoolhouse Rock.

In that little ditty, we are transported to a train yard at Conjunction Junction where we are introduced to the concept of conjunctions and how they can be used to combine or differentiate parts of a sentence or thought.

At this point you are probably wondering how in the world does this have to do with functions in Swift programming? Well, if you think about it, functions are the connective tissue in Swift. Their goal is to make your code more reusable.

Technically you do not need functions but without them your code runs the risk of becoming inefficient and bloated. The adage is, if you use a piece of code more than three times you should make a function. The reasoning is that should you need to make a change to the code, it is easier to make it in one place rather than trying to remember everywhere you used the code and changing it in each spot.

Functions also reduce application obesity. There are times where programmers get lazy and simply cut and paste code in a couple of places (because the adage said reuse of code three times and two is less than three). Depending on how much code that is, it could easily make your application huge which has implications not just on how long it takes to download but the space we are using on a consumer’s device.

I think back to the early days of the Macintosh (again showing my age) when the machine had 64MB of RAM and a 400K disk drive. To run, your application needed to be very efficient otherwise the user experience was disastrous. As RAM prices decreased and computers had more and more hardware power we as programmers became complacent not worrying so much about resource consumption. We would all become better programmers if we went back to creating constraints (either real or imaginary) and trying to fit within those. Given today’s market where we are throwing code out into the wild at a frenzied pace that will never happen but perhaps we should each step back and try to do that once in a while to gain a better appreciation of what life was like for those developers who came before us.

Share this Article

Posted by Jeff Summers

Author, technologist, and baseball aficionado specializing in information technology and developing new and creative ways to interact with the world around us. My goal is to extend the boundaries of what is possible and find ways to make the world a better place while having fun.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Stay Connected

Search

More Articles

Pace Layered Architecture Categorization

Change is inevitable. Today’s computing environments are constantly in flux from internal and external forces that put demands on the systems and necessitate changes to maintain its value stream. Technology currency is a constant struggle that organizations must...

TBM, Another Holy Grail?

Technology Business Management or TBM as a term was coined around 2012 although many of the concepts making up this framework have been around for almost as long as there has been IT. In its simplest form, TBM represents the integration of business, technology, and...

Visionary or Dreamer?

Thinking back over your life you’ve met and worked with countless personality types. You have been a part of teams that struggled to complete simple tasks and the work felt meaningless. Perhaps your goal in these times was to just trudge through the mud hoping the...

Archives