Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Re:Good reasons for Swift and Go (Score 1) 161

The only substantial way of improving on string concatenation in Objective-C would be to introduce custom operators, and that brings its own set of issues. The other alternatives sacrifice consistency.

I think it's telling that the ultimate way Apple found to improve on Objective-C is to put it on a retirement path by introducing a replacement language. That's mostly all I'm saying here.

Comment Re:Good reasons for Swift and Go (Score 1) 161

The problem isn't clear naming of variables. It's boilerplate in the library that you can't get away from. Talk about making your skin crawl, try doing very much with NSString's. Anyone who has worked in a high level language with a concatenation operator (typically "+" or "&" or ".") will feel bewildered at the ridiculous hoops Objective C makes you jump through.

Check out: http://stackoverflow.com/questions/510269/shortcuts-in-objective-c-to-concatenate-nsstrings

Every action that should be common, quick and simple requires forming a committee.

Comment Re:Good reasons for Swift and Go (Score 1) 161

And personally I have no objection to methods with long names - it helps me understand what has been written when I return to a program after months (or a year) away. The long names actually make the code more readable and maintainable.

No, in many cases the extra length is just ridiculous boilerplate. And even in cases where the extra length clarifies what's going on, you can do the same thing in other languages, i.e. every language supports use of meaningful names.

Can you seriously argue that concatenating a string in Objective C is elegant?

Be careful! You're repeating yesterday's Dogma of the Faithful. Apple fanboys now have corporate blessing to move to Swift, and you may find yourself left behind. /joke, joke

Comment Good reasons for Swift and Go (Score 3, Interesting) 161

Swift needed to be created because Objective C stinks, and no other modern language would have fit smoothly into the Smalltalkish legacy of the Cocoa framework. I'm just glad that the Apple fanboys who constitute most of my fellow iOS developers are finally allowed to believe bad things about Objective C, at least now that there's a nice alternative. Made me a little sick before to hear people praising Obj-C while writing reams of ridiculously verbose code that nobody will want to maintain 5 years from now.

Go is a fantastic language for server side development with concurrency that's not painful to wrap your head around, and is perfect for cloud development in Google's world.

Won't comment on Facebook Hack, since it's not clear to me why Facebook itself needs to exist. But to each their own...

Comment Re:Unless end to end, it's a farce (Score 1) 27

The encryption keys used by a BES server are generated by that BES server, and not by BB. As such, there is no key that BB can give to any govt which will decrypt any data sent between a BES and a connected BB phone.

You can substitute the BES server for BB in my remark (see, still trusting a third party), or you can recognize that BB still has control over software and software updates, and thus by definition is able to subvert the system. The most you can say is "Sure, they _can_, but I trust that they never _would_." And the infosec guys will shake their heads sadly at you.

Comment Re:Unless end to end, it's a farce (Score 1) 27

This is a blatant lie.

No, in fact it's a fundamental principle of infosec. Unless you keep keys close to your chest and perform tightly controlled, end to end encryption, there are opportunities for subpoenas by TLAs or for top tier hackers to compromise your keys. Trusting a middle man is a fundamental compromise in the provability of your security.

Comment Unless end to end, it's a farce (Score 2, Insightful) 27

Since multiple governments mandate that Blackberry share back doors with them, it's not clear to me what benefit more encryption will really add. Won't they be sharing keys with governments (and thus potentially hackers can get the same data)?

The only secure encryption is end to end encryption where you understand and actively control/limit how the key transmission works.

Comment Re:Alternative? (Score 1) 377

No, your partial quote of my sentence is misleading. Of course lots of things may be true, i.e. have a nonzero probability. We don't believe these things because we consider them to have a very small probability based on nobody being able to demonstrate them scientifically.

Comment Re:Alternative? (Score 1) 377

First, your comment is actually hilarious given the subject matter. Simply drinking tap water or inhaling air wherever you are may involve inadvertently taking in homeopathic "drugs", because there are always trace amounts of interesting things floating around in different places. (Yes, the land of homeopathy is a silly, silly place to be.)

Which is not what anyone would possibly be referring to.

Before going any further in this conversation... do you know what homeopathic medicine is?

Slashdot Top Deals

Old programmers never die, they just hit account block limit.

Working...