Objective-C is a Piece of Shit
emadibrahim.com
emadibrahim.com
CIContext *context = [CIContext contextWithOptions:
@{ kCIContextUseSoftwareRenderer : @YES }];
CIImage *ciImage = [[CIImage alloc] initWithCGImage: cgImage];
CIFilter *hueAdjustFilter = [CIFilter filterWithName:@"CIHueAdjust"];
[hueAdjustFilter setValuesForKeysWithDictionary: @{ @"something" : @(3.0 * M_PI),
@"inputImpage" : ciImage }];
CIFilter *colorControlsFilter = [CIFilter filterWithName:@"CIColorControls"];
[hueAdjustFilter setValuesForKeysWithDictionary: @{ @"something" : @1.3,
@"somethingElse" : @0.3,
@"inputImage" : ciImage }];
ciImage = [colorControlsFilter valueForKey:@"outputImage"];
[context createCGImage: ciImage fromExtent: [ciImage extent]];
Unsurprisingly, concise code doing a simple task is about the same length in both languages.Well, it was off-the-cuff and written in a browser window to match the other guy's code, so it's probably not the prettiest thing I've ever written, but I don't think it's that bad. But I'm going to guess that you don't do a lot of Cocoa programming. If that's the case, I suppose we can headline this story "Person has minor difficulty reading code in language he doesn't know well."
I know I had trouble reading Objective-C before I learned it. It looks a lot different from other things.
> weird indentation
It doesn't look that weird to me, but of course "weird" is a matter of what you're used to. There are some stylistic things that are more or less "enforced" about Objective-C, but indentation isn't one of them. If you prefer something different, you can indent it differently in your code. It doesn't make a bit of difference.
> long method names that plague the library
I understand how you feel, but I'm pretty well convinced that descriptive method names are not necessarily a bad thing. One of the benefits of Objective-C is that once you know the language and your standard framework, it's usually exceptionally easy open up somebody else's codebase (or my own 10 months later…) and follow what's happening. In another language you'll need to jump around to definitions to see what arguments do, while in Objective-C it's always right there. And if you do know the codebase, skimming over the long method names isn't really a problem in practice.
What's next, we're going to complain that somebody's repo is "plagued with unit tests"?
I did fair bit of Smalltalk development back in school, so I know exactly where Obj-C/Cocoa naming conventions and 'message' syntax comes from. The problem is this: that naming convention doesn't make any sense in a statically typed language. It made sense in Smalltalk because the parameters sent to a message could be anything. It was a convention to avoid common erros. In Obj-C, on the other hand, it doesn't make any sense. Sure, it might sound like saying "message withBananaParameter: banana andCoconutParameter: coconut" is clearer and 'self documenting', but it's a waste of your time typing it (even when you use autocomplete) and the compiler parsing it. Let alone people reading your code in the future.
The indentation is arguable. I don't know whether that's the standard or not, but I dislike the fact that you are pushing stuff to the right, basically forcing yourself to break the parameter list a lot because you get closer to the "right margin". It looks like that indentation convention was specifically invented to make long parameters list harder to read (ironically, considering long parameter lists are an artifact of Smalltalk-like message/parameter convention.)
I've programmed in a bunch of languages and platforms over the yeas, and only three languages always keep bugging me when reading them: Obj-C (specially Cocoa code), Perl and very complex Javascript. There's something about them that just feels off.
NSWindow *window = [[NSWindow alloc] initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle backing:(NSBackingStoreType)bufferingType defer:(BOOL)deferCreation screen:(NSScreen *)screen];
people will often write write: NSWindow *window = [[NSWindow alloc] initWithContentRect: desiredRect
styleMask: windowStyle
backing: NSBackingStoreBuffered
defer: YES
screen: [NSScreen mainScreen]];
The length of the selector requires us to choose how we're going to write this line of code.The second thing you need to learn is the difference between a language and an API.
Additionally, 90% of the code shown here is old C APIs. You will never hear a Cocoa developer defend those. They're particularly frustrating to work with, but have nothing to do with Objective-C the language.
So, overall, this just comes across as hyperbolic and silly. It's cute and I'm sure the author felt smart by making this an image (why is it an image?), but it's mostly devoid of substance.
Weak sauce. This is just a marketing attempt.
Here's a mirror of the image that is the body of the post:
I am all about learning new languages. I love c#, python, ruby and javascript... But objective-c has to be one of the most verbose language out there and is syntacticly fugly...
When I programmed in python after 15 years of .net/c-type languages, I picked it up in 1 day. It was simple and beautiful. The same for ruby... But obj-c, after 2 weeks of using it, I find myself hating it more and more every day...
chill out people...
PS: the image on my blog s from http://xamarin.com/how-it-works
At least own what you said.... You can't make a post like this and then try to roll it back with "ha ha only kidding not my examples anyway".
Yes, if you deliberately set out to write bad code (CFDictionaryCreate instead of @{}? Come on.) then you can make a language look really bad. This should surprise nobody.
I'm afraid that, while you may have attempted to make ObjC look bad, you simply managed to make yourself look bad.
So is your web server.