Java vs Python / Ruby

en Java
TU PANEL DE CONTROL:
REGISTRAR
Wilkinsonpc Tienda Productos Servicios Recursos Gratuitos - Gratis Soporte Comunidad
Foros Qubitaria Ayuda de los Foros
Retroceder   Foros Comunidad : Diseño Web y Programación : Java

Java vs Python / Ruby

Compartir

C + + vs Java vs Python vs Ruby: una primera impresión
Resumen Ejecutivo

Soy un programador de lenguaje oficial agnóstico. Yo no soy un fan de un idioma determinado (casi digo "fanboy"), pero eso es un poco inflamatorias). Sólo quiero escribir programas útiles y divertirse haciéndolo. Sé que C + + y Java bastante bien. Hice algunos trabajos para principiantes en Python y Ruby. Entonces vino para arriba con las siguientes conclusiones. Pero antes de que usted llama, lea el artículo completo.

Ir a la derecha a la comparación lado a lado

* C + + vs Java
recogida de basura de Java es el gran aumento de la productividad
Java es significativamente más lento que C + +
C + + es (mucho) más difícil de codificar correctamente que cualquiera de los otros
* Java vs Python / Ruby
Python / Ruby interpreta ejecución y tipado dinámico son las grandes ganancias de productividad sobre Java.
Python / Ruby son más lentas que Java
Python / Ruby los programas deben andamios menos del exterior (código más limpio)
Hay dos concesiones importantes: [interpretado vs compilado] y [tipos estáticos vs dinámicos]
* Python vs Ruby
casi equivalente

intro

Cuando se ejecuta varias distribuciones de Linux, siempre me encontré con la elección de KDE o GNOME. Hay un montón de los defensores de ambos lados, pero no había una autoridad superior. Luego recientemente Linus Torvalds salió con una opinión definitiva. Él tomó la posición inequívoca de que KDE es el mejor. No es que no es necesariamente el árbitro final de interfaces de usuario, pero al menos ofrece un fuerte Datapoint, y puesto que él es más inteligente que yo y como todos los demás opiniones parecen provenir de fuentes de sesgo, yo Ahora puede elegir KDE y sentirse mejor consigo mismo. Parafraseando el viejo criterio de IBM, "nadie fue despedido nunca para los siguientes una directiva de Linus. Je, después de todo lo que resultó que quería utilizar Ubuntu, que funciona mejor con GNOME para Terminé con eso por ahora. Así, "más práctico" ganó más de lo mejor ".

Mientras tanto, me di cuenta de que tenía que aprender un nuevo idioma y el zumbido es actual Python y Ruby. Una vez más no pude encontrar una respuesta definitiva de los cuales uno es el mejor. De todos los rumores, Se me ocurrió una vaga impresión de que Ruby es más puro y se establece para ganar en el largo plazo, pero que Python es actualmente más práctico por ahora. Y Google utiliza Python, que Datapoint es una importante. No son idiotas por ahí.

Para ver lo que pude averiguar yo, me decidí a codificar algo en Java, entonces el puerto de Python y Ruby y ver cómo me sentía por cada uno, y tratar de identificar el lugar de grandes ganancias son para cada idioma.

Una advertencia. Si algo importante que falta en un lenguaje, como recolección de basura, entonces no quiero escuchar una respuesta que dice "Bien, si utiliza la colección de XYZ incompatible, o si no la técnica ABC complicado, entonces usted puede hacer el lo mismo en [ponga el nombre de lenguaje aquí] ". Estoy tratando de evaluar el estándar aquí, ya que, por supuesto, probablemente puede hacer cualquier cosa en cualquier idioma, incluyendo ensamblador si trabaja lo suficientemente duro. Y el problema con el uso de un estándar biblioteca no es sólo el trabajo de integración extra, es que usted basa su código en algo que puede quedan en el camino más adelante y luego le pegan. A veces vale la pena, pero que se tiene que probar sobre una base caso por caso en lo que a mí respecta.

historia

