style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Concurrencia sin dolor en Java puro, parte 3

En el post anterior ya vimos una alternativa muy buena para manejo de concurrencia en Java: el modelo de STM.

En esta tercera y última parte, veremos el modelo de actores. Esto es algo que tampoco es nuevo, viene de otros lenguajes; en la JVM, Scala es un lenguaje que incluye este modelo de concurrencia. Pero gracias a una biblioteca llamada Akka, la cual fue escrita en Scala, podemos usar el modelo en Java.

Visto de una manera muy simple, un actor es un objeto que responde (o reacciona) a mensajes que se le envían, uno a la vez. Los mensajes se le pueden enviar de manera asíncrona, un mecanismo conocido como fire-and-forget, por lo que puede haber varios hilos distintos enviando mensajes al mismo actor y dichos mensajes serán encolados para que los vaya atendiendo uno por uno.

Conceptualmente, el actor corre en un solo hilo. Pero no siempre tiene que ser el mismo hilo; los mecanismos que despachan los mensajes a los actores administran los hilos para los mismos, de la manera más eficiente posible, de modo que puede haber muchos más actores que hilos disponibles. Similar a un restaurante en donde hay más mesas y comensales que meseros; un comensal es atendido por un mesero a la vez, pero no necesariamente debe ser el mismo siempre.

Un ejemplo simple de un actor en Java, utilizando Akka, es como sigue:

public class Actorcillo extends UntypedActor {
  public void onReceive(Object msg) {
    if (msg instanceof String) {
      System.out.printf("[%s] Me mandan cadena: %s%n",
        Thread.currentThread().getName(), msg);
    } else {
      System.out.printf("[%s] No sé qué hacer con mensaje: %s%n",
        Thread.currentThread().getName(), msg);
    }
  }
}

Basta con extender la clase UntypedActor e implementar el método onReceive. En caso de que un actor pueda procesar distintos tipos de mensajes, habrá primero que detectar qué tipo de mensaje es para procesarlo. Es aquí donde se queda corto Java, comparado por ejemplo con Scala en donde se aplica el pattern matching para identificar y procesar distintos mensajes. Sin embargo aquí no tenemos que manejar ningún tipo de ciclo ni nada parecido; Akka invocará el onReceive de nuestro actor desde un hilo, un mensaje a la vez. Veamos ahora el código para crear el actor y enviarle mensajes:

//No lo instanciamos directamente, usamos una fábrica
ActorRef actor = Actors.actorOf(Actorcillo.class);
//Esto es para que empiece a escuchar mensajes
actor.start();
//Así enviamos mensajes de manera asíncrona
actor.sendOneWay("Mensaje");
actor.sendOneWay(new BigDecimal("1.00"));
//Y así le decimos que ya no procese más mensajes
actor.stop();

Cuando invocamos sendOneWay, el mensaje que pasamos como parámetro se encola para enviarse al actor y el método retorna de inmediato. El mensaje será procesado por el actor en un hilo separado. Si ejecutamos este código, obtendremos algo como esto:

[akka:event-driven:dispatcher:global-1] Me mandan cadena: Mensaje
[akka:event-driven:dispatcher:global-1] No sé qué hacer con mensaje: 1.00

Si metemos una pausa entre ambos mensajes, entonces nos damos cuenta que cada uno fue procesado en un hilo diferente:

[akka:event-driven:dispatcher:global-1] Me mandan cadena: Mensaje
[akka:event-driven:dispatcher:global-2] No sé qué hacer con mensaje: 1.00

Esto significa que Akka se está encargando de administrar los actores, las colas de mensajes de los actores, y los hilos que se usan para que los actores procesen sus mensajes. En el primer caso, enviamos dos mensajes uno tras otro, sin pausa alguna, por lo que Akka le mandó los dos mensajes al actor en el mismo hilo, pero los procesó de manera secuencial. En la segunda ejecución, puse una pausa de 300 milisegundos entre el primer y el segundo mensaje (un simple Thread.sleep(300)) y entonces ocurrió algo distinto: Akka le asignó un hilo al actor para procesar el primer mensaje, y como no había más mensajes en la cola, liberó el hilo. Posteriormente hay un segundo mensaje encolado para procesar, y entonces Akka usa un hilo distinto para que el actor procese este segundo mensaje. Esto significa que Akka tiene un pool de hilos para procesar los mensajes, pero nosotros ya no tenemos que preocuparnos por todo eso, que además es parametrizable y se puede configurar según las necesidades de nuestra aplicación.

