Opinion

Hagan un benchmark de algunas operaciones que piensen que van a realizar en un sistema real. Codifiquen los algoritmos en .NET y Java, compilenlo y corranlo en Windows.

El CLR es big-endian igual que los CPUs Intel, mientras que la JVM es little-endian igual que los procesadores SPARC (porque Java nacio en Solaris). En Intel, la JVM debe hacer ciertas operaciones adicionales para convertir entre big-endian y little-endian, pero como eso ya sido desde el principio, ya lo tienen bastante optimizado. La CLR la hicieron para Intel a proposito porque ahi es donde corre Windows y la CLR esta super optimizada para Windows, pero la JVM a estas alturas tambien corre bastante bien en Windows.

En mi humilde opinion, seria estupido decidirse por una plataforma (la que sea) por un detalle como el endianness de la maquina virtual que van a usar. Pesan mucho mas otros criterios como portabilidad, bibliotecas y frameworks que pueden utilizar, soporte a futuro, documentacion, opciones para capacitacion, etc etc.

No me consta que Java corra mejor en Linux que en Windows. Habria que hacer pruebas. Pero incluso los resultados serian muy dificiles de interpretar, creo yo... si resulta que el mismo programa en Java corre mejor sobre Linux que sobre Windows, es puramente debido a la JVM (porque esta mas optimizada para un sistema operativo que para otro) o es porque ese sistema operativo tiene mejor performance en general?

Lo que si es un hecho es que pasar de VB a Java les va a dar practicamente el mismo trabajo que pasar de VB a .NET; si se van por .NET les recomiendo usar C#; eso de usar VB.NET porque disque es mas facil, tiene en realidad un efecto contraproducente, porque aunque tiene la sintaxis de VB6, no deja de ser OOP con todas las clases de .NET por lo que se van a dar de topes.

Yo siempre he tenido la idea que Java tiene mucho mejor soporte que .NET para las aplicaciones que se realizan comenzando como dices tu por portabilidad, bibliotecas y frameworks ademas de que la Documentacion es mas accesible para Java.

Otra de mis dudas es en cuanto a las bases de datos, para mi Java tendria mejor soporte si usaramos MYSQL.

Seguimos comentando !!!!

Dice él, que Java es un lenguaje de programacion que se hizo para Software Libre...

Incorrecto, nació para cualquier clase de software y Java mismo no fue "libre" hasta hace un par de años.

.. aunque se puede utilizar en los diversos sistemas operativos que conocemos, por ello es mas fácil que corra mejor en Linux que en Windows

Tampoco es necesariamente correcto. Windows ha sido desde el principio el S.O. "base" digamos de Java, por la simple y sencilla razón de que es el S.O. con más usuarios en el mundo. Por lo tanto se han hecho muchisimas optimizaciones para él y para el procesador intel. Un ejemplo ( algo viejo ) es que los threads en Linux fueron por muchisimos años simulados ( green threads, como en Ruby ) mientras que en Windows han sido nativos desde la version 1.2.

"Para el .net tiene mejor rendimiento que java si ambos se trabajan en Windows."

Para salir de la duda, hagan como sugiere Enrique, una o varias pruebas.

Y aprovechando el tema cual es la mejor base de datos para Java.

No hay mucha diferencia. Java tiene un muy buen soporte para la mayoria de los RDBMS

Para hacer un buen comparativo entre Java y .NET

Tendriamos que contemplar lo siguiente :

- Portabilidad
- Bibliotecas
- Frameworks
- Documentacion
- Capacitaciones

Ustedes que mas agregarian, Gracias por el aporte @OscarRyz.

Yo he trabajo tanto en java como en .NET, haciendo aplicaciones empresariales y aplicaciones aplicaciones sencillonas, y de la poca experiencia que considero todavía tengo, lo único que noto es que el pintado es un poquitín mas lento en aplicaciones java que en aplicaciones .NET, pero de ahi en fuera yo considero que es muy parecido el rendimiento. Lamentablemente no he aplicaciones .NET tan pesadas como las he hecho en java, por ejemplo una función que procese 17 mil registros (bueno ni tan pesada jeje), buscando por cada uno información en una base de datos, algo que no se lleva mas de 10 segundos. Pero tambien depende de como programes la función, si no esta optimizada vas a tardar varios minutos o segundos si lo está.

Si te vas por frameworks, lejos gana java, ¿por qué?, fácil por que los windoseros están acostumbrados a trabajar solo con lo que les dé microsoft, y microsoft no saca tantos frameworks que digamos, en contraparte los entusiastas de java no dependían de ninguna empresa para hacer lo mismo, mas aparte la comunidad respondia afirmativamente, cosa que no pasa tanto en microsoft.

Saludos

Pregunta ¿con .NET se tiene acceso al hardware?, otra pregunta ¿Que tan avanzados estan los programas para administrar un proyecto en java o en .net ?, estos programas pueden ser un project, un sistema de uml, un sistema de versionamiento, etc. y cuanto puede llegar a costar la implementacion de un entorno de desarrollo en .net o en java.

He leido en varias partes que java es verdaderamente lento, asi que...

Gracias por sus comentarios, Se trata de evaluar que lenguaje seria mas optivo si deseo emigrar.

veo que Java gana en cuanto a frameworks y eso es bueno cuando se esta mas relacionado con el lenguaje.

¿con .NET se tiene acceso al hardware?
si, con .NET tienes acceso al hardware.

¿Que tan avanzados estan los programas para administrar un proyecto en java o en .net ?, estos programas pueden ser un project, un sistema de uml, un sistema de versionamiento, etc.
Que es lo que estas buscándo, ¿que esas herramientas esten acopladas dentro del IDE?, la verdad no tengo mucha idea ya que desde hace poco mas de un año que no agarro un IDE de microsoft, y el ultimo que probe, el Visual Studio Express Edition 2008, si te proporcionaba manejo de proyectos, pero no diagramas UML y tampoco un CVS.
Ahora el que esten dentro del IDE tal vez agilize un poco pero para nada son indispnesables, puedes utilizar herramientas por fuera y es exactamente la misma funcionalidad. Hay que aprender a ser programadores y no usuarios de un IDE.

cuanto puede llegar a costar la implementacion de un entorno de desarrollo en .net o en java.
Si le sabes bien, configuras todo el entorno en menos de 1 dia, cuanto cobras por dia, 400, 500 pesos?

Sobres

No es cuestion de hablar de un IDE, la idea es conjuntar una serie de herramientas que nos proporcionen un mejor rendimiento de las aplicaciones que vayamos a desarrollar.

Como lo comentaba en mi primer post, lo que haremos en la empresa donde trabajo es emigrar de Visual Basic a Java o .NET pero queremos estar seguros de lo que estamos haciendo porque esto es algo nuevo en cierta forma para nosotros.

Comparar Java solito contra .NET solito, así como en el vacío, creo que no es muy útil. Pero puedes comparar el stack estándar de .NET (Windows, .NET, Visual Studio la edición que vayan a utilizar, SQL Server, IIS, ASP.NET) contra uno de los varios stacks posibles en Java:

Sistema operativo: Linux/Windows/Mac OS X
Base de datos: MySQL / PostgreSQL / MS SQL Server / Oracle / etc.
web server: Apache web server, IIS
Contenedor servlets o JEE: Tomcat / Jetty / JBoss / Glassfish / WebLogic / WebSphere / el de Spring cuyo nombre no recuerdo pero es un Tomcat modificado
IDE: Eclipse / NetBeans / IDEA
Frameworks de persistencia: JPA puro o provisto por el contenedor / Hibernate / iBatis / Cayenne
Frameworks para web y/o MVC: Struts / Spring MVC / Spring Web / Tapestry / Wicket / Apache Click / JSF (ICEFaces, etc) / Vaadin / GWT
Frameworks integrales (los que ya hacen de todo un poco): Grails / Griffon / Play / Spring Roo

Si te vas por frameworks, lejos gana java, ¿por qué?, fácil por que los windoseros están acostumbrados a trabajar solo con lo que les dé microsoft, y microsoft no saca tantos frameworks que digamos,

Son menos que en Java, pero hay suficientes para que no te haga falta nada (y hay algunos mejores que lo que Java ofrece, por ejemplo LINQ/EntityFramework deja en muchos sentidos muy atras a JPA).

También muchas veces se comenta que "es que no hay un IoC oficial" para .NET, cuando existe Unity desde hace años, y asi, he oido cantida de comentario de Javeros (o de .NETeros) de que "alla en la OTRA plataforma que ellos NO conocen, no se tiene X, y no se tiene Y," cuando en relidad si se tiene, solo que ellos no lo saben, no mas le atinan, a veces, por suerte...

en contraparte los entusiastas de java no dependían de ninguna empresa para hacer lo mismo,

Depender de una empresa, depender de una comunidad, al final, la mayoria de los devs de Java que he conocido dependen de un tercero, y la mayoria no tiene el skill para modificar un proyecto de la complejidad de Hibernate, o Richfaces sin causarle graves inestabilidades.

mas aparte la comunidad respondia afirmativamente, cosa que no pasa tanto en microsoft.

Ciertamente a mi también me da impresión de mas participación de la comunidad Java, pero me pregunto que tanto es percepción.

Yo siempre he tenido la idea que Java tiene mucho mejor soporte que .NET para las aplicaciones que se realizan

Que se realizan... para? Y el contexto apa? ;-)

comenzando como dices tu por portabilidad,

En portabilida si gana Java, aunque con Mono tambien se puede... Embarcadero ya vende un IDE que te da esa portabilidad.

bibliotecas y frameworks

Depende de tu necesidad, que equivale a Silverlight en Java? (JavaFX, ahora muerto) y ni que decir de equivalentes a WPF... o la superioridad del manejo de modulos en .NET (vs el ClasspathHell de Java, aunque gracias a OSGi java ya esta dando batalla). O por ejemplo el hecho de que II7 si tiene memory isolation (una aplicacion ASP.NET no puede tirar a otra) y en cambio en Java, cualquier aplicacion puede tirar a todo un Tomcat....
(claro que por otro lado OC4J tambien ofrece este tipo de estabilidad seguridad para Java... en fin... depende...)