Empecé en la C en 1985, aprendió C + + en 1990 (Zortech C + +) y lo han estado utilizando desde entonces. Me enteré de Java a mediados de los 90's cuando fue la primera que sale, y encontró tres gran victoria para Java sobre C + +: La recolección de basura, portabilidad y simplicidad. La recolección de basura y la simplicidad creado grandes ganancias de productividad, y la portabilidad es la portabilidad. No haber hecho una recopilación de elementos del lenguaje antes, el aumento de la productividad fue evidente. La sencillez de Java sobre C + + fue realmente agradable. Al codificar C + +, necesitaba efectivo Meyer C + + en mi escritorio en todo momento para asegurarse de que no estaba invocando alguna conversión de tipos extraños o copiar constructor / operador de asignación anomalía. Y no se incluso comenzar con las plantillas. Con Java no necesitaba eso porque es más simple. Y las bibliotecas de Java eran más completos y manejo de cadenas fue más fácil. Así que en general estaba más productiva de codificación de distancia en Java. Yo todavía le gustaba C + +, pero parece que cuando la programación C + +, la diversión está en descubrir la lengua y la biblioteca , Como resolver un rompecabezas. Eso deja menos tiempo para dedicarse a resolver el problema de dominio de aplicación.
el código

Los ejemplos de código adjunta son implementaciones de un algoritmo de árbol Rojo-Negro adaptado de las descripciones en "Algoritmos en C + +", Sedgewick y la "Introducción a los Algoritmos", Cormen / Leiserson / Rivest. Escogí este porque era corto, pero había cierta complejidad.

toma nota de código y renuncias:

* comentarios son más escasas de lo habitual para evitar el oscurecimiento de código
* Probablemente cometió algunos errores de convenciones en Python y debido a la ignorancia de los idiomas adecuada Ruby
* todos estos programas de compilación y / o ejecutar, sin aviso y salida el mismo resultado
* Creo que los programas son correctos. puede haber errores, pero lo que si están en las 3 versiones
* Java SDK 5.0, Python 2.4, 1.8.3 Ruby, C + + Microsoft Visual C + + 2005

* Comparar en paralelo
* Implementación de Java
* Python aplicación
* Ruby aplicación
* C + + aplicación
* zip archivo de código fuente

portar

Fue sorprendentemente fácil de portar el código Java a Python y el puerto de Python Ruby. Mucho de esto era regular expresión de búsqueda y reemplazo, conseguir algún derecho convenciones de nomenclatura y adaptarse a un idioma pocas diferencias. Durante el proceso de transferencia, los dos grandes trampas me encontré fueron Python bloque sangría errores y Ruby es horrible diagnóstico del compilador.

Portar el código Java a C + + es mucho más una molestia. Traté de hacer uso de gran parte como la comprobación de tipo estático mecanismos que pude. En Java que utilizan los genéricos para el árbol, y en C + + que utiliza plantillas para el envase y 'Const' en su caso. Las trampas grandes en portar a C + + son:

* La dicotomía entre tipos primitivos y objetos en C + + es mucho más pronunciada aún que Java (y Java está en peor situación que Python o Ruby). Esta dicotomía hace que sea difícil escribir una clase que soporta tanto primitivos y objetos. Mi aplicación puede ser que necesite algunas composturas para trabajar con objetos en lugar de 'int'.
* Java, Ruby y Python todos utilizan un único sistema coherente de referencia para referirse a objetos que siempre están en el montón o su equivalente. En C + +, se puede tener una forma estática objetos declarados, un puntero a un objeto, o una referencia a un objeto, cada uno con características y limitaciones. Una referencia de C + + es no es lo mismo como referencia en los demás idiomas. C + + realmente quiere que usted use punteros. Estas alternativas significa que cuando se escribe algo en C + + que tienes que subir con una estrategia coherente para el uso de los 3 tipos de acceso a objetos, y su estrategia podría no ser el mismo que lo que otros prefieren. Hay es «más que una manera de hacerlo".
* La falta de mecanismos integrados o, simplemente, convenciones para las operaciones que deben ser comunes en todos los tipos medios usted tiene que hacer las cosas. Al igual que la conversión de un tipo de representación de cadena. Todas las demás lenguas cuentan con el apoyo de un tipo u otro, pero en C + + tienes que hacer tu propia convención
* Tal vez este soy yo, pero C + + siempre te deja pensando lo que podría haber hecho mal. Es difícil de decir. Si usted lee eficaz Meyer C + + ves que hay cosas de infraestructura detalladas, numerosas como los constructores y los operadores de asignación que tiene para obtener exactamente la derecha o las cosas no en tiempo de ejecución. C + + es muy difícil que salga bien, y nunca me siento totalmente segura de que lo hice correctamente