El Dr. Subramaniam nos mostró un ejemplo donde tenía un objeto que iba por un dato a Yahoo (el valor de una acción en la bolsa), y lo pasaba a un actor para que determinara el mínimo y el máximo de los valores recibidos. Posteriormente, mandó pedir los valores de 50 acciones distintas, de manera secuencial, enviando cada valor al actor, para tomar el tiempo total de ejecución. Y finalmente utilizó un ThreadPool de Java 5 para pedir todos los valores de manera simultánea, en 50 tareas separadas, y cada tarea le enviaba el resultado al actor. El tiempo de ejecución fue dramáticamente menor (26s vs 1.6s).

Para poder implementar este tipo de funcionalidad utilizando sólo las facilidades que nos ofrece, incluso con menos eficiencia, necesitaríamos un hilo dedicado para el actor y una cola donde se pongan los mensajes(LinkedBlockingQueue por ejemplo), pero para poder usar pocos hilos para atender a varios actores ya se complicaría mucho la implementación. Usando Java 7 podríamos sacar provecho del Fork/Join Framework que incluye esta nueva versión.

Conclusión

No es fácil hacer aplicaciones concurrentes; no sólo por los problemas que pueden salir y los errores que pueden ocurrir, sino también me refiero a que realmente puedan aprovechar al máximo los CPU's disponibles, es decir, hacer aplicaciones que utilicen paralelismo para realmente mejorar su desempeño. Pero tampoco tiene que ser tan difícil... si bien el JDK nos da algunas opciones, pueden resultar demasiado complejas para su uso directamente en aplicaciones; son más bien útiles para construir soluciones como las otras dos alternativas que nos presentaron.

El modelo de STM facilita bastante la modificación y lectura de datos compartidos por varios hilos, sin tener que estar manejando directamente candados/semáforos, bloquear hilos, etc. Y el modelo de actores nos facilita el envío de mensajes asíncronos a objetos que necesitan realizar varias tareas de manera secuencial.

No se trata de abrir las aplicaciones existentes y reescribir todo el código que use synchronized y Locks y cosas así; se trata de conocer estas opciones para que a partir de ahora tengamos más herramientas a nuestra disposición para poder manejar concurrencia. El consejo final del Dr. Subramaniam fue que hagamos lo posible por no seguir programando en Java; la plataforma Java es una plataforma excelente, pero el lenguaje, aunque sigue siendo bueno, ya no es la mejor opción, por diversas razones en las que no voy a profundizar aquí porque no es el tema de la serie. Sin embargo, sabiendo que hay numerosas y diversas restricciones en los ambientes de trabajo actuales, como la resistencia al cambio por parte de los mismos programadores, de los líderes de proyecto, project managers, directivos, clientes, y temas de compatibilidad, etc, es una realidad que muchos no pueden simplemente dejar el lenguaje, y entonces lo recomendable es no manejar concurrencia sólo con las herramientas que ofrece el JDK, que son demasiado rudimentarias, sino utilizar las alternativas que existen; aquí nos presentaron dos, pero seguramente hay o habrá más en el futuro.

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Sr. Negativo

El consejo del Dr. Subramaniam

"El consejo final del Dr. Subramaniam fue que hagamos lo posible por no seguir programando en Java; la plataforma Java es una plataforma excelente, pero el lenguaje, aunque sigue siendo bueno, ya no es la mejor opción.."

Triste realidad. Pero, tal vez algún día tendremos que migrar a otro lenguaje.

Siempre había pensado que Java no fue pensado, por poner un ejemplo, para la web. Por eso hay tantos problemas que requieren otras alternativas.