ademas de que la Documentacion es mas accesible para Java.

En que sentido consideras que es mas accesible, toda la documentacion de .NET esta en multiples idiomas (español entre ellos)... en Java en cambio...

Otra de mis dudas es en cuanto a las bases de datos, para mi Java tendria mejor soporte si usaramos MYSQL.

Con .NET, igual te puedes conectar a MySQL, con la ventaja de que puedes usar LINQ/EntityFramework, que supera con mucho a JPA.

No me consta que Java corra mejor en Linux que en Windows.

Desafortunadamete, a mi (y no solo a mi) si me consta. Por favor voten para que Oracle corrija esto!!!!!

Son menos que en Java, pero hay suficientes para que no te haga falta nada
Nunca se dejo en entre dicho eso, solo que en java hay más.

(y hay algunos mejores que lo que Java ofrece, por ejemplo LINQ/EntityFramework deja en muchos sentidos muy atras a JPA).
Sentidos que son utilizados por la minoria de programadores.

También muchas veces se comenta que "es que no hay un IoC oficial" para .NET, cuando existe Unity desde hace años, y asi, he oido cantida de comentario de Javeros (o de .NETeros) de que "alla en la OTRA plataforma que ellos NO conocen, no se tiene X, y no se tiene Y," cuando en relidad si se tiene, solo que ellos no lo saben, no mas le atinan, a veces, por suerte...
Alguna vez vi que un canijo hizo un compilador para sintaxis de java pero te generaba clases para .NET. En realidad de cualquier lado existen frameworks para hacer lo que quieras, inclusive si no existen te los programas tu (si tienes el tiempo claro), pero la mentalidad de un programador .NETero es basicamente esperar a que microsoft lo saque y si viene incrustado en el IDE mucho mejor, para java no pasa tanto, aunque últimamente no me lo parece tanto.

Depender de una empresa, depender de una comunidad, al final, la mayoria de los devs de Java que he conocido dependen de un tercero, y la mayoria no tiene el skill para modificar un proyecto de la complejidad de Hibernate, o Richfaces sin causarle graves inestabilidades.
Todos dependemos de algo, aunque como alguna vez dijo ezamudio, no todos son programadores. Podrán ser usuarios de tal IDE y/o framework/libreria, pero si no tienen la capacidad de entender algo y modificarlo, no son programadores, pero obvio, algunos tienen mayor capacidad que otros, y lo que a los primeros les puede tomar una semana, a los otros les toma 2, es cuestion de aceptar lo que nuestra madre naturaleza nos obsequió.

En portabilida si gana Java, aunque con Mono tambien se puede
Mono ya va bastante avanzado, solo pequeñas piedras en el camino todavía.

Sobres

Sobre ese bug en específico, es un problema de Windows. Lo que dice ahí es que no se puede reemplazar un archivo mientras otro programa lo está usando, y eso sieeempre pasa en Windows.

Para citar a uno de las personas que reporto este bug:

"In this town the tapwater is nasty. Therefore I will serve nasty tapwater at my restaurant, because the customers are used to it."

Traduccion y explicacion metaforica: En este pueblo (Windows), el agua de la llave esta sucia (locking). Por lo tanto, yo serviré agua sucia de la llave (locking) en mi restaurante (Java), por que los clientes (usuarios de windows) estan acostumbrados a ella.

No me parece que eso indique un interes por dar un buen servicio en dicho restaurante.... o si? ;-)

Sobre ese bug en específico, es un problema de Windows.

No, es un problema de Java, por que Java es quien dice ser portable (Windows no dice en ningun momento que va a ser compatible con Unix). Si no lo puede cumplir, entonces el que falla es Java, por que el que prometio portabilidad fue Java.

En Windows, existen APIs para desbloquear archivos (por que Java no las usa?).

Lo que dice ahí es que no se puede reemplazar un archivo mientras otro programa lo está usando, y eso sieeempre pasa en Windows.

