TIOBE: Delphi is on its way out

[mamcx]

Empezado por jlrbotella

Embarcadero siempre depende de una plataforma sea Windows, iOs, Android; con lo que supone que tendrá que competir con los propios fabricantes (Microsoft, Apple, Google) y estos siempre van un paso por delante

Es cierto que el dueño de la plataforma tiene su ventaja, pero no creo que eso signifique no haya forma de aventajarlos. De hecho, Delphi es una mejor expresion de la plataforma visual de Windows, y hay muchos proyectos (python, ruby, php, erlang, haskell) que son reconocidos por ser mejores en varios aspectos (y que de hecho, hasta lo usan esas mismas empresas).

Lo que hace que algo sea bueno es que sea bueno. Su estrategia, implementacion y efectividad de mercadearlo a quienes estan interesados. Ademas, hay cosas que atraen mas un mercado que a otro (por ejm las empresas grandes prefieron lo que las otras grandes usan, pero a la startup y freelancer eso ni le va ni le viene).

[jlrbotella]

No dudo de que Delphi pueda ser un buen producto, ya que mis primeros programas fueron creados en Delphi y todavía hoy funcionan!. Pero lo que quiero decir, es que, Embarcadero tiene que ponerse las pilas ya que porque poco a poco va perdiendo mercado de desarrollo y de eso, no me cabe duda.