?:(

Imagen de bferro

Otro consejo muy radical

El consejo de Subramanian de no continuar programando en Java no es nuevo. Son muchos los que nunca han aceptado a Java como el lenguaje más adecuado y proponen el uso de C++ y otros lenguajes. Entre esos muchos se destacan aquellos que consideran que la programación funcional es la cura de todos los males.

En computación, como en otras disciplinas, no siempre se utiliza lo mejor. El lenguaje que se impone en el mercado se impone por muchas razones, entre ellas razones técnicas, decisiones políticas de las empresas y un sin número de cosas que resulta difícil a veces entender porque la industria selecciona un lenguaje y no selecciona otro.

Por supuesto que el lenguaje que se impone tiene que muy bueno, y ese es el caso de Java, lo que no quiere decir que sea el mejor lenguaje para todo.

Yo en lo personal, en este momento (no se que pasará en 10 años), no comparto para nada el consejo de Subramaniam, y creo que su mensaje debe interpretarse en otro sentido, y ese sentido es, que como profesionales de la computación debemos preocuparnos por aprender varios lenguajes y estar al tanto de las tendencias, sin la necesidad de tomar decisiones radicales. Gente muy destacada de la computación coincide en que un buen diseñador debe conocer varios lenguajes y ser experto en al menos dos o tres de ellos, y que esos dos o tres sean de diferentes paradigmas.

No aconsejaría jamás a alguien experto en Java a que no continúe con ese lenguaje y que de manera abrupta decida hacer borrón y cuenta nueva de un día para otro y abandonar toda la expertisidad (ya se que la palabra no existe) que tiene en Java. Es el lenguaje más utilizado en la actualidad, de eso no hay duda y uno de los lenguajes que más arsenal tiene de proyectos de código abierto.

Imagen de ezamudio

y eso es lo importante

Nuevamente: la frase surtió efecto. Ningún experto en Java en su sano juicio hará Java a un lado de manera abrupta para comenzar de cero. Pero si el consejo en la conferencia fuera "a ver si pueden, algun dia, echarle un ojo a otros lenguajes" entonces nadie sale con ganas de aprender nada. Estas cosas hacen que la gente salga muy motivada pero esa motivación se diluye rápidamente; si no es suficiente, no da ni para que alguien se baje el kit de Scala o Groovy para verlos en un rato libre.

Y en cuanto al arsenal de proyectos de código abierto, precisamente es una de las razones para seguir en la JVM: al usar Groovy, Scala, JRuby, Clojure, etc, se puede seguir aprovechando ese gran acervo que existe.

Mi visión muy ingenua y optimista es que lo ideal sería que los nuevos ya no usen Java de manera directa; que aprendan el lenguaje pero nomás por encimita y se pasen pronto a otro de los lenguajes de la JVM. Java no desaparecerá, pero se convertirá en el lenguaje que se usa para las cosas de infraestructura y esas partecitas que conforman menos del 10% de un sistema que requieren muy alto desempeño y muchísima optimización. Similar a lo que pasa hoy con C++ y Objective-C, que de repente echan mano de algunas rutinas escritas directamente en C. C no ha desaparecido ni desaparecerá, pero ya prácticamente no se usa para aplicaciones, es más de infraestructura. Así tal vez le suceda a Java, dentro del ámbito de las aplicaciones empresariales será el lenguaje que se usa muy de vez en cuando para hacer código muy optimizado en una aplicación que corre sobre la JVM.

Imagen de Nopalin

Sobre comentarios

Los comentarios que hace el señor Subramaniam se me afiguran tan radicales como los de la iglesia católica (no espero crear polémica, solo es un ejemplo) donde tienes que irte al extremo para como dice @ezamudio "surtir efecto".

Imagen de bferro

Claro que es importante el uso de otros lenguajes

Enrique tiene razón cuando comenta acerca de la motivación. Lo que sucede es que a veces la motivación va acompañada de la exageración. Es una estrategia de la mercadotecnia.
Mi comentario anterior puede complementarse diciendo que seguramente si invitamos a otro ponente de la calidad de Subramaniam, y partidario de continuar con el uso de Java, su consejo sería que siguiéramos con Java, argumentando que después de Dios, está Java.
Soy de los que tratan de aceptar las novedades sin prejuicio. En el año 1996 impartía clases de maestría en el Centro de Investigación en Computación. Una de las materias que me tocaba era "Diseño y programación orientada a objetos" para la cual venía utilizando C++ como lenguaje de implementación. Decidí en 1996 cambiar a Java, a solo un año de la salida de ese lenguaje.
Cuando impartía la materia de Arquitectura de Software en el Tec, uno de los tópicos era el Diseño de Marcos de Trabajo y también cambié de Struts a Spring a los pocos meses de la salida de este último. Este semestre imparto una materia de maestría en la Fundación Arturo Rosenblueth y la estoy impartiendo usando Scala como lenguaje para explicar la técnica orientada a objetos y estudiar como la programación funcional no está reñida con la programación orientada a objetos.

Ni Groovy, ni Scala, ni Clojure ni JRuby han demostrado una superioridad relevante frente a Java para diseñar y construir muchos diversos tipos de aplicaciones y no solamente infraestructura.

Lo que sucedió entre Java y C++ no se ha dado en estos lenguajes, por lo que quizá va a pasar más tiempo para que ocupen el lugar de Java. Groovy aporta pocas cosas novedosas radicales. Scala Y Clojure sí aportan cosas muy poderosas dada sus raíces en la programación funcional, pero también su curva de aprendizaje es mayor para casi la mayoría de la gente que programa en Java y que no han tenido contacto con el paradigma funcional.

Por supuesto que considero importante entrarle a otros lenguajes, siempre y cuando se usen las cosas nuevas de esos lenguajes y no un mero cambio de sintaxis. Pero si me preguntan si se debe seguir enseñando Java mi respuesta es Sí.

Imagen de ezamudio

Scala

Por cierto, seguimos esperando los siguientes posts en la serie de introducción a Scala, nos dejó muy picados con el primero...

Imagen de Marce

comparto la misma idea

comparto la misma idea de @ezamudio de trabajar con java un rato y después pasarse a otro lenguaje de la misma JVM, y al igual creo que java es un buen lenguaje para comenzar a programar, creo que es un lenguaje base y formativo, el que te abre las puertas a la programación, te da buenas prácticas para desarrollos integros y de cierta forma pequeños y una ves que conoces lo fundamental de java y la jvm es un buen momento para cambiar a otro lenguaje que te enriquezca en diferentes paradigmas y te facilite lo que ya sabes: "programar".
Realmente no me imagino aprender a programar en groovy o scala y no por que sean malos lenguajes ni nada de eso, más bien los considero como el siguiente paso a java, lenguajes que te ayudan y te hacen más fáciles las cosas, que mejoran notablemente todos esos conceptos que uno aprende al iniciar a programar y que por ende ya tomaron lo mejor y lo peor de java, aprendieron de los errores y van en crecimiento actualizandose. Y al igual que @bferro le doy su mérito a java de dar una estructura sólida a un proyecto.
NO, no creo que debamos dejar de programar en java pero si echarle un ojo a otros lenguajes :) es un gran consejo!

Imagen de ezamudio

comenzar? no

Yo no creo que Java sea un buen lenguaje para comenzar a programar. Si hoy tuviera que dar una clase de programación a gente que nunca ha programado, usaría más bien ruby o Groovy o python o algo así. No Java ni Scala.

No me queda claro

Por un lado tenemos gente que te dice: "Pues la verdad, Java ya no está chido ni está avanzando, cámbiate". Y por otro lado está la gente que dice: "Java jamás pasará, al menos no en los próximos 10-15 años."

Lo que yo digo es, si Java no avanza no tienes que dejar la plataforma y dejar o adoptar tal o cual lenguaje de la JVM es decisión de cada quien. Así cómo también influye el gusto.

A cómo yo lo veo, considero que Java puede ser la entrada al mundo de la programación (y la programación orientada a objetos) porqué es un lenguaje que tiene muchas cosas de otros lenguajes 'clásicos' (C/C++ principalmente).

Ahora, para aplicaciones, pues. La verdad si bien es cierto que la gente prefiere otros lenguajes menos duros y más simples (se me ocurre PHP), debemos tener en cuenta que es algo ridículo hacer afirmaciones del tipo de: "Procuren cambiarse de Java a otro lenguaje", y más aún cuando cómo bien comenta el Doctor Ferro, si este lenguaje aporta solamente sintaxis y no otro estilo/paradigma.

