Come si confronta Objective-C con C #? [chiuso]

Di recente ho acquistato un Mac e lo utilizzo principalmente per lo sviluppo C # con VMWare Fusion. Con tutte le belle applicazioni per Mac in giro, ho iniziato a pensare a Xcode in agguato a un clic di distanza e ad imparare Objective-C.

La sintassi tra i due linguaggi sembra molto diversa, presumibilmente perché Objective-C ha le sue origini in C e C # ha le sue origini in Java / C ++. Ma è possibile apprendere diverse sintassi, quindi dovrebbe essere OK.

La mia preoccupazione principale è lavorare con il linguaggio e se aiuterà a produrre codice ben strutturato, leggibile ed elegante. Mi piacciono molto le funzionalità come LINQ e var in C # e mi chiedo se ci siano equivalenti o funzionalità migliori / diverse in Objective-C.

Quali caratteristiche del linguaggio mi mancheranno sviluppando con Objective-C? Quali caratteristiche otterrò?

Modifica: i confronti del framework sono utili e interessanti ma un confronto linguistico è ciò che questa domanda sta veramente chiedendo (in parte colpa mia per aver taggato originariamente con .net). Presumibilmente sia Cocoa che .NET sono framework molto ricchi di per sé ed entrambi hanno il loro scopo, uno rivolto a Mac OS X e l'altro a Windows.

Grazie per i punti di vista ben congegnati e ragionevolmente equilibrati finora!

Nessuna lingua è perfetta per tutte le attività e Objective-C non fa eccezione, ma ci sono alcune sottigliezze molto specifiche. Come l'utilizzo di LINQe var(per il quale non sono a conoscenza di una sostituzione diretta), alcuni di questi sono strettamente correlati al linguaggio e altri sono correlati al framework.

