In the video demo they show a glitch in the iOS screen. For a fraction of a second the Recent Products carousel has height zero and we see the cells from the carousel below (try recording with slo mo camera to see it). An obvious programming error, and yet they chose that for the demo. It doesn’t exactly inspire trust.
We’d like a swift version of Core Data (a graph of objects), not a ORM. For async programming we have GCD and reactive libraries, async await is on master already, a design document is expected this month.
This post has many generalizations and little technical content. The subject is interesting (for ObjC programmers mostly), but arguments are shallow.
> it was never an issue to port correct C/C++ code
In C/C++ there is no such thing as a portable application only applications that have been ported, even with standard compliant code. Try porting between Linux/Solaris/Windows and see by yourself.
> (paraphrased) Backend apps should be written in Objective-C instead Java, let's rewrite them!
Before making such bold statements about rewriting applications, what can you tell me (if anything) about the speed of a server JVM compared with Objective-C? And this is really a broad question, since for starters, languages don't scale, architectures do. Your outdated SO link doesn't begin to answer. See this general benchmark http://shootout.alioth.debian.org/u32/which-programs-are-fas... and add to that Objective-C message passing. And then think how it translates to server code. Just food for thought.
> Java API replicates the entirety of the UNIX system layer in Java-ese, obscuring any helpful C idioms or UNIX-system knowledge in the process
Because you think that those idioms and platform specific code won't be an issue when ported, or they will be plenty of devs familiar with that, which isn't the case. Most programmers out there use Java because they couldn't code their way out of a paper bag.
> You cannot postpone garbage collection forever. This is a disaster for applications that need to scale.
Nope, GC happens incrementally, and it's not a disaster for scalable Java applications that are deployed now in the real world.
> Oracle now owns Java and is a hostile entity. Java is done. Its future as a product is finished. Whatever your relationship is with Java now, expect it to deteriorate.
Completely wrong. JDK 8 lambdas will be feature completed in January 2013, and if you are an Objective-C programmer, you know how much of a change it brings to the language. And we have Jigsaw, project coin, java.util.concurrent with CAS, and countless JSR. Java has better health than ever, ask around.
> Web shops won't go for Apple servers. All the development, all the monitoring, all the operational knowledge is based on a few varieties of Linux.
It's the cost, not the knowledge. Also if you are a linux admin you get the same toys in Mac. An Apple desktop makes sense because it's less likely to interrupt the work of someone with a salary, but a farm of web servers based on Linux is cheap and easily replaceable. The best contribution of Google to the "open" world was to show that you can scale on Linux.
And this makes me think, given that Apple makes money selling hardware, where is the motivation to compete with Java/.Net promoting server frameworks? This is all about us buying Apple hardware people, don't forget.
> developers who worked at Etsy when I was there, 100% either used a Mac to develop or use a Mac to develop now. This preference is standard in the industry.
Most devs in the planet are behind a cheap HP/DELL PC. Otherwise we would know based on StackOverflow logs and sites like that. You could say best devs use laptops, because that's at least what we see in dev conferences.
> PHP is (or was) the dominant web scripting language by a large margin. This happened because of performance and ease of use,
Java couldn't compete because JVM required 128MB RAM, and one app on a shared JVM instance could bring down the rest, so Java was dangerous and cost prohibitive for small sites.
elegance, simplicity, beauty.. do those words emanate from Ruby in waves or from your inability to give a technical description? what overhead and code-bloat are you talking about? you can read the LLVM code and the objc runtime from Apple and go into specifics if you like.
To write a 3D shooter you can use Objective-C specific features as much or as little as you want. For intensive performance code you can bypass the messaging system and write pure C, for the rest you can use Cocoa APIs. This is what you do in any language. Unless you want to argue that dynamic languages as a whole are not worth it.
If you are happy with RubyMotion go ahead, but don't preach bad mouthing a language you haven't even developed on.
I'd like to know why. I've been hearing this for a while based on the generic design LLVM/Clang and the slower dynamic nature of Objective-C. Both BS reasons.
So - thanks to their special relationship with Apple -
Atari has successfully scrubbed the app store of their
perceived competition. It looks as though Apple complied
without so much as a rebuttal or independent evaluation.
"it looks like" it's not enough to claim there is a "special relationship". It pisses me off that everyone having legal trouble with a third party claims wrongdoing by Apple for spurious reasons.
Apple is taking action based on "the best of their knowledge". That is, they comply when someone files a claim, but they reinstate the game when someone else files a reasoned legal rebuttal. It's not up to them to take the case to court or seek independent evaluation.
You can 1) throw in a suggestion, 2) blindly suggest whatever works for you as the best way, 3) learn about the goals, setup, and knowledge of the user as the first step. The point of the article is: 2) is a mistake.
And I don't understand why you post random links about issues you are not familiar with, which is what you would need to digest them.
Some APIs are not ready for developer use, end of story. Apple does right to forbid their use to avoid crashes on the next iOS upgrade. It's not some plot to gain advantage. CoverFlow clones were always welcome, page curl is already published (clones were welcome before that, I coded one btw), JSON parser already published, some other APIs have no place on developer space.
Your complain should be: Apple doesn't open source their system.
> Apple does right to forbid their use to avoid crashes on the next iOS upgrade
Why doesn't this argument apply to apple? Are there any other methods of preventing crashing?
> Your complain should be: Apple doesn't open source their system.
No. My complaint is that apple doesn't treat developers as fellow programmers, but more like "end developers" or something. Apple gets to do it differently. Case in point being OP's post.
> And I don't understand why you post random links about issues you are not familiar with
Not entirely true. Both iOS and Android have a way to remove applications from your phone. That's useful against rogue applications, the latest of which is HTC's Android giving away your personal data. You want a safe and unregulated market but you can't have it both ways, specially if you are computer illiterate.
Removing malware from phones and the market is entirely reasonable. That's not the problem. The problem is deciding what kind of non-malicious apps people can use on their own hardware. For example:
