Making Fun of Bad Code Is Fun

The latest con talk from Katrina Owen is now available for viewing. It’s one of the funniest talks I’ve ever seen, though the Prisoner’s Dilemma stuff at the end brings it home in a slightly less entertaining fashion. Still, it’s well worth watching, if only for the first 20 minutes.

As with her previous talks, the slides complement the talk beautifully, particularly in the way she shows code and changes in code. You need to pay attention to the video, too. She goes fast and doesn’t always narrate everything.

Whatever Happened to – Ann Mei Chang?

Time for another editorial from ENTER Magazine. This one is dated September 1984:

It’s an article on teaching computer programming, written by a sixteen year old from Lincroft, NJ by the name of Ann Mei Chang.

I was 16 and an assistant instructor at National Computer Camp in Orange, Connecticut. The campers I was teaching were as old as 15. I was very nervous about getting up in front of them. What is they didn’t understand anything I said? I’d be really disappointd if the class was a failure.

Natural worries there. Anybody who has taught anything has had that thought cross their mind.

I was teaching the group Assembler — a fairly complex language that’s used in serious programming. I was nervous, but I wasn’t unprepared. After three years working with computers, and after spending two weeks at National the previous summer, I knew my subject, But would I be able to explain it to other kids?

Long story, short: yes, she could. She outlined three lessons she learned:

  1. Anyone can learn to program if he or she just tries.
  2. Girls are as good at computers as boys are.
  3. You’ve got to be willing to work if you’re going to learn.

Let’s see what she had to say on point two nearly thirty years ago:

While there were fewer girls than boys at National Computer Camp (the ratio was about five boys to one girl), those that I taught were every bit as good as the boys at programming. Three of the eight kids in my class were girls. These girls were just as quick to catch on to difficult concerpts as the boys were. Of course, that didn’t surprise me.

Oh yes, I learned one other lesson. Teaching about computers is a lot harder than programming them. Computers only do what you tell them to. People are never that predictable.

So, whatever happened to Ann Mei Chang? She has the title of Chief Innovation Officer at Mercy Corps in San Francisco today. Before that, she spent time at Google, and was a Fellow at the U.S. Department of State on Global Women’s Issues: “Among other projects, Ann Mei is looking at opportunities to leverage technology to improve the lives of women and girls around the world.”

Here, she writes more about her early days with computers, playing Space Invaders, wanting to program her own game, etc. Just to bring it full circle, here’s part of that history:

While I never developed a full-fledged video game, before I finished high school I went on to write a grading application for teachers at school, build a voice command interface demo at the local Army post, and teach at a computer summer camp.

She is, of course, also on Twitter.

How We Used to Code

To everyone who talks about the relatively minor differences in computer languages today:

This is how we had to do it thirty years ago, from the backs of computer magazines.

Here’s the closeup:

This kind of stuff would go on for three columns per page, and multiple pages per program. Thankfully, as I recall, the last couple of pairs were the checksum that you had typed the line in right. You didn’t go far after making a mistake…

It wasn’t all bad, though: You could also mail a check out for something like $10 or $20, and they’d send you a floppy disc with all the code on it already. Like Mom and Dad would let you get away with that

For completeness’ sake, here’s how to enter the code:

This came out of COMPUTE! magazine, dated December 1987. It had a sister publication, COMPUTE!’S GAZETTE that focused on Commodore computers.

A Different Technology Problem in 1984

Let us look back now to 1984. “ENTER” magazine published an editorial from Stephanie Kaufman, a 17 year old high school student with an interest in computers. She sets up her bona fides at the start:

Do you know how to program? I do. I know Applesoft BASIC, Integer BASIC, Fortran, UCSD Pascal, Mt + Pascal and Forth. I’ve taken five semesters of Computer Math and spent many hours working in my school’s computer lab.

So far, so good, right?

There’s one thing I don’t know, though: how to use computers in a practical way.

Kaufman went to a school in Denver, Colorado with a strong computer program. It taught her a lot of programming stuff. She took things called “computer math” courses.

At school, we’re always hearing about the importance of learning to use computers. The funny thing is, we never learn any of the practical applications. Instead we learn to program, a skill we may never need outside of class. […]

And then we get to her conclusion, which shows you the horrifying future she wanted had come true:

One way of teaching us how to use computers without focusing on programming is by using computers in our other classes. For instance, why not encourage students to use the word processing software for writing a term paper for English class? Or why not have students research a court case for a history class via The Source)?

Then she treads dangerously close to beating Steve Jobs to his trucks vs. cards analogy by twenty-five years:

