ELI5: What are the differences between the C programming languages: C, C++, C#, and Objective C?

"Hello World" in C

C, C++, C# and Objective-C are all programming languages. They're all special ways of writing where a programmer can ask a computer to solve problems for the programmer.

Don't be fooled by the letter “C” in their names, the 4 languages are actually quite different.

---

C is the oldest of the 4. It was one of the first really popular programming languages because it was good at solving the types of problems that programmers had way back in the 1980's. Things like “portability”, “memory management” and “correctness”.

C is quite a simple language, which means you need to do a lot of writing to ask the computer to do complicated things.

---

C++ is actually C with lots and lots of extra stuff added in. It's name is a pun, where to the computer, C++ means something like “better than C”. And yeah, there's other computer languages with pun names like “D” and “F#” too. Because C++ is a lot more powerful than C, you don't need to write quite so much stuff to get the computer to do complicated things.

---

Objective-C is also C but with different stuff added into it. Both Objective-C and C++ try and help programmers solve tricky problems using something called “Object Oriented Programming” (OOP). That's where the “Objective” part in Objective-C comes from. OOP was really good at solving the kinds of problems we had back in the 1990's.

OOP is so successful because it helps teams of programmers work together and co-ordinate. Any time you have a large group of programmers working together, especially on the very largest software projects, you'll find that they're using some version of OOP to help them all co-operate.

---

Because both C++ and Objective-C have a shared history in C, if you wanted, you could take a C program and pretend that's it's C++ or Objective-C and most of the time that might even work!

What really happens though, is that because the languages are so different, it changes the way that programmers think about their problems. This means that C programs, C++ programs and Objective-C programs all end up looking quite different from each other, even when programmers are trying to solve the same problem. ( See also: Sapir–Whorf hypothesis. )

---

Which brings us to C#. C# isn't really a C language at all. There's actually another programming language called Java that used to be really popular around the year 2000 because it helped with the OOP problem much better than anything else. A company called Microsoft wanted to make something that was kind of like Java, but kind of different too. So they created C# to work a lot like Java, but changed things up a little bit so that it looks kinda like C if you squint.

---

Well here we are in 2010's, and the kind of problems programmers are facing have changed again. It turns out that using OOP can sometimes combine with other problems to make them more complicated, graphics problems like “threading” and “latency” or the special problems that come up with Artificial Intelligence for example.

While we have newer languages like “Cg”, “R” or “Python” that try and address some of these newer problems straight on, it turns out the simplicity of C allows individual programmers to focus more clearly on the problems that are important to them. That's why C is still popular today, even though it's the oldest of the 4.

---

TL;DR: C is really simple. C++ and Objective-C are kind of similar because they're both C with extra stuff for “Object Oriented Programming” (OOP). C# is the oddball because it isn't really a C language at all, it's more like Microsoft's version of “Java”.

---

Source: Am programmer.

Praise the Fire Fighter, Damn the Safety Inspector

There's a sickness eating our industry.  It's a culture of Macho Programming.  In it's simplest form, it's the idea that if we just push harder, longer, stronger, then we will win.  Yet time and time again, experience shows that the way to win is by working smarter.

Side-effects

I was once working on a particular AAA title.  The game was running late.  We were in crunch, and had been for a while.  There was no end in sight.  I came across the following code:⁽¹⁾

bool DetectCollision(Vector3 location, float radius){
  ...
  radius * 1.2f;
  ...
}

So that line of code makes the collisions a bit fatter.  It's what we call a 'Fudge Factor' - we don't know why a problem is occurring, so we fudge the numbers a little until it works.

But take a closer look.  The statement as written has no side-effects.  It doesn't actually modify the value of radius.  When the programmer wrote:

  radius * 1.2f;

they intended to write:

  radius *= 1.2f;

Let's review the facts:

• It's the wrong fix to begin with (fudge factors are generally a bad idea)

• It doesn't actually change the behaviour of the running program

• The programmer didn't verify that their "fix" worked

And we can safely assume that the programmer didn't verify the original bug in the first place.

Compound Fail

It gets worse.  In this late stage of crunch, there were so many easily avoidable bugs coming in to the code, that the production team mandated every changelist required a second programmer to sign off.

That's right, not one, but two programmers, working together, managed to convince each other that this placebo changelist actually improved the game.  Together, they marked the bug as fixed and sent it back to QA, fully confident they had made the game better.