En mi opinión (y he escrito un montón de C + +), el uso de C + + sólo cuando usted tiene que para la compatibilidad o razones de rendimiento, o donde usted decida arbitrariamente que prefiere usar C + + porque es más divertido porque es más dificil. Como Tom Cargill (un conocido hombre de C + +) dijo: "Si usted piensa que C + + no es demasiado complicado, sólo lo que es una protección de base abstracta pura destructor virtual privada virtual y cuando fue la última vez que lo necesitaba?".
python bloque de sangría

Me tomó un tiempo para que mi editor (JEdit) feliz con Python y llegar a no utilizar tabuladores. Afortunadamente Nunca jodido el archivo tan malo que el código no funcionó pero siempre tuve una desagradable incertidumbre acerca de la hendidura cocer a fuego lento en el fondo. Algunos (o todos) de este puede ser el prejuicio. Me gustó mucho mejores apoyos que cualquiera de los Do-Ruby o Python Fin sangrado, por lo menos cuando yo estaba de codificación. Por otra parte, una adecuada sangría archivo de Python se parece mucho mucho más limpio y más fácil de leer que cualquiera de los otros, porque no es necesario cerrar todos los símbolos de bloque. Sin embargo el explícito "yo" argumento hace que parezca menos limpias de lo que podía.
errores de sintaxis de Ruby

Muchos de los diagnósticos del compilador que recibimos durante el portar Ruby se limitó a decir "error de sintaxis" y le dio el número de línea de la última línea en el archivo. Gran. Pasé mucho tiempo haciendo búsquedas binario en mi código para encontrar la fuente de error.
El patrón de visitante

Una cosa que hice de manera diferente en cada lengua se tratan de adaptar una pauta de Visitantes (para recorrer el árbol) para el idioma preferido para cada idioma. Usted podría, por supuesto, simplemente el código de una clase de visitante que es casi idéntica para cada idioma, sino que hice lo siguiente.

* Java: un régimen de ayudas: una clase anónima la aplicación de una interfaz predefinida.
* Python: dos regímenes: una clase llamada similar a Java y sólo una función llamada pasa como un parámetro.
* Ruby: dos regímenes: uno lamba función anónima, y la aplicación de un bloque de Ruby

El Java y C + + enfoques darle la comprobación de tipos estáticos, sino que toma mucho más cruft para ponerse en marcha. Encontré el Python llamado parámetro de función muy conveniente. Pero no lleva a ningún estado por lo que si Estado necesita, entonces utilizar una clase. Sorprendentemente, encontré la lambda Ruby más fácil entender y aplicar que bloquear el Ruby ". Esto se debe a mi algoritmo de recorrido es recursiva, y el lambda sólo se pasa alrededor como un parámetro (como la pitón llamada función de parámetros). No explotar las potencial de un cierre de lambda.

El esquema de bloques de Ruby (juego de palabras no tiene por objeto) requiere una sintaxis complicada en las llamadas recursivas, y No pude encontrar una buena explicación de cómo manejar el uso recursivo de bloques en la documentación de Ruby. He descubierto una web single de éxito con un ejemplo y después de tocar el violín con él lo puso a trabajar. Creo que los entiendo ahora, pero es todavía un poco difusa. Quiero decir, sé qué hacer ahora, pero se necesita una cierta concentración de averiguar qué es exactamente lo que está sucediendo y por qué el aspecto del código que lo hace. He encontrado que el ver un bloque de Ruby como co-rutina (por la documentación) y no como una subrutina para ser la mejor manera para entender todo el asunto.

