Una de las cosas que más me llama la atención es que entré a Ingeneiría hace 20 años y aún el currículum es el mismo, siendo que todos los días se descbren (o debería decir se "construyen") cosas nuevas.
En la Universidad Católica se enseñaba Scheme en primer año y el sesgo de los profesionales que salían era claro: Aunque escribieran SQL el código siempre parecía estar escrito en Lisp. Recursividad a fondo. Los alumnos se quejaron de que no había trabajo en Scheme y por lo tanto decidieron cambiar de lenguaje. Un profesor nos preguntó en clases qué lenguaje pensábamos que sería apropiado y obviamente le dije que Smalltalk a lo que me respondió con una mirada de esas que matan y un silencio sepulcral. ¿Alguna otra sugerencia? Supongo que el grave problema que tienen los lenguajes que no son populares es que no se puede encontrar trabajo usándolos directamente, cosa que me queda claro que ya están resolviendo en Argentina. Pienso que usar Smalltalk en primer año debiera ser fácil dado que el lenguaje es realmente simple y debería servir para introducir los conceptos que los alumnos requieren: Estructuras de control (ifTrue: timesRepeat: whileTrue:), Enteros, Strings, Arreglos, archivos, etc. Incluso sospecho que se aprendería tan rápido que quedaría tiempo para explicar un par de ideas avanzadas. Luego en los años siguientes de carrera podrían aprender otros lenguajes simplemente haciendo la comparación con Smalltalk, no debería ser dificil. ¿Porqué digo esto? Bueno aparte de que esta es la lista de Smalltalk y supongo que no habrá nadie que se oponga, me encontré con el blog lambda de ultimate que hacía tiempo que no leía, gracias a la sugerencia de Angel Lopez y acá http://lambda-the-ultimate.org/node/2741 dice: Does it Compose? In large lock-based systems we have a lot of difficulty avoiding race-conditions and deadlocks and priority inversions and starvation and convoying. In a large system with locking, you need to grok the whole system to prevent problems; independently valid components that use locking code might deadlock when composed. That makes locks very difficult to reconcile with large systems - especially those involving open (third-party pluggable) modularity. We have a much easier time with data-parallelism, where we split large calculations into different threads (Cilk, Intel Concurrent Collections, OooJava, Data Parallel Haskell). Where we need concurrent semantics, we have easier time with shared-nothing and lock-free architectures (SOA, Actors, FBP, Publish/Subscribe), or event-loop concurrency (E, Croquet, Win32), or single-assignment concurrency (Oz, concurrent constraint), or temporal logic concurrency (FRP, Dedalus, TCC, UTCC), or transactional systems (databases, tuple spaces, blackboard, hibernate, gemstone, STM). The fact that so much of our computing infrastructure explicitly uses semaphores and mutexes and shared-resource threading speaks of some odd perceptions of the subject, widespread ignorance of other options, maybe a naive considerations for performance and hand-optimization, or perhaps just inadequate language design - the fault of a language community that too easily dismisses concurrency as something to 'tack on' later (excusable for C in 1972, but less so for Bit-C in 2008). There is also a lot of inertia: the prevalence of synchronous IO from the OS (such as every process having three synchronous ports by default) - despite the fact that modern CPUs perform almost no synchronous operations. The limited tools offered by the OS make it difficult to implement other concurrency models efficiently, which certainly resists migration away from thread-based shared resource concurrency, which in turn discourages experiment with providing other concurrency models from the OS. Fighting against inertia is difficult, sometimes radical. Finally, there are also extremely low standards for success. Somehow, in a manner I find nigh incomprehensible: developers that struggle to get the locking right, fail, fight off recurring concurrency bugs repeatedly, discover rare race-conditions months after shipping, fix one bug to create another... these developers will turn around and say that threading and locks were successful and comprehensible. Consider this reportwhere students consistently reported that locking was 'easier' even though they consistently made more mistakes. Is this confabulation? selective memory? unconscious incompetence? Maybe there's something about human nature that associates a retrospective 'triumph' with'good tools' even though it really means 'your tools sucked, you fool; you built this with your own blood, sweat, and parentheses'. Real progress is measured by the extent to which we no longer need to think about or struggle with what we are doing, yet can still accomplish our goals effectively and efficiently - thereby leaving us open to higher-level goals, but offering no 'triumph' for whatever the tool purposes. Modern OS kernels are examples of 'triumph'. That should tell you just what I think of the tools the developers were using. Of course, until better tools are available (and the OS itself can in many ways be considered such a tool) a triumph every new kernel will be. By dmbarbour at Fri, 2010-10-22 19:10 . Lo que dice en resumen es que existen muchas solcuiones que funcionan mejor que las herramientas de bajo nivel como los mutex y los threads, pero que los programadores tienden a elegir las herramientas de bajo nivel porque según dicen el resultado es más claro. Lo que pasa acá puede ser que simplemente el currículum no se adecúa a los nuevos conocimientos y supongo que buena parte de la carga se debe a que los lenguajes que usamos para enseñar son de tan bajo nivel. Muchas de las ideas que hoy en día están implementadas en Java salieron originalmente de Smalltalk y de otros lenguajes usados en la academia (no usados exclusivamente en ella, pero sí principalmente). Smalltalk probablemente es uno de los más extraños en ese respecto porque fue usado durante mucho tiempo en la industria financiera y Java copió casi todo de Smalltalk, excepto la sintaxis. Imagino que es hora que se de vuelta la tortilla y muchas de las ideas que se implementaron en Java ahora sean parte de Smalltalk. Uno de los múltiples ejemplos que menciona en dmbarbour en lambda the ultimate es oooJava: http://www.usenix.org/event/hotpar10/tech/slides/jenista.pdf sugún explica puede lograr un "speedup" de 7.8x en un RayTracer, lo que a todas luces es alucinante. Se podría pensar en usar un enfoque así en Smalltalk para hacerlo más rápido. ¿Qué opinan? -- Simplex Veri Sigillum -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
