Bienvenido(a) a Grupo Linuxero del Bajío jueves, octubre 06 2022 @ 01:07 CEST

Los Peligros de la Universidades Java-eras

  • domingo, enero 01 2006 @ 07:24 CET
  • Autor:
  • Lecturas 4,818
Artículos Lo admito, soy fan de los escritos de Joel Spoisky. Y dada la impresión que me causó su último artículo y las pocas cosas que hacer, me puse a traducirlo. Helo aquí, espero que lo disfruten.

Por Joel Spoisky
Traducido por Víctor Manuel Jáquez Leal

Muchachos flojos.

¿Qué ha pasado con el trabajo duro?

Un signo inequívoco de mi descenso a la senilidad son las quejas y lamentos sobre los "chicos de estos días", y de cómo no quieren o no pueden hacer ya cualquier cosa complicada.

Cuando yo era un muchacho, aprendí a programar en tarjetas perforadas. Si cometías algún error, no tenías ninguna modernidad como la tecla de retroceso para corregirlo. Tirabas la tarjeta y comenzabas de nuevo.

Cuando comencé a entrevistar programadores en 1991, permitía generalmente que usaran el lenguaje que eligieran para resolver los problemas de programación que les daba. El 99% del tiempo escogían C.

Hoy en día, tienden a elegir Java.

Ahora, no me mal interpreten: no hay nada malo con Java como un lenguaje de implementación.

Esperen un minuto, quiero modificar el enunciado. No estoy afirmando, en este artículo en particular, que halla algo mal en Java como un lenguaje de implementación. Tiene muchas cosas malas el lenguaje, pero tendrán que esperar otro artículo.

En lugar de esto, me gustaría afirmar que Java no es, generalmente, un lenguaje de programación los suficientemente difícil como para utilizarse para discriminar a los excelentes programadores de los mediocres. Puede ser un buen lenguaje para trabajar, pero no es el tema de hoy. Me gustaría ir más lejos y decir que el hecho de que Java no es lo suficientemente difícil, es una característica del lenguaje, no un gazapo (bug), pero tiene este problema.

Si puedo ser temerario, en mi humilde experiencia hay dos temas tradicionalmente enseñados en las universidades que son parte de una retícula de ciencias computacionales que mucha gente simplemente nunca llegan a comprender plenamente: punteros y recursividad.

Solían iniciar la universidad con un curso de estructuras de datos, de listas enlazadas y tablas de dispersión y bolsas, con un extenso uso de punteros. Esos cursos seguido eran usados como guadaña: eran tan difíciles que cualquiera que no pudiera con el reto de mental de un grado en CC se daría por vencido, lo que era bueno, porque si creías que los punteros eran complicados, espera hasta que trataras de probar cosas como la teoría del punto fijo.

Todos los chicos que se daban a notar en la preparatoria al escribir juegos de ping-pong en BASIC con sus computadoras Apple II, deberán entrar a la universidad, tomar el curso de CompSci 101, un curso de estructuras de datos, y cuando lleguen a los punteros, sus cerebros explotarán totalmente, y lo siguiente que sepas de ellos, es que están inscritos en Ciencias Políticas porque la escuela de leyes les pareció una mejor idea. He visto todo tipo de cifras en las tasas de deserción en CC y están normalmente entre el 40% y el 70%. Las universidades tienden a ver esto como un desperdicio; yo creo que es sólo la extracción necesaria de gente que no será feliz o exitosa en sus carreras como programadores.

El otro curso difícil para muchos jóvenes estudiantes de CC era el curso donde aprendías programación funcional, incluyendo programación recursiva. El MIT fijó la barra muy alta para estos cursos, creando un curso obligatorio (6.001) y un libro de texto (Structure and Interpretation of Computer Programs de Abelson & Sussman), el cual es usado por docenas o aún cientos de universidades con carreras de CC de alto nivel como la introducción de facto a las ciencias computacionales. (Puedes, y deberías, ver una versión vieja de las exposiciones en línea).

La dificultad de estos cursos es sorprendente. En la primer exposición tienes que haber aprendido mucho de Scheme, y deberías ya estar metido en una función de punto fijo que tome otra función como entrada. Cuando me esforzaba a lo largo de un curso semejante, CSE121 en Penn, observaba como muchos, si no es que la mayoría, de los estudiantes simplemente no podían con ella. El material es muy complicado. Escribí un largo y sollozante correo electrónico al profesor diciéndole No Es Justo. Alguien en Penn debió escucharme (o a algún otro quejoso), porque ese curso ahora se enseña con Java.

Deseo que no me hubieran escuchado.

En esto descansa el debate. Años de gimoteos por parte de estudiantes de CC flojos como yo, combinado con quejas de la industria sobre los pocos graduados en programas de CC de las universidades norteamericanas, han cobrado su derecho, y en la última década un largo número de otroras excelentes escuelas se ha convertido en 100% Java. Es una celada, los reclutadores que usan "grep" para evaluar currículos parece gustarles, y, lo mejor de todo, es que como no hay nada los suficiente duro en Java para realmente podar a los programadores sin la parte del cerebro que entiende a los punteros o la recursividad, entonces las tazas de deserción son menores, y los departamentos de ciencias computacionales tienen más estudiantes, y mayores presupuestos, y todo está perfecto.

Los chicos afortunados de las escuelas Java-eras nunca van a tener extraños fallos de segmento (segfaults) tratando de implementar tablas de dispersión basadas en punteros. Ellos nunca tendrán que delirar severamente tratando de empaquetar cosas en bits. Nunca tendrán que meter su cabeza en cómo, con programación puramente funcional, el valor de una variable nunca cambia, y sin embargo, ésta cambia todo el tiempo. ¡Una paradoja!

Ellos no necesitan es parte del cerebro para obtener un 4.0 en el grado académico.

¿Acaso solamente soy uno de esos cicateros fuera de moda, como los cuatro hombres Yorkshire, jactándome acerca de lo duro que fui para sobrevivir a toda esas dificultades?

Demonios, en 1900, el Latín y el Griego eran materias obligatorias en la universidad, no porque ellas sirvieran a algún propósito, sino porque eran consideradas requisitos obvios para una persona educada. En un sentido mi argumento no es diferente al argumento hecho por la gente que aboga por el Latín (los cuatro). "[El Latín] entrena tu mente. Entrena tu memoria. Hilvanar una oración en Latín es un excelente ejercicio para el pensamiento, un verdadero rompecabezas intelectual, y una buena introducción al pensamiento lógico," escribe Scott Barker. Pero no puedo hallar una sola universidad que obligue el Latín actualmente. ¿Serán los punteros y la recursividad el Latín y el Griego de las Ciencias Computacionales?

Ahora, libremente admito que programar con punteros no es necesario en un 90% del código escrito hoy en día, y de hecho, es categóricamente peligroso en código de producción. Va. Está bien. Y la programación funcional no es muy usada en la práctica. De acuerdo.

Pero sigue siendo importante para algunos de los trabajos de programación más excitantes. Sin los punteros, por ejemplo, nunca serían capaces de trabajar en el kernel de Linux. No podrían entender una linea de código en Linux, o, de hecho, cualquier sistema operativo, sin una verdadera comprensión de los punteros.

Sin entender la programación funcional, no podrían inventar el MapReduce, el algoritmo que hizo a Google masivamente escalable. El término Map y Reduce vienen de Lisp y la programación funcional. MapReduce es, en retrospectiva, obvio para cualquiera que recuerde de su clase de programación equivalente al 6.0001 que los programas puramente funcionales no tienen efectos secundarios y son paralelizables de manera trivial. El simple hecho de que Google halla inventado el MapReduce y Microsoft no, nos dice algo acerca del por qué Microsoft sigue jugando a tratar de entender cómo conseguir que sus búsquedas funcionen, mientras Google se ha movido al siguiente problema: construir Skynet^H^H^H^H^H^H la supercomputadora más masivamente paralelizada del mundo. Yo no creo que Microsoft entienda completamente qué tan lejos se encuentran detrás de esta ola.

Pero más allá de la importancia Prima Facie de los punteros y la recursividad, su valor real está en que construir grandes sistemas requiere un tipo de flexibilidad mental que obtienes aprendiendo acerca de ellos, y la aptitud mental necesaria para evitar ser expulsado de los cursos donde éstas cosas son enseñadas. Los punteros y la recursividad requirieren cierta habilidad de razonamiento, de pensar con abstracciones, y más importante, ver un problema a diferentes niveles de abstracción simultáneamente. Y luego, la habilidad para entender punteros y recursividad está directamente correlacionada con la habilidad de ser un gran programador.

Nada sobre un grado académico en CC totalmente Java-ero realmente poda a los estudiantes que carecen de la agilidad mental para lidiar con estos conceptos. Como un empleador, he visto que las escuelas 100% Java han comenzado a batir a varios graduados en CC que simplemente no son lo suficientemente inteligentes para trabajar como programadores en nada más sofisticado que en Otra Aplicación Contable En Java, aunque hallan podido escapar a la nueva-estúpida-inferior retícula. Estos estudiantes jamás sobrevivirían al curso 6.001 del MIT, o el CS 323 de Yale, y francamente, esta es una razón por la cual, como empleador, un grado en CC del MIT o de Yale lleva más peso que un grado de CC en Duke, quienes recientemente fueron por el carro completo en Java, o la Universidad de Penn, que reemplazó Scheme y ML con Java en un intento de enseñar la clase que casi mata a mis amigos y a mi, CSE121. No es que ya no quiera contratar chicos inteligentes de Duke o Penn -lo hago- es sólo que me es más difícil deducir quién lo es. Solía ser capaz de descubrir a los chicos inteligentes porque ellos podían comprender un algoritmo recursivo en segundos, o implementar funciones para la manipulación de una lista enlazada con punteros tan rápido como si lo escribieran en un pizarrón. Pero los graduados de una escuela Java-era, no puedo saber si ellos se enredan con estos problemas porque están insuficientemente instruidos, o si se enredan con los problemas porque no tiene actualmente esa parte especial del cerebro que van a necesitar para hacer grandes trabajos de programación. Paul Graham los llama Programadores Llorones.

Está mal ya de por sí que las escuelas Java-eras fallen al podar a los chicos que nunca van a ser grandes programadores, a lo que las universidades dirán, con justificación, que no es su problema. La industria, o al menos, los reclutadores-que-sólo-usan-grep, son los seguros demandantes de que Java debe ser enseñado.

Pero las escuelas Java-eras también fallan al entrenar los cerebros de los chicos a ser expertos, ágiles, y los suficientemente flexibles para hacer buenos diseños de software (y no quiero decir con estos diseño Orientado a Objetos, donde pasas innumerables horas reescribiendo tu código para zangolotear tu jerarquía de objetos, o irritarse sobre problemas como contiene vs es-un). Necesitas entrenar tu pensamiento en cosas con múltiples niveles de abstracción simultáneamente, y este tipo de pensamiento es exactamente lo que necesitas para diseñar grandes arquitecturas de software.

Probablemente estés preguntándote si la enseñanza de la programación orientada a objetos (OOP) es un buen sustituto a a la guadaña de los objetos y la recursividad. La respuesta rápida es: no. Sin debatir los méritos de la OOP, no es lo suficientemente duro para podar a los programadores mediocres. La OOP en la escuela consiste, la mayor de las veces, en memorizar un montón de términos de vocabulario como "encapsulación" y "herencia", y tomando exámenes de opción múltiple con la diferencia entre polimorfismo y sobrecarga. No más difícil que memorizar fechas y nombres famosos en una clase de historia, La OOP tiene retos mentales inadecuados para espantar a los estudiantes de primer año. Cuando te lías con un problema de OOP, tu programa aún funciona, es tan sólo más difícil de mantener. Supuestamente. Pero cuando te lías con punteros, tus programas producen la línea Segmentation Fault y no tienes ni idea de qué sucede, hasta que te detienes y tomas un respiro profundo y tratas realmente de forzar tu mente a trabajar a diferentes niveles de abstracción de manera simultánea.

