One of the common questions that comes up among students new to Computer Science and Programming is along the lines of “what is the best programming language?”. And the the brief answer to that is simple:

You’re doing it wrong.

This requires some elaboration. When one asks “what is the best programming language to learn?” or “what is the best programming language to build video games with?”, it seems that the intent is to get some experience with one specific technology, and stop there. That is a failure of an approach.

A programming language is a tool. Tools have specific purposes. Tools change. New tools, technologies, and techniques becomes available. It doesn’t make much sense to specialize in wielding a hammer over a screwdriver, if one lacks the core skill of following assembly instructions. However unlike this construction analogy, technological tools change rapidly.

“Java will guarantee a corporate job”; “PHP is required for web development”; “Ruby is growing at 400% per year”. A lot of people claim to have a solid idea of where the industry will be and are quick to offer advice, but this can’t possibly be the case. All of those languages — Java, PHP, Ruby, have first appeared in 1995. This means that all the hype that you are supposed to “know” right now, didn’t even exist just 13 years ago. So if you plan on sticking to your favourite high school programming language, chances are that by the time you graduate from a University, you’ll show up at the playfield with a wrong type of bat, so to speak.

Higurashi no Naku Koro ni (episode 9)

But then the question still stays: “what should one learn next?”. Algorithms, data structures, complexity, math… Learn the core abstracts, ideas, and skills that are language independent, and that transfer from one syntax to another. Learn the ability to learn. When a new opportunity with new technology comes along, you should be able to get over the learning curve fairly quickly.

So your “best language”; your “most important programming language to learn next” is the one that will help you do the above. As a tool. As a palette with which to express and explore your ideas. It might be one with the cleanest syntax, or the most documentation, or one that you are already familiar with the most.

It wouldn’t make sense to pick up a yet-another-programming-language just to be able to do what you already can, only with a somewhat different syntax. It’s useless to write the same basic sort in 12 different languages, if all of them are too slow to finish in a reasonable time. Worse yet if you don’t understand why this is so.

So lets drop this obsession with learning to say “hello world” (or some more complicated version of essentially the same) in every programming language one can name. Lets also drop the idea of finding “one language to rule them all; and retire”. Once we put the Science back in Computer Science, it wouldn’t matter which language you’ll end up using.

Related posts:

1. Looking back at working with PHP
2. You don’t know that programming language
3. Ruby – best introductory programming language

Or maybe you do? How about your favourite programming language? What does it take to say that one “knows” it?

michaelp asks:

When exactly do you “know” a language?

There’s a gradient of choices to pick from.

1. You know of the language — “I hear they call it Java.”
2. You’ve memorized the “hello world” program — <?php echo ‘Hello World’; ?>
3. You know something unique about the language — “Ruby has closures, but Java does not.”
4. You have all of the documentation memorized — because looking things up is much too slow.
5. And just to get to the other extreme, you wrote a compiler for the language… in itself. (That’s actually not rare, and is termed bootstrapping.)

So what does it take for a programming language to make it onto a resume? Apparently not much, if you are a student. “Know” is more like “know of”. Though perhaps that is fair enough. A lot of skills are transferable, and it’s quite easy to pick up on new languages with similar paradigms. I’ve done this myself before:

Even though I had no experience with PHP or Oracle, I was fairly familiar with Ruby and MySQL. My job offer relied on the claim that such web development is logistically similar, having substituted Ruby documentation for PHP.

Dan agrees.

I don’t think “knowing” a language is any where close to as important as knowing the concepts of computer science and software engineering. Once you have a good grasp of the basic and more advanced concepts, changing languages is trival and becomes easier with the more experience you have.

So perhaps it would be more honest to focus on what really matters — algorithms, design patterns, etc. Memorizing the syntax / API will let one type out that bubble sort faster, though that arguably demonstrates the lack of knowledge that matters.

