How Does Adam Make Us Sinners?

June 19, 2011

I ran across Romans 5:19 today, and I think it may be one of the clearest verses for understanding the doctrine of original sin.

Romans 5:19—”For as by the one man’s disobedience the many were made sinners, so by the one man’s obedience the many will be made righteous.”

The context is that Paul is contrasting Adam’s disobedience, along with the condemnation and death that resulted, with Christ’s obedience, along with the justification and life that resulted. But this verse says something even more specific. The word translated “so” in the ESV is two words in the Greek: οὕτως καὶ. The latter simply means “and,” and the former means “in the same way.” So a more literal rendering could be:

“For as by the one man’s disobedience the many were made sinners, IN THE SAME WAY by the one man’s obedience the many will be made righteous.”

The point is that the means by which we are made sinners by Adam is the same as the means by which we are made righteous by Christ.

So does this teach original sin? One could propose that the way Adam makes us sinners is by his bad example that we follow. If that was the case, then Romans 5:19 would say that Christ makes us righteous in the same way: by giving us a good example to follow. And this is more or less what Pelagians have taught. But Romans is absolutely clear that the means by which Christ makes us righteous is not his good example, in many places, but particularly in 4:3-5:

Romans 4:3-5—”what does the Scripture say? Abraham believed God, and it was credited to him as righteousness. 4 Now to the one who works, his wage is not credited as a favor, but as what is due. 5 But to the one who does not work, but believes in Him who justifies the ungodly, his faith is credited as righteousness”

Righteousness is not first produced in believers. First, it is credited/accounted/imputed to them. They don’t have it inherently to themselves, but it is credited to their account.

So if Romans 4:3-5 teaches that Christ makes believers righteous by crediting them righteousness, and Romans 5:19 teaches that Christ makes righteous the same way Adam makes sinner, then Adam must also credit people sin. The means by which Adam makes people sinners is by crediting them the sin that they don’t yet have, but that he has.

What if someone objects that they don’t accept that Romans 4:3-5 teaches imputation, and that they still insist on taking the verse to mean that Adam makes sinners only by example? If that was the case, then by Romans 5:19 Christ would make people righteous only insofar as being a good example for them. But is that enough? God is a holy God, and he cannot accept sinners. Even if we reject Adam’s imputation of sin to us, we have all sinned ourselves, and stand guilty before God for it. And even if a person was to turn from their sin and live sinlessly for the rest of their life, they would still be guilty of the sins in their past. The only hope for sinners is that Christ would be able to impute his righteousness to us: but the person who rejects imputation in order to avoid original sin can’t then have Christ’s imputation of righteousness.

So, for sinners to have any hope, we need the doctrine of imputation, by which we’re rescued from both our original sin and our own sinful acts by the imputation of Christ’s righteousness.


Script to Clear Dropbox Cache

June 16, 2011

I store an encrypted sparseimage file on my Dropbox for security. As of a few weeks ago, I started getting a problem where my hard drive space was filling up quickly. It turns out that Dropbox was storing multiple copies of it in a folder called “.dropbox.cache”. According to the forums, this is a bug that was fixed years ago, but it seems to have come back.

I’ve reached out to Dropbox for a fix, but, until then, here’s an AppleScript you can run to clear the cache. It quits Dropbox first for safety, clears the cache, then reopens Dropbox. I saved it as an application and put it in my dock so I can run it in one click any time I’m running low on hard drive space.

WARNING: I don’t provide any warranty for this code. It deletes files off of your hard drive without warning. It shouldn’t cause any problem, but if it does, I can’t take any responsibility for it. Understand the code and use it with caution.


tell application "Dropbox"
quit
end tell
do shell script "rm -fr ~/Dropbox/.dropbox.cache/*"
tell application "Finder"
open application file "Dropbox.app" of folder "Applications" of startup disk
end tell


Is iOS 5 Beta Live?

June 6, 2011

Currently, Apple’s iOS Developer page is down, while the iOS 5 Beta is being posted. Here’s a quick Perl script that checks every 5 seconds to see if the page is back yet:


#!/usr/bin/perl
use LWP::Simple;
$url = "http://developer.apple.com/devcenter/ios/index.action";
$size = length(get($url));
while( $size == length(get($url)) ) {
print "Not ready! time = " . time . "\n";
sleep 5;
}
print "Ready!\n";

UPDATE: or you can just pull up this web page.


Delegates, Protocols, and Optional Methods

June 5, 2011

In my iOS app, I have a lot of places where I show a modal view, and that view needs to have access to the view that opened it. To implement this connection, I’m using the concept of “delegates,” where one object has another object that it can call methods on. I created a protocol called ModalDelegate that defined the methods that these modals could call on their parent views. However, the way I implemented this caused a lot of compiler warnings. I just now figured out how to fix these, but the answers were difficult for me to find, so I figured I’d post them here.

First, it was my understanding that using id as a variable type was the standard Objective-C way to keep a reference to an object that can be of any class–the equivalent of the Java class Object, but more widespread in use. However, when I stored my delegate as an id, then tried to call a method on it, I received a warning that that method might not be defined. I could have cast the id to the appropriate type, but that seemed like it shouldn’t be necessary.

So, instead, I changed the type of the variable from id to ModalDelegate, the name of the protocol I created. This seemed intuitive to me from the way Java interfaces are used, and the compiler didn’t reject that variable naming. However, I got a similar warning: that method might not be defined. When I looked into it, I discovered that wasn’t the right syntax to use for a protocol at all. The right type for the variable was id <ModalDelegate>–in other words, an object of any type, but one that conforms to the ModalDelegate protocol. Also, instead of referring to @class ModalDelegate; in my header file, I needed to refer to @protocol ModalDelegate;.

The one remaining warning I was getting after this was that my classes weren’t implementing all the methods on the ModalDelegate protocol. The reason for this was that different views needed to have different methods called on them, and I didn’t want to have a separate delegate definition for each. So there were lots of methods in ModalDelegate, and each class that conformed to the protocol only implemented some of them. Of course, this isn’t how protocols are meant to work, but I didn’t see an alternative. But finally I found it: optional methods on protocols. I just add an @optional above all the methods that I want to be optional, and then the warnings went away. For my protocol, I actually wanted all the methods to be optional.

I don’t think this is a violation of the concept of the protocol, precisely because it removes all the warnings I had above. My modal view can call methods on its delegate without compiler warnings, because it knows it should have an id and that it may have a method of the appropriate type. The alternative would be to simply have an id and accept the warnings, or else use performSelector:withObject:, but those seem like overkill for the situation I’m in. The other alternative would be to implement each of the protocol methods and leave some of them as empty implementations. But all of these seem like overkill for my situation. With a protocol with optional methods, I’ve clearly defined for the compiler what I’m doing, and its lack of warnings assures me that I don’t have any typos.