2009/9/10 Agustin Nicolas Viñao Laseras <[email protected]>:
> Es verdad que las buenas practicas se hacen en todos los lenguajes, pero
> tambien es sabido que hay lenguajes que permiten dichas practicas de manera
> mas natural, considero que ruby/rails lo permite como un pilar mas. No tanto
> asi otros lenguajes, mejor no nombrar a alguno en particular para no abrir
> una nueva polemica.
Naaaah, no se. Mantengo que en ruby cuenta mucho el factor "oh,
shiny!" y el cargo culting. Viene DHH (o inserte
nombre-conocido-en-la-comunidad) y dice que hay que hacer X buena
práctica, y todo el mundo empieza a hacerlo.
Ojo, no digo que sea malo, yo aprendi bastante sobre tests gracias al
énfasis en testing que hay en ruby (como dice un amigo, though, en
ruby hay tanto énfasis en los tests porque es un lenguaje de mierda y
se rompe todo si no tenes 100x más tests de los necesarios en otras
cosas :P)
Simplemente mantengo que ruby no es mejor que otros lenguajes por las
buenas prácticas. Yo escribía tests cuando hacía php (granted, era una
p*ja escribiendo tests en aquella época, pero hey, intentaba :P), y
trataba de no repetirme, ni de sobreconfigurar todo el código.
Lo que si tiene es que hay miembros de la comunidad que encaran y
promueven cosas copadas. Es bueno porque la gente aprende, y es malo
porque todos los borregos siguen a ciegas sin saber por qué ("That guy
said it was cool"), y terminan aplicando mal todos los conceptos, y
enseñando conceptos mal aprendidos, ad infinitum :)
Pero esa moneda tiene otra cara, y es el énfasis en complejidad
innecesaria para lograr un API lindo. La comunidad promueve mucho
"escribir DSLs", que al final agregan mil capas de complejidad para
lograr tener un API "fácil" a la hora de escribir (por ejemplo, lee el
código de ActiveRecord, contra el de Sequel).
(Ojo, no digo que todos los DSLs sean malos, ni agreguen complejidad
innecesaria, el código de Sinatra es super simple y elegante)
>
> Con respecto a otros comentarios que hacen con respecto a la "busqueda de
> saber programar", siempre hago la diferencia de que si sabes programar y
> resolver problemas, es muy distinto a ser un buen programador, tanto asi que
> me toco hacer entrevistas en donde me pedian la definicion de poliformismo,
> y buscaban la definicion de libro o de facultad, cuestion que jamas va a ser
> aplicada en esa vision estricta.
>
> Digamos que, yo puedo saber programar, pero de ahi a ser un buen programador
> en ruby/rails hay un camino a recorrer bastante grande. El
> lenguaje/framework permite hacer las cosas muy rapido, pero de ahi a
> hacerlas eficientes hay que conocer bastantes cosas.
Ehhh conozco un par de ejemplos de primera mano (trabajé mano a mano
con ellos) de gente que programaba en otras cosas antes (Java, php,
C#) y cayó a laburar en rails después de haber jugado un poquito nomás
con el lenguaje, y en un par de meses estaban a tiro con el resto del
equipo.
Capaz que no se sabían todos los piques, ni exactamente cómo funcionan
las singleton classes, o podían enumerar de memoria todas las
diferencias entre una instancia de Proc, un llamado a Kernel#proc, y
un llamado a Kernel#lambda. Pero para el 90% de las cosas, con 1/2
meses de laburo alcanza.
No se, es mi opinión, basada en mi experiencia. Es super subjetiva, y
puede estar altamente equivocada. Pero ta =)
-f
PS: estamos divergiendo bastante del thread original, capaz que pinta un split
> Saludos
> ___________________
> Agustin Viñao
> agustinvinao (Skype)
>
>
> 2009/9/10 Nicolás Sanguinetti <[email protected]>
>>
>> 2009/9/10 Gaston Ramos <[email protected]>:
>> > El Thu, 10 de Sep de 2009, a las 11:31:59AM -0300, Agustin Nicolas Viñao
>> > Laseras dijo:
>> >> Me parece que mas que decir "jodida" la transicion, considero que
>> >> muchas
>> >> veces las selecciones de personal estan guiadas por las personas
>> >> incorrectas.
>> >>
>> >> RoR permite cambiar muchas cosas de la programacionn trandiciones,
>> >> mejorar
>> >> muchas etapas, etc. Pero si en la empresa que buscan personal en RoR,
>> >> ni
>> >> siquiera pueden entender el concepto de BDD o TDD en su mayor
>> >> expresion, ya
>> >> de por si, esa empresa va a seleccionar muy mal los recursos.
>> >
>> > Totalmente de acuerdo, hay que tener en cuenta varias cosas, no
>> > solamente
>> > "ruby/rails", hay muchas empresas que han empezado a utilizar ruby/rails
>> > pero se olvidan de darle importancia a las buenas prácticas que todo
>> > buen rubysta no está dispuesto a abandonar, y por ese motivo pierden
>> > a los buenos programadores, en el transcurso de mi migración a Ruby
>> > hace algunos años atrás lo que más valoro de la comunidad es la
>> > profesionalidad
>> > con la que se hacen las cosas y la simplicidad y por supuesto el
>> > concepto
>> > de BDD, TDD aplicado por casi toda la comunidad.
>> >
>>
>> s/rubysta/programador/g
>>
>> Mantengo que no hay nada raro en ruby. Las "buenas prácticas" se hacen
>> en cualquier lenguaje, ruby no tiene ningún crédito ahí.
>>
>> O bah, tiene el crédito de que la comunidad (especialmente la de
>> rails) va mucho por el cargo culting. Y DHH dice que hacer tests esta
>> bueno, así que vamos a hacer tests :P Pero mucha gente con la que he
>> hablado aplica "las buenas prácticas" porque "hay que hacerlo".
>>
>> Cuando la gente escribe tests porque le dicen que es bueno, y no
>> porque entiende cómo funciona el tema, lo hace mal. (Rinse and repeat
>> para otras cosas como "DRY", etc)
>>
>> -foca
>> _______________________________________________
>> Ruby mailing list
>> [email protected]
>> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
>
>
> _______________________________________________
> Ruby mailing list
> [email protected]
> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
>
>
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
