Simple bugs, difficult explanations

I was reading this excellent post from Mark Dalrymple, which links to an older post of his about a bug.

I know these trials of debugging quite well, and his posts reminded me of a particular bug I tracked down a few days ago; it was what Mark would call a “Five-Minute Bug”, but only because at the last moment, I had an epiphany that required so many obscure bits of knowledge that I was shocked I’d seen it at all.

Find the bug:

// MySeparateFile.m
float DoSomethingInteresting(id object)
{
    return 1.0;
}

// MyHeader.h
#define CheckInterestingStuff(object, result) ({ \
    float __value = DoSomethingInteresting(object); \
    NSLog(@"%s", (__value < (result) ? "YES" : "NO")); \
    __value; \
})

// MyFile.m
#import "MyHeader.h"

void Blah(void)
{
    float thing = CheckInterestingStuff(someObject, 1.1);
    
    NSLog(@"%f", thing);
}

This was the output:

NO
240000.0

This made no sense at all. The function clearly returned 1.0, yet the thing variable equally clearly contained 240000.0. Here’s a hint: It’s not a compiler bug, a need for a clean build, anything wrong with the executing CPU, or related to Objective-C in any way.

Figured it out yet?

The key was a compiler warning that fired in the header file. It said “Warning: No previous declaration for DoSomethingInteresting...“, and was truncated there by Xcode. As with so many other warnings, the eye tends to slide right by it. But this was the problem.

Understanding why requires knowing one of C’s odder quirks, a throwback to the K&R days before there were such things as function prototypes. A function without a prototype or explicit declaration is assumed to return int.

With that in mind, the impossible return value suddenly makes sense. The compiler was effectively doing this:

float __actual_value = CheckInterestingStuff(someObject, 1.1);
int __the_compiler_saw_this = *(int *)&__actual_value; // OOPS
float result = (float)__the_compiler_saw_this;

But to know that, you’d have to know about details of how compilers pass and return function results, quirks of the C language itself, and what happens when you pretend a float is a int. These aren’t casual things that every programmer just knows, although they probably should be.

For those of you who know the ABI and are wondering, yes, on various architectures a floating-point return value should’ve been coming from a different register than an integer one. It doesn’t matter; the value is either converted wrong or coming from the wrong place, and either way it’s wrong.

And the moral of the story is, this is why I use -Weverything -Werror when I can.

Twitter just said “stalking is okay by us”

UPDATE: Twitter reverted the change to blocking after the immediate backlash. I’m not the least bit impressed – their post shows no awareness of the problems with their approach, and continues to make the case for letting harassers harass. It’s clear they reverted purely for PR reasons, and I have no respect for that attitude.

My Twitter feed has been abuzz with the comments of people (including friends) unhappy and even terrified by Twitter’s new changes to the “block” function.

A lot of people have replied, claiming that the changes are for the better and don’t change anything. They couldn’t be more wrong.

By changing “block” to “ignore”, Twitter is effectively saying, “if someone’s bothering you, we prefer that you just ignore what they’re saying, rather than making even a minimal effort to make them stop.” As any victim of sexual harassment of any severity, not to mention any child who was ever told “just don’t react to the teasing and they’ll stop”, could tell them, this doesn’t work. It makes the abusers, the stalkers, and the harassers more bold.

Yes, they could still sign out or make secondary accounts to get around the block, but there was at least a first line of defense before. A lot (I won’t say a majority, but in my experience many) of these people will not go to any great effort if you block them, out of laziness or lack of caring. Those who do can be blocked on secondary accounts, and their mischief is limited when they’re not signed in. But now, they’re free to just stare at what you’re doing all the time, and your only recourse is to not be aware that they’re doing it.

Twitter, this is dangerous. It is victim blaming. It encourages abuse, and it apologizes for the abusers. Revert these changes before there’s a story about some poor soul who was successfully assaulted because they thought “block” meant what it said and couldn’t see the warning signs.

For more information and thoughts on this subject, please check Ashe Dryden‘s blog and Twitter feed. No one has said it better than she has, certainly not me.

Full disclosure: I have never been a victim of harassment on Twitter, before or after these changes. But now, if I ever am, there’s less I can do about it.

The OCDepend saga continuums

No, the title isn’t a typo. Kudos to those who get the reference.

I received yet another response from the people at CPPDepend, and this one was both detailed and featured consideration of each of the objections I outlined in my previous posts. I am again impressed with their communication.

While I still can’t recommend the product, I’d like my readers to consider that my lack of recommendation is purely a personal choice on my part not to make use of this kind of tool, and I have no complaints left about their presentation that they haven’t addressed. I haven’t looked at the tool and I’m not qualified to say whether it’s good or bad. In short, I encourage people to look at it for themselves and make their own decision.

Come to think of it, I always encouraged that, I just had a stronger opinion of my own before. I don’t have it anymore, so just in case anyone was crazy enough to listen to me, stop it! :) I’m actually gratified to see a company out there that pays attention to and answers complaints like mine.