Si, pasa, pero hay mecanismos para resolverlo..., es solo que Java decide no usarlos... tal vez para fomentar el uso de Unix/Linux? (yo al menos, gracias a este bug, no recomiendo los deployments de Java en Windows...). Por otro lado, parece que ya diseñaron una nueva API sin este problema (pero solo sirve para JDK 7 o superior y tienes que reescribir y recompilar tu codigo para aprovecharla... me pregunto si deberas resuelve el problema... y por que no hacen la corrección retroactiva...

Alguna vez vi que un canijo hizo un compilador para sintaxis de java pero te generaba clases para .NET.

IKVM? Lo que si le falta (hasta donde se) a .NET es un compilador de C# que genere clases para Java... o mas bien le falta a la JVM un compilador de C# ? ;-)

Lo que dice ahí es que no se puede reemplazar un archivo mientras otro programa lo está usando, y eso sieeempre pasa en Windows.

Como podemos leer aqui, esto no sieeempre pasa en Windows (simplemente hay que abrirla en modo FILE_SHARE_DELETE). Siendo que Java promete portabilidad, uno esperaria que sieeempre usara dicha opcion cuando abre los .jars (o cualquier archivo, para tener portabilidad con Unix)... pero no lo hace. (Por favor voten para que Oracle corrija este otro bug)

IKVM? Lo que si le falta (hasta donde se) a .NET es un compilador de C# que genere clases para Java... o mas bien le falta a la JVM un compilador de C# ? ;-)

Bueno, jabaco es un primer paso no?

¿Quién lo iba a creer?
Un programador Java programando en BASIC (más bien VB).

Gracias @nopalin por el link...ni por enterado que existia este compilador.

Bueno, jabaco es un primer paso no?

Interesante... no lo conocía!

Asi es compañero,
aunque mi ideal es migrar todo lo que tenemos en visual basic a .Net y Java es por eso que estoy generando este post para conocer las opiniones de gente experta y no experta.

Para tomar la mejor decision.

Saludos

Probablemente en portabilidad, bibliotecas y frameworks. Pero la documentación es bien simple de encontrar, con ir a MSDN te puedes dar muy buena idea de qué se trata; en Java es difícil por el hecho que Fulanito usa Wicket, sutanito usa Spring MVC, juanito usa Intellij IDEA, yo uso Play, etc. No hay algo uniforme (cómo la hay en .NET) por lo tanto la información que buscas es más difícil a veces (sobretodo cuando ya dominas lo básico y quieres ir al siguiente nivel, mi caso). En .NET con MSDN me basta para darme idea de cosas, por ejemplo en aquellos ayeres de la salida de LINQ To SQL, era nuevo pero la documentación de MSDN ya incluía ejemplos LINQ To SQL y era lo simple, ya tu buscabas más y voila, pero en Java lo que me ha tocado es leer aquí y allá (lo que no veo mal, pero desde un punto de vista general es más difícil, yo lo encuentro divertido).

En fin, para BDD te recomiendo PostgreSQL, ya si va a ser algo a gran escala no hay nada cómo Oracle DB.

Re: Y el contexto apa? ;-)

Te cito @luxspes:

Depende de tu necesidad, que equivale a Silverlight en Java? (JavaFX, ahora muerto) y ni que decir de equivalentes a WPF... o la superioridad del manejo de modulos en .NET (vs el ClasspathHell de Java, aunque gracias a OSGi java ya esta dando batalla).

Pues JavaFX no está muerto, lo que murió fue JavaFX Script que era con lo que se programaba JavaFX. Ahora se usará Java (lenguaje) en lugar de JavaFX Script para programar en JavaFX.

Con lo de la documentación, estoy muy muy muy de acuerdo. Pero pues lo de LINQ/EntityFramework, a mi personalmente no me agradan, ya que es usar una variante SQL; y en lo personal SQL sucks. Pero eso ya es cuestión de gustos (he ahí el contexto ;).

en lo personal SQL sucks

En general? O sea eres fan de NoSQL? O por SQL te refieres al MS SQL Server? Microsoft son bastante ingeniosos para nombrar sus productos. Al sistema operativo le ponen Windows, como si fuera el único sistema operativo que utiliza ventanas (ya había otros que las usaban para cuando salió Windows). Al procesador de palabra el ponen Word ("palabra" en inglés); a su navegador le ponen Internet Explorer.

A su servidor de base de datos le ponen SQL Server para que los que no conocen otra cosa que no sea MS, siempre que oigan SQL van a pensar en el MS SQL Server y se confunden cuando les dices que ejecuten una sentencia SQL en Oracle o cualquier otro RDBMS porque piensan que estás hablando de interoperabilidad. O sea, un microsoftero oye "SQL" y piensa "servidor de base de datos de Microsoft, el que conozco", en vez de "structured query language".

Si Microsoft hiciera papel de baño se llamaría "MS Asswipe". Y se quejan de que Apple le puso App Store a su tienda de aplicaciones...

No me refiero a MS SQL Server, me refiero a Structured Query Language. Digo no lo considero algo malo, más bien no me gusta codificar SQL, de hecho odio codificar SQL. Me gusta un poco más lo que usamos en JPA (¿JPQL?), la verdad se me hace más simple rápido y productivo decir:
 

En lugar de:
 

Y por ejemplo en el caso de LINQ TO SQL (del que habla @luxspes) me parece un tanto confuso y raro dialecto de SQL (ejemplo tomado de MSDN):
 

Aunque de cierta forma es muy "Object QL", no sé aún sigo prefiriendo por mucho JPA. Pero cómo dije, eso es en lo personal; y sé las ventajas que esto tiene y las ventajas que tienen otras tecnologías, más sin embargo esto es de gusto, me agrada más el tener un POJO.

