Libertonia || Comments || ¿Qué fue del Ada?


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

¿Qué fue del Ada? | 22 comentarios (22 temáticos, editoriales, 0 ocultos)

Experiencia en el mundo de la empresa (none / 0) (#8)
por Anónimo a las Mon Sep 16th, 2002 at 07:02:43 PM CET

Vaya por delante que no sé apenas Ada, ni mucho menos he programado en Ada para el mundo real, pero si puedo hablar de las ventajas de la "infexibilidad".

La "inflexibilidad" hace lento el programar y cómodo el mantener y depurar. Lamentablemente, hoy en día la política de las empresas es "programa en plazos mínimos, aunque esté lleno de bugs".

No es una cuestión de falta de profesionalidad, es una cuestión de supervivencia. Si alargas los plazos, aumentas el presupuesto y la competencia se te pone por delante. No importa que a largo plazo tus costes sean menores si no sobrevives a corto plazo. Microsoft es el paradigma de esta estrategia.

Hoy en día lo que sobrevive tiene un nombre: "barato", sólo tienes que fijarte en tu propio comportamiento en el supermercado, es posible que en algún artículo tengas tus manías y estés dispuesto a gastar un poco más por calidad, pero en general escoges lo más barato. Lo mismo hace el cliente, consumidor de informática.

Normalmente trabajo en Delphi, que tiene sus más y sus menos, pero en general va bien. Seguir algunas políticas de codificación y diseño no va mal. Hay que saber encontrar el límite entre hacer las cosas a la buena de Dios, o hacerlas muy puristas... para dentro de cinco años.

Hay ciertas cuestiones de "inflexibilidad" que no son meramente académicas, son tremendamente útiles:

Encapsular: centralizas el problema... y los bugs. Solo hay que tener cuidado con no pasarse.

Reutilizar: Puede ser muy util pero es una parte peligrosa. Puedes perder mucho tiempo tontamente haciendo una abstracción de muchos casos, terminas no reutilizado nada y con un objeto que realmente son mil objetos que cubre muchos casos.

Tipos Enumerados: Utilizalos y mucho.

Subrangos: En pascal hay algo parecido, en general no son muy útiles, salvo para ahorrar memoria, (usar 1 byte en lugar de 4 para un entero). Suele ser suficiente validar los rangos en la entrada de datos por programa. Rara vez se producen bugs de rango durante el proceso de información si la entrada está bien validada.

owner

en este artículo

El hecho de que la sintaxis del lenguaje exija cierta "rigidez", en lugar de depender únicamente de que el programador se digne a aplicar la metodología, puede ser un punto a favor de un lenguaje.

[ Padre ]

De inflexibilidades (none / 0) (#10)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Mon Sep 16th, 2002 at 07:42:48 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Llámalo malas prácticas cogidas de C, pero a mí por ejemplo que no se pueda hacer aritmética de punteros (para recorrer una zona reservada de memoria, por ejemplo) es algo me me molesta. Es un ejemplo de inflexibilidades que son incómodas para el que sabe lo que está haciendo. Para el que no lo sabe, puede ser un flotador salvavidas, pero lo considero anecdótico: se salva de ese error, pero ya caerá en otro.

Los lenguajes que se diseñan específicamente para aprender a programar corren el riesgo de no usarse más que aprender a programar. Esa es en mi opinión uno de los puntos que han hecho "fracasar" algunos lenguajes. Y en concreto, entre ellos, a Ada.

El mismo Pascal, si no fuera por Delphi, estaría casi igual de desaparecido. Y programar en Delphi tiene poco que ver con programar en Pascal. Si tuviera ahora que meterme con Delphi, dudo mucho que me sirvieran mis viejos conocimientos de Pascal. Seguramente me servirían bastante más mis conocimientos de un POO como C++.

Y respecto a la recolección de basura, es una auténtica cruzada entre dos "escuelas". Se lleva discutiendo enconadamente desde hace tiempo sin que se haya llegado a una Conclusión Satisfactoria(TM). Está más allá de mis conocimientos dilucidad qué opcion es mejor. Pero a mi intuición no le gusta el recolector de basura. Todo lo que funcione en mi programa autónomamente, sin control, es algo sospechoso. }:-)

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]

