Ok, osea que basicamente los argumentos son claros. Solo me gustaria agregar:
Cita:
|
El concepto de IDE Delphi: editor (visual y textual) + compilador + depurador + utilidades diversas para el desarrollo, no ha tenido (en general) éxito en los ambientes Unix
|
Cita:
|
En Unix/Linux, los desarrolladores (de aplicaciones gráficas) se enfrentan a la tarea de construir aplicaciones para diferentes servidores gráficos, para diferentes gestores de ventanas y escritorios, cada uno con sus propios API's, al contrario que Windows
|
Creo que por eso es que Borland saco el C++ Builder X. Aunque de todas maneras (no se, asi que si estoy hablando pavadas
) que TAN amplio puede ser esa diversidad? o al menos, ¿justifica pegarle a tantos blancos, o mejor concentrarse en los mas populares? O tal vez en mejor hacer primero los planes y definir el mercado al cual va la solucion...
He observado que de Linux ya existe un conjunto de distribuciones mas o menos dominantes (Red Hat, Suse, Mandrake?), y de entornos graficos solo se habla en general de 2 (Gnome y KDE). En las muchas discusiones sobre Kilyk en los foros de Borland, los que usan Kilyk/Linux dicen que han podido desplegar sus aplicaciones con Kilyk "casi" sin problemas en muchas distribuciones. Por otro lado, no es tan facil con Windows, aunque igual toca lidiar con muchas "distribuciones" como Win95,Win98 1 y 2da edicion, WinME (no este no por favor!), Win 2000, XP Home y PRO, 2003 y sus respectivos service packs y demas. Sin embargo, segun lo que entiendo a Kilyk si le falta versatilidad porque esta amarrado a X versiones de las librerias y meterlo en un Linux nuevo da lios. Es por eso que la opinion de muchos en los foros de Borland (e igual otros opinan mas estilo que la comunidad linux no le apetece el producto...lo cual tiene razones logicas tambien) es que a Kilyk le falta mas soporte (o sea, mas compromiso y que asi como Delphi se adapta muy bien al entorno Windows, sea igual al Linux)
De todas maneras, esperemos que surta efecto los esfuerzo por estandarizacion que se estan haciendo para Linux. No hay ningun problema en tener que lidiar con multiples cosas, igual Html por ejemplo corre en toneladas de clientes, y proyectos como Mozilla muestran que si es posible pegarle a multiples targets de forma exitosa, sino el hecho de que no se sabe si la especificacion se sostendra estable (que no le den a un API por llamarlo MostrarVentana y mañana VentanaMostra, por poner un ejemplo malisimo
). En ese campo, MS es mucho mejor. Por mas que se maldiga, MS ha sido muy consistente en cuanto a sostener las API "estables" mientras se pueda, y ha sido la maldicion de Unix el que a todos les de por hacer cada cosa por su lado: Es imposible mantener un mercado cautivo asi. Ahora que con la madurez que ha alcanzado Linux, no dudo que que se logre lo mismo a algo mejor...
Cita:
|
Ahora bien, qué se entiende por productividad
|
No se, cada cual la interpreta diferente. Es como un conjunto de muchas cosas. Con VB, por ejemplo se puede escribir codigo mas "rapido" que en Delphi y se hacen formas muy muy rapido y bonito, pero al terminar el dia se gasto mas tiempo haciendo la aplicacion de bases de datos. Acces da la patada a Delphi en hacer una aplicacion de principio a fin con un BD, pero Delphi gana (bueno, cualquiera le gana en Acces excepto la facilidad) para hacer un desarrollo serio. Con Visual FoxPro la manipulacion de datos da risa, pero el poco soporte a todo lo que esta por fuera de datos pesa en su contra. Para mi Delphi es mas productivo porque permite un desarrollo RAD consistente en todos los frentes, y donde no lo da, al menos se puede contar con que un tercero ha hecho algo. No un desarrollo "brutal" RAD, pero si un desempeño consistente. Es como mejor algo consistente, que algo brutal en algo pero muy deficiento en lo otro.... digo yo...
El tipo de desarrollo influye en la percepcion de productividad, no es posible ser mas productivos haciendo una pagina Web de contenido en Delphi comparado con PHP y ASP.NET, pero se reversa cuando metemos que la pagina no es de contenido sino mas bien una emulacion de una aplicacion o si estamos dentro de una estrategia de multiples plataformas (como aplicaciones nativas que tienen componentes para la Web, sitios de administracion remota, etc...). Al final, uno termina mezclando herramientas y tecnologias....