|
|
|
Secciones
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Criterios
(Puntos:4, Informativo)( http://barrapunto.com/ )
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.
Re:Criterios
(Puntos:3, Interesante)¿Por qué? Me dirás por el rendimiento, pero muchas veces el rendimiento no es lo más importante. ¿Debemos sacrificar la coherencia (tener tipos primitivos y objetos en Java) por velocidad? ¿La seguridad y simplicidad?
Pues en ocasiones, sí. Pero en otras no. Es bueno que existan lenguajes como C que sacrifican muchas cosas en aras del rendimiento y poca abstracción, pero muchas veces necesitamos lo contrario.
>u obligarte a declarar siempre las excepciones, o quitar los gotos, o los "efectos secundarios"
Lo de declarar siempre las excepciones hace la vida mucho más sencilla al programador, en serio. Es mucho más facil que el compilador te diga donde y como has de poner control de errores que tener que ponertelo tu a mano. Que haya un sistema estandarizado para el control de errores es un plus (cuando habia un error en esta función... con el 0 o con -1??). Manejar errores con excepciones queda muy bien. No digo que sea la mejor alternativa; quizas seria mejor unchecked exceptions, pero las checked exceptions 'obligan' a una cierta forma de trabajo que me gusta bastante...
Conozco pocos lenguajes imperativos que eliminen el goto, porque en ocasiones si es necesario (aunque las excepciones son muchas veces un buen sustituto), aunque es mejor no usarlo si no es estrictamente necesario.
Lo de los efectos secundarios ya es más complicado. Dado que tratamos con ordenadores que tienen 'estado', es natural que los funcionales no acaben de encajar; esto es, hacer I/O, acceso a bases de datos, etc... no me acaba de encajar en un lenguaje funcional. Vi lo de las mónadas de Haskell y casi me explota la cabeza.
Siempre he imaginado un lenguaje dual imperativo/funcional... parte imperativa donde sea necesario y un interfaz limpio con la parte funcional que lleva toda la lógica.
> ¿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.
¡No! Un lenguaje no es igual para todas las aplicaciones. Acabas con monstruosidades como el C++, que tienen de todo; el lenguaje en sí está muy bien, pero todos los desarrolladores de C++ hablan dialectos diferentes. Mejor lenguajes pequeñitos para propósitos limitados.
No es lo mismo un lenguaje para hacer sistemas, que uno para hacer cálculo numérico, que uno para hacer interfaces de usuario, que...
Re:Criterios
(Puntos:2, Interesante)( http://www.gatogordo.es/ | Última bitácora: Sábado, 29 Mayo de 2004, 03:47h )
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.
Bien... voy a probar, siguiendo tu metodo, si ProLog es un lenguaje que vale la pena... y lo probare con un programa tan complejo como un servidor X... vaya, el programa es una chapuza total, descartemos ProLog como lenguaje util. Sigamos con el experimento, probemos MatLab para programar Half Life 2... uff, imposible. MatLab no vale para nada. Y, por ultimo, probemos C++ para crear un modulo de inteligencia artificial... eliminamos C++ tambien?
Hace tiempo que se abandono la idea de la centralizacion, de crear Un Lenguaje Unico para reunirlos a todos y atarlos en las tinieblas. Hay conjuntos de aplicaciones que, por sus caracteristicas, requieren de diferentes lenguajes orientados a otro tipo de programacion.
Y eso de que los estudiosos de la metodologia no dicen cosas relevantes... eso solo puedes decirlo si todavia tienes la obsoleta idea de que la algoritmia es unicamente una cuestion de ordenadores. Llevamos mucho tiempo trabajando con la arquitectura Von Newman pero... que pasa si cambiamos esto? Los ordenadores cuanticos estan ya en la mente de algunos cientificos, y con ellos pueden desaparecer conceptos como el acceso a memoria o el sistema de ficheros, que pasara entonces con tus programas? Que no serviran para nada. En cambio, el programa hecho desde un punto de vista "metodologicamente correcto" seguira valiendo, ya que gozara de una perfeccion matematica independiente del sistema de computacion.
Intuyo que eres programador desde hace ya tiempo, del tiempo en el que los programadores solo aprendian las instrucciones y se servian de cualquier chapuza para hacer que el programa funcionara. Con los nuevos paradigmas de programacion estas chapuzas no estan permitidas, y la mayoria de los chapuceros tienden a criticar la (supuesta) falta de libertad en lugar de darse cuenta de la autentica mejora.
Aunque por otra parte... todo esto es solo mi opinion.
Lo que no es util para la colmena no es util para la abeja, Marco Antonio
El Gato Gordo [gatogordo.es]
Re: Más criterios
(Puntos:1)Míralo de otra manera: los lenguajes que te dejan hacer una misma cosa de varias maneras distintas sin que haya un buen motivo (arbitrariamente, por razones "históricas", etc.):
- Te obligan a tomar constantemente decisiones irrelevantes para tu trabajo. ¿Cómo lo hago? ¿Lo hago así o asá? Si son lo mismo...
- Causan inconsistencias entre trozos de código de distintos programadores.
- Aumentan la complejidad y las posibilidades de fallo.
Si sólo hay una manera, pueden pasar dos cosas. 1) Que la manera sea la mala, luego el lenguaje no sirve y mejor no lo uses; 2) que sea la buena, y el lenguaje es mucho mejor.
En Eiffel, las maneras de hacer las cosas me parecen bastante buenas.
eliminar los tipos simples
No se eliminan los tipos simples. Si yo quiero una variable integer, es integer y ya está. Luego puedo manejarla como un objeto, reservando memoria dinámica, creando punteros a ella, etc. O como un tipo simple. El compilador distingue cómo la estoy usando y genera código eficiente en los dos casos.
En cambio, en Java, por ejemplo, cada vez que quiero una variable entera tengo que elegir entre el tipo int, o un objeto de clase Integer. A veces no está claro cuál de las dos opciones es necesaria. Cada vez que hay que transformar de uno a otro, hay que llamar a una función explícitamente. Es confuso, pesado e ineficiente.
o los punteros
Tampoco se eliminan los punteros. Se hace como en Java o cualquier lenguaje OO moderno: lo que se elimina es la "aritmética de punteros" de C. O sea, el poder coger un puntero, sumarle 2 bytes y tener una "cosa" que apunta a la "mitad" de un objeto, permitiéndome destrozarlo y producir unos bugs alucinantes, o tener código no portable. También se elimina la farragosa sintaxis de C y C++ cuando se usan punteros, a base de muchos * y &. Por lo demás, se puede hacer todo lo que haces con los punteros, con la cualidad de que *siempre* apuntan a objetos correctos.
el acceso directo a memoria
El acceso directo a memoria sólo es necesario en programas de bajo nivel: sistemas operativos, drivers de dispositivos y librerías muy especializadas. En cualquier otra aplicación es más peligroso que una granada de mano con la anilla quitada. El acceso directo a memoria se debe hacer siempre en librerías escritas en C y encapsuladas para ser llamadas desde otros lenguajes.
obligarte a declarar siempre las excepciones
En Eiffel el uso de excepciones es más limitado que el de otros lenguajes. Son una característica muy buena, pero usadas con exceso acaban generando código "espagueti", como en los mejores tiempos del "goto". Eiffel también tiene un tratamiento bastante original de las excepciones: te deja reintentar la operación o volver con error, pero no capturar la excepción y volver como si no hubiera ocurrido nada. Esto impide usarlas para control de flujo, que es uno de los abusos más habituales.
o quitar los gotos
Llevo 13 años programando. Desde los viejos tiempos del BASIC del Spectrum jamás he necesitado usar el goto para algo que no sea equivalente a una sentencia "break" o a un lanzamiento de excepción.
o los "efectos secundarios" (ver funcionales puros)
Eiffel tampoco elimina los efectos secundarios. Lo que hace es que los vuelve explícitos, para que siempre que se llame a un método esté clarísimo qué efectos secundarios van a ocurrir. Además, las invariantes y postcondiciones permiten mantenerlos totalmente controlados. O sea, tienes todos los efectos laterales que quieras, y al mismo tiempo evitas la cantidad de bugs chungos que producen en otros lenguajes.
El modelo de Eiffel es para mí la combinación perfecta de lenguajes funcionales y procedurales.
o... todas las prohibiciones que al iluminado de turno se le ocurran para crear el "lenguaje ide
Re:Criterios
(Puntos:2)( http://barrapunto.com/ )