Programar para iPhone

[Vicente]

Si es cierto, es una porquería enorme y apestosa :o

Aun no conozco a nadie que no lo odie. Preferiría 100 veces C# a ObjC. Entiendo las pretensiones de Apple por temas de "petes", pero me da la sensación de que le ha salido algo regular en lo que a juegos se refiere. La gente adora aun más C++ despues de ver ObjC :D

Pues en C# 4.0 van a añadir la palabra reservada "dynamic" para permitir código con tipado dinámico :p Y la gente de Microsoft ya lleva tiempo invirtiendo bastante en el DLR (Dynamic Language Runtime) para soportar IronPython y IronRuby en .NET.

Además hay mucha gente que está encantada con Python, Ruby, Lua, Javascript,... Puede que Objective-C sea una castañufa, no lo sé, pero lenguajes con tipado dinámico populares los hay a patadas :p

[Vicente]

¿El tipado de Objective se considera dinámico? ¿Por qué? Lo de tener que declarar los tipos de las variables explícitamente igual que en C no me parece muy dinámico precisamente... :P

Yo no sé Objective C, pero la wikipedia dice esto:

Objective-C, like Smalltalk, can use dynamic typing: an object can be sent a message that is not specified in its interface. This can allow for increased flexibility — in Objective-C an object can "capture" this message, and depending on the object, can send the message off again to a different object (who can respond to the message correctly and appropriately, or likewise send the message on again). This behavior is known as message forwarding or delegation (see below). Alternatively, an error handler can be used instead, in case the message cannot be forwarded. If the object does not forward the message, handle the error, or respond to it, the message is silently discarded; this is true even if messages are sent to nil (the null object pointer).

Static typing information may also optionally be added to variables. This information is then checked at compile time. In the following three statements, increasingly specific type information is provided. The statements are equivalent at runtime, but the additional information allows the compiler to warn the programmer if the passed argument does not match the type specified.

Un saludo!

Vicente

[synchrnzr]

Acepto barco porque es verdad que el tipado de las variables pasadas a los mensajes de Smalltalk es dinámico u opcionalmente estático. Pero para todo lo demás es estrictamente estático, igual que el C++, no opcional como pone en esta descripción. Almenos por defecto, ignoro si habrá directivas u opciones del compilador para modificar ese comportamiento.

sync

[Prompt]

Mmm, si te relees mi mensaje, vengo a decir precisamente lo contrario :P

Si, lo se. Yo me refiero a 2 problemas comunes en tiempos de ejecución por lo que existe C# por ejemplo. Windows tiene un problema que los programadores, programan mal y rápido porque hay mucho jefe inutil o gente que no entiende bien la industria, bien no entremos ahí. En C# y otros el buffer overflow y overrun no ocurre, porque se dejan ciertas decisiones / comprobaciones etc... para el tiempo de ejecución que hace que al menos no pete o no se pueda inyectar código "malicioso".