Think of it this way: I know how to drive, but I have no idea how a car works. I know how to take care of a car, keep it safe and clean, and how to fill it with gasoline. But I don’t know what makes it run, nor do I need to. I do need to know how to drive one. Well, it’s the same with computers. We don’t need to become “computer mechanics,” but we do need to know how to “drive” computers.

Somebody tell the schools.

And here we are today, where we complain that computers are increasingly locked down without the ability to program them. We use them as fancy appliances (read: tablets) to research history papers on a service called Google. We know how to bring up Microsoft Word and write a paper on it, but we don’t know what a linked list is or how it’s the basis of a word processes from the code’s point of view. Increasingly, the manufacturers prevent us from tweaking the code we use or even getting access to it. The problem has reversed its polarity.

Funny world.

P.S. The Source was bought up by CompuServe in 1989 and subsequently shut down.

Large Programming Problems

Quoting the Washington Post:

Private contractors in charge of building the federal online health insurance marketplace testified Thursday that the administration went ahead with the Oct. 1 launch of despite insufficient testing.

In their first public remarks since the debut of the problem-ridden insurance exchange, executives of the main IT companies told members of the House Energy and Commerce Committee that full tests of the Web site that should have been carried out months in advance, but began just two weeks before its rollout.

I don’t care who’s to blame. This is Washington, so everyone will do an expert job of blaming everyone else. (If you read the story, you’ll see that that’s exactly how it happened. The contractors are blaming the government agency. Democrats and Republicans are blaming each other, often with the most tenuous of links to the issue at hand.) Testing for two weeks for a website of this scale is never going to do you any good. Not that you’d expect a panel full of Washington professional politicians to include anyone with any technological savvy…

Ultimately, it’s a larger problem than anything computer science can solve. It’s typical beaurocratic nonsense. And given how poorly the current system works, drastic reform doesn’t sound like a bad idea. Here’s one alternative:

The president should use the power of the White House to end all large information technology purchases, and instead give his administration’s accomplished technologists the ability to work with agencies to make the right decisions, increase adoption of modern, incremental software development practices, like a popular one called Agile, already used in the private sector, and work with the Small Business Administration and the General Services Administration to make it easy for small businesses to contract with the government.

Large federal information technology purchases have to end. Any methodology with a 94 percent chance of failure or delay, which costs taxpayers billions of dollars, doesn’t belong in a 21st-century government.

Update: Color me skeptical that this will be fixed by the end of November. It’s just too big a pile of code to correct that quickly in any reliable way. (Also, what government project has ever moved that fast?)

Enum.Inject in Elixir

The other day, I showed you Ruby’s Enum#Inject method. Then, I discovered that Perl had it built in through the List::Utils optional module.

Today, let’s use this as a learning experience with Elixir. I wrote the method up for Elixir like so:

defmodule Example do

  def sumup(list) do
    sumup(list, 0)

  defp sumup([], sum) do

  defp sumup([heda | tail], sum) do
    sumup( tail , sum + head )


I named the module Example and the function sumup.

Just to be a little trickier, I set the function up to accept only the list from the caller. Thus, sumup has an arity (number of parameters) of 1, so we refer to it as sumup/1.

That initial sumup/1 is just the public facing function. Its sole purpose is to make it a little simpler on the user to calculate the total of all values in the array by not having to specify a starting total. This program runs on the assumption that you’re always starting from zero.

It then calls on two private functions (defp denotes that) to do the dirty work.

Specifically, we start with sumup/2 where pattern matching kicks in for the first value. If the list is empty, the first version kicks in and returns up the sum. If the list is blank from the start, then it immediately returns the sum, which would be just passed in as 0.

Assuming there’s a list (even if it’s just one value), then we go to the second sumup/2 function. Pattern matching kicks in automatically on the list, and separates the first value (“head”) from the rest of the list (“tail”). It then recursively calls itself, passing the tail alongside the new sum (which now has added in the value of the head of the list the function started with).

Once you get to the last value of the list, “tail” is an empty list, “sum” is the total sum of the numbers in the list, and the first sumup/2 kicks in and returns the sum you had asked for in the first place.

Let’s see this in action. First, I’ll start Interactive Elixir (iex) and load up the file with the Example module in it:

Augies-iMac:elixir augiedb$ iex
Erlang R16B01 (erts-5.10.2) [source-bdf5300] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]

Interactive Elixir (0.10.1) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> c("example.ex")
/Users/augiedb/ruby/elixir/example.ex:1: redefining module Example

Obviously, this isn’t the first time I’ve loaded up the Example module…

Let’s start with the empty list:

iex(2)> Example.sumup []