Para terminar, me gustaría decir que pues si todavía hay aplicaciones (e infraestructura) funcionando en Java 4, mod_perl 2, CORBA, COBOL, etc. ¿Qué nos dice que no tenemos Java para rato?

PD: Cabe mencionar que no estoy muy a favor de Java, principalmente porqué el lenguaje en si es algo farragoso (y más si hablamos de las 'well-known-enterprise applications'). Sin embargo siendo realistas, es bueno saber Java, porqué la verdad yo batallé mucho para aprender Java (cómo se debe, con su orientación a objetos y demás), pero por ejemplo ya no batallo para aprender Groovy o Ruby o Python (bueno, de éste último me falta aprender a usar su lado funcional). Con Scala estoy batallando porqué en mi vida he tenido contacto con la programación funcional, pero en el camino voy.

Imagen de bferro

Objects first?

Resulta complicado resumir en un post lo que desde hace años se discute en la comunidad académica acerca de que enfoque utilizar para los primeros cursos en computación. La discusión se enmarca en el debate conocido como: "imperative first, objects first, functional first, breadth first, algorithms first and hardware first". El problema, más que el lenguaje es la selección del enfoque correcto. El lenguaje en este caso pasa a un segundo plano.

Buscar la solución perfecta resulta imposible. Hay mucho del pensamiento de los defensores de cada enfoque y no es nada sencillo ponerse de acuerdo. También depende mucho del tipo de universidad.

Coincido con Enrique que Java no es el lenguaje ideal para los primeros cursos de computación, aunque como mencioné con anterioridad creo que es bueno enseñar Java, como también creo que es bueno enseñar C++ y otros lenguajes funcionales.

Para un primer curso de computación Java resulta "algo" complejo. ¿Cuántos conceptos debo enseñar para escribir Hola Mundo? Estoy obligado a introducir el concepto de módulo ( la clase), a explicar varias palabras reservadas del lenguaje que no aportan nada a lo que deseo en ese momento explicar y varias cosas más, que por ejemplo, no tendría que explicar en un lenguaje procedural como el lenguaje C, y ni que decir de los lenguajes que en este foro se discuten.

¿Cuál lenguaje usar? Basta un vistazo a lo mucho que hay publicado (un googlazo de "objects first" es suficiente) para darnos cuenta que nadie y todos tienen la razón

Imagen de Nopalin

Ya llevo varios años

Ya llevo varios años trabajando con java, he vistro otros lenguajes de la jvm pero nunca he profundizado tanto como en java. Eh visto comentarios de todo tipo desde aquellos que dicen que .NET es mejor que la jvm hasta aquellos que dicen que la jvm sobreviriá pero java no. Y despues de analizar todos los comentarios yo sigo sin entender realmente de lo que hablan.

¿Hay aqui alguien que me pueda explicar por que los nuevos lenguajes son superiores a Java?. Yo sé que Java no implementa muchas funcionalidades de forma nativa, pero yo no creo que eso sea impedimento para crear sistemas robusos y grandes, así como concurrentes o paralelos. Basta con que alguien se anime y cree una libreria para ello. ¿Cual es la diferencia que sea nativo o forma de 3rd party?

Hasta donde yo puedo entender podemos seguir programando en ensamblador y con el mismo resultado, probablemente hasta mas optimizado. Yo no utilizo ensamblador por lo engorroso que es y los largos archivos de codigo que hay que escribir. Pero eso ya es syntactic sugar, no es algo técnico o algo que pueda hacer en Java y en ensamblador no.

Scala implementa muchas funciones de forma nativa y su paradigma de resolver problemas es distinto al de Java, pero ¿eso lo hace mejor o superior a Java?

Yo no estoy a favor al 100% de la frase de: "aprender en Java y luego pasarse a otro lenguaje de la jvm", yo la modificaria a: "aprender en Java y continuar aprendiendo nuevas cosas", ya que en la primer frase tiene de forma implícita "desechar" y no "complementar" que es lo que entiendo en la segunda.