Es más incluso desde el punto de vista de los más puristas de "bases de datos relacionales" creen que SQL es una maldición setentera de la que necesitamos deshacernos.

Yo preferiría algo que no se le pareciera siquiera:

 
O algo por el estilo. Como que el ejemplo que pones de JPA me sigue pareciendo muy SQLoso.... Aunque sé que el que yo puse es pura imaginación.

A veces siento que el SQL es mi archienemigo ( sobre todo cuando tengo que usar aquello del LEFT OUTER JOIN - ja que en sí es muy fácil, pero es lo primero que me viene a la mente como "uy que difícil" -)

Con lo de la documentación, estoy muy muy muy de acuerdo. Pero pues lo de LINQ/EntityFramework, a mi personalmente no me agradan, ya que es usar una variante SQL; y en lo personal SQL sucks. Pero eso ya es cuestión de gustos (he ahí el contexto ;)

Si crees que LINQ es SQL, entonces no tienes ni idea de que es LINQ, LINQ es aplicar programacion funcional y analisis de AST (Abstract Syntax Tree) para analizar la estructura del codigo y permitir su ejecucion en un contexto distinto... SQL es solo un target mas para LINQ. LINQ puede filtrar objetos en memoria, en un origen LDAP o un archivo XML o JSON (o cualquier origen de datos que se te ocurra)

Y por ejemplo en el caso de LINQ TO SQL (del que habla @luxspes) me parece un tanto confuso y raro dialecto de SQL (ejemplo tomado de MSDN):

Sin animo alguno de ofenderte, antes de hacer afirmaciones del tipo de LINQ es un dialecto de SQL, deberias investigar un poco de lo que hablas...

Aunque de cierta forma es muy "Object QL", no sé aún sigo prefiriendo por mucho JPA.

En serio tu argumento a favor de JPA es "me gusta por que me gusta"? :-(

Pero cómo dije, eso es en lo personal; y sé las ventajas que esto tiene y las ventajas que tienen otras tecnologías, más sin embargo esto es de gusto, me agrada más el tener un POJO.

Por que? por racismo contra los PONOs? ;-) o piensas que los POJOs son mejores que los PONOs por que los PONOs son inferiores a los POJOs :-(.

Es más incluso desde el punto de vista de los más puristas de "bases de datos relacionales" creen que SQL es una maldición setentera de la que necesitamos deshacernos.

Yo voy de acuerdo últimamente con esa idea (la de las bases de datos verdaderamente relacionales vs SQL) pero usando la logica circular, si no comparando lo que SQL, LINQ y Rel ofrecen, los pros y los contras, con el objetivo de tomar una decisión informada (y sustentada).

Pues JavaFX no está muerto, lo que murió fue JavaFX Script que era con lo que se programaba JavaFX. Ahora se usará Java (lenguaje) en lugar de JavaFX Script para programar en JavaFX.

Estas en lo correcto, me equivoque al afirmar que JavaFX esta muerto, es JavaFX Script el que esta muerto, la futura muerte de JavaFX. todavia es debatible (aunque si tuviera que apostar, diria que va derechito para alla, entre otras cosas por que no hay un entorno "Graphis Designer Friendly" para utilizarlo)... pero ya veremos...

Yo preferiría algo que no se le pareciera siquiera:
 
O algo por el estilo

Como LINQ? ;-) :

O tambien se valdria:

(Estoy escribiendo esto de memoria, asi que es posible que haya algun(os) error de sintaxis, si detectan alguno, agradecere su comentario para corregir, pero la idea general permanece)

No digo que .NET sea mejor que Java en todo sentido... cada uno tiene sus puntos fuertes... pero LINQ ciertamente es un aspecto en el que Java se ha quedado atras.... y ciertamente el select de LINQ es inferior a las capacidades de proyeccion de Rel

Sin embargo, LINQ es para facilitar el uso de búsquedas con comandos "SQL-like", por decir de una forma. Y es lo que no me gusta:
 

No me gusta que incluso quieren meter un dialecto de consultas (o un lenguaje integrado de consultas, cómo lo llaman en MS) para hacer búsquedas dentro de una estructura tan base cómo lo es un arrelgo. Que a fin de cuentas sería algo similar a:
 

La diferencia, no sé si sea en perfomarnce, no se cuanto dure el bloque LINQ que puse (tomado desde MSDN) contra un foreach o un for en C#. De haber diferencia es poca y sin meter "palabras raras" para un arreglo (incluso un bloque que te sirve para personas nuevas a .NET).

Y pues la idea LINQ está chida, pero no me convence por el uso de sintáctica "SQL-Like".

La diferencia, no sé si sea en perfomarnce, no se cuanto dure el bloque LINQ que puse (tomado desde MSDN) contra un foreach o un for en C#

La diferencia, asi como lo pones, es minima, pero conceptualmente es muy importante, por que con el for, estas diciendole a la maquina exactamente que quieres que haga "recorre el arreglo, de principio a fin, y compara, 1 x 1, los elementos" eso es malo, por que no te servira de nada tener una maquina con 16 procesadores, igual compararas 1 x 1.

Con LINQ, en cambio, no dices como, solo dices que "encuentra todo los elementos que cumplen con esta condicional", hasta .NET 3.5 daba lo mismo, pero en .NET 4.0 ya hay PLINQ (Parallel LINQ) y con casi el mismo codigo puedes correr en paralelo:

El siguiente paso (quiza en .NET 5.0) podria ser dejarle la eleccion al compilador... introduciendo paralelismo de manera dinamica dependiendo de las capacidades de la maquina.

Como ves, LINQ es mucho mas que un "dialecto de consultas" o un "dialecto de SQL" es una forma diferente (y en mi opinion mas efectiva) de resolver los problemas

Y pues la idea LINQ está chida, pero no me convence por el uso de sintáctica "SQL-Like".

Tal ves sea por el "where" y el "select" que ciertamente le dan un sabor a SQL, pero la idea basica de LINQ no deriva de SQL, si no de la programacion funcional... de hecho, se pueden construir cosas similares en Scala, en Ocaml o en Haskell (o inclusive en Javascript).

No creo en lo absoluto que LINQ for SQL vaya a destronar a SQL para el manejo de fuentes de datos en un modelo relacional. La razón es simple como también es simple que nadie está dispuesto a escribir cálculo numérico en otro lenguaje que no sea FORTRAN si ese alguien necesita de muchas de las bibliotecas de funciones disponibles. Nadie está dispuesto a pagar billones de dólares por llevar lo que existe en FORTRAN a otro lenguaje.

SQL reina en el mundo de las bases de datos, pero como todo rey moderno sabe que muchos príncipes van a compartir sus feudos con éxito, y ese es el caso de LINQ for SQL. Ya tiene un lugar importante para el desarrollo de aplicaciones en .NET y ese lugar importante se debe a muchas cosas. Yo en lo personal, creo que parte de su éxito se debe a que ofrece un modelo de programación consistente para lidiar con tipos diversos de objetos y fuentes de datos.

Toda aquella tecnología -bien hecha por supuesto- que en estos días, ofrezca esa homogeneidad tiene las de ganar.

No es un problema de que me guste o no, de que ame a MS o lo odie. Es pragmatismo, que es lo que más abunda para que una tecnología en computación pase a formar parte del arsenal de los que construyen software.

Buena entrevista a Erik Meijer sobre LINQ.

Es que recordemos que Java de lejos es una plataforma para diseñadores de gráficos. Java tiene tanta gracia en el diseño de gráficos cómo la tiene python. Francamente yo creo que también esa es una ventaja de Flex y WPF. Pero sólo el tiempo es juez.

Ese sería en el mundo ideal. Sin embargo existe algo parecido en Play!:
 

Pues por eso dije: "me parece", lo que podemos cambiar por: "a mi parecer", o por: "de manera personal", o: "a mi me parece". Véase la diferencia con "es". Y no te preocupes, no me ofende, pero yo lo veo desde esa perspectiva y a mi me parece un raro dialecto "SQL-Like" (from, where, select).

Prefiero JPA, porque desde mi punto de vista lo considero más flexible que LINQ (creo que hasta hace poco LINQ únicamente soportaba MS SQL Server y había una empresa que hizo dicha funcionalidad para postgres, oracle y mysql; y era de pago). Con JPA es un estándar y tiene varias implementaciones; incluso creo que Hibernate tiene una version .NET (NHibernate, que la llegué a utilizar, porqué usabamos postgres y no había posibilidad de cambio a SQL Server de MS. Sin embargo creo que era sólo Hibernate, no JPA sobre Hibernate sobre .NET). A día de hoy no sé si ya sea nativo, con sólo cambiar el driver y algunas cosas en config.

Con lo de los PONO, pues no, creo que son más cómodos por el hecho de las propiedades:
 

Pero pues, te digo, de momento podrá LINQ ir a China; a mi personalmente no me convence LINQ. Dentro de la posibilidad que sea (o no) mejor que JPA, yo me quedo con JPA, por mi persepción. Vamos, es cómo decirle a una persona con un Mustang '68 que se comprara un Mustang 2011, muy probablemente el Mustan 2011 es más seguro, tiene mejor diseño, incluso más tecnología (GPS, Reconocimiento de voz), es más cómodo, etc. Sin embargo el Mustang '68 es un clásico y de buenas prestaciones.

Fue para ese ejemplo concreto. Sin embargo para ejemplos cómo el que tu dices, yo la verdad dudo que un arreglo sea necesario computarlo en 16 procesadores. En dado caso, ¿para qué existen las estructuras de datos y los algoritmos de búsqueda?; seguro que en Java debe haber algo similar (yo no conozco).

Con lo de paralelo, está chido, pero ¿es mucha la diferencia comparando con JPA? En sintáctica si, pero en funcionamiento (performance sobretodo). Y pues no dije que fuera un dialecto SQL, sólo que a mi me parece eso.

Ni se acerca, el ejemplo de Oscar, al igual que LINQ, implica verificacion estatica, este codigo es una simple cadena, que el compilador no puede verificar, por lo tanto muy inferior

Prefiero JPA, porque desde mi punto de vista lo considero más flexible que LINQ (creo que hasta hace poco LINQ únicamente soportaba MS SQL Server y había una empresa que hizo dicha funcionalidad para postgres, oracle y mysql; y era de pago)

Ya hay soporte, GRATUITO pare LINQ en todas esas bases de datos.

incluso creo que Hibernate tiene una version .NET (NHibernate, que la llegué a utilizar, porqué usabamos postgres y no había posibilidad de cambio a SQL Server de MS. Sin embargo creo que era sólo Hibernate, no JPA sobre Hibernate sobre .NET).

NHibernate soporta LINQ

Dentro de la posibilidad que sea (o no) mejor que JPA, yo me quedo con JPA, por mi persepción.

De acuerdo, si no te gusta, asi como tal vez no te gusta el helado de chocolate pero si el de vainilla, pues que se le va a hacer, todos tenemos nuestras creencias irracionales.

Fue para ese ejemplo concreto. Sin embargo para ejemplos cómo el que tu dices, yo la verdad dudo que un arreglo sea necesario computarlo en 16 procesadores.

Depende, alguna vez se creia que con 640K era suficiente para todas las necesidades de computo de una PC, ahorita tenemos equipos con 8Gb. Hoy dia, 16 procesadores suena a mucho, tal vez en 10 años tengamos PCs con 8000 procesadores, y algo que esta demostrado, es que la programacion funcional (estilo LINQ) es mucho mas adecuada para sistemas con alto grado de paralelismo que la programacion procedural.

En dado caso, ¿para qué existen las estructuras de datos y los algoritmos de búsqueda?; seguro que en Java debe haber algo similar (yo no conozco).

Pues no, no hay, digo, tal ves si haya mecanismo para buscar en paralelo en un arreglo, pero LINQ es mucho mas que eso.

Con lo de paralelo, está chido, pero ¿es mucha la diferencia comparando con JPA? En sintáctica si, pero en funcionamiento (performance sobretodo)

Pues, es paralelo, JPA ni siquiera puede filtrar en memoria, JPA requiere una base de datos, LINQ no, la base de datos es opcional.

¿Irracionales? ¿para quién?

Pues esperemos a F# (¿o ya está?), si lo que se busca es un enfoque funcional, veamos cómo funciona LINQ en un ambiente puramente funcional. De igual forma, de ser un enfoque así, creo que se le podría sacar mucho más provecho (incluso lo que se hace ahora, sería algo ordinario).

Pues esperemos a F# (¿o ya está?),

Ya esta.

si lo que se busca es un enfoque funcional, veamos cómo funciona LINQ en un ambiente puramente funcional

F#, basado en Ocaml, no es solo funcional, es al igual que C#, multiparadigma (aunque tiene mas caracteristicas funcionales que C#)

De igual forma, de ser un enfoque así, creo que se le podría sacar mucho más provecho (incluso lo que se hace ahora, sería algo ordinario).

No veo por que despreciar las caracteristicas funcionales de C# solo por que F# tiene mas...

¿Irracionales? ¿para quién?

Para cualquiera, si yo digo que me gusta mas el helado de vainilla que el de chocolate, asi, nada mas, y cuando me preguntan por que digo: "por que esa es mi percepcion", estoy siendo irracional, del mismo modo que tu dices "me gusta mas JPA, no importa que LINQ pueda hacer todo lo que hace JPA y mas, a mi me gusta mas JPA" y si te pregunto por que dices "por que esa es mi percepcion".

Si dieras alguna razon mas que "por que es tu percepción", entonces podrias estar en lo correcto, o estar equivocado, pero si reduces tu punto de vista a "eso es lo que percibo, por que lo que percibo es eso", entonces estas siendo irracional

No creo en lo absoluto que LINQ for SQL vaya a destronar a SQL para el manejo de fuentes de datos en un modelo relacional.

LINQ en si mismo no... pero su enfoque funcional para postergar la evaluacion de un fragmento de codigo, y reinterpretarlo de modo que pueda ser enviado a un motor de consultas remoto (algo que puede conseguirse tambine con Ocaml, o con Haskell) podrian llegar a destronar SQL... aunque no creo que en el futuro cercano.

La razón es simple como también es simple que nadie está dispuesto a escribir cálculo numérico en otro lenguaje que no sea FORTRAN si ese alguien necesita de muchas de las bibliotecas de funciones disponibles. Nadie está dispuesto a pagar billones de dólares por llevar lo que existe en FORTRAN a otro lenguaje.

De acuerdo, pero eso es lo maravilloso de este enfoque, que puede invocar a SQL (o algun otro origen de datos) si lo necesita

SQL reina en el mundo de las bases de datos, pero como todo rey moderno sabe que muchos príncipes van a compartir sus feudos con éxito, y ese es el caso de LINQ for SQL. Ya tiene un lugar importante para el desarrollo de aplicaciones en .NET y ese lugar importante se debe a muchas cosas. Yo en lo personal, creo que parte de su éxito se debe a que ofrece un modelo de programación consistente para lidiar con tipos diversos de objetos y fuentes de datos.

