I spend half my day in iOS development and the other half on a Java web stack. I love the RESULT of Obj-C+Cocoa Touch, you can achieve amazing user experience. But I'm reaching the point thinking: it's 2012, I'm an application developer, why am I spending half my time debugging memory leaks and concurrency issues? Java isn't much better either, why all this boiler plate, and still concurrency nightmares. I've done a handful of side projects with django and that's better, but I still think if I showed my teenage self what I'm programming in, he'd wonder if there was ever any real progress.
I guess what I'm saying is after all these years I want to work on a higher level, as a result I've started to play with Clojure and functional languages. Whether I'm idealizing functional/clojure life, I'll soon find out, but the appeal is very high to spend my time dealing with problem complexity, not language/framework ones.
A word of caution with ARC -- you still have to release certain things manually, for example CGImageRefs with CFRelease if you're doing any sort of image manipulation.
ARC to me is scary... I got over the huge learning curve, and the nuances of autoreleasing, and retaining, and it seems like now I gotta unlearn all of that??? And not to mention some third party libraries/source code don't support ARC. To me, I'm gonna hold off using ARC as long as possible.
Well, you don't have to "unlearn" it. It's actually a good thing you went through the "pain" of learning it pre-ARC because if you understand how reference counting actually works, you will be able to make better and more informed decisions on the management of your objects in 5.0+ with ARC (e.g. when to use strong vs. weak properties). There's nothing magical about it, and Ray Wanderlich has a fantastic ARC tutorial that helped me greatly: http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-par...
Holding off on ARC is only advantageous if you need to support iOS versions before 5.0, but ARC is the future of iOS.
Indeed, as Aaron above mentioned, ARC doesn't absolve the programmer of the responsibility of proper memory management, it's just less overhead to have to worry about.
To me, this is almost like asking, "Why, since it is 2012, is the Halting Problem, such a problem?" I don't know what 2012 has to do with functional programming languages, though ... seems like there was this language a long, long time ago, in a far away land ...
What made Clojure stick out for me was its easy access to the vast java libs, and its philosophy on concurrency. Both (I could be very wrong) seemed novel in the functional world.
But I'm reaching the point thinking: it's 2012, I'm an application developer, why am I spending half my time debugging memory leaks and concurrency issues?
Because Objective-C targets everyday desktop apps and mobile apps. In that space, manual memory management still wins the day.
For example, in Windows and Linux DESKTOP those kind of apps are ALSO made in C++ or C.
Java and C# are for the web server and the CORPORATE desktop (in-house apps).
Not many major end user apps outside the enterprise are made with either. Not any famous, widely used ones, anyway. Azureus, maybe, and a few dozen more.
Avoiding GC doesn't equate to "manual memory management." Objective-C uses reference counting, which is only manual in Objective-C for historical reasons, and they're trying to overcome that with ARC. I'm pretty sure most popular scripting languages use reference counting instead of garbage collection. C++ with pervasive use of shared pointers shouldn't be characterized as "manual" either.
Also, as of a few years ago, the only performance-related reason why the JVM wasn't a popular language for desktop GUI apps was startup time. (In the mobile space, it might be true that Java isn't fast enough on current hardware. My experience with Android hasn't been very inspiring, for sure.)
Keep in mind that desktop GUI frameworks take a HUGE amount of time and labor to create, and almost all of the excitement has been in web apps for the last decade. The status quo in GUI frameworks is heavily colored by history. All of the major GUI application frameworks are ancient and reflect the linguistic realities of the year 2000 much more than they reflect current technology.
Also, as of a few years ago, the only performance-related reason why the JVM wasn't a popular language for desktop GUI apps was startup time.
I don't think so. Besides startup time, Swing was always slow --an over-engineered mess. For some Java people it was always "fast enough in the latest version" (like for some Linux people it was always "the year Linux wins over the Desktop"), but even the best Swing UI had perceptible lags over a bog standard native. Heck, even SWT that's half-native has huge GC related lags in Eclipse.
Swing also had the uncanny valley effect, trying to mimic native UIs. And even when they tried to bypass the issue with custom l&f like Alloy et al, they couldn't, because the uncanny value is mostly due to how the controls BEHAVE and not with their style (that's why in, say, OS X, you can use apps styled like Aqua and others styled like Metal at the same time and you don't get the "uncanny valley" effect).
If we judge Java by Eclipse, can we judge C by iTunes? :-) They both tend to become unresponsive at odd times, but it's caused by clumsy background processing, not language performance.
The Eclipse framework itself is plenty fast, and UIs based on Eclipse RCP can be quite snappy. (Except for that damned startup time.) Swing's a mess, but if you're looking for the technical limitations of a language platform, it's the best performers that are relevant, not the worst performers. Otherwise, iTunes is evidence that even C is just too slow.
That's true, but I'd guess that's true of much desktop software. People don't use Microsoft Word because of its efficient C++ code; they use it because it's semi-standard, has lots of features, and overall is good enough. I would bet giant piles of legacy code are a bigger reason for not moving to C# than anything language-specific is.
Don't look to Minecraft for an example of well written code, there are open source alternatives (Minetest in C++ springs to mind) that run rings around it. And Notch himself is well known for his inefficient magic-number and circular-reference ridden Java code. Although I can't attest to Jeb (who is now the lead dev)'s coding skill.
"Then they are converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed."
I'm kind of fond of WPF. Lots of aspects of it (data binding, styles, templates, the layout system etc) seem very elegant to me. It is not without issues. How do you justify the 'total pile of shit' call?
Doesn't scale up as well as win32/GDI. Requires much faster kit with graphic hardware acceleration to run (we had to bin about 200 Matrox Parhelia cards and replace with hefty NVidia cards to make use of hardware acceleration where GDI was fine on Matrox). Can't ILmerge thanks to XAML loader problems. Editor sucks. 5-million casts required in your code. BUGS! Hard to do trivial things. Virtually impossible to produce a scalable composite application. Grinds an 16 core Xeon to a halt inside VS2010. Learning curve from hell (this hurts on a 20 man team).
It's not good progress - it's just a deeper abstraction.
I can't argue with most of those. The designer sucks, and I blame that for lots of the VS slowness. I never open XAML files in the designer. Not sure about 'scaling up' relative to GDI - I guess if you're a gun GDI programmer you can probably make it do pretty much anything, but I felt more productive doing graphics stuff in WPF - seemed to let you do quite a few cool things pretty easily. ILMerge thing is a pain, but not a major one (unless you've gone out and built thousands of assemblies and are getting slammed by load times, in which case you kind of painted yourself into a corner there). When you say "Virtually impossible to produce a scalable composite application." do you mean scaling development, or run-time scalability?
I can't help but feel if MS had paid more attention to perf (maybe re-platform it on top of Direct2D in the .NET 4 timeframe, instead of going all in on WinRT) things would be a lot better.
WRT scalability - it's scaling UI components over time. I build large complicated metadata driven applications and it's quite hard to compose an application on the fly.
Agree with performance. I hope WinRT is better. I have little faith based on my experience with Win8 so far but it's not RTM so I shouldn't comment on it yet.
I guess what I'm saying is after all these years I want to work on a higher level, as a result I've started to play with Clojure and functional languages. Whether I'm idealizing functional/clojure life, I'll soon find out, but the appeal is very high to spend my time dealing with problem complexity, not language/framework ones.