Tag Archives: Programming Languages

Chapters Trip

It’s been a while since I’ve done a post that’s not completely dedicated to my engine project, so this is a nice change. ūüôā At the end of the last school year, I was awarded a¬†Chapters¬†(the Barnes and Nobles of Canada)¬†gift card for being the top in my physics class. I finally got around to spending it today while out buying some other stuff for university.

I wasn’t really sure what type of book to get. I don’t read very often, and since there are still a few fiction books at home I’d like read I decided to look for something non-fiction. I ended up taking a look at the “Computing” section just to see what was there. My expectations weren’t very high, as most general book stores only stock titles like The Complete Guide to¬†OS X Lion, Microsoft Access 101¬†and, of course,¬†The Internet for Dummies. This Chapters was different.

There was about a third of a shelf devoted to various iOS programming guides, ranging from Cocoa programming to interface design. And¬†surprisingly enough there was an Android section too, which certainly wasn’t small either. I browsed through the entire selection of developer-oriented books and was almost going to go with a book on Perl, but I decided to get a Python 3 book instead.

I’ve used Python 2.x before in the past, but I’ve never sat down and actually learned about the details on the language or how to use it to its¬†potential. Sort of like learning French for two years in a classroom and knowing a few verbs, nouns and adjectives I guess. In either case, I’ve always been a fan of Python and since it has so many practical applications it won’t hurt to become more familiar with it. I will need to add scripting support to my game engine at some point as well, and since I’d most likely have used Python regardless of my Chapter’s trip this will definitely help.

I also bought a new Rubik’s cube, since the book was less than my gift card’s value. I’d like to do some statistics/experiments with different solution patterns, but it’ll have to wait until I can get my solve times down into the sub minute range again. I used to be able to solve a cube in less than a minute back in grade nine, but my cube broke around the end of that year and I haven’t had one since.

I’m off to start reading my new book, so that’s all for now!



Top 5 Annoyances in Objective-C

I recently got into iOS programming after purchasing my first iPhone a few months ago (iPhone 4). As a result, I’ve also had to learn to use Xcode and Objective-C. Previously I’d only used Eclipse as my development IDE, since I only really did Java programming on the Mac. As neat as some of Objective-C’s features are, there are several things that bother me when using the language.


5. What’s up with the boolean type keywords? Why do you need¬†YES, TRUE and true? Why not just stick with the standard true¬†and false, instead of adding all these other ones? And they all mean the same thing, of course, because a boolean is a boolean. I guess the thinking behind it is that using¬†YES¬†might make the language feel more “Englishy”, but who knows. Same goes for having bool and BOOL, and nil and NULL. Just pick one and use it.

4. One of the things I disliked about Java was that the file name and the contents of the file had a definite link. If your file is called MyFile.java, the public class inside is required to be named MyFile. With C++, you’re not bound by any such rule and for the most part you aren’t with a Objective-C. Except, if you want to include C++ code in Objective-C, you have to change the file extension.What the hell?

3. Inconsistent/superfluous use of the ‘@’ symbol. Not only is the ‘@’ symbol used to denote an Objective-C String, it’s also prefixed to the interface, property, synthesize, etc keywords. And it’s also to denote the object replacement code for strings (“%@”). Now, I totally get the need for it on the strings, since something has to be used to distinguish between C-strings and Objective-C strings. This makes sense. The use as a replacement tag is also not that bad, and if the language designers had stopped there this item wouldn’t be on the list. But why use it on stuff like interface? In C++ you don’t say @class, and in Java there’s not an¬†@class or @interface keyword. And, if sticking a random character on the front of keywords is so important, why not use the hash (#) sign? That at least shows some consistency. The¬†preferred¬†format would be to just get rid of the damn symbols though.

2. The lack of¬†operator overloading. This kinda goes hand in hand with the next one, but this is definitely something I miss and I’m surprised is missing. There might be some language design reasons why this was not included, I don’t know, but it’s bothersome.

1. And lastly, where the hell is the string concatenation operator? This should be part of every language. I’m used to being able to do something like:

“My number is: ” + mSomeNum + ” and my name is: ” + mMyName;

in Java. Programmers stick strings together quite often, so it makes sense to have something short and sweet. Not to mention the fact that the ‘+’ sign universally translates to “add these things together.” However, in Objective-C we get to do this:

¬†[NSString stringWithFormat:@”%My number is: %i and my name is: %@”,mSomeNum,mMyName];

It makes understanding the block of code much harder, not to mention requires more typing and more linespace. It sucks a lot, and I cannot think of a good reason for forcing it on developers.


JMorse Part 1 – A Crack at the Rules

As mentioned in my previous post, I decided to actually try going down the route of mixing Morse Code and programming. The first step in doing this was coming up with a few rules to write programs in Morse code. The easiest way to get started was to use standard Morse letter sequences, and then fill in any characters that were missing, e.g. ( ) [ ] { } ; ” “. This gave me:

Morse Code

To make parsing easier/possible, I came up with a few spacing rules as well. A single space, ” “, is used between characters in the same “word”. A double space, ” ¬†“, is used to represent the access operator, in Java’s case this would be the period. Finally, a triple space, ” ¬† “, is used to indicate the gap between two words. If any of that is confusing it’ll make sense in a minute with the code snippet.

To start with, I wrote a very simple and cliche “Hello World” in Java, and then encoded it into Morse. The original program looked like this:

Java Hello World

And encoded in Morse I ended up with this abomination:

Java Morse Code

Two things became clear pretty quickly while writing the above program. The first was that as more non-alphanumeric symbols are needed, the more complex the morse equivalents are going to become. I still need =,+,-,/,*,%, the logical and bitwise operators…To fit them all into the Morse code set I’d probably have to extend out to a length of 6 dot/dashes for some cases. This would become very yucky very fast.

The second problem is Morse doesn’t allow for capital and lower case letters. You more or less have to pick one and stick with it. This is a pretty big problem as I’m a strict follower of camelCase-style naming conventions and Java’s standard libraries are loaded with mixes of upper and lower case. The only solution to this that doesn’t require an additional 26 Morse codes adding a “shift” character that has to be prefixed to any character that needs to be in upper case. That would be a bitch.

So where does this leave us? I can’t help but feel that there’s got to be a better way to go about doing this. I know the original intent was to use strict Morse Code compliant characters to write programs, but retrofitting the¬†necessary¬†characters into the existing codeset is brutal. As I see, there are two options left:

1. Use morse of the letters only, and retain existing “punctuation” using Java’s traditional symbols ()[]{}””,;. etc.


2. Start from scratch and design a new variant of Morse Code that’s optimized for programming. Rather than having “e” as “.”, maybe “.” could be the period symbol that it appears to be. And curly braces could be “-.” and “.-“, and so on.

I’ll have to think about this some more, but I think number 1 is looking a bit more appealing. The problem with number 2 is that it feels like I’m just rewriting ASCII, albeit a more reduced version of ASCII. Number 1 retains the Morse Code feel and will require far fewer additions to the original codeset.

That’s all for now though.


%d bloggers like this: