What Killed Smalltalk Could Kill Ruby

[Angel Java Lopez]

Hoy llego a mi radar, este video, desde una lista de Smalltalk

Es de hace unos anios, de @unclebobmartin

https://www.youtube.com/watch?v=YX3iRjKj7C0

algo largo, pero puede resultar interesante

Por el minuto 21, pone "too easy to make a mess" como el principal motivo de problema en Smalltalk, y por lo que segui, luego lo compara con lo que estaba pasando en Ruby

Nos leemos!

Angel "Java" Lopez

@ajlopez

[Ezequiel Gentile Montes]

Arrogance! :-)

[Nicolás]

Sería interesante ponerse a pensar si el hecho de que en Smalltalk es "too easy to make a mess" es un problema o no.

La frase "make a mess" me suena mas a un uso incorrecto por parte del programador, falta de conocimiento de la tecnología que está usando, etc., más que a una característica el sistema en sí.

Sería algo así como dejar de utilizar autos por que es muy fácil matar personas atropellándolas. Nadie dejó de usar un auto por este motivo (bué, habrá algún caso borde seguro).

Me parece que la frase de Uncle Bob (o la forma en la que comunica la idea) excusa al programador de su responsabilidad atribuyendo, en este caso a Smalltalk, la causa del problema.

Qué prefieren: restricción sobre las cosas que pueden hacer vs tener la libertad de poder cambiar/modificar lo que necesitan al costo de ser mas responsables al momento de programar?

Esto me suena un poco a la "restricción y seguridad" que te "da" el compilador en lenguajes estáticamente tipados vs lo que podés hacer con lenguajes dinámicamente tipados.

Salutes!

Nico

El miércoles, 16 de abril de 2014 09:02:16 UTC-3, ajlopez escribió:

[Nacho Facello]

2014-04-22 11:29 GMT-03:00 Nicolás <nicolas...@gmail.com>:

La frase "make a mess" me suena mas a un uso incorrecto por parte del programador, falta de conocimiento de la tecnología que está usando, etc., más que a una característica el sistema en sí.

Hay un idioma en una región de Australia en el que todas las referencias geográficas son absolutas. En ese idioma el tenedor no está a la derecha del plato, está al norte (o al este, dependiendo de cómo esté orientada la mesa). Resulta que la gente que habla ese idioma tiene una capacidad impresionante para orientarse, porque para poder hablar correctamente tienen que saber siempre para dónde queda el norte. Claro, los sacás de la zona que conocen y ya no es tan fácil, y ahí el idioma que antes les daba una facilidad se les convierte en un impedimento.

A lo que voy con eso es que el idioma que hables influye en cómo pensás, y en qué cosas es más fácil o más difícil decir. Lo mismo pasa con los lenguajes de programación. No es casualidad que los factories de factories de factories se vean en Java pero no en Ruby, por ejemplo. Si el lenguaje hace que sea más fácil hacer cosas chanchas, van a aparecer cosas chanchas.

--
Nacho Facello
:wq

[Nicolás]

Cómo va Nacho?

Entiendo y comparto lo que decís.

Creo que una cosa es elegir/evaluar qué tan bien un lenguaje de programación se adapta para algo en particular. Esto está relacionado con las abstracciones que te provee y por lo tanto, la forma en la que vas a pensar cuando lo uses.

Mi punto va más orientado a lo último que decías. ¿Por qué, si un lenguaje te permite hacer cosas chanchas, van a aparecer cosas chanchas?

Para mi es una cuestión de "educación", por así decirlo, que tiene que ver con darse cuenta cuándo nos estamos mandando una y cuando no.

Por que hay que sacrificar la libertad de tener el nivel de acceso que te da Smalltalk/Ruby (que no es el mismo), solo por que hay gente que lo utiliza de forma incorrecta, o tuvo una mala experiencia con eso?

[Pablo Astigarraga]

Si el lenguaje permitiendo cosas chanchas hiciera que se dejara de usar entonces JavaScript y C no lo usaría nadie. no?

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Hugo M.]

Poca gente usa C hoy en día para hacer aplicaciones de alto nivel, que yo sepa. Y de Javascript se quejaba todo el mundo hasta hace unos años. Y eso que JS es definitivamente menos peligroso que C.

