¿Por qué C # tiene muchas más funciones que Java? [cerrado]

14

Tenga en cuenta que esto no pretende ser un argumento Java vs. C #. Soy un programador de Java sin experiencia en C #, preguntando solo por curiosidad.

Leí un poco en C #, y parece que tiene muchas más funciones que Java. Una serie de ejemplos:

  • Tipo de inferencia.
  • dynamic palabra clave.
  • Delegados
  • Parámetros opcionales
  • Lambda y LINQ (en realidad no tengo idea de cuáles son).
  • Propiedades.

Sin embargo, Java realmente no presenta nada que C # no tenga.

Mi pregunta es: ¿por qué C # tiene muchas más características nativas que Java? ¿Y por qué Java no agregó algunos de estos a lo largo de los años, por ejemplo, Propiedades o inferencia de tipos? ¿Los diseñadores del lenguaje Java toman un enfoque más simplista? ¿Cuál es la razón para esto?

Aviv Cohn
fuente
2
@Patrick: ¿es una característica o un detalle de implementación?
Pete
14
Respuesta sesgada: porque el equipo de diseño de C # sabe lo que está haciendo. Respuesta más razonable: C # fue diseñado con el conocimiento de las fallas de Java y sin el dogmático "solo OO puro" (que ni siquiera alcanzaron). La mitad de esas características se importaron en masa de Lisp y Haskell, dos lenguajes en los que Java se negó firmemente a inspirarse hasta Java 8, y los otros son mejoras en la cordura que la falta de Java hizo cegadoramente obvia.
Phoshi
44
Debido a que C # llegó más tarde e inicialmente fue una estafa flagrante de Java, y luego tuvo la oportunidad de agregar todo lo que resultó valioso, además, mientras que Java se vio obstaculizado por objetivos muy estrictos de compatibilidad con versiones anteriores.
Kilian Foth
2
@ Clockwork-Muse pero C # tiene dos implementaciones de tiempo de ejecución: CLR y Mono. También está Xamarin. No he oído hablar de una solución única para construir proyectos cruzados de iOS / Android / WinPhone usando Java.
Den
44
@KilianFoth: En realidad, C # fue inicialmente una estafa de Delphi , reescrita para parecerse a Java. Microsoft incluso saqueó al arquitecto del proyecto Delphi de Borland para crearlo.
Mason Wheeler

Respuestas:

22

Muchas rasones:

  1. C # llegó más tarde que Java; la versión 1 era una estafa flagrante de Java 1.4, por lo que prácticamente tenía todo lo que Java tenía en ese momento.
  2. Pero luego C # se desarrolló mucho más rápido que Java, porque era una plataforma nueva y emocionante (y tenía un controlador absolutamente brillante en Anders Hejlsberg, el padre de Turbo Pascal). Eso les permitió evitar todos los errores en Java que se habían vuelto obvios, al tiempo que agregaban todo lo que los practicantes de Java deseaban tener.
  3. Mientras tanto, Java se vio obstaculizado por objetivos de compatibilidad con versiones anteriores muy estrictos y por un ritmo de desarrollo algo más lento, en parte porque trató desesperadamente de ganar una reputación de ser la solución estándar, empresarial, confiable y no sorprendente para el 95% de los no genios programadores En esto tuvieron éxito, quizás un poco demasiado bien.

El resultado es que Java ahora tiene una pequeña brecha de características. Tiene grandes planes para el futuro, pero como es habitual con este tipo de cosas, todo lleva un poco más de tiempo de lo planeado.