Pero bueno, se que a muchos les gusta (que como me han hecho notar en este mismo sitio, gustar no es lo mismo que verdad) la forma mas simple de escribir de otros lenguajes, y están en su derecho, asi como habemos otros que eso no nos gusta y preferimos la forma verbosa de Java.

Sobres

Imagen de ezamudio

buen punto

Hasta donde yo puedo entender podemos seguir programando en ensamblador y con el mismo resultado

Creo que la cosa va por ahí. Esa frase es una gran falacia. No importa qué tan experto seas programando en ensamblador, no vas a tener la misma productividad que programando en uno de los lenguajes modernos como Java (estamos hablando de aplicaciones aquí; no puedes hacer programación de sistemas con Java). El ciclo de desarrollo es muy distinto (codificar, compilar, probar, integrar, etc) y ni hablar de todas las facilidades que te ofrece la JVM como la recolección de basura, el modelo de hilos, toda la biblioteca de clases básicas, etc.

Una cosa es innegable: entre más código escribes, más defectos vas a tener. Existe una cosa que es la densidad de defectos: el número de defectos que metes en tu código por cada mil líneas de código que tecleas. Necesitas todo un proceso estadístico muy tedioso para conocer tu densidad de defectos (con PSP la obtienes, junto con otros datos), pero se supone que el promedio varía de 15 a 50 defectos por KLOC (1000 Lines Of Code). Por lo tanto, entre menos código escribas, la lógica dicta que menos defectos insertarás en el código. En la realidad la densidad de defectos de una misma persona puede variar por diversos factores, uno de ellos obviamente la experiencia en la plataforma utilizada: tu primer programa en Java inevitablemente tendrá muchísimos más defectos que tu centésimo programa.

Pero pues la cosa es que una vez que te vuelves tan competente en un lenguaje más breve como lo eres en Java, tu densidad de defectos puede mantenerse igual, pero la cosa es que si para hacer una aplicación escribirás un número total menor de líneas de código que si lo hicieras en Java, el total de defectos que metiste inicialmente es menor.

Y otra cosa que pavonean mucho los lenguajes alternos de la JVM es la claridad o expresividad del código. No nada más se trata de escribir menos código, sino de que quede más legible, más entendible, más elegante. Un ejemplo en los 3 lenguajes que conozco de JVM:

HashMap mapa =//un hashmap que contiene o no contiene un valor para cierta llave
UnObjeto a = datos.get("llave");
OtroObjeto meta = null;
if (a != null) {
  Intermedio b = a.consigueUnB();
  if (b != null) {
    meta = b.consigueC();
  }
}
if (meta != null) {
  meta.hazAlgo();
}

Algo verborreico, no? Se entiende, pero pues es como cuando le preguntas a alguien cómo llegar a un lugar cercano y te describe las grietas en el piso de la banqueta que verás durante todo el trayecto...

Se puede un poco más conciso en Java, tal vez sacrificando un poco la legibilidad:

HashMap mapa =//un hashmap que contiene o no contiene un valor para cierta llave
Intermedio b = mapa.containsKey("llave") ? mapa.get("llave").consigueUnB() : null;
OtroObjeto meta = b == null ? null : b.consigueC();
if (meta != null) {
  meta.hazAlgo();
}

Ahora veamos un par de variantes en Groovy:

HashMap mapa =//un hashmap
UnObjeto a = datos["llave"]
OtroObjeto meta = a?.consigueUnB()?.consigueC()
meta?.hazAlgo()

//O en una sola línea
datos["llave"]?.consigueUnB()?.consigueC()?.hazAlgo()

Groovy tiene un operador condicional: a?.b() significa que se invoque el método b() del objeto a, siempre y cuando a no sea null. Muy breve, muy conciso, y pues tal vez no sea precioso el código pero se entiende, una vez que sabes de este operador condicional.

Y en Scala se puede hacer algo así, gracias a que los mapas devuelven una monería llamada Option, que es como un contenedor de un valor que puede indicar si trae valor o si trae nada, y al pattern matching:

val mapa:HashMap = //el mapa
val b = mapa.get("llave") match {
  case Some(a) => a.consigueUnB()
  case None => null
}
if (b != null) {
  val meta = b.consigueUnC()
  meta.hazAlgo()
}

Ah pero si le sabes un poquito más a Scala (porque tomaste un curso, o leíste un libro, o investigaste lo suficiente, etc) sabrás que el Option tiene un método map, que es muy útil porque le pasas una función la cual se ejecuta con el contenido del Option como parámetro, pero sólo si el Option es un Some; si es None, no se hace nada, se devuelve None:

val mapa:HashMap = //el mapa
mapa.get("llave").map(_.consigueUnB()).map(_.consigueUnC()) match {
  case Some(meta) => meta.hazAlgo()
  case None => println("no hubo objeto meta")
}
//O en una sola línea
mapa.get("llave").map(_.consigueUnB).map(_.consigueUnC).map(_.hazAlgo())

En la segunda variante, le pides el valor al mapa, y obtienes un Option, que puede ser None o puede ser un Some que contiene una instancia de UnObjeto. Si es el Some, se invoca el método consigueUnB() del UnObjeto y el resultado será un Some con el resultado (una instancia de Intermedio); a ese Option se le invoca map y si contiene el Intermedio, se invoca el método consigueUnC de ese objeto y el resultado será un Some que contiene un OtroObjeto; y finalmente a ese Some se le invoca map, que ejecuta el método hazAlgo() sobre el OtroObjeto; el resultado de eso será un Option pero se desecha ese resultado.

Este estilo se ve medio raro pero se conoce como declarativo, a diferencia del estilo en Java que es más imperativo. En Java escribes código describiendo exactamente lo que tiene que hacer, mientras que en Scala es más como indicar lo que quieres que ocurra, el resultado al que quieres llegar. Cada uno tiene sus ventajas y desventajas.

Por supuesto que todos estos paradigmas los puedes ver como simple azúcar sintáctica de Java o de OOP o del mismo bytecode. Pero la cosa es que en la práctica, muchos de los problemas actuales se resuelven de forma más simple (ojo, no estoy diciendo que mejor o peor) con estos lenguajes. La concurrencia es más sencilla de manejar en Scala por la cosa de los actores, pero por supuesto puedes seguir usando Threads directamente y Runnables y ThreadPools. Lo que sí ayuda mucho es la facilidad para la inmutabilidad; una vez que tienes código donde ya no hay un solo var, o si acaso tienes un var local pero ya casi todo es puro val, sabes que ese código será más robusto en un ambiente concurrente, que si tuvieras todo mutable (puras variables NO marcadas como final en Java, por ejemplo).

Imagen de Nopalin

Creeme que yo no soy el

Creeme que yo no soy el grinch de lo otros lenguajes de la jvm, estoy conciente que si surgieron es por algo y que ayudan a resolver problemas de una forma mas sencilla y simple ciertos tipos de problemas, así como en su tiempo lo hizo la OOP contra la modular.

Pero recordando lo que alguna vez dijiste sobre las bases de datos sql y no sql: es absurdo hacer un página web siguiendo el modelo de facebook pensando en que tu sistema va a tener millones y millones de peticiones y no importa si sacrificas consistencia por velocidad. En este punto siento que es algo similar, pensando en que todos nuestros sistemas van a ser paralelos y de alta concurrencia.

Y con respecto a lo otro que comentaste de mientras mas lineas de codigo mas errores, ciertamente tendrán razón, pero no se tu, de todos los programadores buenos que conozco, la mayoria no se equivoca sintácticamente (menos en estos tiempos donde el IDE ayuda al 100% en ese sentido), se equivoca en la lógica de un método (o en el algoritmo o en su implementación) y ahi ya no importa si lo hiciste en 20 lineas o en 5.

Sobres

Imagen de ezamudio

sí importa

Tienes razón, los errores no son sintácticos. Pero sí existe una gran diferencia entre un algoritmo o algún bloque de código que realice una tarea, hecho en 5 líneas o en 20. Es más difícil que hayas insertado un defecto en 5 líneas, pero si ese fue el caso, es más fácil depurarlo. Estamos hablando de casos en que una simple ojeada al stack trace no es suficiente, te da el síntoma pero no la causa del problema, y tienes que revisar una o varias clases o hacer un step con el debugger, etc.

Y como dije también, no sólo se trata de escribir menos código, sino de que sea más legible. Aunque mentalmente un programador con mucha experiencia ya puede filtrar los puntos y comas y tantos paréntesis, no debemos olvidar que casi siempre habrá gente con menos experiencia que tendrá que mantener ese código y por eso es importante que quede bien claro.

Imagen de Sr. Negativo

Java forever

Si, me deje levar por la "sugerencia" del Dr. Subramaniam jaja . Bueno ya que.

Imagen de HugoRmz

Wow wow wow

En serio WOW !! un semestre estudiando POO en Java sin entender threads ni sincronizaación y ahora (creo) que lo he entendido, muchas gracias !!

PREGUNTA???

E leido este post y me parece muy interesante, si dicen que java es el presente pero no el futuro cual es la sugerencia para para considerar en un futuro??
Que se deberia considerar para una alternativa a java para realizar aplicaciones empresariales?

saludos
fernando

Imagen de ezamudio

Algun otro lenguaje JVM

Ya hay varios lenguajes que puedes usar para programar sobre la JVM: Groovy, Scala, JRuby, Clojure creo que podrían ser los principales.

Eso de que Java no es el futuro... como yo lo veo, la JVM es una excelente plataforma para aplicaciones empresariales. El problema está en el lenguaje Java, no la plataforma (la JVM). Para hacer aplicaciones hoy en día, el desarrollo en Java llega a ser muy tedioso, en mi opinión porque a veces es de demasiado bajo nivel. Idealmente (al menos para mi), Java debería ser un lenguaje que solamente se utilice para implementar algunas cosas que requieran muy buen desempeño, control muy granular de memoria o de recursos, optimizaciones para velocidad, etc, pero eso es casi para puras bibliotecas y cosas de infraestructura; para aplicaciones es mejor usar uno de los otros lenguajes.

Si prefieres tipado dinámico y la posibilidad de hacer metaprogramación y un poco de programación funcional, Groovy es una excelente opción (también puedes seguir usando tipado estático en Groovy si prefieres).

Si prefieres seguir con tipado estático y la posibilidad de hacer programación funcional, Scala es la opción (puedes hacer OOP pura con Scala, pero creo que no le sacas tanto provecho).

Cuando los programadores eran hombres ....

Dice la leyenda que cuando los programadores eran hombres programaban con tarjetas perforadas ... Java sin duda no es la panacea, pero de que es protagonista lo es, lenguajes van, lenguajes vienen, pero solo los fuertes prevalecen, por ochorrocientasmil razones que ya se han expuesto anteriormente, así que Java tiene para rato, para mucho rato, recordemos que es solo una jovencita que va a cumplir sus 17, encasillarla a proyectos de infraestructura no me parece del todo justo. En mi humilde opinión muchos de los lenguajes nuevos solo embrutecerán más a los nuevos programadores que no comprendan como funcionan, podrán entenderlos y escupir código cuales monitos de feria, pero si no los comprenden (en su mayor parte posible) de mínimo, por ambiguo que parezca , creo yo, no servirá de mucho ... Si, escribirás menos líneas, bla, bla, etc, etc ¿ y ? , ¿la industria se va a volver más millonaria de lo que es , y en función de eso pagará mejores sueldos?, ¿el mundo va a ser mejor ?. Yo no digo que no se aprendan , o que no se usen ... pero de ahí a que diga que se deje de usar tal o cual cosa por mis traumas emocionales, para quizá rematar con que son los lenguajes que salvarán al mundo, pues la neta NEL !!!.

en la pagina de akka

    public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
     
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
     
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello " + ((Greeting) message).who);
    }
    }
     
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    greeter.tell(new Greeting("Charlie Parker"));

y esta clase es nuestro socket se maneja con un writeObject y readObjet de sus ObjectOutputStream ???

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">