No te confundas, no estaba hablando de J2EE. Estaba hablando de Java. Estamos comparando lenguajes, no frameworks. En estado puro... Ruby NO TIENE THREADS. Esa simulacion que tiene no pasa de ser un jugete. Eso lo borra de mi lista. No threads->No escalable . (De forma general, me refiero... Siempre puedes currarte un Big Loop muy especifico para algun servidor. Pero entonces ByeBye Rails y cualquier intento de generalizacion y codear facil). En cuanto a los tipicos "problemas" de Java.
-No hay herencias multiples por que SON un LIO. No porque la gente se lie. Y hace el compilador terriblemente complicado y lento solo para soportar un paradigma que solo sirve para que los C++ eros se ahorren 4 cut's an paste a costa de la claridad de la estructura. (Y que al final, NADIE acaba usando en serio) -"No hay preprocesador"... "que es el arma preferida de los ofuscadores de codigo". Ahí te has retratao:) . Pero te equivocas, si hay preprocesadores, pero no son "oficiales". A mi nunca me ha hecho falta... En C++ es mas util porque NO ES INTERPRETADO. Y ciertas cosas que en Java se pueden hacer en Runtime, en C++ NO y se tiene que PREPROCESSAR para diferentes arquitecturas/Opciones. -Yo veo las referencias a funciones como un truco sucio para suplir la mala ingenieria. Lo que tu llamas sobreingenieria, es lo minimo imprescindible para trabajar en EQUIPO en una EMPRESA en la que te tienes que poner DE ACUERDO en algo.
Y Java no tiene procesos que son mas faciles de gestionar en un Unix. Aparte de que la implementacion de Threads (hasta la 1.4 al menos) deja bastante que desear. ¿Como puedes matar un hilo chungo en Java? Haciendolo bien su codigo no es la solución si ofreces hosting. Usar interrupt tampoco lo es (funciona cuando quiere). Esto hay que reconocer que PHP lo tiene logrado.
-No hay herencias multiples por que SON un LIO. No porque la gente se lie. Y hace el compilador terriblemente complicado y lento solo para soportar un paradigma que solo sirve para que los C++ eros se ahorren 4 cut's an paste a costa de la claridad de la estructura. (Y que al final, NADIE acaba usando en serio)
Si me dices que el cut&paste es la solucion mal vamos. Preferiria que me hubieras dicho que se puede suplir con agregación e interfaces. Si tu problema es el tiempo de compilacion: adoraras Ruby, python, perl,...
-"No hay preprocesador"... "que es el arma preferida de los ofuscadores de codigo". Ahí te has retratao:) . Pero te equivocas, si hay preprocesadores, pero no son "oficiales". A mi nunca me ha hecho falta... En C++ es mas util porque NO ES INTERPRETADO. Y ciertas cosas que en Java se pueden hacer en Runtime, en C++ NO y se tiene que PREPROCESSAR para diferentes arquitecturas/Opciones.
Odio la ofuscación de codigo. Pero tambien odio el overhead que tienen las utilidades de AOP que modifican bytecodes en tiempo de carga de clases. El cut&paste tambien lo odio. El "with" de python 2.5 o el preprocesador de C o C++ muchas veces ayuda a hacer buen codigo (logs, cerrar conexiones,...), y mas legible que el cut&paste, sin el overhead en tiempo de ejecucion del AOP.
-Yo veo las referencias a funciones como un truco sucio para suplir la mala ingenieria. Lo que tu llamas sobreingenieria, es lo minimo imprescindible para trabajar en EQUIPO en una EMPRESA en la que te tienes que poner DE ACUERDO en algo.
Referencias a funciones puede ser mala ingenieria en un lenguaje orientado a objetos, pero simplemente buena ingenieria del software.
Peter Norvig encontró que 16 de los 23 patrones en Design Patterns eran "invisibles o más simples" [norvig.com] en Lisp.
Las cosas que en otros lenguajes como Ruby, Lisp, Perl, Python,... son directas, en Java requieren un monton de pasos intermedios. Esta claro que es mas facil que un becario aprenda a codificar en un lenguaje mutilado que en uno que no lo esta, pero eso es error de la organizacion de las empresas.
El truco de que el codigo sea entendible es un compromiso entre ser explicito y no irse por las ramas. Java, con sus grilletes, te obliga a irte por las ramas. Eso añade complejidad. En el resto de los lenguajes tambien se puede ser metodico, sin ser tan retorcido.
Re:No
(Puntos:1)Ruby NO TIENE THREADS. Esa simulacion que tiene no pasa de ser un jugete.
Eso lo borra de mi lista. No threads->No escalable .
(De forma general, me refiero... Siempre puedes currarte un Big Loop muy especifico para algun servidor. Pero entonces ByeBye Rails y cualquier intento de generalizacion y codear facil).
En cuanto a los tipicos "problemas" de Java.
-No hay herencias multiples por que SON un LIO. No porque la gente se lie. Y hace el compilador terriblemente complicado y lento solo para soportar un paradigma que solo sirve para que los C++ eros se ahorren 4 cut's an paste a costa de la claridad de la estructura. (Y que al final, NADIE acaba usando en serio)
-"No hay preprocesador"
-Yo veo las referencias a funciones como un truco sucio para suplir la mala ingenieria. Lo que tu llamas sobreingenieria, es lo minimo imprescindible para trabajar en EQUIPO en una EMPRESA en la que te tienes que poner DE ACUERDO en algo.
Re:No
(Puntos:2)( http://127.0.0.1/ | Última bitácora: Jueves, 01 Julio de 2010, 03:18h )
Las cosas que en otros lenguajes como Ruby, Lisp, Perl, Python,
El truco de que el codigo sea entendible es un compromiso entre ser explicito y no irse por las ramas. Java, con sus grilletes, te obliga a irte por las ramas. Eso añade complejidad. En el resto de los lenguajes tambien se puede ser metodico, sin ser tan retorcido.
Una vez metido, recordad lo sucedido [laquadrature.net].