Ejemplo:
char string[10]
sprintf(string, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");

En C/C++ al compilar esto dirá poco y petará mucho despues. Ya se sabe, si existe un array de char tu código es vulnerable. Existen funciones para que en tiempo de ejecución la cosa no sea tan grave, "sprintf_s(string, 10, "aaaaaaaaaaaaaaaaaaa")" por ejemplo.

Estos problemas de inyección de código no ocurren en C# y otros lenguajes similares. Para mi, la naturaleza de estos lenguajes es erronea ya que parten de una premisa básica. El programador es tonto o no hay remedio nos frien a programas chungos y no podemos arreglar el SO.

edito: y mira que amaba a las primeras versiones y concepto de C# pero el tiempo me quitó la razón.

Yo le he dado bastante al C# y he acabado odiandolo versión trás versión. Y todos los lenguajes similares en concepto no los quiero ni ver. Flames no, pero Java en multitud de sitios y sobre todo en "esta nuestra industria" está dejando de tener sentido de existencia. Por razones obvias para mi desde hace mucho. (Y mira que a mi me gusta el eclipse)

[Vicente]

Si, lo se. Yo me refiero a 2 problemas comunes en tiempos de ejecución por lo que existe C# por ejemplo. Windows tiene un problema que los programadores, programan mal y rápido porque hay mucho jefe inutil o gente que no entiende bien la industria, bien no entremos ahí.

La media de programadores malos de Windows es la misma que la de programadores de microcontroladores, de páginas web o de SQL. A ver con que datos puedes defender semejante afirmación.

Estos problemas de inyección de código no ocurren en C# y otros lenguajes similares. Para mi, la naturaleza de estos lenguajes es erronea ya que parten de una premisa básica. El programador es tonto o no hay remedio nos frien a programas chungos y no podemos arreglar el SO.

C# no tiene GC u otras características porque los programadores sean tontos, las tienen porque hacen el lenguaje productivo (igual que tu defiendes el tipado estático, es lo mismo). Por esa misma razón añadieron en C# 3.0 un montón de características de los lenguajes funcionales, y eso normalmente no es fácil de entender para los programadores acostumbrados a C y similares (entender el concepto de Func<T>, funciones lambda o árboles de expresión no es tan trivial). Ya tienes un ejemplo de característica productiva que no está orientada a programadores "tontos".

Si te lees el blog de Eric Lippert (uno de los jefes de como evoluciona el lenguaje), verás que siempre añaden funcionalidades que den valor y productividad al lenguaje, independientemente de si son más fáciles o difíciles de entender (obviamente, si tienes algo que da mucho valor y fácil, pues seguramente se implementará primero).

edito: y mira que amaba a las primeras versiones y concepto de C# pero el tiempo me quitó la razón.

Yo le he dado bastante al C# y he acabado odiandolo versión trás versión. Y todos los lenguajes similares en concepto no los quiero ni ver. Flames no, pero Java en multitud de sitios y sobre todo en "esta nuestra industria" está dejando de tener sentido de existencia. Por razones obvias para mi desde hace mucho. (Y mira que a mi me gusta el eclipse)

Otra afirmación debatible. Si no te gustan pues no los uses, pero para tu desgracia cada vez se van a usar más y con razón: nadie normalmente quiere hacer en 10 horas lo que se puede hacer en 5 con otras herramientas.

Edit 2: para reducir el flame.

[davur]

La mayoria de los problemas que provocan usar estas porquerias de mierda asquerosas y putrefactas de lenguajes de programación son el control de memoria, los buffer overrun y overflow. Utilizar ObjC le asegura a apple que la gente no hará que su device pete cada 2 x 3. Pero es que nadie quiere la porqueria del ObjC, que yo sepa todo el mundo lo odia. Es cierto?

No, todo lo que dices en el párrafo citado es rotundamente falso. No tienes ni idea de lo que hablas.

Si, lo se. Yo me refiero a 2 problemas comunes en tiempos de ejecución por lo que existe C# por ejemplo. Windows tiene un problema que los programadores, programan mal y rápido porque hay mucho jefe inutil o gente que no entiende bien la industria, bien no entremos ahí.

...

Son muchas barbaridades juntas: eres el perfecto ejemplo de 'language zealot'. La contestación de Vicente es ejemplar, y correctísima.

Lenguajes modernos y mejor diseñados que C++, como C# o Python, tienen características en absoluto triviales de dominar. Bien harías en informarte antes de decir barbaridades como que su premisa básica es que "el programador es tonto". Porque lo único que haces es dar a entender que tú eres el tonto aquí.

[synchrnzr]

Uffff, como está el patio

Porque lo único que haces es dar a entender que tú eres el tonto aquí.

Dejemos que se enfríe un poco la cosa antes de acabar en una guerra de descalificaciones personales sin sentido ¿ok? ;)

sync

[Prompt]

Si, lo se. Yo me refiero a 2 problemas comunes en tiempos de ejecución por lo que existe C# por ejemplo. Windows tiene un problema que los programadores, programan mal y rápido porque hay mucho jefe inutil o gente que no entiende bien la industria, bien no entremos ahí.

La media de programadores malos de Windows es la misma que la de programadores de microcontroladores, de páginas web o de SQL. A ver con que datos puedes defender semejante afirmación.

Te respondo con una pregunta. Como puedes argumentar lo contrario mejor que yo? C# o Java reducen cierto tipo de errores y aumentan la productividad en contra de cierto rendimiento de la aplicación.

Estos problemas de inyección de código no ocurren en C# y otros lenguajes similares. Para mi, la naturaleza de estos lenguajes es erronea ya que parten de una premisa básica. El programador es tonto o no hay remedio nos frien a programas chungos y no podemos arreglar el SO.

C# no tiene GC u otras características porque los programadores sean tontos, las tienen porque hacen el lenguaje productivo (igual que tu defiendes el tipado estático, es lo mismo). Por esa misma razón añadieron en C# 3.0 un montón de características de los lenguajes funcionales, y eso normalmente no es fácil de entender para los programadores acostumbrados a C y similares (entender el concepto de Func<T>, funciones lambda o árboles de expresión no es tan trivial). Ya tienes un ejemplo de característica productiva que no está orientada a programadores "tontos".