Todo lo que dijo acerca de los visitantes, soy un Python / Ruby para principiantes, posiblemente, hice cosas de la manera difícil
interpretarse vs compilado

Siempre ha habido este sacrificio. De hecho, el Python / Ruby vs controversia rendimiento de Java ™ se parece mucho a la C / ensamblador / Forth los debates en el mundo de sistemas integrados a principios de 1980. Forth fue interpretada, no era necesario elaborar un ciclo y que tenía (supuestamente) características que mejoran la productividad que C no tenía. ciclos de desarrollo son mucho más corto con Forth. El rendimiento fue no tan rápido como C o ensamblador, pero estuvo cerca. El inconveniente de Forth era la rareza de la lengua. C ganó y Forth fue al rincón oscuro de las lenguas sobre todo olvidado.

Los lenguajes interpretados darle un ciclo de desarrollo mucho más rápido, especialmente en los grandes programas. No hay duda de eso. Su simplemente una concesión recíproca de la velocidad de ejecución frente a la productividad. Algunas aplicaciones necesitan la velocidad. Creo que es una optimización prematuro decir el "yo como C / Java mejor que Python / Ruby, ya que ejecutan más rápido". Interpretado es mejor si lo puede conseguir. Cuando estuve probando el código que experimenté la ventaja de interpretar. Yo no mide realmente el rendimiento, pero otras fuentes muestran las diferencias. Pero como Python / Ruby parecen interfaz con C / C + + muy fácil, yo sería muy cómodo trabajando en el mundo interpretado y descendente en el inframundo de compilados C / C + + cuando sea necesario. Sí, Python en realidad es compilado para una máquina virtual, pero usted no tiene una compilación explícita funcionar de manera que actúa para el usuario como un lenguaje interpretado.
tipo estático vs control dinámico

Ok, me gusta el aumento de productividad que ofrecen los tipos dinámicos, ya que elimina una gran cantidad de andamios. He descubierto es muy interesante ver los errores de salir en tiempo de ejecución que normalmente se tiempo de compilación en C + + / Java. Estos errores de tiempo de ejecución se obviamente influidos por las trayectorias en el programa de prueba (o hasta qué punto lo consiguió antes de que vomitaba). Para todo el ciclo, Yo no veía con claridad todas las instancias de esta clase de errores, ya me gustaría tener con la comprobación de tipos estáticos.

Viniendo de un conocimiento de la lengua tipos estáticos, mi tripa dice que tipado dinámico crea un riesgo. El Python / Ruby bloggers decir que si usted sólo prueba la unidad correctamente, entonces no hay problema. Brücke Eckel tiene una bien razonada ensayo sobre el tema. Yo diría que la prueba esperando unidad para recoger las erratas de mecanografía tiene dos problemas:

* de un sistema muy grande, es difícil de probar de forma exhaustiva
* pruebas para la corrección del tipo hace que el programador hacer el trabajo que una computadora podría hacer

Nos typers estática puede estar equivocado. Tuve una experiencia similar a pasar de PVCS De control de versiones Subversion. ¡Oh, Mi Dios, sin bloqueo? El código será completamente en ruinas en una semana. Pero resultó ser un no-tema y agregó Subversion así la fricción y mucho menos para el ciclo de desarrollo que la productividad se ha mejorado tal vez 10%. La buena experiencia colectiva pesaban más que las predjudice base teórica "prueba". El mismo argumento se puede hacer para tipado dinámico vs estática.

No me importaría una pelusa por separado "herramienta" para Python / Ruby (¿es posible?). Yo uso pelusa para C / C + + religiosamente. El conjunto comunidad compilado el idioma se está moviendo hacia una mayor comprobación de tipos estáticos (Java Generics, por ejemplo) en lugar de menos. ¿Son todos idiotas? (No responder a esta)

