I'm Simon Allardice. I obsess about the best ways
of learning—and teaching—software development.
And then I make courses that try to do that.

December 24, 2014 my latest course is out at lynda.com:
Comparing Swift and Objective-C

Also out recently at lynda.com: my iOS App Development with Swift Essential Training, Swift Essential Training and Swift First Look courses.

Why programming manuals aren't on audiobook

15 Jan 2015

Ever wondered why we don't get a lot of programming reference manuals on audiobook? Here's the reason, illustrated with a reading from "The Swift Programming Language" document from Apple, section on "Metatype Types".

Getting Started, circa 1983

17 Mar 2014

Like most folks who started programming in the 70's and 80's, I began on mainframes. It was years before I programmed a desktop computer.

And while I strive to avoid damn-kids-get-off-my-lawn graybeard ramblings, I'll sometimes get this question from a brash young whippersnapper trying to understand what pre-PC era programming was like:

Back in your first programming job, what kind of computer was on your desk?

In my first programming job, I didn't have a computer on my desk.

My desk - like those of my co-workers - was device free. The nearest we had to a personal computing device was an LCD calculator.

Not only didn't I have a computer on my desk, there wasn't one in the entire office, or even in the same building. We were programming a mainframe that was about five miles along the road.

Instead, imagine a stack of these on my desk:

COBOL Coding sheet

This is an IBM coding sheet, for COBOL. We had them for other languages, too: Pascal, Assembly language, Fortran.

You'd use these to hand-write your computer programs. In pencil.

Because this was the dizzying heights of "undo" technology:

pencil eraser

And when you were finished handwriting a section of code - perhaps a full program, perhaps a subroutine - you'd gather these sheets together (carefully numbered in sequence, of course) and send them along to the folks in the data entry department.

They'd type it in.

And the next day you'd get a report to find out if it compiled or not.

Let me say that again: the next day you could find out if your code compiled or not.

If you'd made even a simple typo - say, a missing period, or something that looked more like a colon than a semicolon - it'd take at least another 24 hours to get a fix in and turn it around.

This method, as you might imagine, requires a somewhat higher level of attentiveness to writing code than the way most of us work now.

I wouldn't want to work like this again, but I'm glad I have worked like this.

And though it may seem primitive now, several of the programmers I worked with at the time viewed that state of affairs as programmer-friendly, if indeed not simplistic.

They'd been used to working with punch cards, something I only ever did a handful of times.

I'll admit that even at the time (early 80's) this was a little - though not much - behind the times. I was working for the British Government, not some new-fangled highly-funded tech company. You use what you can get.

A year or two into this, we were finally upgraded. Amidst much rejoicing, we were provided a handful of IBM 3270 dumb terminals - monochrome devices, with the classic IBM Model M clicky keyboard.

Imagine the sensation - type your own code in? Compile a program yourself? How marvelous! What an age we lived in!

Do I need to know C to write Objective-C?

02 Mar 2014

Another common question:

Should I learn C and/or C++ to be an Objective-C developer?

If you're asking, and therefore have any amount of resistance to the idea, then: no.


But this is a long-winded "it depends" answer. There are some developers that very publicly proclaim no-one should touch Objective-C without being a C expert first, but that is simply and demonstrably untrue: I know many successful, knowledgable iOS devs with multiple apps in the store who couldn't write a basic C malloc statement if their lives depended on it.

However, some of this is personality-driven - some folks enjoy learning the underlying tech, and it's true that if you're good with C, you'll enjoy lightbulb-going-off understanding of why-things-are-the-way-they-are in the Apple frameworks.

So - is knowledge of C useful? Sure.

Is it necessary? No, I don't believe so.

There's enough already to learn in the world of iOS dev, so I suggest that most people, most of the time, be as ruthless as they can in dumping anything that's not absolutely necessary.

If your primary goal is "Write an iOS app and get it in the store", then C is a nice-to-have-but-not-essential skill.

If you know C already, great - but if you don't know it, spending weeks (or months) wrapping your head around C concepts and techniques that you will never (or at least, very, very rarely) use in Objective-C isn't the best use of your time.

However, if your goal is not just the pragmatic "write and sell an app", but also "have a deep understanding of what's going on under the hood", then sure, C is a stunningly useful language to know.

(Well, I pause while I'd make an argument for Assembly Language as being the true hardcore language to give you a real appreciation of what's actually going on on the chip... but try C first and see how you like it.)

What about C++?

Okay - there's value in knowing C even if you're not going to write plain C programs, but C++ is a language you should learn if you want to actually write C++ programs. If you don't want to write C++ code, don't learn it.

Full disclosure - I'll admit C++ is not my favorite language - I spent a long time writing it, and about 10 years ago had a consulting gig where I was brought in to spend 6 months purely on fixing other people's incompetently-written C++ and that was like aversion therapy; I shudder to look at it now. so I don't mind if you like it, but I'd be a happy man if I never wrote a line of it ever again.

Previous entries