Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Worthless... (Score 5, Insightful) 130

Yet another worthless benchmarking from Phoronix (Moronix, amirite?). They switch between compilers, compiler versions, and even use Xcode itself for some of these comparisons, which make it essentially worthless. Add to that absolutely zero investigations of the reason for differences between the platforms (aside from the obvious mention of graphics drivers) and this is yet another piece of benchmark porn from a site dedicated to it.

Comment Re:ObjC sucks (Score 2) 437

Method signatures are often ridiculously long (see NSBitmapRep's initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: method)

That's rather the point. It make code easier to read and understand when you can see, in the method invocation itself, what all of the parameters are for.

Parameter names in method calls are /always/ named. You can't just say obj.someMethod(x,y). It's always [obj someMethodForX:x y:y].

Again, rather the point. Otherwise your above example would endue as initWithBitmapData(p,w,h,b,s,a,p,c,f,r,b).

The above combine to make even the most basic operations tedious. Want to trim leading/trailing whitespace off a string? Enjoy [someString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]]

Autocomplete makes this rather irrelevant, no? Especially the much improved autocomplete in Xcode4+.

Immutable arrays, dictionaries, sets, strings. I get it, it can be useful for performance to know something is immutable (maybe, I'm not that convinced). But the common use case is most certainly mutable, so /that/ should be the default, e.g. NSArray should be mutable and then if needed there can exist some NSImmutableArray or something. But no, they did it the other way around.

That you don't actually understand this point is pretty telling. Performance isn't the only reason to make arrays and such immutable by default. It also makes such structures safer to pass around, especially to outside code, without having to worry about the data getting modified unexpectedly.

Memory management (up until recently) was neither fully manual nor fully automatic and ownership was based on naming conventions

Ownership is always based on naming conventions, or else there would be no predictability and the language would be unusable.

Being a superset of C, they couldn't provide an object-oriented array class using the normal array syntax, so instead you have tedium like [myArray objectAtIndex:2]

"Fixed" in enhancements coming with Xcode 4.4.

Ditto for strings. Also, you have to prefix string constants with '@'.

Oh no, a single extra character!

Similarly, you can't put "plain" objects into arrays, e.g. [myArray addObject:5] won't work, but [myArray addObject:[NSNumber numberWithInt:5]] will.

Perhaps you one valid complaint, rendered nearly irrelevant by enhancements again coming in Xcode4.4.

And of course you can't just create an array with ['a', 'b', 'c'] but instead have to do [NSArray arrayWithObjects:@"a", @"b", @"c", nil].

Oh hey, same thing.

Backwards conventions like [NSDictionary dictionaryWithObjectsAndKeys:@"value0", @"key0", @"value1", @"key1", nil];

And again, a solved issue.

If I'm going to pay the dev cycle price of a compiled language, it should catch stuff like non-existent selectors at compile time instead of blowing up at runtime

It does. Unless you turned off those warnings. I always build with -Wall -Wextra -Wno-unused-parameter

Stack traces from delayed selector calls have zero contextual information

They have the same information as that selector normally does.

The single inheritance model and a strict class hierarchy discourages writing reusable code. For example, if I have an app that runs on iPad and iPhone and they share a common screen (from the user's perspective although the layout/design might be significantly different), it's a real task to write a common parent class holds the common code.

You're doing it wrong. Reusing code is trivial as long as you've cleanly separated it using the MVC paradigm most common in Objective-C.

Many violations of don't-repeat-yourself: if you want to have an object with properties like Foo.title, then the code is roughly:

@interface Foo { NSString *title; }

@property (nonatomic, retain) NSString *title; @end

@implementation Foo @synthesize title -(void)dealloc { [title release]; [super dealloc]; }

Oh hey, another solved issue. Some of it has been for a few years now. You don't need a backing ivar on iOS or 64-bit OS X and never have. With the enhancements coming in Xcode4.4, you don't even need synthesize. With ARC, you don't need dealloc.

Similarly, there's no way to have a truly dynamic object with a clean syntax, e.g. in Python/ruby/js/and a host of others you could have a quick little object you use to pass state around, kind of like a struct that has its members added on the fly, e.g.: x = new Object() ; = 'dave' ; x.age = 3. There is literally no way to do that in ObjC - the best you can do is create mutable dictionary and use its verbose syntax.

These are a bad idea in those languages too. Hey, lets have an object that can store anything under any name at any time, with no restrictions. Brilliant!

We could have a whole extra thread about the toolchain (Interface Builder is an abomination, Xcode often pegs multiple CPUs when it's just sitting there, if you kill the simulator instead of stopping the app via Xcode then you often have to reboot your host machine before you can run the simulator again) but I digress.

We could indeed. IB is still leaps and bounds ahead of any other GUI tools and your last point is just completely wrong. Xcode does have its problems though.

Comment Re:UN declares war on Libya (Score 3, Insightful) 501

Illegitimate nations like Libya have no sovereignty beyond what the international community grants them. Just because a guy uses military force to control an area doesn't give him any sort of right to that area. Right now there is no Libya beyond Ghaddafi. Only once he is out of the way and the people of that area are able to determine their own fate can it be said that they truly have anything resembling sovereignty.

Slashdot Top Deals

In any formula, constants (especially those obtained from handbooks) are to be treated as variables.