Toda aquella tecnología -bien hecha por supuesto- que en estos días, ofrezca esa homogeneidad tiene las de ganar.

Coincido completamente

No es un problema de que me guste o no, de que ame a MS o lo odie. Es pragmatismo, que es lo que más abunda para que una tecnología en
computación pase a formar parte del arsenal de los que construyen software.

Exacto, a mi me gusta el enfoque de LINQ, y las posiblidades que abre, y me encantaria ver algo asi en Java, O ver el nacimiento de un lenguaje tipo Rel pero funcional ( algo como Datalog, pero con una sintaxis mas amigable)

Es probable que sea yo el que "más peina canas" en este sitio, y por esa razón me permito dar un consejo a los más jóvenes.

Para evaluar y dar opiniones de las nuevas ideas que se materializan, siempre es obligatorio conocer con profundidad los cimientos de esas nuevas ideas. Conocer sobre todo los fundamentos teóricos en los que se sustentan que siempre serán los más importantes. Más importantes, por ejemplo, de la sintaxis y lo bonito si se trata de un lenguaje de programación o de extensiones a ésta.
Los fundamentos teóricos siempre van a estar ahí, y la sintaxis va a cambiar con el tiempo, para acoplarse a las necesidades de los programadores.
Algunas de las discusiones en este hilo relativas a LINQ, se han basado solamente en lo bonito o feo que puede resultar su sintaxis actual, cuando lo que en mi opinión es relevante, son los hombros de los gigantes en los que se pararon los que diseñaron esta técnica, donde destaca sobremanera los que han aportado tanto a la programación funcional. Gente que ha ido contra corriente durante muchos años y que gracias a sus aportes científicos han logrado que ese estilo de programación sea en la actualidad algo que todos los lenguajes imperativos quieren incorporar. Y no es moda; es una mirada a las "mieles" de la computación.

Hay mucha información en la red sobre los fundamentos de LINQ. Conviene darle un vistazo a quienes son sus creadores, quienes lo han incorporado a C#, cómo aprovecharon lo realizado en Cw(C omega) y otros proyectos de investigación de gran calibre.

No puede valorarse LINQ si no se conoce lo que es la programación funcional. No es necesario que LINQ opaque a otras cosas para considerarlo como algo bueno que vale mucho la pena conocer. Todo cabe en la viña del señor.

De seguro, los que conocen la programación funcional y programan en un lenguaje imperativo, son mucho mejores programadores que los que no la conocen.

¿Una clase de programación funcional? Quien mejor que Erik Meijer (entre otros).

Yeap, sé que se parece pero LINQ tiene más transformación por debajo.

En mi ejemplo:

sería:

Es decir, algo que todos los programadores de Java conocen ( o de un lenguaje objeto "punto" metodo conocen ) sin más complejidad!

Mientras que en LINQ sería:
 
Lo cual es sintactic sugar para:

El   es un closure en C#.

( Breve interludio sobre como se escriben los closures/blocks/funciones anónimas en otros lenguajes - y no nos metamos por ahora en purezas entre las diferencias entre funciones anónimas closures, first class functions y bloques. Son pa'pronto con cachos de código que se pueden usar como si fueran variables )

En Ruby es
 
En Smalltalk ( llamados blocks )
 
En Groovy
 
En Javascript es
 
En Ryz es  

Continuamos, entonces las partes serían:

So far so good, sigue siendo la misma interfaz uniforme, aunque ahora involucra este nuevo concepto de closure ( nuevo para los Javeros,claro porque en otros lenguajes existen desde hace mucho en fin )

Así, si parecen ser iguales, pero aquí viene la queja, ¿por que si son similares, se introduce este nuevo features en el lenguaje! ( C# en este caso ) para hacer que luzca más como SQL?
La razón: porque es algo más reconocido.

Pero entonces se aleja de lo que a mí me gustaría "Algo que ni se le parezca" por algo que se le parece demasiado.

La transformación del lenguaje "integrado" ( LINQ significa Language Integrated Query ) lo transforma en esto:

Iack! demasiada magia en un solo paso.

Esta magia, no cabe duda es lo que tanto gusta a los programadores, porque le quita chamba al que escribe, transladandola al compilador ( lo cual es bueno ) pero al hacerlo introduce nueva complejidad en el lenguaje ( lo cual NO es necesariamente mala ) pero crea confusión en los nuevos programadores ( para muestra este post, aunque ya sé que aquí no semos .neteros ) y crea la necesidad de decir: "esto es SQL, no no lo es,si es pero acá,y allá y etc".

Lo mejor en diseño de interfaces de usuario es que simple es mejor ( alguién compare IE6 vs. Chrome ) En lenguajes de programación la sintaxis es la interfaz.

Claaaaaro, crear un balance entre simplicidad y funcionalidad es muy complejo.