I rarely look at C while at the office. In many ways, it’s a language of a bygone era, especially when you’re talking about web application development. Sure, we take advantage of C every day, but write in it? Never. 

However, I’ve become fairly proficient in it these past two years and have grown to appreciate the language for what it is: Blazing fast and fine-tuned for several specific use-cases. Unlike JavaScript (my language of choice while at work), C does not come with dozens of associated frameworks that come and go on a moment’s notice. It also doesn’t split its time between the hard logic of an application and managing the user interface. In many ways, C runs the world of computers around us without us even knowing.

The story behind C is the most interesting part of the language. Written in the late 60’s and launched into production around 1972/1973, C was born from necessity. In the late 60’s, Dennis Ritchie and Ken Thompson decided to write an operating system for the PDP-11, Unix (pictured above – it’s the size of a huge refrigerator and it’s processing power isn’t even close to the power of my phone).

Most of the logic of the operating system was written in Assembly at first, but this proved to be fairly clunky. Assembly’s limited support for logical constructs made this a painstaking process that grew so difficult that Ritchie decided to write his own language, specifically for handling Unix, and so C came into existence. 

The language is so basic that its primitives don’t include strings, garbage collection is left up to the programmer, and objects are nowhere to be found. However, the language’s relationship to the Unix operating system means that it is nearly ubiquitous as Unix (or some variant) is found on nearly every web server, the majority of smartphones, and the computer that I’m using (a Macbook Pro) to write this post. Wherever Unix is found, C is right behind, managing all of the commands you type into a terminal, the boot process of your computer, and, well, most anything you do. 

Like the core functionality of Unix, which has a philosophy of limited design, C has not grown much beyond it’s humble beginnings. Features have been added incrementally, but much of my own work with the language is done in C99, a standard written nearly 20 years ago. One of my favorite bits of back and forth that I have with Scott Fennell, our lead developer at LexBlog, is his love of languages that are well-defined and static. The more a language changes, the harder it is for teams and individuals to manage. Imagine if English were changing at the same breakneck pace of JavaScript; we would barely be able to communicate from day to day.

As I’ve grown less enamored of just getting a project up and running and seen the value of maintainable systems and software, I must admit that I’ve come to Mr. Fennell’s side of the argument. Give me a language that doesn’t change but does the job just as well, if not better, than any of it’s counterparts. That’s not to say that I want to spend my days writing C, but it wouldn’t be the worst thing.

I’m over halfway through Oregon State University’s post-bacc computer science program. It’s a (mildly) grueling gauntlet of 15 courses, made more grueling by the fact that I’ve been working full-time and taking two-courses a quarter (with an exception made for this past summer when only one course was on the docket to give me some time to get married ūüôā ). To-date, I’ve taken, or am currently taking, the following courses (in no particular order):

  • Introduction to Computer Science I
  • Introduction to Computer Science II
  • Discrete Structures in Computer Science
  • Data Structures¬†
  • Web Development¬†
  • Introduction to Databases
  • Computer Architecture & Assembly Language
  • Analysis of Algorithms
  • Operating Systems (currently in progress)
  • Software Engineering I (currently in progress)
Continue Reading Over Halfway Through Oregon State’s Post-Bacc Computer Science Program

Another week of reading, lectures, and confused Googling and skimming through videos is in the bag. This week was all about NP-complete. It has been fun to experience an “aha!” moment in each course I’ve taken so far, and this was an especially fun one. In large part, because seeking answers to these questions is seemingly beyond the reach of computers (in a reasonable time).

We’re accustomed to computers being incredibly fast. So accustomed that we forget just how fast they are. They’re really fast. I’m writing this on a 4-year old computer. It has a 2.5 GHz Intel Core i7 processor. That number equates to how many cycles the system clock of this computer runs in a second. So 2,500,000,000 cycles in one second. The version of the CPU  running on this machine is quite powerful. It should execute around 9 instructions per cycle for a single core in the processor and there are 4 total cores running.

This all adds up to a lot of numbers and those numbers represent commands that we expect the computer to execute for us so that we can….. I dunno….. watch videos of cute cats.

Continue Reading Understanding NP-complete.

Having just finished my midterm in Analysis of Algorithms (yes, the class is as dry as it sounds), my brain is still sharp on a few topics; one of them being dynamic programming, which I mentioned in my last post. In that post, wherein I tried to find motivation for forcing myself to relearn calculus, I used the classic example of trying to calculate the nth term of the Fibonacci sequence.

I thought it would be helpful to see this example running with some real code. Below, we have a JavaScript function –¬†fibRecursive¬†– that takes an integer as a parameter. This integer represents the term that we want from the Fibonacci sequence. For example, a call to the function like so¬†fibRecursive(6)¬†would return 8.¬†

Continue Reading A Short Story About Dynamic Programming

This is a question that is plaguing me at the moment as I force myself to relearn calculus for Analysis of Algorithms at Oregon State University. In moments like this, where the concepts are abstract and I need to learn even more abstract concepts so I can understand the first class of abstract ideas, motivation is key.

Why does this matter? I’ve been working in the industry for over five years and never needed this knowledge before, why now?

Well, the short answer is that you don’t need this body of knowledge to develop a wide range of applications and features to applications. In my world, many of the concerns that common sorting, searching, and general optimization algorithms address are not real concerns because they’ve been abstracted to parts of the language or framework. I’m able to do my job because someone else has figured out how to do other parts of my job that normally would need to be created from scratch. So while learning merge sort and analyzing its complexity is a fun exercise, I’ll not be writing it from scratch anytime soon.

Continue Reading Why Study Algorithms?

I’m about halfway through Oregon State University’s (Go Beavers!) post-bacc program for computer science, but feel like I’ve just entered the belly of the beast. On the docket for the summer is CS 271 ‚Äď Computer Architecture and Assembly Language; a fine relaxing course to take in the months before and during my wedding, right? Not so much.

The material is dense as we learn to program how to move memory around on a computer and perform basic actions on the contents of said memory.¬† The class is focused on the IA-32¬†– a 32-bit version of the x86 instruction set architecture found in early IBM workstations and personal computers, and then later in embedded systems for phones, aerospace tech, and electronic musical instruments.¬† I’m only a few weeks in, but already it’s painfully obvious to me that assembly is not like any other language I’ve used.

Continue Reading Oh The Places You’ll Go! …… with Assembly