8 ms·

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.

by siavosh 15y ago

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.

aaronblohowiak 15y ago
Dispatch queues have made most of my concurrency woes go away; same thing with ARC for memory leaks.
- mirkules 15y ago
  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.
  - aaronblohowiak 15y ago
    Those aren't Objective-C objects, but I get your point. ARC does not relieve you of thinking about memory, it just makes it easier.
    - AznHisoka 15y ago
      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.
      - mirkules 15y ago
        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-part-1 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.
      - deleted 15y ago
        [deleted]
  - batista 15y ago
    Well, same goes for every non memory managed object in any language. Like, SWT objects in Java. Or file descriptors. Or DB connections.
    - mirkules 15y ago
      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.
deleted 15y ago
[deleted]
dinkumthinkum 15y ago
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 ...
- siavosh 15y ago
  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.
batista 15y ago
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.
- RandallBrown 15y ago
  and visual studio... It has a WPF frontend anyway. I'm sure it drops into native code pretty quickly. Evernote actually did a great post about switching from C#/WPF back to a C++ app and how it actually let them move faster. Pretty interesting read. http://blog.evernote.com/2010/10/26/evernote-4-for-windows-is-here/ http://blog.evernote.com/2010/10/26/evernote-4-for-windows-i...
  - unicron 15y ago
    That's down to WPF which is a total pile of shit to be honest (having spent the last 3 years with it). It's nothing to do with the language.
    - josephcooney 15y ago
      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?
      - unicron 15y ago
        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.

by siavosh 15y ago

aaronblohowiak 15y ago

Dispatch queues have made most of my concurrency woes go away; same thing with ARC for memory leaks.

mirkules 15y ago
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.
- aaronblohowiak 15y ago
  Those aren't Objective-C objects, but I get your point. ARC does not relieve you of thinking about memory, it just makes it easier.
  - AznHisoka 15y ago
    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.
    - mirkules 15y ago
      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-part-1 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.
    - deleted 15y ago
      [deleted]
- batista 15y ago
  Well, same goes for every non memory managed object in any language. Like, SWT objects in Java. Or file descriptors. Or DB connections.
  - mirkules 15y ago
    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.

deleted 15y ago

[deleted]

dinkumthinkum 15y ago

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 ...

siavosh 15y ago
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.

batista 15y ago

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.

RandallBrown 15y ago
and visual studio... It has a WPF frontend anyway. I'm sure it drops into native code pretty quickly. Evernote actually did a great post about switching from C#/WPF back to a C++ app and how it actually let them move faster. Pretty interesting read. http://blog.evernote.com/2010/10/26/evernote-4-for-windows-is-here/ http://blog.evernote.com/2010/10/26/evernote-4-for-windows-i...
- unicron 15y ago
  That's down to WPF which is a total pile of shit to be honest (having spent the last 3 years with it). It's nothing to do with the language.
  - josephcooney 15y ago
    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?
    - unicron 15y ago
      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.