Riesgos de las escuelas Java

From The Joel on Software Translation Project

Jump to: navigation, search

Por Joel Spolsky
Jueves 29 de diciembre del 2006
Artículo original: The Perils of JavaSchools
Traducido originalmente por: Laurens Rodriguez



Qué perezosos son los chicos.

¿Qué pasó con el trabajo duro?

Un seguro indicio de mi descenso a la senilidad son mis continuas quejas y lamentos acerca de los "chicos de ahora", y cómo ya no quieren o no pueden hacer cosas difíciles.

"Ustedes si que tuvieron suerte. Nosotros vivimos por tres meses en una canasta de papel marrón dentro de un tanque séptico. Teníamos que levantarnos a las seis de la mañana, limpiar la canasta, comer la corteza de un rancio pan, e ir a trabajar abajo del molino, catorce horas al dia, todos los dias de la semana, y cuando llegabamos a la casa nuestro padre nos golpeaba para ir a dormir con su cinturón."
Monty Python's Flying Circus, Four Yorkshiremen

Cuando yo era un muchacho, aprendí a programar con tarjetas perforadas. En esos tiempos si cometías un error, no tenias ninguna de nuestras modernas comodidades como la tecla retroceder para corregirlo. Tenias que tirar la tarjeta y empezar todo de nuevo. Cuando empecé a entrevistar programadores en 1991, les dejaba usar generalmente cualquier lenguaje que quisieran para resolver los problemas de programación que les planteaba. 99% de las veces, ellos escogían C.

Ahora ellos tienden a escoger Java.

Pero no me malinterpreten: no hay nada malo con Java como lenguaje de implementación.

Esperen un momento, quiero rectificar eso último. No digo, en este artículo en particular, que haya algo de malo con Java como lenguaje de implementación. Hay un montón de cosas mal con Java, pero tendrán que esperar a un artículo diferente. En vez de ello lo que me gustaría decir es que Java no es, generalmente, un lenguaje de programación lo suficientemente difícil que pueda ser usado para distinguir entre excelentes programadores y programadores mediocres. Puede ser un buen lenguaje para trabajar, pero ese no es el tema de hoy. Puedo ir incluso mas allá y decir que el hecho de que Java no sea lo suficientemente difícil es parte de su diseño, no es un bug en si, pero que tiene ese gran problema.

Si pudiera ser tan atrevido, diría que en mi humilde experiencia han sido dos las cosas tradicionalmente enseñadas en las universidades como parte de la carrera de Ciencias de la Computación (CS) las que mucha gente nunca llega realmente a comprender: punteros y recursión.

En esos tiempos lo normal era empezar la universidad con un curso en estructuras de datos, con listas enlazadas, tablas hash y por qué no, con un uso abundante de punteros. Esos cursos eran frecuentemente usados como cursos de poda: eran tan difíciles que cualquiera que no pudiera soportar el desafío mental de un grado en CS se daba por vencido, lo que era bueno, porque si piensas que los punteros son difíciles, espera hasta probar las cosas de la teoría del punto fijo.

Todos eso chicos que la hicieron grande en el colegio escribiendo sus juegos PONG en BASIC para su Apple II, iban a la universidad, tomaban CompSci 101, un curso en estructuras de datos, y cuando se estrellaban con el negocio de los punteros sus cerebros simplemente estallaban, y lo siguiente que sabias es que se estaban especializando en Ciencias Políticas porque la escuela de leyes parecía ser una mejor idea. He visto todos los tipos de cifras de deserción en CS y ellas estaban entre 40% y 70%. Las universidades tienden a ver esto como un derroche; yo creo que es solo la necesaria poda de gente que no va a ser feliz o exitosa en una carrera de programación.

