TIOBE: Delphi is on its way out

[mamcx]

El problema es que delphi tiene un nicho (GUIs para windows) y exige un precio ($$$) de entrada alto, ademas, no esta donde esta la accion ahora (moviles, cloud, web, apps distribuidas, etc). Asi que la pregunta se invierte: para que solo Delphi, que solo sirve (honestamente) como para apps RADs si con python, java, c++, etc puedo hacer de todo y es relevante para todo?

El problema de delphi es que siendo un lenguaje tremendo a sido mal manejado. Se le nota sus idiosincracias. No tiene un mind-share (como C, C++) que justifique "aguantarselas" y las implementaciones maltrechas y a medio camino para atacar lo nuevo (moviles, cloud, web) son o malas o pésimas. Y no hay como arreglarlas.

Para los que nos movemos en otros entornos, sin desconocer lo bueno que es delphi, es *muy* notable lo estancado no solo del lenguaje y herramienta, sino de la comunidad en general. Si es que en JS se estan viendo cosas *increibles* ahora... Javascript!

http://www.echojs.com/latest/0

El problema es que delphi esta condenando de muerte. El que no entre suficiente sangre joven es la muerte de cualquier cosa. Existio una esperanza con lo de embarcadero, pero no solo por el manejo comercial sino el tecnico es claro que no va a resucitarse el impulso que se logro con Delphi 3...

No creo que Delphi/Pascal como concepto este muerto. Pero para mi es claro que ni el Delphi de ahora ni FreePascal seran la carta que resucite su estilo de programacion y practicidad. En parte, tecnicamente no pueden porque estamos en la inflexion de un cambio de paradigmas en los desarrollos, el surgimiento de nuevas plataformas y el ocaso del duopolio wintel. Delphi ni freepascal se estan moviendo a la velocidad necesaria, y ya creo es tarde pa ellos.

Lo que queda es retomar lo bueno y crear una plataforma nueva. De cuando en cuando, hay que reinventar la rueda (como lo que esta ocurriendo ahora con los lenguajes funcionales, que estaban como zombies, pero que han resurgido en los ultimo años).

TIOBE como unico punto de evidencia no es suficiente, pero el marco general es claro. Delphi esta en su ocaso, y no hay signos en ningun lado de que vaya a repuntar -osea, como para ser una estrella puntera-.

[defcon1_es]

Empezado por mamcx

El problema es que delphi tiene un nicho (GUIs para windows) y exige un precio ($$$) de entrada alto, ademas, no esta donde esta la accion ahora (moviles, cloud, web, apps distribuidas, etc).

Lo del precio no te lo puedo discutir, pero en lo demás... pero hoy he estado presente en el evento XE4 Iberian Tour de Madrid y he visto las nuevas características de XE4 (unas pocas, no todas) y, al menos en el tema de desarrollo y despliegue de aplicaciones para iOS, ha cambiado bastante (a mejor) respecto de XE2 (que es un infierno )

Empezado por mamcx

Asi que la pregunta se invierte: para que solo Delphi, que solo sirve (honestamente) como para apps RADs si con python, java, c++, etc puedo hacer de todo y es relevante para todo?

Quizás si, pero... ¿igual de rápido/eficiente con java que con delphi?... sinceramente lo dudo.

Empezado por mamcx

El problema de delphi es que siendo un lenguaje tremendo a sido mal manejado. Se le nota sus idiosincracias. No tiene un mind-share (como C, C++) que justifique "aguantarselas" y las implementaciones maltrechas y a medio camino para atacar lo nuevo (moviles, cloud, web) son o malas o pésimas. Y no hay como arreglarlas.

En esto discrepo contigo, al menos en la parte de los móviles de apple (no he desarrollado nada aún para "la nube" ni para web) ha mejorado mucho en 1 año aprox.
Repito que de XE2 a XE4 hay un abismo. Y espera que saquen XE5 para despliegues en Android.

Empezado por mamcx

El problema es que delphi esta condenando de muerte. El que no entre suficiente sangre joven es la muerte de cualquier cosa. Existio una esperanza con lo de embarcadero, pero no solo por el manejo comercial sino el tecnico es claro que no va a resucitarse el impulso que se logro con Delphi 3...

Desde que salió Delphi 8 he oido esa frase tantas veces...

Empezado por LoPiTaL

¿No os parece un poco raro que el lenguaje "Delphi / Object Pascal" haya bajado tres posiciones mientras que el lenguaje "Pascal" ha subido dos?

¿Hay alguien que todavía está trabajando en Pascal, sin objetos?

Si que es raro de narices...

Empezado por rretamar

si necesitamos aplicaciones eficientes, veloces, multiplataforma (lazarus), compiladas, ricas visualmente, y además buscamos productividad...¿ de qué vamos a tirar ? ¿ De Java, de Visual Basic, de C++, de Python ?.

Totalmente de acuerdo con movorack y con rretamar.

[mamcx]

Empezado por defcon1_es

En esto discrepo contigo, al menos en la parte de los móviles de apple (no he desarrollado nada aún para "la nube" ni para web) ha mejorado mucho en 1 año aprox.
Repito que de XE2 a XE4 hay un abismo. Y espera que saquen XE5 para despliegues en Android.

Conoces como es el desarrollo en iOS? Porque la estrategia de embarcadero es igual a la de Java en GUIS: Una gui alienigena, desligada de su plataforma de ejecucion y que no hace parte del ecosistema. Si ha mejorado con respecto a la version anterior, pues que bien. Pero eso no es el punto. No es mejorar delphi vs delphi. Es que sea una herramienta "nativa" de su entorno (en este caso, ios).

Pa que lo entiendas, Delphi es un exito en Windows porque corre sobre el API de windows (encapsulandolo de una forma mucho mejor) no porque (al igual que java) crea su propio GUI y luego corre de forma mediocre sobre varias plataformas.

Lo que ha hecho embarcadero, solo le causa gracia al programador de delphi. Pero no al programador de iOS. Significa echar al carajo todo lo que hay disponible, por un entorno que no ofrece una ganancia superior, y que visualmente, es mas bien feito. Lo que ha tenido exito pa IOS son aquellos que permiten operar de forma nativa, como monotouch (c#), rubymotion, varios proyectos de LUA/JS que permiten accesar al API interno.

Pero los que solo son mediocres soluciones multiplataformas (como phonegap a pelo) solo le causa gracia al programador que quiere la forma mas mediocre y rapida de estar en todas las plataformas posibles. Osea, al estilo de Java.

La estrategia de Delphi imita a la de Java de hace años. Que no es lo que hace en Windows.

[[Al González]]

A pesar de que los lanzamientos apresurados han sido uno de los principales factores en la pérdida de popularidad, después de analizarlo con mayor detenimiento creo que podríamos estar ante una versión que podría poner freno a esa tendencia. El hecho de que venga con un mucho mejor soporte para iOS y de que se esté allanando el terreno para Android va a ser un factor muy positivo, que sumado al evidente estancamiento de Microsoft (Windows 8, .NET, C#...), a la finalización de los cinco minutos de fama de Java y a la inevitable ausencia paulatina de los veteranos de C, podría inclinar la balanza nuevamente a favor de Delphi como el lenguaje moderno, pujante y bien pensado que siempre ha sido.

Me permito un modesto pronóstico: En la lista de mayo de 2014 Delphi habrá subido, por lo menos, a la posición 14 que tuvo no hace mucho tiempo y con tendencia a seguir en esa dirección.

¡Saludos!

[mamcx]

Empezado por Al González

que sumado al evidente estancamiento de Microsoft (Windows 8, .NET, C#...), a la finalización de los cinco minutos de fama de Java y a la inevitable ausencia paulatina de los veteranos de C, podría inclinar la balanza nuevamente a favor de Delphi como el lenguaje moderno, pujante y bien pensado que siempre ha sido.

Como se ve no solo en tiobe sino en otros lugares (como stacoverflow, github) C, C#, Java, C++ estan muy por encima en uso. Ni de lejos dejaran de ser relevantes durante esta decada.

El unico asombro es la subida inmensa de Objective-C (debido a iOS) que tambien tiene segura su posicion por largo rato.

De todo esos, C es el que menos probable desaparece. Ese maldito es mas duro de matar que John McClane!

Así que creo que hay que olvidarse de la idea de que todos esos engendritos de C van a salir de escena. Lo que importa es ver si los que le hacen contra como se ponen al frente y dan pelea buena.

Aunque los 1eros puestos están dominados por herederos de C, si se juntan todos, se vera que los que son alternativa hacen un grupo mas grande!


Pero el problema es que para estar al frente (y no volverse un lenguaje de nicho como RPG) hay que tener, de forma solida, al menos:

- Ser la opción por defecto de una plataforma exitosa (Windows, iOS, Sql, etc)
- Ser la contraparte "cool" (el pepsi de la coca-cola) de la anterior
- Ser la opción #1 de un estilo de programación en auge (Cloud, móvil, multi-core, etc)
- Ser el dueño indiscutible de un nicho que nadie mas le importa (R)

Basicamente, es como dicen las 22 leyes inmutables del marketing. Hay que ser el #1. Y si no se es el #1 en lo absoluto del mercado, hay que ser el #1 en un segmento lucrativo.

Delphi es/era la herramienta #1 como RAD y la contraparte cool a C++. Pero ha perdido ese enfoque (ha sido grave la caída de MS en ese sentido).


Delphi no es ahora dueño de un segmento en auge, y ha perdido cancha en donde es fuerte. Osea, es claro que .NET, Java y otros son malos como RAD, pero son "suficientes" y tienen la ventaja en que son la opcion por defecto de una(s) plataformas bases y pa rematar, son contendientes de peso en demasiadas categorias. Y ya que pocos usan varias herramientas a la vez, una vez que alguien usa un lenguaje intenta por todos los medios usarlo para todo.


Da un poco de luz:

http://www.wired.com/wiredenterprise...ing-languages/

http://www.eecs.berkeley.edu/~lmeyer.../viz/rank.html

[defcon1_es]

Empezado por mamcx

Conoces como es el desarrollo en iOS? Porque la estrategia de embarcadero es igual a la de Java en GUIS: Una gui alienigena, desligada de su plataforma de ejecucion y que no hace parte del ecosistema. Si ha mejorado con respecto a la version anterior, pues que bien. Pero eso no es el punto. No es mejorar delphi vs delphi. Es que sea una herramienta "nativa" de su entorno (en este caso, ios).

No conozco como es el desarrollo en iOS, pues lo poco que ví de XCODE (mira mis post sobre FireMonkey) me horrorizó: acostumbrado a delphi, XCODE me resulta difícil, críptico, casi ininteligible, y si a eso añadimos que no tengo ni idea de Objective-C... pues peor aun.

Pero me fío de Embarcadero al afirmar que con XE4 se consiguen apps verdaderamente nativas.

Empezado por mamcx

Pa que lo entiendas, Delphi es un exito en Windows porque corre sobre el API de windows (encapsulandolo de una forma mucho mejor) no porque (al igual que java) crea su propio GUI y luego corre de forma mediocre sobre varias plataformas.

Lo que ha hecho embarcadero, solo le causa gracia al programador de delphi. Pero no al programador de iOS. Significa echar al carajo todo lo que hay disponible, por un entorno que no ofrece una ganancia superior, y que visualmente, es mas bien feito. Lo que ha tenido exito pa IOS son aquellos que permiten operar de forma nativa, como monotouch (c#), rubymotion, varios proyectos de LUA/JS que permiten accesar al API interno.

Repito que no conozco mucho sobre el desarrollo para iOS, y mi poca experiencia que tuve con XE2+FireMonkey+XCODE fue de lo más nefasta,
pues ni siquiera los emuladores de XCODE te garantizan que tu app funcione correctamente en el dispositivo final.
Mi impresion sobre este tema es la siguiente: Se desarrolla en OSx con XCODE para otro S.O. "ligeramente diferente" como es iOS.

[[rretamar]]

Empezado por mamcx

El problema es que delphi tiene un nicho (GUIs para windows) y exige un precio ($$$) de entrada alto, ademas, no esta donde esta la accion ahora (moviles, cloud, web, apps distribuidas, etc). Asi que la pregunta se invierte: para que solo Delphi, que solo sirve (honestamente) como para apps RADs si con python, java, c++, etc puedo hacer de todo y es relevante para todo?

No veo haciendo una aplicación de escritorio en Python. O mejor dicho, no veo a Python apropiado (ni cerca) para desarrollar aplicaciones de escritorio. Y en Java...lo pensaría dos (y hasta tres) veces.

[[egostar]]

Empezado por mamcx

Basicamente, es como dicen las 22 leyes inmutables del marketing. Hay que ser el #1. Y si no se es el #1 en lo absoluto del mercado, hay que ser el #1 en un segmento lucrativo.

Que yo sepa, Delphi es #1 en aplicaciones de escritorio y seguirá siendolo hasta el final, cosa que a muchos no les agrada en lo más mínimo, sin embargo ha incursionado en otros mercados como iOS, Android, Linux, 64Bits, etc etc etc. y aunque no es a la velocidad que muchos desearían si que ha ido resolviendo uno a uno los obstaculos que se le han puesto, comenzando por el sistema operativo del que es nativo.

Empezado por mamcx

Lo que ha hecho embarcadero, solo le causa gracia al programador de delphi. Pero no al programador de iOS. Significa echar al carajo todo lo que hay disponible, por un entorno que no ofrece una ganancia superior, y que visualmente, es mas bien feito.

Pues que yo esté enterado, lo que se hace con Delphi está ajustado al estandar de colores y formas de iOS, o sea, que sea feo no es culpa de embt, sino del estandar que tiene iOS. Y yo estoy seguro que no tardará mucho en encontrar la fórmula de hacer app's nativas tanto en iOS como en Android.

Además, hay que recordar que Delphi siempre ha luchado contra enemigos y traidores que lo único que desean es que muera, me parece que es un producto demasiado bueno como para soportarlo y por eso tanta mierda en el entorno.

Yo no soy adivino para decir cuando Delphi va a morir, es más, no me importa, mientras esté vivo seguiré disfrutando de programar con lo que me siento cómodo y en ese tenor me parec que soy como usted, y mire amigo mamcx, a mi me agrada la forma que tiene de defender sus puntos, eso es tener pasión por lo que se hace, pero a veces creo que le gana la soberbia, relajese un poco y va a ver las cosas de diferente forma.


Saludos.

[mamcx]

Empezado por egostar

Que yo sepa, Delphi es #1 en aplicaciones de escritorio y seguirá siendolo hasta el final, cosa que a muchos no les agrada en lo más mínimo, sin embargo ha incursionado en otros mercados como iOS, Android, Linux, 64Bits, etc etc etc. y aunque no es a la velocidad que muchos desearían si que ha ido resolviendo uno a uno los obstaculos que se le han puesto, comenzando por el sistema operativo del que es nativo.

Que es la herramienta RAD #1 no se discute. Pero la estrategia que lleva para los demas frentes es muy pobre. Si te dijera que es mejor usar Java para una GUI que delphi, me creerias? No, porque conoces Delphi. Solo un programador de Java que no sabe nada mas creeria que Java es buenisimo pa eso. Es lo mismo: Si conoces lo que se mueve en moviles, iOS, Web y demas veras lo obvio que Delphi es una muy pobre eleccion en esos campos.

Empezado por egostar

Pues que yo esté enterado, lo que se hace con Delphi está ajustado al estandar de colores y formas de iOS, o sea, que sea feo no es culpa de embt, sino del estandar que tiene iOS.

Osea, no conoces de programacion en iOS. Pa que te hagas una idea: Usar Firemonkey en iOS es tan mala idea como usar Swing para hacer una GUI en windows.

No solo es una abstraccion "alienigena", sino que firemonkey esta plagado de problemas. Pa rematar no tiene la facilidad de uso de la VCL, ni el poder de Coccoa touch.

Coccoa touch es el framework para hacer GUIs en iOS, y esta de lejos como la mejor herramienta para esa labor. Es rapido, es flexible y poderoso y es la razon por la cual en iOS se pueden tener las mejores interfaces graficas del momento (y de feo no tiene nada)

Te digo como *odio* tener que programar en obj-c. Pero me lo aguanto para poder usar coccoa. Coccoa es la razon de mas peso en iOS, y sacrificar su uso es inaceptable (para un programador profesional en esta plataforma) como inaceptable seria que NO tuvieras acceso a la VCL y te tocara usar Winforms desde delphi, a las malas. Y que pa rematar, la alternativa tiene compromisos.

Empezado por egostar

Además, hay que recordar que Delphi siempre ha luchado contra enemigos y traidores que lo único que desean es que muera, me parece que es un producto demasiado bueno como para soportarlo y por eso tanta mierda en el entorno.

Antes la cosa era muy clara: Uso algo mas enruedado, complejo y maluco como C++/MFC/Vb o uso Delphi. Era una opcion muy clara, si uno podia elegir y si ademas conoce uno de Delphi.

Me gustaria que Delphi sea una opcion clara para las plataformas moviles. Te digo de nuevo que obj-c es la lata como lenguaje (pero, es rapido, flexible. Es la sintaxis que es maluca). He pensado *muy* seriamente pasarme a Mono/C# (pero me digo: Si es pa tirarse a otro C pues sigamos en lo mismo). La mejor alternativa ahora seria rubymotion (pero es aprender OTRO lenguaje/paradigma) y con python lo unico que hay es http://kivy.org/#home y tiene el mismo problema de delphi: Una gui alienigena.

El punto es que Delphi no sale en el radar de nadie que este serio en iOS. No tiene el gancho que se requiere (no es tanto por el precio... sino que no lo vale ni regalado).

Si fuera una opcion viable, me le tiraria en voladora. El problema es que ya conozco la plataforma lo suficiente pa darme cuenta si algo es o no es bueno pa ella.

Que quieres que te diga? No es por soberbia, de hecho, le jale tiempo a delphi mirando si valia la pena reescribir mi app principal (un punto de venta) para iPad.

Honestamente, no puedo recomendar a Delphi, al dia de hoy, para ese nicho. Asi como no lo recomendaria para hacer apps web.

Y que puede uno hacer? Comprarla y ya? No hay como arreglarla. Las recomendaciones (en los foros) que se hacen no se escuchan -cosa que he hecho durante años-. No hay librerias modernas en los nichos nuevos, y sentarse a hacerlas -que es lo que como comunidad mas deberiamos- valdria la pena si se viera la direccion y el animo.

He pensado hasta crear un nuevo lenguaje, parcialmente inspirado en pascal, pero eso es una solucion aun peor .

Que queda? Usarla pa lo que es bueno. Eso hago! Tengo varias apps hechas en delphi, y van del pelo. Pero no puedo usar la herramienta que (junto a python) mas me gusta en nada de lo que veo en el futuro inmediato.

[[Al González]]

Mario, si trabajaras en Embarcadero y te preguntaran ¿qué podemos hacer para que FireMonkey sea mejor o por lo menos tan bueno como Cocoa Touch?, ¿qué sugerirías? De tu meditada respuesta puede surgir alguna buena idea para tomarse en cuenta.

¿Por qué esa tendencia a pensar que Delphi las tiene de perder donde otros han sido los primeros? ¿Acaso no podemos, comunidad + fabricante, ponernos las pilas para hacerlo competitivo en esos terrenos? ¿No se dispone de capital, medios, profesionales cualificados y putas ganas para lograrlo?

¿Podrías dedicar el tiempo que sea necesario, en tu siguiente mensaje, para exponer un ejemplo contundente, sin margen de ambigüedades, argumentado con paciencia y sin limitarte a presentar meras referencias Web, que deje claro, sin lugar a dudas, las diferencias de calidad y productividad entre Cocoa Touch y el FireMonkey de Delphi XE4?

Y si Cocoa Touch es tan bueno como dices, ¿qué se necesita para usarlo desde Delphi? Yo estaría encantado de poder usarlo desde nuestro lenguaje, ¿es viable?

Ya tienes tarea, saludos y buenas noches.

Al González.

[mamcx]

Empezado por Al González

Mario, si trabajaras en Embarcadero y te preguntaran ¿qué podemos hacer para que FireMonkey sea mejor o por lo menos tan bueno como Cocoa Touch?, ¿qué sugerirías? De tu meditada respuesta puede surgir alguna buena idea para tomarse en cuenta.
.

Que es lo que hace a delphi una herramienta superior en Windows? Inventarse una libreria alienigena a la plataforma donde corre y "pintarla" para taparlo? Al contrario, es construir sobre esa plataforma y ofrecer un nivel de abstracción mejor.

Firemonkey es un intento de crear una libreria unificada para todas las plataformas. Esa es la estrategia de Java, y su éxito solo ha sido a los programadores que no les interesa hacer la mejor app posible sino simplemente tener su app en el mayor numero de plataformas. Es por eso que multiplataforma en el nivel de la GUI siempre ha sido equivalente a una interface mediocre (no muy mala, no muy buena, mediocre). Eso es lo que la gente le choca de "Java" y otras librerias similares.

El problema, es que al contrario del API de windows, Coccoa Touch es un (conjunto) de frameworks muy bien pensado. En muchos aspectos, mas avanzados que la VCL. Sin embargo, todo se puede mejorar y simplificar, por ejemplo hace dias vi https://github.com/clayallsopp/formotion (eso que muestra ahorra un monton de trabajo!).

Osea, si soy alguien que quiero tener la mejor app (a nivel de GUI) firemonkey ni me va ni me viene. Como dije antes, uno puede programar Winforms desde delphi, pero para que? Lo que me interesa es poder sacar provecho, no solo a un API mas completo, y superior, que cualquier intento de crear una GUI multiplataforma, sino que me da acceso a todos los componentes disponibles en el mercado (ej: http://www.cocoacontrols.com/platforms/ios/controls). Ganar firemonkey y perder Coccoa Touch no tiene gracia.

Ganar Firemonkey y poder usar Coccoa Touch sin problemas? Eso es *muy distinto*. Es lo mismo con windows: Ganas VCL y puedes usar API Win32. Es win-win. Si te sale mejor con VCL, genial, sino, no hay problema.

Y mejorar firemonkey, por lo que he visto es complicado. Conceptualmente no lo entiendo muy bien. Siendo coccoa touch complicado -como todo api grande- es muy facil de entender como se construyen nuevos controles. Son como 4 cosas que debes entender (Todo es un UIView, se construye con capas, usas datasources virtuales y haces delegados. Eso es todo). Lo hago de forma habitual todo el tiempo, y sin lios.

Empezado por Al González

¿Por qué esa tendencia a pensar que Delphi las tiene de perder donde otros han sido los primeros? ¿Acaso no podemos, comunidad + fabricante, ponernos las pilas para hacerlo competitivo en esos terrenos? ¿No se dispone de capital, medios, profesionales cualificados y putas ganas para lograrlo?
.

Yo no pienso eso! Ser primero es mucha ventaja, pero el segundo tiene la ventaja de ver el pasado y mejorarlo (prácticamente, esa es la estrategia de Apple ).

El problema es que los que han manejado Delphi no han tenido una estrategia que conduzca a todo eso. Y mucha gente de la comunidad se ha cansado, gente con talento.

Empezado por Al González

¿Podrías dedicar el tiempo que sea necesario, en tu siguiente mensaje, para exponer un ejemplo contundente, sin margen de ambigüedades, argumentado con paciencia y sin limitarte a presentar meras referencias Web, que deje claro, sin lugar a dudas, las diferencias de calidad y productividad entre Cocoa Touch y el FireMonkey de Delphi XE4?

Me la pones dificil! Sin *referencias*! si eso es lo que mas me gusta! La diferencia se nota en las mismas apps, su fluidez, desempeño, y versatilidad. Has usado un iPhone o iPad? Solo es comparar las apps que alli se ven con las que se ven en windows.

En fin, te pongo ejemplos, sacados de mis proyectos (asi que no son de lo mejor, porque programador de GUI no soy):

Asi es como se anima una transicion, con efecto de "pasar pagina", a pesar que donde hago eso, hay cientos de controles graficos. Cero problemas de desempeño:

Código PHP:

- (IBAction)saveDocument:(id)sender {
    if ([self saveRecord]) {
        [UIView transitionWithView:self.view
                          duration:0.7
                           options:UIViewAnimationOptionTransitionCurlDown
                        animations:^{
                            [self newDocument:0];
                        } completion:^(BOOL finished) {
                        }];
    }
} 


Asi es como puedo graficar miles de imagenes, sin problemas de desempeño:

Código PHP:

// The cell that is returned must be retrieved from a call to -dequeueReusableCellWithReuseIdentifier:forIndexPath:
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath {
    ProductIconViewCell *cell = (ProductIconViewCell *)[collectionView dequeueReusableCellWithReuseIdentifier:@"IconCell" forIndexPath:indexPath];
    
    NSDictionary *p = self.data[indexPath.row];
    NSString *img = [p objectForKey:@"imageName"];
    NSString *imgFile = [[p objectForKey:@"image"] lastPathComponent];
    
    cell.imageBtn.tag = indexPath.row;
    [cell.imageBtn setBackgroundImage:[UIImage imageNamed:imgFile] forState:UIControlStateNormal];
    cell.title.text = img;

    [cell.imageBtn setTitle:self.ref forState:UIControlStateNormal];

    return cell;
} 


Asi convierto un HTML a un PDF, el HTML esta full con CSS3:

Código PHP:

    DDLogInfo(@"Report HTML %@", templatePath);

    NSError * error;
    
    content = [GRMustacheTemplate renderObject:self
                                                fromString:content
                                                     error:&error];
    
    [content writeToFile:[@"~/Documents/demo.html" stringByExpandingTildeInPath] atomically:YES encoding:NSUTF8StringEncoding error:nil];

    if (error && [self.delegate respondsToSelector:@selector(reportFail:)]) {
        [self.delegate reportFail:error];
    }


[NDHTMLtoPDF createPDFWithHTML:content
                                         pathForPDF:[@"~/Documents/demo.pdf" stringByExpandingTildeInPath]
                                           delegate:self
                                           pageSize:kPaperSizeA4
                                            margins:UIEdgeInsetsMake(10, 5, 5, 5)]; 


QUiero visualizar un conjunto de datos igual a http://pinterest.com/all/, control el cual no existe. Asi que necesito inventarmelo (y los que mire open source no me gustaron):

Código PHP:

//
//  NewsListViewController.m
//  DisplayNews
//
//  Created by mamcx on 15/03/13.
//  Copyright (c) 2013 El malabarista. All rights reserved.
//

#import "NewsListViewController.h"

@implementation NewsListCell

- (UILabel *) buildLabel:(NSString *)className {
    UILabel *label = [[UILabel alloc] init];
    label.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin | UIViewAutoresizingFlexibleBottomMargin;
    label.backgroundColor = [UIColor clearColor];
    
    [NUIRenderer renderLabel:label withClass:className];

    return label;
}

- (id)initWithFrame:(CGRect)frame
{
    self = [super initWithFrame:frame];
    if (self) {
        // Initialization code        
        self.lbTitle = [self buildLabel:@"LargeLabel"];
        self.lbTitle.lineBreakMode = NSLineBreakByWordWrapping;
        self.lbTitle.numberOfLines = 0;

        self.lbDate = [self buildLabel:@"NormalLabel"];
        self.lbSource = [self buildLabel:@"NormalLabel"];

        [self addSubview:self.lbTitle];
        [self addSubview:self.lbDate];
        [self addSubview:self.lbSource];
    }

    return self;
}

- (void) layoutSubviews {
    [super layoutSubviews];
    
    self.lbDate.frame = CGRectMake(10, 5, self.frame.size.width - 20, 20);
    [self.lbDate sizeToFit];
    
    self.lbTitle.frame = CGRectMake(0, self.lbDate.frame.size.height + 6, self.frame.size.width - 20, self.frame.size.height - self.lbDate.frame.size.height*2 - 6);
    self.lbTitle.center = CGPointMake(self.frame.size.width/ 2, self.frame.size.height/2);
    
    [self.lbSource sizeToFit];
    self.lbSource.frame = CGRectMake(10, self.frame.size.height - self.lbSource.frame.size.height - 6, self.frame.size.width - 20, self.lbSource.frame.size.height);
    
    [NewsSource adjustFontSizeToFit:self.lbTitle from:14 to:60];
}
@end

@interface NewsListViewController ()

@end

@implementation NewsListViewController

- (void)viewDidLoad
{
    [super viewDidLoad];

    self.delegate = self;
    
    self.onSingleTap = ^(UIView* view, NSInteger viewIndex){
        NSLog(@"Single press on %@, at %d", view, viewIndex);
        
        [[NSNotificationCenter defaultCenter]
            postNotificationName:NOTIFY_SHOW_NEW object:[NSNumber numberWithInt:viewIndex] userInfo:nil];
        
        __weak NewsListViewController *weakSelf = self;
        
        [weakSelf.navigationController popViewControllerAnimated:YES];
    };

    self.onLongPress = ^(UIView* view, NSInteger viewIndex){
        NSLog(@"Long press on %@, at %d", view, viewIndex);
    };
    
    self.onDoubleTap = ^(UIView* view, NSInteger viewIndex){
        NSLog(@"Double tap on %@, at %d", view, viewIndex);
    };

    [self reloadData];
}

- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {
    BDDynamicGridCell *theCell = (BDDynamicGridCell*)cell;
    
    theCell.gridContainerView.backgroundColor = [UIColor lightGrayColor];
    
    for (UIView *v in theCell.gridContainerView.subviews) {
        //[NUIRenderer render:v];
        v.backgroundColor = self.view.backgroundColor;
    }
}

- (NSUInteger)numberOfViews
{
    return [NewsSource SourceDB].newsItems.count;
}

-(NSUInteger)maximumViewsPerCell
{
    return 3;
}

- (UIView *)viewAtIndex:(NSUInteger)index rowInfo:(BDRowInfo *)rowInfo
{
    
    NewsListCell * cell = [[NewsListCell alloc] initWithFrame:CGRectMake(0, 0, 300, 300)];
   
    FeedItem *item = [NewsSource SourceDB].newsItems[index];
    
    cell.lbTitle.text = item.item.title;
    cell.lbDate.text = [[NewsSource SourceDB] formatDate: item.item.date];
    cell.lbSource.text = item.source.name;
    
    return cell;
}

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
{
    //Call super when overriding this method, in order to benefit from auto layout.
    [super shouldAutorotateToInterfaceOrientation:toInterfaceOrientation];
    return YES;
}

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration {
    [self reloadData];
}

- (CGFloat)rowHeightForRowInfo:(BDRowInfo *)rowInfo
{
    return 300;
}
@end 


P: La parte visual se hace con Interface Builder, no tan bueno como el diseño en Delphi, pero apenas suficiente. De todo lo anterior, es notable lo poco código que requieren, excepto por lo largos que son los metodos en obj-c.

Animar, rotar, graficar, componer controles en base a otros, alimentar los datos no importan lo bastante que sean, a pesar de correr en maquinas menos potentes que un PC, y aplicar efectos y estilos visuales atractivos, son las cosas que programadores normales como yo podemos hacer, sin problemas y sin sudar mucho.

Hay muchas cosas que salen genial. Es dificil sin apuntar a algo concreto (no se si les parecera mucha gracia mis ejemplos, a mi si porque la programacion GUI no es mi fuerte ). Por ejemplo, necesito hacer una tarea en el "background" sin frenar la GUI:

Código PHP:

dispatch_async(queue, ^{
        self.inventory = [Product retrieveInventoryItems];
        dispatch_async(dispatch_get_main_queue(), ^{            
            lbHello.text = @"Inventory Loaded\n\nHow can I help you?";
        });
    }); 


O necesito notificar (broadcast) a todo el que escuche que algo paso:

Código PHP:

[[NSNotificationCenter defaultCenter] postNotificationName:DB_RECORD_CHANGED object:ds userInfo:nil]; 


En fin, Coccoa Touch es el equivalente a la VCL (ya que no solo cubre la parte visual, sino que ademas maneja otras sub-apis, como las de audio, multimedia, sqlite, mapas y otros)

[[Al González]]

Prometo dejar de alimentar a los troles.

Empezado por mamcx

Firemonkey es un intento de crear una libreria [sic] unificada para todas las plataformas. Esa es la estrategia de Java, y su éxito solo ha sido a los programadores que no les interesa hacer la mejor app posible sino simplemente tener su app en el mayor numero de plataformas.

Entonces, dado que Java fracasó en la calidad de sus aplicaciones, FireMonkey también lo hará, ¿esa es la lógica?

Empezado por mamcx

El problema, es que al contrario del API de windows, Coccoa [sic] Touch es un (conjunto) de frameworks muy bien pensado. En muchos aspectos, mas avanzados que la VCL.

Pues eso para mí no es un problema, sino una buena oportunidad de mejorar nuestros desarrollos para iOS. Vuelvo a preguntar: ¿qué se necesita para usar Cocoa Touch desde Delphi?

Empezado por mamcx

Ganar Firemonkey y poder usar Coccoa Touch sin problemas? Eso es *muy distinto*. Es lo mismo con windows: Ganas VCL y puedes usar API Win32.

Insisto, ¿de qué forma se podría?

Empezado por mamcx

Y mejorar firemonkey, por lo que he visto es complicado. Conceptualmente no lo entiendo muy bien.

¡Ajá! Eso ya lo venía sospechando.

Empezado por mamcx

El problema es que los que han manejado Delphi no han tenido una estrategia que conduzca a todo eso.

¿Alguna idea para ellos? De ser posible, bien redactada.

Empezado por mamcx

Me la pones dificil! Sin *referencias*!

Ese es el problema de no saber leer (o sí saber, pero hacerlo a las carreras, sin el debido interés).

Empezado por Al González

[...] sin limitarte a presentar meras referencias Web [...]

Empezado por mamcx

Has usado un iPhone o iPad?

Por ahora, apenas dos o tres toques de pantalla en el teléfono de un familiar. Muy llamativas interfaces de usuario, por cierto. ¿Y tú...

Empezado por egostar

[...] ¿has hecho alguna aplicación iOS con XE4?

Esa pregunta aún no ha sido respondida.

Empezado por mamcx

En fin, te pongo ejemplos, sacados de mis proyectos...

Sí, gracias, pero ese código no me dice nada. ¿No se puede conseguir lo mismo con FMX o con acceso directo a Cocoa Touch desde Delphi? ¿Te parece si nos ponemos a adaptar FMX a Cocoa? ¿Mucho trabajo? Sólo un poco más del que dedicamos a quejarnos y debatir, creo yo...

Empezado por mamcx

En fin, Coccoa [sic] Touch es el equivalente a la VCL (ya que no solo cubre la parte visual, sino que ademas maneja otras sub-apis, como las de audio, multimedia, sqlite, mapas y otros)

Reitero, ¿sabes cómo podríamos aprovecharla desde Delphi, ahora que tenemos la posibilidad de generar aplicaciones para iOS?

No dudo que tengas la experiencia necesaria en iOS como para acarrear esos aires de suficiencia, pero un poco de paciencia y serena orientación para los plebeyos ignorantes que apenas vamos ingresando a ese mundo no estaría mal. Ábrete un poco a la idea de que muy pocas cosas en este planeta son imposibles. Si ya pueden crearse con Delphi aplicaciones para iOS, posiblemente de mayor calidad que las de Java, y muy pronto para Android también (que en mi opinión tendrá más valor), creo que deberíamos estar de plácemes los programadores de este lenguaje. Seguramente pediremos (pues es casi nuestra obligación) que se mejoren los particulares aspectos que veamos mal de XE4, pero primero hay que conocer esos aspectos. No dar por hecho que todo está mal sólo porque algo no entendimos o porque no nos gustó la forma en que fue diseñado en una pasada versión.

Como te comenté en otra ocasión, mi estimado Mario, arrima el hombro más allá de la crítica. La Comunidad Delphi te necesita.

Saludos.

[[egostar]]

Empezado por mamcx

Que es la herramienta RAD #1 no se discute. Pero la estrategia que lleva para los demas frentes es muy pobre. Si te dijera que es mejor usar Java para una GUI que delphi, me creerias? No, porque conoces Delphi. Solo un programador de Java que no sabe nada mas creeria que Java es buenisimo pa eso. Es lo mismo: Si conoces lo que se mueve en moviles, iOS, Web y demas veras lo obvio que Delphi es una muy pobre eleccion en esos campos.

A ver, vamos por partes, yo no pienso incursionar en iOS para que sea mi mercado primario, eso es lo que no has entendido o nadie te ha explicado, Delphi no es para MAC, iOS y demás yerbas, pero te está permitiendo desarrollar aplicaciones complementarias a tus desarrollos hechos en windows para que puedas hacer más amplio tu mercado.

Empezado por mamcx

Osea, no conoces de programacion en iOS. Pa que te hagas una idea: Usar Firemonkey en iOS es tan mala idea como usar Swing para hacer una GUI en windows.

No solo es una abstraccion "alienigena", sino que firemonkey esta plagado de problemas. Pa rematar no tiene la facilidad de uso de la VCL, ni el poder de Coccoa touch.

Coccoa touch es el framework para hacer GUIs en iOS, y esta de lejos como la mejor herramienta para esa labor. Es rapido, es flexible y poderoso y es la razon por la cual en iOS se pueden tener las mejores interfaces graficas del momento (y de feo no tiene nada)

Pues no, no conozco iOS, pero eso es lo bonito de esto, ya he hecho un par de app's con delphi que funcionan sin problema así usen firemonkey o lo que sea, no me interesa porque te repito, no es mi mercado primario, para mi es un plus de mis desarrollos para Windows.

Y lo de feo tú lo has dicho no yo, yo sólo dije que las app se ajustan al estandar de colores y formas de iOS.

Empezado por mamcx

Te digo como *odio* tener que programar en obj-c. Pero me lo aguanto para poder usar coccoa. Coccoa es la razon de mas peso en iOS, y sacrificar su uso es inaceptable (para un programador profesional en esta plataforma) como inaceptable seria que NO tuvieras acceso a la VCL y te tocara usar Winforms desde delphi, a las malas. Y que pa rematar, la alternativa tiene compromisos.

Insisto, no soy profesional de iOS, si soy profesional en windows.

Empezado por mamcx

Me gustaria que Delphi sea una opcion clara para las plataformas moviles. Te digo de nuevo que obj-c es la lata como lenguaje (pero, es rapido, flexible. Es la sintaxis que es maluca). He pensado *muy* seriamente pasarme a Mono/C# (pero me digo: Si es pa tirarse a otro C pues sigamos en lo mismo). La mejor alternativa ahora seria rubymotion (pero es aprender OTRO lenguaje/paradigma) y con python lo unico que hay es http://kivy.org/#home y tiene el mismo problema de delphi: Una gui alienigena.

El punto es que Delphi no sale en el radar de nadie que este serio en iOS. No tiene el gancho que se requiere (no es tanto por el precio... sino que no lo vale ni regalado).

Si fuera una opcion viable, me le tiraria en voladora. El problema es que ya conozco la plataforma lo suficiente pa darme cuenta si algo es o no es bueno pa ella.

De nuevo, Delphi es para Windows, y el plus es poder hacer aplicaciones para iOS y proximamente para Android, pero como complemento a nuestras aplicaciones windows, tú tienes otra perspectiva porque estás inmerso en ese operativo y tienes otras necesidades, pero eso no hace menos a Delphi, de eso puedes estar seguro.

Empezado por mamcx

Y que puede uno hacer? Comprarla y ya? No hay como arreglarla. Las recomendaciones (en los foros) que se hacen no se escuchan -cosa que he hecho durante años-. No hay librerias modernas en los nichos nuevos, y sentarse a hacerlas -que es lo que como comunidad mas deberiamos- valdria la pena si se viera la direccion y el animo.

La verdad es que éste último año las cosas han cambiado un poco, realmente hubo mucho "feedback" de parte de los beta-tester, claro no es aún lo óptimo, pero la apuesta está hecha y yo creo que si se puede, a pesar de los "buenos" deseos de quien quiere que Delphi se muera y de los que están abandonando el barco por miedo ¿miedo?

Y reitero, yo estoy con delphi hasta el final, sea como sea.

Por cierto, ¿ has hecho alguna app iOS con XE4 ? Yo si.

Saludos

[[egostar]]

Por cierto, me he referido siempre a las app móviles que es donde enfoco mi mercado, no a aplicaciones para escritorio de MAC, y lo comento para que queden claros mis argumentos.

Saludos

[diegofhernando]

Hola a todos... sé que no tienen idea de quién soy, pues bien, les digo que he sido parte del foro desde hace muchos años, aquí creci como programador Delphi y en su momento fue mi mejor escuela para crecer como profesional y como ven, ocasionalmente me paso por aquí a ver como van las cosas con mi querido lenguaje, esta vez, no pude contener las ganas de postear y es simplemente para publicar mi humilde punto de vista al respecto de este tema.

Desde hace 3 años TUVE que dejar a Delphi como mi lenguaje de desarrollo principal y es que no es posible tapar el sol con las manos, la tendencia como lo dice el amigo mamcx es el desarrollo web, cloud y demás artilugios de los últimos años y para ser sincero en mi caso Delphi no pudo satisfacer mis exigencias y las de mis clientes, en su momento tuve que aceptar tristemente que la grandiosa herramienta que me habia traído tantas satisfacciones ya no era suficiente para mi, así pues que me "embarque" en ese nuevo rumbo que hasta ese momento era completamente nuevo para mi y les puedo decir que fué una de las mejores decisiones que he tomado como desarrollador.

Finalmente y para concretar mi publicación, para mi es claro que Delphi no puede cubrir las necesidades de las plataformas web, al menos no como uno esperaría a nivel profesional y también es claro que para desarrollos Windows no hay nada mejor que Delphi, como les digo, actualmente lo que me da de comer está en la web y no es un secreto que es una plataforma que cada día toma mas fuerza... de hecho en mi grupo de compañeros ya no hay nadie que desarrolle aplicaciones de escritorio, mi humilde punto de vista que si Delphi llegase a "fallecer" (no es literal) no sería por mala herramienta, sería por que el sector en el que realmente es bueno ya no sea lucrativo.

Salu2.

[mamcx]

Empezado por rretamar

No veo haciendo una aplicación de escritorio en Python. O mejor dicho, no veo a Python apropiado (ni cerca) para desarrollar aplicaciones de escritorio. Y en Java...lo pensaría dos (y hasta tres) veces.

El punto mas fuerte de Delphi es la VCL. Aunque pa python se puede usar http://qt-project.org/wiki/Category:...ndings::PySide y otros. El mejor resultado se logra con OSX, las apps son indistinguibles de las nativas hechas en OSX.