Mi conclusión es que duck typing "dinámico" es más productivo, más agradable, da más limpia buscando el código pero incurre en un riesgo de que usted obtendrá una excepción de tipo en tiempo de ejecución en su aplicación en una fecha posterior. El riesgo está ahí, dejar de fumar se puede negar.
los resultados

Estos resultados están destinadas a cubrir los temas me di cuenta en el portar / I prueba lo hizo. No es una evaluación global. Si yo cosas mencionar que no se ha ejecutado en la mano primero, y luego tirar eso.
C + + vs Java

1. La recolección de basura es la gran victoria para Java.
2. simplicidad Java sobre C + + complejidad es una gran victoria para Java.
3. C + + es mucho más difícil de escribir y hacerlo bien de Java o de cualquiera de las otras opciones
4. C / C + + es mucho más rápido que Java
5. Requisitos lingüísticos andamios son similares para ambos
6. C / C + + es el único camino a seguir para el bajo nivel de programación de sistemas.

Java vs Python / Ruby

1. interpretarse vs compilado es una gran victoria para la productividad Python / Ruby
2. tipado dinámico de la productividad es una gran victoria para Python / Ruby
3. Java es mucho más rápido que Python o Ruby
4. andamios mínimo es una gran victoria para la productividad Python / Ruby. Hace más de programación no es agradable tener que construir toda la infraestructura.
5. sobre todo funciones de primera clase una gran victoria para Python / Ruby.
6. listas integradas / arrays y hashes / diccionarios una gran victoria sobre Java [] y colecciones de las bibliotecas base. Java 5.0 corrige algunos de esto, pero en las colecciones de Java aún parecen insertan en lugar de integrados.
7. carga dinámica de código en Python / Ruby es una gran victoria. Sí, puede hacerlo en Java, pero de nuevo, la costra.
8. Ruby integridad OO en Java dicotomía entre tipos primitivos frente a objetos es una gran victoria para Ruby, no tanto para Python.
9. Hay una cierta rareza en Python y Ruby alcance léxica de los nombres. La documentación de cada uno tiene varias advertencias sobre los casos extremos donde los nombres se unen en la forma esperada. Esto me da una sensación de náuseas, aunque en la práctica puede no importar. Otra victoria para la comprobación de tipos estáticos.
10. Comparable 'Java' interfaz fea en comparación con Python construido / Ruby en los mecanismos de comparación que sólo requieren que una sola función a aplicarse para obtener el conjunto completo de operadores de comparación. Un ejemplo de exceso de Java andamios.
11. la falta de comentarios de varias líneas en Python / Ruby estaba molesto

Soluciones de compromiso

1. tipos estáticos es una victoria para la corrección de Java, especialmente con los genéricos en 5,0. El C + + / Java es la tendencia más fuerte hacia la comprobación de tipos estáticos, no menos
2. tipado dinámico de la productividad es una victoria para Python / Ruby a costa de cierto riesgo
3. interpretarse vs oficios, compilada en velocidad de ejecución de los ciclos de desarrollo más cortos.

Python vs Ruby

ninguno de estos son tan importantes
PYTHON WINS

1. compilador de Ruby / Mensajes de error de ejecución en su mayoría "error de sintaxis" sin ninguna ayuda. en muchos casos casi inútil
2. ¿Por qué rescatar a usar Ruby / garantizar que en el resto del mundo se ha establecido en try / catch / finally? Quiero decir, su arbitraria elección ¿por qué no siguen la convención general?
3. Una vez que el sangrado es correcto, un programa de Python es la más limpia buscando

RUBY WINS

1. cierto malestar en Python vs Ruby explícita sangría 'end'. probablemente un predjudice.
2. obligación explícita de Python para "yo" parámetro a los métodos y el acceso variable de instancia es muy molesto
3. Ruby integridad OO es una victoria sobre Python.

EQUIVALENTE

1. bloques de Ruby / lambda / rendimiento parecía equivale más o menos (para mí) a la clase llamada Python o función. ¿No parece una gran victoria al ser capaz de escribir una función anónima en línea. De hecho, uno podría argumentar que el anonimato clases / funciones / lambdas reducir la capacidad de prueba porque no puede ser probado independientemente del código que contiene. Pero el Por otra parte no estaba usando lambdas en el sentido más completo, en el que pueden actuar sobre el medio ambiente que contiene de tal manera que una función llamada no puede.

