¡Te lo dije!
Permítame que me eche unas risas... ya, sí, ya puedo continuar...Sin duda, usted conocerá a Beavis y su amiguete Butt-head. Son dos friquis metaleros de dibujos animados, que se pasaban la vida intentando "anotar"; meter un gol, ya me entiende... Cuando la serie llegó a su fin, el creador, jocosamente, escribió un epitafio para sus personajes:
- They never scored.
Nunca "anotaron". Pobrecillos. Lo mismo, por desgracia, se puede decir del compilador de Borland para .NET: nunca llegó a marcar gol. Murió virgen aunque no casto.
¿Una tragedia? Nah. Tragedias son las guerras, el hambre, las enfermedades. Concedo que puede ser una molestia. Mi sabor favorito de Häagen-Dazs ya no se vende en mi barrio. Es molesto, e irritante, eso sí. De todos modos, tengo todo el derecho del mundo a decir: ¡TE LO DIJE!
... y nada más que la verdad
Veamos los hechos desnudos: un buen día, la compañía antes conocida como Inprise decide que su negocio de compiladores es una ruina. Segrega la compañía (igual que las babosas segregan un moquillo adherente), bautiza CodeGear al retoño, y anuncia que tiene un montón de novios. Pero la petición de mano se demora infinitamente y toda la villa comienza a sospechar que se trataba de un farol. Tras varias peripecias, aparece el Príncipe Azul, un tal Embarcadero, cabalgando radiante sobre su moto acuática, y carga con la solterona (¿le habrán pagado para que se la llevase de una puñetera vez?).
Uno esperaría que, tras tan accidentado romance, la parejita se pusiese a fabricar pequeños ogros, como Fiona y Shrek, pero... es que Fiona ya aportaba al enlace dos monstruitos: Delphi para Win32 y Delphi.NET. Ah, sí, y esa abominación de "Delphi para PHP" y otros engendros que mejor dejo sin clasificar. Bueno, menos trabajo para el ogro, ¿o no?
Entonces, la comedia se transforma en drama: Shrek tira Delphi.NET por la ventana y toma en adopción el brillante hijo de un vecino, llamado Oxygen, aka Chrome. ¿Sabía Shrek lo que iba a hacer con su vástago desde el primer momento? ¿Se convenció a su pesar de que Delphi.NET no tenía arreglo? A todas estas, los representantes de Fiona parecen haberse puesto de acuerdo en mostrar su mejor sonrisa a los medios. Pero uno imagina que la procesión debe ir por dentro...
El bien o el mal
No me entienda mal: Oxygen es un producto que me gusta y que recomiendo sin reservas. De hecho, en cierta manera lo considero un familiar cercano. Freya ha copiado impúdicamente algunas ideas de Oxygen/Chrome, como la palabra clave method o los niveles de visibilidad. Muchas características comunes son fruto de una evolución paralela: es un indicio de que ambos proyectos arribaron a los conclusiones lógicas en esos puntos. A la vez, me empeño en creer voluntariosamente que puede que alguna característica de Freya se haya podido filtrar a Oxygen/Chrome.
¿Es el párrafo anterior una recomendación de compra de Delphi Prism? ¡Más despacio, por favor! Si usted odia orgánicamente las llaves, le recomendaría que comprase Oxygen. Delphi Prism es Oxygen más toda la morralla de "compatibilidad" con los obsoletos módulos heredados de CodeGear. ¿Alguien en sus cabales se atreve a programar con dbExpress.NET... cuando dbExpress nativo terminó siendo un fracaso sonado? Si va a programar con Oxygen, mi recomendación es que utilice ADO.NET, o los productos de acceso a datos de RemObjects. Cualquier otra decisión, significaría empantanarse por puro capricho.
En cualquier caso, Embarcadero tiene un bonito problema: Delphi Prism y Delphi for Win32 son dos lenguajes muy diferentes. ¿Tendrá secuela este peliculón?
Ian Marteens, 9:50 a. m.
47 Comments:
Pues si no es para poder usar la VCL y dbExpress y similares y portar aplicaciones Win32 a .NET, no se me ocurre ninguna razón para usar Delphi Prism. No vas a liarte a usar un producto minoritario y sin muchas garantías de continuidad solo por que no te gusta abrir y cerrar llaves.
Yo creo que en ADO.NET lo único aprovechable son los SqlCommand y los DataReader. Con Delphi todavía se pueden desarrollar aplicaciones de bases de datos mucho más rápido a no ser que te lo curres un montón con el Visual Studio y te montes un tinglado para no usar los DataSets de ADO.NET
Eso sí, hay muchos que cuando se ponen a inventar algo para sustituir una rueda cuadrada (ADO.NET) inventan una rueda triangular (ORM).
Pues menos razón todavía para cambiar de carreta.
De todos modos, ¿a que es de risa que a estas alturas hayan descubierto que el compilador de Delphi.NET no tira?
Ya, ya. Pero conozco a gente que está contenta con la salida de Prism por que lo ven como una oportunidad para pasarse a .NET reaprovechando cientos de miles de líneas de código. A ver si es verdad.
El viejo Delphi.NET era demasiado malo, o eso tengo entendido.
Pero para proyectos nuevos no le veo sentido a no ser que sea para crear aplicaciones de bases de datos en 2 capas a toda leche usando los DataSets de Delphi.
En mi empresa hemos desarrollado una chapuzaplicación en 2 capas en Delphi de más de 200 tablas en muy pocos días (con un prototipo funcional en 1 día), y aunque sea bastante lenta y siempre lo será, con ADO.NET hubiese sido imposible cumplir el plazo. Y no digamos ya con un ORM :-)
Le he estado echando un vistazo a lo del Delphi Prism y parece que lo de la migración de código desde Delphi para Win32 aun está un poco verde :-(
A donde vamos a ir a parar con tanta cosa.
La verdad hace 10 años, recuerdo que muchas cosas de VS.NET de hoy Borland ya las tenía, todavía recuerdo lo divertido que era crearse algo CORBA, los Formularios de datos, el IntelliSense, etc etc, una gama inigualable de productos. De pronto algo pasó y Borland murió. La mala suerte es que no podemos ver actualmente nada más que VS.NET, hay que decir y está muy bien, pero que mundo maravilloso sería que Borland u otra exisitiera que les hiciera esa competencia de años atrás, se imaginan las tools que tendríamos en estos momentos. La cosa .NET está casi que monopilizada por MS, y no hay quien los haga mejorar. Sin desmeritar su gran esfuerzo y avances que hay unos excelentes. Tú mismo Ian nos diste unos tips del famoso Entity Framework, que al parecer va bastante deficiente con lo prometido, que tal la Borland ficticia actual, haciendo el suyo y presionando al gigante azul.
Saludos
Efectivamente, Andrés, es una verdadera lástima que MS no tenga competencia, sobre todo en lo que respecta a la increible comunidad que Delphi logro crear en su derredor, con miles de componentes para hacer casi cualquier cosa y que Microsoft no ha conseguido ni siquiera emplazar IMHO.
Delphi lleva muerto desde hace 5 o 6 años (desde la salida del infame Delphi 8, o como narices le llamasen al que salió despues del 7). Muerto o mejor dicho, "en estado vegetativo y con respiración asistida", un enfermo terminal que contrajo un terrible mal, llamado desidia. Lo más lamentable del asunto, las incomprensibles posturas de algunos pocos "irreductibles" (aunque no galos) como el tal DrBob, quien se ha empecinado en mantener con vida al agonizante despojo, en lugar de ayudar a procurarle una eutanasia digna... y unos funerales con honores de Estado. Que es lo mínimo que Delphi merecía, en mi opinión. Sin embargo ahora ya sólo le queda la amarga muerte del que se sabe solo, porque sus seres queridos (nosotros, los desarrolladores) se han (nos hemos) hartado de tanto sufrimiento y tanta agonía. Porque por duro que sea a veces, "the show must go on".
Quizá me ha quedado un tanto siniestro, podria ser un "requiem" en toda regla, pero es lo que hay. Desde el momento en que supe, por Ian, de la existencia de Chrome (actual Oxygene), supe que Delphi ya no tenia nada que hacer. De no haberme ya iniciado en C# y haber estado, en ese momento, buscando un "equivalente rápido" de Delphi para .NET, no hubiera tenido la menor duda: Chrome.
Saludos
Pablo, no creo que fuese por desidia si no por incapacidad para competir.
Delphi ya estaba condenado desde que salió .NET igual que Turbo Pascal estaba condenado desde que salió Windows 3.
El problema es que esta vez Borland no ha sido capaz de seguir en la brecha con un nuevo producto competitivo.
Y no es por que no fuese posible.
Triste lo de Delphi. En su día programé con varias versiones, hasta llegar a la 7. Delphi y CBuilder me parecían excelentes productos en su momento.
A partir de ahí vinieron los engendros y el desencanto. Un Delphi.NET que nunca evolucionó, un Kylix que prometía programación multiplataforma (curiosamente, igual que promete Prism) y que desapareció misteriosamente... JBuilder, del cual mejor ni hablamos.
Me fastidia ese "baúl de los recuerdos" de Borland. Ese intento de llamar "Delphi" a cosas que nada tienen que ver con Delphi (php, por ejemplo) o Turbo a otros productos, como recuerdo de glorias pasadas. Cada vez que veo algo que empieza por Delphi, últimamente tengo la extraña sensación de que me quieren engañar...
Lo siento por Borland, sus merecidos tiempos de gloria parecen haber pasado.
Andrés: que tal la Borland ficticia actual, haciendo el suyo y presionando al gigante azul.
Bueno, ahora la competencia puede ir por otros rumbos. Es probable que tenga que empezar un proyecto con Hibernate para .NET (exigencias del guión). No es lo mismo, por supuesto, que tener a toda una compañía ofreciendo una alternativa de desarrollo completa (herramientas + compilador + infraestructura), pero no creo que se vaya a estancar la Informática por ello.
Abrasax: la increible comunidad que Delphi logro crear en su derredor
La verdad es que uno tiene la impresión de que la calidad de los componentes para .NET es menor. A pesar de que el IDE de Delphi "clásico" estaba malísimamente documentado, al final podía uno integrar mejor sus propios productos en tiempo de diseño. Por contra, VS tiene mejor documentada sus extensiones, pero la mayoría de los componentes que conozco no tienen el mismo "brillo" que los equivalentes antiguos. Y puede que se deba, quizás, a eso que mencionas: la comunidad, la calidad profesional de la gente que se involucró.
Pablo: pocos "irreductibles" (aunque no galos) como el tal DrBob
La verdad es que, sentimentalmente hablando, me cuesta pasar página. Pero es también cierto que Borland/CodeGear también se esforzó en alejar clientes. ¿Cómo se llamaba aquel "relaciones públicas" que trataba a la gente como si fuese un perro guardián? A la más mínima queja de que algo no te funcionaba... ladrido y bocado.
Juan: un Kylix que prometía programación multiplataforma (curiosamente, igual que promete Prism
Pero ahí mismo tienes la diferencia: Prism tendrá debajo, en Linux y Windows, una misma plataforma de infraestructura. Y con Kylix, lo que falló precisamente fue la infraestructura para Linux. ¿Quién se acuerda de los follones que daban los Variant en Delphi 6 y Delphi 7?
El problema es que esta vez Borland no ha sido capaz de seguir en la brecha con un nuevo producto competitivo.
Y no es por que no fuese posible.
La verdad es que es más difícil ahora. Delphi 1 entusiasmó porque te evitaba programar con el API de Windows o el MFC ofreciendo la VCL. Delphi 3, tres cuartos de lo mismo, porque te permitía programar para COM con mucha más facilidad de lo que te permitían el API de COM y la ATL.
Es decir, había siempre un API de Microsoft con la funcionalidad necesaria, pero con una interfaz de programación pésima. Y con Hejlsberg retocando el lenguaje a la medida, era más fácil crear esas clases en Delphi que, digamos, en el mismísimo C++, a pesar de ser más potente. Recordad el modificador message contra el sistema de macros para mensajes. Y todas las adiciones al lenguaje para soportar COM adecuadamente.
Al aparecer .NET, ese hueco dejó de existir. Y Hejlsberg está haciendo en Microsoft exactamente lo mismo que hacía en Borland: en cada nueva versión, el lenguaje trae "algo" para simplificar la programación en "algo". En C# 4.0 va a ser lo de la interfaz con "lenguajes dinámicos". En la v3.0, fue el LINQ.
Creo también que a Borland la afectó mucho el cambio generacional. En su momento, se quedaron con unas pocas viejas glorias y un montón de jóvenes promesas, y lo malo es que las viejas glorias no parece que hayan sido muy pedagógicas: falló el pase del bastón.
La verdad es que es más difícil ahora.
Cada vez es más difícil todo :-)
Al aparecer .NET, ese hueco dejó de existir.
Ese sí, pero aun quedan montones.
Y Hejlsberg está haciendo en Microsoft exactamente lo mismo que hacía en Borland: en cada nueva versión, el lenguaje trae "algo" para simplificar la programación en "algo".
Y está demostrando sus limitaciones en el campo del diseño de lenguajes de programación. Lo que ha hecho desde que llegó a Microsoft es coger cosas de aquí y de allá y mezclarlas sin mucho criterio.
Así lo explica el mismo:
let's take C#, let's try and take SQL, let's try and take XML or XQuery and let's all sort of put them into one big bowl and stir and see what comes out of it
Linkito
y lo malo es que las viejas glorias no parece que hayan sido muy pedagógicas: falló el pase del bastón.
Y que las jóvenes promesas no han sido capaces de superar a las viejas gloras. Eso siempre es un gran fracaso.
@Alfredo:
"Pablo, no creo que fuese por desidia si no por incapacidad para competir."
Incapacidad, puede. Pero yo creo que sobretodo fue desidia. En Borland/Inprise se les iluminaron los ojillos cuando vieron la posibilidad de cobrar 4 o 5 veces más por un producto, encima destinándolo a gente que no tenia NPI de desarrollo (y por tanto no podía 'chistarle' la calidad de sus productos). Lo que se da en llamar ALM, vamos.
Si fuese el título de un libro, bien podria ser: "Cómo cobrarle a un directivo diez veces el precio de un lenguaje de programación por darle un Paint 'tuneado' para que CREA que sabe programar" (Lo del Paint tuneado me imagino que sabeis por donde va. Sí, los diagramitas UML).
Lo gracioso es que en Microsoft ahora parece que quieren tirar por los mismos derroteros.
"Delphi ya estaba condenado desde que salió .NET igual que Turbo Pascal estaba condenado desde que salió Windows 3."
Hmmm... No sé si sabes que Delphi 1.0, era internamente Turbo Pascal 8. Lo puedes ver en el .exe ;-) Así que condenado, creo que de eso nada. Eligieron cambiarle el nombre al producto, como podrian haber optado por conservarlo.
"(Hejlsberg) está demostrando sus limitaciones en el campo del diseño de lenguajes de programación."
Ah, faltaba el sutil dardo envenenado del sr. Novoa... xD
Yo desde luego... no se tú, pero mi nivel de conocimientos desde luego no me permite marcarme la 'sobrada' que has soltado. No tengo "lo que hay que tener" para poner en tela de juicio la capacidad de uno de los considerados "Monstruos" a nivel mundial, en precisamente ese terreno, el del diseño de lenguajes y compiladores. Pero bueno, me imagino que debes tener fundadas razones para poder decirlo, aunque también creo que la frase que quoteas la estás cogiendo un poco 'con pinzas'.
Sin acritud eh.
Yo desde luego... no se tú, pero mi nivel de conocimientos desde luego no me permite marcarme la 'sobrada' que has soltado.
No te preocupes, el mio sí ;-) :-)
No tengo "lo que hay que tener" para poner en tela de juicio la capacidad de uno de los considerados "Monstruos" a nivel mundial, en precisamente ese terreno, el del diseño de lenguajes y compiladores.
Lo que pasa es que solo los no iniciados lo consideran así. Entre la gente que se dedica a eso en serio no creo que le conozcan. Hablando sobre C# 3.0 con gente que si que sabe del tema comentaban que está claro que sus diseñadores aunque seguramente sean buenos desarrolladores no saben de diseño de lenguajes de programación.
aunque también creo que la frase que quoteas la estás cogiendo un poco 'con pinzas'.
No, la he cogido con copiar y pegar. :-)
Pero antes de leer eso ya me imaginaba que el proceso de diseño tenía que haber sido algo parecido.
Lo que ha hecho desde que llegó a Microsoft es coger cosas de aquí y de allá y mezclarlas sin mucho criterio
Hombre, hay cosas en C# que están mal diseñadas. Por mencionar las que recuerdo, así de pronto:
1- El mecanismo de las propiedades automáticas. La idea en sí es buena, pero hubiese sido mejor implementarlas como los "eventos automáticos", en vez de depender de los niveles de accesibilidad de los métodos de acceso para crear propiedades de sólo lectura. Consecuencia: no hay forma de preinicializar (en la declaración) una propiedad automática.
2- Es discutible si no tendrían que existir parámetros pasados por nombre y valores por omisión desde la primera versión.
3- No me gusta que todos los indizadores necesariamente sean anónimos.
4- Sigo sin convencerme de la necesidad de los puñeteros métodos anónimos.
Pero hay errores que no se deben al diseño del lenguaje, sino al ritmo de desarrollo. Por ejemplo:
1- Yo hubiese unificado el sistema de tipos como en Freya, haciendo que los arrays fuesen un tipo genérico (también como en Eiffel). Pero eso hubiese significado esperar hasta 2005 para tener la primera versión.
2- El mismo problema de que ahora se introduzcan los valores por omisión en parámetros por presión para unificar el lenguaje con VB.NET.
3- La sintaxis de métodos anónimos en C# 2.0 se vuelve obsoleta con C# 3.0... pero hay que reconocer que para algunos casos es mejor la primera sintaxis.
Y hay otros "defectos" que son opinables:
1- Se puede opinar si el conjunto de características implementadas en LINQ son las correctas o no. Yo, perfectamente, me hubiese quedado con la idea de LINQ como biblioteca de clases, sin el pseudo SQL. De hecho, cuando uso LINQ casi siempre utilizo la sintaxis basada en métodos.
Pero volvemos a lo mismo: es mejor tener un lenguaje práctico aunque imperfecto en el 2002 que no esperar a por las uvas en el 2010.
Yo me refiero sobre todo a C# 3 y 4. El 1 era Java con un par de retoques, y Java nunca fue un lenguaje avanzado para su tiempo.
No tiene funciones genéricas como Common Lisp ni herencia múltiple, el modelo de herencia tiene muchas inconsistencias y el sistema de tipos no es seguro.
El 2 era el 1 con genéricos y poco más y fue un buen paso.
Pero el 3 es un pastiche y una chapuza de la leche.
Por poner un ejemplo de los más graciosos si haces esto:
if (new { x = 1, y = 2 } == new { y = 1, x = 2 }) ...
El compilador dice esto:
Error 2 Operator '==' cannot be applied to operands of type 'AnonymousType#1' and 'AnonymousType#2'
Ridículo X-D.
Y no puedes pasar este tipo de "objetos" como parámetro ni devolverlos en funciones, el orden de los componentes hace incompatibles los tipos, etc.
Las conversiones automáticas de tipos no funcionan cuando usas tipos anónimos:
var a = new { x = 1.0, y = 0 };
a = new { x = 1, y = 0 };
No funciona.
Y montones y montones de fallos de principiante más.
SQL fue un lenguaje diseñado en 1976 por gente que nunca había diseñado un lenguaje antes y además experimentaron cosas en él que no salieron bien. Y van y lo toman como modelo para LINQ.
LINQ tiene fallos garrafales por no entender de bases de datos.
Las actualizaciones son orientadas a registros, cosa que ya es más que suficiente para ponerles las orejas de burro y mandarlos a la esquina.
Antes de poder hacer una proyección o una junta o cualquier operación que devuelve una expresión con un tipo no "mapeado" antes te obliga a crear una clase.
Te obliga a asociar clases (que son tipos) a tablas (que son variables). Es decir que te obliga a asociar tipos y variables, lo cual es una barbaridad de campeonato.
LINQ to Objects no tiene ninguna optimización algebraica ni de reescritura de expresiones y además está diseñado de tal forma que no la va a poder tener. Esto lo convierte en algo prácticamente inútil.
Con LINQ to Entities se hacen la picha un lío de mala manera con extrañísimas ideas sobre lo que es el Modelo Entidad/Relación. Se montan un tinglado para al final guardar en un archivo XML condiciones predeterminadas para los "join" cuando hay publicadas formas muchísimo más elegantes de simplificar las consultas.
Si LINQ lo hubiese diseñado una persona con un mínimo de conocimientos entonces podríamos usar las tablas de la base de datos como si fuesen ciudadanos de primera clase indistinguibles del resto de las variables del programa. Sin tener que hacer ningún "mapeado" entre tipos y variables.
Y así me podría tirar todo el día.
Vale que C# 1 y 2 puedan ser lenguajes prácticos implementados en poco tiempo, pero de trabajo brillante e innovador nada de nada. Son lenguajes mediocres y por detrás de su tiempo. Y en el caso del 3 no les hubiese costado más trabajo hacer las cosas bien.
LINQ to Entities ...
LINQ to Objects...
Eso son bibliotecas, y ni siquiera de las "básicas", de soporte del lenguaje (como podría serlo IDisposable, o IEnumerable).
Sobre la optimización "algebraica": precisamente, en la 3.1, las consultas select/where (no triviales) tienen una implementación especial para evitar el pipelining. El problema es que muchas de estas optimizaciones se realizan (mejor) en el JIT compiler.
No son solo bibliotecas. Una biblioteca no modifica la sintaxis. Para poder crear LINQ también le han añadido al lenguaje chapuzas tremendas como los tipos anónimos. Y eso de entremezclar sintaxis con bibliotecas es otra buena chapuza.
Pero sí, uno de los errores más grandes de LINQ es no haber integrado realmente las tablas y los operadores de las bases de datos en las aplicaciones y haberse quedado a medio camino.
Un LINQ bien hecho hubiese sido el avance más importante en muchos años pero lo que han hecho es inferior en muchos aspectos al viejo SQL incrustado.
La optimización algebraica va mucho más allá de eso que dices y son optimizaciones de alto nivel que se hacen mucho antes de llegar al compilador JIT. Además para hacerlo bien la reescritura de las expresiones debería de depender de los datos contenidos en las colecciones en cada momento.
Si estuviese bien hecho una consulta con LINQ to Objects debería de ser más rápida que una consulta procedimental escrita con prisas por un programador medio en lugar de ser casi un orden de magnitud más lenta.
Y me olvidaba de mencionar los métodos de extensión que son un pobre sucedaneo de las funciones genéricas a la Common Lisp.
Una biblioteca no modifica la sintaxis
Es que LINQ for SQL, por poner un ejemplo, no modifica la sintaxis. LINQ sí, por supuesto, pero si estamos hablando (en parte) de las chapuzas de los ORMs, éstas no tienen que ver con el lenguaje, sino que parecen más "apropiadas" una vez que existe un lenguaje de consultas.
De hecho, y esto es tan peligroso como cualquier juicio de intenciones, mi impresión es que Hejlsberg se opuso cuanto pudo (que no fue poco) a los ORMs: Inappropriate Abstractions.
Entonces estamos de acuerdo en que todas las cosas que estoy comentando si forman parte de C#.
Y además LINQ admite unas cosas u otras dependiendo de si estás usando una librería LINQ to XML o LINQ to SQL u otra.
Hasta la sintaxis cambia. Por lo que tengo entendido si usas LINQ to SQL para hacer un "join" tienes que usar el método join, pero si usas LINQ to Entities puedes hacer un "join" usando un punto y metiendo la condición en un horrible archivo XML.
Las chapuzas de los ORM si tienen que ver con el lenguaje por que si tuviesemos equivalentes directos de las estructuras de las bases de datos en los lenguajes de programación de aplicaciones no haría falta complicarse la vida ni se tendría oportunidad de meter la pata con "abstracciones inapropiadas".
Imagínate que en el archivo de proyecto asocio una aplicación a una base de datos y en el código de la aplicación escribo:
delete Clientes where [Código Postal] = codigoPostalTextBox.Text;
Y que el compilador se encargue de comprobarlo todo. La variable de tipo tabla de la aplicación sería una abstracción apropiada de la tabla Clientes de la base de datos. Sin miles de lineas de XML ni gaitas.
Y por lo que veo en C# y leo en los artículos, me parece que Hejlsberg no lo acaba de pillar.
Y que el compilador se encargue de comprobarlo todo.
Hablando con propiedad, eso existe desde hace milenios: se llama Embedded SQL y tiene una variante modular, llamada (cómo no) Modular SQL. As a matter of fact, mi tesis de graduación fue un sistema SQL completo con engine, intérprete y compilador de Modular SQL (y otras personas implementaron la variante "embedded" para Pascal). :) Pero no recuerdo que nos sintiéramos muy a gusto programando con aquel sistema (a pesar de que era eficiente y potente). Y no, no tenía que ver con la existencia de un compilador adicional (con strong-type checking).
Claro que existe desde hace milenios, a eso me refería con lo del SQL incrustado.
Estos supuestos "genios" lo único que han hecho es reinventar un SQL empotrado mucho peor. Y eso que SQL es el peor lenguaje relacional que ha habido.
No se por que no os sentiríais muy a gusto, pero eso es mucho mejor que lo que tenemos ahora en .NET y Java.
Una vez el director de una consultora importante me dijo que mucho cuento con Java y todo eso pero que la productividad del SQL incrustado no la habían igualado con nada, y evidentemente hablaba de ganar dinero y sabía lo que decía (aunque no el porqué).
Es una pena que las modas también se lleven por delante las buenas ideas.
Lo que habría que hacer es crear un "SQL incrustado" que en lugar de ser SQL fuese un lenguaje bien diseñado con tipos definibles por el usuario, herencia, encapsulación, polimorfismo y todo eso.
Ese es el camino evidente para solucionar el "impedance mismatch" ese, como llevan diciendo décadas los expertos en bases de datos.
Clase = Dominio de la base de datos pero bien hecho.
Me vais a perdonar, pero después de leerme 22 comentarios como estos me voy a permitir el "lujo" de preguntar: ¿Que coño haceis haciendo lo que quiera que hagais teniendo los conocimientos para crear lo que nadie es capaz? Descolgar ahora mismo el telefono tanto Alfredo como Ian y llamar a M$ y explicarles las verdades que no ven.
Esperad, mejor aún... creo que tengo el movil de Hejlsberg por aquí en algún sitio...un momento que lo busco...
Jejeje :)
P.D. Es sólo coña :)
Rox, hay miles de personas que se saben bien estas cosas y que sabrían hacer muchas cosas mejor que los "genios" de Microsoft que están al mando.
El caso es que nunca ha habido mucha relación entre los conocimientos que se tienen y el puesto que se ocupa.
Es más, cuando los negados mandan y son mayoría, el hacer las cosas bien hace que tengas muchas probabilidades de no prosperar mucho.
Yo conozco a gente que se sabe todas estas cosas muy bien y que trabajaron para empresas como Microsoft e IBM y que dicen que no hay nada que hacer y que se hartaron de intentarlo.
Google es otra cosa. El director de investigación Peter Norvig si que es un científico de los de verdad y uno de los mayores expertos mundiales en inteligencia artificial. Seguro que veremos cosas interesantes en ese campo en el futuro. Pero lamentablemente no parecen interesados en el campo de los lenguajes de programación y las bases de datos.
Como puedo ver por tu respuesta, has entendido que sólo era un comentario gracioso por todo lo que habíais estado discutiendo. Yo no llego a vuetro nivel de conocimientos ni juntando 3 vidas :) Pero me resultaba gracioso como iba desarrollandose el dialogo.
Entiendo también que al final todo esto es un negocio y que lo ideal no es siempre lo mejor, es decir, si todo funcionara bien y eternamente, cerraban la mitad de las empreas. Pero claro si nos ponemos a filosofar sobre programación y nos damos cuenta que estaba mejor hecho (con todas sus carencias y errores) lo de hace 20 años que lo de ahora, pues...
Lo de Google si que te doy la razón, es de las pocas empresas (otra es Apple en su campo) en el mundo de la informática que ha conseguido sorprendernos, mejorar, inventar algo.
Soy un apasionado defensor de lo maravilloso que me parece el concepto de Google Earth por poner un ejemplo. Sólo le faltaría estar en tiempo real, eso si que sería la leche.
Y claro para que se van a meter en el mundo de los lenguajes y bases de datos si ellos lo que quieren es inventar utilidades/servicios, no crear las herramientas con las que crear utilidades.
P.D. Y en esta tesitura de lenguajes por lo que comenzó este dialogo, yo un "cuasi-profano" en la materia, hecho la vista atrás y pienso en los que he conocido:
Crecí chupeteando TurboPascal, Cobol y QBasic, probé C/C++, incluso ojee VisualC++, me enamoré de Delphi, utilicé SQL para dominar a las bestias, miré de reojo a VB y Java, he tonteado con C# y me moriré pensando que amaba el Ensamblador... jeje :D
Osea que vosotros no me quiero ni imaginar lo que buye por vuestras cabezas... :)
Hay muchos de nosotros que aunque no llegamos a alcanzar el nivel de estos temas como lo hacen Ian y Alfredo padecemos de desarrollar aplicaciones con los males que los lenguajes de programación cargan y nos hacen pensar que si habra una mejor forma de hacer las cosas y con mas facilidad, estos temas asi me motivan a seguir programando sabiendo que hay personas como Ian y Alfredo que tienen bien claro los defectos de estos lenguajes y como se puede dar solución.
En mi país lo que uno encuentra es personas que se creen que lo saben todo y su nivel es inalcanzable por otros pero cuando uno ve el código que ellos desarrollan se ve que son chapuzas que hay que estar dandole mantenimiento diario por que no se puede dejar solo ni un minuto en miles y miles y miles ...
de lineas de codigo que hace frustante su mantenimiento. Y lo malo es que las personas que lo contrataron para hacer la aplicación creen que se le puede dar termino a una chapuza tan grande por que despues de haber gastado una gran cantidad de dinero decirle que seria mejor empezar de nuevo es mentarle su madre, y si fuera una aplicación pequeña uno talvez empesaria sin decirle nada a los dueños pero cuando se trata un sistema que abarca demasiadas cosas uno esta entre la espada y la pared.
Otro mal que es dificil curar en mi país es que los empresarios los que conocen lo que es un sistema se hacen que no saben para ofrecerle a uno lo menos que se pueda y los que no conocen es peor.
También me llevo de aquella frace que dice "Medir el progreso de una aplicación por la cantidad de lineas de código es como medir un avión por su peso"
@Junior:
"En mi país lo que uno encuentra es personas que se creen que lo saben todo y su nivel es inalcanzable (...) el código que ellos desarrollan se ve que son chapuzas (...) Y lo malo es que las personas que lo contrataron para hacer la aplicación creen que se le puede dar termino a una chapuza tan grande por que despues de haber gastado una gran cantidad de dinero decirle que seria mejor empezar de nuevo es mentarle su madre..."
Si fuera sólo en tu país... ;-)
En cuanto a lo que dice Rox, yo ya hace tiempo le comenté a Alfredo que qué hacía que no estaba de Mega Boss Product Manager Del Copón en Oracle (por nombrar a alguna), o en la misma MS. La frase de Alfredo "nunca ha habido mucha relación entre los conocimientos que se tienen y el puesto que se ocupa" pues es una verdad como un puño (véase la frase de Junior)... sin embargo a mí no me entra en la cabeza que para un puesto de altísima responsabilidad como el de Ingeniero Jefe de la Division de Herramientas de Desarrollo (sigamos poniendo como ejemplo a MS), tengan tres candidatos: Uno bueno, otro mediocre y otro malo, y el jefe diga "OK, cojamos al mediocre, no nos interesa hacer las cosas bien". Lo siento, pero no.
sin embargo a mí no me entra en la cabeza que para un puesto de altísima responsabilidad como el de Ingeniero Jefe de la Division de Herramientas de Desarrollo (sigamos poniendo como ejemplo a MS), tengan tres candidatos: Uno bueno, otro mediocre y otro malo, y el jefe diga "OK, cojamos al mediocre, no nos interesa hacer las cosas bien".
Eso sería posible si la gente llevase escrito en la frente si uno es bueno mediocre o malo. Pero la realidad es que cuando un jefe no técnico tiene que elegir a un jefe técnico normalmente no tiene la más remota idea de quien es bueno o malo y entonces elige basándose en factores superficiales como la popularidad.
Una pregunta muy sencilla:
- ¿Conocéis algún proyecto que haya fracasado sólo por tener un jefe incompetente?
Una subpregunta:
- ¿Conocéis algún proyecto que haya triunfado a pesar de que todos sus programadores fuesen incompetentes?
Mi respuesta a ambas es que no. Un jefe incompetente puede ser neutralizado por un buen equipo de programadores. A un mal equipo de programadores no lo arregla ni Alan Turing... a no ser que el jefe se ponga a programar. Si a esto le sumamos el principio de Peter, os podéis imaginar lo demás.
Respecto al problema del técnico brillante en una empresa, hay dos factores importantes:
1- El más frecuente, es que en sociedades como la española, son tan importantes las relaciones de poder como el obtener resultados.
(puedo escribir mucho sobre las manifestaciones de lo anterior)
2- Existe un fenómeno que yo llamo "efecto horizonte". El uso que le doy viene de la Inteligencia Artificial: a un sistema capaz de explorar N niveles en el árbol de búsqueda, le cuesta "entender" las jugadas de un sistema que explora N + M. En la vida real ocurre que es muy difícil demostrar cuando alguien realmente sabe o no. Es más fácil entre gente de la misma profesión, o que al menos conoce el contenido de la profesión. Yo no soy físico, pero sé que las "gauge theories" son complicadas, por ejemplo. Pero con nuestra cultura, en la que los jefes intentan no mojarse técnicamente, sino sólo "funcionalmente", es muy fácil que se la cuelen.
Es precisamente lo que ocurrió en la "empresa imaginaria" de mis últimos posts: de repente te encuentras luchando por demostrar lo evidente, porque un señor "funcional" (teóricamente, que esa es otra) se niega a reconocer que le han estado dando pomada durante cinco largos años.
Por cierto, Alfredo: Google será una maravilla, sobre todo en lo que tiene que ver con su buscador. Pero el resto de la tecnología de ellos que he tocado da pena. Mi propio blog acaba de rechazar un comentario mío (el anterior)... probablemente por un timeout, entre el momento en que empecé a escribirlo hasta el momento en que terminé. Aquí no hay verificación por palabras, porque cuando la hay, se produce el doble de errores de ese tipo. Y la lista de bugs que tiene el puñetero blogger es enorme.
Volviendo por un momento al tema inicial, a mi mas que desaparezca Delphi.NET de la vista sustituido por Prisma, lo que me fastidia es que al final para .NET van a tener un plugin para Visual Studio y, sin embargo, para programar para Win32 tendremos que seguir soportando un IDE escrito en .NET, lento y pesado, porque tenía que ser el mismo IDE para todos los "sabores".
Pero es que no sólo se trata del IDE, sino del propio lenguaje...
Tal vez me esté comportando demasiado radicalmente en este tema, pero mi opinión es que un Delphi, o una variante de Delphi, para .NET no tiene sentido alguno. ¿Cuál lenguaje, de los que conocéis soporta simultáneamente código nativo y .NET? Sólo conozco Visual C++... y la verdad es que es un castigo programar con Visual C++. Ah, y que nadie me diga que, precisamente, Delphi.NET, porque la versión de Borland ha sido un fracaso (por eso la abandonan ahora) y la versión de RemObjects no es, hablando con propiedad, Delphi (y no tiene un compilador nativo).
El mundo nativo y el mundo .NET son tan diferentes que un lenguaje que permita programar para los dos lo tiene muy crudo. Es por ese motivo que Freya, casi desde el primer momento, se alejó de Delphi todo cuanto me pareció razonable (teniendo en cuenta los intereses del diseño del lenguaje).
Otro tema relacionado: ¿tiene sentido desarrollar un compilador nativo para una variante viable de Delphi para .NET, como Oxygene o Freya? Mi opinión es que tampoco. Por ejemplo, la idea del garbage collection permea todo el diseño de estos lenguajes. Lo primero es que el compilador nativo tendría que dar soporte al garbage collection. Y a toda una serie de subsistemas similares. Por lo tanto, terminaría ejecutándose sobre un runtime... ¡que sería un clon de .NET! Hombre, pues para eso ya está Mono, digo yo.
Ese fue el error inicial de Borland. Lo del IDE, a pesar de su gravedad (pues significa lo que significa), es secundario.
"la idea del garbage collection permea todo el diseño de estos lenguajes. Lo primero es que el compilador nativo tendría que dar soporte al garbage collection."
Hmmm... igual es que yo veo las cosas demasiado sencillas, pero ¿no se podria dejar el uso de los conocidos métodos Free, FreeAndNil etc, para la versión Win32 del lenguaje, e implementar el uso de IDisposable (por ejemplo) solo para .NET? Y posibilitar el que el compilador utilice unas u otras en función de una metasentencia ... o qué narices, en función de la plataforma para la cual vamos a compilar? Y allí donde no corresponda, pues error de compilación que te crió.
Insisto: que igual estoy diciendo una barabaridad eh... :-P
:) Barbaridades decimos todos. Esta parte de la informática es una ingeniería, no una ciencia, y hay mucho margen para la subjetividad...
Free, FreeAndNil
Es posible, con mucha disciplina (aunque me temo que las diferencias semánticas reaparezcan en algún momento). Supón que lo has resuelto... a costa de añadir un par de métodos (Free/FreeAndNil) a una biblioteca de clases con la que siempre tienes que cargar o modificando el compilador para que realice "compiler magic" (anular esas llamadas en .NET, p.e.). De todos modos, tienes las diferencias en el resto de las clases, como que la raíz cuadrada en un sitio es Math.Sqrt y en el otro Sqrt a secas. O la entrada y salida. O la existencia de funciones "globales": no hay que perder de vista que Delphi es un lenguaje híbrido.
En cualquier caso, habría que rediseñar la biblioteca de clases de Delphi nativo. Y lo más importante de esa decisión: good bye, compatibilidad con el pasado.
. Esta parte de la informática es una ingeniería, no una ciencia,
Ojalá fuese una ingeniería, es más bien un oficio artesanal.
Si tu le das un diseño de un puente a 100 ingenieros y les preguntas si tiene la resistencia suficiente todos te responderán lo mismo.
Si le preguntas cualquier cosa sobre el diseño de un sistema a 100 "ingenieros de software" lo más normal es que obtengas 100 respuestas diferentes seguidas de una batalla campal.
Yo creo que Win32 es una plataforma en vías de extinción y no tiene sentido invertir mucho en ella.
Además Mono se está convirtiendo en una opción seria para ejecutar aplicaciones desarrolladas con Visual Studio. Sobre todo en servidores.
Por otra parte aunque la recolección de basura sea muy cómoda para la mayoría de las aplicaciones hay veces que causa más problemas de los que resuelve como por ejemplo si necesitas crear sistemas en tiempo real.
No se si conocereis alguna salida para estos casos además de forzar la recolección de basura continuamente.
@Ian:
"tienes las diferencias en el resto de las clases, como que la raíz cuadrada en un sitio es Math.Sqrt y en el otro Sqrt a secas. O la entrada y salida. O la existencia de funciones "globales"".
Bueno pero es que entonces volvemos a un antiguo debate que yo ya tuve hace tiempo: ¿Delphi es Object Pascal? ¿o Delphi es Object Pascal + la BCL? De la respuesta depende, evidentemente, que consideremos más o menos "portable" un lenguaje. Las funciones "globales" son las que lleva incorporadas "de serie" el lenguaje (y viene a mi cabeza el vetusto BASIC, con sus Rnd(), Sin(), Read()...) por lo tanto y a mi seguramente corto entender, tienen la misma categoria que los comandos propiamente dichos, ya que forman parte indivisible del propio lenguaje, y por tanto candidatas a ser "portables" (o cross-platform, como se prefiera).
Lo mismo podriamos decir a la inversa: ¿consideramos a C# sólo C#, o sería C# = C# + el CTS + la BCL de .NET?, pues en este caso está claro leyendo la especificacion, que C# es potencialmente "poco portable" a Win32 porque son poquisimas palabras reservadas y donde está la verdadera fuerza (al igual que en el caso de Delphi) es en la inmensa libreria de clases (y tipos!) que apoyan el lenguaje... Libreria que obviamente no te vas a poner a portar (aunque lo de utilizar Mono en esa hipotética tarea, es una magnífica idea).
Alfredo lo de la recolección de basura en tiempo real... me parece, y si no he entendido demasiado mal lo (poco) que he leído del tema, que tal como está montado en .NET es bastante poco eficiente ya para aplicaciones de varias hebras (aunque cumple su labor bastante bien en aplicaciones monohilo), y no te digo ya nada si se utilizase tal cual en tiempo real. Sin embargo el concepto no es malo, aunque se me antoja que debería ser un proceso "aún más" externo el que vigilase el asunto.
¿consideramos a C# sólo C#, o sería C# = C# + el CTS + la BCL de .NET?
Bueno, al fin y al cabo, library design is language design... pero es que ni siquiera se trata de eso. No se trata de si dos sistemas de desarrollo con runtime libraries diferentes son o no el mismo lenguaje, que eso es muy metafísico, sino de las consecuencias prácticas al pasar de un sistema (nativo o .NET) al otro.
Pablo, los sistemas en tiempo real son sistemas que requieren respuestas en periodos de tiempo acotados.
Es decir que si le mando tal orden el sistema tiene x microsegundos como máximo para dar la respuesta y si en ese momento salta el recolector de basura entonces se va todo a tomar por saco.
No se si conocereis alguna salida para estos casos además de forzar la recolección de basura continuamente.
Customized CLR hosting? No lo he mirado, pero si hay algo debe ir por ahí...
... de todos modos, para algo tienen que servidor C++ y Delphi nativo. Ese es el tipo de cosas que no me lo pensaría para arrancar con otro lenguaje que no fuese C# (a pesar de que el ray tracer puede lanzar 64, 100 y más recogidas de basura en un rendering de uno a diez segundos, sin que sea el coste predominante).
Y si la comunicación con bases de datos no necesitase respuestas en tiempo real, para evitar el agobio usaría MSMQ para encolar las grabaciones. Lo digo porque en ocasiones he visto agobios e histerias por las necesidades de grabación de datos "en tiempo real", necesidades que luego no han resultado ser tales. A mí, sinceramente, me preocupa más que el McAfee salte en un momento inoportuno que el salto del garbage collector... más aún cuando se utiliza el garbage collector concurrente.
"...me preocupa más que el McAfee salte en un momento inoportuno..."
Creo que ha llegado el momento de cambiar de antivirus ;-P
Buah... el Kaspersky es aún peor. Y juro por los dioses del Olimpo que el Panda de 1999 se llevaba a matar con mi Delphi 5 y las tres dichosas capas. Siempre sospeché que el hecho de que estuviera hecho en Delphi (sería interesante averiguar en qué lo programan ahora) tenía algo que ver. Además, el icono del panda que aparecía en la bandeja de iconos me daba mucho yuyu: parecía una calavera con mala leche.
"el Kaspersky es aún peor"
¡¡¡Hereje!!! :D
Por lo menos Kaspersky no es como el Norton (¿estará el ilustre Peter arrepentido de haberles "prestado" a Symantec el uso de su apellido?), que con los SIETE procesos que tiene en memoria es fácil que pase DE LOS 100 MB de RAM utilizados. Yo al Kaspersky sinceramente no he visto nunca (al menos en las dos últimas versiones) que sea para nada intrusivo. También es cierto que aqui en casa no tengo un archivo .pst del Outlook de casi 3GB como en el curro, para compararlo... ;-)
En cuanto a Panda... yo siempre me he preguntado si el hecho de quedar todos los años (pero todos eh) vencedor de las comparativas de la infame PC Actual, tendrá que ver con la ingente cantidad de páginas de publicidad que Panda pone (y paga) en esa "revista". Lo que sí es objetivo es que durante bastantes años, hasta hace dos o tres creo, dejaron de asistir a los tests de VirusBulletin. Es de suponer que la "somanta palos" que se habían llevado en las anteriores hicieron pensar a sus jefes (los de Panda) en no hacer más el ridículo.
Que más o menos por la época que comentas (2001) en una empresa en la que estuve, instalar el infame Panda Platinum en el servidor de producción que tenia WinNT4 por entonces... nos llevó a vernos obligados a FORMATEAR Y REINSTALAR dicho servidor DURANTE EL FIN DE SEMANA (sí, nuestra "suerte" fue que la degradación galopante que sufrió el cacharro en cuestión, llegó a su punto insoportable el viernes por la tarde, lo cual "afortunadamente" no afectó al desempeño de la empresa, y además todo el departamento trabajamos sábado y domingo "con mucho gusto").
Creo que ahora mismo desarrollan en Winforms, al menos la parte interfaz (lo sé por que vi ofertas en infojobs, jeje). Ah, por la web de blogs que se mueve tu amigo (y mi admirado) Octavio, geeks.ms (donde habita tambien gente "un poco bastante" clasista y elitista, pero esto ya es harina de otro costal), hay un par de ex-Pandas, aunque yo como tampoco tengo confi con ellos nunca me he aventurado a meterles el dedo en la llaga xD
Saludos
Ah, por la web de blogs que se mueve tu amigo (y mi admirado) Octavio, geeks.ms (donde habita tambien gente "un poco bastante" clasista y elitista, pero esto ya es harina de otro costal), hay un par de ex-Pandas
Así han quedado de la cabeza. El Panda además de ser para muchos el peor antivirus y para todos uno de los peores, es una empresa muy vinculada a la iglesia de la cienciología.
Xenu
Panda. Curiosa empresa. Hace años, cuando las primeras adsl de telefónica, tuvimos un problema en un cliente. Resulta que el Panda daba conflicto con el driver del modem adsl y daba pantallazo azul. Solución del soporte técnico de Panda: "... Pues desactive el antivirus cuando vaya a navegar por Internet". Me pinchan y no me sacan gota sangre...
Publicar un comentario
<< Home