Programar para iPhone

[Eskema]

Es curioso que este tipo de post siempre acaben en una batalla C++ contra el resto del mundo, cuando todos sabemos que todos los lenguages tienen sus mas y sus menos.

Yo no he visto ningun problema de rendimiento usando objc frente a usar c++, la unica ventaja del iphone es que al dejarte usar c++ puedes seguir ampliando tus conocimientos y ganar experiencia, mientras que el objc si no te quedas en la plataforma mac, te sirve de bien poco en el mundo laboral

[matriax]

La que ha liado Angel con una simple pregunta de iPhone XDDD

[Prompt]

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.

Recuerdo un paper de Epic Games, donde dicen que no han usado para UE 3 nada de ensamblador, no se si será cierto pero me lo creo. Invertir el tiempo en cosas más útiles:
- Lo demás
- Programar para el compilador

Qué es esto último? pues algo que leí en el libro Code Complete hace ya un tiempo. Hacer un código legible, pero no solo por que sea mantenible y extensible, sino hacer un código legible para el compilador:

Código [Seleccionar] Expand



for XXX
{
     int valor = game.getStatus( )
...
}



Si valor nunca cambia:

Código [Seleccionar] Expand



for XXX
{
     const int valor = game.getStatus( )
...
}

// Y obviamente:
const int valor = game.getStatus( )
for XXX
{
...
}


Y así con infinidad de cosas:

Código [Seleccionar] Expand


vector<Cosa*> vMiTest;
vMiTest.push_back( new Cosa( parametro) );
vMiTest.back()->queBurrada( 1 );
vMiTest.back()->queBurradaInmensa( 2 );
vMiTest.back()->queBurradaInnecesaria( 3 );


Yo soy un creyente de programar para humanos y para el compilador. Sobre el tema de usar ensamblador es por ejemplo muy optimo para multiplicar matrices, si. Pero y si usas un "truquito" y lo haces en GPU :)?

Código [Seleccionar] Expand


float mBone01[16] = { ... }
float mBone02[16] = { ... }
float mResult[16];

glMatrixMode( GL_MODELVIEW );
glLoadIdentity( );
glLoadMatrix( mBone01 );
glMultMatrix( mBone02 );
glGetMatrix( GL_MODELVIEW, mResult );


Quien lo hace más rápido la CPU en ASM o la GPU así! eh!  :o
Está claro que no todo es optimizar de forma enfermiza, yo he pasado por eso y no se gana mucho.

[blau]

Yo soy un creyente de programar para humanos y para el compilador. Sobre el tema de usar ensamblador es por ejemplo muy optimo para multiplicar matrices, si. Pero y si usas un "truquito" y lo haces en GPU :)?

Código [Seleccionar] Expand


float mBone01[16] = { ... }
float mBone02[16] = { ... }
float mResult[16];

glMatrixMode( GL_MODELVIEW );
glLoadIdentity( );
glLoadMatrix( mBone01 );
glMultMatrix( mBone02 );
glGetMatrix( GL_MODELVIEW, mResult );


Quien lo hace más rápido la CPU en ASM o la GPU así! eh!  :o
Está claro que no todo es optimizar de forma enfermiza, yo he pasado por eso y no se gana mucho.

Hombre, estoy de acuerdo contigo en casi todo, pero lo de la multiplicacion de matrices en la GPU no lo veo claro.

Es mas legible sin duda.

Pero no creo que se llegue a mandar ningun dato a la GPU, por lo menos en la operacion de multiplicacion, eso lo implementara el driver ejecutandolo en la CPU.

Y si fuese como dices, en todo caso la comunicacion con la GPU penalizaria mas que implementar la operacion en C++. 

A mi me gusta al estilo XNA.

Código [Seleccionar] Expand


Matrix.Multiply(ref bone1, ref bone2, out result);


[Prompt]

Bueno, habría que medirlo, si pasa por CPU como podría ser normal sería un chasco, pero también sería lo normal al no ser client side, quizás en un iPhone con OGL ES todo sea en GPU. En cualquier caso para animaciones etc... mejor usar un vertex shader con skinning :)

[Vicente]

A mi me gusta al estilo XNA.

Código [Seleccionar] Expand


Matrix.Multiply(ref bone1, ref bone2, out result);


Por suerte desde .NET 3.5 SP1 ya se puede multiplicar con "*" en vez de usar el método Multiply :)

Un saludo!

Vicente

[Vicente]

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.

Re-leyendo esto (y ahora que ando con un libro de IronPython) he encontrado esta cita de Anders Hejlsberg (el creador de C#):

Go look at dynamic languages and meta-programming: those are really interesting concepts. Once you get an understanding of these different kinds of programming and the philosophies that underlie them, you can get a much more coherent picture of what's going on and the different styles of programming that might be more appropriate for you with what you're doing right now.

Anyone programming today should check out functional programming and meta-programming as they are very important trends going forward.