Kilian Foth
fuente
77
No estoy seguro de estar de acuerdo con esto. Quiero decir que todo es cierto, pero sospecho que la razón tiene más que ver con la política en torno al colapso del Sol. Básicamente, Java tenía más de 5 años donde no había organización / liderazgo, por lo que no había nuevas características.
Telastyn el
77
C # 1 tenía tipos de valor. Algo que Java nunca tendrá. Así que no es solo una "estafa descarada".
Den
1
@Telastyn: creo que esa es la razón más importante aquí. Especialmente cuando agregas "y luego te adquiere el oráculo" al final del colapso del Sol.
Wyatt Barnett
77
De acuerdo con @Den. Creo que la razón más importante para que C # se desarrolle más rápido (y en la dirección correcta) es el liderazgo de Anders Hejlsberg. Él y su equipo agregaron las mejores funciones de otros lenguajes y lograron integrarlas sin problemas en C #. El resultado es que C # tiene características de lenguaje muy ordenadas sin sentirse desordenado o desordenado.
David Kirkland
1
@WesleyWiser - actualizado a "podría tener en el futuro".
Den
4

Agregaría a la respuesta de Kilian que una gran diferencia entre Java y C # es que los diseñadores de C # controlan no solo el lenguaje, sino también el IDE estándar.

Agregar algo como métodos de extensión y clases parciales podría ser una pesadilla en el control de versiones de desarrollo / control si los IDE no lo admitieran adecuadamente.

Como se espera que pueda compilar Java con su plataforma de elección (Eclipse, Netbeans, vi + Ant), agregar funciones que rompan el código (y usarlas para desarrollar extensiones adicionales como LINQ) es mucho más complicado que decir " Como IntelliSense se ocupará de estos casos, no debemos preocuparnos ".

Además, a veces vale la pena señalar el valor de las características en lugar de su número. Por ejemplo, las propiedades automáticas son agradables y ciertamente desearía que Java lo admitiera, pero al final solo significa que tiene que escribir algunas líneas más de código en Java. De manera similar, encuentro que llamar a "Eventos" una característica es algo inapropiado, ya que son poco más que delegados especialmente etiquetados, y solo una copia refinada del patrón de Observador ya utilizado por Java (por otra parte, en Java necesita más información explícita codificación)

No me malinterpreten, creo que C # ha introducido varias innovaciones notables, y deseo que algún día los grandes jefes de Oracle se despierten y lancen un verdadero "Java 2" para incluir algunos de estos, pero la brecha no es tan obvia como su puntos de pregunta

SJuan76
fuente
2
Las nueve líneas necesarias para una definición de propiedad simple (declaración + get / set + espacio en blanco) se suman rápidamente a más de "unos pocos".
Kevin Cline
@kevincline y yo también documentamos correctamente tanto los setters como los getters. Pero al final, incluso si no estoy usando mi generación automática de código IDE para el descriptor de acceso, no estoy usando ninguna cantidad de tiempo notable con estos, cuando tomas en cuenta el tiempo dedicado a la lógica comercial, las pruebas y el diseño del código (de hecho Estoy pensando principalmente en esto incluso cuando escribo los accesos). Entonces, si bien es agradable, no es algo que haga una gran diferencia al final ...
SJuan76
3
No es el momento de escribirlos. Es el momento de leerlos e ignorarlos, una y otra y otra vez, mientras se dirige a las partes interesantes.
Kevin Cline
@kevincline Estoy de acuerdo, es casi legible y el código está limpio. Esta es la razón por la que valoro cosas como los Eventos, que son solo un patrón de Observador incorporado, pero hacen las cosas mucho más limpias si tuviera que escribirlas usted mismo
Aviv Cohn
@AvivCohn La cuestión es que "incorporada" es la parte clave. Puede tener un despacho dinámico en el ensamblaje, puede tener funciones de orden superior en C, cada característica de lenguaje que pueda tener es posible en el ensamblaje, obviamente, ya que en algún momento, todavía se ejecuta en su CPU x86. Raramente necesita implementar el patrón de Comando en C #, porque tiene delegados. Lo mismo con Observer y eventos, y muchos otros. Java tuvo métodos anónimos durante algún tiempo, pero tuvo que crear un tipo anónimo completo . Todas esas cosas son pequeñas, pero suman.
Luaan