Tuesday, January 8, 2013

Why Delphi developers should learn Objective-C and XCode

This is an opinion piece with technical sprinkles on top.  I believe strongly that when a developer only knows one language, they tend to see the software development world through blinders. Ask yourself if this sounds like you:

1. If you had to work in an environnment where creating a new visible control on the screen wasn't a TControl, or where you had to add a new window and it wasn't possible to make that window and double click on an event on a component in that window, and then write your code inside there without ever writing a single line of boilerplate code, could you even work? Are you a RAD junkie?

2. Imagine that you had to learn a new set of libraries or frameworks. You've spent a lot of time learning the VCL. Have you ever tried to learn a new framework, whether it's the .NET framework used with the C# language, or the Boost libraries, or QT framework commonly used in cross-platform-C++, or others, like the UIKit which is the flavor of the Cocoa framework that you use to build native iPhone apps.

What happens to your brain when you learn a new framework, library, or language?  New ideas come in. And even if you then go back to doing the usual delphi thing, you might find a little fresh air has come in and disturbed the dusty recesses of your mind, where old, unchallenged ideas await, needing questioning, improvement, and calling for some general review.

Here are some reasons why Objective-C, and XCode 4.5, are worthy of your time:

1.  XCode 4.5 is an extremely nice, extremely powerful IDE with a lot of really good ideas in it, including "Assistant editor panes",  and a really powerful integrated visual GUI building tool which is not just slightly different from what you're used to when you do "RAD" style development in C# or Delphi, it's radically different.   Try to learn what a "first responder" is, and why "delegates", "categories", and "events" are not exactly something you can correlate 1:1 to an existing class, terminology, or practice you already know in Delphi,  because, actually, it really is quite different.   XCode as an IDE is stellar.  new user forgets to put in semicolon? XCode, help that user out! Done.    You forgot the @ sign that goes in front of an NSString literal, making your string literal a classic C string literal?  XCode notices, and warns you.  You have to try this compiler to really understand how awesome it is.

2.  Objective-C now has an amazing compiler and new set of language features collectively called "ARC", Automatic Reference Counting.  It's like the smart pointers of C++ have been moved quietly into the language itself.   This reduces the amount of boilerplate code needed to make the underlying reference-counting nature of Objective-C objects easy for users to handle in most cases. There are only a few areas where this approach requires manual intervention, including the fact that unlike a Garbage Collector, there is no cycle detection system, you must manually unhook cyclical links, for the collector to work.    So far I think the system is just about the most brilliant thing ever.  A secondary and surprising benefit of ARC is that it has taken a lot of weak-typed pitfalls that Objective-C had inherited from ANSI C and papered over them with warning labels (compiler warnings), or better yet, filled them with cement (compiler errors, that stop you from doing something bad).   Did you ever learn to thank a compiler for stopping now with an error or at least flagging with a warning or a hint, something that would have taken you a long time to find at runtime?  The latest CLANG/LLVM compiler (version 4.1) that compiles all the C-family languages (C, C++, and Objective-C) in XCode is a beautiful compiler, with beautiful error messages, and warnings.

3.  The frameworks (UIKit, which is Cocoa for iPhone) are amazing.   Lately I have come to wonder just how is Embarcadero going to handle things like screen rotation in their framework.  I hope they'll do an excellent job. How do you think the smart people at Embarcadero are going to design Firemonkey FM2 Mobile, or whatever it's called when they release it? You got it, Pontiac. They're going to study this working example of a mobile application framework, because it works, and there are millions of appStore apps out there that prove it's a solid design.

One caveat; You have to have a Mac in order to run XCode, and so, if what I've said makes you want to play with XCode, but you don't have a Mac, I suggest you get one. Go find a used Mac Mini on eBay, and try it out.  You'll be amazed.   You'll be frustrated sometimes. You'll want to yell at whoever decided to make something so alien and foreign to your delphi-loving brain.  But once your brain has seen other things, things it was not expecting, you will find that certain blind spots you had (and even cherished) begin to go away, leaving you to see Delphi in a clear, sober light.   Thus sobered you will not love Delphi less, but you will be more aware of where it is weak, and be able to help it along when it needs some care.