Opiniones varias (3.00 / 1) (#12)
por DopeRider a las Tue Sep 17th, 2002 at 02:02:00 AM CET
(Información Usuario)

Me temo que no estoy de acuerdo con ninguno de los dos, que ya es difícil. A ver si puedo dar una explicación convincente del porqué.

He programado "unas cuantas" líneas de código con Delphi y aprendido a que me guste lo que estáis llamando "la rigidez". Pero yo nunca la llamaría así. Para mí es un "mecanismo de detección temprana". Me parecía muy cabreante que en CLIPPER o Java los "compiladores" te dejasen tragar muchas cosas... e incluso se ejecutasen bien, explotando una docena de instrucciones más tarde y soltando un volcado de "pila virtual". Si a la hora de compilar se "sabe" con toda seguridad que existe un error, ¿por qué me haces perder el tiempo con un ciclo compila-ejecuta-cagonlaleche?.

Pero dejarlo así es equívoco. Ni Delphi ni su antecesor TurboPascal (desde 1985) te impiden hacer cualquier tipo de burradas (léase typecastings de lo más variado, entre otras cosas). Yo las usaba bastante a menudo y hubiese mandado el lenguaje al peo, si no. Pero ¿es ésa la única razón de que esta línea haya tenido éxito a diferencia de sus primos (Modula, ADA, Oberón, etc.)?. Tampoco diría yo eso, porque además se suman:

Precio. En el 85 creo que TP 1 costaba $50. El precio de la versión elemental de Delphi era hasta la versión 5 de unos $200.
Ausencia de fallos graves
Entorno de desarrollo con depurador integrado muy usable. Si se le suma que el compilador es rapidísimo (unos cuatro millones y medio de líneas por minuto), la diferencia cuantitativa se hace cualitativa. Tengo Gentoo y ya quisiera que Linux se compilase a esa velocidad :-)
Librerías adecuadas para cualquier tarea necesaria.
Código nativo muy rápido.
Comunidad activa.

Así que parece que el éxito se forma haciendo muchas cosas bien a la vez. O no haciendo mal las que más joden. O quizás la clave sea todo eso y además estar en el sitio y momento adecuados para llenar una necesidad. Se explica de forma bastante amena en "Worse Is Better" (es el punto 2.1 de este doc). Es en cualquier caso un texto muy interesante para afilarse las entendederas :-)

Otra cosa que me gustaría matizar es que los distintos lenguajes de programación pueden tener utilidades muy distintas. C, Pascal, Ada (o sus variantes con objetos) son prácticamente todos el mismo lenguaje, con diferencias cosméticas.

Pero Perl, Lisp o la familia ML creo que son algo completamente distinto.

Lo digo porque no es lo mismo hablar de un recolector de basura para Lisp que para C o Pascal. A un lenguaje del nivel de Delphi no se le debe prohibir el manejo directo de la memoria. Lo que es idiota es no hacer que los objetos puedan opcionalmente ser variables de pila, que las hay en C++ y no pasa nada. Por otra parte, me parece que el mayor problema de un recolector es que esté mal hecho, que me temo que he visto al menos un caso.

Otras características también dependen del tipo de lenguaje. Por decir una obviedad: un lenguaje interpretado no necesita buenas herramientas para detectar fugas de memoria (a no ser que su recolector de basura sea una caca) o un depurador de código objeto.

En fin, que este tipo de análisis es muy complicado, porque depende de muchos factores. Personalmente me quedo con la respuesta: "un lenguaje no es popular porque no gusta a quienes podrían hacerlo avanzar".

[ Padre ]

