En defensa de los lenguajes complejos: el significado de las clases - viralinstruction

En el invierno de 2014/15, era un estudiante universitario. Mi característica era que tenía demasiado tiempo libre, pero no suficiente dinero para mantenerme ocupado en mi tiempo libre. Aburrido y arruinado, la programación era el pasatiempo perfecto. Si ya posee una computadora, es gratis y el compromiso de tiempo no es desalentador cuando lucha contra el aburrimiento. Elegí aprender Python por recomendación de otros y puedo transmitir esta recomendación a los principiantes desde el fondo de mi corazón. La curva de aprendizaje es suave y cuando solo necesitas descubrir cómo funciona un bucle for, el lenguaje es en su mayor parte divertido y no distrae demasiado. Estoy progresando lo suficientemente rápido.

Sin embargo, hay un concepto que me cuesta mucho entender: las clases. No la magia oscura profunda dentro de la implementación de una clase, sino simplemente el concepto de una clase tal como aparece en su superficie.

Mi material de estudio presenta clases con este cliché:

Las clases te permiten modelar objetos directamente en tu código. Digamos que escribes algún código relacionado con tu perro Rex, que ladra. En este caso, podrías escribir

¿Puedes ver por qué lo anterior es una mala introducción para alguien que nunca ha estado expuesto al concepto de "clases"? Tómate un momento para reflexionar.

banq Nota: "Leyenda" es una técnica retórica en idioma chino: la metáfora. Ver: Los modelos de datos son una táctica de vergüenza

No puedes entender una solución si no entiendes el problema que resuelve. Si se le ocurre la solución primero, será más difícil descubrir que hubo un problema en primer lugar. (banq: el mapeo de modelado es un conocimiento del que carecen los programadores junior)

Este es el problema que encontré al leer el ejemplo de "Puppy Rex". No es que no entienda cómo funciona el código, la clase del ejemplo sí parece un perro de 35 kg llamado Rex que ladra. ¿Pero sabes qué es lo que también hace ladrar a un perro de 35 kilogramos llamado Rex? Dos variables y una función.

Compare los dos fragmentos de código anteriores. Son funcionalmente idénticos. Este último es mucho más breve y va al grano.

No introduce ninguna sintaxis o reglas nuevas para un estudiante que ya ha aprendido sobre funciones y variables.

Haga una pausa por un momento y reflexione sobre lo extraña y poco intuitiva que es la sintaxis de clases de Python. __inicio__? ¿En realidad? Entonces, ¿qué es el yo? ¿Por qué una función sin parámetros se define como una función con un parámetro? ¿Cuál es la diferencia funcional entre corteza (peso) y perro.bark()?

El segundo fragmento de código es mejor en todos los sentidos.

Así que creo que puedo prescindir de las "clases".

Me imagino que si las clases de Python tienen una razón para existir, ¡deben tener algún comportamiento especial que no puedo ver! Eso es lo que pienso.

Mirándolo ahora, es obvio que mi suposición estaba equivocada.

Por supuesto, las "clases" desbloquean algunos comportamientos nuevos que no serían posibles sin el uso de clases, pero no es por eso que las clases son útiles. De hecho, casi todas las clases que escribo ahora no hacen nada que no sea posible con tipos integrados y llamadas a funciones.

El problema con el ejemplo del perro Rex es que la clase no pretende representar a tu perro.

Representa algo completamente diferente: encapsulación, modularidad, abstracción.

No elijamos qué significan exactamente estos términos, todos se refieren a lo mismo: gestionar la complejidad de su propio código.

El software no es infinito

Como artefacto, el software es muy diferente de las creaciones físicas de otras artesanías. No se consume materia prima para producirlo. No requiere herramientas especializadas para producir ni siquiera código de la más alta calidad. El producto no pesa nada y su distribución física es casi sin esfuerzo. Cuesta casi nada producir millones de copias y enviarlas a todo el mundo.

Entonces, sin estas limitaciones, ¿el software es ilimitado e ilimitado? No, está sujeto a otras limitaciones.

