Recientemente he comprado un Mac y lo uso principalmente para C# desarrollo bajo VMWare Fusion. Con todos los bonitos aplicaciones de Mac de todo he empezado a pensar en Xcode que acechan instalar un clic de distancia, y el aprendizaje de Objective-C.

La sintaxis entre los dos idiomas se ve muy diferente, presumiblemente debido a Objective-C tiene sus orígenes en C y C# tiene sus orígenes en Java/C++. Pero sintaxis diferentes puede ser aprendido de modo que se debe ACEPTAR.

Mi principal preocupación es que trabaja con el lenguaje, y si se le ayuda a producir bien estructurado, legible y elegante de código. Yo realmente disfrutar de características tales como LINQ y var en C# y me pregunto si hay equivalentes o mejor/características diferentes en Objective-C.

¿Qué características del lenguaje le echo de menos en vías de desarrollo con Objective-C? ¿Qué características le voy a ganar?

Edición: El marco comparaciones son útiles y muy interesante, pero un idioma comparación se lo esta pregunta es realmente preguntando (en parte por mi culpa por que originalmente marcado con .net). Presumiblemente tanto el Cacao y el .NET son muy ricos marcos en su propio derecho y ambos tienen su propósito, orientación Mac OS X y el otro Windows.

Gracias por el bien del pensamiento hacia fuera y razonablemente equilibrada de los puntos de vista hasta ahora!

  • Xcode no es perfecto, pero sin duda tiene un montón de potentes y útiles características. Despectivo algo como «pura maldad» sin copias de seguridad o la prestación de cualquier contexto para la comparación es FUD que no ayuda a nadie. En cualquier caso, es irrelevante para la pregunta.
  • Xcode 3.2 es posiblemente el mejor IDE que he usado, con su elegante punto de interrupción de la manipulación, el análisis estático, en línea mensajes de error y un montón de otras características. Por cierto, es «Xcode» y no «XCode». @Nathan, yo realmente no veo por qué usted necesita para denigrar a Xcode, calificándola de «pura maldad» – sin justificación alguna-en un debate sobre las lenguas.
  • Una gran cosa que usted va a obtener mediante el uso de Objective-C es que usted tendrá acceso a el Cacao marcos. También, C, C#, Java y C++, todos comparten un común sintáctica del patrimonio. Objective-C se presenta la sintaxis de Smalltalk.
  • También vale la pena señalar que el Java y (posiblemente en menor medida) C# obtenemos el objeto de la semántica de Smalltalk, como Objective-C, mientras que C++ es más influenciado por la Simula.
  • en todo caso, yo diría que el Java y, sobre todo, C# (con explícita virtual) están mucho más cerca Simula que a Smalltalk. Smalltalk es dinámicamente tipado y que se ocupa de los mensajes. Simula es de tipo estático y que se ocupa de los métodos. Supongo que uno Java/C# otoño bajo.
  • Me debería haber dado cuenta con mi comentario anterior que la falta de Xcode odio es probablemente debido a la C# y .NET etiquetas. Me vino a la pregunta de la Objective-C, etiqueta, así que hay que ir… con toda honestidad, yo prefiero las herramientas Xcode, pero definitivamente hay aspectos de VisualStudio que espero hacer su camino en Xcode. Dicho esto, me encanta para un VisualStudio adicto a mostrarme un equivalente a los Instrumentos o el Xcode Analizador Estático para C#/.NETA… 🙂
  • La parte interesante de la lengua de herencia/similitud pregunta es que Java fue realmente inspirado en gran medida por el Objetivo-C (virtualschool.edu/objectivec/influenceOnJava.html), y creo que C# es muy similar, por lo que a pesar de que no uso Smalltalk-estilo de mensajería o de tipado dinámico, probablemente desde Simula lo que usted podría pensar en un principio…
  • Studio (2010), es lo que yo llamaría horrible. Se tarda una eternidad en cargar y para iniciar un nuevo proyecto, y la interfaz es demasiado desordenado. En cuanto al idioma se va, Objective-C, en su mayoría ha sido desarrollado por Apple, por lo que es mutuamente diseñado para el Cacao. Uno de los Obj-C, el diseño de los objetivos para que se lea como el inglés, Java y C# retener la más C-como la convención de usar las contracciones dentro de los nombres que lo hacen parecer más como el «código».
  • C# reglas. Período! (15 años de experiencia). Objective-C ok…. entonces. Ahora me gusta la codificación elegante y fácil como sea posible. .NET -> C# hace todo. (LINQ = wow), no se equivoquen.
  • Hacer C# trabajo utilizando VMWare fusion? Sólo utilice mono y monodevelop (que es una versión open source de .NET y Visual Studio que funciona en Mac y Linux. El uso de Mono también puede crear Mac y iPhone aplicaciones con C# y a la vez utilizar el .Biblioteca de RED, así como el Cacao…
  • C# es mucho mejor que el objective-C,…, C# y java son agradables productivo idiomas.. obj-c es feo y muchas molestias… pero que es lo que usted está atascado con , en general,.. pero también se puede utilizar mono para mac o iphone
  • 15 años de experiencia en el uso de C#? Fue lanzado en 2001!

