Skip navigation

Help! Why is my Objective-C code so bulky?

1140 Views 8 Replies Latest reply: Nov 20, 2012 5:26 PM by Ginobean RSS
DavidStein Calculating status...
Currently Being Moderated
Jul 4, 2012 4:16 PM

I'm coming from a C#/Visual Studio background, and trying to get up to speed with Objective-C/Xcode. I've also recently dabbled in Python a bit.

 

Today, I spent some time applying my new Objective-C skills to a routine programming exercise - a database interface. I've previously written this same logic in C# and Python, and figured that the Objective-C port would be straightforward. The result was a mess: VERY verbose code + messy syntax = difficult to write / debug / maintain.

 

I wrote up my experiences here:

 

http://www.djstein.com/Misc/Objective-C-vs-Python.html

 

I'm posting here to ask for help in making my Objective-C code more efficient and readable (especially the type conversions, which are pretty onerous). Any help? Thanks in advance.

MacBook Pro (17-inch Late 2011), iOS 5.1
  • etresoft Level 7 Level 7 (23,915 points)
    Currently Being Moderated
    Jul 4, 2012 5:45 PM (in response to DavidStein)

    You are comparing a high-level, scripted language with a C-based object-oriented language using a C API. I can assure you that Python is doing all the same stuff, just behind the scenes. There is no way a compiled, strictly typed language can ever compete with a script language like Python or Perl. If you were writing something to run on a server somewhere, then Objective-C would be a poor choice. If you were writing code to run on a thin client like an iPad or a Mac, then Python would be the language causing you all the grief.

     

    You don't have to use the C API for SQLite. I'm sure there are other, more high-level wrappers. You can also use Core Data an abstract the database away almost entirely.

  • mark133 Level 1 Level 1 (55 points)
    Currently Being Moderated
    Jul 4, 2012 6:28 PM (in response to DavidStein)

    I shouldn't really be on here, because I haven't even started Objective-C yet, but isn't the whole point of objective-C that you can utilize the classes that have already been made? Like using key values to access the file, NSArray, NSFormat and NSArchive, or whatever, to do what you want?

  • etresoft Level 7 Level 7 (23,915 points)
    Currently Being Moderated
    Jul 7, 2012 3:43 PM (in response to DavidStein)

    DavidStein wrote:

     

    Right - the interpreter is providing much more built-in routine legwork to enable a simpler syntax. That's my point: the Objective-C parser is so unhelpful that it forced me into a very verbose and clumsy use of the language.

    How can you say "Right" and then completely misunderstand? If you don't like Objective-C, then don't use it. No one is forcing you. You are making evaluations based on a subjective analysis the source code looks. I don't think it looks verbose or clumsy at all. It is much better than C or C++ would be. Perl would be better than any of them, including Python. So why not use Perl then?

     

    Second - all things being equal, a compiled language  can apply much more extensive and complex language parsing during the leisurely point of compiling, than an interpreter that's parsing the script totally at runtime. So a compiled language *should* be much more robust and capable than an interpreted language.

    Can you name any examples where that would be true?

     

    But as I indicated in the introduction of my write-up, the functionality of the task itself wasn't the point. I chose a routine programming task to see how elegantly I could solve a routine problem in each language. Reliance on APIs would have rendered the exercise moot and uninformative.

     

    In that case, you need to re-do your Python script. Only this time, leave out the following two lines:

     

    import sqlite3

    import re

     

    Now that would be a far more interesting and fair comparison.

  • Llessur999 Level 4 Level 4 (1,155 points)
    Currently Being Moderated
    Jul 7, 2012 7:47 PM (in response to DavidStein)

    DavidStein wrote:

     

    But as I indicated in the introduction of my write-up, the functionality of the task itself wasn't the point. I chose a routine programming task to see how elegantly I could solve a routine problem in each language. Reliance on APIs would have rendered the exercise moot and uninformative.

     

    But the task you selected happens to be a task that Cocoa does not natively support with abstracted classes. If you had selected a different task, the results might be different. For example, develop a user interface based on table view navigation.

     

    I am also from a long C# / Visual Studio background. If I wrote a C# application that accessed an Oracle database using the Oracle Call Interface (OCI) API it would be a nightmare of complexity. Fortunately Microsoft provides ADO.NET System.Data classes as part of the .NET class library, which allow me to access databases with concise code.

     

    Unless you are only evaluating suitability for client/server database application development, it is not fair to penalize Objective-C or Cocoa because Apple decided not to include database access classes. Most C# development that uses ADO.NET to access databases is for ASP.NET or WCF server applications. Since Objective-C is not used for server applications, Apple probably doesn't rate database access class development very high on their priorities

     

    I personally would prioritize native support for REST web service clients much higher than database clients.

  • etresoft Level 7 Level 7 (23,915 points)
    Currently Being Moderated
    Jul 7, 2012 7:53 PM (in response to DavidStein)

    DavidStein wrote:

     

    Do you understand how interpretation and compilation are performed?

     

    I've dabbled.

     

    Again, I don't understand your point. The Python and Objective-C solutions both use the built-in SQLite3 library for the language.

     

    No, in your example, you use SQLite's C-language interface. There are higher-level interfaces available. Ideally, you would just use Core Data and virtually all of your Objective-C code would go away. Scripting languages are good at doing low-level tasks in concise language. No compiled language is good at that. Because they are closer to the hardware, you have more control over the details. That's the point of it.

     

    It isn't that Objective-C is any more bulky, messy, or verbose than any other compiled language. I just think your example is contrived. You are trying to roll your own object-oriented database and stuff it into a relational database. I think I tried something like that when I was 24. What a mess.

     

    I don't know anything about Python. But if I wanted to reimplement what you did in Perl, I'm sure it would be much less verbose than the Python. That doesn't mean there is anything wrong with Python. Each language has its strengths. Each language is supported by its vendor for certain tasks. If you want to write apps for iOS or MacOS X, you will go much further with Objective-C than with Python. If you want to write server-side scripts, then Python or Perl would be better.

  • Ginobean Calculating status...
    Currently Being Moderated
    Nov 20, 2012 5:26 PM (in response to DavidStein)

    I've been a professional programmer for over 20 years and my experiences so far with Objective-C have been fairly positive (I started learning it this past July).

     

    Prior to Objective-C, I had been programming in Java as my preferred language of choice.

     

    Now, I actually prefer the combination of Objective-C + Cocoa. It's not as strict as Java, which, for me, means that I can typically get more done with less code.

     

    At first, I didn't like the bracket notation for object messaging and I thought it looked pretty clunky. Now that I'm used to it, I like it.

     

    Automatically synthesized properties are really nice and save on writing tedious setter/getter methods.

    Fortunately, I think I was able to miss most of the gnarliness with having to use retain/release. By the time I started picking it, XCode was supporting automatic reference counting. So, by partitioning non-ARC code into it's own library, I could pretty much ignore retain/release semantics (in fact, I am only dimly aware of them), and focus on whether a variable should be defined as strong, weak, or assign. (But, of course, you still have to understand strong references versus weak ones, but this is pretty basic computer science).

     

    All in all, it's a fun language and Xcode's code completion seems far superior to Eclipse's code completion. And Xcode as an IDE seems to be very polished and is very comfortable for me to work with. For me, the difference, in feel, between Xcode and Eclipse is similar to the difference between a Mac computer and a Windows computer.

     

    And with Java on the Android platform, even though Java handles garbage collection automatically for you, this has actually turned out to be a pain the neck in some cases where you need real time performance and responsiveness. I developed one game, for the Android platform, where the game would pause for 100-200 milliseconds to do its garbage collection, which was fairly unacceptable. I ended up having to work around it by object pooling to reuse objects and tracking down numerous cases where I was creating objects inside the game loop. Fun stuff .

     

    Now, I actually prefer Objective-C over Java.  .

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.