Michael Thomas Flanagan, profesor de una universidad del Reino Unido, lleva varios años desarrollando en colaboración con sus alumnos una librería científica para Java. La librería es muy completa: cuenta con funcionalidad para realizar operaciones con matrices, estadísticas, generación de números aleatorios, propagación de errores, regresión, optimización, transformadas de Fourier, integrales, interpolaciones, buscar raíces, operaciones con números complejos... y un largo etcétera.
Es la mejor librería científica/matemática que yo conozco para Java, o al menos la que más funcionalidad tiene. Tengo experiencia usando sobre todo la parte de transformadas de Fourier, y es la única librería (que no snipet de código) que he encontrado en Java que realice esta función. Java nunca ha sido un bastión fuerte para el cálculo numérico.
Sus puntos débiles son que ha sido desarrollada por científicos, que no por ingenieros de software. El API no está bien diseñada y no emplea convenios Java; la documentación de la librería la han hecho "a mano" sin usar el Javadoc. A menudo resulta necesario hackear la librería para conseguir lo que uno quiere; por ejemplo, ellos proporcionan funcionalidad para representar gráficamente una transformada de Fourier. Pero no proporcionan un widget, sino que lanza un Frame (tan siquiera JFrame) nuevo para representarla.
El otro punto débil es que la licencia no está demasiado clara. Lo único que te vienen a decir es que puedes usarla gratis en proyectos no comerciales. Pero el código no tiene una licencia propiamente dicha. En cualquier caso, como ya he dicho, para mí es la mejor librería científica que hay en Java.
¿Que otras librerías científicas conocéis?
Etiquetas: otro, Calculo, cientifico
http://jscience.org/
Eso no es que no sean ingenieros de sw, es que no tienen ni p*** idea de Java ... Se arregla con tiempo e interés (que a lo mejor les faltan). No me extraña que el código no tenga "licencia" ... Me "huele" a gente de Fortran ... Que se vayan mirando Fortress ...
(soy el anterior anónimo) Java nunca ha sido un bastión fuerte para el cálculo numérico. (Ni C, C++ ... Ni la mayoría de los lenguajes que usan los "ingenieros de sw" (perdón)).
La librería matemática muy bien... gracias.... pero me ha sorprendido cierta expresión viniendo de quien viene. Me perdonareis porque no quiero encender a nadie...
Estoy de acuerdo con la distinción que "sutilmente" se hace entre "ingenieros de software" y aquellos que saben programar.... pero para ser "ingeniero de software" primero hay que ser ingeniero... e ingeniero en algo relacionado con el software.
En serio... sin ánimo de crispar la situación en absoluto que sé que estos temas son discutibles y que hay gente muy válida en todos los campos (con o sin título)... pero lo dicho... que me sorprendió cierta cosa por eso que se dice de "ver la paja en el ojo ajeno".
Tal vez lo mejor sea decir: "se nota programada por alguien que no sabe programar en Java" y asi no hay sutilezas ni matices... porque lo de no usar el javadoc... es que clama al cielo...
El API no está bien diseñada y no emplea convenios Java; la documentación de la librería la han hecho "a mano" sin usar el Javadoc
¿Te refieres a esos "maravillosos" convenios de Java que mezclan mayúsculas y minúsulas haciendo casi ilegibles los textos? ¿O a ese "maravilloso" cambio a mayúscula de la primera letra de un nombre en los "getters" y los "setters"?
En lo que respecta al javadoc, ¿te refieres a esos "maravillosos" comentarios que, en realidad, no sirven para nada porque son completamente redundantes (¡por ejemplo, se comentan cosas que ya aparecen en la propia declaración de los métodos) y encima hacen que el código fuente sea ilegible porque está SATURADO de comentarios?
Yo odio los convenios de Java en cuanto a mayúsculas, y también odio el javadoc. ¿Soy por ello un mal programador? ¡No, no y no!
Me temo que estoy entrando de cabeza en un flame, pero es que algunas cosas de las que dices no tienen ni pies ni cabeza. Me explico:
Te puede gustar más o menos el convenio Java de nomenclatura, pero desde luego NO se trata de mezclar mayúsculas y minúsculas como te salga del bul, sino una sencilla regla: "las palabras se separan haciendo que la primera letra de las siguientes palabras sea en mayúscula".
Si entiendes esa regla entenderás porque se escribe getName y setName. Pero por lo que escribes parece que no te has parado ni un segundo a considerar que a otros muchos lo que nos molesta es ver set_name, y tener el código tiroteado por "_".
En lo que respecta al javadoc: ¿me quieres decir que cuando vas a usar una librería te pones a mirar el código fuente de esa librería? ¿Redundantes? Pues claro, SI LO QUE TIENES ES EL CÓDIGO FUENTE DELANTE. Si no ya me dirás tú como sabes la API de una librería... ¿te pones a usar reflection? :-D
Desde luego, tú tendrás tu sistema de documentación que es chachi piruli los-demas-no-tienen-ni-puta-idea-de-programar, pero permítenos a los demás ponernos de acuerdo en un estándar como el javadoc, y no tener que descifrar para cada librería que cae en nuestras manos como cojones se organiza la documentación de la API.
No tengo ni idea de que tipo de programador serás, pero desde luego con ese comentario has demostrado que de Java sabes lo justo, tirando a poco.
Salu2
Hola, ibon.
1.- Conozco la regla de las mayúsculas - minúsculas. Aun así, veo más legible perico_de_los_palotes o pericodelospalotes que pericoDeLosPalotes. ¿Tú no?
2.- Personalmente, el exceso de getters y setters (y los beans) es la cosa más absurda que he visto en mis últimos años de programador. De todas formas, yo sí que prefiero set_name antes que setName para establecer un "name" (¡no "Name"!).
3.- Yo no he dicho que tengas que mirar el código fuente para documentarte sobre una API. Las herramientas de documentación automática podrían documentar automáticamente determinadas cosas a partir de las declaraciones, sin necesidad de todos esos comentarios redundantes y palizas.
Por cierto, sí que sé Java (además de muchos, muchos, muchos otros viejos lenguajes). Y precisamente por esto me atrevo a cuestionar determinadas "convenciones".
1.- Conozco la regla de las mayúsculas - minúsculas. Aun así, veo más legible perico_de_los_palotes o pericodelospalotes que pericoDeLosPalotes. ¿Tú no?
No es por entrar al flame pero no, yo no. Y ahora tengo un problema porque claro, si trabajamos los dos en el mismo software...¿que hacemos? ¿trago yo con tu "convenio personal"? ¿tragas tu? ¿no tragamos ninguno y mezclamos todo?
2.- Personalmente, el exceso de getters y setters (y los beans) es la cosa más absurda que he visto en mis últimos años de programador. De todas formas, yo sí que prefiero set_name antes que setName para establecer un "name" (¡no "Name"!).
Pues yo no. Se llama el "principio de encapsulación" y permite acceder a los datos siempre desde el mismo punto. Así puedo meter validaciones, control de acceso, formateo, eventos, etc (vamos, lo que todo el mundo ya sabe). Si te molestan usa un IDE hombre, que te los genera...aunque claro get_name() no creo que te lo haga ninguno (es lo que tiene no usar los convenios)
3.- Yo no he dicho que tengas que mirar el código fuente para documentarte sobre una API. Las herramientas de documentación automática podrían documentar automáticamente determinadas cosas a partir de las declaraciones, sin necesidad de todos esos comentarios redundantes y palizas.
Lo mismo hombre, usa un IDE, que te lo genera automatico. Así luego, si tienes algo que no sea redundante o palizas que añadir puedes cambiarlo (cosa que no podrías hacer si siempre se generara el comentario redundante de forma automatica)
Hola Anónimo (este es mi último mensaje antes de que proporciones una forma de denominarte, no habrá más si no lo haces).
1 - Como dijo Pedro: no, no y no (y aun no ha cantao el gallo). Y como ves no soy el único. Y desde luego ahora en tu comentario parece tener más lógica la regla de nomenclatura de Java. Pero desde luego, usa lo que quieras, el compilador no se quejará. Otra cosa serán tus compañeros de trabajo o al que le toque mirarse tu código.
2 - " ¿O a ese "maravilloso" cambio a mayúscula de la primera letra de un nombre en los "getters" y los "setters"? " Eso fue lo que dijiste en tu primer comentario. Por eso deduje que no tenías mucha idea de Java, porque ese "maravilloso cambio" es LA MISMA CONVENCION que 1. Osea que repetías la pregunta que tiene la misma respuesta, hecho por el cual deduzco que realmente NO sabías la respuesta.
Y si, ahora dices que lo que te molesta es su proliferación, yo también te cambio de tema, y te digo que lo que a mi me molesta es la subida del petróleo. ¿Hablamos de ello? ;-) Pero desde luego, calificarlo como "absurdo" no me parece lo más adecuado.
Por cierto, de tu comentario vuelvo a deducir que hay otro convenio que no usas (o que pareces no conocer, y eso me extraña porque es BASICO): "las clases siempre empiezan con mayúscula, y los objetos con minúscula". Partiendo de ese convenio, todos los programadores Java que he conocido han entendido siempre que setName NO es dar valor a una variable llamada Name, porque ninguna variable puede empezar con mayúsculas (sólamente las constantes se escriben en mayúsculas).
3 - Mira, de nuevo empiezo a dudar seriamente de tus conocimientos sobre Java; porque Javadoc ES UNA HERRAMIENTA DE DOCUMENTACIÓN AUTOMÁTICA. Prueba un día a no meter esos "redundantes comentario" y produce el javadoc de esa clase. Fijate, oh sorpresa del 2008 (aunque lleva existiendo desde el principio de los tiempos), que javadoc documenta "automáticamente determinadas cosas a partir de las declaraciones, sin necesidad de todos esos comentarios redundantes y palizas."
¿Me quieres contestar a una pregunta? ¿Como es posible que alguien que "sabe Java" cometa en tan sólo dos comentarios tantos errores o que no conozca el uso más básico de las herramientas a su disposición? ¿Entiendes que dude (y bastante, después de este segundo post) de tus conocimientos REALES sobre Java? O tal vez... ¿crees saber de Java más de lo que sabes?
No sé, es totalmente lícito criticar una convención, pero la crítica debe tener algo de razonamiento o sustancia. Porque ya te digo: no hay nada más atrevido que la ignorancia.
Salu2
(No soy el anónimo al que respondes). Ibón, por muy "fanboys" de Java que seamos, hay que reconocer que no siempre es adecuado documentar en el código fuente. Ten en cuenta que documentar en el código fuente implica sacar una nueva versión (o sub-versión) cada vez que hay un cambio en la documentación, aunque éste sea muy pequeño. Por poner un ejemplo, yo trabajo en un organismo que tiene "externalizados" los servidores web, por lo que cada nueva versión implica un coste de despliegue; por este motivo, sólo ponemos en el código fuente aquellos comentarios que resultan imprescindibles a la hora de leer el código fuente; y la documentación la mantenemos en un wiki interno. Cambiando de tema, también hay que reconocer que los convenios de java sobre la utilización de mayúsculas han recibido y siguen recibiendo críticas por parte de muchos programadores, algunos de ellos gurús de Java. Pero dejando aparte todos estos flames, lo que si me parece fatal es que se critique una librería de Java por el simple hecho de no seguir los convenios de Java. ¿No sería preferible fijarse en si está bien o mal programada?
Anónimo 2 (en serio, ¿no te parece ridículo que me OBLIGUES a llamarte asi?),
Totalmente en desacuerdo contigo, y no sólo yo, si lees "Pragmmatic Programer" (uno de los libros que más han influenciado las "buenas prácticas" de las nuevas generaciones de programadores) verás que mantener la documentación separada del código fuente es una mala, mala, mala idea. Además como acabo de contestar antes: de acuerdo, no documentéis nada, JavaDoc lee la signatura del método y te crea una documentación básica. Osea que se puede usar Javadoc SIN meter la documentación en el código fuente. Pero vuelvo a decirlo: es una mala, mala, mala, malísima idea.
En el caso que tu comentas, la solución estaría en modificar el script de build (maven, ant o lo que sea) y comprobar que los cambios que ha habido han sido de documentación o de código. Con un diff y un poco de maña no cuesta tanto, seguro que hay algo hecho. Además, y este consejo ya es gratis, si tanto problema de despliegue tenéis, ese script de build podría además mirar más cosas: si el build necesita despliegue o no (porque un becario haya cambiado el nombre de una variable, no tendríais que hacer el despliegue).
No meter documentación en el código fuente para no tener que desplegar, a mi me parece una solución chapucera que a la larga puede ser catastrófica. Pero es mi opinión.
Respecto al convenio Java para la nomenclatura: a mi me gusta, y ninguna de las opciones que he visto me gusta lo más mínimo. Si me presentan una que me guste más, pues bienvenida. Pero sobre gustos no hay nada escrito, lo que si hay escrito es sobre ponerse de acuerdo para entenderse todos.
"lo que si me parece fatal es que se critique una librería de Java por el simple hecho de no seguir los convenios de Java"
Es que si algo tiene la ambición de ser una LIBRERÍA DEBE cumplir esos convenios para que la pueda usar cualquier programador Java: osea un Javadoc cuanto más detallado mejor. Porque mal que pese, mucha gente se ha puesto de acuerdo para entenderse. Y sino que la use Rita.
Salu2
Hola, Ibon:
1.- Siguen gustándome más las minúsculas que las mayúsculas, Y NO SOY EL ÚNICO.
2.- Ya sé que al hacer un setNombre se establece un elemento llamado "nombre", y que se utiliza setName en vez de setname (o SETname, o set_name) por las dichosas convenciones. ¿No te das cuenta de que son, precisamente, las absurdas convenciones sobre mayúsculas las que conllevan que haya que usar setName para establecer un "name"? La convención de mayúsculas en los setters y getters llega a ser tan absurda que no puedo usar un setter si, por cualquier cosa, alguien ha llamado Grrr a una variable y grrr a otra (seguro que me dices que eso no se debe hacer, pero ¿no hubiese sido más fácil que la convención hubiera sido set_variable o SETvariable o setvariable o SET_variable, en vez de setVariable?
3.- Tienes razón en lo del javadoc. La verdad es que como nunca lo he necesitado no sabía que puede documentar sin necesidad de comentarios (¡estoy tan acostumbrado a que los intrusivos IDEs te lo llenen todo de comentarios redundantes!). Pero sigo pensando en que es ridículo llenar el código fuente de comentarios pensados para el javadoc. Ya he visto que tú prefieres documentarlo todo en el fuente, y otro anónimo te ha dado una buena razón para documentar fuera del código fuente. Yo estoy de acuerdo con él: en el código fuente se deben poner solamente comentarios destinados a quienes vayan a revisar el código fuente en el futuro (sería, por ejemplo, absurdo comentar algo así: "incremento la variable i"). Documentar mediante comentarios en el código fuente es absurdo porque ¿cómo meter imágenes, diagramas, etc., que se necesitan en la documentación?
De todas formas, está claro que no vamos a ponernos de acuerdo. :-)
Es que para que nos pongamos de acuerdo como mínimo me tienes que dar algun motivo ;-)
1- Pues vale... pero porque no te guste no puedes calificarlo de ABSURDO. Eso es lo que realmente me molestó de tu comentario.
2- Vamos a ver: ¿es que no lo entiendes? De nuevo no puedo comprender que un programador que haya pasado al menos media hora con el código de otra persona no pueda llegar a entender el porqué las variables DEBEN escribirse en minúsculas. Si tú en tu código utilizas Grr en lugar de grr, cuando yo lo estoy estudiando y acordándome de tí (porque encima no vas a poner comentarios), en la línea 5678 de tu clase aparece Grr me obligas a pensar si es una Clase o es un Objeto. Imaginate:
metodoHazAlgoConEsto(Grr);
Cojonudo! Me dirás que Grr es un objeto? Pues no, porque si te vas al metodHazAlgoConEsto (que por supuesto estará en el culo del mundo de tu código) tienes que:
private void metodoHazAlgoConEsto (Class clase){
Pero siguiendo tu "convenio" (que no es un convenio sino más bien "haz lo que te salga del bul") voy a tener que ir subiendo, bajando, un pasito palante Maria por todo tu código para enterarme de que ese método recibe como parámetro una Clase.
Siguiendo ese razonamiento lo debes pasar bastante mal con el compilador cuando quieres crear un objeto File de la clase File... claro que para tí la solución debe estar en que Sun llame a la clase File file, o mejor fi_le... No sé como explicartelo: tal vez después de un par de leches que te darás seguro, te des cuenta.
3- Y dale con faltar: "intrusivos IDE's". Macho, apuesto 100€ a que no tienes NI PUTA IDEA de como configurar esos IDE's para que no sean "intrusivos".... pero por si acaso ya te estás cagando en ellos...
" otro anónimo te ha dado una buena razón para documentar" ¿Buena? ¿Has visto mi respuesta?
"en el código fuente se deben poner solamente comentarios destinados a quienes vayan a revisar el código fuente en el futuro (sería, por ejemplo, absurdo comentar algo así: "incremento la variable i")."
¿? Joder pues claro, que tiene que ver el comentario:
//incremento la variable i
con el javadoc? Macho, confundes churras con merinas muy fácilmente...
"Documentar mediante comentarios en el código fuente es absurdo porque ¿cómo meter imágenes, diagramas, etc., que se necesitan en la documentación?"
Mira te voy a contar un secreto: es que TU NECESITAS IMAGENES Y DIAGRAMAS PORQUE NO DOCUMENTAS EL CODIGO FUENTE CON JAVADOC. Eso lo primero. Lo segundo es que el javadoc es HTML y por tanto PUEDES INCLUIR LINKS a donde te de la gana. Y lo tercero. Documentar en el código fuente MIENTRAS se programa es la mejor opción porque:
a) La documentación SIEMPRE estará actualizada
b) La documentación SIEMPRE estará donde está el código fuente.
Si no te parece importante esto, es porque supongo que aún no has particpado en ningún proyecto de software con al menos dos personas involucradas. Es que me parece de perogrullo, pero bueno, tú verás.
Y no sigo más que estoy harto de hablar con un anónimo y esta discusión, no es ni siquiera una discusión.
Salu2 y adios
Yo odio los convenios de Java en cuanto a mayúsculas, y también odio el javadoc. ¿Soy por ello un mal programador? ¡No, no y no!
SI, SI y SI. Eres, perdona que lo diga, el PEOR tipo de programador ... Aquel del que nadie quiere heredar el código, aquel que se cree con capacidad para decidir que parte de un estandar seguir y cual no. De esos que dicen que el código es la documentación, de esos a lo que lo único que le interesa es que "funcione", de esos que NI SIQUIERA comunican con sus propios colegas, vamos una prima donna, un cowboy, un lone coder, un hacker (en el sentido de la chapuza) ... Estupendo si lo que haces es tu propio/a sistema/mierd@ o eres el lider de un grupo y FATAL si tienes que trabajar con alguien ...
Si, con tu experiencia, aun crees que toda convención debe ser a tu gusto ... Hay gente muy válida por ahí, que ha escrito cosas muy interesantes que nadie quiere usar porque decidió que no iba a seguir los convenios. Es la forma más clara de decir : me importa un c*rajo el resto del mundo. Y, ¿sabes qué? el resto del mundo decidió que ídem de ídem.
Lo anterior sí es algo muy claro de una parte del "ethos" (la ética?) de lo que es ser un "ingeniero". Por poner un ejemplo, UML (ó XML) pueden ser una mierd* para muchas cosas, pero en el momento en que en un proyecto, cada "artista" se dedica a usar su "variante" nos hemos cargado el proyecto ...
Es muy "guay" atacar un estandar, especialmente si: 1) Realmente no haces nada que use el resto de la gente (de esto te encuentras mucho en I+D, escuelas), 2) Tienes la capacidad de subvertir cualquier estándar: Microsoft. En cualquier otro caso, estas diciendo "soy un pardillo" o "no entiendo nada".
Pero sigue así, uno se cree muy superior cuando critica a los demás diciendo yo lo habría hecho mejor. Sólo hay una pequeña diferencia, ellos lo han hecho y tu seguirás siempre en el condicional ...
Firmado: Hasta los C@JONES de los que se creen por encima del bien y del mal ...
(el de los C@JONES)
Sobre otros lenguajes, plataformas:
Como sabes de muchos otros lenguajes, supongo que habrás reflexionado sobre porqué muchos de esos lenguajes, pese a su superioridad técnica en muchos aspectos o no han triunfado, o han dejado de usarse, o sólo se usan en nichos.
Sobre lo que le gusta a cada uno, a mí me encanta Scala pero soy consciente de que no va a sustituir a Java. Eso no me impide: aprenderlo, usarlo, programar mejor en Java como resultado. Pero de ahí a decidir que voy a cambiar la forma en que el resto programa en Java, va un abismo de "optimismo" y egocentrismo. De hecho, Scala sacrifica unas cuantas cosas, por mantenerse cercano y útil al código Java.
Es muy sencillo tomar un feature de un lenguaje y criticarlo de forma aislada (incluso los creadores de lenguajes con mayúscula) se dedicar a este innoble deporte ya sea por márketing o por saldar cuentas con la competencia. Pero ellos lo hacen sabiendo que lo que están haciendo no es más que algo de cara a la galería, para reforzar la moral de sus tropas. Ellos en el fondo sabes que la fortaleza de un lenguaje está, no en tener más features o las mejores sino en como están integradas y como se combinan entre sí. (Esto es un principio básico de diseño, de nada :) ).
Pero dejando aparte todos estos flames, lo que si me parece fatal es que se critique una librería de Java por el simple hecho de no seguir los convenios de Java. ¿No sería preferible fijarse en si está bien o mal programada?
Sobre la formación y lo que significa conocer una tecnología:
Eso depende, si lo que quieres es usar corta y pega con el fuente de la librería, supongo que bastaría. Pero claro, si lo que afirmas es que es una librería Java .... pues ya vamos mal. Insisto, el que programe para la máquina, que se lo mire porque quizá no debería estar usando Java. Si, como creo, es una librería creada por gente que forma a otros en Java tenemos un serio problema (no es nuevo, pero a estas alturas ya NO se debería tolerar).
Parte de la gracia de Java/Net es la capacidad-facilidad de manejar/integrar APIs y librerias de múltiples fuentes en, incluso, los proyectos más pequeños. (Faltan capacidades de modularidad aun, y lo de los "componentes" del 68 sigue aun en proyecto: para los amigos del condicional). Reflexiona un momento sobre la cantidad de código sobre la que te apoyas para realizar incluso cosas aparentemente sencillas en una plataforma de "managed code". Esto forma parte de la naturaleza del lenguaje/plataforma.
Hay gente que es incapaz de ver más allá de una sintaxis (algunos de ellos se ganan la vida enseñándola ...). Java a dado de comer a mucha de esta gente y estos, a cambio, han timado a sus "alumnos" enseñándoles sólo aspectos superficiales de la plataforma.
La superficialidad de la sintaxis es algo que se repite hasta la saciedad, pero la mayoría sigue sin verlo. La mayoría de las discusiones se acaban centrando en esta convención o la forma de escribir esto otro ... La esencia de LISP no son los paréntesis, es la equivalencia código-datos. Puedo criticar todo lo que quiera lo primero, pero si no he llegado a comprender lo segundo, no se LISP. (Y tampoco necesito ser un experto en lambdas para entender LISP, como otros, tirando por elevación elitista, tratan de vender)
En el desarrollo empresarial, te encuentras gente a paladas que tan sólo tiene un conocimiento superficial de la plataforma. Los buenos, lo reconocen, no van pontificando y tienen capacidad de aprendizaje y adaptación. Los malos, se dedican a subvertir y, en general, son de esos que reman hacia el otro lado y, encima, les tienes que aguantar que digan que el resto del mundo rema mal. En mi opinión, los primeros son "ingenieros" (y me da francamente igual si se sacaron su título, bastante mierda hay que comer en las escuelas para andarse con menudencias en una profesión no regulada). los segundos, a menudo, son de esa gente con productividad NEGATIVA para el conjunto.
Un consejo tipo Les Luthiers: Si la gente afirma que alguien es un gran programador, pero nadie quiere tocar su código: corre, tonto, corre !
JB
oops: a dado (si me leo, ¿que pasa?. Me leo porque pienso en LOS DEMÁS ;) )
Aunque se que la h es una convención que podría eliminar, de hecho, que puñetas, el español es una mierda, esta claro que sobra la h y la c (usemos k o z) y la v (usemos b) ...
De hecho, ¿porqué no estais todos hablando Esperanto?
JB
PD: Busca en google "simplify english"
Se te ha ido la olla.
Escribe tu comentario