What other trivial mistakes did those programmers make that night?

What a colossal waste of time and resources, simply because those two programmers had inadequate sleep.  The project would have been much better off if those two programmers had just gone home at 18:00.  Or 17:00.  Or even 14:00.

[Edit: I just wanted to add, these are actually two really good programmers! I'd jump at the chance to have them on my team again.  The equation here is crunch + good programmers = too many careless mistakes.]

Praise The Fire Fighter ...

When you're deep in crunch, it's easy to see the heroic efforts, the mountains of caffeinated beverages, the change logs at 4am.  It's easy to point to the person who's working the hardest and say "We all need to be more like that guy."  Because when it's all falling apart, you need to do something.

(Hint: That something we need to do is to get more sleep.)

... Damn the Safety Inspector

And when you're at the beginning of the project, and the Safety Inspector is telling you that what you're building isn't up to code, that the schedules are unrealistic and will lead to crunch, slipped deadlines, hard-to-find bugs and adds unacceptable levels of risk to the project...  Well they're easy to dismiss "We're trying to build something here! Why are you trying to stop us?"

(Hint: The Safety Inspector is probably right.)

Macho Programming

As an industry, we should be working smarter than that. We should be rewarding measurable results and hard evidence, rather than effort and posturing.

To me, Macho Programming, is blundering onward in whichever way you possibly can, without regard to what's best for the project or the team, simply for the appearance of getting something done.

I think we can do better than that.  In the true Agile sense, as a team, we need to make the best decisions based on the best information we have, right now, and move forward in the best direction we can.

Who's with me?




⁽¹⁾ Some details have been changed to preserve anonymity.

ScooterBoy NZ Launch at Digital Nationz

ScooterBoy and Modka Games was lucky enough to be involved with the Homegrown exhibit at the Digital Nationz expo!

The ScooterBoy booth at Digital Nationz

Hands on

Our booth consisted of a large monitor hooked up to a laptop (Display Mirror), playing the actual game.  We had a second laptop with a slideshow, and then lots of glossy printouts of the logo, icon and artwork.

www.scooterboygame.com

We also had two iPads running the game, which we tried to get into the hands of as many players as possible, getting some awesome user feedback.

Oh, and a portable "QR" code with a direct download link for iPhone users!

Attract Mode

For the main screen, we cooked up a special build of ScooterBoy running in "Attract mode" - basically bouncing between the intro comic, level selection, and the game itself, choosing random levels, scooters, characters, pets, music, etc.

I hooked up Momma's AI to the player, so the game would merrily play itself with no human intervention required.

"Attract Mode" turned out to be a super useful feature, it meant we could talk to gamers 1 on 1, while the screen continued to play for the small crowd that gathered.

... in fact "Attract Mode" proved to be so useful, that on the second day of the expo, two other Indies had added the feature to their game!

Big Screen

ScooterBoy also got some time on this awesome 103" panel upstairs in the chill out zone.  It really shows off the amazing HD retina graphics in ScooterBoy!

Telecom Homegrown "BigScreen", running ScooterBoy

Thanks!

Thanks everyone for making an awesome #ScooterBoyGame weekend with @DIGITALNATIONZ

And a special shoutout of thanks to Telecom, Asus, @oldjackgrey, @BenTuhoeKenobi and @sknightly!!

Shameless Plug

And if you're in New Zealand, and own an iPhone, iPad or iPod touch, why not download ScooterBoy and give us a rating! ScooterBoy on NZ App Store

Mr Lemon

Wow, we've been pretty busy with a whole bunch of things lately!

It's not quite ready for the big reveal yet, so in the interim, here's an unmodified screenshot from a real tablet to show some of the cool new stuff:

Click through for original size

You can see one of the new characters, Mr Lemon, pulling a wheelie, and wearing the always popular cowboy hat!

As this is the first (tutorial) level, there's also a swipe hint to the player.

And lastly, a debugging helper in the bottom left, 59 fps on the slowest iPad!!

FrameBaker

Marmot Recipes

Today I'm working on the "FrameBaker".  It's a tool we're using to put the characters and animations into the game.

You can see here a work-in-progress of the "Pink Marmot".  It's just one of the many characters you'll be able to unlock in the game as you progress.

FrameBaker

The FrameBaker starts with all the individual elements that make up the animation.

This is the Primary Animation, and makes the biggest emotional impact for the player.

You can see the familiar Squash and Stretch in the last four frames on the right.


Next we add in the Procedural Animation.  I'm using a technique called Inverse Kinematics to keep the arm locked onto the handlebars and the shoulder.

In a video game, it's the procedural animation which links the character to their environment.

In the screenshot, you can see the green tick marks which show the anchors and pivots for the inverse kinematics solver.




Lastly we mix in the Secondary Animation.  This is the spinning beany or the waving antenna.  It creates the believability and makes the character seem real without affecting their overall movement.



    ...and that's how you bake a Pink Marmot.

The Infinite Blogpost

There's an Indie project floating around at the moment, that's being touted as infinite.

For some reason, it really bugs me when people take a perfectly good word, a word like "infinite", and then apply it incorrectly.

You see, a desktop computer is finite.

Suppose your desktop computer is a Commodore VIC-20, with a whopping 3.5 kilobytes of memory.  Then there are only 256^3,583 different states that your desktop computer can be in.

Sure, that's a lot of states, but it's certainly not infinite. You could, at least in principle, enumerate them all.  And you'd find that there are exactly 256^3,583 of them.  That's the very definition of finite.

Finite software runs on finite computers

Lets take a closer look at those finite states on the VIC-20.  We know that the computer is finite, but maybe there is some magical technique in which we could write a computer program to have an infinite amount of state?

Unfortunately, no, we cannot.  The pigeon hole principle forbids it.

Fast forward to the Modern Era

Oh? Your computer has more memory than a VIC-20? 4 Gigabytes perhaps?

Well that's still just 256^{4,294,967,296} states.  It's still not infinite.

Oh, you have a 3TB hard drive as well?

Okay, so now you have access to an additional 256^{3,298,534,883,328} different states.

That's a lot of storage.  These numbers are large, but they're all still finite.

The problem is that infinity is just so mindbogglingly larger than any number you could possibly store on your hard drive.

You'd need a technology shift to be able to store infinite state.

Bandwidth, over time, is Infinite

So hopefully I've managed to convince you that your computer, and by extension, the software running on it, is finite. Regardless of what that hardware is.

But now consider, the curious case of your internet connection.

If you're like me, you have a bandwidth cap of 4GB per month.  Then it is true, that for any particular month, your bandwidth is finite.

But consider your 4GB bandwidth extending over time.

I can send 8GB in 2 months.  Or 40GB in 10 months. Or 400GB in 100 months.

Here's the curious thing, if we assume that time is infinite (a big assumption, granted), then for any amount of state, we can calculate how many months it would take to send that state on your internet connection by dividing by 256^{4,294,967,296} .


Let me repeat that, given any amount of state, we could send that state in a finite amount of time, over your internet connection.

And that is what is meant by "Bandwidth, over time, is infinite".

Don't Repeat Yourself

When making Indie games, there's a mantra that bears repeating over, again and again:

“Don't Repeat Yourself”

It's actually a corruption of a much deeper truth. If software development excites you, I urge you to read all the gory details about that deeper truth over on wikipedia. (If you want to go read it now, I'll still be here when you get back.)