Ada no se diseñó para aprender (none / 0) (#14)
por fernand0 a las Tue Sep 17th, 2002 at 11:12:41 AM CET
(Información Usuario)

"Los lenguajes que se diseñan específicamente para aprender a programar corren el riesgo de no usarse más que aprender a programar. Esa es en mi opinión uno de los puntos que han hecho "fracasar" algunos lenguajes. Y en concreto, entre ellos, a Ada."

Es la primera noticia que tengo sobre el diseño de Ada para aprender a programar. Lo que dices si que es posible que haya hecho que Pascal no haya llegado a ninguna parte; aunque algunos de sus derivados gozan (y han gozado) de buena salud. Por lo tanto, parece que lo que impidió que Pascal llegara a ningún sitio fue que se trataba de un lenguaje 'de juguete' que carecía de cosas importantes (en aquel entonces, principalmente, memoria dinámica).
Tienes razón al decir que a Ada le faltan bibliotecas; en realidad, si nos fijamos, los lenguajes que 'triunfan' no es por la calidad del lenguaje, sino normalmente por la existencia de un buen conjunto de bibliotecas que permiten hacer cosas habituales de modo sencillo, y aumentar eso que llaman productividad. Como dice alguien más arriba, normalmente se vende el producto y adiós que te vaya bien; a veces se solucionan las pegas y fuera.
Otra cosa es que Ada (o un subconjunto adecuado de Ada) sea un buen lenguaje para aprender: tipado fuerte, sintaxis regular, compilador disponible (y gratis) para muchos sistemas, portable, es un lenguaje 'de verdad' (no como Pascal, que si quieres hacer algo tienes que recurrir algún pariente 'próximo'), ....

[ Padre ]

Lenguajes de "verdad" (none / 0) (#15)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Tue Sep 17th, 2002 at 01:08:08 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

No, pero sí se ha utilizado para ese menester en las universidades. Esa es mi experiencia, y probablemente la de la mayoría de los que conocen el lenguaje Ada por estos lares.

En cuanto a lo de `lenguaje de verdad' me gustaría saber si consideras un lenguaje de verdad a Ada 83 -que es con el que yo aprendí, por ejemplo-, dejando Ada 9X -perdon, Ada 95- aparte.

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]

Si, creo que si (none / 0) (#17)
por fernand0 a las Wed Sep 18th, 2002 at 12:08:36 PM CET
(Información Usuario)

Lo que me sorprende es que tú no lo consideres (si no, no tiene sentido la pregunta, igual estoy equivocado), y me gustaría saber por qué.
Mi experiencia con Ada83 es limitada: construí un pequeño simulador; si no recuerdo mal, ya se incluían paquetes genéricos y creación dinámica de tareas concurrentes.

[ Padre ]

Tampoco (none / 0) (#16)
por DopeRider a las Tue Sep 17th, 2002 at 05:25:25 PM CET
(Información Usuario)

Lo que dices si que es posible que haya hecho que Pascal no haya llegado a ninguna parte

¡Qué va!. Pascal fue un pelotazo. De hecho, murió de éxito. Como todo el mundo quería Pascal en su nueva plataforma ya, se inventaron la máquina virtual y el bytecode. ¿Cómo?, ¿que entonces se llamaban de otra forma?. Sí, pero eran exactamente lo mismo que el Java tiene ahora. Naturalmente, en aquellos tiempos (¿y en estos?) la sobrecarga era excesiva para las máquinas existentes y cayó la fama de la lentitud. Las implementaciones originales eran compiladas, pero tú cría fama...

Tampoco es verdad que faltara memoria dinámica. Era estándar desde Wirth.

Lo que sí faltaban por ejemplo eran las cadenas como tales (existían arrays de caracteres, pero no había librería estándar) y funciones potentes de consola. Cada fabricante añadió extensiones a su bola y fue un caos.

[ Padre ]

Nunca he sido un fan de Pascal (none / 0) (#18)
por fernand0 a las Wed Sep 18th, 2002 at 12:23:45 PM CET
(Información Usuario)

Lo del éxito no lo tenía claro. Para la crítica sobre lo que le faltaba a Pascal un artículo interesante es Why Pascal is not my favorite Programming Language. Lo lei hace bastante tiempo, y echándole un ojo ahora no estoy seguro de que tenga razón en todo.
Pero algún problema debía tener, si los que pensaban que Pascal era un buen lenguaje para la enseñanza 'evolucionaron' a cosas como Modula, y Oberón.

[ Padre ]

Prehistoria (none / 0) (#19)
por DopeRider a las Wed Sep 18th, 2002 at 07:00:50 PM CET
(Información Usuario)

Why Pascal is not my favorite Programming Language. Lo lei hace bastante tiempo, y echándole un ojo ahora no estoy seguro de que tenga razón en todo.

Para los que empezamos con TurboPascal no tiene razón en casi nada. La mayoría de las cosas que dice que no se pueden hacer, sí se pueden hacer con TP (desde la versión 1 de 1985). OK, TP no era un lenguaje estándar, pero eso es otra historia.

Otras cosas que presentan como defectos son en realidad ventajas, cuando se consideran con "objectividad".

Lo único en que estoy de acuerdo es la molestia de los "begin" en bloques. En TP fue una cuestión política. Ya existía Modula, en el que Wirth había corregido su fallo anterior. Sin embargo, "Pascal" seguía siendo un nombre más conocido que "Modula" y parece que Anders tiró por el lado comercial a la hora de pegarse a un estándar.

Pero algún problema debía tener, si los que pensaban que Pascal era un buen lenguaje para la enseñanza 'evolucionaron' a cosas como Modula, y Oberón.

Problema y gordo tenía el original. Era un lenguaje cuyo estándar era de juguete. No así las implementaciones comerciales, pero entonces el problema era la falta de un estándar fuerte.

Los creadores de C escarmentaron en cabeza ajena e implementaron una librería estándar suficiente (para la época).

[ Padre ]

Tu mismo lo dices (none / 0) (#20)
por fernand0 a las Thu Sep 19th, 2002 at 10:11:16 AM CET
(Información Usuario)

TurboPascal no es Pascal. Ni siquiera había compatibilidad hacia atrás en algunas de las cosas que fijaba el estándar de Pascal. Era una opción válida, en todo caso (luego vino Delphi, y goza de razonable salud). Además TurboPascal sólo existía para Windows (creo que para mac tampoco lo había, pero no podría confirmarlo). Súmale a la falta de un estándar completo la aparición de MS Pascal, con sus particularidades (¿cómo se llamaba, alguien lo recuerda?), y ya tienes el lío armado.

[ Padre ]

QuickPascal (none / 0) (#21)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Thu Sep 19th, 2002 at 10:29:10 AM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Si no recuerdo mal era QuickPascal. Estuve utilizandolo una temporada. Era muy similar al Turbo Pascal, excepto que no era 100% compatible.

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]

fernand0 (none / 0) (#22)
por fernand0 a las Fri Sep 20th, 2002 at 10:30:24 AM CET
(Información Usuario)

O sea: tenemos Pascal, Turbo Pascal, y Quick Pascal. A eso me refería. Claro que en otros lenguajes ha habido la misma atomización (o más) y han gozado de éxito. Aunque creo que tenían estándares más amplios que el de Pascal. Pobre Pascal, tanto hablar de él en una historia sobre Ada ;)

[ Padre ]

¿Es malo? (none / 0) (#13)
por DopeRider a las Tue Sep 17th, 2002 at 03:12:34 AM CET
(Información Usuario)

Lamentablemente, hoy en día la política de las empresas es "programa en plazos mínimos, aunque esté lleno de bugs".

No creo que sea necesariamente malo un programa porque se haga rápidamente, ni que tenga que estar lleno de bugs. Me mosquea más lo de "barato". Lo barato es caro.

Le he estado dando muchas vueltas recientemente a saber qué falla con las herramientas de programación que uso.

Todavía tengo más preguntas que respuestas, pero cada vez veo más práctica la programación web, apoyada en un lenguaje flexible y potente.

Delphi es muy bueno para las interfaces de usuario, pero éstas ya no exigen tanta eficiencia. Con una máquina reciente y un navegador tienes el 90% de la funcionalidad y además multiplataforma.

Lo que marcaba la diferencia era el buen diseño visual, que venía a ser manejar un compilador de forma tanto o más cómoda que un intérprete. Por cierto que Borland quizás deba sacar otra vez Intrabuilder :-)

[ Padre ]

¿Qué fue del Ada? | 22 comentarios (22 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda