Etiquetas
Uno de las asignaturas que enseño en la UIB es «Sistemas Operativos 2», del segundo semestre del segundo curso de la ingeniería en informática. En esta asignatura enseñamos fundamentalmente gestión de memoria, de E/S y sistemas de ficheros.
La práctica consiste en el desarrollo en C desde cero de un sistema de ficheros basado en i-nodos. Quizás es la práctica más difícil y extensa (aunque son poco más de 2.000 líneas de código en C) que se hayan encontrado, pero tampoco es tan complicada. De hecho uno de los objetivos de la práctica es desmitificar la complejidad (de los conceptos fundamentales, el demonio está en los detalles) de los sistemas de ficheros. Pero nos encontramos con muchos problemas:
- No saben relacionar lo aprendido en estructuras de datos. Por ejemplo, a esta alturas ya han visto árboles y el recorrido iterativo y recursivo en ellos, sin embargo les cuesta mucho hacerlo para la traducción de bloques lógicos a físicos (que es básicamente recorrer árboles de uno, dos o tres niveles).
- Falta de práctica de programación. No están acostumbrados a desarrollar programas que sean mayores a un par de cientos de líneas, cuesta mucho que muestren código que «huela» bien, ni siquiera son capaces de sangrarlo correctamente, son incapaces de hacer el diseño del programa.
- Desconocimiento de C, del compilador, y de su relación con la arquitectura de los ordenadores.
Para que estos problemas no bloqueen todo el desarrollo, el diseño se lo pasamos hecho al nivel de funciones con un programa semanal de qué funciones deben implementar y cómo probarlas. Además les pasamos el código de las funciones de recorrido de las estructuras más complejas.
Aún minimizando los problemas anteriores, el otro gran problema que tienen -y creo que el peor- es la incapacidad para analizar y corregir los errores del código. Aún en las partes más sencillas y obvias, es típico el diálogo:
– Profesor, el programa me falla.
– ¿Dónde está el fallo?
– No lo sé, da un segmentation fault.
– Pero ¿en qué función?.
– No lo sé, lo hace apenas lo ejecutamos.
– Pero ¿no has puesto ni print-efes para saber por donde se cuelga?
– ¿Dónde los pongo?
Es muy fustrante, les pego unos rapapolvos importantes. El ejemplo que doy a continuación es un caso real, del lunes pasado.
Como parte de las pruebas del sistema de fichero, tienen que desarrollar unos programas concurrentes que escriban una estructura de datos en posiciones aleatorias de un fichero. Luego otro programa tiene que recorrer secuencialmente ese fichero y detectar las escrituras, la forma fundamental es verificar que uno de los campos de la estructura sea igual al PID del proceso que escribió en ese fichero.
Un par de alumnos tenían problemas, después un un diálogo muy similar al anterior les indiqué que antes que les mire el código debían indicarme exactamente el sitio donde les daba problemas. Me mostraron el siguiente código:
struct record rec, rec2;
char pathname[256];
...
my_read(pathname, &rec, position, sizeof(rec));
while (rec.pid != pid) {
position += sizeof(rec);
my_read(pathname, &rec, position, sizeof(rec));
}
printf("Final del bucle\n");
Me dijeron:
– El problema es que nunca sale del bucle.
Es decir, según ellos, que nunca se cumplía la condición de que rec.pid sea igual a pid. Les indiqué el primer problema, el código no verificaba que se haya llegado al fin del fichero (es decir, que el resultado de my_read() sea mayor que cero). Si no salía de ese bucle, el my_read() debería estar generando errores y muy raro que no salga ningún error. En un momento de la conversación, y después de varios minutos verificando que el fichero estaba bien (el my_read() funciona correctamente), les digo:
– Esto no puede ser, debe haber otro error ¿habéis verificado que el nombre del fichero en pathname sea correcto?
– Ahora que lo dices, en una de las pruebas cuando habilitamos la impresión de errores nos dio «la ruta no existe».
– ¡¡¡¡#$@!!!
Les pedí que impriman el valor de la variable pathname, y en vez de un /dir1/dir2/datos.dat salía /dir1dir2/datos.dat, todo por olvidare de una «/» en el sprintf() para el pathname.
Es decir, el problema no estaba ni el bucle, sino unas cuantas líneas más arriba de él, pero no fueron capaces de darse cuenta de ello. A los pocos minutos los mismos alumnos me dicen:
– Ahora nos da segmentation fault después del bucle, en estas instrucciones, y no sabemos por qué.
Voy a mirar esas líneas:
rec2.pid = rec.pid; rec2.x = rec.x; rec2.y = rec.y; rec2.z = rec.z ... /* más código complejo */
Era obvio que esas instrucciones, asignación de estructuras idénticas (y sin punteros involucrados) no podían generar un segmentation fault (además de la optimización es obvia y con menos código: memcpy(&rec2, &rec, sizeof(rec)).
– El error no está allí, ¿por qué decís que son esas líneas?
– Porque lo último que imprime es la salida del bucle.
– Pero ¿estáis seguro que es allí y no en el código de más abajo? ¿habéis puesto un printf para verificar?
– No.
– 
(y rapapolvos varios)
Estos casos son los que nos encontramos cada día en el laboratorio y tutorías, ayer mismo me pasó otro. Un grupo me dice:
– Profesor, el programa nos falla, ¿lo puede mirar?
– Pero ¿cuál es el fallo?
– No sabemos, nos da stack smashing detected
– Eso es porque trabajáis con algún puntero local y os estáis saliendo de los límites, por eso el error en la pila. ¿En qué función dónde da eso?
– Hummmm… creemos que en esta, pero aquí no hay nada raro.
Miro la función y detecto el error inmediatamente, les indico que es el «sprintf».
char pathname[11]; sprintf(pathname, "%s/%s/pruebas.dat", dir1, dir2);
– Pero ¿por qué el error? si está bien.
– Porque la longitud del string generado es superior a 11.
– Pero si «pruebas.dat» es menor que 11.
– (y enésima explicación de strings, array de caracteres, y rapapolvos varios).
Este segundo ejemplo muestra el desinterés por aprender bien las herramientas que usan (el lenguaje C es muy sencillo), pero también hay una incapacidad de asumir que se cometen errores y de interpretar y analizar el código. Aunque es una técnica muy habitual en programación, son incapaces de reducir el espacio del problema para analizar el código (tan fácil como poner print-efes donde toca). A pesar de las horas que llevan de programación en más de un año y medio de carrera, no tienen siquiera la iniciativa de poner mensajes para así poder llegar exactamente a la instrucción que les está provocando el error. En pocas palabras, carecen de las habilidades básicas para hacer debugs de programas, que a su vez es una habilidad básica de los programadores.
No sé qué estamos haciendo mal en la universidad para que no tengan un dominio básico de debugging. O si el problema lo arrastran de instituto, por ejemplo, no tener iniciativa para resolver por sí solos los problemas, esperan -y casi exigen- que el profesor tenga capacidad adivinatorias superiores que les evite pensar a ellos. O que no hayan tomado conciencia que cualquier profesional necesita conocer las herramientas con las que trabaja.
Después de dos años de una carrera de ingeniería informática no podemos permitir que tengan esas carencias fundamentales, en temas tan básicos. Tenemos problemas de calado en la forma en que los formamos. O quizás deberíamos empezar a tomar no tan en serio lo del «seguimiento personal a los alumnos» del Plan Bolonia y dejar que se apañen solos, que parece que lo seguimos tratando como a niños desvalidos intelectualmente.
En cualquier caso, ya me desahogué, es frustrante. Y perdón a mis alumnos por los rapapolvos, pero es que es muy frustrante (y mejor que se los dé yo, antes que su primer jefecillo 😉 ).
Relacionado (gracias): Why I never give straight answers.
Ricardo Galli, de software 
Precisamente lo que no aprendí en la carrera, lo hice en las primeras semanas en el trabajo. Allí no viene nadie a ayudarte, te buscas la vida.
No te mortifiques tanto, estás en la etapa de profesor guay. Dentro de diez años pasarás olímpicamente de tus alumnos y serás uno mas.
Ley de vida.
Pingback: La incapacidad de solucionar errores de nuestros estudiantes de informática
En mi opinión, el problema viene desde el instituto.
No se enseña nada realmente útil en la asignatura de informática, solo Word y Excel en Windows XP (o este es mi caso), y si eso algún juego con Scratch o algo de HTML básico.
Se debería aprender a programar en Bachiller, en una buena asignatura de informática, y no en los ratos libres que tenga cada uno en su casa.
Reciente y relacionado: http://lemire.me/blog/archives/2013/06/03/why-i-never-give-straight-answers/
@Veisslan
Llevo 20 años enseñando Sistemas Operativos 😉
BTW, ¿puedes recomendar algún buen libro (o libros) para aprender C? El curso que viene empiezo la carrera y no quiero ir desde 0 😛
-En primer lugar señor Galli, es totalmente normal que no sepamos aplicar estructuras de datos a su asignatura, ya que misteriosamente, Estructuras de datos se da en el mismo cuatrimestre y los arboles concretamente se dan casi al final del curso, cuando su practica anda ya por la etapa 7 u 8.
-Falta de programacion, no se lo discuto, puesto que la mayoria solo han programado en primero (4 cosas básicas) y en el primer quatrimestre de segundo, y sobre lo del sangrado… me gustaria que me dijese cuantas prácticas le han entregado sin sangrar o en código espagueti.
-Desconocemos C, si totalmente de acuerdo, ya que su asignatura es la primera en la que se da C, ya que gracias a su gran amigo T.E. que da SO1 , lo que nos enseñan de C es lo mismo que nos enseñan a conducir aviones y lo peor de todo es que usted que tanto lo critica sabe muy bien que todo esto es cierto.
El Lenguaje de Programación C, de Kernighan y Ritchie.
Como moderador de unos foros de programación, veo ese problema a diario, constantemente, y lo más grave es que no aprenden, siempre vienen con la misma canción:
No sólo no saben buscar dónde está el error, es que ni siquiera saben identificarlo, y si les preguntas, además, se molestan, o contestan con un vago mensaje: , y se quedan tan anchos, esperando que usemos nuestra bola mágica para resolverles el problema.
¿Usar el depurador?, eso es sólo cosa de «gurús», la inmensa mayoría no tienen ni idea, no saben ni que existe.
En fin, paciencia.
Saludos.
Por cierto, he puesto texto «entrecomillado», pero con los signos «mayor que» y «menor que» y ha desaparecido ese texto, no se ve en mi comentario anterior.
Saludos.
Yo antes de entrar en la universidad ya había hecho un curso de Basic (con 14 años), 1 de Pascal (Turbo Pascal) y 2 de C (Turbo C) en academias privadas, por lo que se me hace difícil recordar cuando adquirí esas «habilidades» para depurar.
Además, en aquella época, sin Internet y en el que conseguir un compilador ya era algo épico, tenías que apañartelas tu solo si o si.
De todas formas tu tienes un sesgo importante, ya que no creo que el 100% de tus alumnos sean así, si no que solo vienen a preguntarte los menos «experimentados».
Ricardo, como ex-alumno tuyo tengo que decir que no es tu caso, pero en mi época había muchos profesores en la UIB que en sus clases limitan que el alumno pensara por sí mismo.
Eran de esos que plantean un problema y que dan como incorrecta cualquier solución que no se parezca a la que proponen ellos mismos, aunque no haya por dónde cogerla.
Recuerdo sobre todo un caso en el que suspendí la asignatura por plantear un diagrama entidad-relación diferente al propuesto por la profesora (el suyo tenía relaciones 1-1 y M-N sin ningún sentido). Al defender mi propuesta cara a cara empezó diciendo que mi trabajo era un auténtico desastre. Al explicárselo pasó a decir que veía que yo tenía muy claro lo que hacía, aunque luego remató con un contundente: «pero te tengo que suspender porque no es la solución que he propuesto en clase». Con dos cojones (ovarios, en este caso). Acabé denunciándola, pero no me hicieron ni p#to caso…
No sé si el panorama actual es diferente, pero cuando yo estudiaba no costaba encontrar profesores en las carreras de informática que no habían trabajado nunca en el «mundo real». Y cuando empiezas, te tragas todo lo que te digan. Pero cuando sales fuera y empiezas a trabajar y vuelves por las clases, te das cuenta de que hay más de un iluminado que está enseñando sobre algo que ha visto en los libros, pero que nunca a tocado con las manos.
Y luego pasa lo que pasa…
Es cierto que al llegar a SOII algunos alumnos alumnos son un poco «perros» a la hora de hacer debugg y es más comodo dejárselo al profesor. También considero que la práctica, en algunas partes, se entrega muy masticada, y que las funciones recursivas, aunque no se puede pedir que se sepan al dedillo ya se han dado en algoritmia, pero lo que no se puede hacer es dejar toda la culpa sobre el alumnado ( y menos cuando se trata sólo de una parte).
«No saben relacionar lo aprendido en estructuras de datos. Por ejemplo, a esta alturas ya han visto árboles y el recorrido iterativo y recursivo en ellos, sin embargo les cuesta mucho hacerlo para la traducción de bloques lógicos a físicos (que es básicamente recorrer árboles de uno, dos o tres niveles).»
Estructura de datos es paralela a SOII por lo que el conocimiento, si se ha dado en la etapa necesaria de la práctica, está aún bastante verde y sin la asimilación que supone realizar una práctica con ellos.
«Falta de práctica de programación. No están acostumbrados a desarrollar programas que sean mayores a un par de cientos de líneas, cuesta mucho que muestren código que “huela” bien, ni siquiera son capaces de sangrarlo correctamente, son incapaces de hacer el diseño del programa.»
Esto es una de las maravillas de bolonia, las asignaturas son de 4 meses y no puedes empezar desde el principio a hacer una buena práctica. Esto provoca que las prácticas asignadas no requieran muchas líneas de código ni un gran diseño.
Sobre el sangrado… toda la razón del mundo, duele a la vista, pero del total de alumnos habrán 2 o 3…
«Desconocimiento de C, del compilador, y de su relación con la arquitectura de los ordenadores.»
Esos conocimientos no vienen por inspiración, y menos aún por SOI.
Bueno Ricardo, comparto plenamente la opinión de «El_Justiciador» que ha escrito más arriba.
1) ¿Cómo vamos a dominar el temario de estructuras de datos si se hace en el mismo cuatrimestre que SO2?
2) ¿Cómo vamos a saber hacer según qué en C si en SO1 tuvimos a un inútil como T.E.B.?
Tengo aprobada SO2 pero no precisamente gracias a los conocimientos previos que tenía, sino a base de echarle horas y hacer tutorías. Tu asignatura es una carga de trabajo muy importante y, aunque para ti no lo sea, para muchos alumnos es un calvario lidiar con tantas cosas desconocidas hasta el momento. Salvo que seas el empollón de turno que invierte la poca vida social que le queda tras la carrera en ser auto-didacta y aprender a hacer cosas que NO se han impartido en el grado en informática es muy difícil afrontar tu asignatura.
¿Que el sistema educativo está mal y llegamos mal formados? SÍ, pero eso no es culpa nuestra, mira dentro de tu departamento y tus colegas en vez de culpar a los alumnos.
No sé si habrán cambiado muchos las cosas desde los tiempos que estudie en la UIB, pero los problemas que cuentas Ricardo, independientemente de la pericia y motivaciones de la nueva generación son:
-En el primer curso de carrera hay poca carga de programación, 1 asignatura, frente al exceso de carga de otro tipo de asignaturas no tan necesarias en un primer curso (análisis matemático, economía, física, etc…)
-El nivel del curso de programación era realmente bajo, con una mayor preocupación por «lo formal» que por lo «práctico». Además, en mis tiempos no había feedback por parte del profesor sobre el contenido de la práctica, así que si hacías código bueno o malo nadie te corregía al respecto. Y que no se me olvide, la elección de Pascal como lenguaje de programación.
-Se podía cursar tu asignatura teniendo suspendida la programación, vamos, que no había prerequisitos para tu asignatura.
– El shell, que fue la que hice yo, fue la práctica con mayor dificultad de programación que tuve en toda la ingeniería técnica.
Es decir, sin obviar la culpa de los estudiantes, resulta bastante claro que el timing plan de estudios podría mejorarse.
Yo creo que el problema grave, como tú apuntas, es la falta de iniciativa propia. Como el alumno de más arriba, que se queja de que no saben C porque no se lo han enseñado en ninguna asignatura, habiendo como hay millones de recursos en Internet para aprender C en dos tardes. No como para programar perfecta y eficientemente, pero sí al menos para los conceptos básicos y necesarios.
Yo estudié la diplomatura allá por el pleistoceno. Tú nos diste dos semanas de clase de C++ (sé má má) dentro de la asignatura de Biel Fiol, creo que era también tu estreno en la UIB. Como apunta alguien antes, quien más quien menos antes de empezar la carrera ya había hecho sus pinitos con el Pascal y el Basic en su casa (y alguno muuuy friki incluso sabía hacer cosas en C y ensamblador), a base de libros, revistas y manuales porque no teníamos Internet.
Es cierto que había algunos profesores como la que describe el del comentario anterior (Heidi, seguro), que lo que tenías que aprender no era a hacer las cosas bien, sino a hacerlas como a ELLA le gustaba. Pero no eran tampoco los más.
La diferencia con los alumnos de ahora creo que es la actitud, no la aptitud.
Yo ahora, después de casi 20 años dedicado a la informática, estoy estudiando magisterio de primaria. Y todas las teorías de la educación que se impulsan ahora son muy diferentes a las que se aplicaban cuando nosotros estábamos en la EGB. Ahora se educa buscando la educación personalizada y los objetivos son la adquisión por parte de los alumnos de competencias, más que de datos memorísticos. Y me parece bien, pero para primaria. Una de las competencias que se dice que se debe adquirir es la de iniciativa personal, y «aprender a aprender». Y algo está fallando cuando llegan a la Universidad y no son capaces de «buscarse la vida» cuando enfrentan algún problema.
Si los tenemos que llevar siempre de la mano, algo falla.
Cuantos más años lleves dando la asignatura, más fallos verás en los alumnos que son primerizos y que ni tienen una carrera universitaria, ni han programado nunca en C tal y como comentan los justicieros de por arriba.
Imagínate que viniera una profesor@ nueva a tu asignatura, con una carrera de informática, y que ya supiera programar (en teoria), pero no tuviera ni idea de la asignatura ni de la práctica. Si esta hipotétic@ profesor@ no supiera ni hacer eso, imagínate lo que podrías exigir a alumnos inexpertos, que no tienen culpa de que no se les haya enseñado.
Estoy de acuerdo con la opinión de que cada uno debe buscarse la vida, pero hasta cierto punto. Hasta que han llegado a tus manos han pasado (y pagado) por una serie de asignaturas en las que desgraciadamente (y aún a sabiendas por parte de las «autoridades competetentes») no se les ha enseñado una mierda. Y aún así se permite.
Lo que no tengo claro (tengo 45 años) es si ahora al llegar a la facultad se supone que sabes programar o se supone que te enseñan allí. En mi época, por ejemplo en Filología Inglesa había profesores que asumían que ya se sabía inglés a un buen nivel al entrar y otros que asumían que no se sabía y enseñaban de cero. El tema era que los que sabían inglés se aburrían en las clases de los segundos y los que no sabían se perdían en los de los primeros.
¿Como es ahora en una facultad de informática? Lo pregunto por entender algún comentario que he leído.
Voy a dejar un comentario e intentaré sopesar ambas partes, recordar cuando yo era el estudiante y ahora que soy profesor de asignaturas similares en otra universidad…El problema no es ni de los alumnos ni de los profesores sino de ambos, me explico, en un curso un alumno puede tener una importante carga con las distintas asignaturas, amén de que no «enganchan» muy bien las unas con las otras o incluso se ven planes muy pero que muy mal diseñados, donde ciertas cosas están totalmente al revés….lo que hemos de hacer amigo Ricardo es motivar a los alumnos, dicho así suena fácil, pero esta es la tarea más complicada que tenemos encomendada, un alumno motivado, con ganas de aprender como funciona y como se programa un planificador a corto plazo, es decir, con ganas de aplicar la teoría es un alumno aventajado que seguramente superará la asignatura, en cambio, un alumno al que nadie explica los conceptos de forma clara y concisa pero que tanto el profe de la asignatura A como el profe de la asignatura B se dan «facepalm:» e insisten en publicitar y hacerles ver que se equivocan, eso no conduce a nada y ese alumno está avocado al fracaso (el manos universitariamente hablando, luego en el mundo laboral nos encontramos casos realmente extraños). El reto es, tenemos que explicar todo (el 100%) para que lo entienda todo el mundo y si para ello es necesario ver conceptos de otras asignaturas o conceptos previos, ánimo, tu puedes con todo!
¡Muy bueno el artículo! Gracias 🙂
Yo también soy profesor de informática en la universidad. Seguramente, veo las cosas desde un punto de vista muy distinto a como lo ven mis alumnos por mi «trayectoria vital». Mis primeros programas de ordenador los escribí en el año 1986 con 12 años en un Commodore-64: simplemente copiaba líneas y líneas de código (Basic) de una revista mensual que creo que costaba 500 pesetas (3 euros). No lo he calculado, pero podrían ser fácilmente unos 10 euros de ahora. No creo que hoy en día mucha gente estuviese dispuesta a pagar 10 euros por una revista de unas 40 páginas.
Al principio, no entendía absolutamente nada, pero me maravillaba la posibilidad de que una máquina «muerta» cobrase «vida». Poco a poco fui entendiendo los «goto», «gosub» y «print», aunque los «peek», «poke» y «data» nunca los pude comprender del todo porque nunca tuve la posibilidad de tener un ensamblador: llegué a saber lo que era, pero nunca conseguí un libro ni mucho menos el programa para poder interpretar los números que tenía una instrucción «data». En aquel entonces, para conseguir un programa, tenías que poner un anuncio en el periódico o en una revista de ordenadores para contactar con otras personas de tu ciudad para intercambiar cintas de casete.
Casi 30 años después, gracias a Internet, tienes al alcance de tus dedos prácticamente todo el saber que ha acumulado la humanidad durante miles de años. Y prácticamente a coste 0: necesitas un ordenador, una conexión a Internet y punto. En pocos minutos, de forma legal o ilegal, puedes tener en tu ordenador el libro o el software que quieras.
Yo no espero que mis alumnos lo sepan todo. Esperar eso sería una gilipollez, porque entonces, ¿cuál sería mi papel? Pero sí que espero que sean capaces de aprender de forma autónoma y que recurran a mí cuando se sientan perdidos. Eso es lo que se espera de ellos el día de mañana cuando trabajen, y si no los acostumbramos a ello, acabarán en la lista del paro o desempeñando otros trabajos.
Ser un profesional, de cualquier cosa, es algo más que tener unos conocimientos, un título. Supone también tener una actitud. Y la actitud es mucho más difícil de lograr que los conocimientos.
Los casos narrados son sólo botones de muestras, el mal es general. Y en los campos de la ingeniería más aún, y en el ámbito laboral todavía más. Cuando un ingeniero joven (y no tan joven) hace un proyecto y necesita que un ingeniero senior le dirija, le explique, le supervise, le corrija,… ¿quién está ayudando a quién? ¿Quién es el ayudante y quién es el ayudado? ¿Acaso reflexiona el joven el nivel de la ayuda que está pidiendo?
En mi opinión, el mal se origina desde pequeños, desde el momento en el que el padre más que ayuda a su hijo con cualquier pequeño problema («no encuentro el mando de la tele»), se lo resuelve. Y así se le educa. Cuando llegan a la universidad repiten el mismo comportamiento. Y así siempre. Y también creo que un reflejo de esa tendencia es culpar a los profesores: nos enseñaron mal, o no nos enseñaron. Cuando en la universidad la idea no debería ser ésa, sino más bien un señores, éste es el nivel necesario para saber lo que exige el título, es problema de ustedes aprenderlo. ¿Aceptaríamos que los médicos salieran de las facultades simplemente sabiendo leer, escribir y abrocharse la bata?
Yo creo que lo que habría que hacer es decir que no y exigir que trabaje más. Que lo piense, que lo intente resolver el chaval antes; debería avergonzarse de tener que pedir ayuda, de reconocer que se ha fracasado buscando la solución correcta. Pero claro, esto significaría que los chavales han de tener ganas de esforzarse, ganas de trabajar. Y por ahí sí que no pasamos.
Con todo, de vez en cuando nos encontramos con jóvenes que son increíbles y nos permiten creer que, después de todo, la cosa no está tan negra.
Por cierto, que no haya comentado nunca no significa que no sea un seguidor acérrimo del blog. ¡Gracias, Galli!
Hace varias horas había puesto un comentario a mi amigo y compañero Ricardo en facebook sobre este post, y lo repetiré aquí, vista la polémica:
» Te has desahogado bien!!!, jajaja.
Es verdad que están verdes en depuración de programas (habría que comentarlo con el jefe de estudios para que también se haga inciso en ello en otras asignaturas que impliquen programación). Sin embargo también hablaré en favor de nuestros alumnos, como coprofesora de dicha asignatura :
– La práctica ES COMPLEJA y LARGA (aunque muy interesante!!!). Supone más de 3500 líneas de código (incluídos comentarios y restando las líneas en blanco…. las he contado!!! a realizar en 13 semanas (eso supone unas 270 líneas semanales de código como media, o sea unas 5 páginas). Se programa en lenguaje C, del que tienen poca formación previa, e implica un uso exhaustivo de punteros, funciones de cadenas de carateres, semáforos, cabeceras de programas, recursividad y estructuras de datos diversas, incluídos árboles. Han de aprender además a hacer un makefile y scripts, que les es completamente nuevo.
– La asignatura de estructuras de datos no la han cursado previamente, sino que la hacen en paralelo a la de SOII (y no todos los alumnos tienen porqué haberla escogido)…
– Tienen que distribuir el tiempo entre nuestra práctica (y la teoría correspondiente) y otras 4 asignaturas
No defiendo en absoluto bajar el nivel, o facilitar más la práctica de lo que lo he hecho ya , pero tendremos que ver cómo poner remedio a las carencias para que puedan hacerlo aún mejor.»
—–
Y añadiré algunas cosas más:
– Es cierto que la asignatura de SOII exige mucho esfuerzo y dedicación a los alumnos, pero no sólo la afronta satisfactoriamente el «empollón de turno», más de la mitad de alumnos la superan a la 1ª y entre los matriculados el curso pasado hubo un 27’78% con notable, un 12’8 con excelente y un 4’17% con Matrícula de Honor (y porque por normativa no se podían conceder más MH!!!).
– Sobre la hipótesis que plantea un comentarista «Imagínate que viniera una profesor@ nueva a tu asignatura, con una carrera de informática, y que ya supiera programar (en teoria), pero no tuviera ni idea de la asignatura ni de la práctica»… quiero señalar que fue mi situación REAL hace dos veranos cuando me dijeron que «me había tocado» impartir esta asignatura para el curso 2011-12 (las prácticas de ASO en plan antiguo el primer cuatrimestre, y SOII completa en el 2º Q). Y tengo que decir que Ricardo tuvo muuuucha paciencia conmigo, me aceptó de oyente en sus clases de teoría de ASO durante el 1er cuatrimestre, atendió todas mis consultas y me dio la tranquilidad de poder contar con él en todo momento, incluso telefoneándole durante mis clases si alguna vez me surgió alguna duda que me impidiera avanzar la práctica con los alumnos.Pero al mismo tiempo, el saberle muy exigente y muy puesto en la materia, me hizo ser exigente conmigo misma y aprovechar esa oportunidad para mejorar. Me descargué las diapositivas/apuntes sobre los temas de SO II de más de 10 universidades, fui a la biblioteca a pedir prestados unos 6 libros de SO, hice mis propias diapositivas con lo que había aprendido, me reciclé en C, desmenucé el código de las mejores prácticas entregadas el curso anterior para ver diferentes estilos de programarla, detallé el «paso a paso» de la práctica hasta niveles algorítmicos para facilitar su comprensión a los alumnos, creé una sección de recursos para incluir enlaces a documentación complementaria, preparé ejercicios para que las clases teóricas no fueran tan «abstractas» y los alumnos lo captaran mejor, recopilé preguntas de exámenes con soluciones de otras universidades para que los alumnos pudieran ejercitarse… Para mí fue un curso durísimo, el de mayor esfuerzo y tensión de mis dos décadas en la UIB, pero también el de mayor satisfacción personal para conmigo misma, para con Ricardo (me consta que incluso fue a comentarle mi implicación en la asignatura al director del departamento), y para con los alumnos (prueba de ello es que en las encuestas de ASO me calificaron con un 8’06 e incluso me encontré una plantita en mi casillero con un «GRACIAS» firmado por varios alumnos)
– Sobre el comentario acerca de cierta profesora de BDs, al que otro comentarista ha puesto que seguro que era Heidi… pues aclarar que no soy yo. La 1ª vez que he tenido que utilizar diagramas de entidad-relación en alguna asignatura ha sido este curso, en Ingeniería de Software, y no he impuesto a nadie «MI diagrama», porque ni lo tengo y no admito una «única solución» como válida (me parecería absurdo hacerlo) sino que he mirado al detalle cada una de las ofrecidas por los grupos de prácticas y cada uno ha recibido su corrección personalizada en base a lo que habían hecho. Una cosa muy diferente es empeñarse en que algo se han de hacer como uno dice por el hecho de creerse en posesión del conocimiento absoluto (lo cual no encaja conmigo, pues peco de humildad en ese sentido) y otra es exigir a los alumnos que ciertas actividades se hagan siguiendo determinados requisitos, si el saber adaptarse a ello forma parte de la asignatura en sí misma.
Por lo demás, simplemente señalar que en un foro me parece tan importante cuidar os contenidos como las formas, así que os invito a seguir opinando, pero de forma constructiva y respetuosa.
Saludos,
Adelaida
@Adelaidalaida
Hola colega
Varias cosas:
1. Deje de sobre protegerlos, que son mayorcitos 😉 (y sus jefes no les tratarán igual)
2. Los ejemplos que comento no son de la mayoría, pero sí que hay un problema importante de programación y depuración.
3. Esta práctica bien programada no supera las 2.500 líneas, y ten en cuenta que las funciones más gordas se las pasamos ya acabadas. 2.500 líneas de código en C es muy poco en la «realidad», aunque sí es mucho para prácticas en la universidad, pero eso es un problema. Sólo desarrollando programas más grandes se empieza a aprender de la complejidad.
4. Salvo árboles, que quizás las den en el segundo cuatrimestre, las demás estructuras las vienen tratando y tocando desde primero. Y lo mismo para patrones de programación, como el antiquísimo «lectura secuencial de ficheros», al que sabes que tienen problemas… hasta para eso (a pesar que ellos programaron el read()).
Hay cosas que no se pueden dejar pasar, una de ellas que tengan tantos problemas para enfrentarse a programas relativamente sencillos, y que no puedan resolver problemas de «logica» sencillas por sí solos. Aunque sean muy pocos, no deberían.
Y ya sé que no es problema sólo de los alumnos, lo dejo claro en el apunte: hay problemas compartidos. Y como dices, esto hay que llevar al Consejo de Estudio.
PS: No te molestes por las «formas», es lo habitual en Internet, no creo que cambien 😉
Por desgracia no todos hemos tenido tan claro y tan pronto cual era nuestra vocación, si ese fue tu caso está bien que tomaras la iniciativa y te lanzaras a aprender cosas por tu cuenta, pero si ese no es el caso no implica que haya falta de actitud, todos empezamos de cero en algún momento y por unas razones u otras a veces se empieza un poco más tarde.
Hola, me hacen gracia las excusas del tipo: «cómo voy a conocer los ‘árboles’ si ‘estructuras de datos’ es al final del curso».
Es como si pides que fria un huevo y lo hace sin sacar de la cáscara, con la excusa de que «abrir el huevo es a final de curso y todavía no lo sé».
Lo normal es que vayas un momento a la sección «abrir huevo» y luego volver a «freir huevo». Pero no lo eches entero a la sartén 😀
Saludos
Programar en C no es trivial, y los errores vistos desde fuera siempre parecen bobadas. La pregunta de no sé porque no funciona esto, ha de trasladarse a ver con trazas si el programa está haciendo lo que se supone que debería estar haciendo.
Hacía algunos años que no tocaba el C y me he puesto con Arduino. Tiene un compilador muy interesante. Parece especialmente diseñado para despistar.
Un buen entorno de programación ayuda bastante a la depuración.
Si me lo permites, a un alumno no se le debe decir donde esta un error de código, sino guiarlo hasta que lo encuentre ÉL.
Tú estás de vuelta tanto en programación como en la práctica, sabes lo que falla nada más con la descripción, y es que además los errores son recurrentes en varios alumnos… No puedes pretender que el alumno tenga el mismo nivel de consciencia que tú, ni que sea capaz de seguir una explicación que presupone ese nivel de consciencia.
Lo que yo haría es guiarlo como si no supiera donde está el error, aunque lo esté viendo delante de mis narices. Cuando ya esté muy cercado el error, tras haber mirado documentación y todas las entradas y todo, si no cae de la burra, entonces sí, ya le explicas. De esta manera no solo aprende a buscar el error con un ejemplo, sino que también entiende que no es más cómodo irte a preguntar donde está: porque en el fondo lo va a hacer él igual.
@Adelaidalaida
Estábamos hablando de estudios de hace 20 años. De hecho, no sé si Heidi sigue como profesora en la UIB, aunque supongo que sí. Y no, no eres tú.
En mi opinión, es lo peor que se puede hacer. El profesor universitario no es un profesor particular. No puede dedicar horas y horas a enseñar a los alumnos, de uno en uno, a resolver problemas sencillos. El error está en educar a los chicos en que siempre nos tendrán a nosotros como guías en la vida. No, no, el alumno debe explorar los cien caminos erróneos antes de aprender a identificarlos a la primera o segunda, y debe hacerlo en la etapa de alumno porque en su vida profesional no se podrá permitir ese lujo.
Además, si un alumno se atasca en un momento dado, a quien debe acudir es a sus compañeros, ¿no? Estos si que se han de ayudar unos a otros, hoy por ti y mañana por mí.
Tienes razón, no todo el mundo tiene tan claro «qué hacer en la vida», pero embarcarte a estudiar una carrera como informática, en la que la vocación es muy importante, sin tenerla, es bastante arriesgado y puede tener un desenlace desafortunado. Pero si es así, no hay que culpar la sistema, a la carrera o a los profesores.
A día de hoy, la informática sigue siendo muy artesanal, un arte. Y en el arte, además de los conocimientos técnicos, de ejecución o de los materiales que se emplean, hace falta algo muy importante que creo que no se puede enseñar, la pasión. Por poner un ejemplo tonto, yo podría estar con Cristiano Ronaldo mil horas, me podría contar mil batallitas, pero el fútbol me seguiría sin gustar.
Aquí dejo una lectura que explica bastante bien el tema de la pasión en informática: A Commencement Speech for Graduating 2013 CS Majors (http://programming.oreilly.com/2013/05/a-commencement-speech-for-graduating-2013-cs-majors.html)
Ricardo, algún día podrías escribir sobre la vocación de los estudiantes de informática, es un tema sobre el que se puede hablar mucho. Meterse a estudiar informática, sin haber escrito antes una sola línea de código, me parece inconcebible. Y sin embargo, esa es la historia de muchos alumnos de informática (desgraciadamente, en mi facultad muchos llegan de rebote porque no han sido admitidos en otras carreras y estudian informática por la misma razón que podrían haber acabado estudiando «cultivo de la lechuga»). A partir de ahí, pueden ocurrir dos cosas: pueden ir las cosas bien, y que durante la carrera «se despierte tu pasión» o que por lo menos asumas la situación; pero también puede ser que no ocurra y pases por la carrera «de puntillas», en ese caso, no le eches a los demás la culpa de tu destino.
Después de leer esto, solo puedo decir que las cosas cambian y mucho, y no creo que a mejor. Hace tiempo, hablando con un profe de Matemáticas, me dijo que de año en año el nivel bajaba, que la gente llegaba peor del insti, pero que por otra parte la Universidad no ve con buenos ojos los exámenes duros, las prácticas infernales, los suspensos, y eso acaba «pasándole factura» al profesor. Así que muchos optan por bajar el nivel. Y yo creo que ese no es el camino. Los estudiantes de ingeniería tienen que quemarse las pestañas delante del teclado, pasar noches sin dormir, compilar en el último minuto tras solucionar un bug, sufrir estrés, y salir de todo eso y sentir orgullo por lo que hacen. Y buscarse la vida, que cuando salgan, nadie les regalará nada.
Y quien se sabe buscar la vida, a la larga será el que mejor evolucione en su carrera profesional y personal. He tenido compañeros de trabajo con muchos más títulos y certificaciones que yo, pero sin sentido común ni pensamiento lógico y analítico. Presas del pánico ante un crash de un sistema crítico fuera de los parámetros habituales. ¿Eso es lo que se quiere formar?
Yo empecé hace 20 años, que se dice rápido, en Barcelona, y las asignaturas de sistemas operativos y arquitectura de computadores las recuerdo como algunas de las más divertidas. Y no excesivamente duras.
Respecto de los que dicen que «es que no me han enseñado a usar árboles o …». Existe una cosa llamada biblioteca, y ahora, otra llamada Internet. Además de preguntar al profe, no para que te resuelva la papeleta, sino donde buscar/seguir… Yo recuerdo que en primero, en «Programación metódica», la práctica se hacía en Modula 2 y los profes nos daban una librería de árboles binarios hecha, y nuestra práctica era derivar el código que resolvía el problema, implementarla en Modula 2. La librería fallaba en algunos casos. Era una de esas semanas tontas de puente. Lo que hizo la mayoría fue ir a quejarse de que su código no funcionaba y los profes corrigieron en función de lo hecho. Un amigo y yo nos curramos nuestra propia librería de árboles. La probamos, compilamos y nadie nos dio una palmada en la espalda. Es más, me abroncaron porque no era el objetivo de la práctica a pesar de ser el único de mi clase que podía ejecutar la práctica y me pasé el puente encerrado en las salas de terminales del VAX. Y por ofrecer una solución NO estándar que mejoraba el rendimiento de O(NlogN) a O(N) que el profe no se quiso mirar a fondo. Pero hasta más adelante, cuando profundicé en las estructuras de datos no tuve la base para poder haber defendido mi idea.
A usar un debugger deberían haber aprendido en Estructura de Computadores en primer curso, cuando empezaron con el ensamblador.
Creo que es más un problema de vocaciones, un problema generacional. Antes, muchos de los que llegaban a informática lo hacían desde la línea de comando, desde el BASIC en las CPUs de 8bits, de aquellas clases de TurboPascal, TurboC, MS Cobol de las academias a las que iban al salir del instituto. Hoy vienen de las consolas, de las tablets, de Internet, no de los libros, de los cursos de HTML, Dreamweaver, del drag&drop… De lo visual y gráfico. Y meterse en las tripas de la bestia cuesta si no te buscas la vida.
En mi época también había quien no había tenido nunca un PC en casa, ni había tocado uno antes de llegar a la facultad. Pero salían adelante, se tenían que buscar la vida. Y no había problema en preguntar a los compas, a gente de otros cursos más mayores, a los profes fuera de clase, … Y son grandes profesionales. Que del paso de la EGB con el libro como guión al BUP, tirando de apuntes, rebuscando en la biblioteca,… también fue un cambio. Hay que asumirlos, ir cada vez a más.
Por ello veo genial lo que hacen desde el Citilab de Cornellà (relacionado http://goo.gl/fx1tn ), introducir la programación desde antes de la uni, pero no para que sepan tal o cual lenguaje, sino para que sepan estructurar su mente para resolver problemas. Por ello el bajón de nivel de matemáticas en la ESO y BAC respecto a años anteriores (lo veo con las hijas de mis primos) no ayuda.
Siempre me salen unos ladrillos de comentarios. El próximo será breve, lo juro. 😉
Muy de acuerdo con Sergio en su último comentario. Actitud, pasión por lo que se hace, curiosidad, ganas de aprender.
Meterse en una ingeniería cualquiera sin vocación o acaba mal, o si termina, acaba formando malos profesionales, trabajadores «de manual».
«Stay Hungry, Stay Foolish»
Steve Jobs
Te voy a contar un secreto, pero que quede entre tú, yo e Internet.
Lo de bajar el nivel, es un hecho que yo percibo en mi alrededor y, desgraciadamente, soy partícipe de ello. ¿Cómo se llega a esa situación? No lo sé, a veces pienso que es como cuando uno engorda: empiezas a comer un poco más, dejas de hacer ejercicio, pasas más tiempo tumbado en el sofá, etc. De un día para otro no te das cuenta, incluso de un año para otro, pero pasados cinco años te miras en el espejo y dices «¡ostras, qué gordo que estoy, pero si hace cinco años no tenía tripa!». ¿Por qué has engordado? ¿Tenías la intención de engordar?
¿Existe una «directiva» para suspender o aprobar a más gente? La financiación de las universidades públicas depende en gran medida del número de alumnos: cuantos más alumnos tenga una universidad pública, más dinero recibe. Por tanto, desde un punto de vista económico, no convienen las «escabechinas» y que la gente huya, especialmente en los primeros cursos. Pero por otro lado, conviene que la gente repita, porque cada vez la matrícula es más cara. En definitiva, el tema es complejo y yo nunca he tenido constancia de presiones para suspender o aprobar a más o menos gente. Pero esto va a cambiar, a peor.
Por lo menos en la Comunidad Valenciana, los alumnos repetidores no se cuentan para la carga docente, como si no existieran: por ejemplo, si un turno de prácticas son 35 alumnos, y en una asignatura tienes 35 alumnos nuevos y 35 alumnos repetidores, oficialmente sólo vas a tener un turno de prácticas en esa asignatura. ¿Y qué hacemos con los repetidores? Magia. Pero además, y con los nuevos criterios de calidad que se están implantando, si suspendes a muchos alumnos significa que eres un profesor malo: no malo de maquiavélico, sino malo de inútil. A partir de aquí, que cada uno saque sus conclusiones…
Sergio, mientras estudiaba, por una de esas jugadas del destino, bien pronto fui becario de sistemas, y luego por una baja muy larga PAS de la propia universidad, y estuve también viendo las cosas desde dentro.
Sé que la financiación es un gran escollo, que el «sistema» impone criterios que … Y sé que vosotros los tenéis que sufrir. Y mucho.
Y parece que fuera la cosa a ciertos niveles no se diferencia mucho. Creo que los mismos que tienen la «imaginación» para reformar los planes de estudio y dotarlos, son los mismos que fomentan «la sociedad del conocimiento» y los mismos que me provocan dolor de estómago cuando tengo que lidiar con cosas increíblemente absurdas en la Informática de algunas de las grandes empresas del IBEX35. Esas que deberían tener a los mejores profesionales y las mejores prácticas. Y no proyectos «bicicleta».
Al final, el sector más serio en el que he trabajado es el de la automoción. Todo se calcula, todo se mejora, tiene sus pifias como en todas partes pero la organización se toma en serio que todo funcione, siempre, y te escuchan. Valoran lo que cuesta estar parados.
En otros lados han llegado a lograr que una impresora sea un punto de fallo crítico en una delegación bloqueando el trabajo de la gente (y donde también cuesta mucho dinero).
Reblogueó esto en Cuadrando ideasy comentado:
Algunas verdades que Galli establece sobre fundamentos y estructuras educacionales de los estudiantes de informática.
Fuera de la programación, en análisis de conducta y más concretamente en aprendizaje, cuando un sujeto, en este caso animal, hace algo «incorrecto» consideramos más bien que el animal hace lo que tiene que hacer en cada momento y los equivocados somos nosotros que no hemos programado las pautas de aprendizaje de una manera adaptada al sujeto.
Decir que el estudiante es esto o lo otro, impide mirar más allá de las fáciles acusaciones ad-hominem y no examinar a qué son debidos fenómenos como los que se indican en el artículo.
Una enseñanza deficiente, falta de estrategias adecuadas que motiven al alumno, sistemas anquilosados y burocratizados, etc, etc, hacen que obtengamos los resultados que vemos.
De una cosa se llega a otra y en este caso, a la frustración de un profesor al que le llega el producto de todo lo anterior.
Obviamente, «quod natura non dat, Salmantica non praestat» pero debería ser interesante ver qué «producto» le llegaría a Gallir si los programas curriculares y la metodología y la evaluación del desempeño fueran otras.
Se puede argüir que el alumno tiene parte de culpa porque no se involucra o no le interesa, pero esto es volver a lo anterior: Es el pez que se muerde la cola y en verdad una pseudoexplicación.
Somos producto de nuestra historia, y lo que vemos es el resultado de ella, y en este caso se la come con patatas un profesor involucrado. De otro modo no escribiría un artículo así.
Yo creo que parte del problema es la excesiva fragmentación tanto de asignaturas, como de exámenes y trabajos. En asignaturas anuales las prácticas eran grandes. Ahora, en asignaturas cuatrimestrales y, en muchos casos, con varias prácticas, éstas han de ser pequeñas (básicamente ejercicios programados) y, a veces, un mero llenar huecos de algo casi solucionado.
Además, como la práctica de la semana 3 solamente puede usar los conocimientos de las semanas 1 y 2, es imposible requerir cosas que requieran haber madurado los conocimientos.
En los exámenes igual: en mi época entraba todo el temario del año (y temarios bastante más densos que los actuales) y un examen podía durar 4 ó 5 horas. Era imprescindible haber abstraído y madurado el conocimiento. Ahora, en el parcial, entra lo de las últimas 6 ó 7 semanas, y en pruebas que a veces no llegan a las dos horas. Por tanto, se aplica el «lleno la cache; vacío la cache».
Los alumnos se adaptan al sistema y éste, en general, les permite seguir adelante con muchas carencias en su formación.
La culpa es tuya por contestar. Yo también he dado clases en informática y he vivido exactamente todo lo que describes. También me ponía las manos a la cabeza e increpava al personal. Al final, la conclusión es obvia. Es más fácil preguntar que pensar. Además hay gente que le suda la polla que les digas de todo, sólo quieren la respuesta y puerta. La mayoría de alumnos no son tontos, son vagos. Si no te tienen a ti se espabilan. Pero si estas tu por ahí, preguntan, acaban antes y encima se rien si le sueltas alguna a alguien. Así de simple.
Por cierto.. leyendo todo esto he recordado mis tiempos como estudiante de SO y me ha dado el mismo asco que me daba por aquel entonces xD. Yo en el fondo entiendo el poco interés… pero esto ya es cuestión de gustos. 🙂
Me pasa a menudo con desarrolladores con poca experiencia. Solución: explicar cómo se trabaja.
Hago lo mismo que tú: Ante un «oye, esto da error»
respuesta: «Qué error da?» «Dónde»
persona: «No lo sé»
yo: «Has mirado el log?»
persona: «Eeee no.»
yo: «Vale, te voy a explicar cómo tienes que actuar cuando tienes errores en el progama. 1) leer el log. 2: buscar el punto de error. 3: ir al código y entender por qué sale ese mensaje de error».
Ya mayoría tardan poco más de una semana en aprender a detectar y corregir la mayoría de errores.
El conocimiento está ahí, pero no lo saben 🙂
PS: Por cierto, yo no nací sabiendo. También me pasó la frustración de ver que da error y desesperarse por no saber ni el motivo ni cómo arreglarlo. En programas concurrentes era una locura, a veces necesitaba más de una hora leyendo prints y haciendo recorridos a boli en listados impresos de código anotando el valor de las variables a cada paso. Qué recuerdos! 🙂
PS2: Algunos no tienen remedio y les toca finiquito
Idò el pla Bolonya no ha fet més que agreujar això. Les petites entregues que s’exigeixen per fer un seguiment continuat són responsables de què la gran majoria d’alumnes sàpiguen implementar bé algoritmes però no tenguin ni idea de com fer un programa mitjanament gran, i, el que és pitjor, de documentar-lo tant a nivell de comentaris al codi com a un informe final.
D’això en són veterans aquí, a la FIB. Vénen aplicant aquest mètode des de molt abans de la UIB (són veterans de l’EU2015) i els laboratoris funcionen de manera extremadament guiada i a base de pràctiques petites independents. Això no afavoreix a comprendre el concepte més global de la programació, ni s’aprèn a documentar ni a fer servir tècniques de l’estil que descrius, pròpies de projectes grans. Per altra banda, crec que no motiva gaire a l’alumne (al menys a mi no).
Un ex-alumne teu, que també va passar pel sistema de fitxers 😉
No se el caso de tu universidad pero al menos en la mía Politécnica de Madrid pasa lo siguiente:
Nuestro primer contacto con C (si no lo sabias de antes) es Programación para Sistemas, asignatura de 3 ECTS con 2h de docencia a la semana. Básicamente las clases que dan son para explicar 4 comandos unix básicos (cp, mv, ls, …) y como mucho la estructura de C. Hay que entregar 4 prácticas en C y nadie explica ni como se usa un puntero (al menos explican que es).
Nadie explica como funciona la memoria ya que aún no has llegado a asignaturas donde se de, nadie explica que es un stack overflow, nadie explica que es un segfault, nadie explica que es un bus error, nada…
Y por supuesto ni una mención a GDB, no sea que se les caigan las manos o se queden afónicos…
Básicamente pagas 3 ECTS para hacer honor a su acrónimo inventando por los alumnos (Estudia Cabrón Tu Solo), no se… para eso no me matriculo pero es obligatoria…
Al semestre siguiente empiezas a cursar asignaturas que «parchean» los huecos de conocimiento y también Sistemas Operativos donde se hacen más practicas en C y se explican cosas muy interesantes… pero los alumnos ya llegan con unos conocimientos «lisiados». Son prácticas mas complejas y les cuesta mucho mas aún…
He visto muchos compañeros suspender por las prácticas, pero no tienen la culpa esos profesores que además son buenos… ellos simplemente saben que has cursado una asignatura en la que te enseñan C y continúan desde ahí…
Y en esas practicas si necesitas GDB… vas a tutorías con errores en las practicas y los profesores se quedan pálidos cuando ven que los métodos de debug de los alumnos son printf antes y después de cada sentencia… 33% código 66% printf de debug…
Encima Programación para Sistemas es una asignatura impartida por otro departamento diferente a la de Sistemas Operativos y a parte de coordinación nula ni los profesores intentan poner soluciones comunes por peleas de departamento. Además los profesores que imparten Programación para Sistemas no están capacitados para ello, no es su especialidad ni se corresponde con lo que hacen en otras asignaturas…
No se exactamente en tu universidad que PRE tienen a tu asignatura pero en la mía ese PRE da pena.
Mi profesor de Sistemas Operativos también nos ponía algunas de las prácticas más difíciles de la carrera (del tipo a la que explicas, o modificar la gestión de colas en el SO MINIX, etc) y cuando surgían preguntas como estas, sencillamente pasaba bastante de nosotros. Y yo se lo agradeceré eternamente, porque al principio se hacía odiar un poco, pero a la larga entendías que hay que prestar mucha atención al programar y por supuesto a hacer los famosos print efes cuando tocaba encontrar un error. Eso sí, si veía que llevabas un rato buscando con cabeza el error, no dudaba en echarte una mano.
Este profesor ha sido uno de los mejores que he tenido. Mostraba gran pasión por lo que enseñaba, sabía llevar perfectamente a la clase y al mismo tiempo ha sido de los que más me han exigido. Ojalá todos hubieran sido así…
Yo creo que la culpa es de la LOGSE, y a alguno lo suspendería por escribir «quatrimestre». Todavía me acuerdo de uno de los primeros programadores que tuvimos en Visual, que cuando fallaban los programas siempre decía que era por culpa de los «eventos».
«el lenguaje C es muy sencillo»
Esto…¿no podria ser que solo le parezca sencillo el que ha estado años y años viendo segmention faults?
Tiene punteros, manejo de la memoria manual y demas caracteristicas de un lenguaje de bajo nivel pensado para exprimir a la maquina y no tanto para facilitar su escritura y lectura. Ademas no tiene manejo de excepciones con stacktraces que ayudan bastante a depurar sin tener que llenar todo de printfs.
Con esto no quiero decir que la culpa sea del lenguaje, los so’s *hay* que implementarlos casi obligatoriamente en un lenguaje de bajo nivel y depurar contra viento y marea es una habilidad imprescindible para un programador.
Sin embargo y dejando de lado argumentos en plan «las nuevas generaciones mimadas no tienen iniciativa» (implicitamente se piensa que la de uno si) esta claro que es en esta asignatura donde estan aprendiendo esa habilidad y su profesor el primero que se la esta enseñando. Si no debia ser esa asignatura y ese profesor es culpa de la universidad y no de los alumnos, sobre todo si se detecta que es una carencia generalizada.
yo creo que no es un problema de falta de dominio del debugging, sino de interés por programar
Estoy de acuerdo con Juanky. ¿Para qué vas a formarte si no eres más que un trozo de carne bautizado?
Una de las primeras cosas que debe aprender cualquier profesional que se enfrenta cada día a una máquina es que uno tiene que ser al menos tan tenaz como una máquina, y al final prevalecer. Eso lo sabe cualquiera que haya visto la saga Terminator.
Y si no tienes esa actitud, entonces ya te puedes ir haciendo a la idea de que los que van a hacer desarrollos son los chicos de Bangalore, y tú vete haciendo un módulo de FP de camarero.