( NOTA: proprio come C # è strettamente accoppiato con .NET, Objective-C è strettamente accoppiato con Cocoa. Quindi, alcuni dei miei punti potrebbero sembrare estranei a Objective-C, ma Objective-C senza Cocoa è simile a C # senza .NET / WPF / LINQ, in esecuzione sotto Mono e così via. Semplicemente non è il modo in cui le cose vengono fatte normalmente.)

Non pretendo di elaborare completamente le differenze, i pro e i contro, ma eccone alcuni che saltano in mente.

• Una delle parti migliori di Objective-C è la natura dinamica: invece di chiamare metodi, invii messaggi, che il runtime instrada dinamicamente. Combinato (giudiziosamente) con la digitazione dinamica, questo può rendere molti modelli potenti più semplici o addirittura banali da implementare.

• In quanto superinsieme rigoroso di C, Objective-C confida che tu sappia cosa stai facendo. A differenza dell'approccio gestito e / o typesafe di linguaggi come C # e Java, Objective-C ti consente di fare ciò che desideri e sperimentarne le conseguenze. Ovviamente questo a volte può essere pericoloso, ma il fatto che la lingua non ti impedisca attivamente di fare la maggior parte delle cose è abbastanza potente. ( MODIFICA: dovrei chiarire che C # ha anche caratteristiche e funzionalità "non sicure", ma il loro comportamento predefinito è codice gestito, che devi disattivare esplicitamente. In confronto, Java consente solo codice typesafe e non espone mai puntatori non elaborati in come fanno C e altri.)

• Le categorie (aggiungere / modificare metodi su una classe senza sottoclassi o avere accesso alla sorgente) è un'arma a doppio taglio impressionante. Può semplificare enormemente le gerarchie di ereditarietà ed eliminare il codice, ma se fai qualcosa di strano, i risultati a volte possono essere sconcertanti.

• Cocoa rende la creazione di app GUI molto più semplice in molti modi, ma devi avvolgere la testa attorno al paradigma. Il design MVC è pervasivo in Cocoa e modelli come delegati, notifiche e app GUI multi-thread sono adatti a Objective-C.

• Le associazioni Cocoa e l'osservazione dei valori-chiave possono eliminare tonnellate di codice collante e le strutture Cocoa sfruttano ampiamente questo aspetto. L'invio dinamico di Objective-C funziona di pari passo con questo, quindi il tipo di oggetto non ha importanza fintanto che è conforme al valore-chiave.

• Probabilmente ti mancheranno i generici e gli spazi dei nomi, e hanno i loro benefici, ma nella mentalità e nel paradigma Objective-C, sarebbero sottigliezze piuttosto che necessità. (I generici sono tutti incentrati sulla sicurezza dei tipi e sull'evitare il casting, ma la digitazione dinamica in Objective-C lo rende essenzialmente un non-problema. Gli spazi dei nomi sarebbero carini se fatti bene, ma è abbastanza semplice da evitare conflitti che il costo probabilmente supera i benefici, soprattutto per il codice legacy.)

• Per la concorrenza, i blocchi (una nuova funzionalità del linguaggio in Snow Leopard e implementata in decine di API Cocoa) sono estremamente utili. Poche righe (spesso accoppiate a Grand Central Dispatch, che fa parte di libsystem nella versione 10.6) possono eliminare un boilerplate significativo di funzioni di callback, contesto, ecc. (I blocchi possono essere utilizzati anche in C e C ++ e potrebbero certamente essere aggiunti a C #, il che sarebbe fantastico.) NSOperationQueue è anche un modo molto conveniente per aggiungere concorrenza al tuo codice, inviando sottoclassi NSOperation personalizzate o blocchi anonimi che GCD esegue automaticamente su uno o più thread diversi per te.

Sto programmando in C, C ++ e C # da oltre 20 anni, ho iniziato nel 1990. Ho appena deciso di dare un'occhiata allo sviluppo di iPhone e Xcode e Objective-C. Oh mio Dio ... riprendo tutte le lamentele su Microsoft, ora mi rendo conto di quanto siano state brutte le cose del codice. Objective-C è più complesso rispetto a ciò che fa C #. Sono stato viziato con C # e ora apprezzo tutto il duro lavoro svolto da Microsoft. La lettura di Objective-C con invocazioni di metodo è difficile da leggere. Il C # è elegante in questo. Questa è solo la mia opinione, speravo che il linguaggio di sviluppo Apple fosse buono come i prodotti Apple, ma carissimo, hanno molto da imparare da Microsoft. Non ci sono dubbi sull'applicazione C # .NET, posso far funzionare un'applicazione molte volte più velocemente di XCode Objective-C. Apple dovrebbe sicuramente prendere una foglia dal libro di Microsoft qui e allora avremmo l'ambiente perfetto. :-)

Nessuna recensione tecnica qui, ma trovo che Objective-C sia molto meno leggibile. Dato l'esempio che Cinder6 ti ha dato:

C #

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)

Obiettivo-C

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

Sembra orribile. Ho anche provato a leggere 2 libri su di esso, mi hanno perso all'inizio e normalmente non lo capisco con i libri / linguaggi di programmazione.

Sono contento di avere Mono per Mac OS, perché se dovessi fare affidamento su Apple per darmi un buon ambiente di sviluppo ...

La gestione manuale della memoria è qualcosa con cui i principianti di Objective-C sembrano avere più problemi, soprattutto perché pensano che sia più complessa di quanto non sia.

Objective-C e Cocoa si basano per estensione su convenzioni sull'applicazione; conoscere e seguire una serie molto piccola di regole e in cambio ottieni molto gratuitamente dal tempo di esecuzione dinamico.

La regola non vera al 100%, ma abbastanza valida per tutti i giorni è:

• Ogni chiamata a allocdovrebbe essere abbinata a una releasealla fine dell'ambito corrente.
• Se il valore restituito per il metodo è stato ottenuto entro alloc, dovrebbe essere restituito da return [value autorelease];invece di essere abbinato a un file release.
• Usa le proprietà e non esiste una regola tre.

Segue la spiegazione più lunga.

La gestione della memoria si basa sulla proprietà; solo il proprietario di un'istanza di oggetto dovrebbe mai rilasciare l'oggetto, tutti altri dovrebbero sempre non fare nulla. Ciò significa che nel 95% di tutto il codice si tratta Objective-C come se fosse stato raccolto dalla spazzatura.

E il restante 5%? Hai tre metodi a cui prestare attenzione, qualsiasi istanza di oggetto ricevuta da questi metodi è di proprietà dell'ambito del metodo corrente :

• alloc
• Qualsiasi metodo che inizia con la parola nuovo , come newo newService.
• Qualsiasi metodo contenente la parola copia, come copye mutableCopy.

Il metodo ha tre possibili opzioni su cosa fare con le sue istanze di oggetti di proprietà prima che esca:

• Rilascialo usando releasese non è più necessario.
• Assegna la proprietà a un campo (variabile di istanza) o una variabile globale semplicemente assegnandola.
• Rinuncia alla proprietà ma offri a qualcun altro la possibilità di prenderne possesso prima che l'istanza scompaia chiamando autorelease.

Quindi quando dovresti assumerti la proprietà in modo proattivo chiamando retain? Due casi:

• Quando si assegnano i campi negli inizializzatori.
• Quando si implementa manualmente il metodo setter.

Certo, se tutto ciò che hai visto nella tua vita è Objective C, la sua sintassi sembra l'unica possibile. Potremmo chiamarti una "vergine della programmazione".

Ma poiché molto codice è scritto in C, C ++, Java, JavaScript, Pascal e altri linguaggi, vedrai che ObjectiveC è diverso da tutti loro, ma non in senso positivo. Avevano una ragione per questo? Vediamo altre lingue popolari:

C ++ ha aggiunto molti extra al C, ma ha cambiato la sintassi originale solo quanto necessario.

C # ha aggiunto molti extra rispetto a C ++ ma ha cambiato solo le cose che erano brutte in C ++ (come rimuovere "::" dall'interfaccia).

Java ha cambiato molte cose, ma ha mantenuto la sintassi familiare tranne nelle parti in cui era necessaria la modifica.

JavaScript è un linguaggio completamente dinamico che può fare molte cose che ObjectiveC non può fare. Tuttavia, i suoi creatori non hanno inventato un nuovo modo di chiamare metodi e passare parametri solo per essere diversi dal resto del mondo.

Visual Basic può passare parametri fuori ordine, proprio come ObjectiveC. È possibile assegnare un nome ai parametri, ma è anche possibile passarli regolarmente. Qualunque cosa tu usi, è un normale modo delimitato da virgole che tutti capiscono. La virgola è il solito delimitatore, non solo nei linguaggi di programmazione, ma nei libri, nei giornali e nel linguaggio scritto in generale.

Object Pascal ha una sintassi diversa dal C, ma la sua sintassi è in realtà PIÙ FACILE da leggere per il programmatore (forse non per il computer, ma a chi importa cosa pensa il computer). Quindi forse hanno divagato, ma almeno il loro risultato è migliore.

Python ha una sintassi diversa, che è ancora più facile da leggere (per gli esseri umani) rispetto a Pascal. Quindi, quando l'hanno cambiato, rendendolo diverso, almeno l'hanno reso migliore per noi programmatori.

E poi abbiamo ObjectiveC. Aggiunta di alcuni miglioramenti a C, ma inventando la propria sintassi di interfaccia, chiamata di metodo, passaggio di parametri e cosa no. Mi chiedo perché non hanno scambiato + e - in modo che più sottrae due numeri. Sarebbe stato ancora più bello.

Steve Jobs ha sbagliato sostenendo ObjectiveC. Ovviamente non può supportare C #, che è meglio, ma appartiene al suo peggior concorrente. Quindi questa è una decisione politica, non pratica. La tecnologia soffre sempre quando le decisioni tecnologiche vengono prese per motivi politici. Dovrebbe guidare l'azienda, cosa che fa bene, e lasciare le questioni di programmazione a veri esperti.

Sono sicuro che ci sarebbero ancora più app per iPhone se decidesse di scrivere iOS e supportare le librerie in qualsiasi lingua diversa da ObjectiveC. Per tutti tranne che per i fan accaniti, i programmatori vergini e Steve Jobs, ObjectiveC sembra ridicolo, brutto e ripugnante.

Una cosa che amo di Objective-C è che il sistema a oggetti si basa sui messaggi, ti consente di fare cose davvero carine che non potresti fare in C # (almeno non finché non supportano la parola chiave dinamica!).

Un'altra cosa grandiosa dello scrivere app di cacao è Interface Builder, è molto più bello del designer di moduli in Visual Studio.

Le cose su obj-c che mi infastidiscono (come sviluppatore C #) sono il fatto che devi gestire la tua memoria (c'è la raccolta dei rifiuti, ma non funziona su iPhone) e che può essere molto prolisso a causa di la sintassi del selettore e tutti i [].

Come programmatore che ha appena iniziato con Objective-C per iPhone, proveniente da C # 4.0, mi mancano le espressioni lambda e, in particolare, Linq-to-XML. Le espressioni lambda sono specifiche per C #, mentre Linq-to-XML è in realtà più un contrasto tra .NET e Cocoa. In un'app di esempio che stavo scrivendo, avevo dell'XML in una stringa. Volevo analizzare gli elementi di tale XML in una raccolta di oggetti.

Per ottenere ciò in Objective-C / Cocoa, ho dovuto utilizzare la classe NSXmlParser . Questa classe si basa su un altro oggetto che implementa NSXMLParserDelegate protocollo con metodi che vengono chiamati (lettura: messaggi inviati) quando viene letto un tag di apertura di un elemento, quando vengono letti alcuni dati (di solito all'interno dell'elemento) e quando viene letto un tag di fine elemento . Devi tenere traccia dello stato e dello stato dell'analisi. E onestamente non ho idea di cosa succede se l'XML non è valido. È fantastico per scendere nei dettagli e ottimizzare le prestazioni, ma oh uomo, è un sacco di codice.

Al contrario, ecco il codice in C #:

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

E questo è tutto, hai una raccolta di oggetti personalizzati tratti da XML. Se vuoi filtrare quegli elementi per valore, o solo quelli che contengono un attributo specifico, o se vuoi solo i primi 5, o saltare il primo 1 e ottenere i successivi 3, o semplicemente scoprire se sono stati restituiti degli elementi ... BAM, tutto qui nella stessa riga di codice.

Esistono molte classi open source che rendono questa elaborazione molto più semplice in Objective-C, quindi questo fa gran parte del lavoro pesante. Semplicemente non è integrato.

* NOTA: in realtà non ho compilato il codice sopra, è solo inteso come esempio per illustrare la relativa mancanza di verbosità richiesta da C #.

Probabilmente la differenza più importante è la gestione della memoria. Con C # ottieni la garbage collection, in virtù del fatto che è un linguaggio basato su CLR. Con Objective-C devi gestire la memoria da solo.

Se provieni da uno sfondo C # (o da qualsiasi linguaggio moderno per quella materia), passare a un linguaggio senza gestione automatica della memoria sarà davvero doloroso, poiché trascorrerai molto del tuo tempo di codifica per gestire correttamente la memoria (e il debug come bene).

Ecco un buon articolo che mette a confronto le due lingue: http://www.coderetard.com/2008/03/16/c-vs-objective-c/

A parte la differenza di paradigma tra le 2 lingue, non c'è molta differenza. Per quanto odio dirlo, puoi fare lo stesso tipo di cose (probabilmente non così facilmente) con .NET e C # come puoi fare con Objective-C e Cocoa. A partire da Leopard, Objective-C 2.0 ha la garbage collection, quindi non lo fai dovete gestire la memoria da soli se non si desidera (la compatibilità del codice con i Mac più anziani e applicazioni per iPhone sono 2 motivi per voler).

Per quanto riguarda il codice strutturato e leggibile, gran parte dell'onere ricade sul programmatore, come su qualsiasi altro linguaggio. Tuttavia, trovo che il paradigma di trasmissione dei messaggi si presta bene a codice leggibile a condizione che tu chiami le tue funzioni / metodi in modo appropriato (di nuovo, proprio come qualsiasi altro linguaggio).

Sarò il primo ad ammettere che non ho molta familiarità con C # o .NET. Ma le ragioni sopra elencate da Quinn sono alcune delle ragioni per cui non mi interessa diventarlo.

Le chiamate al metodo usate in obj-c rendono il codice facilmente leggibile, a mio parere molto più elegante di c # e obj-c è costruito sopra c quindi tutto il codice c dovrebbe funzionare bene in obj-c. Il grande venditore per me, però, è che obj-c è uno standard aperto, quindi puoi trovare compilatori per qualsiasi sistema.