Un pensamiento final sobre C + +. Para mí, el C + + Biblioteca de plantillas estándar se distingue de las bibliotecas de otro idioma ya que parece ser mucho más matemáticamente pensada. Los contenedores y los algoritmos de la STL tienen garantías explícitas complejidad de tiempo de ejecución. No parece a la ciencia mucho más equipo en la STL que en las bibliotecas de otro idioma. Java es algo así como que, mientras que Ruby y las bibliotecas de Python parecen mucho más ad-hoc. Esto probablemente tiene mucho que ver con su comunidad de código abierto conducido acercamiento a las bibliotecas. Me gusta mucho como la STL fue pensado y diseñado.
conclusión

Java es más productivo que C / C + +. Utilice C / C + + cuando el acceso speed metal o desnudo se pide. Python / Ruby es más productivo que Java y más agradable al código pulg Hay una gran pregunta sobre tipos estáticos vs dinámicos. Yo sostengo que tipos estáticos tiene que ser mejor a los efectos de la corrección del programa, pero la costra reduce la productividad requerida. Si la práctica real en las grandes muestra los sistemas que en tiempo de ejecución hecho de escribir errores no se producen a menudo y lo compensan la productividad, entonces yo someterse a tipado dinámico. No puedo encontrar una respuesta definitiva a Python vs Ruby. Parecen muy equivalente. ¿Podría escoger en base a lo práctico en una situación dada. Mi sensación general es que Python me molestaba de manera que Ruby no lo hizo, pero creo que esas molestias desaparecerían si yo estaba usando Python todo el tiempo.

Mierda, el objetivo era elegir Python o Ruby, pero estoy de vuelta donde empecé.
Compartir
  #1  
Creado: 08-Apr-2010, a las 00:48 Vistas: 13614
Creado por: svyatoslav svyatoslav está desconectado (29-March-2010 | Colombia | 1.618 Mensajes.)
Respuesta

Etiquetas
comparativa, java vs c ++, java vs python, java vs ruby, lenguajes programacion


Temas Similares
» Java 6 Update 21 0
» Múltiples vulnerabilidades en Sun Java 0
» problemas al bajar java 0
» Nuevo! Java de SUN 1.6 Update 2 0
» Vulnerabilidad en Java Web Start de Sun Java 0
» problemas con java 0
» Nuevo! Java de SUN 1.5.0_10 0
» Nuevo Java de SUN 1.5.0_07 0
» Deserialización provoca DoS en Sun Java JRE 0
» Dos graves fallos de Java 0


« - | - »
Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Ir al Foro


» ComuniDAD
Inicio
Noticias de Actualidad
Apuntes, Monografias y Tareas
Telefonia, Celulares, TV, GPS, ISP, PDA
Programas Windows, Mac, Linux, etc.
Hardware, Electronica y Redes
Diseño Web y Programacion
Internet y Grandes Portales
Juegos, Consolas y Emuladores
Multimedia, Diseño y Animaciones
Peliculas, Series, Musica, Trailers, Videos, Parodias
Seguridad y Spyware
Salud, Bienestar, Familia y Esparcimiento
Economia, Negocios y Asuntos Legales
Hoteles, Viajes y Turismo
Mundo a Motor [Motos, Autos, etc]
Foros Generales (OFF TOPIC)
Calendario de Eventos
Administracion ComuniDAD



Ultimos Temas

100% acquista arabia buy [email protected] certificados certificates certificati comprar database esol exams gmat idp ids ielts [email protected] kilan nebosh onlin original originale registered saudí similares skype spain toefl verifiable verificabili verificables whatsapp yates

La franja horaria es GMT -5. Ahora son las 08:07.


2010 ©
Powered by : vBulletin® Versión 3.8.8 Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
Sitemap 1 - Sitemap 2 - Sitemap 3 - Sitemap 4