Sobre que el GC y demás existe para hacerlo más productivo, estoy totalmente de acuerdo contigo. Incluso en C++ existe el "__gc" pero hay otros lenguajes que aportan más ventajas productivas. Según para que cosa queramos desarrollar.

Func<T>, esto no existe en C++? Yo creo que te confundes. Yo no digo que los programadores de C# sean tontos, eso es algo que no casa con la realidad. Digo que C# existe por la existencia de una problematica global y una manera de funcionar, que hacen que existan programas que tienen problemas de malfuncionamiento. C# minimiza ciertos problemas críticos como la inyección de código. Buffer overrun, buffer overflow y hace que el código a parte de productivo sea seguro. Tambien existe un modo NoSafe para programar en C#.

En C# 1.0 y 1.1 a mi el lenguage me ecantaba, tengo ahí mi libro de justo cuando salió, tengo apps, he trabajado con el profesionalmente y tengo que decir que C# 2.0 no me gustó nada. C# 3.0 tiene cosas muy buenas. Entre ellas las que comentas, nada triviales ni para tontos. Recuerdo que hace poco en Java preocupados por el rendimiento general del lenguaje añadieron también templates. Hacer en tiempo de compilación cosas para no perder luego el tiempo. En el departamento de moviles me comentarón que era un 20-30% más rápido el código usando templates. Cosa que existe desde hace siglos en C++ y parece ser que el camino de C#, Java etc... no es el camino contrario a C++.

edito: y mira que amaba a las primeras versiones y concepto de C# pero el tiempo me quitó la razón.

Yo le he dado bastante al C# y he acabado odiandolo versión trás versión. Y todos los lenguajes similares en concepto no los quiero ni ver. Flames no, pero Java en multitud de sitios y sobre todo en "esta nuestra industria" está dejando de tener sentido de existencia. Por razones obvias para mi desde hace mucho. (Y mira que a mi me gusta el eclipse)

Otra afirmación debatible. Si no te gustan pues no los uses, pero para tu desgracia cada vez se van a usar más y con razón: nadie normalmente quiere hacer en 10 horas lo que se puede hacer en 5 con otras herramientas.

Ya no lo uso activamente, de hecho comprobé yo mismo como de rápido era hacer una tool mezclada con un visor de render en C# y probé a usar algo que no fuera MFC. Qt y wxWidgets. Y para mi, extrañamente me atrapó Qt y me maravilló.

Dices que nadie quiere hacer algo en 10 horas si lo haces en 5. Claro, depende, no creo que haya tanta diferencia si hablamos de C++ y C# no obstante, si tu objetivo es el rendimiento entre otras cosas la gente no usa lenguajes como Java o C#. Hablando del contexto de videojuegos, existe XNA que es una gran idea pero eso tiene el mercado que tiene. Igual que C/C++ tiene el suyo. Y cada uno usará lo mejor para el y más productivo según los objetivos que se tengan.

[flipper83]

Recuerdo que hace poco en Java preocupados por el rendimiento general del lenguaje añadieron también templates. Hacer en tiempo de compilación cosas para no perder luego el tiempo. En el departamento de moviles me comentarón que era un 20-30% más rápido el código usando templates. Cosa que existe desde hace siglos en C++ y parece ser que el camino de C#, Java etc... no es el camino contrario a C++.

Solo puntualizar que si con esto te refieres a utilizar "generics" en j2me, no se puede ya que están disponibles a partir de 5.0 y al igual que el foreach la maquina virtual de j2me peta. Excepto que en la nueva kvm hayan hecho algo nuevo.

y decir también q los generics de java son un poco de palo ^_^, son más bien por comodidad que por rendimiento.

[Prompt]

Solo puntualizar que si con esto te refieres a utilizar "generics" en j2me, no se puede ya que están disponibles a partir de 5.0 y al igual que el foreach la maquina virtual de j2me peta. Excepto que en la nueva kvm hayan hecho algo nuevo.

y decir también q los generics de java son un poco de palo ^_^, son más bien por comodidad que por rendimiento.

:) hehehe, no lo sé es lo que me comentaron. A mi me parece igualmente interesante usar Java o C# para ciertas cosas y sea de palo o no, entiendo que hacer cosas en tiempo de compilación aumenta el rendimiento. Ya no se si mucho o poco.