Su apuesta por Firemonkey le veo arriesgada debido a que existen otros productos como Qt Java en el mercado y funcionan muy bien. Hace un tiempo vi un herramientas de la empresa FourJs ( http://www.4js.com/ ) que la verdad me impresiono ya que con un mismo código funciona el desarrollo en todas las plataformas (Web, Escritorio) a ver si algún día sería posible verlo en Delphi.

También me gustaría ver si se lanza un Firemonkey para Linux, que aunque no lo creaís muchas empresas públicas están optando migrar sus Windows 7, XP a la plataforma Redhat / Ubuntu con virtualizaciones de escritorios.

No sería mala idea saber la hoja de ruta del Rad Studio para este año 2013-2014 y así estudiar el ciclo de vida de los productos de Embarcadero en las nuevas plataformas Winrt, Android, etc...

Bueno eso es todo y buen fin de semana.

[jhonny]

Empezado por jlrbotella

No sería mala idea saber la hoja de ruta del Rad Studio para este año 2013-2014 y así estudiar el ciclo de vida de los productos de Embarcadero en las nuevas plataformas Winrt, Android, etc...

Bueno eso es todo y buen fin de semana.

¿No se si te refieres a esta?... bueno, creo que es la más actualizada hoja de ruta que hay por ahora...

[[rretamar]]

En Linux tenemos a Lazarus / Free Pascal que cada día mejoran más, y son multiplataforma REAL. Además el IDE funciona NATIVAMENTE en distintos OS. Y su coste es CERO. No veo que tenga mucho sentido un firemonkey para Linux.

[[egostar]]

Empezado por rretamar

En Linux tenemos a Lazarus / Free Pascal que cada día mejoran más, y son multiplataforma REAL. Además el IDE funciona NATIVAMENTE en distintos OS. Y su coste es CERO. No veo que tenga mucho sentido un firemonkey para Linux.

Yo si le veo sentido, bajo éste concepto, tienes un único código base para todas las plataformas, imagina por un instante que tienes que desarrolllar una aplicación que corra en windows, pero que puedas acceder desde iPhone, desde Android, desde Linux y sólo te preocuparías por la cuestión estética, pero el código es el mismo para todos los ambientes. Por donde lo veas resulta genial.

Otra cosa es que no se quiera invertir un duro en las herramientas que uses, ante eso nada compite. Y siendo sinceros, muchos se han ido por la libre durante toda su vida "profesional" y no han gastado un sólo duro en las versiones de Delphi, sólo se preocupan por encontrar el crack de la última versión y suele ser que son los que más se quejan de los precios.

Saludos

[[nlsgarcia]]

rretamar,

Empezado por rretamar

...No veo que tenga mucho sentido un firemonkey para Linux...

Revisa este link:

Desarrollo plataforma cruzada FireMonkey : http://www.webhostinghub.com/support...ada-firemonkey

Espero sea útil

Nelson.

[[Al González]]

Empezado por egostar

[...] desarrolllar una aplicación que corra en windows, pero que puedas acceder desde iPhone, desde Android, desde Linux y sólo te preocuparías por la cuestión estética, pero el código es el mismo para todos los ambientes. Por donde lo veas resulta genial.

Totalmente de acuerdo. Imposible no darle valor alguno a esa ventaja.

Empezado por rretamar

[...]todavía me acuerdo de algunos mensajes de Andreano despotricando contra este SO...[/b]

"¡Linux es una mierda!" es la frase más desafortunada que le escuché pronunciar en un par de reuniones. Pero quizá debamos darle el beneficio del tiempo transcurrido (alrededor de cinco años). Todos hemos dicho una que otra barbaridad de la que tiempo después nos retractamos, cuando conocemos mejor el tema. Es de humanos equivocarse.

Empezado por DarkDudae

No obstante, investigando un poco, llegué al estupendo blog de un koreano llamado Simon Choi, donde se explica cómo usar las herramientas de X-Code / Coccoa desde RAD Studio:

Primeramente, agregamos al uses de nuestro formulario [...]

Muchísimas gracias, DarkDudae. ¡Justo lo que preguntaba en anteriores días! Como es costumbre en Delphi, siempre hay más de una manera de resolver algo.

Sin duda será algo a lo que eche un vistazo en las próximas semanas.

Saludos.

[jlrbotella]

Empezado por jhonny

¿No se si te refieres a esta?... bueno, creo que es la más actualizada hoja de ruta que hay por ahora...

Gracias por tu aporte, ahora solo queda esperar a Linux y WinRt.

[[rretamar]]

Si HOY quiero desarrollar una aplicación para LINUX (y que a la postre pueda recompilar en Windows con no demasiados cambios) ya tengo el lenguaje de programación: Object Pascal y ya tengo la herramienta: Free Pascal / Lazarus. Y este último no es lo que era hace dos o tres años: ahora funciona muy bien, ha mejorado mucho. Más viendo que la plataforma LINUX no está ni cerca entre las prioridades de Embarcadero (todavía me acuerdo de algunos mensajes de Andreano despotricando contra este SO...y contra Firebird).

Y sobre el pago de licencias, pagué tanto la licencia de mi Windows como la de Delphi, aunque mi trabajo principal no es de desarrollador de software, pero lo necesitaba para un proyecto y ahí está. Pero eso no quita que no tenga que buscar otras alternativas (Libres en este caso) que llenen huecos a los que Delphi no llega.

[[egostar]]

Empezado por rretamar

Si HOY quiero desarrollar una aplicación para LINUX (y que a la postre pueda recompilar en Windows con no demasiados cambios) ya tengo el lenguaje de programación: Object Pascal y ya tengo la herramienta: Free Pascal / Lazarus. Y este último no es lo que era hace dos o tres años: ahora funciona muy bien, ha mejorado mucho. Más viendo que la plataforma LINUX no está ni cerca entre las prioridades de Embarcadero (todavía me acuerdo de algunos mensajes de Andreano despotricando contra este SO...y contra Firebird).

Y sobre el pago de licencias, pagué tanto la licencia de mi Windows como la de Delphi, aunque mi trabajo principal no es de desarrollador de software, pero lo necesitaba para un proyecto y ahí está. Pero eso no quita que no tenga que buscar otras alternativas (Libres en este caso) que llenen huecos a los que Delphi no llega.

Y yo no estoy diciendo lo contrario, sólo respondí a tu comentario "No veo que tenga mucho sentido un firemonkey para Linux." yo sostengo que cuando eso sea posible tendrá mucho sentido.

El asunto de licenciamiento o gratuidad no es el tema de mi respuesta, eso lo decide cada uno de acuerdo a sus necesidades.

Saludos

[DarkDudae]

Interesante debate, sin duda alguna. Recientemente he estado probando Firemonkey, y bueno, es cierto que está bastante limitado y que no es tan poderoso como Coccoa en algunos aspectos.

No obstante, investigando un poco, llegué al estupendo blog de un koreano llamado Simon Choi, donde se explica cómo usar las herramientas de X-Code / Coccoa desde RAD Studio:

Primeramente, agregamos al uses de nuestro formulario las librerias de Coccoa y Objective-C, y definimos algunos detalles sobre las clases de estos objetos en la plataforma nativa:

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Dialogs, FMX.StdCtrls, FMX.Platform.iOS,
  //
  System.TypInfo,
  Macapi.ObjectiveC,Macapi.ObjCRuntime,
  iOSapi.CocoaTypes,iOSapi.foundation,iOSapi.uikit,iOSapi.CoreGraphics,
  FMX.Layouts, FMX.Memo;

type
  //
  IBtnDelegate = interface(NSObject)
    procedure BtnPressed; cdecl;
  end;
  //
  TBtnDelegate = class(TOCLocal)
   Private
    Finx   : Integer;
    FMemo  : TMemo;
   Public
    constructor Create( inx : integer; memo : TMemo );
    function  GetObjectiveCClass : PTypeInfo; override;
    procedure BtnPressed; cdecl;
  end;

  // protocol -----------------------------------------------------------------
  mycalcEvent = interface(IObjectiveC)
   procedure oncalcEventA(inx :Integer; ext1 : Integer); cdecl;
   procedure oncalcEventB(inx :Integer; ext1 : Integer); cdecl;
  end;
  //
  TmycalcEvent = class(TOCLocal,mycalcEvent)
  private
  public
   procedure oncalcEventA(inx :Integer; ext1 : Integer); cdecl;
   procedure oncalcEventB(inx :Integer; ext1 : Integer); cdecl;
  end;

Luego, podemos crear por ejemplo un botón usando estas clases/APIs en runtime, eso sí, acomodándonos a la estructura de la API de Apple que nos resumió hace algunos post el compañero mamcx (target, action, event, delegate):

procedure TForm1.Btn_CreateBtnClick(Sender: TObject);
begin
 Btn := TUIButton.Wrap( TUIButton.OCClass.buttonWithType(UIButtonTypeRoundedRect) );
 //
 Btn.setFrame ( CGRectMake(40,130,170,40) );
 Btn.setTitle (NSStr('iOS UIButton'),UIControlStateNormal);
 //
 BtnDelegate := TBtnDelegate.Create(10,Memo1);
 Btn.addTarget( BtnDelegate.GetObjectID,       // target
                sel_getUid('BtnPressed'),      // action
                UIControlEventTouchDown);      // event
 //
 WindowHandleToPlatform(Self.Handle).View.addSubview(Btn);
end;

Está claro que no es un proceso muy "amigable", pero sinceramente, he hecho algún que otro programa con X-Code y lo cierto es que no difiere excesivamente a lo planteado en este post (con la salvedad de que tenemos que "sufrir" con Objective-C).

No creo que pase mucho tiempo antes de que alguna compañía (o la propia Embarcadero) "encapsule" estos procedimientos en algún set de componentes y nos brinde gran parte de las virtudes de las APIs de Apple sin renunciar a la comodidad y estilo de Delphi.

Os adjunto el código fuente completo (puesto que sólo he agregado en el post los puntos básicos), y os invito a que le echéis un vistazo al blog que os comentaba donde podréis encontrar este y otros muchos ejemplos:

http://blog.naver.com/simonsayz

Un saludo