Frank Merchlewitz is a writer, musician and multimedia dude from Des Moines, Iowa. Frank works part time as an assistant producer and intern at Strategic America in West Des Moines and as the technical director for the Welch Avenue Show. You can see his alt-jazz band Watercolors performing monthly at the Lift and Star Bar (or in this video he made).

He still doesn’t know what he wants to be when he grows up, so he tries to soak up as much as he can. Inspired by the folks he met during his summer internship with Silicon Prairie News, he’s teaching himself to code—sharing some of his posts along the way via SPN. It’s hard, but at least the kid’s trying. 

This post originally appeared on Frank’s personal blog, “Idiot Learns to Code,” and has been republished here with his permission.

[DISCLAIMER: I am an idiot. The following is a personal exercise that I’m sharing about my attempt to understand the dense field of computer science. I’m making progress. Kind of. I do not vouch for the accuracy of anything that I write on this subject. If this were a blog about sandwiches, this disclaimer would not exist, for I have a profound understanding of the art of the sandwich. I’m a sandwich artist, if you will. Read on if you want to share my epic(?) journey.]

Thanks to our sponsor

Become an SPN sponsor »
Meet our sponsors »

Long time, no blog! Coding is a lot like exercise, in that I’ve done neither for about two weeks.

And I suppose it’s difficult to gain progress in both coding and fitness without consistent effort—even just 15 minutes a day. So that’s what I’ve been doing during the week, slowly but surely (with programming, not exercising). I’m done with my HTML/CSS refresher and set to delve deeper into Python.

Even though I’ve been busy making videos for the past couple of weeks, I’ve kept up with my computer science research, taking notes on some terms that kept popping up that were out of my depth. For now, I’ll ignore the easy stuff that Codecademy covers well—conditionals, loops, the various data types.

The following are terms that you may have heard before, but don’t quite have a grasp on. In keeping with the format of this blog, neither do I, but here goes nothing:

Object-Oriented Programming (OOP)

OK, this is something everyone needs to have a basic understanding of, if you don’t have one already. OOP is programming oriented around—wait for it—objects.

What’s an object?

It’s easier to think about objects by what they’re made up of—a combination of variables, functions, properties, all sorts of data. These data are stored within the object in the form of keys and values (in JavaScript, this looks like ‘var obj: {key: value}’). Let’s say my cup of coffee is an object. I’ll write it out here in object literal notation for js:

var coffee { temperature: 160, color: black, sugar: “Papa didn’t raise no sissies.” };

It’s like data, but, y’know, more so. 

tl;dr

OOP revolves around the construction/structure and interaction of different objects to build a piece of software.

Module (Modular Programming)

A fancy term for the simple elements—functions or subroutines, classes, variables—that build a much more complex program. When we talk about modular programming, we’re talking about the way different pieces interact, how code elements are interdependent.

Many applications are built on modular programming with a single module file containing class and function definitions that are accessed or imported by other files. It’s a convenient way to keep the nitty-gritty details of code in one easy-to-find place when building out something to scale.

Client-Side Scripting

Scripting executed in a user’s web browser. HTML/CSS and Javascript are the classic examples. The computing is done on your end. I usually think about this in relational terms to front-end development; I see the information on my end, interact with it and provide my own information, which is processed on the back end. Which brings us to…

Server-Side Scripting

If client-side is closer to front-end, server-side is the back-end. This is computation performed on a host server. Think about it logically: If all the data you saw on your computer screen was processed on your end, load times would be impossibly long. But a server can only process so much information at a given time (remember healthcare.gov?). Some data is stored exclusively on these servers and presented client-side only when it is being accessed.

This sounds simple (maybe even patronizing), but again, that’s the purpose of this blog. Examples of server-side scripting include Java, C++, ASP.NET, and all of the more complex languages that build highly functional, cool apps/software.

Application Programming Interface (API) 

Odds are you’re using several right now. APIs are the stuff that cool web functionality is built on. Technically speaking, they’re a set of programming instructions that dictate how users can access and utilize a web tool. When software companies release public APIs, it allows developers to build tools and applications for sites like Twitter, Facebook or Amazon. Streaming a Netflix video on your DVD player, using your mobile device to pay for concert tickets—simple enough, but it requires different devices with potentially different data structures to work together.

Mega tl;dr

APIs allow software to talk to other software seamlessly, without the user noticing.

Integrated Development Environment (IDE)

Also called an Interactive Development Environment. IDEs are a mixed bag, one-stop-shop for everything you need to write code. Most feature an editor, compiler/interpreter, debugger and a GUI builder (GUI is Graphical User Interface…does this need a definition?). IDEs let you get a look at your code in real time as you write it, plus troubleshoot problems as you go.

“What You See Is What You Get” (WYSIWYG)

WYSIWYG looks like a Welsh swear word. To some programmers, it is (…a swear word, but not necessarily Welsh).

Think of WYSIWYG as writing code in reverse. Adobe’s Dreamweaver gets a lot of flak from the dev community; it allows you to design a web page and creates the code after the fact, fielding it out based on the design. Seems simple enough and it works for a brave few. But it makes a mess of the code, often resulting in something referred to as “tag soup”—improperly nested HTML tags and jumbled, overly complex code.

The appeal of WYSIWYG builders is clear to the uninitiated but it can create a lot of problems. I’ve found that Dreamweaver works well for me as an IDE, growing code from the root up and being able to view it in split-screen mode as I build. But I imagine this gets more difficult as projects scale.

Stack

I threw this one on here because it was really bugging me—just kept seeing it without understanding what it was. I’m least confident in my explanation of this term. Hold on tight.

A stack is a type of data structure that holds elements in a particular order. Those elements are accessed LIFO, an acronym for “Last-In-First-Out.” Stack structure is important in understanding a program’s workflow, how it sees, accesses and uses data.

A good example is the undo command (with which I am all too familiar). Type a sentence. Copy-paste something. Whoops, didn’t mean to, undo. The copy-paste action—stored as the most recent function executed—is removed (or “popped”) from the top of the stack. If you select undo again, your typed sentence is deleted, emptying the stack (or creating a new stack in the redo action menu).

Phew!

I’ll follow this post next week with a few more comp-sci terms to butcher. Leave any questions or comments below, or on Facebook/Twitter. I’d also like to know what topics you think I should cover. Drop me a line!

Want to get in contact with Frank? Tweet at him at @Frank_Merk or visit his website.

Update: Frank wrote an update to the first part of his computer science glossary, you can find it on his blog “Idiot Learns to Code.”

Credits: Frank Merchlewitz photo courtesy of Merchlewitz.