Obligatory disclaimer: I have received no compensation, monetary or otherwise, for posting this article, blah blah blah blah blah something something something.

More about OCDepend

A few hours after I posted about the email I got from CPPDepend, I received this response:

Hello,
I read your interesting feedback about our product posted in your blog, and what can I confirm is:

- It's not a spam, this mail was sent to only 3 people, that we consider they have a good Objective-C skill to have their valluable feedbacks.
- You are right some effort must be done for OCDepend in our website.
- Maybe I'm wrong but I dont think that OCDepend features exist in XCode, for example CQLinq is a powerful tool to request code base and enforce its quality.

If you have time to test the product it will help us a lot to improve the product,

Best Regards.

Dane.

Here is my response:

Hi Dane,

Please note, in the interest of full disclosure, that I have also posted this response on my blog for my readers to see.

First, I’d like to say that I’m impressed. Not everyone would bother to take the time to respond to comments like the ones I made, and considering how “form letter” the first email was, I’m doubly gratified to see a personally addressed response the second time around.

I’m still somewhat troubled that the original email read very much like marketing spam. Thank you for contacting me and for considering my opinion valuable, but in my opinion, sending a generic email that doesn’t say anything about why I’m receiving it or give me any sense that it was even intended for me is a very poor way to ask me to review your product. Since you did take the time to respond to me, however, I will offer these additional thoughts:

The value of the pro license you offered in your first email, USD $500, is by itself something I would not recommend to any Objective-C developer in the first place. Mac developers, particularly the smaller ones like myself, are not as used to such high-cost licensing schemes as you’ve probably come to expect from your Windows customers. I certainly wouldn’t consider buying something that expensive unless I had very certain and solid proof that it was going to save me a significant amount of time over the tools Xcode already provides.

Without actually looking at the product itself (and I’ll emphasize to other readers, I have not looked at OCDepend itself and can offer no direct judgements about it), I have browsed your website considerably, and I have to say again: It is entirely lacking. As a developer, I read the phrase “CppDepend and OCDepend are based on Clang for more reliability.” and immediately dismiss it as nonsense. It turns me off, severely so. Basing something on Clang does not intrinsically make it reliable; it only means you have access to the exact same system upon which modern versions of Xcode are built! And Xcode itself shows that it’s extremely possible to be based on Clang and still be horribly unreliable.

Your cited feature that makes OCDepend so much better than Xcode is this “CQLinq” language that allows for querying of my code. To what end, exactly? To “request code base”? Assuming I understand your intended meaning, this means I can get information about my code in query-language form. I presume “enforce its quality” refers to something like putting this query language in a Git commit hook or other such script to check that conventions are being followed. Your website cites CQLinq as being “for maximum flexibility”, which is meaningless if it’s actually your flagship feature; that phrase makes it sound more like an add-on for advanced users. I don’t mean to make light of your English, and if I’m doing so, I apologize, but I can’t see what this feature is meant to do for me. Your website gives the following example:

from m in Application.Methods  
where m.NbLinesOfCode >  30  && m.IsPublic
select m

Which returns all public methods longer than 30 lines of code. So, I have to learn a new domain-specific language applicable solely to your product in order to do something that’s ill-defined at best to begin with. What is a line of code? Do blank lines count? Lines consisting only of an opening or closing brace? Comments? Preprocessor macros? Macros that delete code under certain conditions? To say nothing of the fact that Objective-C doesn’t have the concept of non-public methods.

CppDepend also advertises its ability to compare builds. Any developer who needs to do this is almost certainly already using Git or Mercurial (or some other VCS) to do so for free. For tracking builds in the wild there are such tools as HockeyApp, Crashlytics, and TestFlight. CppDepend’s dependency graphing already exists in Xcode, and quite frankly, most of its other features for code quality look like something of interest purely to managers more concerned with metrics than functionality. No developers with whom I’ve ever personally worked in Objective-C (my personal experience only, that of others will almost certainly differ) have worried about metrics like these. They’re more the subject of The Daily WTF articles!

In summation, from what I can see without downloading your product, I can’t imagine I’d ever give it a second glance. It is obviously true that my experience may be atypical, that there may be much more useful features in your product that are not listed on your website, that I’m simply in a bad mood today, or any number of other explanations for my disinterest. I remain very much open to being proven wrong, and I look forward to that possibility, but as it stands I could not recommend this product to anybody (again, for those others reading, I haven’t in fact downloaded it at all, so take it with a grain of salt). I would see the price tag and immediately veer towards the tools I already have unless yours could quickly and convincingly show me that it was better for the job.

– Gwynne Raskind

A short note on CPPDepend/OCDepend

This morning, I got an email from someone purporting to be from something called “OCDepend”, which turns out to be some kind of tool for using Clang to analyze Objective-C code.

Basically, the static analyzer with a bit of GUI and a LINQ language for looking at your code, from what I can tell.

