Muchas veces me han preguntado por qué prefiero usar lenguajes de programación como Haskell y Rust, porque no son las herramientas más utilizadas y populares. Esta publicación está escrita con la intención de desmitificar lo que pasa por mi cabeza cuando pienso en opciones tecnológicas.
El desarrollo de software con los requisitos de operación a largo plazo y un cierto nivel de confiabilidad es, en cierto sentido, similar a un juego de ajedrez. Las variantes del desarrollo de eventos en ambos son bastante difíciles de comprender para el cerebro humano, el papel de la experiencia es de gran importancia y cada movimiento / elección puede ser crítico. La similitud continúa en el sentido de que, como el ajedrez, el desarrollo es muy "posicional": se puede apuntar una serie completa de movimientos a prepararse para una maniobra que conducirá a la victoria de un peón. Puede parecer que esto es solo un peón, pero para un juego serio esto puede ser una ventaja significativa. De manera similar al juego posicional del tablero de ajedrez, durante el diseño y desarrollo de grandes proyectos, constantemente tomamos decisiones que tienen como objetivo resolver problemas mayores o cumplir con los requisitos del proyecto.El efecto de cada solución, incluso una pequeña, tiende a acumularse hacia el final del juego, o cuando el producto de software está en funcionamiento. La diferencia, que agrava la situación, es que el desarrollo de software, a diferencia del ajedrez, no se resuelve en una computadora, y usted no puede simplemente tomar y encontrar los mejores movimientos ejecutando un motor de computadora. Por lo tanto, es necesario tomar muchas decisiones que de manera incremental nos lleven a este objetivo, y todos los medios que mejoran nuestra "posición" estratégica son buenos.y no puede simplemente ir y encontrar los mejores movimientos ejecutando un motor informático. Por lo tanto, es necesario tomar muchas decisiones que de manera incremental nos lleven a este objetivo, y todos los medios que mejoran nuestra "posición" estratégica son buenos.y no puede simplemente ir y encontrar los mejores movimientos ejecutando un motor informático. Por lo tanto, es necesario tomar muchas decisiones que de manera incremental nos lleven a este objetivo, y todos los medios que mejoran nuestra "posición" estratégica son buenos.
Las soluciones se pueden simplificar en varias categorías: arquitectónicas, metodológicas e instrumentales. Los arquitectos hablan de cómo estructuramos un proyecto. Los métodos determinan cómo organizamos el proceso de trabajo, aseguramos la calidad y corrección de la implementación. Las herramientas determinan con qué debe trabajar el equipo de desarrollo para obtener el resultado. Para un ciclo de desarrollo completo, hoy en día se utilizan una gran cantidad de herramientas: es necesario formalizar los requisitos, el proceso de desarrollo, escribir el código del programa y probarlo, crear una versión, etc. A pesar de la abundancia de tareas, el La elección de un lenguaje de programación puede jugar el papel más importante, ya que determina un conjunto de los siguientes parámetros:
- Línea de base sobre la velocidad del software.
- , .
- , . , .
- // , .
- , , .
- .
Además, la elección de un lenguaje de programación también puede afectar significativamente las cuestiones metodológicas, por ejemplo, las herramientas del ecosistema del lenguaje pueden determinar cómo y en qué medida se escriben las pruebas unitarias. Una buena infraestructura para las pruebas de propiedad puede dar un impulso en esta dirección, y la falta de una buena infraestructura para las pruebas unitarias puede dificultar su escritura y mantenimiento.
Las herramientas también afectan los problemas de arquitectura: la reutilización de módulos en el sistema está ligada a la conveniencia de dividir bloques conceptualmente y estructurar el código. Por ejemplo, trabajar explícitamente con sistemas de efectos le permite generalizar más el código y asegurarse de que el módulo de código no realice operaciones de E / S, como trabajar con la red y el disco, lo que le permite razonar sobre seguridad y arquitectura.
En base a esto, debe tener en cuenta que elegir el lenguaje de programación adecuado para un proyecto y un equipo puede tener consecuencias de gran alcance. Teniendo en cuenta la analogía del ajedrez, tenemos en cuenta que cada pequeña ventaja irá a la alcancía del idioma y puede jugar un papel importante en un gran desarrollo. También vale la pena mencionar que estamos hablando de elegir una herramienta de desarrollo para situaciones en las que no existen restricciones estrictas en la elección de tecnologías en conexión, por ejemplo, con un gran ecosistema ya escrito en algo. En Typeable, nos guiamos por las siguientes consideraciones para los lenguajes de uso general:
- . . , , .
- — , , . . - , , , .
- . GIL (Global Interpreter Lock) . .
- , . , , , .
- . , CS . « » , IT , .
- , .
Como resultado de todo lo anterior, hay suficientes bloques en nuestra caja de herramientas que nos permiten tomar una posición de confianza en muchos proyectos. Volviendo a la analogía del ajedrez, estos son nuestros principios que nos permiten jugar un juego posicional. El juego posicional es un juego destinado a crear una posición a largo plazo que abre oportunidades para el jugador y minimiza las debilidades. Se opone a un juego de ataque, "agudo", donde hay una gran proporción de riesgo, y el jugador atacante intenta completar este juego antes de que su oponente pueda tomar una buena posición defensiva. El desarrollo "agudo" es la programación de Olimpiadas, MVP para experimentos de marketing, muchas tareas en ciencia de datos y, a menudo, la creación de software que acompaña a las publicaciones de Ciencias de la Computación. Les une el hecho de que a menudo no requieren apoyo a largo plazo,solo necesitan trabajar en un momento determinado. El juego posicional es un juego a largo plazo, donde la capacidad de mantenimiento y la capacidad de actualización son indicadores clave. Esto es lo que estamos haciendo y necesitamos una buena base para tener confianza en el rendimiento a largo plazo del software que escribimos y actualizamos. Estos proyectos también pueden comenzar con MVP, pero se realizan con requisitos previos completamente diferentes.
¿Por qué la lista de consideraciones para elegir tecnologías es exactamente así? Hay varias razones para esto. En primer lugar, es deseable excluir las cuestiones de moda y tendencias de la tecnología para aumentar la previsibilidad durante un largo período de tiempo. Un compilador con una larga historia y una comunidad activa es, aunque conservadora, pero una opción confiable, a diferencia de las cosas nuevas y brillantes que aparecen año tras año. Seguramente algunos de ellos pasarán de la última categoría a la primera, pero esto lo sabremos más adelante, probablemente en años. En lugar de tendencias, estamos tratando de utilizar la informática fundamental y una gran cantidad de investigación sobre este tema que ha encontrado aplicación en los lenguajes de programación que utilizamos. Por ejemplo: la teoría de tipos es una disciplina relacionada de las matemáticas y la informática que se ocupa de las cuestiones fundamentales de la formalización de requisitos. Esto es exactamente lo quelo que necesitamos para escribir software. Además, esta es la experiencia acumulada de otras personas que se dedican a las ciencias exactas y, en mi opinión, es una estupidez descuidar esta experiencia. Es mejor tomar tal disciplina como base que no tomar nada, o tomar una opinión subjetiva basada en la experiencia de vida de una sola persona.
En segundo lugar, buscamos la implementación del mayor número de principios que hemos adoptado en lenguajes de programación y compiladores. Por esta razón, además de nuestro querido Haskell, Rust ha comenzado a aparecer en nuestra caja de herramientas. Con requisitos de tiempo real y límites estrictos en el uso de la memoria, necesitamos algo de bajo nivel. La rigurosidad de la escritura en C todavía deja mucho que desear, por lo que si es posible usar Rust para tal tarea, preferiríamos hacerlo.
La tercera razón: hacemos software principalmente para nuestros clientes y nos gustaría que estuvieran protegidos de nuestros prejuicios. Por tanto, a la hora de elegir un instrumento, el riesgo no puede superar un determinado nivel, que debe ser acordado con el cliente. Pero incluso con tales condiciones, tenemos tecnologías bastante marginales como GHCJS, porque con el análisis combinado de las fortalezas y debilidades, el panorama seguía siendo atractivo para nosotros y nuestros clientes. Ya escribimos sobre cómo llegamos a esta decisión: Elm vs Reflex .
Cuando se trabaja con bases de código grandes y software complejo, todos los medios y justificaciones teóricas son buenos, porque necesita de alguna manera poder mantener esta complejidad bajo control. Nuestra idea del enfoque correcto es defender cada peón, mejorar su posición con fluidez y precisión, para que el proyecto pueda sobrevivir en buenas condiciones hasta el momento en que pueda jugar un papel decisivo para el negocio de nuestros clientes. Te deseamos lo mismo.