I recall the first drafts of my resume, as I’ve started out in co-op at University. I’d list a dozen different programming languages that I knew of. Now I would probably list none. That is not to say that I have unlearned things over the years but, on the contrary, that it’s true that the more you know, the more you realize of how little you know in the grander scheme of things.

So, with a few exceptions, I don’t think one gets to “know” a programming language. I also think that this shouldn’t matter.

Related posts:

1. Looking back at working with PHP
2. Ruby – best introductory programming language
3. The most important programming language

There seem to be some misconceptions about Apple computers. Some of the common questions that come up, at least when thinking about for-University laptops, are along the lines of “Will I be able to write programs on a MacBook?” and “I thought Macs were just for arts…”. I will try to challenge that view.

Note: This is not a OS X vs. Windows vs. Linux argument. There are plenty of those just about everywhere else. If you really feel like repeating any of the arguments that have already been mentioned many times before — try the forums instead.

The use of Apple computers among the software developers is actually quite common. And with a plethora office snapshots available on Flickr, this calls for a visual case study!

Adobe

Original photo by: tskdesign. That’s totally a Mac. See the original image for higher quality. Though having made Photoshop, the Apple application, there isn’t much surprise here.

Digg

Original photo by: Mrs L. Digg’s Kevin Rose loves his MacBook. There’s more of this at just about every Diggnation episode.

Facebook

Original photo by: Zach Klein. This Facebook office comes with a couple of Apple workstations.

Flickr

Original photo by: roozbeh-a-brojeni. Searching for Flickr on Flickr is so meta…

GigPark

Original photo by: GigPark @ Flickr. GigPark is all Mac and iPhone. Those aren’t even available in Canada yet! (Also, is that Facebook.com on the screen? Slacker.)

Google

Original photo by: Anil Chopra. I don’t understand this, but one of Google’s offices has a boat for a couch. There’s also a MacBook.

LinkedIn

Original photo by: LinkedIn Blog @ Flickr. Look, it’s iMac. From another angle it’s actually a Cinema display attached to a MacBook Pro.

Microsoft

Original photo by: jeffwilcox. That’s right, a MacBook Pro on Microsoft’s campus. Actually those are not nearly as uncommon as one might think, as Microsoft develops plenty of software that runs on Macs as well.

Mozilla

Original photo by: stuartp. Mozilla’s new Toronto office is all Mac (and a cardboard box for a coffee table).

Twitter

Original photo by: kohtzy. I suspect that just about all of the computers at Twitter are Macs. Though other than the few marked in the image, event at high resolution cited, I can’t say definitively.

So there you have it — a bunch of Apple computers used by real developers at real software companies (likely using real programming languages). There are, obviously, a lot more tech companies, but I’d leave them to the comments section.

Related posts:

1. The silliest reason to get a MacBook

Hi, Im wondering how i can create a boat in turing and if someone can post a example.

This makes no sense, since one doesn’t normally make water vehicles in Turing, the programming language. Though this got me thinking — if a programming language was a boat, what would it be?

Turing

Turing would definitely be a kayak (thank you for comments). It’s small. It’s human powered. It’s often used as a beginner “boat”. And it’s also very Canadian.

Original photo by naokomc

Java

Java is a cargo ship. It’s very bulky. It’s very enterprise~y. Though it can also carry a lot of weight. Will carry a project, but not very fun to drive.

Original photo by cfarivar

Perl

Perl is a tugboat. Powerful enough to tug Java around, in 80 characters or less.

Original photo by xeeliz

Ruby

Ruby is difficult to describe. It’s sleek, sexy, and very fun to drive. Here’s a picture. Very trendy.

Original photo by Tony Falcon

PHP

PHP is a bamboo raft. A series of hacks held together by string. Still keeps afloat though.

Original photo by permanently scatterbrained

C

C is a nuclear submarine. The instructions are probably in a foreign language, but all of the hardware itself is optimized for performance.