A veces, el software está limitado por las capacidades físicas, el espacio en disco, el uso de la memoria o la velocidad informática de la máquina en la que se ejecuta. No pretendo menospreciar estas limitaciones físicas. Después de todo, mucho de lo que escribo en este blog tiene que ver con el rendimiento. Pero, sobre todo, el software está limitado por el proceso de creación. Los programadores tienen una cantidad de tiempo limitada para crear código y una cantidad de tiempo especialmente limitada para mantenerlo.

Verá, mantener el código, como corregir errores, requiere que los programadores comprendan el funcionamiento interno del código en detalle. Cuanto más código, mayor es la complejidad, más tiempo lleva comprenderlo y más errores agrega el programador al no comprender lo que sucede o podría suceder cuando se ejecuta el código.

Esto no quiere decir que el software esté condenado a ser particularmente difícil de entender en comparación con otros productos del trabajo creativo. Precisamente porque no hay otros obstáculos, los programadores podemos seguir creando, y seguir creando, hasta que tengamos un dispositivo con más partes móviles que cualquier dispositivo físico que podamos construir, y seguir creando hasta que ya no podamos. La creación permanece en la mente y se ralentiza. sumidos en un fango de complejidad, consumiendo tiempo.

Por eso las clases son importantes en Python: nos ayudan a que nuestros programas sean más fáciles de controlar a medida que crecen.

Como principiante, no lo sé porque todavía tengo que experimentar la complejidad de uno de mis programas fuera de control. Nunca he visto una puerta cerrada, así que no entiendo por qué alguien querría una llave.

Desde entonces he tenido el privilegio de enseñar Python a otros principiantes. En estos cursos, tengo como prioridad asignar a los estudiantes un gran proyecto personal al final del curso, incluso si eso significa tener que recortar otros aspectos del curso. Al asesorar a los estudiantes, esto brinda una oportunidad única para hacerles saber, en lugar de decirles, que las buenas prácticas de codificación pueden ayudarlos a desentrañar el código espagueti y recuperar el control de sus proyectos hundidos.

¿Qué pasaría con Python sin clases?

Entonces, ¿qué pasa si desactivamos las clases en Python?

Oh, esto hará que el lenguaje sea muy simple, como en mi ejemplo de Rex; el resto será pura lógica de dominio, lógica de negocios, ¡el verdadero negocio! Casi no se desperdicia código en plantillas o rituales. ¡Casi no se desperdicia código en plantillas o rituales! No hay mucha sintaxis extraña que enseñar, y no hay obstáculos para que los novatos como yo se queden atascados mientras aprenden. Lo mejor de todo es que casi no hay pérdida de funcionalidad, ya que las clases en su mayoría no le brindan ningún comportamiento nuevo.

Lo que también puede suceder es que los usuarios descubran que el número de variables se vuelve inmanejable. Hasta que un día, a algunos programadores se les ocurrió una gran idea: podían reducir la cantidad de variables que mantenían en sus cabezas, siempre y cuando agruparan las variables en un dict.

Por lo tanto, reintroducirán clases accidentalmente, solo que esta vez, la existencia de las clases está implícita en el código, su comportamiento se define ad hoc y sus invariantes están dispersos por los archivos fuente, y hay No hay herramientas a nivel de lenguaje ni introspección para ayudar a los programadores.

La clase todavía existe, pero como un patrón implícito.

Este tipo de estructura aparecerá de forma espontánea y constante en el código.

Los lenguajes de programación anteriores no admitían funciones, pero luego se descubrió que las instrucciones a menudo se agrupan por función, y conceptualizarlas como una función hace que sea más fácil razonar sobre el código. La introducción de funciones no hace que la programación sea más compleja, al contrario, la simplifica en aspectos importantes.

Los lenguajes anteriores no tenían estructuras, pero los programadores posteriores descubrieron la utilidad de agrupar conjuntos de datos en datos abstractos de orden superior llamados estructura. Además, esta característica no hace que el programa sea más complejo, sino que lo simplifica.

Julia y Rust

En comparación con los lenguajes de esa época, los lenguajes de programación modernos están superpoblados. Personalmente me gustan Rust y Julia, ambos idiomas son notoriamente complejos y distintivos.

Julia tiene un sistema de tipos complejo. Me gusta AbstractSet{Union{Nada,