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
<[email protected]> 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/