El otro curso difícil para muchos jóvenes estudiantes de CS era el curso donde aprendías programación funcional, incluyendo programación recursiva. MIT puso la barra muy en alto para esos cursos, creando un curso requerido (6.001) y un texto de consulta (Abelson & Sussman's Structure and Interpretation of Computer Programs), los cuales eran usados en docenas o quizás cientos de escuelas de CS de prestigio como el estándar de facto para la introducción a la ciencia de la computación. (Puedes, y deberías echarle una ojeada a la antigua versión online.)

La dificultad de esos cursos es asombrosa. En la primera clase has aprendido casi todo Scheme, y ya has sido introducido a la función de punto fijo que toma otra función como entrada. Cuando me esforzaba en pasar ese curso, CSE121 en Penn, observaba como muchos sino la mayoría de estudiantes simplemente no lo lograban. La materia era muy difícil. Inclusive yo escribí un largo email de lloriqueo a mi profesor diciendo que “simplemente no era justo”. Alguien en Penn debe haberme escuchado (o a alguno de los otros llorones), porque ese curso es ahora enseñado en Java.

Cómo quisiera que no hubiesen escuchado.

¿Piensas que tienes lo que se necesita? ¡Pruebate aqui!

Aquí radica el quid del asunto. Años de lloriqueo de estudiantes perezosos, combinados con quejas de la industria acerca de cuan pocos graduados en CS salen de las universidades americanas, han pagado su precio, y en la ultima década un gran numero de otrora perfectamente buenas universidades se han vuelto 100% Java. Esta de moda, a los reclutadores que usan “grep" (buscador de texto en múltiples archivos) parece gustarles, y, lo mejor de todo, no hay nada lo suficientemente difícil en Java como para podar aquellos programadores sin la parte del cerebro que entiende punteros y recursión, así que las deserciones son menores, y los departamentos de ciencias de la computación tienen mas alumnos, y mayores presupuestos y todo esta bien.

Los chicos con suerte de esas Java-escuelas nunca van a toparse con raros fallos de segmentación tratando de implementar sus tablas hash basadas en punteros. Nunca se van a volver locos tratando de empacar cosas en bits. Nunca tendrán que ocupar sus cabezas en como en un lenguaje puramente funcional, el valor de una variable nunca cambia, y aun así, ¡cambia todo el tiempo! ¡Una paradoja!

¿Soy solo uno de esos viejos cascarrabias anticuados, vanagloriándose acerca de cuan duro era sobrevivir toda esa difícil materia?

Rayos, en 1900, el Latín y el Griego eran temas requeridos en la universidad, no porque sirvieran de algún propósito, sino porque de alguna manera eran considerados un requisito obvio de la gente educada. De cierta manera mi argumento no es diferente del argumento echo por la gente pro-Latín: “[El Latín] entrena tu mente. Entrena tu memoria. Desembrollar una sentencia en Latín es un excelente ejercicio del pensamiento, un verdadero acertijo intelectual, y una buena introducción al pensamiento lógico”, escribe Scout Barrer. Aun así no puedo encontrar una sola universidad que requiera Latín nunca más. ¿Son los punteros y la recursión el Latín y el Griego de las ciencias de la computación?

Ahora, fácilmente admito que programar con punteros no es necesario en el 90% del código escrito en la actualidad, y de hecho es totalmente peligroso en el código de producción. OK. Está bien. Y que la programación funcional simplemente no es muy empleada en la práctica. De acuerdo.

Pero es aun importante para alguno de los más excitantes trabajos en programación. Sin punteros, por ejemplo, nunca serias capaz de trabajar en el Kernel de Linux. No puedes entender una simple línea del código de Linux, o de hecho, de cualquier sistema operativo, sin verdaderamente entender punteros.

Sin entender programación funcional, no podrás inventar MapReduce, el algoritmo que hace Google tan masivamente escalable. Los términos Map y Reduce vienen de Lisp y programación funcional. MapReduce es, en retrospectiva, obvio para cualquiera quien recuerde de su clase equivalente a 6.001 que los programas puramente funcionales no tienen efectos colaterales y por ende son trivialmente paralelizables. El simple hecho que Google inventara MapReduce, y no Microsoft, dice algo del porque Microsoft esta aun jugando a lograr que características básicas de búsqueda funcionen, mientras Google se ha movido ya al siguiente problema: construir Skynet la más grande supercomputadora masivamente paralela del mundo. Simplemente no creo que Microsoft entienda completamente cuan retrasados están en ese campo.

Pero mas allá de la importancia a simple vista de los punteros y la recursión, su valor real radica en que construir grandes sistemas requiere del tipo de flexibilidad mental que adquieres aprendiéndolos, y de la actitud mental que necesitas para no huir de los cursos en donde son enseñados. Punteros y recursión requieren cierta habilidad para razonar, para pensar en abstracciones, y más importante, para ver un problema en diversos niveles de abstracción simultáneamente. Y entonces, la habilidad para entender punteros y recursión esta directamente correlacionada con la habilidad de ser un excelente programador.

No hay nada en grado académico 100% Java que descarte realmente a los estudiantes que carecen de la agilidad mental para tratar con esos conceptos. Como empleador, he visto que el 100% de esas Java-escuelas han empezado a producir en serie una buena cantidad de graduados quienes simplemente no son lo suficientemente listos para trabajar como programadores en nada mas sofisticado que una simple aplicación contable Java, aunque se las han arreglado para colarse a través de la ahora simplificada materia.

Esos estudiantes nunca sobrevivirían al 6.001 del MIT o al CS 323 en Yale, y francamente, esa es una razón por la cual, como un empleador, un titulo en CS del MIT o Yale tiene mas peso que uno del Duke, quien recientemente se hizo full-Java, o de Penn, donde remplazaron Scheme y ML con Java tratando de enseñar la clase que casi asesina a mis compañeros y a mi, CSE121. No es que no quiera contratar chicos listos de Duke o Penn, lo hago, es solo que es mucho más difícil para mí saber quienes son. Yo estaba acostumbrado a decir que los chicos listos eran aquellos que podían desmenuzar un algoritmo recursivo en segundos, o implementar funciones de manipulación de listas enlazadas usando punteros tan rápido como podían escribir en la pizarra. Pero con un graduado full-Java, yo no se si ellos padecen con esos problemas debido a que han sido mal educados o si padecen porque ellos realmente no tienen esa parte del cerebro que van a necesitar para ser buenos programadores en el trabajo. Paul Graham los llama Blub Programmers.

Ya es bastante malo que las Java-escuelas fallen en podar los chicos que nunca van a ser buenos programadores, algo que las universidades podrían justificablemente decir que no es su problema. Después de todo es la industria, o al menos, los reclutadores-que-usan-grep, los que están pidiendo a gritos que Java sea enseñado.

Pero las Java-escuelas fallan también en entrenar las mente de los chicos a ser expertas, ágiles y lo bastante flexibles para hacer buen diseño de software (y no me refiero al “diseño” OO, donde gastas incontables horas acomodando tu jerarquía de objetos, o preocupándote en problemas superfluos como “tiene-un” vs. “es-un”). Necesitas entrenamiento para pensar en las cosas con múltiples niveles de abstracción simultáneamente, y ese tipo de pensamiento es exactamente lo que necesitas para diseñar excelentes arquitecturas de software.

Puedes estar preguntándote si la enseñanza de programación orientada a objetos (OOP) es un buen sustituto de poda a los punteros y recursión. La respuesta rápida: no. Sin debatir acerca de los meritos del OOP, simplemente no es lo suficientemente difícil para podar a los programadores mediocres. OOP en las universidades consiste básicamente en memorizar un puñado de términos de vocabulario como “encapsulacion” y “herencia” y tomar exámenes con alternativas acerca de las diferencias entre polimorfismo y sobrecarga. No más difícil que memorizar fechas históricas y nombres en una clase de historia, OOP tiene desafíos mentales inadecuados para espantar a los estudiantes de primer año. Cuando tú te enfrentas con un problema OOP, tu programa aun funciona, es solo que es un poco más difícil de mantener. Supuestamente. Pero cuando te enfrentas a un problema con punteros, tu programa produce la línea Fallo de segmentación y se cuelga, no tienes ni la menor idea de lo que está sucediendo, hasta que te paras y tomas una fuerte bocanada de aire y tratas de forzar tu mente a trabajar en dos diferentes niveles de abstracción simultáneamente.

Los reclutadores-que-usan-grep, de hecho, son ridiculizados aquí, y por un buen motivo. Nunca he conocido alguien que pueda hacer Scheme, Haskell y punteros en C quien no pueda entender Java en dos días, y crear mejor código en Java que gente con cinco años de experiencia en Java, pero trata de explicar eso al zombi de Recursos Humanos.

¿Pero que acerca de la misión CS de las facultades de CS? ¡Ellas no son escuelas vocacionales! No debería ser su trabajo entrenar gente para trabajar en la industria. Eso esta para las universidades comunales y programas de recapacitación del gobierno para trabajadores desplazados, te dirán ellas. Ellas se suponen que están para dar a los estudiantes las herramientas fundamentales para vivir sus vidas, no para prepararlos para sus primeras semanas de trabajo. ¿Cierto?

Cs1.png

Aun así, CS son demostraciones (recursión), algoritmos (recursión), lenguajes (calculo lambda), sistemas operativos (punteros), compiladores (calculo lambda), y entonces la conclusión es que las Java-escuelas que no enseñan C y no enseñan Scheme no están enseñando realmente ciencias de la computación, tampoco. Tan inútil como el concepto de function currying puede serle al mundo real, es un obvio prerrequisito para un graduado en CS. No puedo entender porque los profesores en los comités de curricula de las facultades CS han permitido sus programas ser embrutecidos a tal punto donde no solo no pueden ellos producir programadores que trabajen, sino que ni siquiera puedan producir graduados en CS que puedan obtener PhDs y puedan competir por sus puestos de trabajo. Oh esperen. No importa. Quizás entienda.

Si regresamos atrás y analizamos las discusiones que tomaron lugar en el mundo académico durante el “Gran Levantamiento Java”, encontraremos que la mayor preocupación fue que Java no era lo suficientemente simple para ser usado como un lenguaje de enseñanza.

Mi Dios, pensé, ¡ellos están tratando de embrutecer la curricula aun mas! ¿Por que mejor no les llevamos la comida a la boca a los estudiantes? Dejemos que los asistentes dean los exámenes por ellos también, entonces nadie se cambiara a Estudios Americanos. ¿Cómo se supone que alguien aprenderá algo si la curricula ha sido cuidadosamente diseñada para hacerse más fácil de lo que ya es? Parece haber una comisión de trabajo (PDF) intentando idear un simple subconjunto de Java que pueda ser enseñado a estudiantes, produciendo documentación simplificada que esconde cuidadosamente toda esa basura EJB/J2EE de sus tiernas mentes, de tal manera que no tengan que preocupar sus cabecitas con otras clases que no necesiten para resolver sus aun mas fáciles problemas CS.

La interpretación mas compasiva de porque las facultades CS son tan entusiastas en embrutecer sus clases es porque ello les dará mas tiempo para enseñar verdaderos conceptos CS, así ellos no necesitaran dos sesiones para esclarecer a los alumnos las diferencias entre digamos un Java int y un Integer. Bueno pero si ese fuera el caso, 6.001 tiene la respuesta perfecta: Scheme, un lenguaje de enseñanza tan simple que el lenguaje entero puede ser enseñado a estudiantes brillantes en cerca de 10 minutos; entonces puedes gastar el resto del semestre en puntos fijos.

Fiu…

Voy a regresar a los unos y ceros.

(¿Tu tenias unos? ¡Maldito suertudo! todo lo que teníamos nosotros eran ceros)


The Joel on Software Translation Project - Español

Personal tools