That might be a good blog post;  Areas where Delphi developers have blind spots.  One of them, just for starters is the tendency to create giant slimy muddles of code, with 10K lines of code in a single unit, and class. How dare anyone call a 20K line .pas unit with a single class in it a class. It's a compilation unit that is less object oriented than a stack of FORTRAN punchcards from 1957.  Sorry, it's not OOP. It's just a nasty mess, that doesn't even deserve the term "structured programming", which is the pre-OOP term for the desire for developers to stop making a mess, and to work in an elegant orderly, and understandable manner while building software.

There's no better way to learn to be a better developer than to force yourself to start over.  Beginner's mind. It's Zen, baby.  Look it up.

Update:  If you want to see the kind of learning curve you'd be facing, look at this question I posed today on StackOverflow.

Update2:  After a bit of a tussle with provisioning profiles and Wildcard AppIds, I'm now able to run apps on my device.



8 comments:

  1. I agree that learning something else always refreshes what you already know. Knowing how the iOS platform works from an XCode/Objective-C/UIKit point of view will make someone a better developer there even if they choose to use FM2 and the mobile dev tools planned. Its like driving a car when you know or do not know a thing about how the engine works; you can manage, but you will be a better driver if you do.

    ReplyDelete
  2. Yes, no doubt learning in new environment is quite enjoyable too.
    It has created a competitive atmosphere in the market. It has come with the tremendous features and dynamic applications.
    But in real, there is always pros and cons .

    mobile application development

    ReplyDelete
  3. Those interested in something different - 'Check Racket' - little off topic. Today the entry into this world is a nice one.

    Use help to change the language (not the programming language - the IDE language). The programming language can be defined in various ways. Experiment it's amazing.

    ReplyDelete
  4. if Firemonkey enables me to address multiple plattforms I can cut my development cost by the number of platforms I will sell my application into.

    ReplyDelete
  5. I'm not saying that Firemonkey isn't right for some people. But I am (quietly) saying that if the main thing you want is a first-class iOS app that looks and feels native, and handles the rotation and resize operations, and platform API integration that Firemonkey may not be the fastest or best way to a working iOS application. At this point, CocoaTouch has the most mature "write once run anywhere" framework, but as I'm a bigger fan of Delphi than of C#, I really do hope Firemonkey turns into a great multi platform mobile framework. Right now it's a beta, and anybody who knows what is in it is bound by NDA not to speak. I'm not currently in the beta, but would like to sign up when I have time to test and contribute bug reports, which isn't right now, as I'm too busy. :-)

    Warren

    ReplyDelete
  6. If someone is looking for a good introduction/tutorial into Objective C and XCode development on OS/X ... http://www.youtube.com/watch?v=7vy7pEpEYvk. Tutorials for both Objective C and XCode ... Especially for beginners. It covers many interesting topics and many burning questions. More than > 25 lessons and beyond ...

    ReplyDelete
  7. I sort of get what you are saying, but IMO time is better spent mastering new concepts more so than learning new ways to do an IF statement or another way to manage a button. How many programmers are completely fluent in threading, SQL, queues, versioning, protocol architectures, graphics, design methodologies, etc? IMO deeper understanding of complex processes makes a programmer better not the breadth of languages/platforms. IMO quality over quantity and that system doesn't require buying an extra laptop.

    ReplyDelete
  8. @Cameron; Then you're not getting me at all! if statements in Objective-C work just like if statements in Pascal, except that blocks begin and end with braces instead of the begin, and end keywords. That's not what will take you time to understand. Understanding why delegates, categories, protocols, responders, events, nibs, view-controllers, and a hundred truly Alien concepts are both powerful, useful, and in the context of iPhone development, better than the closest VCL/Windows concepts is where your brain really will expand. And language features in Objective-C will really be eye-openers, where you do learn them. The ability to extend objects at runtime with categories can be compared to class-helpers in Delphi, but there are some features like key-value-coding that don't quite have Delphi equivalents yet. Since Delphi has very powerful RTTI, there's no reason someone couldn't learn about Key-Value-Coding in Cocoa/Objective-C and then bring that knowledge back to Delphi, and implement some really powerful capabilities in Delphi using Key-Value-Coding. Now you get me?

    I freely recognize that not everybody wants to own a piece of Mac hardware, but hey, if that's going to block you, then you're never going to write an iPhone app, and so, maybe you should find something else (Java, .net) and learn that. My generic point applies even if you don't want to buy any hardware.

    Warren

    ReplyDelete