When making Indie Games, however, “Don't Repeat Yourself” means something different. It's rooted in the notion that (calender) time is the most precious resource. It's the free variable with the highest opportunity cost. The longer amount of time it takes you to do something directly translates into a lesser amount of time you could be working on your next goal.

So what happens if you have to repeat a previous step? Replace an image that's no longer working? Change a sound effect? Rebuild a level? What happens when you have to repeat yourself?

For every repeat, the time you wisely invested into the previous version of that asset is effectively wasted.

You would have been better off using that initial time reading game development blogs. Or meditating. Or playing Dino Switch II.

So what does "Don't Repeat Yourself" really mean? It means that as an Indie, (almost) every piece of content you put time into, needs to ship at some point in the future. It means that each time you touch an asset, you should treat it as the last time you'll touch it before it ships.

Your asset pipeline (as an Indie) needs to go :

Concept -> Placeholder -> Shippable Asset

Cappucino

Contrast that with the apocryphal AAA game producer, “Make three cappucinos... then bring me the best one!”

Of course, what he really means is “Have three baristas separately make three different cappuccinos... then discard the two which aren't as good.”

So here's a Pop-Quiz, are those two discarded cappuccinos wasted?

Some would say “Yes”, referring to the ingredients and skill which went into the preparation of content which will never be consumed.

