Algunas conclusiones aleatorias de la educación para programación con Java en Guatemala

Durante el meetup 2019.07 el grupo de usuarios Java de Guatemala tuvo a bien realizar una discusión con el tema enseñanza de Java en la academia.

Para esta reunión nos acompañó personal docente y académico de la Universidad de Costa Rica (sede pacifico) específicamente de la carrera de informática empresarial -i.e. desarrollo de software comercial-.

Diferente de muchas reuniones de GuateJUG, en esta ocasión logramos juntar un grupo heterogéneo de actores en el sector educativo, incluyendo profesores de enseñanza media, Universidad Mariano Galvez, Universidad Rafael Landivar, Oracle Workforce Development, Oracle University y personas de la industria bajo la misma pregunta.

¿Como y porqué es fácil/dificil enseñar programación con Java a nivel universitario?

En linea con el debate, comparto mis notas de la discusión:

  • Todos coinciden que las clases a nivel universitario en Centro América aun se dan con Java 6/7 porqué ningún programa de estudios incluye programación funcional. Esto es especialmente problemático en programación asíncrona, sistemas escalables y micro servicios, la industria NECESITA programadores con capacidades funcionales y no los encuentra.
  • Un problema aun vigente en Guatemala es que durante los años 90 la industria se desarrolló en base a tecnologías propietarias. De los asistentes alguien que se había formado en los años 90s dio su «testimonio» de como eso limitó su carrera profesional.
  • Todos los asistentes coinciden que el peor de los factores para desistir de aprender Java fue/es un mal profesor que no tiene buenos fundamentos de POO, algunos de los síntomas comunes:
    • No sabe utilizar interfaces
    • Codifica todo con métodos estáticos
  • El mejor IDE para aprender fundamentos de POO es BlueJ
  • El mejor IDE profesional para principiantes en Java es NetBeans
  • De todos los asistentes por lo menos el 30% aprendió a programar utilizando Java como primer lenguaje, el resto recibió formación previa en Pascal, C y Scratch. Al parecer es el patrón común en Centro América.
  • De las personas que aprendieron con Java como primer lenguaje, todos coincidieron que eso les abrió las puertas a dominar cualquier otro lenguaje ya que es el lenguaje más fácil para aprender programación orientada a objetos.
  • Todos los asistentes coincidieron en que el proceso de enseñanza de programación es el siguiente y es malo por un motivo:
    • Se aprende algoritmos básicos (precisos, finitos y determinados)
    • Se elaboran ejemplos en pseudocodigo de estos algoritmos
    • Se elabora un programa de computadora a partir del pseudocódigo con sentencias 0- secuenciales, 1- condicionales, 2- repetitivas, 3- invocación
  • El motivo por el cual es «malo» es porque traducir pseudocódigo hacia un lenguaje POO (Java/C#) es un proceso antinatural ya que el pseudocódigo es en esencia programación estructurada
  • Las opciones planteadas al problema anterior son:
    • Live coding en clase
    • Java REPL
    • Uso de otro lenguaje como Groovy que soporta ambos paradigmas y puede ser un buen paso intermedio hacia Java/C#
  • Uno de los principales problemas de empatar con las necesidades de la industria, es que la industria solicita dominio de frameworks. En su afan de entregar gente capaz a la industria la academia introduce estos frameworks sin mucho éxito o metodología.
  • Un problema poco visible es que los frameworks modernos y sobre todo su documentación presuponen que el lector sabe:
    • Meta-programación (anotaciones)
    • Patrones de diseño
    • Domain Driven Development
  • El JavaScript moderno es un desmadre, ES6 tuvo avances pero para alguien que ya sabe Java . . . es un desmadre
  • Aprender Kotlin como primer lenguaje podría ser un suicidio . . . pero es fácil para alguien que ya sabe Java

Espero que estas conclusiones le sirvan a alguien con el poder adecuado para cambiar la educación en el país.

Una respuesta a “Algunas conclusiones aleatorias de la educación para programación con Java en Guatemala”

  1. Google Chrome 75.0.3770.101 Google Chrome 75.0.3770.101 Android 8.0.0 Android 8.0.0
    Mozilla/5.0 (Linux; Android 8.0.0; moto g(6)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.101 Mobile Safari/537.36

    Y tampoco nada o muy poco de testing unitario.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *