"Keep the JVM, dump the rest" - Havoc Pennington

Scala OK, Play! OK, mongoDB... mmmm.... si necesitara una base de datos NoSQL, puede ser que usara mongoDB. O Cassandra. O CouchDB. O HBase.... en fin. Pero de default usar mongoDB, no sería una opción para mí. Tal vez ya estoy muy maleado de usar bases de datos SQL (pseudo-relacionales, porque si pongo relacionales viene luxspes a corregirme con un comentario de 17 párrafos).

Eso de poner mongoDB como default me recordó este famoso diálogo de xtranormal.

En lo personal, mi stack alterno sería Grails + PostgreSQL.

Me acordé cuando en un foro alguien preguntó: "Alguién sabe de un webframework ligero para Python" y yo conteste "Pues ... Django que no?" y respondieron, "dije ligero no el gorila ese" .. y alguién salió en mi defensa, "Es que él programa en Java..." y todos "...ahhh... con razón."

Ouch...

Se ve bien.

Según yo Play echa a la basura el stack del servlet y los servlets containers en favor de algo más simple. Los puede usar pero más como una opción para no perder público que como un fin.

Scala, esta bien, pero me molesta un poco que no acepten que es un lenguaje complejo que hace que las cosas sean simples. Es decir está presentado con piel de OO y luego resulta que todo lo bueno se hace con la PF. Y para variar la comunidad es agresiva ( más que la de Java que de porsí )

Por ejemplo en un blog alguién mal entendio la "monada" Option ( Option monad - que por cierto Modad es algo que se inventó en programación funcional para decir: "Que? No le entiendes? ahh es que no es para todos..." - ) y le llovieron respuestas como esta. Luego resulta que el inventor del lenguaje dice, no usen flatMap usen esto en vez ¿Entonces? Pues que ni los que le llamaron amateur, sabian eso.

Sobre MongoDB paso. Solo sé que no es para todos los escenarios. Alguna vez leí decir a James Gosling ( años antes de que se le llamara al movimiento NoSQL así ) que le gustaba la idea pero no para todo. Dijo algo como "Denme un montón de RAM y un archivo de log" Pero Enrique ha explicado varias veces como hay escenarios ( transaccionales según entiendo ) donde no aplica. En Facebook por ejemplo, que pasa si no aparece mi comentario? O no aparece el "me gusta"? Pues lo vuelvo a escribir y ya o le vuelvo a dar click y listo. En tu banco, no creo que fuera buena idea que no te llegue tu depósito y que simplemente la reintentes.

Estan super estas nuevas opciones.Muestra clara de que hay quienes aunque ya existan las cosas se pueden "mejorar" o al menos hacer diferentes.

Jajaja, xtranormal, no lo conocía. Está chido; lástima que no hay voy de hombre mexicano.

Ne, pues a mi me gusta más Scala que Groovy. Y también por ese ODIO acérrimo que le tengo a SQL preferiría algo cómo mongo (quizás bigtable o S2). Este Stack me llamó la atención, pero igual Grails + PostgreSQL, aunque no es del todo alterno, aunque si te olvidas de la JEE old-school, que esa es la idea.
A mi parecer lo malo de Grails, es que tiene cosas muy a la Spring (el cual tampoco me termina de gustar).

FueraTema: ¿Foro pythonico en español?, pasa la liga porfavor.

Nap!.. era en inglés, en StackOverflow por su puesto.

Decepción, triste decepción.

Al igual que los demás, creo que NoSQL es para escenarios específicos. De hecho creo que decir "no me gusta SQL por eso usaré alguna BD NoSQL" es incoherente, más que nada porque el movimiento NoSQL debería llamarse NoRel o algo así. El nombre NoSQL sugiere que el problema es con el lenguaje SQL, pero dentro del mismo contexto relacional, cuando (por lo que he visto, soy un poco neófito en el tema) las BD NoSQL proponen un esquema diferente al relacional: key-value store, grafos, etc... El hecho de nombrarlo "NoSQL" a mi me parece que es meramente hype.

Por eso creo que confunde el término NoSQL a quien no conoce exactamente a lo que se refiere y le hace pensar que es para el mismo propósito pero es mejor.

Algo verdaderamente "NoSQL" podría ser Rel, que sigue siendo relacional pero sin SQL y con un lenguaje de consulta que aprovecha mucho mejor las relaciones.

Scala OK, Play! OK, mongoDB... mmmm.... si necesitara una base de datos NoSQL, puede ser que usara mongoDB. O Cassandra. O CouchDB. O HBase.... en fin. Pero de default usar mongoDB, no sería una opción para mí. Tal vez ya estoy muy maleado de usar bases de datos SQL (pseudo-relacionales, porque
si pongo relacionales viene luxspes a corregirme con un comentario de 17 párrafos).

17 parrafos, 5 ligas, y 6 o 7 libros... ;-)

En lo personal, mi stack alterno sería Grails + PostgreSQL.

Dejando de lado (temporalmente) a Rel, que desafortunadamente no esta suficientemente maduro (todavia), mi stack alterno seria Weld + Scala + Seam Remoting + PostgreSQL. (Mi stack "normal" seria Spring-MVC + Java + Jackson o DWR + Oracle)

En cuanto a Mongo... trabajar con una base de datos que no tiene joins ni transacciones, ni locks me parece, francamente, ademas de un retroceso a los tiempos pre-pseudo-relacionales de COBOL, un modo gratuito de complicarse la vida, al menos para el tipo de sistemas empresariales que yo tengo que construir, pero parece que para construir otro tipo de cosas es mejor.

Ah sí, olvidé mencionar mi stack.

Basándome en un análisis que hice en estos días sobre varias combinaciones de frameworks, me voy por Grails + PostgreSQL.

Luxspes toca un punto muy importante. Muchas de estas bases se enfocan totalmente a performance, sacrificando muchas cosas que son importantísimas para muchas aplicaciones, como transaccionalidad, reglas de integridad, joins, locks, etc. Como dicen en el video de xtranormal, si sólo quieres performance y no te importa lo demás, pues simplemente escribe todos tus datos a /dev/null y listo.

Para mí hay un criterio definitivo. El día que un banco o al menos un sitio respetable de comercio electrónico utilice una de estas bases de datos para manejar dinero, quiere decir que está lista para cualquier cosa. Antes no. Yo creo que por ahora están muy bien para hacer aplicaciones de redes sociales y cosas así; si de repente se pierde un tweet, un status de facebook, un checkin de foursquare, no pasa nada. Si se pierden registros de pagos, o se registran duplicados, o los saldos de las cuentas no cuadran, habrá serios problemas.

Combinación extraña

Scala (no, ni hablar apenas se usar Java)
mongoDB (no se nada de NoSQL, voy a investigar)
Play! (de plano los frameworks no son lo mio, prometen facilitarte la vida, pero no dicen cuando)

Apenas si se usar Java y salen con esto.

Ya veo porqué lo de "Sr. Negativo".

Pues Scala, no tiene una curva te aprendizaje desgarradora que impide aprenderlo, y pues si no sabes cómo hacerlo en Scala, lo haces cómo solías hacerlo en Java =P.

Con lo de mongo es donde hay más broncas, todavía mucha gente no cree en el modelo NoSQL (o no relacional, cómo menciona @benek de manera acertada y acertiva). O están personas cómo @luxspes y creen que el modelo verdaderamente relacional es lo < < lo de hoy > > y el modelo NoSQL es < < lo de antes de ayer > >, aunque a mi este último razonamiento (eso de regresar a COBOL y tal) me parece que es decir: "los teléfonos móviles son malos, porqué regresamos al reloj de bolsillo"; pero todo es cuestión de persepción.

Y pues con Play!, la mera verdad creo que framework más simple y que te simplifique la vida más que este no vas a hallar. Basta con que entiendas teóricamente que es MVC y saber cómo hacer conexiones a bases de datos para hacer aplicaciones tan simples o tan robustas cómo quieras sin concentrarte en cosas cómo la configuración.

Creo que unas leídas no te harían mal, porqué de verdad hace tiempo que no usaba JSP + Servlet; y ahora en la escuela la verdad digo: "Play!, cómo te extraño, o ya de menos Wicket".

Saludos.

Pues Scala, no tiene una curva te aprendizaje desgarradora que impide aprenderlo, y pues si no sabes cómo hacerlo en Scala, lo haces cómo solías hacerlo en Java =P.

Creo que quisiste decir Groovy, en Scala (que yo sepa) no es posible escribir código con sintaxis Java, en Groovy sí.

Eso creo que se cambia con el tiempo, es cómo por ejemplo alguien que programa en FOX y VB 6 te va a decir que programar orientado a objetos es estercolero, inseguro e incluso "la causa de la crisis que se aproxima este 2012". Igual al programar funcional, el punto es que cuando te cambian el paradigma te quedas de: "Ash, o sea eso yo lo hacía en MySQL con 3 tablas, una de ventas, otra de productos y otra que se llamaba venta_productos; unidas por los Id de ambas tablas."; en cambio ahora que no lo tienes en las bases de datos NoSQL (que NoSQL algunos lo definen cómo: "Not only SQL") piensas que es más difícil. Desgraciadamente por ello (en mi limitada lógica respecto a lo NoSQL a día de hoy) se generan las duplicidades de la desesperación de cómo bien dices no existir un join, e.j.:
 
Y eso que en este caso no estamos hablando de un sistema empresarial...Podríamos decir que esta es una aplicación de slacking para crear tu árbol familiar. Y si tienen razón de momento no me imagino haciendo un sistema (cómo los que suelo hacer) con NoSQL. Habrá que estudiar más.

Según yo si, porqué en muchos lados veo documentación que acaba siendo repaso de Java XD. Incluso hay una empresa donde andaban buscando un Scalero pero Scalero, porque los que les llegaban básicamente usaban Scala cómo si fuera Java (ví código). A no ser que me hayan dicho mal y yo me haya comido ese cuento (tanto en documentación, cómo en esa empresa).

Movido a:

"Ash, o sea eso yo lo hacía en MySQL con 3 tablas, una de ventas, otra de productos y otra que se llamaba venta_productos; unidas por los Id de ambas tablas."; en cambio ahora que no lo tienes en las bases de datos NoSQL

Ojala esa fuera toda la diferencia. Con el enfoque relacional, y si uno hace cierto tipo de sistemas, puede caer en esa vision simplista... la cuestion es que "ligar" (como dices tu) a las tablas por ID, no es algo especial en el enfoque relacional, es decir, uno puede escribir joins con el campo que a uno le de la gana, si necesidad de modificar el model... con Mongo, es necesario definir los "caminitos" por adelantado, por lo que el dia que te piden un nuevo reporte, con la misma data que ya tenias, pero una perspectiva nueva, en ves de simplemente hacer un join en una vista, tienes que cambiar todo tu modelo de datos.

Lo que voy a comentar no creo que sea objeto de debate ya que cae en el contexto de gustos, pero observando los códigos de oscar para el ls en java y scala, a mi me parece que java es mas entendible.

sobres

Exacto Nopalin, es cuestión de gustos, es algo totalmente subjetivo.

Sucede que nos es más entendible algo que conocemos. Java fue diseñado a propósito para parecerse a C++ y hacerlo más familiar. Groovy es lo más natural del mundo viniendo de Java. Scala también se parece a Java, pero intenta atraer al publico que usa lenguajes como Haskell y OCaml.

En Scala se puede hacer código mucho muy similar a Java o totalmente diferente. El que yo puse ( según yo ) es algo más similar a Java pero con algunos cosas que no se encuentran para hacer notar la diferencia.

A mi parecer un lenguaje no debería de tener tantos "estilos", una cosa es usar diferentes algoritmos ( usar recursion en vez de for, un mapa en vez de una lista, etc ) y otra es que el mismo algoritmo se pueda implementar de formas tan distintas.

No sé si lo mencioné antes, pero la verdad es que hacer algo original y que no luzca "extravagante" al mismo tiempo esta bastante difícil.

Exacto, lo que puse fue "la punta del iceberg". Por eso dije que algo tan tan simple cómo eso (pseudo-relacional), no me imagino sacando más ventajas.

Eso de entendible es super reativo, yo puedo ver codigo de VB y digo WTF! y asi pensaran de Java os que venen de VB... de hecho alguien habia dicho en otro post por ejemplo groovy se le hacia aberrante (o algo asi) pues esa fue su impresion del como se ve

En mi caso no tendria bronca con trabajar con Groovy (que soy un starter) o Scala (que todavia no se) porque he visto muchas cosas que me han gustado como se hacen aunque me causen ruido como se vean... por ejemplo, antes de usar closures yo los criticaba por su forma de "como se ven" pero cando los utilice ahora si me que calle el hocico con su tremenda funcionalidad... bueno asi ha de ser con las otras cosas que son nuevas para nosotros, hay que familiarizarnos

Asi mismo será pera las DB nosql, anque tambien hay que reconocer que apenas esan tiernitas y de los frameworks de controladores "estoy hasta el gorro" bie dicen que si tienes muchas opcones ninguna se te antoja, y eso me pasa asi que opte ya por profundizar en Grail y ya, ni uno mas!! (por un buen rato o hasta que me conste que exista uno mejor)... por cierto, vi lo de Play y se ve interesante, pero no me convence del todo (mas que grails, aunque si suena mejor que otros) por eso ya dije: Grails y nada mas!

En el otro thread ya puse mi versión del tiny ls en Groovy, para poder hacer el contraste entre Scala, Java y Groovy. Yo la neta, me quedo con Groovy...

Eso de entendible es super reativo, yo puedo ver codigo de VB y digo WTF! y asi pensaran de Java os que venen de VB... de hecho alguien habia dicho en
otro post por ejemplo groovy se le hacia aberrante (o algo asi) pues esa fue su impresion del como se ve

Tal ves fui yo, a mi me parece que Groovy es Java sobrecargado de epiciclos. Scala es mas como plantear las reglas del juego desde el principio y de una mejor manera.

Asi mismo será pera las DB nosql, anque tambien hay que reconocer que apenas esan tiernitas

No creo que sea exactamente el mismo caso, siento que las NoSql tienen limitaciones fundamentales, hay cosas como los theta joins, o las trasacciones que sencillamente parecen ir en contra de la tendencia "NoSQL" que mas bien parece un regresar al modelo de datos "network" de CODASYL/COBOL, en donde en ves de dejarle al motor de la base de datos el trabajo de determinar el mejor plan de ejecucion de forma automatica a partir de las capacidades del hardware, volvemos a modo procedural en que hay codificar todo proceduralmente, pasito a pasito....

Por otro lado, siempre me he preguntado... que impide que yo programe un inteprete del lenguaje de Rel que use a MongoDb como su mecanismo de persistencia... y de hacerlo... exactamente a que paradigma/modelo perteneceria la solucion resultante?