Un amigo que labura en Java me dice: ni en pedo hago algo que maneje guita en Ruby. Obviamente, se puede hacer (¡y en PHP también!), pero a lo que se refería es que una empresa grande prefiere que sus productos estén hechos en algo mas "sólido" como Java, que le garantiza menos posibilidad de error, porque al manejar guita un error puede ser un desastre de negocios. Creo que ese es uno de los motivos de que los lenguajes compilados o pseudocompilados y de tipos estáticos estén en el mundo empresarial mucho mas que los de tipos dinámicos e interpretados. Son mas "fiables", mas difícil que un programador cometa errores.

En PHP sumás un número a un string y está todo bien. O sea, esto no me dejaría tranquilo:

php > $a = "bla";
php > echo $a;
bla
php > $a += 2;
php > echo $a;
2
php > $a += "bla";
php > echo $a;
2
php >

[Lorenzo Jorquera]

No me convence ese argumento. La falta de tipos estaticos no es muy grave si tenés tests de unidad y si no los tenés estás expuesto a muchísimos errores por más que tu lenguaje sea tipado.

[Hugo M]

Puede ser, pero cuantas mas posibilidades de error, mas riesgo de negocio. Y estamos hablando de empresas que ya tienen su negocio establecido, no startups (en el que el tiempo de desarrollo de un producto tiene mas importancia).

Pero bueno, quizás hay otra explicación por la cual se usan mas esos lenguajes mas restrictivos (¿marketing? ¿performance? ¿inercia?).

Hugo Massaroli

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/rubysur/NjPU8iMJ1s8/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a rubysur+u...@googlegroups.com.

[Dario Seminara]

Lo que pudo haber salvado Smalltalk salvara Ruby (TDD)

En los lenguajes dinamicos los chequeos de tipos y demas cosas que hace el compilador se reemplazan con TDD, mientras haya buen TDD (sea que se trate de un lenguaje estatico o dinamico) habra mayor confianza en el codigo, y una buena suite de tests sobre codigo en un lenguaje dinamico hacen al sistema mas solido de lo que seria algo programado en un lenguaje estatico pero sin tests

Mi conclusion, si necesitas codigo solido/confiable hay que hacer TDD, y eso sirve mas alla de si el lenguaje tiene tipos o no. Sin tests, usar un lenguaje estatico no garantiza nada, solo te obliga a hacer las cosas de una manera en que va a haber mas chequeos y tu codigo seria menos proclive a errores, pero eventualmente los habra y si no tenes tests para detectarlos estas en una situacion muy similar a la de no tener tests en un proyecto rails. 

Con tests bien hechos, podes confiar en el codigo sin importar como este implementado o con que lenguaje se hizo (sea dinamico, estatico, etc...)

[Hugo M]

En Java hay TDD y se usa bastante, de hecho la primera vez que escuché sobre unit testing fue con JUnit... no me parece productivo usar TDD como compilador, sino para probar los casos de negocios. Y va a haber menos cosas que probar en un TDD con Java porque no necesitás probar "qué pasa si le mando un número en vez de un string a este método" ya que ese caso de error ni siquiera existe.

Uso Java como ejemplo pero lo mismo para cualquier lenguaje fuertemente tipado y (pseudo)compilado.

Pero sí, obviamente no te podés fiar para nada en el compilador para pensar que tu código no tiene errores. Sólo es una capa más de seguridad que ya viene por default.

Hugo Massaroli

[emanuelF]

no se si alguien quiere decir algo del tema... 

soy programador JAVA (o ex), y vengo a ruby y a lo dinamico...

Mi opinion es la siguiente: 

1- el tipado estatico si da seguridad lo da en un solo punto... errores que puedo considerar aberrantes como del tipo que mencionas: string+ numero. Si vamos a un desarrollo real yo a un string lo llamaria con un nombre adecuado: 

• descripcion
• nombre
• apellido
• marca
• caracteristicas
• razon_social
• etc....

jamas en mi vida llamaria a un dato tipo String con alguno de los ejemplos:

• edad
• cantidad_hijos
• hora
• total
• impuesto
• subtotal

ahora, JAVA o el lenguaje con tipado estatico que mas te guste, no te va a ayudar en lo mas minimo si haces una cosa tal como esta:

edad+nombre

mi ideal al programar es no tener que mover el mouse o mi mirada para ir al top de la clase o en el ambito que sea, para ver de que tipo de datos es la variable que estoy declarando. deberia inferirla por el nombre, sino me hago una mula programando...

Asi que, el tipado dinamico no es mas inseguro, para nada, porque la unica "seguridad" que te da (o al menos la que mas se alaba) un lenguaje con tipado estatico, se resuelve nombrando de manera logica a tus variables.

