Meh, todo apesta. Che, Gabriel: en serio te parece que alguien comente sobre django es tratar de empezar un flame? Really? Sobre todo si lo comenta educadamente? "Tenés miedo de que te demuestre como django encara y todos tus frameworkcitos en ruby son una pija, totalmente inútiles?" sería más un intento de flame q(ojo, es un ejemplo de flame, no te enrosques ;)). El mail de Juan Pedro me parece perfecto, y un aporte a la discusión (a diferencia del tuyo, que no dice nada relevante ;)). O de este, que tampoco dice nada relevante :P
Discutir sobre las cosas buenas de otros lenguajes no me parece mal. Au contraire, todos podemos aprender un montón de python y de django. -foca 2010/1/25 Leandro Marcucci <[email protected]>: > 2010/1/25 Michel Martens <[email protected]>: >> 2010/1/24 Leandro Marcucci <[email protected]>: >>> 2010/1/24 Michel Martens <[email protected]>: >>>> 2010/1/24 Federico Brubacher <[email protected]>: >>>>> Michel creo q ahi entramos en un tema de gustos : >>>>> hay mucha gente creo (aunque no es 100% mi caso ni cerca, es mas cada >>>>> vez me gusta mas ruby y menos las dsl) que le gustan las DSL locas y >>>>> la magia de ActiveSupport y no se cuantas cosas mas. >>>>> >>>>> Creo que Rails 3 esta prolijo, si bien obviamente viene con "batteries >>>>> included" para hacer la transicion de los usuarios de 2.3 mas facil, >>>>> uno puede por ejemplo : elegir que partes de ActiveSupport usar, que >>>>> partes de ActionController usar, el router esta mejorado (cada ruta es >>>>> un rack endpoint y solo dsp de q pasa por Rack Realities creo se fija >>>>> como le "pega" a un controlador. En fin son varias razones por la cual >>>>> Rails 3 esta mejor . >>>> >>>> Lo de las DLSs supérfluas está ejemplificado acá: >>>> http://blog.citrusbyte.com/2009/12/15/superfluous-dsls/ >>>> >>>> Con mapeo innecesario me refiero más que nada a las RESTful routes. Es >>>> posible crear un website RESTful con Rails, Sinatra, PHP, Java, HTML >>>> pelado, siempre y cuando se honren las convenciones REST. Con esto >>>> quiero decir que no hace falta poner map.resources :photos o resources >>>> :photos, hay otras maneras. >>>> >>>> En Rails 3: >>>> resources :posts >>>> >>>> Esto genera las siguientes rutas: >>>> >>>> # GET /photos >>>> def index; ... end >>>> >>>> # GET /photos/new >>>> def new; ... end >>>> >>>> # POST /photos >>>> def create; ... end >>>> >>>> # GET /photos/1 >>>> def show; ... end >>>> >>>> # GET /photos/1/edit >>>> def edit; ... end >>>> >>>> # PUT /photos/1 >>>> def update; ... end >>>> >>>> # DELETE /photos/1 >>>> def destroy; ... end >>>> >>>> Si sólo se quiere exponer GET /photos/1, hay que poner map.resources >>>> :photos, :only => :show. >>>> >>>> El gusto por las DSLs puede ser legítimo. Lo que es dudoso es el gusto >>>> por las DSLs innecesarias. En este caso, el "resources" de Rails está >>>> generando código para mapear URLs a métodos en un controller, cuando >>>> Sinatra demostró que es un paso innecesario. La mera existencia del >>>> comentario antes de cada método --cada "action"-- es indicador de que >>>> la abstracción es, como mínimo, imperfecta. El efecto colateral de que >>>> olvidar un :only o un :except implique que un website exponga deletes >>>> y updates de forma insegura, es indicador de una leaky abstraction. >>> >>> Estoy de acuerdo con el argumento, no con la conclusion. No me parece >>> una abstracion defectuosa. Si usas mal el framework, seguramente el >>> resultado sera desagradable. >> >> Te invito a justificar esa abstracción. Tratá de demostrar por qué ese >> mapeo es relevante. >> > > Es facil: si querés exponer sólo un método de los siete que define > REST (index, new, create, edit, update, show, destroy), y usas el > método resources, estas haciendo, a mi entender, dos cosas mal: la > primera es usar el metodo que permite que tu aplicacion responda a los > 7 cuando solo queres usar uno solo; la segunda es ignorar que rails te > da un metodo para declara una ruta puntual para un recurso. En ningun > caso veo defecto del framework, es todo error de capa 8. > >>>> >>>> El equivalente con Sinatra: >>>> >>>> get "/photos" do ... end >>>> get "/photos/new" do ... end >>>> post "/photos" do ... end >>>> get "/photos/:id" do ... end >>>> get "/photos/:id/edit" do ... end >>>> put "/photos/:id" do ... end >>>> delete "/photos/:id" do ... end >>>> >>>> En primer lugar, el comentario cuasi imprescindible de Rails es ahora >>>> irrelevante. >>> >>> ¿? >> >> Rails inserta este comentario: >> # GET /photos :id >> > > Falso, lo inserta el generador de scaffolds. Rails no toca tu codigo > en absoluto. > >> Digo que al usar Sinatra, no hace falta generar ese comentario porque >> la definición del entry point es más que explícita: >> >> get "/photos/:id" >> > > En rails tambien. Convencion sobre configuracion. Si tenes un def > create end en tu controlador, o bien algo en routes declara que tu > aplicacion respondera al post para ese controlador, o esta mal > testeada, o es codigo basura. > >>> >>>> En segundo lugar, la posibilidad de exponer por accidente >>>> algún método es casi inexistente. >>> >>> Claro, no podes exponer nada que no escribiste. Con rails no necesitas >>> escribirlo, y la mayoria de las veces vas a querer exponerlo, he aqui >>> la ventaja de lo que ofrece Rails. (ojo, una cosa es una cosa y otra >>> cosa es otra cosa: el resultado bueno a cualquier precio no es >>> correcto, podria estar bien hecho). >> >> No veo la ventaja. Hablás del generador de código? > > No. Del generador de codigo no hablo nunca. > >> >> Supongamos el caso de DELETE /photos/:id >> >> Con Sinatra: >> >> delete "/photos/:id" do ... end > > Incompleto. > > Con Sinatra: > > delete "/photos/:id" do ... end > delete "/foos/:id" do ... end > delete "/bars/:id" do ... end > > y asi para cada recurso de tu aplicacion que pueda ser borrado. > > Con Rails: > > resources :photos, :foos, :bars > > Y el verbo http no lo escribo nunca, porque ya lo conozco. > > Claro, estoy corriendo un framework varios ordenes mas extenso en > lineas de codigo. > >> >> Con Rails: >> >> resources :photos >> def destroy; ... end >> >> En la versión de Rails hay más código, no? El hecho de que no >> necesites escribirlo por haberlo generado con un scaffold creo que es >> irrelevante, porque hay generadores de código para cualquier >> framework. > > De nuevo, no. Si estoy programando REST, el verbo http de cada accion > es inamovible (¿?), y salvo que maneje un solo recurso en mi > aplicacion, los repito en cada "controller" de forma innecesaria. > >> >> Cuando hablaba de métodos expuestos por error me refería a lo >> siguiente: supongamos que tenés un método def edit; ... end, con su >> correspondiente vista. Al borrar el método del controller, la vista >> sigue siendo accesible. >> > Claro, eso es como estacionar el auto y dejarlo abierto. Si te afanan > vas a culpar al fabricante de la alarma (o a la alarma misma)? > >>>> En tercer lugar, la cantidad de >>>> memoria y ciclos de CPU es ridículamente menor. >>> >>> En C es mucho menor que en ruby, habria que hacer sitios web en C. >> >> Es en serio este comentario? >> > > El tenor es el mismo que el del comentario al que hace referencia ;) > >>> >>>> En cuarto, la cantidad >>>> de ciclos cerebrales (para seguirle la corriente al mapeo de Rails) es >>>> reducida a cero. >>> >>> Siempre me molesto muchisimo lo dificil de seguir que es el trace de >>> cualquier cosa que haga rails. + 1 a la no simplicidad. >>> >>>> Si lo que Rails ofrece es un atajo para generar >>>> websites restful, por qué razón con Sinatra obtengo un mejor resultado >>>> tipeando menos? >>> >>> El resultado no es necesariamente mejor siempre, ni peor siempre. >>> Tampoco estas tipeando menos. Es mas, estas tipeando de mas. Salvo que >>> quieras programar REST mal, siempre vas a tener el mismo verbo http >>> antes de la misma accion/ruta. Estas tipeando --muchisimas-- mas cosas >>> obvias que el comentario de rails, que solo es escrito por el >>> generador de scaffold (dejo lugar a que en rails 3 estos comentarios >>> sean necesarios, pero lo dudo mucho). >> >> De nuevo creo que estás confundiendo cantidad de código con quién lo >> genera. No importa que lo generes con un scaffold, > > Si, si importa. Los scaffolds no sirven para casi nada, y no me parece > que el codigo que generan sirva para juzgar a Rails (tampoco me gusta > el blog en 15 minutos, apesta). Escribiendo delete por cada recurso, > tengo chances de escribirlo como el tujes y tener un error por eso. Y > estoy inflando de codigo poco informativo mi aplicacion. > >> porque lo mismo >> aplica para cualquier framework. Lo importante es que hay mayor >> cantidad de código en la versión de Rails que en la de Sinatra. >> > > Estoy de acuerdo con los principios de la apreciacion, pero la > conclusion es falsa. El desarrollador debe escribir menos codigo en > Rails que en Sinatra, con todos los riesgos que eso reduce. > >>>> >>>> En Rails 3 es más sencillo integrar middlewares de Rack. Incluso es >>>> sencillo integrar aplicaciones de Sinatra como midlewares de Rack. >>>> Para qué me tomaría el trabajo de armar algo con Rails, incurrir en >>>> los costos (mentales y otros) que describí, para poder "bajar" a >>>> "metal" e insertar aplicaciones de Sinatra, cuando puedo escribirlas >>>> directamente y obtener algo mejor, que ocupa una fracción del RAM y se >>>> ejecuta mucho más rápido? Cuál es la ganancia? >>>> >>>> Saludos, >>>> >>>> -- >>>> Michel >>>> _______________________________________________ >>>> Ruby mailing list >>>> [email protected] >>>> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >>>> >>> >>> Como dicen por ahi, la mejor herramienta para cada caso. Rails es una >>> buena herramienta para desarrollar sitios web seguros, con codigo >>> elegante corriendo "sobre" él, así como lo es Sinatra, y cualquier >>> otro. Simplemente cada uno sirve para solucionar problemas diferentes. >> >> No lo veo así, creo que ambas herramientas apuntan a solucionar el >> mismo problema. Por qué creés que sirven para solucionar problemas >> diferentes? >> > > Porque los dos son "enlatados", y estan desarrollados con principios > diferentes, para ser de utilidad a mucha gente. Yo estoy tomando en > cuenta como aporta cada uno a facilitar trabajos especificos, y Rails > me parece mas flexible. Tiene defectos, la mayoria ocasionados por ese > afan de ser lo mas cercano al todo para casi todos (curiosamente en > Getting Real DHH postula lo opuesto: no podes ser todo para todos). > > No creo que uno sea mejor que el otro objetivamente, pero si creo que > subjetivamente tienen cosas diferentes para ofrecer, lo que los hace > mejor herramienta para casos especificos. Pago ciclos de procesador y > uso de memoria para no programar todo en assembler, por eso uso ruby. > Tambien los pago para no redesarrollar cosas que rails trae > solucionadas de entrada. Rails no es perfecto. Lastima. Sigue > mejorando todos los dias, gracias a los colaboradores. > > -- > Leandro Marcucci. > http://twitter.com/leanucci > _______________________________________________ > 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
