How to compare Objective-C with C #?

Question

I recently purchased a Mac and used it mainly for developing C # for VMWare Fusion. With all the great Mac apps around me, I started thinking that Xcode hides only on the installation click and learns Objective-C.

The syntax between the two languages ​​looks very different, apparently because Objective-C has its origin in C and C #, its origin occurs in Java / C ++. But various syntaxes can be recognized, so this should be fine.

My main concern is working with the language, and if it helps to create well-structured, readable, and elegant code. I really like functions like LINQ and var in C #, and I wonder if there are equivalents or better / different functions in Objective-C.

What language features do I miss developing with Objective-C? What features will I get?

Edit:. Rational comparisons are useful and interesting, but language comparisons are what really ask this question (partly my mistake for initial marking with .net ). Presumably, both Cocoa and .NET are very rich frameworks on their own, and both have their own purpose, one designed for Mac OS X and other Windows.

Thanks for the well thought out and reasonably balanced point of view so far!

Answer 1

The language is not ideal for all tasks, and Objective-C is no exception, but there are some specific subtleties. Like using LINQ and var (for which I do not know about direct replacement), some of them are strictly related to the language, while others are related to the framework.

( NOTE: Just as C # is closely related to .NET, Objective-C is closely related to Cocoa. Consequently, some of my points may seem unrelated to Objective-C, but Objective-C without Cocoa is akin to C # without. NET / WPF / LINQ, runs on Mono, etc. It's just not the way it is usually done.)

I will not pretend to fully understand the differences, pluses and minuses, but here are some of them that come to mind.

• One of the best parts of Objective-C is the dynamic nature, and not the calling methods, you send messages that dynamic routes run dynamically. Combined (reasonably) with dynamic typing, this can make many powerful templates simpler or even trivial to implement.

• As a strict superset of C, Objective-C trusts that you know what you are doing. Unlike a controlled and / or typical approach to languages ​​such as C # and Java, Objective-C allows you to do what you want and experience the consequences. Obviously, this can be dangerous from time to time, but the fact that the language does not prevent you from doing most things is quite effective. ( EDIT: I should clarify that C # also has “unsafe” functions and functionality, but by default they are controlled by code that you must explicitly refuse. For comparison, Java only allows you to use type code and never outputs raw pointers like this as C and others do.)

• Categories (adding / modifying methods in a class without a subclass or accessing the source) is an amazing double-edged sword. It can greatly simplify inheritance hierarchies and eliminate code, but if you do something weird, the results can sometimes be puzzling.

• Cocoa greatly simplifies the creation of GUI applications, but you need to wrap it around a paradigm. The MVC design is widespread in Cocoa, and templates such as delegates, notifications, and multi-threaded GUI applications are well suited for Objective-C.

• Cocoa bindings and monitoring key values ​​can eliminate tons of glue code, and Cocoa frameworks use this extensively. Objective-C dynamic distribution works hand in hand with this, so the type of an object does not matter as long as it is compatible with the key.

• Most likely, you will miss childbirth and namespaces, and they have their own advantages, but in the thinking and paradigm of Objective-C they will be more subtleties than needs. (Generics is all about type safety and avoiding casting, but dynamic typing in Objective-C makes this essentially not a problem. Namespaces would be nice if everything was fine, but it's simple enough to avoid conflicts that might outweigh the benefits, especially for legacy code.)

• For concurrency, Blocks (a new language feature in Snow Leopard and implemented in Cocoa's many APIs) are extremely useful. A few lines (often in conjunction with Grand Central Dispatch, which is part of libsystem at 10.6), can eliminate a significant pattern of callback functions, context, etc. (Blocks can also be used in C and C ++ and can be added to C # which would be great.) NSOperationQueue is also a very convenient way to add concurrency to your own code by sending either custom NSOperation subclasses or anonymous blocks that GCD automatically executes for one or more different threads for you.

  / li>

Answer 2

I have been programming in C, C ++ and C # for over 20 years, first started working in 1990. I just decided to look at the iPhone and Xcode and Objective-C developments. Oh my god ... all the complaints about Microsoft that I take away now I understand how bad the code was. Objective-C compared to what C # does. I was spoiled by C #, and now I appreciate all the hard work Microsoft has put in. Just reading Objective-C using methods makes it difficult to read. C # is elegant at that. This is just my opinion, I was hoping that the Apple development language was as good as Apple products, but dear, they have a lot to learn from Microsoft. There is no problem with a C # .NET application. I can get the application faster and faster than Xcode Objective-C. Apple, of course, should take a sheet from a Microsoft book here, and then we will have a perfect environment. :-)

Answer 3

There is no technical review here, but I just find Objective-C much less readable. Given an example, Cinder6 gave you:

FROM#

 List<string> strings = new List<string>(); strings.Add("xyzzy"); // takes only strings strings.Add(15); // compiler error string x = strings[0]; // guaranteed to be a string strings.RemoveAt(0); // or non-existant (yielding an exception) 

Objective-c

 NSMutableArray *strings = [NSMutableArray array]; [strings addObject:@"xyzzy"]; [strings addObject:@15]; NSString *x = strings[0]; [strings removeObjectAtIndex:0]; 

It looks awful. I even tried to read 2 books, they lost me early, and usually I do not get this with books / programming languages.

I am glad that we have Mono for Mac OS, because if I had to rely on Apple to give me a good development environment ...

Answer 4

Manual memory management has something newbies to Objective-C seem to have a big problem, mainly because they find it more complicated than it is.

Objective-C and Cocoa expand on reliance on enforcement agreements; Know and follow very small rule sets, and you get a lot of free dynamic runtime in return.

The rule is not 100% true, but good enough for everyday:

• Each alloc call must match release at the end of the current scope.
• If the return value for your method was obtained using alloc , then it should be returned return [value autorelease]; instead of matching release .
• Use properties, and there is no rule three.

The following is a more detailed explanation.

Memory management is based on ownership; only the owner of the object instance should ever release the object, each else should always do nothing. This means that in 95% of all code, you process Objective-C as if it were going to garbage.

What about the remaining 5%? You have three methods to search, any instance of the object obtained from this method belongs to the current scope of the method:

• alloc
• Any method starting with the word new, for example new or newService .
• Any method containing the word copy, for example copy and mutableCopy .

The method has three possible options for what to do with object instances belonging to it before it is released:

• Release it using release if it is no longer needed.
• Grant ownership of field a (instance variable) or global variable simply by assigning it.
• Give up ownership, but give someone the opportunity to take ownership before the instance leaves by calling autorelease .

So, when should you actively participate by invoking retain ? Two cases:

• When assigning fields in your initializers.
• When manually implementing the setter method.

Answer 5

Of course, if all you've seen in your life is Objective-C, then its syntax looks like the only one possible. We could call you a "programming virgin."

But since a lot of code is written in C, C ++, Java, JavaScript, Pascal and other languages, you will see that ObjectiveC is different from all of them, but not in a good way. Do they have a reason for this? Let's see other popular languages:

C ++ added many advanced features to C, but it changed the original syntax only as much as needed.

C # added a lot of extras compared to C ++, but only changed what was ugly in C ++ (for example, removing "::" from the interface).

Java has changed many things, but retained the familiar syntax, except for the parts where this change was necessary.

JavaScript is a fully dynamic language that can do many things that ObjectiveC cannot. However, its creators did not invent a new way to call methods and pass parameters to be different from the rest of the world.

Visual Basic may pass parameters out of order like ObjectiveC. You can name the parameters, but you can also pass them in the usual way. No matter what you use, this is the usual comma-delimited way that everyone understands. Comma is a common delimiter not only in programming languages, but also in books, newspapers, and in written language in general.

The Pascal object has a different syntax than C, but its syntax is actually EASIER readable for the programmer (maybe not for the computer, but who cares about what the computer thinks). So maybe they backtracked, but at least their result is better.

Python has a different syntax that is even easier to read (for people) than Pascal. Therefore, when they changed it, making it different, at least they helped us programmers.

And then we have ObjectiveC. We add some improvements to C, but coming up with our own interface syntax, method call, passing parameters, and what not. I wonder why they have not changed + and - so plus subtracts two numbers. It would be even colder.

Steve Jobs screwed up by supporting ObjectiveC. Of course, he cannot support C #, which is better, but belongs to his worst competitor. So this is a political decision, not a practical one. Technology always suffers when technical decisions are made for political reasons. He must lead the company that he is doing good, and leave the programming questions to real experts.

I'm sure there will be even more applications for the iPhone if he decides to write iOS and support libraries in any language other than ObjectiveC. For everyone but skilled fans, virgin programmers, and Steve Jobs, ObjectiveC looks funny, ugly, and repulsive.

Answer 6

One thing I like about objective-c is that the object system is message-based, it allows you to do really nice things that you couldn't do in C # (at least as long as they don't support the dynamic keyword !).

Another important thing in writing cocoa applications is the Builder interface, which is much better than the form designer in Visual Studio.

As for obj-c, which annoys me (as a C # developer), it is the fact that you need to manage your own memory (there is garbage collection, but this does not work on the iPhone) and that it can be very verbose due to the selector syntax and all [].

Answer 7

As a programmer starting with Objective-C for the iPhone, starting with C # 4.0, I miss the lambda expressions and, in particular, Linq-to-XML. Lambda expressions are C # -specific, while Linq-to-XML is really more different than .NET and Cocoa. In the example application that I wrote, I had some XML in the string. I wanted to parse the elements of this XML into a collection of objects.

To accomplish this in Objective-C / Cocoa, I had to use the NSXmlParser class . This class relies on another object that implements the NSXMLParserDelegate protocol with methods that call (read: sent messages) when the open item tag is read, when some data is read (usually inside the item), and when some end item tag is read. You need to keep track of parsing status and status. And I honestly have no idea what will happen if the XML is invalid. This is great for going into the details and optimizing performance, but about a person that has a lot of code.

In contrast, here is the code in C #:

 using System.Linq.Xml; XDocument doc = XDocument.Load(xmlString); IEnumerable<MyCustomObject> objects = doc.Descendants().Select( d => new MyCustomObject{ Name = d.Value}); 

And what is it, you have a collection of custom objects taken from XML. If you want to filter these elements by value or only those that contain a certain attribute, or you just need the first 5 or skip the first 1 and get the next 3 or just find out if any elements were returned ... BAM, all in one line of code.

There are many open source classes that greatly facilitate this processing in Objective-C, which does most of the heavy lifting. It just isn't built in.

* NOTE: I have not actually compiled the above code, it just means an example illustrating the relative lack of details required by C #.

Answer 8

Probably the most important difference is memory management. With C # you get garbage collection, thanks to the fact that it is the CLR language. With Objective-C, you need to manage memory yourself.

If you are working in the background of C # (or in any modern language), switching to a language without automatic memory management will be very painful, as you will spend a lot of time correctly managing memory (and debugging).

Answer 9

Here is a pretty good article comparing two languages: http://www.coderetard.com/2008/03/16/c-vs-objective-c/

Answer 10

The method call used in obj-c make for easily readable code is, in my opinion, much more elegant than C #, and obj-c is built on top of c, so all c-code should work fine in obj-c. The big seller for me is that obj-c is an open standard, so you can find compilers for any system.

Answer 11

Besides the differences in the paradigm between the two languages, there is not much difference. As much as I hate to say this, you can do the same (perhaps not as easy) with .NET and C # as you can with Objective-C and Cocoa. Starting with Leopard, Objective-C 2.0 has garbage collection, so you do not need to manage the memory yourself if you do not want (code compatibility with older Macs and iPhone applications are 2 reasons).

As for structured, readable code, most of the burden lies with the programmer, like in any other language. However, I find that the messaging paradigm reads well for readable code if you name your functions / methods appropriately (again, like any other language).

I will be the first to admit that I am not very familiar with C # or .NET. But the reasons mentioned above are many reasons why I do not want to do this.