There’s not a single screenshot of the Objective-C version on their website, and I’m not about to download a tool which:

  1. Is so desperate that they’re sending out free pro license offers to random people with an email form letter in hope of a good blog review.
  2. Has absolutely no documentation on the website, which is purely about the C++ version of the tool for Windows.
  3. Sends the aforementioned email from an address which appears nowhere on their website but at the same time isn’t a personal name; it came from just “developer”@.
  4. From what I can tell, duplicates functionality that’s been built into Xcode for some time now, and provides nothing else beyond a query language for information that Xcode also shows.

I would strongly suggest to these people that they look over their marketing and consider carefully what they’re really providing to their supposed Mac customers before sending out unsolicited emails with bad grammar and poorly qualified From addresses.

P.S.: I looked over the email carefully and it doesn’t appear to just be random spam, but if it is, my apologies to CPPDepend.

P.P.S.: The full text of the email I received, in case someone can tell me I’ve lost my mind and/or am overreacting:

Return-Path: <cppdepend AT gmail DOT com>
Sender: cppdepend AT gmail DOT com
Date: Thu, 7 Mar 2013 14:06:27 +0000
Subject: Managing Objective-C code quality using OCDepend
From: developer <developer AT cppdepend DOT com>
To: REDACTED
Content-Type: multipart/alternative; boundary=f46d0444ee1f73edc604d7563650

--f46d0444ee1f73edc604d7563650
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

I'm Dane the Community Manager for OCDepend Tool.

*OCDepend* is a static analysis tool that simplifies managing Objective-C
code quality and provides a highly flexible code query language. Please
find more detailed features here : *http://www.cppdepend.com/Features.aspx*

I=92ll be pleased to offer you a pro licence, so that you can try OCDepend
and blog about it if you find it useful.

I=92ll send you a pro licence as soon as I receive your confirmation.

Some of OCDepend=92s key functionalities :


   - Code Query language(CQLinq), with visual tools/editors
   - Compare Builds
   - More than 80 Code Metrics
   - Display analysis results in different types of Diagrams
   - Easy integration to Build process
   - Detailed and highly customized reports
   - Facilitate Code Reviews by using Code Change Metrics
   - Visual Editor that gives many views (Code Query Builder, Dependency
   Graph, Matrix and Metrics views ++)


Best Regards!
Dane,
OCDepend Developer & Community Manager.

--f46d0444ee1f73edc604d7563650
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"color:rgb(34,34,34);font-size:13px;backgroun=
d-color:rgb(255,255,255)"><font face=3D"verdana, sans-serif">Hi,</font></di=
v><div style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255=
,255,255)">
<font face=3D"verdana, sans-serif"><br></font></div><div style=3D"color:rgb=
(34,34,34);font-size:13px;background-color:rgb(255,255,255)"><font face=3D"=
verdana, sans-serif">I&#39;m Dane the Community Manager for OCDepend Tool.<=
/font></div>
<div style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255,2=
55,255)"><font face=3D"verdana, sans-serif"><br></font></div><div style=3D"=
background-color:rgb(255,255,255)"><font face=3D"verdana, sans-serif"><font=
 color=3D"#222222"><b>OCDepend</b> is a static analysis tool that simplifie=
s managing Objective-C code quality and provides a highly flexible code que=
ry language. Please find more detailed features here :=A0</font><span style=
=3D"background-color:transparent"><font color=3D"#1155cc"><u><a href=3D"htt=
p://www.cppdepend.com/Features.aspx">http://www.cppdepend.com/Features.aspx=
</a></u></font></span></font></div>
<div style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255,2=
55,255)"><font face=3D"verdana, sans-serif">=A0</font></div><div style=3D"c=
olor:rgb(34,34,34);font-size:13px;background-color:rgb(255,255,255)"><font =
face=3D"verdana, sans-serif">I=92ll be pleased to offer you a pro licence, =
so that you can try OCDepend and blog about it if you find it useful.</font=
></div>
<div style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255,2=
55,255)"><font face=3D"verdana, sans-serif">=A0</font></div><div style=3D"c=
olor:rgb(34,34,34);font-size:13px;background-color:rgb(255,255,255)"><font =
face=3D"verdana, sans-serif">I=92ll send you a pro licence as soon as I rec=
eive your confirmation.</font></div>
<div style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255,2=
55,255)"><font face=3D"verdana, sans-serif">=A0</font></div><div style=3D"c=
olor:rgb(34,34,34);font-size:13px;background-color:rgb(255,255,255)"><font =
face=3D"verdana, sans-serif">Some of OCDepend=92s key functionalities :</fo=
nt></div>
<div style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255,2=
55,255)"><font face=3D"verdana, sans-serif">=A0</font></div><div style=3D"c=
olor:rgb(34,34,34);font-size:13px;background-color:rgb(255,255,255)"><ul st=
yle>
<li style><font face=3D"verdana, sans-serif">Code Query language(CQLinq), w=
ith visual tools/editors</font></li><li style><font face=3D"verdana, sans-s=
erif">Compare Builds</font></li><li style><font face=3D"verdana, sans-serif=
">More than 80 Code Metrics</font></li>
<li style><font face=3D"verdana, sans-serif">Display analysis results in di=
fferent types of Diagrams</font></li><li style><font face=3D"verdana, sans-=
serif">Easy integration to Build process</font></li><li style><font face=3D=
"verdana, sans-serif">Detailed and highly customized reports</font></li>
<li style><font face=3D"verdana, sans-serif">Facilitate Code Reviews by usi=
ng Code Change Metrics</font></li><li style><font face=3D"verdana, sans-ser=
if">Visual Editor that gives many views (Code Query Builder, Dependency Gra=
ph, Matrix and Metrics views ++)</font></li>
</ul></div><div style=3D"color:rgb(34,34,34);font-size:13px;background-colo=
r:rgb(255,255,255)"><font face=3D"verdana, sans-serif"><br></font></div><di=
v style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255,255,=
255)">
<font face=3D"verdana, sans-serif">Best Regards!</font></div><div style=3D"=
color:rgb(34,34,34);font-size:13px;background-color:rgb(255,255,255)"><font=
 face=3D"verdana, sans-serif">Dane,</font></div><div style=3D"color:rgb(34,=