No obstante, yo probé Qt 4.2 hasta ahora la 4.5.2 (es muy buena y tiene correcciones de rendimiento) y a mi me va muy bien y me parece un framework muy productivo. A mi me viene genial para temas de GUI. Aunque Qt tiene de todo, red, sonido...

[Vicente]

Func<T>, esto no existe en C++? Yo creo que te confundes.

No existe: en C++ no hay delegados ni genéricos. Tenéis punteros a funciones y templates que son parecidos, pero no son lo mismo.

Yo no digo que los programadores de C# sean tontos, eso es algo que no casa con la realidad. Digo que C# existe por la existencia de una problematica global y una manera de funcionar, que hacen que existan programas que tienen problemas de malfuncionamiento. C# minimiza ciertos problemas críticos como la inyección de código. Buffer overrun, buffer overflow y hace que el código a parte de productivo sea seguro. Tambien existe un modo NoSafe para programar en C#.

Pero es que si buscas porque MS creó .NET, no lo creo por eso, lo creó porque quería una nueva plataforma de desarrollo de aplicaciones empresariales moderna (que el VB6 ya estaba viejuno, además de querer comerse a Java), ya que hacer aplicaciones cada vez era más complicado, cada vez eran más grandes y lo último que quería un programador es pegarse con un memory leak cuando hay mil cosas más interesantes que hacer en temas de arquitectura o diseño (problemas interesantes de verdad).

MS quería proporcionar una plataforma unificada de desarrollo en Windows que soportara ventanitas, web, acceso a datos, xml,... En vez de tener 1000 librerías de diferentes equipos de producto cada cual con sus propias idiosincrasias. Si miras el desarrollo de Windows antes de .NET era un cacao de APIs. Pero no hicieron .NET porque la gente se ponía a petar Windows con buffer overflows y cosas así.

En C# 1.0 y 1.1 a mi el lenguage me ecantaba, tengo ahí mi libro de justo cuando salió, tengo apps, he trabajado con el profesionalmente y tengo que decir que C# 2.0 no me gustó nada.

Esto me sorprende, ¿porqué no te gustó nada? En C# 2.0 así a grandes rasgos añadieron:

- Generics y constraints: MiClase<T> where T : new y similares (ya solo por esto 2.0 merece la pena).
- Nullable types: int?, float?, ... Pensados para interactuar con una BBDD ya que en una BBDD es posible que un int valga NULL.
- Palabra reservada yield: para implementar iteradores de forma más sencilla (y corrutinas y cosas así, se te puede ir la pinza mucho con esto).
- Delegados anónimos: para no tener que declarar tipos nuevos cada dos por tres, aunque la sintaxis es un poco fea.

Y luego ya sin contar que (por lo menos para mi) el VS2005 es bastante mejor que el VS2003.

C# 3.0 tiene cosas muy buenas. Entre ellas las que comentas, nada triviales ni para tontos. Recuerdo que hace poco en Java preocupados por el rendimiento general del lenguaje añadieron también templates. Hacer en tiempo de compilación cosas para no perder luego el tiempo. En el departamento de moviles me comentarón que era un 20-30% más rápido el código usando templates. Cosa que existe desde hace siglos en C++ y parece ser que el camino de C#, Java etc... no es el camino contrario a C++.

Ves, pero es que las cosas no son así. En Java no añadieron generics (que no templates) por rendimiento, porque se implementan usando "type erasure". Mira en la Wikipedia (en Sun tienes bastantes papers si quieres más información):

Generics are checked at compile-time for type correctness. The generic type information is then removed via a process called type erasure. For example, List<Integer> will be converted to the raw type (non-generic type) List, which can contain arbitrary objects. However, due to the compile-time check, the resulting code is guaranteed to be type correct, as long as the code generated no unchecked compiler warnings.

Los generics se implementaron porque tener un ArrayList donde la posición 0 es un perro, la 1 una pera y la 2 un int es una locura (básicamente el mismo problema del que tú te quejabas con los tipos dinámicos). Y luego ya sin entrar que genéricos y templates no son lo mismo. Si quieres comparar templates con una característica de .NET, en mi opinión se parece mucho más a T4.

Ya no lo uso activamente, de hecho comprobé yo mismo como de rápido era hacer una tool mezclada con un visor de render en C# y probé a usar algo que no fuera MFC. Qt y wxWidgets. Y para mi, extrañamente me atrapó Qt y me maravilló.

Qt está muy bien sip.

Dices que nadie quiere hacer algo en 10 horas si lo haces en 5. Claro, depende, no creo que haya tanta diferencia si hablamos de C++ y C# no obstante, si tu objetivo es el rendimiento entre otras cosas la gente no usa lenguajes como Java o C#. Hablando del contexto de videojuegos, existe XNA que es una gran idea pero eso tiene el mercado que tiene. Igual que C/C++ tiene el suyo. Y cada uno usará lo mejor para el y más productivo según los objetivos que se tengan.

Claro que si quieres un motor que exprima el último frame de las máquinas no vas a usar C# seguramente, pero no todos los juegos tienen esa necesidad. Puede que a C# le quede mucho para ser el lenguaje de los videojuegos, o puede que nunca lo consiga, pero donde sí que destaca por encima de C++ es en la creación herramientas. Y cada vez va a ir a más.

[Prompt]

Claro que si quieres un motor que exprima el último frame de las máquinas no vas a usar C# seguramente, pero no todos los juegos tienen esa necesidad.

Que C# no sea el día de mañana un lenguaje para videojuegos está por ver. Si hacen de una vez CPUs muy potentes cada vez se notará menos que tiene menor rendimiento.

Puede que a C# le quede mucho para ser el lenguaje de los videojuegos, o puede que nunca lo consiga, pero donde sí que destaca por encima de C++ es en la creación herramientas. Y cada vez va a ir a más.

Esta es la comparación de OpenGL vs DirectX. C++ es un lenguage y C# un lenguaje + framework. Ciertamente dentro del standard de C++ han actualizado muchas cosas últimamente, pero nunca más allá de lo que es el lenguaje en si. Con lo cual si comparamos C++ y C# para hacer herramientas, no hay comparación que sirva. Si acaso C++ y Qt vs C#.

El problema de que C++ "sea de todos" es que aunque exista un "comité" para standarizar cosas nunca abrá unos intereses de evolucionar el lenguaje y hacer un framework standard.

Por eso hasta hace poco, me gustaba bastante la idea del lenguaje D. Es como un C++ limpio y evolucionado. Pero no deja de ser un lenguaje y no un framework pagado por una empresa para que evolucione como debe.

En cualquier caso, otra cosa que me gustó es que hace tiempo decidieron liberar las especificaciones de C# y así el proyecto Mono podrá evolucionar a mejor ritmo. Una de las cosas que no me gustan es usar tecnología que me prive de libertad. Como por ejemplo compilar en algún cacharro un programita en C para hacer cosas de robótica. GCC es muy extendido y allá donde esté mi código compilará. Esperemos que Mono siga ese ritmo y que C# evolucione. En definitiva los programadores queremos crear cosas no ser unos radicales de un lenguaje en concreto.

[flipper83]

En definitiva los programadores queremos crear cosas no ser unos radicales de un lenguaje en concreto.

La frase mas coherente que he leido en stratos XD

[seryu]

ObjC deja para el tiempo de ejecucion ciertas decisiones. La mayoria de los problemas que provocan usar estas porquerias de mierda asquerosas y putrefactas de lenguajes de programación son el control de memoria, los buffer overrun y overflow. Utilizar ObjC le asegura a apple que la gente no hará que su device pete cada 2 x 3. Pero es que nadie quiere la porqueria del ObjC, que yo sepa todo el mundo lo odia. Es cierto?

Objective-C es un lenguaje tipado dinámicamente, como otro montón de lenguajes que hay por ahí. Y como cualquier cosa tiene sus ventajas y sus inconvenientes, pero no creo que sean "mierdas asquerosas y putrefactas", simplemente otra forma de pensar y trabajar.

:D como me he reido con esto.

Cuanta razón tienes vicente.

[Lord Destiny]

La diferencia en eficiencia entre C++ y C# a estas alturas dista bastante de ser relevante (en codigos "decentes" para cada uno) es como entre ensamblador y C++, ya nos preocupamos por ello (en el 99.9% de los casos). Es mejor dedicar el tiempo extra que te dan estos lenguajes a optimizar ese 10% de codigo critico (ya sabeis la regla heuristica de que el 90% del tiempo se ejecuta un 10% del codigo), a decidir una buena arquitectura y a un mejor testeo.

Ademas intentar optimizar el codigo al extremo lleva a empeorar bastante su legibilidad (aunque me gusta bastante optimizar TTxTT).

Y con programadores "mancos" ambos se pueden volver igual de ineficientes, lo que pasa es que sabemos distinguir mucho mejor que codigos son aceptables en el lenguaje que usamos abitualmente, mientras que de otros lenguajes que no dominamos nos tragamos mas basura.