El autor del artículo analiza los problemas de los lenguajes de programación modernos y las formas en que se pueden corregir las deficiencias.Solo en los últimos 18 años, las personas han ideado muchos idiomas, entre los cuales probablemente los más populares son Swift, Kotlin y Go. Además, la característica distintiva del lenguaje de programación del siglo XXI es la ausencia de características distintivas. Lo más agradable de trabajar con estos idiomas es que puedes pasar un fin de semana aprendiendo uno de ellos y finalmente decir que lograste aprender una novedad popular, pero que de hecho no has aprendido nada nuevo. Realmente no son nada nuevo. Todos los lenguajes modernos se crean sobre la base de alguna fórmula correcta y probada, cuyo nombre es probablemente Objective-C, Java o C.
La "falta de novedad" puede considerarse una característica valiosa, pero esta situación plantea una pregunta. ¿Estamos realmente frente a los idiomas del nuevo siglo XXI, o todo esto es solo un reflejo de los malos hábitos de programación del siglo XX?
Si inventara el lenguaje, no trataría de corregir el pasado, sino que trataría de crear algo que funcionara bien en las condiciones modernas, pero que también pudiera desarrollar y resistir la prueba del tiempo. Si esto requiere soluciones constructivas radicales, que así sea.
¡Abajo la sintaxis!
La sintaxis de los idiomas modernos refleja un intento de exprimir la libertad de la tiza y el pizarrón en los grilletes de ASCII. Algunos elementos de un registro, como signos aritméticos o corchetes, se perciben de manera más o menos natural. Pero una serie de otras designaciones se justifican solo ahorrando esfuerzo al presionar los botones de teletipo.
Introducir texto desde el teclado ya no es difícil. No estamos obligados a ponernos en una posición en la que sea necesario adivinar el significado de la sintaxis. Piezas como
(($: @ (<# [), (= # [), $: @ (> # [)) ({~? @ #)) ^: (1 <#) - un formato de grabación muy corto y espacioso (esto, por cierto, es un código
real en
lenguaje real ), pero no mejora la legibilidad de ninguna manera. Y, lo que es más importante, es difícil "googlearlo" o encontrarlo en stackoverflow.
Lo mismo puede decirse sobre los misteriosos nombres de funciones, convenciones de códigos de retorno y atributos con un significado oscuro. Sirvieron bien en el pasado, ahorrando mucho espacio en tarjetas perforadas, pero hoy es el momento para un merecido descanso.
Algo como
FILE * test_file = fopen("/tmp/test.txt", "w+");debe transformarse en
create file /tmp/test.txt for input and output as test_fileNo necesitamos todos estos corchetes, comillas, asteriscos y punto y coma (a menos que, por supuesto, realmente no transmitan la idea más claramente). El resaltado de sintaxis es bastante capaz de reemplazar completamente la notación de sintaxis.
Algunas cosas abundantes están disponibles en el siglo XXI: por ejemplo, velocidad de análisis, memoria de computadora, búsqueda en línea. Otros recursos aún están en precio: tiempo de desarrollo, memoria del programador, esfuerzo dedicado al aprendizaje de las características del lenguaje. Los cambios en las reglas para escribir código deberían cambiar el enfoque hacia recursos más baratos y ahorrar recursos más caros.
¡Abajo los tipos incorporados!
Probablemente esté familiarizado con las
paradojas de JavaScript . Por ejemplo, tales:
> 10.8 / 100
0.10800000000000001Este resultado no es exclusivo de JavaScript. Y esto no es una paradoja en absoluto, sino un ejemplo de adhesión absolutamente correcta al respetado estándar IEEE 754. Una implementación similar de números de punto flotante se encuentra en casi todas las arquitecturas. Y no es tan malo, teniendo en cuenta que estamos tratando de meter un número infinito de números reales en 32, 64 o 256 bits.
Lo que los matemáticos consideran imposible, los ingenieros encarnan el rechazo del sentido común en aras de la implementación práctica. Los números de coma flotante en la interpretación IEEE no son números en absoluto. Las matemáticas requieren asociatividad de la operación de su adición. Los tipos flotante y doble no siempre guardan esta propiedad. Las matemáticas requieren que el conjunto de números reales incluya enteros, pero este requisito no se cumple ni siquiera para float y uint32_t del mismo tamaño. Las matemáticas requieren que los números reales tengan un elemento cero. Bueno, a este respecto, el estándar IEEE supera todas las expectativas, porque los números de coma flotante tienen dos elementos cero en lugar de uno.
No solo los números de coma flotante tienen características similares. Los enteros integrados no están mejor implementados. ¿Sabes qué sucede si intentas agregar dos números de 16 bits?
0xFFFF + 0x0001Nadie dará una respuesta exacta. Un instinto nos dice que el desbordamiento dará 0x0000. Sin embargo, dicho resultado no está documentado en ninguna norma internacional. Al manejar esta operación, todos se guían por el enfoque C y la familia de procesadores x86. Alternativamente, puede resultar 0xFFFF, o se activará una interrupción, o se almacenará un bit especial que indica desbordamiento en un lugar especial.
Tales momentos generalmente no se consideran en ningún lado, y las reglas para procesar tales operaciones difieren de un idioma a otro. Si las rarezas de coma flotante están al menos fijadas por el estándar, entonces la última pregunta planteada es, en principio, impredecible.
En cambio, para los cálculos numéricos, sugeriría introducir tipos de datos de un valor definible con un punto fijo y con un comportamiento estandarizado en caso de pérdida de precisión o ir más allá del límite superior o inferior. Algo como esto:
1.000 / 3.000 = 0.333
0001 + 9999 = overflowed 9999
0.001 / 2 = underflowed 0No es necesario agregar todos los ceros finales: su presencia debe estar implícita en la definición del tipo de datos. Pero es importante poder elegir los límites máximos y mínimos usted mismo, y no depender de la arquitectura del procesador.
¿No funcionarán tales cálculos más lentamente? Sí lo harán Pero pregúntese: ¿con qué frecuencia tiene que programar la informática de alto rendimiento? Creo que si no eres un experto en este campo, entonces es muy raro. Y si está involucrado en tales tareas, entonces utiliza equipos y compiladores especializados para estos fines. Por lo que puedo decir, un programador típico del siglo XXI rara vez resuelve ecuaciones diferenciales.
Sea como fuere, nada impide el uso de tipos integrados rápidos, complejos e impredecibles del pasado como alternativa, en lugar de como la opción predeterminada.
¡Abajo la práctica de los metalenguajes!
Hay lenguajes maravillosos que se inventaron no para realizar tareas, sino para crear idiomas que sean capaces de realizarlas. Racket, Rebol y Forth son solo algunos ejemplos. Me gustan todos, jugar con ellos es puro placer. Pero, como probablemente haya adivinado, el placer recibido de trabajar con el idioma no es el criterio principal que hace que el idioma sea universal y popular.
La capacidad de crear nuevos idiomas dentro de un idioma para realizar una tarea en particular es una herramienta muy poderosa que vale la pena durante el trabajo de investigación independiente. Desafortunadamente, si el código debe ser claro no solo para el autor, además del principal, tendrá que enseñar a otras personas y el nuevo idioma interno. Y aquí comienzan los problemas.
La gente quiere completar la tarea, y no aprender un idioma que ayudará a hacer el trabajo exactamente una vez, y después de eso no serán útiles. Para los extraños, la idea de dominar su idioma es una inversión que es poco probable que valga la pena. Pero aprender algo estandarizado es una inversión para toda la vida. Por lo tanto, más bien, volverán a escribir su código nuevamente y solo entonces lo aprenderán. Por lo tanto, innumerables dialectos aparecen para una esfera aplicada. La gente discute sobre estética, ideología, arquitectura y otras cosas sin importancia. Y millones de líneas de código están escritas para hundirse en el olvido en unos pocos meses.
Los chicos de Lisp pasaron por esto en los años 80. Se dieron cuenta de que mientras más elementos del lenguaje aplicado estén estandarizados, mejor. Así surgió Common Lisp.
Y él era enorme. El estándar INCITS 226–1994 tiene 1.153 páginas. Este registro, 17 años después, se rompió solo por C ++ con el estándar ISO / IEC 14882: 2011 (1338 páginas). C ++ tiene que arrastrar un legado insoportable, a pesar de que no siempre ha sido tan grande. Common Lisp fue creado en su mayor parte desde cero.
El lenguaje de programación no debería ser tan grande. Esto no es necesario Solo necesita una buena biblioteca estándar, llena de todo tipo de cosas útiles, para que las personas no tengan que reinventar la rueda.
Por supuesto, mantener un equilibrio entre el tamaño y la idoneidad de la aplicación no es fácil. La experiencia de C ++ en la práctica ha demostrado lo difícil que es. Creo que para lograr el equilibrio necesario, el lenguaje del siglo XXI debe agudizarse condicionalmente bajo cierto campo aplicado. Dado que la mayoría de los problemas ahora surgen precisamente en el campo de las aplicaciones empresariales, el lenguaje probablemente debería centrarse en los problemas empresariales, y no en el desarrollo de juegos o el diseño web.
Entonces ...
El lenguaje del siglo XXI debe estar orientado a los negocios, usar expresiones de lenguaje claro y no depender de tipos incorporados. ¡Es genial que tal lenguaje ya exista! ¿Qué piensas, de qué estamos hablando?
Sí, esto es COBOL.
Este es uno de los primeros idiomas de alto nivel, hoy mayormente olvidado. Tengo que admitir que describí intencionalmente las características antiguas de COBOL como ultramodernas e increíblemente prometedoras. Y lo hice para mostrar una cosa. El código no está escrito por características del lenguaje. Tu lo haces
Es ingenuo pensar que el idioma es responsable de la calidad del código, y que agregar algunos dispositivos (o eliminarlos) puede mejorar automáticamente todo. Hubo un tiempo en que a los programadores no les gustaban Fortran y COBOL, por lo tanto, inventaron C ++ y Java, para finalmente llegar a una situación en la que, 20 o 30 años después, tampoco les gustaban a todos.
Según mis sentimientos, la raíz del problema se encuentra en algún lugar del campo de la sociología y la psicología, pero no en la programación. ¿Realmente nos disgustan tanto los idiomas? ¿Y estamos satisfechos con el entorno en el que trabajamos? Windows es vulnerable, Visual Studio es demasiado lento, es imposible salir de Vim. De hecho, son estas cosas las que causan descontento, y no el proceso creativo en sí.
Pero siempre tienes que encontrar al culpable. Como ingenieros de software, en parte responsables de lo pésimos que son los programas, no nos culparemos, ¿verdad? Por lo tanto, estamos buscando fallas en las herramientas. Inventemos nuevos COBOL hasta que un día el sol comience a brillar más, las aves no canten más fuerte y Windows comience a cargarse en 2 segundos.
Pero lo más probable es que este día nunca llegue.
Por lo tanto, si quisiera inventar el lenguaje de programación del siglo XXI, trataría de encontrar un nuevo enfoque de responsabilidad. O una nueva forma de dominar mejor las herramientas existentes. Intentaría estar más atento a los detalles esenciales y deshacerme sin piedad de cualquier complejidad innecesaria. En lugar de idiomas que entran y pasan de moda, siempre hay algunas cosas fundamentales que merecen un replanteamiento constante.
