En general estoy de acuerdo contigo, aunque déjame que afine algunas cosas, de buen rollo ;-)
En cuanto a paradigma yo más bien diría:
Programación Imperativa (PI)
Programación Orientada a Objetos (POO)
Programación Declarativa (PD)
No coicido contigo en llamar a la programación estructurada un paradigma, porque es una característica posible más o menos común en los lenguajes modernos y se puede implementar en muchos lenguajes (como la programnación orientada a objetos, posible en lenguajes imperativos como C, por ejemplo; con la diferencia de que no creo que la programación estructurada sea un paradigma, sorry XD).
Claro que puedes programar no estructurado en C (?), pero no veo que eso sea un paradigma en si mismo. ¿Es incompatible con el resto? Puede que vengamos de diferente escuela. En mi época se mencionaba cuando saltabas de Basic con números de linea a C, por ejemplo X-D
La verdad, empezar por POO me parece fuerte si no hay una base de PI, que viene a ser algo así como los ejercicios que propones (control de flujo, bucles, entrada salida, etc).
La PD debería ser delito y solo crea a monstruos programadores en SWI/Prolog y cosas peores X-D (no lo entiendo, tengo miedo).
La PI es mi candidata, claro :-) Aunque no se puede quedar ahí, la programación POO debería ser un buen objetivo final, aunque es mucho más difícil plantear problemas sencillos desde POO (porque implica que existan objetos, contradictorio con la simplicidad).
Yo destacaría que aprender a programar NO es hacer aplicaciones. Ni mucho menos. Para hacer cualquier cosa en Delphi, VB, o lo que sea que uses de herramienta visual, tampoco hay que saber programar mucho. Se puede limitar todo a conocer el IDE y rellenar en gran medida formularios.
Se que es duro, y que cada vez cuesta más separar toda la parafernalia de un SO moderno y ver los problemas reales que debemos resolver cuando aprendemos a programar. Dejarse de ventanitas es muy importante, y a lo mejor programar un bubble sort al principio es un complicadísmo, o un merge sort o quick sort.
Aprendiendo a programar las prisas son el peor compañero de viaje.
He estado dando clases de programación, y me voy a contener de poner la URL aquí (es que tengo una lista de correo con menos tráfico que... buah). Si a alguien le interesa que haga ese primer ejercicio de encontrar la página de las clases XD
Desde mi experiencia, empezar con C como lenguaje imperativo para terminar en C++ como lenguaje orientado a objetos, es una buena opción y me ha funcionado bien. Todo aderezado con la cantidad adecuada de teoría, que es importante (aunque se meta sutilmente; diagramas de flujo, pseudocódigo, etc.).
A ver, lo que es programación estructurada y programación orientada a objetos lo tengo claro... Pero alguien me puede aclarar qué es eso de programación declarativa? Gracias.
Es algo sencillo... las permutaciones de N elementos es lo mismo que, para cada elemento de los N, fijarlo como primer elemento de la combinación, y proceder de la misma forma (recursivamente) con el resto de los elementos.
Tal vez no sea la solución más rápida (en cuanto a ejecución puede referirse) ni tampoco la que menos memoria consuma... eso sí, seguramente sea la que más rápido escribas.
La recursividad es muy muy potente en algunos casos.
Y ya al hilo de la conversación, aprender también algún lenguaje declarativo te permite buscar soluciones por otras vías. La solución que he propuesto sería la típica que haría un programador de prolog (en apenas 4 líneas). Portar una solución a un problema sencillo (como es este caso) a C, también es muy sencillo.
Algunas puntualizaciones y más
(Puntos:1)En general estoy de acuerdo contigo, aunque déjame que afine algunas cosas, de buen rollo ;-)
En cuanto a paradigma yo más bien diría:
No coicido contigo en llamar a la programación estructurada un paradigma, porque es una característica posible más o menos común en los lenguajes modernos y se puede implementar en muchos lenguajes (como la programnación orientada a objetos, posible en lenguajes imperativos como C, por ejemplo; con la diferencia de que no creo que la programación estructurada sea un paradigma, sorry XD).
Claro que puedes programar no estructurado en C (?), pero no veo que eso sea un paradigma en si mismo. ¿Es incompatible con el resto? Puede que vengamos de diferente escuela. En mi época se mencionaba cuando saltabas de Basic con números de linea a C, por ejemplo X-D
La verdad, empezar por POO me parece fuerte si no hay una base de PI, que viene a ser algo así como los ejercicios que propones (control de flujo, bucles, entrada salida, etc).
La PD debería ser delito y solo crea a monstruos programadores en SWI/Prolog y cosas peores X-D (no lo entiendo, tengo miedo).
La PI es mi candidata, claro :-) Aunque no se puede quedar ahí, la programación POO debería ser un buen objetivo final, aunque es mucho más difícil plantear problemas sencillos desde POO (porque implica que existan objetos, contradictorio con la simplicidad).
Yo destacaría que aprender a programar NO es hacer aplicaciones. Ni mucho menos. Para hacer cualquier cosa en Delphi, VB, o lo que sea que uses de herramienta visual, tampoco hay que saber programar mucho. Se puede limitar todo a conocer el IDE y rellenar en gran medida formularios.
Se que es duro, y que cada vez cuesta más separar toda la parafernalia de un SO moderno y ver los problemas reales que debemos resolver cuando aprendemos a programar. Dejarse de ventanitas es muy importante, y a lo mejor programar un bubble sort al principio es un complicadísmo, o un merge sort o quick sort.
Aprendiendo a programar las prisas son el peor compañero de viaje.
He estado dando clases de programación, y me voy a contener de poner la URL aquí (es que tengo una lista de correo con menos tráfico que... buah). Si a alguien le interesa que haga ese primer ejercicio de encontrar la página de las clases XD
Desde mi experiencia, empezar con C como lenguaje imperativo para terminar en C++ como lenguaje orientado a objetos, es una buena opción y me ha funcionado bien. Todo aderezado con la cantidad adecuada de teoría, que es importante (aunque se meta sutilmente; diagramas de flujo, pseudocódigo, etc.).
Un saludo.
Una pregunta...
(Puntos:1)( http://julipedia.blogspot.com/ )
The Julipedia [blogspot.com]
Re:donde?
(Puntos:1)( http://www.flagsolutions.net/ )
Tal vez no sea la solución más rápida (en cuanto a ejecución puede referirse) ni tampoco la que menos memoria consuma... eso sí, seguramente sea la que más rápido escribas.
La recursividad es muy muy potente en algunos casos. Y ya al hilo de la conversación, aprender también algún lenguaje declarativo te permite buscar soluciones por otras vías. La solución que he propuesto sería la típica que haría un programador de prolog (en apenas 4 líneas). Portar una solución a un problema sencillo (como es este caso) a C, también es muy sencillo.
Saludos, y espero haberte ayudado.
Lo que se puede medir, se puede mejorar.