Una propuesta curricular de Bertrand Meyer

No soy un especialista en métodos o contenidos de aprendizaje, pero me preocupa en general, en particular en mi área de conocimientos, y más todavía, en el territorio cultural en el que me desenvolví históricamente. Pasé décadas en Argentina viendo sucesivas reformas educativas, y observando un resultado crecientemente más pobre...(puede que a otros les suene familiar este asunto). Ray Bradbury tenía un título llamado "El hombre ilustrado", que leí hace ya demasiado tiempo, pero del que creo recordar que enfocaba el desfase entre un paradigma cultural y una nueva época. Sea ese o no el tema de Bradbury, quizá lo que para mí sea una nota desalentadora, sea simplemente el no comprender otra forma de hacer las cosas...Será así?
Sin embargo, a través de la observación de las preocupaciones de estudiantes al pedir ayuda, en su participación en foros de Ingeniería de Software u otros semejantes, en conversaciones directas, en la participación en el mercado laboral, encuentro muchos rasgos comunes, que desearía que fueran distintos a cómo son.
En mis lecturas rápidas de vacaciones encontré una propuesta curricular de Bertrand Meyer que aparenta ser valiosa. Dado que es de 1993, supongo que ya debe tener un buen número de críticas, y que debe tener respuestas superadoras que los especialistas conocerán. Trataré de averiguar más sobre su desenvolvimiento posterior. Sin embargo, en un ámbito específico, me dá argumentos de peso en algunos puntos que en meses pasados hemos discutido con otros colegas.
La propuesta de Meyer trata sobre la enseñanza del enfoque orientado a objetos en Informática. Extienda sus fundamentos al área de estudios que considere...
El objetivo de Meyer:

As the software community recognizes the value of the object-oriented approach, the question increasingly arises of when, where and how to include object-oriented concepts, languages and tools in a software curriculum -- university, college or even high school.

This article proposes a coordinated approach to structuring such a curriculum, based on systematic reliance on the best aspects of the object-oriented method. It suggests a radical departure from the traditional methods of teaching programming, design and analysis: the progressive opening of black boxes, also known as the ``inverted curriculum'' and based on the systematic use of object-oriented libraries of reusable components. It also offers ideas for university departments that are in search of ambitious, multi-year federating projects.

Uno de los puntos de mayor interés, comparativamente; cuándo empezar:

The earlier the better. The object-oriented method provides an excellent intellectual discipline; if you agree with its goals and techniques, there is no reason to delay bringing it to your students; you should teach it as the first approach to software development. Beginning students react favorably to object-oriented teaching, not just because it is trendy, but because the method is clear and effective.

This strategy is preferable to a more conservative one whereby you would teach an older method first, then unteach it in order to introduce object-oriented thinking. If you think object-oriented development is the right way to go, there is no reason to delay.

Este punto de vista, de "introducir" un conocimiento pasando por toda su historia, de tal forma que el núcleo de real interés se termina viendo al final, a veces con poco tiempo restante, y luego de ser contaminado con otros métodos o conocimientos que luego sabemos son antecedentes, es un criterio que he visto más veces de las deseables, y uno de los puntos que discutiéramos con otros colegas hace algún tiempo.

There is little justification for such an approach which, transposed to elementary education, would mean that students first learn to count in Roman numerals, only later to be introduced to more advanced ``methodologies'' such as Arabic numerals. If you think you know what the right approach is, teach it first.

Meyer defiende la idea de introducir directamente a los estudiantes en el conocimiento más actualizado y adecuado, el que técnicamente sea el corrientemente aceptado, en forma clara, en lugar de sufrir en una travesía complicada:

Just explaining why an array and a pointer have to be treated as the same notion -- a central property of C-based languages, having its roots in obscure optimization techniques for hardware architectures of the nineteen-sixties -- would consume precious time and energy, which will not be available for teaching the concepts of software design. More generally, students would be encouraged, at the very beginning of their training, to reason in terms of low-level mechanisms -- addresses, pointers, memory, signals. They would inevitably spend much of their time, if they eventually produce any compilable program, chasing various damaging bugs. The approach would leave the students perplexed and might well end up in disaster.

In contrast, an introductory course must focus on the essential concepts and techniques, and present the students with a clear, coherent set of principles. The notation must directly support these principles; in fact there must be a one-to-one correspondence between the language and the method. The language must help the students, not confuse them.

Otros dos conceptos defendidos son: Progresiva apertura de cajas negras, introduciendo nuevos conceptos y mayor complejidad a medida que se avance en la práctica, partiendo de librerías de contenido bien desarrollado, en lugar de mantenerse en un nivel de ejemplos de trabajo básicos:

A frustrating aspect of many courses is that teachers can only give introductory examples and exercises, so that students do not get to work on really interesting applications. One can only get so much excitement out of computing the first 25 Fibonacci numbers, or replacing all occurrences of a word by another in a text -- two typical exercises in an elementary programming course.

With the object-oriented method, a good object-oriented environment and, most importantly, good libraries, a less traditional strategy is possible if you give students access to the libraries early in the process. In this capacity students are just reuse consumers, and use the library components as black boxes in the sense defined above; this assumes that proper techniques are available for describing component usage without showing the components' internals.

With this technique students can start building meaningful applications early: their task is merely to combine existing components and assemble them into systems. In many respects this is a better introduction to the challenges and rewards of software development than the toy examples that have been the traditional mainstay of introductory courses. (...)Then little by little the students are induced to adapt the components to new purposes -- either by copying them and modifying the copies, or by using the inheritance mechanism, whose very purpose is indeed to support a combination of reuse and adaptation. In the process the need for new software elements will most likely arise, so the students will start writing their own classes; they only do so after having had extensive exposure to the best possible examples of quality object-oriented software -- library classes.

El otro punto: Desarrollo de proyectos de más larga duración, si es posible, multianuales:

(...) it is interesting to have the students build a system by successive enhancement and generalization, each year's class taking over the collective product of the previous year and trying to build on it. This method has some obvious drawbacks for the first class (which collectively serves as advanceman for future generations, and will not enjoy the same reuse benefits), and I must confess I have not yet seen it applied in a systematic way. But on paper at least it is an attractive idea. There hardly seems to be a better way of letting the students weigh the advantages and difficulties of reuse, the need for building extendible software and the challenge of improving on someone else's work.
(...) Even if the context does not permit such a multi-year strategy, instructors in charge of software education should try to avoid a standard pitfall. Many undergraduate curricula include a ``software engineering'' course, which often devotes a key role to a software project to be carried out by the students, often in groups. Such project work is necessary, but often disappointing because of the time limitations stemming from its inclusion in a one-trimester or one-semester course. If the academic administration can at all be convinced, it is much preferable to run such a project over an entire schoolyear (even the total amount of allocated work is the same). Trimester projects, in particular, border on the absurd; they either stop at the analysis or design stage, or result in a rush over the last few weeks to code at any cost and using any technique that will produce a running program -- often defeating the very purpose of software engineering education. It is desirable to have a little more time on your hands, so as to let the students appreciate the depth of the issues involved in building serious software. A year-long project, whether or not it is part of a longer-term policy as suggested above, favors this process. It is a little more difficult to fit into the typical curriculum than the standard trimester or semester course, but well worth the fight.

(Todos los subrayados en negrita son míos).
Como decía, esta es una propuesta de 1993. Este tipo de propuestas son leídas y pesadas a la hora de preparar el material de trabajo en la Universidad?
Si me guío por múltiples impresiones obtenidas, creo que no...