Hola, como parte de la tarea de un curso que estoy tomando, nos dejaron resolver String Calculator y aquí comparto mi solución, la termine en poco tiempo, pero no en menos de 30 minutos la parte de probar las exceptions se me dificulto, se que con shouldFail de GroovyTestCase eso se pudo resolver, pero quise experimentar un poquito. Ya me dio flojera hacer que los delimitadores fueran mas complejos como por ejemplo [****].

Aquí les dejo unos código muy sencillos en este lenguaje.

Buenos Días a Todos.

De antemano felicitarlos por este gran foro. Mi inquietud es la siguiente, tengo que desarrollar un aplicación, utilizo un modulo EJB y una aplicación(Escritorio) común y corriente. y quiero utilizar persistencia de datos (JPA).

Pero estoy algo confundido sobre JPA, por lo que he leído en algunos Blog, es lento. Utiliza dos tipos de persistencia Leasy y Eager, una carga toda el mapeo de la base de datos, (que pienso que se consumiría todos los recursos) y la otra solo carga los datos de cada objeto sin mapeo.

También leí, que se podían obviar los dos anteriores y tener todas las clases sin que se cargue los datos en memoria.

Me gustaría saber cual es su punto de vista sobre este tema.

¿Creen que JPA aplicaría o seria lo suficientemente viable, donde una aplicación puede crecer a nivel de datos y tablas?
¿Hay alguna forma de utilizar persistencia de datos sin utilizar Leasy y Eager, es decir que no haga ese cargue de información en memoria pudiendola saturar, y si hay alguna forma como seria?

Gracias, y nuevamente felicidades por este foro.

En el Code Retreat que hubo en Agosto de 2012, el reto fue implementar el famoso Game of Life, en parejas. En mi equipo, @juwe y yo lo desarrollamos en Ceylon (no me impuse; él se animó, jejej).

Apenas hoy lo pude subir a un repositorio que tenemos en GitHub especialmente para ejemplos de Ceylon, después de darle una buena actualizada al código porque han habido varios cambios en la sintaxis y en el módulo de lenguaje desde que escribimos esto originalmente: ya teníamos comprensiones, funciones de orden superior, funciones anónimas y varias otras cosas, pero no teníamos por ejemplo el assert, tuplas, ni la sintaxis actual para secuencias y colecciones iterables; la sintaxis para funciones anónimas cambió ligeramente, al igual que la de parámetros variádicos (los famosos varargs).

fuente (http://www.primefaces.org/)
Equipo PrimeFaces se complace en anunciar la primera versión candidata de PrimeFaces 3,5. Esta versión cuenta con nuevos componentes, mejoras a los componentes existentes, el apoyo RTL, accesibilidad mejorada y más. En comparación con versión anterior principal 3.4, hay más de 175 mejoras + presentadas.

En breve estaré impartiendo un curso de Fundamentos del lenguaje de programación Scala, presencial "en línea", usando el sistema Webex Training Center, con todas sus posibilidades. Lo estaré ofreciendo en el horario de la tarde noche dos veces por semana con una duración de 30 horas (5 semanas). Los interesados pueden enviarme un correo a barbaro.ferro@gmail.com para conocer temas, precios y calendario.

De lo más relevante en ésta versión es la inclusión de lambdas y junto con ello nuevos conceptos como las interfaces funcionales.

Podemos decir que una interfaz se considera funcional cuando tiene un método abstracto sin implementación. La intención es crear un contrato o una “forma” de como será una expresión lambda para que el compilador cuente con información suficiente al momento de aplicarla, dicho de otra forma, es el tipo de datos de la expresión lambda. ¿Por qué?. Bueno, en Java las expresiones lambda son como cualquier otro objeto y como tal, también necesitan un tipo de datos. Por ejemplo, el siguiente programa traduce e imprime una palabra de español a inglés usando lambdas.

El año que acaba de concluir fue bastante lento para Ryz, la razón es que me pasaron muchas cosas.

- Cambié de trabajo para entrar a Knowtion y esto me absorbió la mayor parte de mi tiempo libre.
- La otra gran parte de mi tiempo libre me la pesé haciendo otras cosas que me hacían mucho, mucho, pero muucho muy feliz.

Estuvo bien, no hay queja. El objetivo de Ryz no es competir contra los otros lenguajes, ni siquiera contra Java mismo, no hay prisa.

En el 2012 lenguajes existentes y nuevos han ido consolidando algo que pretende hacer Ryz, simplificar el uso de Java. Java 8 incluirá closures finalmente, IDE's como Intellj IDEA 12 ya tienen soporte para ello. La comunidad (al menos en la que me encuentro) tiene ya bastante familiaridad con el uso de bloques y la programación funcional está empezando a consolidarse como paradigma al lado de la POO. Hay al menos un lenguaje con tipado estructurado que está siendo usado con éxito en producción actualmente. Todos hablan ya de Smalltalk y así por el estilo. Mucho e esto estaba en la base de Ryz, mucho solo en mi cabeza.

Encontré esta comparación de lenguajes que me parece interesante compartir.

http://research.google.com/pubs/pub37122.html

No estoy muy acostumbrado a leer este tipo de documentos, pero encuentro bastante entretenido aunque sea solo ojearlo y ver los dibujitos.

Una cosa que encuentro es que en Scala se puede escribir con mucho menos código, pero que esa brevedad se transmite muchas veces al tiempo de ejecución, es decir debes de verdad saber que estás escribiendo y que impacto tiene ahorrarse algunas lineas de código, claro ejemplo los for-comprehensions que Ezamudio ya explicó por acá anteriormente.

Voy a seguir viendo las figuritas, se ve bastante interesante.

Les dejo la conclusión (ya todos saben que no hay que hacer caso a estas conclusiones verdad? bien)

Hemos implementado un algoritmo compacto bien especificado
en cuatro lenguajes, C++, Java, Go y Scala, y evaluado los resultados
en varias dimensiones, encontrando factores de diferencia en todas las
areas. Hemos discutido varias optimizaciones subsecuentes especificas
a cada lenguaje que nos indican puntos débiles comunes en el desempeño
de cada lenguaje.