Software Engineering discussion
Beautiful Code
>
Another Level of Indirection
date
newest »
newest »
I liked this chapter. It had a nice mix of code and discussion.This chapter felt a little dated with C code and old file systems, so I'd understand if anyone had a hard time relating to this.
I work with storage devices (databases, file systems, and tape drives) at low levels often. Abstractions like this are still common. I try to use a decorator pattern, which isn't too far abstracted from this chapter's design.
C is present throughout this whole book! Is C "beautiful"??
I would think most popular langauges are "beautiful". Langauges likely fall in the "Another Level of Indirection" classification too.I think C is common in this book, because many of the functional issues in this book were solved many years ago when C was big(ger).
Here is an example of ugly. A bug related to this kept me up far too long last night.
I am learning Objective-C. In general, I like it and there are many beautiful things about it. But, support for Booleans is ugly. There are several places that require an object, not a primitive, such as in arrays and Core Data (the object persistence framework). This is how you represent a Boolean as an object:
[NSNumber numberWithBool:YES]
This is ugly in at least three other ways beyond the obvious. First, my bug was related to using the address of the object instead of the Boolean value. Since the address was non-0, it is treated as a NO! Strong typing, where are you?
Second, the debugger (based on GDB) can't directly show you the state of an object, which greatly slowed my debugging productivity by putting me in NSLog (the equivalent of printf) mode, writing to the console. There might be a better way, but I have not found it yet.
Third, think of the memory footprint required to hold one of two states... especially when the target hardware might be a mobile device with limited resources.
Ugly.
I am learning Objective-C. In general, I like it and there are many beautiful things about it. But, support for Booleans is ugly. There are several places that require an object, not a primitive, such as in arrays and Core Data (the object persistence framework). This is how you represent a Boolean as an object:
[NSNumber numberWithBool:YES]
This is ugly in at least three other ways beyond the obvious. First, my bug was related to using the address of the object instead of the Boolean value. Since the address was non-0, it is treated as a NO! Strong typing, where are you?
Second, the debugger (based on GDB) can't directly show you the state of an object, which greatly slowed my debugging productivity by putting me in NSLog (the equivalent of printf) mode, writing to the console. There might be a better way, but I have not found it yet.
Third, think of the memory footprint required to hold one of two states... especially when the target hardware might be a mobile device with limited resources.
Ugly.
This chapter serves as a good reminder at just how many layers and levels of indirection are at play in a computing system these days.