Los reclutadores-que-sólo-usan-grep, aprovechando, son ridiculizados aquí, y por una buena razón. Jamás he conocido a nadie que trabaje con Scheme, Hasker o punteros en C y que no pueda trabajar con Java en dos días, y crear mejor código en Java que las personas con cinco años de experiencia en Java, pero traten de explicar eso al idiota promedio de recursos humanos.

Pero ¿qué hay acerca la misión de CC en los departamentos de CC? ¡Estos no son escuelas vocacionales! No debería ser su trabajo entrenar gente para trabajar en la industria. Eso déjenlo a los colegios comunitarios y a los programas de entrenamiento gubernamentales para trabajadores desplazados, ellos te lo dirán. Ellos están supuestamente para dar a los estudiantes las herramientas fundamentales para vivir sus vidas, no para prepararlos para sus primeras semanas de trabajo. ¿Correcto?

Aún así. CC es computabildad (recursividad), algoritmos (recursividad), lenguajes (cálculo lambda), sistemas operativos (punteros), compiladores (cálculo lambda) - y por tanto la última línea es que las escuelas Java-eras que no quieran enseñar C y no quieran enseñar Scheme no están enseñando realmente ciencias computacionales, tampoco. Tan inútil como el concepto de función curryficada puede ser para el mundo real, es obviamente un prerequisito para una escuela de graduados en CC. No puedo entender por qué el profesorado en los comités de retículas en las escuelas de CC han permitido que su programas sean idiotizados al punto de que no solamente puedan producir programadores de trabajo, ellos no pueden siquiera producir estudiantes graduados de CC que puedan conseguir un PhD y competir por sus puestos académicos. Ah, esperen. Olvídenlo. Tal vez ya entendí.

Actualmente si regresan y buscan la discusión que tuvo lugar en la academia durante El Gran Cambio A Java, notarán la gran preocupación era si Java es lo suficientemente simple para usarse como lenguaje para enseñar.

¡Dios mio, pensé, están tratando de idiotizar aún más la retícula! ¿Por qué no les dan todo peladito y en la boca a los estudiantes? Dejemos que los tutores hagan sus exámenes por ellos también, entonces nadie querrá cambiar de carrera. ¿Cómo es que alguien que va a poder aprender cualquier cosa, si la retícula ha sido cuidadosamente diseñada para hacer todo más fácil de lo que realmente es? Parece ser que hay una fuerza de tarea en camino (PDF) para buscar un subconjunto de Java más simple que pueda ser enseñado a los estudiantes, produciendo documentación simplificada que cuidadosamente esconde toda la basura de EJB/J2EE de sus tiernas mentes, y así no tengan que preocupar su cabecitas con clases que no necesites hacer en tu conjunto de fáciles problemas de CC.

La interpretación más empática de por qué los departamentos de CC son tan entusiastas con su idiotización de sus cursos es que dejan así más tiempo para enseñar conceptos de CC actuales, si no tiene que gastar dos exposiciones completas para explicar a los estudiantes las diferencias entre, digamos, un int en Java y un Integer. Bueno, este es el caso, 6.001 era la respuesta perfecta para ti: Scheme, un lenguaje de enseñanza tan simple que el lenguaje entero puede ser enseñado a los estudiantes brillantes en cerca de 10 minutos; luego puedes gastar el resto del semestre en puntos fijos.

Eh.

Regreso a mis unos y ceros.

(¿Tienes algunos? ¡Maldito bastardo! Todo lo que tenemos son ceros.)