Java vs .Net

[Daniel Molina Wegener]

On 14/06/12 02:39, Javier Garay wrote:
> Pienso que para ser un buen programador no hay que solo conocer un
> lenguaje o plataforma, hay que saber de frameworks, vms y sobre todo
> de metodología, patrones de diseño/iteración, buenas practicas, etc.,
> cosas que le permitan al desarrollador crear una aplicación decente,
> escalable y robusta. No todo tiene que ver con el lenguaje y el manejo
> que se tenga de este.

   Los aspectos tecnicos y metodologicos no sirven de nada sin una buena
base teorica...

>
> En cuanto a lo que me decía Daniel, nadie esta siempre 100% de acuerdo
> con algo, yo soy Java fan boy, pero "por lo que me han contado" y he
> visto .Net no tiene nada que envidiar a Java y de seguro que tiene
> ventajas gracias al soporte de MS y es a eso a lo que quiero apuntar,
> para que no nos desviemos del tema central, solo he leído un par de
> respuestas que están centradas en el thread.

   En Java en cuanto a productividad tienes Scala, puedes escribir en
menos lineas de codigo algo productivo, te doy un ejemplo, si sabes
como calcular la varianza, el siguiente codigo en Haskell lo puedes
migrar a la misma cantidad de lineas en Scala para calcularla sobre
una lista / array de Floats:

olVar :: [Float] -> Float
olVar [] = 0.0
olVar xs = lolVar xs 0 0 0
   where lolVar [] n' m' r' = (r' / (n' - 1)) :: Float
         lolVar (t:ts) n m r = let n' = n + 1.0
                                   d' = t - m
                                   m' = m + d' / n'
                                   r' = r + d' * (t - m')
                               in lolVar ts n' m' r'

   Con una sola iteracion (no con 2 iteraciones como lo indica la
forma tradicional). Eso si que es productivo. Con todas las ventajas
que tiene la JVM y la potencia de un lenguaje 100% multiparadigma
como Scala.

>
> Saludos.
>
> Cordialmente,
> Javier Garay G.
> Ingeniero en Informática.
>
> El 13-06-2012, a las 23:34, Christian Pedreros
> <christian.pedreros en gmail.com>  escribió:
>
>>
>>
>> El 13-06-2012 23:20, Daniel Molina Wegener escribió:
>>> On 13/06/12 22:14, Felipe wrote:
>>>> La verdad Javier, estoy en profundo desacuerdo contigo. Me refiero
>>>> especificamente a la frase:
>>>>
>>>> "permiten enfocarse de mejor manera en la lógica de negocio del sistema,
>>>> en lugar de estarse preocupando por el código en si".
>>>
>>>   No estoy de acuerdo al 100% con tus ejemplos, pero si en varios
>>> aspectos. Eso viene del mito nacido con Visual Basic 5/6  de que
>>> "cualquiera puede programar y /este lenguaje/ es la panacea".
>>> Creo que no existe mito mas falso... ;)
>>>
>> No es tan falso: realmente cualquiera puede programar, como postulan en www.codecademy.com
>> De hecho su curso es bastante amigable con la gente que no sabe nada de programacion.
>>
>> Ahora, lo dificil es que cualquiera haga buenos programas... eso es otro cuento!
>>
>>
>>
>>>>
>>>> La verdad, ambos aspectos son importantes, y el desarrollo se vuelve mas
>>>> colaborativo, escalable y ameno con buenas practicas de desarrollo que
>>>> son transversales a todos los lenguajes de programacion y stacks
>>>> tecnologicos.
>>>>
>>>> Algunos ejemplos de porque si hay que "preocuparse del codigo en si":
>>>>
>>>> Ejemplo #1:
>>>> Tienes un servicio critico en una nube en Windows Azure y de pronto se
>>>> cae. Tienes 0 segundos para arreglarlo y cada segundo que pasa significa
>>>> una perdida significativa.
>>>>
>>>> Ves los logs, pero no hay nada. Solo hay "OLAA AQUI ESTOY PASANDO!!" y
>>>> tonteras similares. Abres Visual Studio, y por no preocuparte del codigo
>>>> en si, terminas revisando miles de lineas de codigo, donde posiblemente
>>>> algunas de ellas no estan en uso, y ocupas mucho tiempo en proporcionar
>>>> una solucion. Para cuando terminas, el downtime total genero nuevos
>>>> problemas con consecuencias graves para "el negocio".
>>>>
>>>>
>>>> Ejemplo #2:
>>>> Tu jefe contrata mas gente, los hace trabajar contigo, pero por no
>>>> preocuparte del codigo en si, nadie se siente capaz de agregar nuevas
>>>> funcionalidades o corregir un defecto.
>>>> Despues de mucho tiempo invertido, la persona hace un commit y todo se
>>>> rompe.
>>>>
>>>>
>>>> Ejemplo #3:
>>>> 2 personas intentan trabajar, pero todo esta en una clase gigante. Elige
>>>> el desenlace:
>>>> a) Para evitar hacer un merge gigante, una de las personas se va a tomar
>>>> un cafe y a leer el diario. La empresa cambia dinero y cafe a cambio de
>>>> nada.
>>>> b) Hacen un merge gigante, se demoran 20 minutos y meten un bug nuevo.
>>>> El log de control de versiones tiene un merge por commit.
>>>>
>>>>
>>>> Ejemplo #4:
>>>> Quieren agregar pruebas de unidad. Tarde en el desarrollo, como siempre
>>>> ocurre cuando no te preocupas del codigo en si. Pero como esta todo
>>>> acoplado. Implementar una prueba a nivel unitario se vuelve imposible y
>>>> tu prueba se vuelve equivalente a correr el programa completo.
>>>> Hacer un deployment a produccion se vuelve un juego de azar. La
>>>> integracion continua se vuelve imposible o pierde sus ventajas.
>>>>
>>>>
>>>> Ejemplo #5:
>>>> Te llega un reporte de bug. Arreglas la porcion de codigo afectada pero
>>>> por no reutilizar codigo (pues para que preocuparse del codigo en si),
>>>> hay codigo que resuelve el mismo problema en secciones distintas del
>>>> proyecto. De pronto, tienes un bug fix parcial y alargaste el QA una semana.
>>>>
>>>>
>>>> Asi que, en mi opinion, el codigo siempre es importante. No es lo mas
>>>> importante, y no es lo unico importante, pero es importante.
>>>>
>>>> Gracias,
>>>
>>> Atte.
>>

Atte.
-- 
Daniel Molina Wegener <dmw [at] coder [dot] cl>
System Programmer & Web Developer
Phone: +56 (2) 979-0278 | Blog: http://coder.cl/