Herb Sutter: por primera vez en 36 años, el creador de C++ se opone a su comité

Este es un resumen bien escrito y bastante diplomático de Herb Sutter. No estoy lo suficientemente al tanto como para asegurar que tenga razón en que la oposición de Stroustrup fue la razón principal por la que la votación de C++26 falló donde otras han pasado, pero suena plausible.

También enumera 6 posibles caminos a seguir para C++26 con pros y contras. Creo que son aproximadamente:

A. Omitir un estándar oficial de C++26 pero incluir estas características en C++29.

B. Eliminar los contratos de C++26 y aprobarlo.

C. Decir "por favor" y votar de nuevo.

D. Ajustar los contratos en lo relativo a funciones virtuales y votar de nuevo.

E. Aprobar C++26 como estándares nacionales de muchos países diferentes en lugar de como un estándar internacional.

F. Hacer E y también considerar dejar ISO y pasarse a ANSI/INCITS.

Creo que esto le da demasiado peso a este evento y a la posición de Bjarne sobre los contratos.

La oposición de Bjarne a los contratos podría haber inclinado la balanza, pero definitivamente hay un creciente cansancio (y recelo) hacia las grandes características a medio cocer que se dejan como ejercicios para los implementadores (mirándote a ti, módulos).

Ignorar ese contexto histórico al analizar esta votación parece un error.

No le he prestado mucha atención a C++ desde hace tiempo (la última característica interesante que vi fueron los conceptos). Normalmente disfruto un poco del extraño y expresivo code golf que se puede escribir con las nuevas características. Por ejemplo, probé a usar conceptos para asegurar que las dimensiones de Matrix fueran compatibles con la operación deseada. No era muy útil, pero fue un experimento mental curioso.

Pero estos contratos propuestos... simplemente no veo mucho beneficio que ofrezcan sobre escribir explícitamente tus propias aserciones.

Supongo que puedes ver los requisitos en las declaraciones, pero apostaría a que las declaraciones modernas y sofisticadas de C++ se vuelven rápidamente tan largas y verbosas que te fatigarías pronto de leerlas. Quizás en la era de los LLM sean más útiles?

Como alguien que pasó unas semanas intentando meterse en C++ (antes de los LLM, así que quizás ahora sea mejor?) y que más o menos se rindió por confusión, realmente me resultó difícil lidiar con las múltiples formas diferentes de hacer algo. Quiero decir, ¿qué puntero debería usar? ¿Cómo debería iterar? Estoy seguro de que hay una respuesta para esto, pero simplemente me resultó más fácil volver a python y recurrir a rust cuando lo necesitaba.

Parece que parte de la preocupación es que la característica debe enviarse bien a la primera porque vivirá para siempre. ¿Quizás permitir que las características queden obsoletas y luego se eliminen podría ayudar?

Pero no sé, no he escrito nada que haya durado 36 años, así que quizás el enfoque actual sea lo mejor!

Solo pasaba por aquí para decir que Sutter no solo tiene razón al reiterar la posición de Bjarne aquí, sino que también es el autor, en mi opinión, del artículo más impactante sobre el progreso del rendimiento del hardware y el cambio a la ejecución concurrente: https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf

36 años de acuerdo sostenido no es bueno; significa que nadie le dice que no a nada, y tienes una enorme bola de nieve sucia rodando montaña abajo.

Estoy seguro de que no soy el único, pero siento que C++ está acabado/terminado. Trabajo en una base de código C++ y he estado haciendo C++ durante > 20 años y, al menos para mí, las señales son claras.

1. C++ es inseguro. Bjarne sigue dando charlas que efectivamente dicen "úsalo perfectamente y no cometas ningún error y es seguro". Eso ya no es útil. En un mundo donde los LLM pueden encontrar cada error para explotarlo, todos los proyectos de C++ están luchando por mantenerse al día y mantenerlos en C++ es básicamente garantizar que habrá más exploits en el futuro. Sí, no todos los errores se resuelven cambiando a un lenguaje más seguro, pero reducir la superficie de ataque en la nueva realidad ya no es algo que se pueda posponer.

2. Los LLM pueden reescribir. Los argumentos anteriores solían ser "hay bases de código heredadas de C++ así que C++ nunca morirá". Ese era un argumento válido antes de que un LLM simplemente lo reescribiera todo. Entiendo que la gente dirá que no son perfectos, pero los humanos tampoco. Además, mejoran todo el tiempo, y vemos su progreso. Gente apuntando un LLM a algún proyecto y mágicamente haciéndolo funcionar en otra plataforma, etc... Está claro que está sucediendo.