As we expected. Parenthesis are optional. I like using parenthesis, generally, but for a quick and dirty example like this, I’m OK going without:

iex(3)> Example.sumup([])

That does look a little weird.

So let’s see what happens when we have a list with one value in it.

iex(4)> Example.sumup [1]

That does the trick. Finally, for multiple values in a list:

iex(5)> Example.sumup [1,2]
iex(6)> Example.sumup [1,2,55]
iex(7)> Example.sumup [1,2,55,1]

Elixir has a built-in reduce function in its Enum module, so you could always go with that:

iex(8)> Enum.reduce([1, 2, 3, 4], 0, fn(x, acc) -> x + acc end)

For some reason, reduce/2 isn’t working for me, so I needed to go with reduce/3 instead. Odd, that, but hardly insurmountable.

The Problem with Functional Programming

Functional programming does certain things very well. Amazingly well. Blows other programming out of the water.

Other things, I don’t know that it does much better. That limits it. And the problem is, unless a language can be all things to all people these days, why bother switching to it, or adding it as a major new tool in the tool belt? Being intellectually curious about something is one thing, evangelizing it in your enterprise career is another. Does it make much sense to start using a new language just to create HTML tables from database stores? Ruby, PHP, Perl, etc. will do that just fine.

So what’s the killer app for Erlang, Haskell, Elixir, etc. that blog writing was for Ruby on Rails, for example?

Finn Espen Gundersen nails it in his blog:

…if we want to convey the usefulness of FP [functional programing] to the imperatives amongst us, we need to focus on elegant solutions to real world inputs and outputs. Most software needs to integrate with other software. We need to show how our I/O-libraries, often overlooked or thought of as mere “helpers”, are superior in efficiency and leads to cleaner and more maintainable code. While a pure HashMap is a beautiful thing, let’s focus more of our time on Haskell packages such as postgresql-simple, amqp (of which I am a minor contributor), aeson and the fact that there is no native MSSQL library, just ODBC. Let’s focus on the plumbing, so to say. Great packages for integrating with the outside world is what will bring FP to the masses. When that prerequisite is there, only then are they ready for all the other stuff we have.

Minor Github Annoyance

Minor annoyance of the ego: I’ve contributed to the Elixir Wiki page two or three times now, with a few simple grammatical fixes and some new links added to the resources section. Nothing terribly major. It’s an open Wiki. You can basically do whatever you want. There’s no approval process. This isn’t like doing a pull request and hoping the owner accepts it. This is more like “accepted by a community by them not rejecting it outright,” really.

But Github doesn’t track those changes as being open source contributions when it comes to filling out that green graph tracking your activities:

Guess I need to work harder…

(Yes, it shows up in Public Activity, but that’s hardly as much fun as green boxes on a chart…)

Random Linkage for 19 Oct 2013

  • I made my open source contribution this weekend by adding a “Podcasts” listing page to the Elixir Wiki. Only two listings there so far, but let me know if you find others!

  • This is allegedly Facebook’s original home page code. Makes me hate PHP all over again. But you know what? It got the job done. And once the site scaled, they did all sorts of crazy things that they needed to go to keep things going. Nothing to be ashamed of there.

  • Interesting look at CSS code mistakes in Top 1000 websites. Most of these lessons won’t apply to most of us. Any website we work on is likely not quite this large. But the lessons are useful to keep in mind. I can hack my way through CSS, but this advanced stuff is new to me. (That said, even I would guess that using 700 floats on a single page is likely a poor design decision.)

  • I’m embarrassed to admit that I forgot about this, but I bet most people today wouldn’t know the answer to this question: Where are the A: and B: drives in Windows? What really makes me old is that one answer made sure to include a picture of the devices they were talking about, since lots of people today have never used a floppy disk! (ACK! OLD!)

  • Random thought: If I were designing the keyboard today, the pipe key would not require a shift.

Functional Programming in Ruby

Like so many these days, I’m intrigued by functional programming. There’s something so pure and so mind-bending about it that it’s easy to capture your interest and attention. I’ve been toying with Elixir to explore this path, which is basically Erlang rewritten by a Ruby programmer. (Yes, that’s a horribly general thing to say, but it’s what attracted me to the language in the first place. So just go with it…)

Today I watched Jessica Kerr’s presentation from this year’s Windy City Rails conference and it was awesome. It’s only a half hour, but it’s worth the time to see a great example of how to do functional programming with Ruby. She has some easy to understand rules and a simple, yet solid, example to get you started.

I want to go break out some stabby lambdas now…

October 20, 2013 Update: Sitepoint has a three part series called “Functional Programming Techniques With Ruby” that’s worth a read.