34,34);font-size:13px;background-color:rgb(255,255,255)">
<font face=3D"verdana, sans-serif">OCDepend Developer &amp; Community Manag=
er.</font></div></div>

--f46d0444ee1f73edc604d7563650--

Getting rid of old certificates in Xcode

Xcode 4.x’s Organizer window has an annoying habit of not only keeping old certificates (whether expired, revoked, duplicated, or otherwise redundant) around, but also restoring them every time you try to delete them. There’s no interface in Xcode for removing these extraneous identities and nothing sees to work for getting rid of them. Here’s what I originally tried, more or less in order and starting from the beginning with another step added every time:

  1. Deleting certs and keys from Keychain Access
  2. Deleting certs and keys with the security command
  3. Restarting Xcode
  4. Restarting computer
  5. Ditching ~/Library/Caches/*{Xcode,Developer}*
  6. Ditching ~/Library/Preferences/*{Xcode,Developer}*
  7. Ditching ~/Library/Developer (while saving only my keybindings and font/color settings)
  8. Removing all archives from the Organizer
  9. Grepping my entire home directory for the certificate name (four hours taken)
  10. Grepping my entire computer for the certificate name (2.5 days taken as I couldn’t figure out a command that excluded sending it down several recursive directories that led back to / – I could’ve, but I was lazy).

I finally ferreted out the final hiding place of Xcode’s ridiculous cache of certificates in /var/folders/<some random alphanumeric characters here>/com.apple.{dt.Xcode,Xcode.501,Developer} (or something very similar). When I deleted that and all of the other things mentioned above, the offending/offensive identities finally vanished.

tl;dr: To make sure you’ve really killed Xcode’s cache, make sure you clear out the area Apple deliberately made hard to find and set as $TMPDIR as a so-called security measure.

OS X Internals

It’s been pointed out to me recently that my blog has nothing at all on it about my work on the book Mac OS X Internals: A Systems Approach, by Amit Singh. So, here’s all the info I have that I can give right now, in the form of a FAQ:

Is it true you’re updating the book?

Yes. As of November 2012, I was contracted by Pearson to author a second edition of Mac OS X Internals, which in keeping with Apple’s change in naming, will now be titled “OS X Internals: A Systems Approach”. A big shout-out and thanks to Michael Ash for letting me guest-write on his blog and to Kirby Turner for putting me in touch with Pearson!

What is the release date?

Update: It’s taking quite a while to get this book into its proper shape. I’m sorry to everyone for the delays, but it’s important to make it the best reference it can be in an era when the material can change faster than it can be written down. My current target for release is late 2014 – as always, this is not a promise; only a guess.

At this time, I have no solid release date to offer. My best guess for a release is late in 2013.

Are you working with Amit Singh on the second edition?

No. To the best of my knowledge, Amit is not involved in the second edition in any way as of this writing. Should he change his mind about having a role, I will be nothing but grateful for his help!

Are you working with anyone else?

Update: Yes! As of September 2013, Sam Marshall has signed on to co-author the book with me. His enthusiasm for the project is as great as mine, and I hope to bring you an even better book with his help!

Not at this time.

Will the second edition contain information about iOS as well?

Yes, I am planning to include information on iOS. Some details of iOS’ implementation are, of course, internal to Apple and unavailable, but I will be adding as much public information as I can.

Will the second edition cover the latest OS releases?

Update 2: As time moves forward and more possible OS releases come forward, a more generic answer is needed to the original question; see the (edited) original answer below.

Update: Yes!

I will do my best to include any changed information from any OS versions which are publicly released before the final manuscript delivery date. I can’t make any guarantees, and due to NDA restrictions, I can not include information on versions which are still in beta at the time of delivery.

If I’ve left out anything, don’t hesitate to shoot me an email and ask!

Rant: Security Questions Are Stupid

We’ve all heard this bit before, especially the avid readers of Bruce Schneier’s security blog, but after seeing the security questions available on a new account I created today, I just had to do my own rant.

Security questions are considered by some to be a form of “two-factor authentication”. They’re no such thing. If used to further secure login, they’re just an extra password which is almost guaranteed to be much more guessable than your usual password. If used to recover a lost password, they function to replace your password with something almost certainly less secure.

Some suggest giving nonsense answers to security questions for this reason. Of course, then you’re back where you started: You’ll never remember your answers. That’s when you could’ve remembered your answers if you answered them honestly, which is often just as impossible. And now we’re back to writing it down on paper, which negates the entire point.

Yet these stupid things are required on a majority of secure sites now. Can security auditors please stop trying to please their clients and tell them the truth about how security questions just make things worse?

The questions which prompted this rant:

  • “What was your favorite color in elementary school?” – Now, let’s assume I remember that time of my life in the first place. At which point in elementary school? Let’s say I just pick one, and let’s even more fantastically say I somehow stick to remembering which one. Most children will have said one of the colors of the rainbow. Say it with me now… “Dictionary attack”!
  • “What is the nickname of your youngest sibling?” – Suppose I don’t have any siblings. Suppose I am the youngest sibling. Suppose my youngest sibling doesn’t have a nickname. And even aside from all this, names suffer from relatively low entropy, though admittedly not as low as colors.
  • “What was your first job?” – Have I ever had a job? Am I young enough that I remember exactly which thing I did first? Do I count doing chores as a child? Do I count shoveling snow for my neighbors? Do I count internships? How do you define a “job”?
  • “What breed of dog was your first pet?” – I’ve never had a dog as a pet in my life. And that’s even after the assumption that I have a pet at all. If I did, was the first one a dog, and did I only get one dog at that time? By the way, the entropy of dog breeds is even lower than that of colors when you include all colors.
  • “What is the nickname of your oldest sibling?” – See youngest sibling.
  • “What is the name of your first pet?” – Again, suppose I have no pets. Suppose my “first” pet was one of a group. Suppose I picked an arbitrary one out of a group. Also, low entropy again.
  • “Who was your childhood hero?” – What constitutes a hero? Suppose there wasn’t someone I looked up to in childhood? Suppose there was more than one? Suppose I just don’t remember? And the entropy of a hero’s name is likely to be rather lower, on average, than that of a regular name.
  • “What was the model of your first car?” – Where do I even begin here? Did I ever own a car? Am I even old enough to drive? Do I remember its model? Do car models have any kind of entropy at all?
  • “What was the name of your earliest childhood friend?” – I had lots of friends as a child. Didn’t everyone? Suppose, more morosely, that I had none. Am I going to know which one was the earliest? And yet again, the low entropy of names.

Now, I grant, most of these are pretty silly nits. They don’t have to be accurate answers, just ones to which I can remember the answers consistently. Unfortunately, the more likely I am to remember the answers, the less likely they are to be remotely secure passwords.

Password strength doesn’t count when the answers are only one word long and chosen from a limited pool, people.

Objective-C and the Web

Earlier today, courtesy of @GlennChiuDev, I was reading Kevin Lawler’s informal tech note about using Objective-C to power the Web. I found myself agreeing with quite a lot of it.

I then had the chance to read @heathbordersresponse to the original post, which I realized I was also agreeing with in considerable measure.

So here’s my response to both. I’ve assumed that readers have at least skimmed both the original post and the response so that I don’t have to do what Heath did and duplicate everything they said here :).

Kevin makes the point that Apple has hugely improved Objective-C in recent times, especially with the most recent releases of OS X and iOS. Heath objects that while Objective-C has certainly improved, it’s still a strict superset of C and comes with all of C’s well-known and discussed-to-death problems.
While I agree with every one of Heath’s list of issues with Objective-C, my thought is that everyone works best in whatever works best for them. Some people (myself included) are going to be more comfortable in a bare-metal-with-extensions language like Objective-C, while others are never going to enjoy it in comparison to Java. It’s a personal thing, and I’d argue that a programmer who doesn’t like Java, for whatever reason, will never save time in it no matter how many conveniences it provides over Objective-C. Heck, I get plenty of scripting done in PHP even though I agree that Python and even Ruby have enormous language advantages and that PHP has severe community and design issues, because I’m extremely familiar with it.

Kevin goes on to say that Java was meant to be a write-once run-anywhere language but failed at it, and Heath counters by pointing out that Java does indeed do this.
This isn’t really a simple argument in either direction. Java was indeed intended as write-once run-anywhere, but while Java CLIs and servers do fulfill this promise for the most part, I think Kevin was thinking (as I did at first) of Java GUIs. To a one, I have never met a Java GUI I like, on any platform. Java apps look and act horribly non-native on OS X, are slow (and odd-looking, if less so) on Windows, are just as clunky as everything else on X11 (my personal opinion of all the X windowing toolkits is that they all stink), and as for Android… well, I don’t like Droid, and even that aside, Java working “right” on one platform is the exact opposite of the promise. In that respect it might as well not be any different from Objective-C in its platform dependence.

I do have to agree with Heath and disagree with Kevin regarding writing portable C/C++ being easy. Even if you use only POSIX APIs exclusively, which will severely limit your functionality in the general case, this is a nightmarish undertaking. Even if you restrict yourself only to Linux variants, nevermind trying to work with all the other UNIXen, OS X, and Windows, it’s all but impossible without a complex system like autoconf (which is another entire rant about horrible garbage in the making).

With regards to the JVM, I have to agree with Heath again: The JVM is absolutely a useful UNIX system layer, and JIT does make it a lot less slow than Java used to be. Similarly with garbage collection; GC is an abomination in C and Objective-C, but that’s because the design of those languages precludes the collector having full knowledge of what is and isn’t a live object without very restrictive constraints. In a fully virtualized language like Java or C#, properly implemented garbage collection is absolutely a useful technology.

I can’t say much about Java re: Oracle, since I don’t know much of what really happened there, but just from reading the respective posts, I have to say Heath makes a more persuasive argument than Kevin’s declarative statements.

Kevin then goes on to say that object-oriented programming is a win over functional programming, and Heath objects, saying that there are a great many people who disagree. In this case, while I personally agree with Kevin in my own work, this is another area where personal preference and training will trump blanket statements every time.

Kevin also talks quite a bit about Automatic Reference Counting (ARC); Heath didn’t respond to this section. I find ARC an absolute divine gift in Objective-C, but all ARC does is bring the syntax of GC to a non-GC environment, and in an incomplete fashion: The developer must still be careful to avoid retain cycles with weak references and explicit nil-ing of strong references.

Kevin goes on to talk about Apple’s failed WebObjects project. He gives some reasons and thoughts about Apple moving Objective-C to cross-platform deployment. He seems to be unaware of GNUStep, ObjFW, and other similar projects, but setting that aside, I absolutely agree that Apple bringing the full Objective-C runtime, including most if not all of Foundation, to a wider UNIX base would be spectacular. Reviving and expanding the former OpenDarwin project would also be awesome, in my opinion. In this, I’m completely on Kevin’s side; this should happen and he lists several good reasons for Apple to do it.

Now Kevin goes on to say what is no doubt the most controversial thing in his entire post: “Xcode is an excellent IDE, with tolerably good git support.”

Like Heath, I must say: This. Is. Patently. False.

Xcode 3 was a tolerably good IDE, absolutely. Not modern or fully-featured by any measure, but fairly decent. Xcode 4, however, is a crock of <censored>. I’ll let Heath’s response speak for me on this for the most part, but I’d like to add that Xcode’s git support is also absolutely abysmal. Worst of all, there’s no way to shut it off, even if you never told Xcode that the project had a git repo.

So to summarize, what Kevin seems to have posted is a rant about his issues with functional languages and Java, and his love for Objective-C, without a lot of facts to back it up. I’m strongly in agreement with his feelings on most points, and I totally agree that Objective-C would be an awesome language for Web programming, but I suspect Apple hasn’t gotten into the field exactly because Java isn’t the terrible beast he made it out to be. This is a shame, to be sure.

As a footnote to those who still follow this blog hoping for a post on this subject: Missions of the Reliant isn’t dead! I’ve been pretty busy for a long time, but I will find time to work on it!

A potential direction for Objective-C

As with my Xcode rant, this is a modified version of a mail I sent to an Apple mailing list, in this case objc-language:

I agree that adding an === operator to Objective-C would be, at the very best, questionable at this late date, if indeed it was ever anything else. My experience in PHP has been that the two are very often confused and misused, and I can’t see that being any different in Objective-C.

I do strongly support the concept of @== and @!= operators that equate to [object isEqual:] and its negation, as well as the associated @<, @> etc. operators. If one of the objects in question can be determined not to implement compare:, throw a compile error. If either operand is typed id, throw a runtime exception, exactly as [(id)[[NSObject alloc] init] compare:] would do now. In short, make the operators mere syntactic sugar, just like dot-syntax and the collection literals, rather than trying to toy with the runtime as @"" does.

This is not “arbitrary” operator overloading, as with C++. That would be an absolutely abhorrent idea, IMO. Define new, unambiguous operators and make it very clear exactly what happens when they’re used. Don’t make it possible to change that behavior from affected code. Add a compiler option or ten so you can do -fobjc-compare-selector='myCompare:' or what have you (as with the one for the class of constant strings), but that’s all.

I understand people who complain that Objective-C is getting “too big”, but the fact that the collection literals were implemented (yay!) makes it clear, as far as I’m concerned, that it’s understood that the language is just too verbose (and difficult to read) as it stands. Adding a new set of clear, intuitive operators would not detract from its usability. People who don’t know enough to write @== instead of == were already going to write == instead of isEqual: anyway, as a rule.

My Xcode rant

It seems everyone who develops for OS X or iOS these days has their own rant about the problems with Apple’s development environment, Xcode. Well, here’s mine, excerpted from a message I sent to the xcode-users mailing list.

Xcode 3 was getting pretty good for awhile, but then Xcode 4 was released, a massive backwards step in functionality which has only been getting worse with its point releases. I have suffered, shockingly, very few of the crashes and data loss bugs which other people have been plagued with, but I have plenty of gripes just the same.

Xcode 4′s integrated layout may look good on paper, and even work better for some people, but for others it’s a hopeless struggle to manage screen space and get a consistent workflow going. Xcode 3′s ability to pop open and then close the build progress window was delightful; with Xcode 4 I just get the build log in my editor pane without being able to see the code I’m working on. Ditto that the IB integration into Xcode; with a windowed layout that would have been tolerable, but as it is I spend considerable time just going back and forth between interface and code views to see what the heck I’m doing – and no, tearing off Xcode 4′s tabs doesn’t make it better, because that has a near-100% tendency to completely destroy my window position and layout settings. Xcode 4 took away the class hierarchy view. It took away the ability to compile one file at a time. The integrated debugger console is painful and takes away from code editor screen space. Workspaces are just plain broken and do not work as advertised. The configuration editor is a step up, but unfortunately the “scheme” concept is a two steps down. Switching between Debug and Release should not require chugging through three settings panels to find the right switch. And don’t talk to me about the inability to shut off Git integration on a per-project basis (or, for that matter, at all). Why can’t I enable Guard Malloc or change the debugger used for unit tests? Why am I sacrificing valuable screen space (and I say that having a 27″ screen, fully aware that people are doing dev with Xcode 4 on 11″ Macbook Airs) for an iTunes-like status display when Xcode 3′s status bar was just as useful?

And Xcode 4 itself is, as a whole, sluggish in every respect. Operations of all kinds, from editing text to creating connections in IB to switching between code files, which were perceptually instantaneous in Xcode 3 take visible time in 4. Even those 200 milliseconds here and there add up to an overall feeling that I’m spending more time waiting for my development environment to catch up with my thinking than I am actually writing code. Yes, it’s very nice that the debugger console and utility panels slide neatly in and out with smooth animation, but I’m a developer; Apple doesn’t have to market eyecandy to me. I’d strongly prefer instant response. And all I get for all this trouble is ridiculously bloated memory usage forcing a restart of the program every several hours of serious work.

Before anyone asks, yes, I’ve filed several Radars. All have been closed as duplicates (which means I’ll never hear anything about them again) or ignored (same result). The impression I get from Apple is that they think that they have enough people who build their livelihoods on the iOS ecosystem that they don’t have to put any effort into improving the tools for those who give a darn about a time when writing code wasn’t an exercise in stockpiling $20,000 for a tripped out Mac Pro whose stats can compensate for Xcode’s flaws.

Some other good examples of the problems people have with Xcode:

Missions of the Reliant: Back on the Radar!

It’s been a long time since I made any meaningful posts about Missions of the Reliant, but here I am at last to tell you all that I haven’t abandoned it! First before anything else, thanks to everyone for your exemplary patience with me over the last year or so with no word.

Coming back to the code after all this time and with the experience hard-won in other code, I can see that in the past I was both absolutely brilliant and somewhat stunted :). However, most of the issues that I see have more to do with the code having been originally designed when Leopard was the latest and greatest OS; the technically inclined among you will remember with horror the days of no libdispatch, libcache, libclosure, ARC, or ZWRs. I say without shame that a lot of problems I’ve had (and a few that still exist) would never have happened if I’d had ARC to work with from the beginning.

This brings me to the secondary point of this post – Missions will be the better (and the more quickly completed) for an ARC migration. ARC is supported on Snow Leopard, but one of its most powerful features, Zeroing Weak References, works only on Lion. I had this same debate when SL itself came out, and I’m faced with it again: Am I comfortable with limiting Missions to working only on Lion?

So here I am, asking for the opinion of the loyal followers of this project again, with it kept in mind that I’m working on the code either way: How many of you would be left out by a Lion requirement? (And, more amusingly, how many of you would upgrade to Lion at last just to play!? :)

I’d like to say thanks again to everyone who’s bothered themselves keeping up with my near-silence over the time since I started working on this port. I’ll post again as soon as I have the project building in Xcode 4 (yes, it’s been so long since I touched it that I have to retool it for a whole new Xcode version!). Until then, happy space flights to you all!

Guest post on Michael Ash’s blog

I am honored to announce that I’ve done a guest spot regarding assembly language on the blog of well-known Mac developer Michael Ash. You can find my post at his blog. I highly recommend every one of his posts for OS X and iOS developers of all kinds. Thanks for the opportunity, Mike!

Markdown is cool

I have discovered that the minimalist markup language known as Markdown is absolutely awesome. Why? Because it’s utterly simple, utterly expressive, easier to type than HTML, and works spectacularly in TextMate.

That is all.

For those of you who are still hoping for Missions of the Reliant news, I want you all to know I have not forgotten or abandoned the project. I will come back to it, hopefully someday soon. I thank all of you who remain from the bottom of my heart for your incredible patience, and hope you’ll bear with me just a little longer!

Missions of the Reliant: Happy Belated Anniversary, Reliant!

The one-year anniversary of the project to port Missions to modern Mac OS was one week and 5 days ago. I’m sorry I missed it, but as always, life puts a heck of a damper on the fun we want to be having. Still, I’ve got a few extra minutes to spend on it, and in the last few months I’ve learned a lot of new things. One of them is that having a plan is almost always a good idea! So as gift and apology, here’s the plan for the present and future of Missions of the Reliant!

  1. Because I haven’t worked on the project in a while, and because the time I’ve spent in iOS has taught me a great deal about proper Cocoa programming and OpenGL, my first action in returning to the Xcode project titled “Missions” will be to go through the game’s subsystems and fix some of the rather basic mistakes I made as a less experienced coder. This includes such things as the use of VBOs in OGL, unification of the disparate “node” classes into a proper hierarchy (eliminates an amazing amount of duplicated code), replacement of some of the things I hand-crafted (such as audio file access) with third-party libraries (since the ones I’ve investigated invariably did better at what they were meant for than my efforts), and possibly an even more general refactoring if I decide it’s necessary (a decision which pends further review).
  2. After that comes completion of the missing gameplay functionality. I don’t at this moment have a decent list of what’s missing available, but the stuff that comes to mind are most of the computer functions and the enemy AIs. Once all of that is done, the lot of it has to be tested to make sure I didn’t miss anything above the level of fine details. This leads up to…
  3. … The storyline, the literal “missions” of the Reliant! Those of you who played the original game (almost all of you, I’m sure) will remember that Mike provided three of them – invasion, rebellion, and time travel. These require tying together all of the gameplay elements in their proper linear fashion, which may sound simple, but this is one place where the mass of spaghetti in the original source code isn’t nearly so sad to look at (with, as always, apologies to Mike), because that was the only way to do it without OO features at least as advanced as Objective-C’s.
  4. At that point, the game will be ready for beta testing, and a 1.0 release. Said release will of course be freeware, and I plan to distribute through the App Store as well as on my Web site. I plan to ask Mike for suggestions on how to handle beta testing, but I tentatively plan to open it up to, at the very least, to everyone who subscribed to the mailing list.
  5. With 1.0 behind us, there will still be plenty to do. The game in that state will not be a direct port, and just won’t provide the sense of nostalgia I suspect many of you are, like me, hoping for. There are too many new features and changes in the interface. Some of them were my creativity getting the better of me, some were just inevitable moving between two completely different operating systems and programming languages across a gap of more than a decade. I plan to make a 1.5 (or whatever!) release which provides a “classic gameplay” mode, wiping out all the new features and restoring as close to the original exact interface behavior as possible. User feedback may, of course, convince me that this would not be worth the effort, but that’s something to think about at the time, not now.
  6. Finally, I never saw Missions as a static game. Mike released it as such because, among other things, that was the only kind of game we had back in those days. But just like Kirk and the Enterprise had lots more adventures after the original series, so can this game have more episodes. My vision is of downloadable content, and even a scripting interface so anyone can make new episodes for the game. This is a project almost as large as the game itself, and is another thing to possibly set aside based on the feedback of players, but it’s something I would certainly enjoy doing.
  7. Even further in the future, perhaps a 3D engine and models? The sky’s the limit! But let’s not get ahead of ourselves. At that point we’re talking about an entirely new game, practically an MMO if one takes the thought far enough, and that’s pretty silly if you look at it from right now. It might not be later!

I hope it’s obvious that I’ve put some thought into all of this. I still won’t have a lot of time to work on the game, but any is more than the none I’ve had lately, so expect to see updates coming again.

As always, my deepest thanks go out to you all for your patience as I’ve struggled my way through this project, and I’ll continue to do my best not to disappoint.

P.S.: I have considered making the game require Snow Leopard to play. It’s been long enough since its release that this might not be a bottleneck to most people, and it would considerably simplify some of the code; Apple added quite a few nice things to Cocoa only that recently. Please leave some feedback on this thought in the comments or on the mailing list!

Missions of the Reliant: Broadcasting distress call.

At the suggestion of Jude, seconded by none other than the man himself, I’ve created a mailing list for announcements and discussions about Missions of the Reliant.

Unfortunately, I’m a bit of a newbie when it comes to mailing lists, and I had to settle for a Google Group for simplicity’s sake: http://groups.google.com/group/missions-of-the-reliant. It’s members-only, but anyone can subscribe. Please feel free to sign up and comment; it’s open for discussion as well as news :-).