Barrapunto

Pues tienes suerte, si logras aprender todas las capacidades de ese lenguaje lograrás una buena visión de la programación Orientada a Objeto, es un lenguaje muy completo, permite implementar prácticamente todos los tipos de herencia (creo que había hasta 11...) y cualquier otro lenguaje que vayas a utilizar, quizás quitando C++ en algunos aspectos, (Java) será un juguete a su lado.. Sobre todo intenta asimilar "los conceptos". Agentes, renombrado, redefinición, sobrecarga de operadores.., herencia múltiple con "camino" de herencia, etc... Creo que usar Eiffel, junto con Smalltalk, para para mostrar un lenguaje no tipado estáticamente, es la mejor estrategia para enseñar Orientación a Objeto. Felicidades... P.D.: 1 Obviamente no pierdas de vista C++ o Java, por interés "laboral" y para ver cómo otros lenguajes inventan chapuzas para algo que Eiffel implementa de manera natural... 2 La empresa de Meyer ha sacado un compilador Eiffel compatible .NET y también compatibles Linux y Mac. Aunque SmallEiffel debería sobrarte para prácticas...

...porque haciendo Eiffel en un "cuatrimestre" tienes que ser un fiber...
espero que tengais suerte con la temida practica de PP, y que cojais un buen compilador, porque un servidor con su equipo usaban el que te dejaban en la asignatura, al que le costaba entre 30 segundos y 1 minuto compilar, y tuvo que currarse la E/S de ficheros haciendo llamadas a C con "_c_inline_c_" porque la que traia la libreria del eiffel no permitian casi nada.

Espero que lo tengan mejor montado que hace unos añitos...

Muchos animos con PP y que no decaiga.

Un fiber en el extranjero

Creo que los fibers ya no utilizan Eiffel para PP sino que utilizan Java... Mi experiencia con Eiffel es que las herramientas que hay son de calidad bajísima, por esto solo se usa en entornos académicos. La verdad, es que yo diría que lo mejor que te puede pasar con Eiffel es poder huir. Intenta trabajar con Java o C++

Lo que un estudioso de metodologís te dice sobre lo bueno que es un lenguaje basándose en sus características es completa, absoluta y totalmente irrelevante, inútil e incluso me atrevo a decir que perjudicial para tu carrera.

Las características en sí pueden ser muy interesantes mientras te faciliten llevar a cabo ciertas tareas (aunque muy posiblemente sea mejor la presencia de librerías) pero desconfía de todas las características que consisten en impedir cosas u obligarte a programar de una forma determinada.

Por ejemplo, es bueno tener objetos porque te permiten encapsular operaciones. Pero no lo es eliminar los tipos simples, o los punteros, o el acceso directo a memoria, u obligarte a declarar siempre las excepciones, o quitar los gotos, o los "efectos secundarios" (ver funcionales puros) o... todas las prohibiciones que al iluminado de turno se le ocurran para crear el "lenguaje ideal".

El lenguaje ideal es el que te permite hacer cualquier cosa con el mínimo número de "tokens" (no de caracteres), que dispone de mayor cantidad de librerías y herramientas, y que no es monopolio de una empresa. Si además se entiende lo que escribes, no sólo es ideal, sino que además sirve para algo :-)

¿Quieres un criterio infalible?. Busca un programa de complejidad media y lo escribes en cada lenguaje que encuentres. Que el problema tenga al menos sockets, tuberías, ficheros binarios, multihilo, acceso a bases de datos relacionales y un algoritmo de cálculo intensivo.

Comprueba si se puede, lo que cuesta escribirlo, lo que cuesta leerlo después de cuatro meses, lo que le cuesta leerlo a otra persona, que se ejecuta en tiempo razonable, lo que cuesta localizar fallos, etc.

Después lee lo que cuentan por ahí y lo que te digan los profesores. Y por último y si te sobra tiempo, escribe en Barrapunto preguntando :-)

Tampoco te fíes de la popularidad del lenguaje para juzgarlo. Es una pista, pero no prueba nada.

Usé Eiffel el semestre pasado en una práctica y, pese a que no tenia demasiadas buenas expectativas con él, me acabó gustando. És un excelente lenguaje para aprender OO, mucho más adecuado que Java, por decir alguno, para ese fin.

El problema está en que Eiffel és un lenguaje de programación relativamente nuevo y a veces es sumamente complicado encontrar buena información y tutoriales para él. Además sus complementos dejan bastante que desear, como es la libreria wxEiffel, una implementación de las wxWindows para Eiffel, que está llena de bugs e, incluso, en ciertos sistemas ni siquiera funciona (como por ejemplo en GTK dónde es imposible recoger un evento de un botón).

Lo paradójico del caso es que los responsables de la práctica que hice nos recomendaban usar esta libreria gráfica cuando incluso el propio programador en jefe de ella se extrañó cuando le comenté tal hecho.

Un dia de estos yo y un par de colegas haremos una libreria gráfica para Java, a ver si en una unversidad de Australia les da por recomendarsela a los alumnos! u_U

salU2

Yo hice PP el cuatrimestre pasado y me gustó bastante programar en Eiffel. Lo que más me gustó sin duda fue la información que vuelca el programa al violar alguna aserción (causadas normalmente por indices fuera de rango, objetos no instanciados, ..., o por las que tú hayas definido), te muestra toda la pila claramente y el valor de variables y estructuras de datos en el momento del error. Sobre PP decirte que es una asignatura hecha para hacer sufrir, no importa el lenguaje en que la hagas xD Algunos consejos: no uses las wxWindows como os recomendarán, estan plagadas de bugs, usa la utilidad short que incluye SmartEiffel para generar la documentación de las clases (lo agradecerás en la segunda entrega), no os paseis con los requerimientos y especificad bien claramente cada clase antes de poneos a implementar cosas como locos (luego pasa lo que pasa, no PaRaP? xD). Un saludo y ánimo con PP.

