iOS Need some help with binary

[ArtOfWarfare]

I loathe the case sensitivity in C. (I am not a case sensitive human.)

???

I guess you find thisMethodName difficult to read?

 

[chown33]

???

I guess you find thisMethodName difficult to read?

Case-sensitivity usually means that case is significant in identifiers. So thisMethodName and thisMethodname would be different identifiers.

Case-insensitivity would mean thisMethodName, thisMethodname, and THISMethodNAME all refer to the same thing.

I've never seen "case-sensitive" used to say anything about readability.

Compare and contrast:
http://en.wikipedia.org/wiki/CamelCase
http://en.wikipedia.org/wiki/Snake_case

 

[Duncan C]

Case-sensitivity usually means that case is significant in identifiers. So thisMethodName and thisMethodname would be different identifiers.

Case-insensitivity would mean thisMethodName, thisMethodname, and THISMethodNAME all refer to the same thing.

I've never seen "case-sensitive" used to say anything about readability.

Compare and contrast:
http://en.wikipedia.org/wiki/CamelCase
http://en.wikipedia.org/wiki/Snake_case

Exactly.

CamelCase is fine for readability, but my eye does not easily catch differences in case. I've wasted more time than I care to think about trying to figure out why some code won't compile, only to find that I did not have the case of a method name correct.

I think it's really stupid that aMethodName and aMethodname are 2 different methods. Anyone who uses method names that are identical except for case should be taken out and shot. Ugh.

I like the way default Mac file system works, case-preserving, but not case sensitive.

If you look at the design of C, and read the K&R C book, it's pretty clear that they tried to reduce the size of source files. If you're going to use 1 and 2 character variable names, having case sensitivity is useful. However, there is no good reason for using 1 and 2 character variable names, and plenty of reason not to.

 

[ArtOfWarfare]

If you look at the design of C, and read the K&R C book, it's pretty clear that they tried to reduce the size of source files.

I guess that explains the numerous methods in C's standard library that are all but impossible to read (strcmp() - if you didn't already know what that was, would you ever find out without looking it up?), and why the built in types are int and char instead of integer and character...

Hmm... kind of feeling like a bunch of C's stuff should change now to be more verbose... in this day and age the numbers of bytes in your source code is the least of your concerns.

 

[Duncan C]

I guess that explains the numerous methods in C's standard library that are all but impossible to read (strcmp() - if you didn't already know what that was, would you ever find out without looking it up?), and why the built in types are int and char instead of integer and character...

Hmm... kind of feeling like a bunch of C's stuff should change now to be more verbose... in this day and age the numbers of bytes in your source code is the least of your concerns.

It endemic in UNIX developers. If you think the C language is bad for terseness, take a look at Unix command line commands.

cp = copy file
pwd= print working directory
ls = list files
chown = change file ownership
chmod = change file permissions
mv = move files.
cd = change directory

And the list goes on.

Thus our own chown33's handle...

 

[chown33]

I guess that explains the numerous methods in C's standard library that are all but impossible to read (strcmp() - if you didn't already know what that was, would you ever find out without looking it up?), ...

Long ago, on a PDP-11 far, far away...

The maximum size of an extern symbol for the linker was either 7 or 8 chars. I forget which, but it's close enough for government work, as the saying goes.

Furthermore, the C compiler would prefix a symbol like strcmp with an '_' so it wouldn't collide with any assembler symbol, where the naming convention was to not start any extern symbol with '_'. So that left only 6 or 7 significant characters for C function names, extern globals, and the like. If the C compiler was given a longer symbol name it would simply truncate it to the max allowed by the linker.

So if you go through and look at the symbol names in the C standard libraries, especially the libs that have been around the longest, you'll find that symbols are unique within the first 6 or 7 characters. Thus, you have things like strcmp(), strncmp(), strlcmp(), where a difference is always within the first 6 or 7 chars.

Small symbols also meant a small symbol-table size for shared libraries, an important consideration when a PDP-11 with a total of 256KB of RAM and a 64KB addressable address space per process was not uncommon as a time-sharing computer for a developer team. That was also when 80 MB of hard drive space meant a disk drive the size of a washing machine, and a stack of spinning aluminum platters 14 inches across.

It's striking how far things have advanced since then, but it's also striking how much could be accomplished with what now seems like so little.

 

[Duncan C]

Long ago, on a PDP-11 far, far away...

The maximum size of an extern symbol for the linker was either 7 or 8 chars. I forget which, but it's close enough for government work, as the saying goes.

Furthermore, the C compiler would prefix a symbol like strcmp with an '_' so it wouldn't collide with any assembler symbol, where the naming convention was to not start any extern symbol with '_'. So that left only 6 or 7 significant characters for C function names, extern globals, and the like. If the C compiler was given a longer symbol name it would simply truncate it to the max allowed by the linker.

So if you go through and look at the symbol names in the C standard libraries, especially the libs that have been around the longest, you'll find that symbols are unique within the first 6 or 7 characters. Thus, you have things like strcmp(), strncmp(), strlcmp(), where a difference is always within the first 6 or 7 chars.

Small symbols also meant a small symbol-table size for shared libraries, an important consideration when a PDP-11 with a total of 256KB of RAM and a 64KB addressable address space per process was not uncommon as a time-sharing computer for a developer team. That was also when 80 MB of hard drive space meant a disk drive the size of a washing machine, and a stack of spinning aluminum platters 14 inches across.

It's striking how far things have advanced since then, but it's also striking how much could be accomplished with what now seems like so little.

Yup. It's also depressing how we wind up stuck with the limitations of past hardware, seemingly forever. We'll be base64 encoding binary data to send it over hyperspace links.

IBM computers still talk to their terminals using 80 character "cards", even though card readers are finally dead and gone.

And we still have to use gawd-awful 2 character command names in our favorite UNIX shell, and our grandchildren will probably be doing the same.

Your comment about accomplishing so much with so little is also very true. Consider that the Apollo moon missions were flown with computers made out of hand wire-wrapped discrete NAND gates.