InformationsquelleAutor Alex Angas | 2009-09-02

11 Comentarios

  1. 89

    Ninguna lengua es perfecto para todas las tareas, y Objective-C no es la excepción, pero hay algunos muy específicos de sutilezas. Como el uso de LINQ y var (para los que no soy consciente de un reemplazo directo), algunos de estos son estrictamente relacionados con la lengua, y otros son de marco.

    (NOTA: como C# está estrechamente ligado con .NET, Objective-C es fuertemente junto con el Cacao. Por lo tanto, algunos de mis puntos pueden parecer ajenas a Objective-C, pero Objective-C sin Cacao es similar a la de C# sin .NET /WPF /LINQ, que se ejecuta bajo Mono, etc. Es sólo la forma en que las cosas se hacen generalmente.)

    No pretendo totalmente elaborar las diferencias, pros y contras, pero aquí hay algunos que saltan a la mente.

    • Una de las mejores partes de Objective-C es la dinámica de la naturaleza en lugar de llamar a los métodos, enviar mensajes, que el tiempo de ejecución de las rutas de forma dinámica. Combinado (con prudencia) con tipado dinámico, esto puede hacer una gran cantidad de potentes patrones más simples o incluso trivial de implementar.

    • Como un estricto superconjunto de C, Objective-C, confía en que sabes lo que estás haciendo. A diferencia de los administrados y/o typesafe enfoque de lenguajes como C# y Java, Objective-C permite hacer lo que usted quiere experimentar las consecuencias. Obviamente, esto puede ser peligroso a veces, pero el hecho de que la lengua no activamente impiden hacer la mayoría de cosas es bastante potente. (EDICIÓN: debo aclarar que C# también se ha «inseguros» características y la funcionalidad, pero el comportamiento predeterminado es el código administrado, que tienes para anular de forma explícita. Por comparación, Java sólo permite typesafe código, y nunca se expone la cruda punteros en la forma en que C y otros.)

    • Categorías (agregar/modificar los métodos de una clase sin subclases o tener acceso a la fuente) es una impresionante espada de doble filo. Puede simplifican enormemente las jerarquías de herencia y eliminar el código, pero si haces algo extraño, los resultados pueden ser a veces desconcertante.

    • De cacao hace que la creación de la GUI de aplicaciones mucho más fácil, en muchas maneras, pero usted tiene que envolver su cabeza alrededor del paradigma. De diseño MVC, es omnipresente, está en el Cacao, y los patrones como los delegados, las notificaciones, y multihilo, GUI, aplicaciones están bien adaptados a Objective-C.

    • Cacao enlaces y pares clave-valor de la observación puede eliminar toneladas de código de pegamento, y el Cacao marcos aprovechar esta ampliamente. Objective-C del envío dinámico, trabaja de la mano con esto, por lo que el tipo del objeto, no importa el tiempo es clave-valor que cumple.

    • Es probable que usted pierda medicamentos genéricos y de los espacios de nombres, y tienen sus beneficios, pero en Objective-C mentalidad y paradigma, que sería sutilezas en lugar de las necesidades. (Los medicamentos genéricos son todos acerca de la seguridad y evitando la colada, pero tipado dinámico en Objective-C hace esto, en esencia, no es un problema. Los espacios de nombres sería agradable si se hace bien, pero es lo suficientemente simple como para evitar los conflictos que el costo podría decirse que es mayor que los beneficios, especialmente para el código de la herencia.)

    • Para la concurrencia, Bloques (una nueva característica del lenguaje en Snow Leopard, y aplicado en las puntuaciones de Cacao Api) son extremadamente útiles. Un par de líneas (con frecuencia junto con Grand Central Dispatch, que es parte de libsystem en 10.6) puede elimina de forma significativa repetitivo de funciones de devolución de llamada, el contexto, etc. (Los bloques también pueden ser utilizados en C y C++, y ciertamente podría ser añadido a C#, lo cual sería impresionante.) NSOperationQueue también es una forma muy conveniente de agregar la concurrencia para su propio código, mediante el envío personalizado NSOperation subclases o bloques anónimos que MCD automáticamente se ejecuta en uno o más subprocesos para usted.

    • Técnicamente, C# dispone de todos los no-tipo de poder a prueba de características que ObjC hace: raw punteros, aritmética de punteros, obligado-desmarcado de las matrices, los sindicatos, alloca. Simplemente no las hacen tan fácilmente accesibles, usted necesita para optar en forma explícita.
    • También, de sus puntos en el Cacao, obviamente, son aplicables a Cacao, en lugar de ObjC (hay otros enlaces de lenguajes de Cacao). Tampoco está claro lo que estamos comparando Cacao en contra – por ejemplo, WPF tiene todo lo que una lista así.
    • Yo simplemente mencionar Cacao debido a que la mayoría de la apelación de la programación en Objective-C es debido a que el Cacao marcos. Sería C# ser interesante, sin .NET y/o WPF? El autor de la pregunta se menciona específicamente LINQ, por lo que, obviamente, mirando más allá de la lengua, a la experiencia.
    • LINQ es una parte de C#el lenguaje en el sentido de que el lenguaje tiene soporte directo para LINQ construcciones (que hace que sea mucho más fácil de usar en algunas complicado de anidación de los casos).
    • Lo cual está bien. No estoy tratando de pelear con C#. Si tuviera que escribir el software de Windows, que es lo que yo uso. Estoy simplemente tratando de señalar las similitudes y diferencias entre las lenguas y las herramientas relacionadas. Eres muy obviamente más con experiencia en C#, y yo con Objective-C. agradezco tus aclaraciones, pero tal vez lo más constructivo respuestas y menos pelo-división será más útil.
    • No es el pelo de división, Quinn. Yo simplemente señaló que lo que comenzó como un lenguaje de comparación se convirtió en la discusión general de cómo el Cacao es bueno en algún momento de su respuesta. Todavía me gustaría señalar que sus puntos sobre el Cacao, no comparaciones – dicen que «X bien» – y que bien podría ser el caso – pero ellos no dicen «hace X mejor/peor que+de C#WPF», que es lo que la pregunta es ampliamente acerca de.
    • Eso es principalmente porque no estoy lo suficientemente familiarizado con el C# alternativas. A diferencia de los .NET, es casi siempre el caso de que el Cacao código es código Objective-C, que es la razón por la que me dijo que el pelo de la división. (Me imagino que C# de la gente supone .NET y considerar entornos como el Mono la excepción más que la regla, y es la misma que en el otro lado de la valla.) Con eso en mente, a ver si no he abordado el autor de la pregunta la pregunta final, en negrita…
    • Respecto a las nuevas incorporaciones a su respuesta: ObjC bloques son sólo de primera clase de las funciones anónimas, derecho? Si es así, C# dispone de ellos (como los delegados anónimos y de lambdas). Su uso específicamente en la concurrencia contexto está llegando .NET 4.0 – LINQ Paralelo. Java ha anónimo interior de las clases, que pueden servir en ese papel, a pesar de que no capturar mutable locales, y son extremadamente detallado para tal construcción.
    • Esa es una buena pregunta — Bloques son los cierres, pero no sé qué tan cerca están para su C# primos. Todos en todos, tienen un sonido bastante cerca. (Que son sin duda no es el mismo que anónimo interior de las clases en Java.) Bloques de captura ámbito que lo rodea (incluyendo las correspondientes variables locales) y se copian automáticamente en el montón como sea necesario. Que puede ser tratado de forma similar a las funciones anónimas, pero hay algunas diferencias sutiles. Una de las mayores diferencias, obviamente, es la capacidad para el envío de bloques con MCD.
    • +1 excelente respuesta de Quinn
    • Creo que es más relevante para comparar no sólo el idioma, sino el actual marco de interfaz de usuario: Cacao vs .Neta… Cuando se trata de iPhone vs Windows Phone: es mucho más fácil para iniciar en windows Phone 7. Sin embargo, muy rápidamente se da cuenta de lo extenso de Cacao en el iPhone. La documentación de Apple también es excepcional, un montón de detalles y ejemplos.

  2. 54

    He sido de programación en C, C++ y C# ahora por más de 20 años, comenzó en 1990. He decidido tener una mirada en el iPhone y desarrollo Xcode y Objective-C. Oh mi dios… todas las quejas acerca de Microsoft tomo atrás, me doy cuenta ahora de cómo las cosas malas de código han sido. Objective-C es más complejo en comparación con lo que C#. Me han echado a perder con C# y ahora aprecio todo el trabajo duro de Microsoft han puesto en. Sólo la lectura de Objective-C con el método invoca es difícil de leer. C# es elegante en esto. Es solo mi opinión, yo esperaba que el desarrollo de Apple fue una lengua bien como los productos de Apple, pero querido a mí, ellos tienen mucho que aprender de Microsoft. No hay ninguna pregunta C#.NET aplicación puedo conseguir una aplicación en funcionamiento muchas veces más rápido que XCode Objective-C. Apple sin duda debe tomar una hoja de Microsoft del libro aquí y entonces tendríamos el ambiente perfecto. 🙂

    • A pesar de que ha mirado en un iPhone dev libro que todavía son capaces de crear una aplicación más rápido en una plataforma a la que han de 20 años de experiencia en? INCREÍBLE
    • Tengo la misma experiencia que Waz. Yo también soy mucho más agradecido por el trabajo que Microsoft ha puesto en C# y las herramientas de desarrollo como Visual Studio, después de que he empezado a aprender Objective C.
    • Esa fue mi experiencia, así, mientras que el estudio de objective-c, overcomplexity en comparación con c#. @alexy13 Qué parte de la c y c++ desde el mensaje original perdido? Tener décadas de experiencia en una familia de lenguas es de gran ayuda para evaluar cómo de difícil es hacer el mismo trabajo con otra lengua de la misma familia.
    • Recientemente he comenzado a hacer el iPhone de desarrollo después de más de 15 años de MS de desarrollo y se encontró objetivo c multa después de que la curva de aprendizaje inicial. Pero como para conseguir una aplicación funcionando, Xcode ha sido una experiencia positiva para mí. El Mvc enfoque del desarrollo se siente mucho más maduro cuando dicen que en comparación con WPF del MVVM, que en las grandes equipos de desarrollo ha sido la causa de muchos técnicos de las guerras santas.
    • Desarrollamos grandes WPF, MVVM aplicaciones en nuestra empresa y todos sentimos que es, por lejos, el mejor patrón para construir fiable y robusto software en equipos grandes si bien aplicados.
    • cómo es esta respuesta? no es una concisa respuesta, sólo una clara opinión sesgada de algunos idiomas, aprendió la noche frente a un lenguaje que él ha estado utilizando más de 20 años…es obvio que no va a ser tan competente en el nuevo idioma
    • "Just reading Objective-C with method invokes is difficult to read" – he aquí un muy subjetiva argumento que se menciona aquí como los contras de Obj-C. Todas las demás es sólo discutible de la retórica.
    • OP no ha sido el uso de C# por más de veinte años; no ha sido tanto tiempo. Mire los dos primeros idiomas que menciona: esos son los antepasados de los Obj-C. Infierno, todo el código C es válido Obj-C.
    • -1 tengo 15 años de C/C++/C#/Obj-C a la experiencia y me parece que las acusaciones no se muy bien fundada. Carecen de mérito técnico y muy subjetivo – no ad rem, por así decirlo. Los lenguajes de programación son herramientas, sólo tenemos que encontrar las adecuadas para el trabajo.
    • -1 Todas las opiniones. Cero hechos.

  3. 46

    Sin revisión técnica aquí, pero acabo de encontrar Objective-C, mucho menos legible.
    Dado el ejemplo Cinder6 di:

    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)

    Objective-C

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

    Se ve horrible. Incluso traté de leer 2 libros sobre él, se perdió de mí desde el principio,
    y, normalmente, no entiendo que con los libros de programación /lenguajes.

    Me alegro de que te han Mono para Mac OS, porque si yo hubiera tenido que depender de Apple
    para darme un buen entorno de desarrollo…

    • Ignorando el hecho de que la 1ª línea debe terminar con [NSMutableArray array] lugar (es que es una fuga de memoria) y la 4ª línea debe comenzar con NSString* x o id x (error de compilación)… Sí, Objective-C, carece de medicamentos genéricos (yo, sinceramente, no los echo de menos), no de índice de objetos con la sintaxis de array, y las Api son generalmente más detallado. A-puede-a, a-mah-a. Realmente depende de lo que usted prefiere ver. (Puede escribir el mismo código en C++ STL y me gustaría pensar que fue horrible.) Para mí, un código legible a menudo significa que el texto del código le dice a usted lo que está haciendo, y por lo tanto el código Objective-C es preferible.
    • Yo realmente no encontrar nada malo con la sintaxis como tal – la razón principal por la que se siente menos legible es porque 1) es desconocida para todo el mundo procedente de C de fondo, y 2) se utiliza en el medio de la llanura C construcciones, donde se ve extranjero. Por otro lado, Smalltalkish nombre-parámetros-como-parte-de-método-nombre realmente hacer llamadas más comprensible desde el ir. De hecho, el ejemplo de código C#, así lo demuestra – no va a compilar, porque List<T>.Remove toma un string como argumento, y quita la primera occurenceof esa cadena. Para eliminar por índice, usted necesita RemoveAt.
    • … mientras que ObjC versión con removeObjectAtIndex:, mientras más detallado, también es inequívoca en cuanto a lo que hace.
    • Excelentes puntos, Pavel. También, la inconsistencia entre strings[0] y strings.RemoveAt(0) resta valor a la claridad, al menos para mí. (También, siempre me molesta cuando el método nombres que comienzan con una letra mayúscula… sé que es un pequeño problemita, pero es raro.)
    • Por otro lado, strings[0] es consistente con la llanura de matrices, y puede ser utilizado en el lado izquierdo del operador de asignación.
    • Lo cierto es que. La preferencia Personal de nuevo, pero me hubiera gustado sintaxis que las máscaras de los métodos con la notación de matriz. Quizá sea porque yo también uso llanura C matrices en la ocasión, y la mezcla de la notación haría daño código de la comprensión más que ayuda.
    • Me gustaría nota, ninguno de los ejemplos de código son míos, son tomadas de la página de alguien vinculado a los anteriores :p
    • Con los modernos Objective-C, esto sería:NSMutableArray *cadenas = @[]; [strings addObject:@15]; NSString *x = cadenas[0]; etc…
    • el poder de objetivo C crece en los métodos con múltiples argumentos.. oh dios como odio este tipo de cosas en c# esta.doSomething(a,b,c,d,e,g) y tener que comprobar siempre ¿qué diablos se supone que voy ajuste en qué espacio… yo mucho mejor como [auto doSomethingWith:un withColor:b alpha:c rotación:d escala:e optionalFlags:g]
    • no es que el mismo como parámetros con nombre en c# o es diferente en Objective-C?
    • no es exactamente el mismo, pero parecido, objetivo c esta en el nombre del método y nivel de c# que tiene sobre el argumento de nivel (lo que pasa argumentos adicionales también y que afectan el tiempo de procesamiento), objective – c no tiene este gigante de la sobrecarga. Se refieren a este para algunas pruebas de parámetros con nombre dotnetperls.com/named-parameters
    • Muy interesante de leer, thnx
    • Si necesita saber algo es una cadena, hacer su propio mutable de la clase array que contiene sólo las cadenas. Usted puede utilizar NSArray internamente.
    • -1 personas en general tienden a evitar lo que es diferente de sus hábitos y conocimientos, de modo de zanjar un lenguaje de programación únicamente en su llamado «legibilidad» no está bien fundada. Lenguaje de programación es una herramienta.
    • En mi caso, como para muchas personas, la lectura de «la herramienta» que afecta a mi productividad. Me siento cómodo y productivo con muchos idiomas Objective-C sin embargo, no ha sido nunca uno de ellos y que no es porque no lo ha intentado. Pero, de nuevo, al final del día es todo acerca de la preferencia personal. A diferencia de hace 20 años, usted no está obligado a usar el lenguaje de X en orden a la plataforma de destino Y. elegir lo que mejor se adapte a ti.

  4. 17

    Manual de gestión de la memoria es algo que a los principiantes a Objective-C parece haber mayor problema con el, sobre todo porque piensan que es más complejo de lo que es.

    Objective-C y Cocoa por extensión se basa en las convenciones sobre la ejecución; conocer y seguir un conjunto muy pequeño de reglas y obtener una gran cantidad de forma gratuita por la dinámica en tiempo de ejecución en volver.

    El que no es 100% fiel a la regla, pero lo suficientemente bueno para todos los días es:

    • De cada llamada a alloc debe coincidir con una release al final de la actual ámbito de aplicación.
    • Si el valor devuelto por el método ha sido obtenida por alloc entonces debe ser devuelto por return [value autorelease]; en lugar de ser acompañado por un release.
    • Utilizar las propiedades, y no hay ninguna regla de tres.

    La explicación más larga de la siguiente manera.

    La gestión de la memoria se basa en la propiedad; sólo el titular de la instancia de un objeto nunca debe soltar el objeto, todos persona siempre debe hacer nada. Esto significa que en el 95% de todo el código de tratar a Objective-C como si estuviera en el recolector de basura.

    Entonces, ¿qué acerca de los otros 5%? Dispone de tres métodos para mirar hacia fuera para cualquier instancia del objeto recibido de estos métodos son propiedad del actual el ámbito del método:

    • alloc
    • Cualquier método que comienzan con la palabra nueva, tales como new o newService.
    • Cualquier método que contiene la palabra copia, tales como copy y mutableCopy.

    El método tiene tres posibles opciones de qué hacer con la propiedad de instancias de objetos antes de que salga:

    • Liberación mediante release si es que ya no es necesario.
    • A dar la titularidad a un campo (variable de instancia), o una variable global simplemente la asignación de la misma.
    • Renunciar a la propiedad, sino de dar a alguien una oportunidad para tomar posesión antes de que la instancia se va llamando autorelease.

    Así que cuando usted debe pro-activamente la propiedad llamando retain? Dos casos:

    • A la hora de asignar los campos en su inicializadores.
    • Cuando manualmente la aplicación de método setter.
    • +1 Excelente resumen. Suena muy similar a cuando me enteré de C años.
    • Solo para aclarar, de recolección de basura es totalmente compatible con Objective-C en el Mac, y no se necesita hacer ningún manual de gestión de la memoria. Manual de gestión de la memoria es necesaria sólo en iOS.
    • Aún así, es bueno para aprender los conceptos básicos de la gestión de la memoria, aunque sólo sea para mejorar el rendimiento cuando lo necesite (no tiene que ejecutar la recolección de basura).
    • iOS 5 introdujo ARCO, eliminando la necesidad manualmente tener que publicó asignado objeto. Pero aún no es tan fácil como C#. Hay que tener en cuenta que Objective-C es de más de 20 años de edad, y se ha mantenido algunos de los requisitos de idiomas en aquellos días: que es saber cuando asignación y cuando libre de liberación de memoria. C# ha eliminado todo esto para usted. Habiendo dicho eso, el Cacao tiene una gran cantidad de APIs que aún no son tan accesibles en Windows Phone. Tales como gestos, mucho más de los controles cuando se trata de eventos de interfaz de usuario, etc…
  5. 10

    Seguro de que, si todo lo que has visto en tu vida es Objective C, entonces su sintaxis se ve como la única posible. Podríamos llamar una «programación de la virgen».

    Pero dado que muchos de código está escrito en C, C++, Java, JavaScript, Pascal y otros idiomas, verás que ObjectiveC es diferente de todos ellos, pero no de una buena manera. Tenían una razón para esto? Vamos a ver otros lenguajes populares:

    C++ añadido un montón de extras a C, pero cambió el original de la sintaxis sólo tanto como sea necesario.

    C# añade una gran cantidad de extras en comparación a la de C++ pero cambió sólo las cosas que se pusieron feas en C++ (como la eliminación de la «::» a partir de la interfaz).

    Java cambiado un montón de cosas, pero se mantiene la sintaxis familiar, excepto en las partes donde el cambio era necesario.

    JavaScript es un completo lenguaje dinámico que puede hacer muchas cosas ObjectiveC no puede. Aún así, sus creadores no inventar una nueva forma de llamar a los métodos y pasar parámetros a ser diferente del resto del mundo.

    De Visual Basic pueden pasar parámetros de orden, como ObjectiveC. Usted puede poner el nombre de los parámetros, pero también puede pasar de la forma habitual. Todo lo que se utilice, es normal delimitado por comas de manera que todo el mundo entiende. Coma es el habitual delimitador, no sólo en los lenguajes de programación, pero en los libros, los periódicos, y el lenguaje escrito en general.

    Object Pascal tiene una sintaxis diferente de C, pero su sintaxis es en realidad más FÁCIL de leer para el programador (tal vez no para el equipo, pero a quién le importa qué equipo piensa). Así que tal vez se distraía, pero al menos su resultado es mejor.

    Python tiene una sintaxis diferente, lo que es aún más fácil de leer (para los humanos) de Pascal. Así que cuando lo cambiaron, lo que es diferente, al menos de que lo hayan hecho mejor para nosotros los programadores.

    Y, a continuación, hemos ObjectiveC. Añadiendo algunas mejoras a C, pero la invención de su propia sintaxis de la interfaz, llamada al método, paso de parámetros y lo que no. Me pregunto por qué no se swap + y – lo que más resta de dos números. Habría sido aún más fresco.

    Steve Jobs jodido por el apoyo ObjectiveC. Por supuesto, él no puede apoyar a C#, que es mejor, sino que pertenece a su peor competidor. Así que esta es una decisión política, no una práctica. La tecnología siempre se sufre cuando de tecnología se toman las decisiones por razones políticas. Él debe dirigir la empresa, lo que lo hace bueno, y dejar las cuestiones de programación a verdaderos expertos.

    Estoy seguro de que sería aún más apps para el iPhone si se decidió a escribir iOS y bibliotecas de soporte en cualquier otro idioma que ObjectiveC. A todos, excepto a die-hard fans, la virgen, los programadores y Steve Jobs, ObjectiveC parece ridículo, feo y repulsivo.

    • el último párrafo 2 suma de todo
    • Oh, sí, seguro que la sintaxis es ridículo, pero la joya de el lenguaje Objective-C es que no tiene casi el más fácil de utilizar la reflexión de todos los idiomas y algunos realmente brillantes características de tiempo de ejecución que hace varios paradigmas casi trivial de implementar. Por ejemplo, cuando el uso de Objective-C yo nunca necesita a la mente que lineal tabla – lista enlazada o vector o lo que sea – sólo NSArray y se encarga de la selección de la mejor algoritmo basado en la máquina y la naturaleza de los datos.
    • Entré en mi primer trabajo como (virgen) programador de la aplicación de iOS de la Aplicación de interfaces de usuario en Objective-C. Todo lo que quiero por ahora (después de 3 años) es para salir de ese solitario ‘la isla’ y aprender algo más independiente de la plataforma y por lo tanto más seminal. También para llegar a saber si otros marcos también se actualizan tan rápido – y buggy. Hey! Nueva Característica! – Bloqueo… la Esperanza (alemán) centro de trabajo gasta algo de dinero para mí en los tutoriales de Java y/o C++/C# porque ya no me quieren desarrollar para Apple sh*t.
  6. 5

    Una cosa que me encanta objective-c es que el objeto del sistema se basa en mensajes, te permite hacer cosas verdaderamente buenas que no se podía hacer en C# (al menos no hasta que apoyan la dinámica de palabras clave!).

    Otra gran cosa acerca de la escritura de cacao aplicaciones de Interface Builder, es mucho más agradable que el diseñador de formularios de Visual Studio.

    Las cosas acerca de obj-c que me molestan (como C# developer) son el hecho de que usted tiene que manejar su propia memoria (no hay recolección de basura, pero que no funciona en el iPhone) y que puede ser muy detallado porque de la sintaxis del selector y todos los [ ].

    • dynamic sólo va a llegar a mitad de camino – la implementación de un verdadero objeto dinámico, incluso con las cosas más triviales como el mensaje de la delegación, es tedioso, incluso en C# 4.0. Por otro lado, el precio de la flexibilidad de la verdadera dinámica del paso de mensajes a la ObjC se pierde tipo de seguridad.
    • Vale la pena señalar que Objective-C, permite opt-in estático, el cual proporciona un mayor grado de seguridad de tipos. Algunas personas prefieren tiempo de compilación de cheques, otros prefieren tiempo de ejecución de la comprobación. Lo bueno (en ambos idiomas) es que la elección no necesita ser absoluta.
    • Diseñador de Formularios de Windows no es tan grande, pero si usted es capaz de utilizar WPF (como de .NET 3.0) Expression Blend es difícil de superar…
    • Usted puede hacer un montón de este con System.Reflection combinado con extensiones en C# 3.0, usted puede llamar a cualquier método de encontrar, pero no es cierto, paso de mensajes, se verá como obj.PassMessage("function_name", params object[] args); para un mejor paso de mensajes integrado en el lenguaje, el método que falta se puede llamar normal objeto sería necesario.
  7. 4

    Como un programador introducción a Objective-C para iPhone, proveniente de C# 4.0, me estoy perdiendo las expresiones lambda, y, en particular, Linq to XML. Las expresiones lambda son C#, mientras que el Linq to XML es realmente más de una .NET vs Cacao contraste. En una aplicación de ejemplo que me estaba escribiendo, tenía algo de XML en una cadena. Yo quería analizar los elementos de XML en una colección de objetos.

    Para lograr esto en Objective-C/Cacao, tuve que usar el NSXmlParser clase. Esta clase se basa en otro objeto que implementa la NSXMLParserDelegate protocolo con métodos que son llamados (leer: los mensajes enviados) cuando un elemento abierto etiqueta se lee, cuando algunos de los que se leen los datos (generalmente en el interior del elemento), y cuando algún elemento de la etiqueta de cierre es leer. Tienes que seguir la pista de los análisis de situación y estado. Y yo, sinceramente, no tienen idea de lo que sucede si el XML no es válido. Es ideal para llegar a los detalles y optimizar el rendimiento, pero, oh, hombre, eso es un montón de código.

    Por el contrario, este es el código en C#:

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

    Y eso es todo, tienes una colección de objetos personalizados que se dibuja a partir de XML. Si quieres filtrar los elementos por valor, o sólo a aquellos que contienen un atributo específico, o si sólo quería los 5 primeros, o para omitir el primer 1 y obtener el próximo 3, o simplemente averiguar si alguno de los elementos fueron devueltos… BAM, todo bien en la misma línea de código.

    Hay muchos de la abrir-fuente clases que hacen que este proceso sea mucho más fácil en Objective-C, por lo que no hace mucho del trabajo pesado. Es simplemente que no esta construida en.

    * * * * NOTA: yo en realidad no compilar el código anterior, sólo se entiende como un ejemplo para ilustrar la relativa falta de detalle requerido por C#.

    • Importante no aquí, sin embargo, que no hay por lo tanto una «falta de detalle» en la parte de C# en esta comparación, sólo que el nivel de detalle está contenido en el .net framework de clases que se utiliza para analizar el XML. Si examina el código dentro de estos, usted es probable encontrar una buena oferta de más de código de C#, posiblemente incluso más detallado.
  8. 3

    Probablemente la diferencia más importante es la gestión de la memoria. Con C# tienes recolección de basura, por la virtud de ser un CLR lenguaje basado en. Con Objective-C, que usted necesita para administrar la memoria de sí mismo.

    Si vienes de un C# de fondo (o de cualquier lengua moderna, para el caso), para pasar a una lengua sin gestión automática de la memoria va a ser muy doloroso, como va a pasar mucho de su tiempo de codificación en la correcta administración de la memoria (y depurar así).

    • ObjC tiene seguimiento de recolección de basura en estos días. Por otro lado, C# permite administrar la memoria de sí mismo si se desea (gracias a raw punteros).
    • No encuentro el manual de gestión de la memoria en Objective-C (en el contexto de Apple marcos) a ser un mucho de una carga: el retener/release/grupo de liberación automática del ciclo es mucho menos engorroso que el «tradicional» de la gestión de memoria en C y C++.
    • Esto simplemente no es cierto DSO – incluso en un no-recolección de basura ambiente como el iPhone, el retener/liberación y el grupo de liberación automática cosas se tarda unos 10 minutos para aprender y, a continuación, no es un problema. He encontrado un montón de C#-res a los que les gusta exagerar los retos de la gestión de la memoria. Es casi como que el miedo que empiece a gusto obj-c demasiado de lo contrario… 😉
    • Los fundamentos del manual de gestión de la memoria no es difícil. Pero puede complicarse rápidamente cuando usted comience a pasar los objetos asignados a su alrededor y tiene que lidiar con complejas de objetos gráficos, ya que es necesario seguir cuidadosamente las reglas como quién es el responsable de liberar y cuando. El recuento de referencias implementaciones de hacer un poco más fácil, excepto que necesita para lidiar con los ciclos en los gráficos de objeto… en comparación con C#, todo esto de la OMI es una gran diferencia.
  9. 1

    Aquí un muy buen artículo comparando los dos idiomas:
    http://www.coderetard.com/2008/03/16/c-vs-objective-c/

    • Es una lástima que la página dice que está en UTF-8, pero tiene todo tipo de desagradables reemplazos para los apóstrofes y las comillas. Creo que su texto utiliza «curvy» entre comillas, pero seguro que tergiversar el código…
    • parece que han robado su introducción todo cerdo, pero incluso el origen artículo tiene su código munged. tampoco es un gran artículo.
  10. -2

    Otro que el paradigma de la diferencia entre los 2 idiomas, no hay mucha diferencia. Tanto como me gusta decir, se puede hacer el mismo tipo de cosas que (probablemente no tan fácilmente) con .NET y C# como usted puede con Objective-C y Cocoa. Como de Leopardo, Objective-C 2.0 cuenta con recolección de basura, por lo que no han administrar la memoria de sí mismo a menos que usted desee (código de compatibilidad con los antiguos equipos Mac y aplicaciones para el iPhone son 2 razones para querer a).

    Medida de lo estructurado, legible el código se refiere, gran parte de la carga no recae en el programador, como con cualquier otra lengua. Sin embargo, me parece que el paradigma de paso de mensajes se presta bien a un código legible siempre que el nombre de sus funciones/métodos apropiadamente (de nuevo, como en cualquier otro idioma).

    Yo seré el primero en admitir que no estoy muy familiarizado con C# o .NET. Pero las razones Quinn mencionados anteriormente son muy pocas razones por las que no me importa para que así sea.

  11. -3

    Las llamadas al método utilizado en obj-c hacer para leer fácilmente el código, en mi opinión mucho más elegante que el de c# y obj-c está construido en la parte superior de c para todo c código debería funcionar bien en obj-c. El gran vendedor para mí es que aunque obj-c es un estándar abierto, así que usted puede encontrar compiladores para cualquier sistema.

    • ISO C# también es un estándar abierto. También, a lo que yo sé, la única ObjC compilador en la existencia es gcc.
    • Hay también el Objeto Portátil Compilador (users.telenet.be/stes/compiler.html) y clang.
    • En realidad, GCC no es el único compilador — Clang y LLVM son un par de tecnologías diseñado y desarrollado para reemplazar GCC y hacer cosas que nunca podría, incluyendo la compilación JIT. Este es el núcleo de OpenCL en Snow Leopard. También son extensibles a otras lenguas, y son dignos de visitar.
    • Yo, sinceramente, no se considere la portabilidad a ser un pro de Objective-C. Lugar, las fuerzas están más a lo largo de las líneas de rápido desarrollo y de la reducción en el volumen de código para realizar la misma tarea.
    • Gracias por corregir mi error en el compilador de disponibilidad. Así, la portabilidad es técnicamente allí de todos modos – puedo utilizar MinGW/ObjC en Win32 bien, por ejemplo – en ese sentido es tan portátil como gcc en sí es. Por supuesto, las bibliotecas no van a estar allí (aunque… hay GnuStep/Win32?), pero esta situación no es realmente mucho peor que lo que tenemos con Mono; así que en conjunto, yo diría que la portabilidad no es un punto fuerte para cualquiera de los lados.
    • C# puede ser compilado con la fuente abierta Mono proyecto.

Dejar respuesta

Please enter your comment!
Please enter your name here