Honeymoon's over
Apr. 28th, 2010 06:21 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
rbandrewsI've been coding in Objective-C (everyone else uses the dash, so I'll start) almost every day for a couple weeks now. I can still only draw rectangles, but I can fill them, erase them, and change the background color, too.
The main thing I've been doing is trying to make my code small and pretty, like Ruby has taught me code should be. It's not so easy.
I thought that the main sources of verbosity would be memory management (retain and release) and loops (since Ruby uses blocks). These are actually not so bad: memory management adds a total of two lines to my code, since I only need to care about managing my one C structure. Objective-C objects are all garbage collected. Loops aren't too bad, because there's a foreach construct, which is really no wordier than Ruby's.
No, the problem is error checking.
See, it works like this: it's disastrous if the commands coming in don't match what I'm expecting, like if I expect the name of a shape and get some completely different thing. So, at every step, I have to check that everything's still as expected, and print out an error message if it isn't. The traditional C way to do this is return error codes, so every time you call a function, you check the return value and see if anything went wrong. The code ends up looking like this:
After a while, the simplest things get pretty long. Modern languages, including Objective-C, have a construct called "exceptions", whereby you can raise an exception which gets handled previously on the call stack. So, I can have a function that reads in a command and passes control to a more specialized function, and then receives (and handles) any errors that get raised. If it can't create a shape, then getShape raises an error and the stroke() function never has to care.
Unfortunately, it's very difficult to do this right when you have to give really good, descriptive error messages (which, given the purpose of Scribble, is pretty well required). I'm going to switch the app to using exceptions, but I'm not sure how much the errors will suffer.
There are some other minor annoyances, too: it doesn't look like much thought was given to making it easy to write; getting values out of arrays (for example) is pretty verbose:
As I go along, I'm trying to write it as elegantly as possible, so even though I've added very few more features, I've done a lot to reorganize the code. Eventually I'll hit the sweet spot where writing an individual command is only a couple or three lines, and then I should be able to knock out the rest of the commands easily.
The main thing I've been doing is trying to make my code small and pretty, like Ruby has taught me code should be. It's not so easy.
I thought that the main sources of verbosity would be memory management (retain and release) and loops (since Ruby uses blocks). These are actually not so bad: memory management adds a total of two lines to my code, since I only need to care about managing my one C structure. Objective-C objects are all garbage collected. Loops aren't too bad, because there's a foreach construct, which is really no wordier than Ruby's.
No, the problem is error checking.
See, it works like this: it's disastrous if the commands coming in don't match what I'm expecting, like if I expect the name of a shape and get some completely different thing. So, at every step, I have to check that everything's still as expected, and print out an error message if it isn't. The traditional C way to do this is return error codes, so every time you call a function, you check the return value and see if anything went wrong. The code ends up looking like this:
shape = getShape(command);
if(!shape){ error("Expected a valid shape in %@", command); return; }
color = getColor(command);
if(!color){ error("Expected a valid color in %@", command); return; }
// repeat ten times for every aspect of the commandAfter a while, the simplest things get pretty long. Modern languages, including Objective-C, have a construct called "exceptions", whereby you can raise an exception which gets handled previously on the call stack. So, I can have a function that reads in a command and passes control to a more specialized function, and then receives (and handles) any errors that get raised. If it can't create a shape, then getShape raises an error and the stroke() function never has to care.
Unfortunately, it's very difficult to do this right when you have to give really good, descriptive error messages (which, given the purpose of Scribble, is pretty well required). I'm going to switch the app to using exceptions, but I'm not sure how much the errors will suffer.
There are some other minor annoyances, too: it doesn't look like much thought was given to making it easy to write; getting values out of arrays (for example) is pretty verbose:
[someArray objectAt: index]. Hashes are [someHash objectForKey: key]. It follows the "no magic" principle, which I like, but it's wordy. I'd prefer something like [someArray at: index] or even [someArray: index], with identical syntax for hashes. Having to declare all new methods in separate files is a pain as well; I'd like it if calling a method declared in the same implementation file (but not in the header) didn't generate a warning.As I go along, I'm trying to write it as elegantly as possible, so even though I've added very few more features, I've done a lot to reorganize the code. Eventually I'll hit the sweet spot where writing an individual command is only a couple or three lines, and then I should be able to knock out the rest of the commands easily.
