Pensar distinto

> Andrés,
>
> Eso puede suceder en C (recuerdo haber desarrollado muchas capas de
> abstracción en SCO C++, pero que nunca funcionaron en otro compilador, mucho
> menos en g++ 8-(
>
> Sin embargo todo lo desarrollado en Java funciona hasta el día de hoy,
> porque Java se ha encargado de hacer las cosas compatibles hacia atrás, a
> nivel del formato de las clases que entiende la máquina virtual.
>
> En Smalltalk, su creador que es Alan Kay, es un fuerte proponente de que las
> cosas cambien, que no se fije nada en duro, y yo comparto plenamente su
> apreciación. Por eso propone que el formato de las imágenes en Smalltalk
> sean diferentes y evolucionen, lo mismo con el formato de los objetos, de
> las clases, etc. Aunque el lenguaje se mantiene inalterable, la mayor parte
> de las mejoras ocurren desde la máquina virtual hacia abajo y no hacia
> arriba (porque el lenguaje no cambia, muy a pesar de lo que a Alan Kay le
> gustarìa).
>
> Pero el hecho de que cambie tanto los formatos tiene una desventaja: Es
> imposible hacer un programa en Smalltalk que corra en todas las máquinas
> virtuales. Es una gran desventaja. Cuando me encuentro con este tipo de
> problemas, siempre pongo una capa de abstracción entre medio. Es decir, el
> programador no debiera programar directamente sobre Smalltalk, sino sobre
> una capa de abstracciòn que estuviera implementada en todas las màquinas
> virtuales. Algo asì como un "Smalltalk sancionado", que alguien te asegure
> que ese Smalltalk es uniforme en un conjunto razonable de Smalltalks
> comerciales y open source. El mecanismo de control podrìa corresponder a un
> sistema de permisos sobre Smalltalk para modificar y para usar ciertas
> clases, que deberìa ejecutar mientras se desarrolla, y que luego cuando se
> pasa a producción se podrìa desechar (estoy pensando en un Proxy o en AOP).
>
> Por otra parte el hecho de que Smalltalk no cambie (o no cambie tanto, ya
> que los cambios se producen principalmente a nivel de la class library),
> creo que corresponde a que efectivamente nadie a encontrado un sistema
> mejor. En Smalltalk nada està amarrado (o casi nada), de modo que como todo
> es modificable, o bien se encontrò un màximo local y por eso ya no se puede
> seguir mejorando el lenguaje, o no hay nadie suficientemente inteligente que
> estè interesado en averiguar còmo Smalltalk funciona y modificarlo para que
> haga algo nuevo (como dice Alan Kay se requiere gente que entienda cosas
> diferentes, "pink plane AND blue plane").
>
> Lo ùltimo que he visto en Smalltalk y Java es AOP y Traits. Ambas ideas me
> parecen mucho màs limpias y poderosas que lo que se utiliza tipicamente en
> Smalltalk, porque de alguna manera que todos los objetos se conozcan (lo que
> tìpicamente se produce en Smalltalk y cuando diseñas diagramas de clases en
> UML), es una forma de acoplamiento que impide que se ataquen problemas
> realmente grandes. Cerca de las 300 clases, el sistema se vuelve inestable
> (esto depende de las personas, puede que sea a las 30 o a las 3000, pero de
> seguro no a las 300.000). Como dice Alan Kay los que estàn "enamorados de
> los objetos" no entienden esto y piensan que incluso es bueno estar amarrado
> a esta idea, porque no piensan en los procesos.
>
> Estructurando sistemas con AOP, proxies y traits me da la impresiòn que los
> sistemas quedan mucho màs pequeños. Y esto es algo que dice Alan Kay en su
> presentaciòn tambièn: Que para que un sistema pueda crecer, necesariamente
> tiene que ser pequeño, para que sea entendible. Lo que significa que debemos
> eliminar todo ese código repetido y quedarnos con el código que realmente
> importa, para lo cuál muestra esa media página de código que implementa un
> intérprete en Lisp. No sè si ustedes saben pero la inspiración de Alan para
> crear Smalltalk fue Simula y Lisp, por eso Smalltalk corre dentro de un
> ambiente al igual que Lisp.
>
> Otra de las cosas con la que estoy de acuerdo con Alan es que los sistemas
> debieran ser màs configurables, para en tiempo de ejecuciòn tomar cambios.
> Claro que èl propone que los cambios estèn en còdigo, y no me parece mal que
> asì sea, pero creo que la mayor parte de los cambios debieran ser por
> configuraciòn, y tener configuraciones a nivel de archivos (a la Unix) me
> parece como una gran chambonada. De partida hay que saber dònde està el
> archivo, hay que saber el formato, y luego hay que reiniciar el sistema.
> Todo eso tiene soluciòn, pero sigue siendo una chambonada como idea
> original.
>
> La configuraciòn debe ser en lìnea y se debe poder guardar y copiar (como
> objeto). Las verificaciones las puede hacer el programa y lo que ejecuta
> debe preocuparse de mantener todo consistente. El enfoque de archivos es un
> enfoque flojo y pobre, pero salen hordas de programadores con esa manera de
> pensar, de modo que no me parece extraño que sólo los gerentes tengan buenos
> sueldos, si los ingenieros se ven a sí mismos como gente que hace el trabajo
> de limpieza (o trabajo repetitivo que podrìa hacer una màquina) incluyendo
> el trabajo de programaciòn, lo cual explica porqué ha habido tan poco avance
> en como se desarrollan los sistemas, ha aumentado considerablemente el
> alcance (en cuanto que hoy en dìa todas las empresas funcionan con sistemas
> computacionales), pero la calidad del software desarrollado no ha aumentado
> considerablemente.
>
> Sin duda el alcance de los sistemas no puede seguir expandièndose
> ilimitadamente, porque hoy en dìa casi todo lo que peude ser automatizado de
> manera simple ya lo ha sido, no hay personas que no tengan acceso a
> computadores (o son muy pocos los que quedan aùn). De modo que lo ùnico que
> puede pasar es que la calidad del software aumente considerablemente. Si lo
> piensas todos lossistemas que uno necesita ya existen. Se pueden comprar
> desde autos hasta departamentos por internet, puedes hacer tus operaciones
> bancarias y pagar cuentas por internet. Falta poder pagar las multas de
> trànsito por internet, pero es un detalle. Los impuestos se pagan por
> internet, ¿què tantos sistemas màs se puede desarrollar?
> Nuevas necesidades siempre va a haber, pero no serà suficiente para cubrir
> la oferta de desarrollo, de modo que necesariamente los sistemas deberàn ser
> menos monolìticos y màs fàciles de ensamblar como piezas lego. Creo que esa
> es una gran oportunidad para Smalltalk y para Java, porque son màs dinàmicos
> que los lenguajes tradicionales.
>
> El problema que tenemos es que tenemos mucha gente acostumbrada a pensar de
> la manera tradicional y entregar un EXE o un JAR al final del proceso. Se
> tiene que pensar màs como un sistema que va creciendo desde un "Hello World"
> hasta entregar todas las funconalidades pedidas. Un sistema que no es
> necesario bajarlo para subirle nuevas funcionalidades, es decir, donde se
> pueda ir desarrollando al mismo tiempo que lo estàn usando.
>
> Imagìnate un sistema con 3 pantallas, le agrego una cuarta y la gente que lo
> usa lo ve inmediatamente, voy agregando componentes en la pantalla y cada
> componente ya tiene incorporados los servicios que tiene que llamar y esos
> servicios se pueden redefinir. Eso serìa como armar sistemas como si fueran
> legos.
>
> Saludos,
> Guillermo.

> Hola gente,
>
>
> "El problema que tenemos es que tenemos mucha gente acostumbrada a pensar de
>   la manera tradicional"
>
> Como pensar que Smalltalk es un lenguaje.
>
> Realmente no estoy muy de acuerdo con todo este mail. Me parece  son de una
> simplificacion grotezca de las cosas y le da un matiz de unidimensionalidad
> al desarrollo. Esto nos ata a continuar pensando en el soft  en los terminos
> convencionales. Y el salto se da cuando se rompen esas convenciones y
> prejuicios. Pensemos la epoca cuando hicieron el Smalltalk-80. Esos si que
> rompieron con todo e inclusive muchas de las cosas que usamos hoy las
> hicieron en aquella epoca. Todavia no le llegamos ni a los talones al
> Smalltalk-80...
>
> Saludos
>
> Elvio

> Como andas Edgar,
>
> che no es ataque. Es critica o reflexion. No hay que sentirse mal cuando hay
> una critica. La idea es absorver todo lo posible de la critica y procesarlo
> cada uno. Lo que sirve sirve y lo que no, se lo lleva el viento.
>
> Muchachos es solo charla. Son ideas, no peleas. A mi me interesa que esto se
> entienda. Si cada vez que hay otra postura contrapuesta a la nuestra nos
> enojamos estamos al horno. No hay que tomarlo tan a pecho. Asi terminamos
> todos peleados, porque no podemos lidiar con otros puntos de vista. Creo que
> si seguimos ese tren gana el famoso mainstream del mercado, cuyo fin en
> ultima instancia (para poder vender), se dedica sistematicamente a hacernos
> creer que no es posible ver las cosas desde otro punto de vista, o que otro
> punto de vista es inaplicable, inapropiado, delirante, excecrable, etc.
>