Java vs .Net

[Daniel Molina Wegener]

On 13/06/12 23:33, Christian Pedreros wrote:
>
>
> 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!

   No creo que sea asi. Te doy el ejemplo del proyecto en el que estoy
ahora, disenie un priority queue que es dinamico, cambia de acuerdo
a las variables de entorno para un sistema de control industrial en
la estacion de procesamiento (donde llegan los datos), me base en una
maquina de estados para hacer los cambios en el priority queue, que
esta debidamente formalizada en un automata. Ademas de eso el modelo
del proceso va a estar debidamente verificado y formalizado en un
paper usando algunas herramientas de verificacion (como calculo pi).

   Programar no es solamente saber que la instruccion "print" imprime
en pantalla, o saber que "print" escribe en el buffer stdout, etc.
Lo tecnico es una cosa, pero sin la base teorica adecuada, se cae en
errores y a veces errores graves.

   Te doy otro ejemplo. Me encargaron mantener un proyecto tipo workflow.
El programador anterior no tenia la base teorica respecto a automatas.
El codigo que dio por resultado eso fue una selva de instrucciones if
muy dificil de mantener. Bastaba con meter los estados del workflow
en una maquina para hacerlo mas "ordenado".

   Insisto en que "saber programar" no es cuestion de solo saber meter
instrucciones en un archivo, hay hartas cosas mas...

>
>
>
>>>
>>> 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/