[[Delphius]]

Empezado por roman

De cualquier manera, yo creo que decir que es más sencillo para el novato, entender la programación orientada a eventos de VB que la orientada a objetos de Delphi, si bien es una afirmación dictada por la experiencia, no estoy seguro que sea aplicable precisamente en el contexto de un usuario avanzado que quiere hacer sus pininos. Si bien Delphi permite una buena programación orientada a objetos, ¿cuántos de nosotros realmente aprovechamos esa característica? El instanciar un objeto y asignarle propiedades, no es programar orientado a objetos. Yo creo que tal usuario avanzado, la mayoría de veces, programará usando exclusivamente eventos. Y en ese punto estamos "igual" que con VB, y creo que es así como habría que hacer la comparación en cuestión de facilidad de aprendizaje.

¿A quien estaríamos considerando un novato? Como ya se ha dicho en este debate... y se sabe muy bien... el novato puede ser tanto aquel universitario que recien estudia la carrera como la ama de casa que busca divertirse en su rato libre (creo que fue exagerado el ejemplo... pero creo ilustrar el amplio concepto de lo que es un novato).
Para aquellas personas que se inician en la actividad le resulta (debería serlo) más sencillo aprender... obvio.
Yo estoy estudiando para ser ingeniero en informática (y aclaro que la formación que se nos ha dado en mi universidad no está muy enfocada en la programación sino más bien en la dirección y formulacion de proyectos informáticos) y creo que muchos de los que estamos analizando estas cuestiones somos (o seremos) profesionales de la materia.
Viendolo desde el punto de vista académico (disculpen que lo exponga según mi experiencia como alumno), lo ideal para armortiguar la curva de aprendizaje no va por una cuestión del lenguaje sino más por la lógica de aprendizaje. ¿Qué es lo primero que se le enseña? Pensar, abrir la mente... una vez que la mente se adapta a pensar en forma lógica/matemática se le enseñan simples herramientas visuales (diagramas de bloques), pseudocódigo y a la par las sentencias simples: IF, CASE, FOR, REPEAT, WHILE, ASIGNACION y estructuras de datos. Esta primera absorción es a modo simple: conocer que hacen o para que se las emplea.
Cuando comienzan las primeras lecciones de prácticas se toma contacto con problemas sencillos, sumas, promedios, ordenacion de arrays, busqueda... Para ello lo ideal es emplear un lenguaje similar a la sintaxis que fueron vistas, algo intituivo, sencillo y que no sea "rebuscado". En mi caso fue Pascal.

Lo anterior corresponde a los inicios... para climatizar al programador. Lo que sigue en su enseñanza es la polémica desatada en los últimos mensajes.
Cuando se entiende la programación procedural... le salen con un mundo distinto: la programacion por eventos u objetos. Yo la vi en ese orden... y a mi parecer esto influye en la mente y el aprendizaje.
Decirle al estudiante que ahora cuenta con eventos asociados a un boton es totalmente distinto que decirle: el boton es un objeto que posee eventos (y demás cosas...) y puedes heredar de el y agregarle más eventos.
Y según el lenguaje que se use en su enseñanza le resultará sencillo o complicado.

Yendo al tema VB vs Delphi: Yo vi POO con VB y la programacion por eventos en Delphi. ¿Sería lo correcto? No sé...
Todo se resume en la lógica (a si lo veo y entiendo yo) que les hablaba inicialmente.

A lo que voy es que el aprendizaje dependerá de lo que vea inicialmente y con que herramienta lo aprenda. Resulta mejor ver primero por eventos y luego POO. Ver ambas cosas a la vez, resulta demasiado complicado.

Como dices roman... todo depende de la facilidad de aprendizaje. Pero éste aprendizaje depende de la "cultura informática" que posea la persona. La cultura de un programador pasa por pensar lógicamente. Si uno entiende lo que es un IF, no interesa el lenguaje. Si se tiene la mente para pensar en sentencia simples ya no interesa si es por eventos u POO. Cada enfoque o paradigma tiene sus sutilesas y manera propia: Ahora es cuestión de que el estudiante entienda lo que es evento y lo que es objeto. Y como emplear dichas sentencias simples en cada paradigma.

Ahora... pongamos al ama de casa. ¿Entiende lo que es POO?¿Un IF?¿Que es evento? Lo más seguro es que se agarre un libro especializado en un lenguaje. Pongamos un ejemplo: Delphi y la Cara Oculta. En los primeros capítulos vera un poco de eventos... POO... controles... deteción de errores... como manejar el IDE. ¿Esto lo hace programadora? Yo, lo dudo. Se verá con un mundo de controles, objetos clases... y deberá buscar otro libro que le explique POO... cuando entienda objeto se dirá: "y ahora ¿que le pongo?... se lo que debe hacer pero como le digo que hacer?" Busca algo más simple: las sentencias simples... Si sabe inglés, tiene la mitad hecha.

¿Se ha entendido lo que dije? Porque eso espero

Con respecto a lo que remarqué con rojo en tu frase: se trata de la manera de como implementar la POO. Se tiene un problema: se buscan las clases... su diagrama de secuencia, de estado, etc. Se codifica... Ahora se usa el aspecto visual para pasar los parámetros hacia los objetos (previamente creados, obvio). Se disparan los eventos necesarios y se deja que las relaciones entre los objetos (mensajes... o como prefieran llamarle) se disparen hasta objeter el resultado final. Si debe notificarse el resultado, se lo muestra en pantalla. Asi lo veo yo... una mezcla de eventos y POO.
Es cierto también que no siempre vamos a hacer 20 clases, es más... si ya tenemos las suficientes y las adecuadas sólo bastará "engancharlas" con el aspecto visual (mediante los eventos) para obtener el aplicativo. ¡Eso es lo lindo y sencillo que le encuentro a Delphi!
Ahora bien... diste un punto clave:El instanciar un objeto y asignarle propiedades, no es programar orientado a objetos
.Cierto... pero tampoco hay que ser extremistas para decir que nunca hacemos POO. La POO se construye mediante los mensajes entre los objetos y el poder de concentrar variables, estados. Y hay casos en que ni siquiera es necesario emplear objetos pues se trata de sistemas muy simples. Yo para ello declaro unidades al estilo clásico: funciones y procedimientos sueltos (yo las llamo "Unidades API"). Si veo que la solución es algo más rebuscado, como pasos de variables, secuencia de acciones y procedimientos, almacenamiento de variables, interaccon entre varias funciones, y demás... declaro cases según el diagrama de clases adecuado (y tratando de seguir los patrones) y hago empleo de dichas funciones "API" mediante eventos y mensajes en los objetos.

Saludos, y disculpen que suelte semerendo rollo de hilo.