Others would say “No”, because the producer couldn't know ahead of time which barista would prepare the best coffee. Three times the amount of resources have gone into the production, in exchange for an improvement in quality and a substantially reduced chance (risk) of getting a bad coffee.

Don't Repeat Yourself

As an Indie, where (calendar) time is the most precious resource, “Don't Repeat Yourself” means shipping every piece of content you produce. If you somehow find yourself with 3 cappuccinos, then you're going to be drinking them all!

But does that also mean you need to ship the pieces which didn't work out? Not at all. Because the overarching process goes like this:

• Get placeholder assets for everything into the game

• Without repeating yourself, systematically lift every asset in the game up to shippable quality.
  (Upon completion, your game as a whole ought to be shippable)

• Do a polish pass where you replace only the assets which are (a) quick to improve, (b) have a big impact on quality

• Ship it

And that's indie game development...

Beta

In the world of stuff, there's things that you know, and things that you don't know.  It can sometimes feel like all of us are simply questing to try and know more and more stuff.

But there's another way of looking at the world of stuff.  We can also split stuff into the things that other people know, and also things that other people don't know.  It can sometimes be confusing thinking about what other people know.  Fortunately we live in a social world so we should all be good at it.

In any case, Mathematicians, like me, sometimes like to use Venn Diagrams to describe these kinds of relations:

We can then build fun subcategories, like "Secrets", which contains all the stuff that we know, but that noone else does.

Or "The unknown" - that's all the stuff that noone knows about.  Yet.

But there's another interesting subcategory that I wanted to talk about today.  I'm sure there's a great German word for this category, but I don't think it has a name in English. It's that category of stuff that other people know (about us), but that we don't know about ourselves.  It's all the stuff like:

• What does the back of my head look like?
• What was everyone laughing about just before I walked in to the room?
• Why do I always struggle to open doors?

And the all-consuming:

• Does this pair of jeans make my anorak look out of proportion?

Even in principle, this stuff is unknowable to us. Why? Because even if we were to ask a trusted friend, there's a complex web of social contracts which ensures the information they relay to us be 100% believable, yet have no basis whatsoever in reality.

Beta Testing

When we're making video games, there's a number of tools we can use to improve the quality of the game prior to launch.  One of the most useful is Beta Testing.  Of course, we do all manner of testing when making video games, but Beta Testing is the one which can really make or break a game.

In a true Beta-Test, all of the intended features are actually present in the game in a playable state.  It might even be one of the first builds where this is true.  The game is then played by people who are outside of the development team.

In a (true) Beta-Test, it's the development team looking for feedback about all the stuff that other people know.


So if you're ever asked to Beta Test some software, what does that look like?


Well first things first, remember the social contract?  That's not what a Beta Test is about.  The dev team isn't looking for praise or apologies, they want solid, genuine feedback about the features in the game. Be that an emotional response ("it felt great when..."), or something actionable ("I couldn't reach the exit because...")

Naturally they're looking for confirmation about the stuff they (think they) already know, so be sure to include some high level comments about the stuff that seems obvious to you, the stuff that "...everybody knows...."

More valuable to the dev team is going to be feedback about stuff they don't know.  Try and tell them about the bugs that only you encountered.  Try and share anecdotes that are relevant, but that will be unknown to the dev team.  Try and give them access to the areas they can't otherwise see.

The Beta Blog Post

So all of this is stuff that I know, and after reading though, now it's stuff that you know too.  I happen to think this is important stuff that everyone should know, but I may be in the minority on that one.

However, there is a chance that this blog post contains serious defects.  For example, I know that this post still has lots of room for improvements.

For that reason, I'm officially declaring this blog posting to be a "Beta Blog Post".  What that means is, I think it contains most of the good ideas, but there might be stuff about this topic that I don't know (yet) or haven't covered adequately.

Why not help me out and use the comments section below to give me some feedback, maybe an emotional response, or even something actionable?   ;)

The Big Picture

"It's just behind that one over there!"

I always have this kind of mental picture in my head about all the things that need to happen before I can launch a game.

It's filled with lots of tiny little things :

• Putting in a 'squish' sound when you press a button on the main menu. (5 minutes)
• Re-export a piece of artwork with different quality settings. (10 minutes)
• Building out the website with a FAQ section. (15 minutes)

For each one of those little user stories, I'm thinking : "Oh, I can do that, that's easy."

There's also a whole bunch of medium sized things :

• Make the draw routines faster so it doesn't skip quite so much. (1 hour)
• Add a 'Load' screen to, umm, cover the loading. (1.5 hours)
• Make the 'Undo' button work properly. (2 hours)

I guess if I had to, I could cut those user stories, but in the back of my head I'm thinking, "Oh, I know how to do that too, it's not that hard..."


Of course, there's a whole bunch of difficult things to do too, but even those I'm not too worried about.  I know in principle that they're solvable, and I've solved similar tricky problems in the past.

The problem comes when I try and find all the things that need to happen before I can launch a game, and then add up how much time it is going to take to get all of those things done.  It's a huge chunk of time. It can be a little daunting.

The Plan

My original plan was to have an app out on the appstore by now.  So I guess that didn't happen :)

But I hope you'll allow me the indulgence of quoting former US president, Dwight D. Eisenhower:

         "Plans are worthless, but planning is everything."

The easy thing to do right now would be to just keep chipping away at the original plan.  I am making good progress after all, even if there has been considerable discovered work.  It definitely feels like I'm getting closer to something.

"... That one over there looks easier to get to..."

But maybe there's a smarter way through here.  Maybe I can find a smaller game to make.  One that I can launch sooner.  Something to at least establish a presence, and then use that as a base to launch bigger games.

...hmmmm...

What would you do in this situation? Any advice? What do you think I should do?

    ... watch this space ...

Officespace

What makes a great work environment?

I've had a lot of time to think about this one over the years, mostly when working in cramped, overcrowded, smelly, noisy, unsafe or otherwise distasteful locales.

I always used to think it would be in a context of setting up my own team in a new office.  Now that I've gone Indie, that's still true, but it's a team of one.

Space

The most critical element in the work environment is space.  You need enough space to have all your working equipment easily accessible.  I like to have everything already plugged in and ready to go, but switched off at the wall.  And don't forget to move around and stay active, so I've setup a typing station, a coffee station, a thinking station, a reading station, a print/scan/copy station, an audio recording station etc, etc,  each already prepared for a particular type of activity.

If you're a fan of John Cleese, you'll know that low ceilings encourage closed thinking modes, and high ceilings facilitate open thinking modes.  Factor that in the next time you book a meeting room for a brainstorming session (high ceiling) or triage session (low ceiling).

Time

How many times have you heard, "It's done when it's done!"

For many creative tasks, you can estimate how long something will take, but not very accurately.  I find it useful to work in blocks of around ~2 hours. I pick a task I think will take an hour to do, and work on it, until it's done.  If there's still 2 hours left before the next planned disruption, I'll pick another ~1 hour task, and work on that.

It's crucial to finish every day with a win.  Ernest Hemmingway says it much better than I ever could:

"The best way is always to stop when you are going good and when you know what will happen next. If you do that every day … you will never be stuck. "

Some employers believe in billing for hours worked, and still others believe in crunch.  If you're in a creative industry and you're being micro-managed like that, and want to have a career rather than a burn-out,  I strongly recommend considering your options.

Location

The day doesn't stop when you walk out of your office.  You still need to get home (or to the gym, or to the pool, etc)  How much is that commute costing you in terms of money, time and stress?  Is the parking lot safe? Can you even find a park when you need to? Can you commute when it's raining/snowing without getting wet?

Working from home is great, but be sure to separate work from home with a doorway or even a staircase.

If you're forced to reuse equipment, then create separate user accounts, facebook accounts, email accounts etc, and be sure to log in and out every time you transition from home to work and vice versa.

If you're a real digital nomad, why not setup separate home and work environments on different USB sticks using portable apps?

Ergonomics

There's a lot of literature about setting up your chair, desk, keyboard, monitor for comfort and usability.  It really does make a difference.  If you're still a skeptic (like I was up until recently), just try it for a week.  If you don't see an improvement, you can always go back to your old bad habits.

...And don't be shy, help out a neighbor.  If you see a colleague struggling with RSI, or squeezed in to the wrong sized chair, bring it up, maybe it's something you can help with.

Sound

Headphones are not enough.  You need a reasonably quiet, connected space.  We humans are social animals, so complete silence can be too isolating.  We need to feel connected with our colleagues, and with the wider environment too, but not distracted from the task at hand.

Oh, and a pet-peeve of mine, a place to take private phone calls.  I hate reciting credit card numbers in a hallway frequented by programmers with eidetic memories.

What else?

What makes your work environment great?  How could it be even better?