y ahora, ruby, python, php o lo que sea... modifico una triste linea de codigo que me ta jodiendo la vida, y reinicio el servidor y listo, no debo recompilar y me gano un apreciable tiempo. y de paso me olvido de maven, ant y no se de que otra mala palabra...

Y por lo otro... se usa en las empresas, porque hay mas personas que saben JAVA que las que saben RUBY, y por el recambio de personal, tener a RUBY, algunas empresas piensan que seria insufrible. 

--

Emanuel Friedrich - Casi licenciado en Sistemas... :)
Cel: 3754-495887

Haya paz

[emanuelF]

no me parece productivo usar TDD como compilador, sino para probar los casos de negocios. Y va a haber menos cosas que probar en un TDD con Java porque no necesitás probar "qué pasa si le mando un número en vez de un string a este método" ya que ese caso de error ni siquiera existe.

Si bien no entiendo lo de usar TDD como compilador... aun con tipado estatico, los test no estan solo para esto

[Angel Java Lopez]

Sobre TDD como compilador http://msmvps.com/blogs/lopez/archive/2013/02/20/tdd-como-compilador.aspx

2014-04-23 16:10 GMT-03:00 emanuelF <aemanuel...@gmail.com>:

no me parece productivo usar TDD como compilador, sino para probar los casos de negocios. Y va a haber menos cosas que probar en un TDD con Java porque no necesitás probar "qué pasa si le mando un número en vez de un string a este método" ya que ese caso de error ni siquiera existe.

Si bien no entiendo lo de usar TDD como compilador... aun con tipado estatico, los test no estan solo para esto

--

[Gabriel Balbuena]

Tengo un cacharo armado en ruby, maneja guita imprime facturas, maneja varios usuarios a la vez, caja cobros, etc

Claro que el stack de impresion de comprobantes la arme con jasper reports y evidentemente tuve que mudar el proyecto a jruby, precisaba algo robusto y que me caminara con algun servidor que ya conocia (tomcat).

Puedo decir que haciendo uso de transactions y con buen codigo defensivo el margen de fallos criticos se limiten a muy pocos en los primeros dias de produccion que rapidamente se solucionaron.

Problemas los tuve en activerecord algunas consultas reventaban en el servidor tuvieron que ser reescritas.

Se buscaba rapidez y me hice la apuesta por ruby, funciono de maravilla no me arrepiento para nada.

Se Llego a produccion a la carrera sin manual testing previo, todo rapido y sin peros ni sobre analisis unitarios y da dentro.

Les puedo decir que ruby es confiable. confiable por ser dinamico? a mi parecer no

Confiable porque se hacen las cosas con cuidado y con un buen tiempo invertido en tdd (1/3 del tiempo de desarrollo), tal vez si se hubiera optado por no invertir en tdd tambien hubiera entrado en la cancha (seguro con mas problemas).

El tema principal es el porte del sistema, en java pasa muy seguido aun siendo fuertemente tipado trabajo manteniendo proyectos en java y se ve mucha cosa linda y de las chanchadas de todos los dias.

A mi forma de ver depende de cuanto tiempo tenes, que podes hacer y que no.

Esa es mi experiencia sobre el tema, tal vez aporte algo.

​

--

Gabriel Balbuena

[Nico Papagna]

Hay varias cosas para comentar:

El hecho de que, por ejemplo, PHP sea un lenguaje dinámico no significa que uno no tenga que validar los colaboradores que recibe al momento de crear un objeto. Como nota al margen, si estamos hablando de plata un número no alcanza: se trata de una cantidad más la moneda en la que está expresada.

Por lo tanto, podría validar que el objeto que recibo como "cantidad" cumpla las condiciones que tiene que cumplir, creando solo instancias validas de "plata". Eso además de tener cobertua vía TDD (y no solo test de unidad).

O sea, un lenguaje estáticamente tipado te da garantías sobre la jerarquía de clases a la que pertenece un objeto, pero no te puede decir si su invariante se mantiene o no (eso nos toca a nosotros!).

Si hablamos de negocios, sistemas que manejan plata y sobre todo empresas que no son start-ups qué mejor ejemplo que JP Morgan, que tiene una larga relación implementando sus sistemas con Smalltalk.

No se olviden también que en un lenguaje estáticamente tipado como Java hay que compilar, y compilar puede significar tener que bajar mi sistema, hacer deploy de una nueva versión y volver a levantarlo (aún si se del fix mas pavo). Esto para un monstruo como JP Morgan no es aceptable, ya que bajar el sistema significa pérdida de plata (y probablemente mucha). El sistema se tiene que actualizar/fixear mientras está corriendo.

Acá se ve que con un lenguaje de programación estático no alcanza. Que sea dinámico tampoco alcanza, se necesita un sistema de programación como lo es Smalltalk.

Por último, el hecho de que Java sea una tecnología que domine el mercado creo que tiene que ver más con una cuestión comercial/de marketing (y esto trae acarreado disponibilidad masiva de recursos, etc), que por otra cosa.

Está claro que siempre pueden aparecer pros y contras desde los dos lados, pero al momento de sentarse a programar hay que elegir uno (el lado oscuro???).

Salutes!

Nico

[Prefiero.PHP]

Hola,
No usé Smalltalk para trabajar, si lo usé para la facultad, eso fue el nos 90's.

diferencias con ruby:
*no había implemetaciones libres (o nadie las usaba/conocia).
*implementaciones "buggy", al menos las versiones asequibles (visual works I'm talking to you).
*code/ide/run environment totalmente acoplado.

Cuando dicen que es muy facil "make a mess" no solo es por el lenguaje, muchas veces se corrompía la imagen y nadie sabía por qué. Había que hacer backups de 4MB o más a cada rato, en la época que el tamaño se medía en disquettes.

Lo que sí veo de similar entre ruby y smalltalk son las tendencias en la comunidad(1):
*Teoría (o elegancia) sobre practicidad.
*No normalizar datos.
*Solo aceptar soluciones sobre smalltalk/ruby (todo lo demás "is evil")
*Blame Canada (2)

(1) disclaimer: estereotipo de la comunidad, no la comunidad en sí.
(2) South Park reference.

Firma: yo

[Mauricio Garavaglia]

No poder actualizar el código sin "bajar el sistema" no es un problema del lenguaje o del tipado, es un problema de arquitectura de tu aplicacion. 

Por otro lado, es gracioso que menciones a Java como triunfo del marketing cuando das el ejemplo de JPMorgan y su proyecto Kapital (larga relación?). Pueden buscar los PR de la época, son bastante patéticos. 

[Angel Java Lopez]

Ya que mencionaron otros lenguajes, pros y contras, hoy entro en mi radar

http://programmers.stackexchange.com/questions/221615/why-do-dynamic-languages-make-it-more-difficult-to-maintain-large-codebases

http://programmers.stackexchange.com/questions/209376/is-there-a-correlation-between-the-scale-of-the-project-and-the-strictness-of-th

El primero referencia al segundo, quedando el primero como duplicado. Pero son interesantes los comentarios.

El segundo, de nuevo, interesante discusion, ver que alguien de Scala menciona a Ruby on Rails

Nos leemos!

Angel "Java" Lopez

@ajlopez

[Nico Papagna]

El jueves, 24 de abril de 2014 00:37:59 UTC-3, Mauricio Garavaglia escribió:

No poder actualizar el código sin "bajar el sistema" no es un problema del lenguaje o del tipado, es un problema de arquitectura de tu aplicación. 

De acuerdo! Es el comentario que hice sobre el tipado. Y está claro que un lenguaje mágicamente no te va a resolver esos problemas. 

Pero el hecho de no tener al sistema "vivo" para poder inspeccionarlo, por ejemplo, si puede afectar tu capacidad de modificarlo.

 

Por otro lado, es gracioso que menciones a Java como triunfo del marketing cuando das el ejemplo de JPMorgan y su proyecto Kapital (larga relación?). Pueden buscar los PR de la época, son bastante patéticos. 

El ejemplo está relacionado a lo que hablábamos antes (fijate en los primeros posts) en el que alguien decía que le comentaron que ni a palos harían un sistema que maneje plata en Ruby, que preferían elegir algo más sólido como Java. Ahí tenés un sistema que claramente no es de una start-up y está hecho en un lenguaje dinámico. 

Qué te parece a vos el triunfo (por ponerle alguna palabra...) de Java / por qué creés que llego a estar en donde está ahora?

No es una pregunta sarcástica, sino para conocer tu punto de vista sobre el tema.

Como fué que llegaste a laburar con eso, lo conociste o lo preferís sobre alguna otra tecnología al momento de desarrollar un sistema?

 

Igual creo que se perdió un poco el foco. Siempre van a existir pros y contras.

Lo que me llama la atención es el tema de que "un lenguaje que te permita hacer chanchadas" es motivo para dejar de utilizarlo.