Yo tengo desde hace tiempo un dilema con dos lenguajes: Python y Eiffel. Son muy distintos, pero para mí ambos son candidatos a ser "el lenguaje ideal" (combinándolos con C para el bajo nivel). Pero los dos necesitan algo para ser perfectos, que el otro lo tiene.

Sobre Python no diré mucho, porque es bastante conocido. De Eiffel diré que tiene tres o cuatro ocurrencias que a mi me parecen verdaderas genialidades, y que echo de menos todos y cada uno de los días que me paso programando en cualquier otro lenguaje. Yo he programado todo tipo de cosas, desde scripts hasta aplicaciones gigantes con 20 programadores. Y estas cualidades se notan más cuanto más grande es el programa, aunque creo que también se pueden aplicar a los más pequeños.

1) Sobre todo, elDiseño por Contrato integrado en el lenguaje. En otros lenguajes también se puede hacer, pero siempre cuesta bastante más, y no hay una manera normalizada de hacerlo. Aun así, yo me he acostumbrado a programar siempre usándolo. Casi nunca hago pruebas unitarias, y sin embargo, creo que mis programas son más sólidos y funcionan mucho más pronto que si lo hiciera de otra manera.

2) Encapsulación de los atributos. Cualquier programador de OO sabe que no se debe hacer un atributo público para que cualquiera pueda escribir cualquier cosa sobre él. La solución típica C++ es hacer todos los atributos privados, y escribir funciones get y set. ¡Feo, engorroso e ineficiente! Lamentablemente, todos los lenguajes famosos tienden a copiar este error (por ejemplo, Java y Python). En Python aún peor, hay que declarar el get, el set y luego una property.

En Eiffel, directamente está prohibida, por definición de lenguaje, la sintaxis objeto.atributo = valor. Sólo se pueden cambiar los atributos desde dentro de la clase. Así ya no hay peligro en declarar atributos públicos, y se puede usar público o privado para su sentido real, que es saber si un atributo debe ser conocido por los usuarios de la clase o no. Y si se quiere que otros puedan modificarlo, se escribe la función set, la cual puede tener precondiciones que validen el dato a modificar. También es eficiente, porque el compilador convierte en inline automáticamente todas las funciones pequeñas, sin tenerselo que decir explícitamente como en C++.

3) Código autodocumentado. Esto también se puede hacer más o menos en otros lenguajes, pero no como en Eiffel. Este lenguaje está diseñado para que se puedan tener varias vistas del código: una completa; otra ocultando la implementación y mostrando sólo las declaraciones; otra ocultando todos los atributos y métodos privados. Así tienes sin salir del editor, lo que en otros lenguajes se suele hacer con herramientas separadas (javadoc, doxygen o cocoon, pydoc). También se puede emular con el "folding" de algunos editores, pero no es lo mismo. Por ejemplo, no se puede hacer "fold" de los métodos privados y dejar los públicos. En Python, si haces fold desaparecen los comentarios. Y el fallo del punto 2 hace que si oculto la parte privada, me desaparecen todos los atributos y los métodos get/set se mezclan con los métodos normales, lo cual me impide tener una vista clara del "Tipo Abstracto de Datos" que implementa la clase.

Para mí, Eiffel, como lenguaje, es casi perfecto. Sin embargo, tiene un único fallo gravísimo que lo invalida: su autor ha pasado completamente de la comunidad. Al contrario que Guido Van Rossum, Meyer tiene mentalidad "Microsoft", tipo "yo me lo guiso todo". Pero no tiene tanto poder como M$, y no ha sabido estar a la altura, ni tampoco ha conseguido la colaboración de los demás. Por eso, las herramientas, librerías, manuales, soporte, y todas las cosas que rodean a un lenguaje y lo vuelven realmente útil, no son tan buenas como deberían.

Ahora lo está intentando "arreglar" aliándose con Micro$oft para crear un Eiffel# integrado en .Net, pretendiendo así arrimarse a las herramientas mucho más potentes de esta plataforma, pero sin perder la mentalidad cerrada.

No sé cómo ac

Lo confundes con Ada.

cada dia me hace mas gracia este señor

La explosión del Ariane 5 es por culpa del lenguaje Eiffel

Es justo al revés. Lo del Ariane 5 es un ejemplo que viene en el libro de Meyer sobre Eiffel, y lo pone como caso arquetípico de la utilidad del Diseño por Contrato.

En el ejemplo, Meyer explica cuáles fueron las causas de la explosión, y demuestra que, si hubieran programado con Eiffel, no hubiera ocurrido.

No recuerdo exactamente, pero era algo así: la causa fue que el programa de control del Ariane tenía una función que recibía como parámetro de tipo float con una velocidad. La función había sido probada mil veces y no tenía ningún bug, pero el parámetro medía la velocidad en millas, y sin embargo el programa llamante le pasaba kilómetros. Esto no venía indicado en ningún lugar del código fuente, sólo se explicaba en un documento aparte que nadie consultó por problemas de tiempo.

O sea, que no fue un bug de código sino de documentación. Si hubieran programado en Eiffel, las precondiciones de la función hubieran dado la alerta, y los revisores del código se habrían dado cuenta.

Tiene razón hirunatan:
Lo que ocurrió. Estaba programado en Ada (lo que no quiere decir nada, claro...). [uni-lj.si]
Desde el punto de vista del Eiffel y del diseño por contrato [maths.tcd.ie]