Original photo by Ryan C. McGinley

HTML

HTML isn’t really a programming language boat.

Original photo by ascendeddaniel

There’s a lot more to this, and it’s all up for discussion. How would your favourite programming language fare in open waters?

Related posts:

1. The most important programming language
2. This is -Sparta- Ruby!!!
3. You don’t know that programming language

“This is even worse than before. They put multiple versions of their same code, in the same branch. And demos they found online.”

Cargo cult programming is a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose.

I have seen some students try to paste in blocks of code, seemingly at random, out of desperation, frustration, confusion… though doing that in a completely different language is new. Epic fail!

The thousand monkeys on thousand typewriters mentality fails as the number of monkeys approaches one. Software rarely gets better from having more code thrown in (actually it often gets worse). And lack of thought poisons the code-base for all of the team members, with content that should simply be deleted. This quickly turns into a mess of a project.

We’ve got to get more monkeys!

So for everybody’s sanity (and better grades!), lets refrain from throwing random code into group projects. I think a good rule to have is a requirement for some comments (it’s ok if they are short), both next to the new code, and in the source control commit messages. If anything, then simply as a proof, to everybody, that you know what you are doing. Lets be honest, if one isn’t sure what’s happening with their own code, others will have even less of an idea trying to figure it out.

No related posts.

This makes me recall one of my all-time favourite programming webcomics from MacHall:

As a person controlling your (DWITE) grades, I too have some advice:

1. Sidestepping the assignment negates its purpose. You fail to learn a concept or demonstrate your ability.
2. In an academic setting, you simply fail.
3. You are almost there. Even the hard code values come from somewhere, perhaps from figuring things out on paper — put the same logic into the program.

Though I think I’ll let MacHall offer the final advice on writing hard code…

That is all.

Related posts:

1. Ways to spot plagiarized code

Debugging software is an art of its own, without which it could be quite frustrating to explore the field of computer programming. The unchartered areas of computer code often come with ambiguous errors and bugs, and it seems that many students try to stay away from the unknown. There’s this fear of being told, by a computer, that you are wrong — though that may stem from the general tendency of schools to suppress creativity.

And that’s a closed loop — fear of errors discourage trying new things; isolation from errors limits experience of understanding bugs; limited experience spawns fear of dealing with errors. It’s a tough loop to break out of, especially if the educational system re-enforces the idea of not making mistakes. Though mistakes are there to learn from, and we must break out of this loop. Otherwise we give up creativity. We give up ability to deal with errors. We give up the sense of exploration and ability to understand and push a system to its limits. This is too much to pass up on.

There are many way of dealing with bugs and errors, and most come down to just one thing, understand exactly what you are doing. This is where the Computer Science part kicks in — set up an experiment that isolates the faulty code. This is kind of like deleting faulty code, but in reverse. Figure out what part of the code causes a problem. Figure out the problem. Really figure out the problem. It’s a learning process, and over time it’s easy to get a feel for what causes cryptic error messages, without the need to jump through the hoops to find that code. Though it takes practice.

I am not suggesting to break your own code on purpose (that’s just not the same), but don’t be afraid to have your code broken. It’s best to get in this habit early, as programming comes with a lot of errorous code: accidental mistakes and typos, having to deal with someone else’s code, or simply pesky University exam questions.

No related posts.

Developing quality software requires a lot of mental effort. The concept could be difficult to grasp for people outside the field, those who associate work with physical labour — movement, assembly, typing up reports. Though when it comes to writing software, a bulk of effort goes into thought. So much in the same way how one needs to take a break after lifting heavy boxes, it’s also a good idea to give one’s mind a break after a mental workout.

Personally, I like to go outside for short walks.

While distracting yourself with reddit takes one’s mind off actual work just the same, there are a number of additional benefits to going outside:

1. Get some fresh air — the brain is very sensitive to the levels of oxygen. Assuming that the quality of air is actually better outside, it is very refreshing to recharge with a fresh supply.
2. Reduce eye stress — walking away from your screen reduces the stress on your eyes. Preventing the buildup of stress on the eyes is very important for their maintenance.
3. Refresh the mind — when stuck at a problem, going outside puts things into a new perspective, one away from all the lines of code. Sometimes I come up with new ideas to try, but more often I just let my mind drift and sort itself out, in a zen line state.

During one of my work terms, even as a student, I have gotten a few senior developers to regularly join me for coffee breaks across the street from the office. It was a much needed opportunity for the mind to take a break from the programming and refresh itself in the afternoon, so the idea quickly caught on. As an added bonus, we were keeping up with each other’s progress much better than the weekly meetings ever could facilitate.

What do others do to keep their mind from burning out after long programming sessions? Leave a comment!

No related posts.

what commands will i need?

What makes this question silly is that it is asked in “what is the minimum set of a programming language keywords required to complete a task?” type of sense. It usually has to do with some game project, and the student is looking for some “fix it all” type of answers. There isn’t one.

The thing is, computer programming is like LEGO. Having a list of a bunch of different commands is like having a bag of blocks — useless on its own, but with a potential to build something. Advanced commands are like specialty pieces, they can be used to achieve a higher level of detail, but often must be used in a creative way. Though the important point here, is that similar models can often be put together, just out of the basic pieces.

Basic variables, input/output, if statement, and a loop should be enough to do just about everything. Obviously this doesn’t guarantee efficiency, or speed of development, or maintainability. Some students don’t question this though, and blissfully type up 5000 lines of repeated code.

Alright, so a special block would have been useful, but the question is still backwards. A bag of new commands is always followed up with a “what do I do with any of this?” question, leaving the student more confused than before. One can’t just shake a bag of blocks and expect an assembled model to fall out. During the assembly, one needs to know what kind of a block needs to be attached next, and then find that block. Similarly one needs to figure out what task needs to be performed, before searching for a command that performs that task.

So the question is not “what commands will i need?”. It should be “what command performs this particular action?”. One is better off knowing what they are building, rather than shaking a bag of parts without a plan.

No related posts.

I previously mentioned that programming has a handwriting like signature that could be analyzed. This could be matched to the previously submitted programs, but even better — when a program is mashed together out of copied parts, the inconsistencies really show through. It is those inconsistencies in the coding style that easily give away the plagiarism offence.

Function naming conventions. There are different styles to naming functions. Descriptive words, capitalization, use of underscores, use of parameters. Good use of helper methods in some places, but repetition of code in others also signals an inconsistency of function use.

Variable naming conventions. Notice the degeneration of variable naming quality. From PicBackGround to picback — there’s a loss of CamelCase format and descriptiveness, while both variables are used for the same purpose. game/gam — inconsistency in spelling. The use of really obscure variables, such as d is quite a bit off from very descriptive variables, such as the first PicBackGround. Declaration of variables that are never used in the program should also prompt questions.

Comments describe more than code. Same as before, there are obvious formatting styles to comments. Capitalization of words, indentation, use of comment characters. The distribution of comments is also telling — some sections of code could be lacking necessary comments, while others would have more than needed amount of description. The vocabulary, spelling, and grammar used in the comments is also very reflective of the author. “user is playing” vs. “the player lose” should raise flags.

String literals, similar to comments found in code, bring the plagiarism fight back into the realm of the English class. All of the words used in a program, form a sort of an essay. Vocabulary, spelling, grammar, punctuation — it all assesses the author, on a level independent of code, logic, and algorithms.

And more! Outside the scope of this example, there’s also Math, preferences toward some functions over others, structure of logic, algorithms, and other technical details. The point here is simple — don’t plagiarize code, it’s too easy to get caught.

Related posts:

1. Source Control (plagirism) in Education
2. Regular Expression Google Code Search
3. On the use of comments in code