¿Cómo es que los compiladores son tan confiables?

64

Utilizamos compiladores a diario como si su corrección fuera un hecho, pero los compiladores también son programas y pueden contener errores. Siempre me pregunté acerca de esta robustez infalible. ¿Alguna vez has encontrado un error en el compilador? ¿Qué era y cómo te diste cuenta que el problema estaba en el compilador mismo?

... y cómo hacen que los compiladores sean tan confiables?

EpsilonVector
fuente
16
Bueno, compilan el compilador en él ...
Michael K
31
No son infalibles. Hay errores de compilación, es solo que son muy raros.
ChrisF
55
Los errores se vuelven más raros a medida que desciende la pila de código: los errores de la aplicación son más comunes que los errores del compilador. Los errores del compilador son más comunes que los errores de la CPU (microcódigo). Esta es realmente una buena noticia: ¿te imaginas si fuera al revés?
Fixee
Es posible aprender algo al observar cómo un compilador que lo hace tener una gran cantidad de insectos (como sdcc!) Es diferente de un compilador gcc como que es mucho más robusto y fiable.
Ben Jackson
55
VC ++ 6 tenía un error.
Mateen Ulhaq

Respuestas:

97

Se prueban exhaustivamente a través del uso de miles o incluso millones de desarrolladores con el tiempo.

Además, el problema a resolver está bien definido (por una especificación técnica muy detallada). Y la naturaleza de la tarea se presta fácilmente a las pruebas de unidad / sistema. Es decir, básicamente está traduciendo la entrada de texto en un formato muy específico para generar en otro tipo de formato bien definido (algún tipo de código de bytes o código de máquina). Por lo tanto, es fácil crear y verificar casos de prueba.

Además, generalmente los errores también son fáciles de reproducir: aparte de la plataforma exacta y la información de la versión del compilador, generalmente todo lo que necesita es un código de entrada. Sin mencionar que los usuarios del compilador (siendo los propios desarrolladores) tienden a dar informes de errores mucho más precisos y detallados que cualquier usuario promedio de computadoras :-)

Péter Török
fuente
32
Además, gran parte del código del compilador probablemente pueda probarse como correcto.
biziclop
@biziclop, buen punto, esta es otra consecuencia de la naturaleza especial de la tarea.
Péter Török
El primer compilador completo fue escrito en 1957 para el lenguaje FORTRAN por John Backus. Entonces, ya ves, la tecnología de compilación tiene más de 50 años. Hemos tenido bastante tiempo para hacerlo bien aunque, como otros señalan, los compiladores tienen errores.
leed25d
@biziclop, de hecho, algunos componentes como lexers y analizadores pueden incluso autogenerarse a partir de una gramática, lo que nuevamente reduce el riesgo de errores (siempre que el generador lexer / analizador sea robusto, lo que generalmente es, por las mismas razones enumeradas anteriormente) .
Péter Török
2
@ Péter: los generadores Lexer / parser parecen ser bastante raros en los compiladores más utilizados: la mayoría escribe lexer y parser a mano por varias razones, incluida la velocidad y la falta de un generador de analizador / lexer lo suficientemente inteligente para el idioma en cuestión (por ejemplo, C )
61

Además de todas las excelentes respuestas hasta ahora:

Tienes un "sesgo de observador". No observa errores, y por lo tanto asume que no hay ninguno.

Solía ​​pensar como tú. Luego comencé a escribir compiladores profesionalmente, y déjame decirte que hay muchos errores allí.

No ves los errores porque escribes código que es como el 99.999% de todo el resto del código que la gente escribe. Probablemente escriba código perfectamente normal, directo y claramente correcto que llame a métodos y ejecute bucles y no haga nada elegante o extraño, porque es un desarrollador normal que resuelve problemas comerciales normales.

No ve ningún error del compilador porque los errores del compilador no se encuentran en los escenarios de código normales sencillos y fáciles de analizar; los errores están en el análisis de código extraño que no escribes.

Por otro lado, tengo el sesgo de observador opuesto. Veo códigos locos todo el día todos los días, y para mí los compiladores parecen estar llenos de errores.

Si se sentó con la especificación de idioma de cualquier idioma, y ​​tomó cualquier implementación del compilador para ese idioma, y ​​realmente trató de determinar si el compilador implementó exactamente la especificación o no, concentrándose en casos de esquina oscuros, muy pronto encontrará errores del compilador con bastante frecuencia. Déjame darte un ejemplo, aquí hay un error del compilador de C # que encontré literalmente hace cinco minutos.

static void N(ref int x){}
...
N(ref 123);

El compilador da tres errores.

  • Un argumento ref o out debe ser una variable asignable.
  • La mejor coincidencia para N (ref int x) tiene argumentos no válidos.
  • Falta "ref" en el argumento 1.

Obviamente, el primer mensaje de error es correcto y el tercero es un error. El algoritmo de generación de errores está tratando de descubrir por qué el primer argumento no es válido, lo mira, ve que es una constante y no vuelve al código fuente para verificar si se marcó como "ref"; más bien, supone que nadie sería tan tonto como para marcar una constante como referencia, y decide que la referencia debe faltar.

No está claro cuál es el tercer mensaje de error correcto, pero este no lo es. De hecho, tampoco está claro si el segundo mensaje de error es correcto. ¿Debería fallar la resolución de sobrecarga o "ref 123" debería tratarse como un argumento de referencia del tipo correcto? Ahora tendré que pensarlo un poco y hablarlo con el equipo de selección para que podamos determinar cuál es el comportamiento correcto.

Nunca has visto este error porque probablemente nunca harías algo tan tonto como para intentar pasar 123 por ref. Y si lo hiciera, probablemente ni siquiera notaría que el tercer mensaje de error no tiene sentido, ya que el primero es correcto y suficiente para diagnosticar el problema. Pero trato de hacer cosas así, porque estoy tratando de romper el compilador. Si lo intentaras, también verías los errores.

Eric Lippert
fuente
44
Los buenos mensajes de error después del primero son muy difíciles de hacer.
Seguro que debe haber energía mejor gastada que hacer que los compiladores sean completamente "tontos" a prueba :)
Homde
2
@MKO: Por supuesto. Muchos errores no se arreglan. A veces, la solución es tan costosa y el escenario es tan oscuro que el costo no está justificado por los beneficios. Y a veces suficientes personas han llegado a confiar en el comportamiento "con errores" que tiene que mantener para mantenerlo.
Eric Lippert
mmm ... los errores que terminan en mensajes de error están "bien". Siempre es posible tocar el código un poco para que funcione. ¿Qué pasa con los errores en los que el compilador acepta el código fuente y produce un resultado "incorrecto"? Eso da miedo
Gianluca Ghettini
77
@aij: Correcto en el sentido de "código C # claramente legal". Por ejemplo, ¿alguna vez ha escrito un programa que contenga una interfaz que herede dos interfaces donde una interfaz tenía una propiedad y la otra tenía un método con el mismo nombre que la propiedad? Rápido, sin mirar las especificaciones: ¿ es legal ? Ahora suponga que tiene una llamada a ese método; ¿Es ambiguo ? Y así. Las personas escriben código que no hace lo que quieren decir todo el tiempo. Pero rara vez escriben código donde tendrías que ser un experto en especificaciones para decir si es legal C #.
Eric Lippert
52

¿Me estás tomando el pelo? Los compiladores también tienen errores, realmente se cargan.

GCC es probablemente el compilador de código abierto más famoso del planeta y eche un vistazo a su base de datos de errores: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=-- -

Entre GCC 3.2 y GCC 3.2.3, eche un vistazo a cuántos errores se solucionaron: http://gcc.gnu.org/gcc-3.2/changes.html

En cuanto a otros como Visual C ++, ni siquiera quiero comenzar.

¿Cómo hacer que los compiladores sean confiables? Bueno, para empezar, tienen montones y montones de pruebas unitarias. Y todo el planeta los usa para que no haya escasez de probadores.

Sin embargo, en serio, los desarrolladores de compiladores que me gusta creer son programadores superiores y, aunque no son infalibles, son un gran golpe.

Fanatic23
fuente
19

Me he encontrado con dos o tres en mi día. La única forma real de detectar uno es mirar el código de ensamblaje.

Aunque los compiladores son altamente confiables por razones que otros carteles han señalado, creo que la confiabilidad del compilador a menudo es una evaluación autocumplida. Los programadores tienden a ver el compilador como el estándar. Cuando algo sale mal, asumes que es tu culpa (porque el 99,999% de las veces es así) y cambias tu código para solucionar el problema del compilador en lugar de al revés. Por ejemplo, el bloqueo de código bajo una configuración de alta optimización es definitivamente un error del compilador, pero la mayoría de las personas simplemente lo configuran un poco más bajo y continúan sin informar el error.

Karl Bielefeldt
fuente
66
+1 para "ver el compilador como el estándar". Durante mucho tiempo he sostenido que hay dos cosas que realmente definen un lenguaje: el compilador y la biblioteca estándar. Un documento de estándares es solo documentación.
Mason Wheeler
8
@Mason: eso funciona bien para idiomas con una sola implementación. Para idiomas con muchos, el estándar es vital. El impacto en la vida real es que, si se queja de algo, el proveedor lo tomará en serio si se trata de un problema de estándares y lo ignorará si se trata de un comportamiento indefinido o algo así.
David Thornley
2
@Mason - Eso es solo porque muy pocos idiomas tienen un estándar y / o al cual acatan. Eso, por cierto, en mi humilde opinión, no es algo bueno: para cualquier tipo de desarrollo serio, se espera que dure más de una generación de sistema operativo.
Torre
1
@David: O más exactamente, una implementación dominante . Borland define Pascal y Microsoft define C # independientemente de lo que digan ANSI y ECMA.
dan04
44
El bloqueo de código C, C ++ o Fortran bajo una alta optimización es mucho más a menudo un código de entrada incorrecto que los errores del compilador. Muy a menudo trabajo con compiladores recientes y previos al lanzamiento, a menudo para hardware muy nuevo, y veo fallas asociadas a la optimización con bastante regularidad. Debido a que estos lenguajes tienen nociones de comportamiento indefinido y no especifican el manejo de programas no conformes, uno debe verificar los bloqueos con bastante cuidado, eventualmente contra el ensamblaje. En el 80-90% de los casos, el código de la aplicación es incorrecto y no el compilador.
Phil Miller
14

Los compiladores tienen varias propiedades que conducen a su corrección:

  • El dominio es muy conocido e investigado. El problema está bien definido y las soluciones ofrecidas están bien definidas.
  • Las pruebas automatizadas son suficientes para probar que los compiladores funcionan correctamente
  • Los compiladores tienen pruebas muy extensas, generalmente públicas, automatizadas y unitarias, que se han ido acumulando con el tiempo para cubrir más espacio de error que para la mayoría de los otros programas.
  • Los compiladores tienen una gran cantidad de globos oculares observando sus resultados
blueberryfields
fuente
2
Además, en muchos casos, el código es antiguo, GCC tiene más de 20 años, al igual que muchos de los otros, por lo que muchos de los errores se han solucionado durante un largo período de tiempo.
Zachary K
13

Usamos compiladores a diario

... y cómo hacen que los compiladores sean tan confiables?

Ellos no. Hacemos. Debido a que todos los usan todo el tiempo, los errores se encuentran rápidamente.

Es un juego de números. Debido a que los compiladores se acostumbran tan penetrante, es altamente probable que cualquier fallo se puede accionar por alguien, sino porque hay un gran número de usuarios, por ejemplo, es muy poco probable que alguien que será usted específicamente.

Entonces, depende de su punto de vista: en todos los usuarios, los compiladores tienen errores. Pero es muy probable que alguien más haya compilado una pieza de código similar antes que usted, por lo que si hubiera sido un error, los habría golpeado a usted, no a usted, por lo que desde su punto de vista individual , parece que el error fue nunca ahí.

Por supuesto, además de eso, puede agregar todas las otras respuestas aquí: los compiladores están bien investigados, bien entendidos. Existe el mito de que son difíciles de escribir, lo que significa que solo los programadores muy inteligentes y muy buenos realmente intentan escribir uno, y son muy cuidadosos cuando lo hacen. Por lo general, son fáciles de probar y fáciles de estresar o realizar pruebas de fuzz. Los usuarios del compilador tienden a ser programadores expertos, lo que genera informes de errores de alta calidad. Y al revés: los escritores de compiladores tienden a ser usuarios de su propio compilador.

Jörg W Mittag
fuente
11

Además de todas las respuestas ya, me gustaría agregar:

Creo que muchas veces, los vendedores están comiendo su propia comida para perros. Es decir, están escribiendo los compiladores en sí mismos.

DevSolo
fuente
7

Me he encontrado con errores de compilación a menudo.

Puede encontrarlos en los rincones más oscuros donde hay menos probadores. Por ejemplo, para encontrar errores en GCC, debería intentar:

  • Construye un compilador cruzado. Encontrará literalmente docenas de errores en los scripts de configuración y creación de GCC. Algunos resultan en fallas de compilación durante la compilación GCC y otros resultarán en la falla del compilador cruzado para construir ejecutables que funcionen.
  • Cree una versión de Itanium de GCC con profile-bootstrap. Las últimas veces que probé esto en GCC 4.4 y 4.5 no se pudo producir un controlador de excepciones C ++ que funcione. La construcción no optimizada funcionó bien. Nadie parecía interesado en corregir el error que informé y dejé de arreglarlo yo mismo después de tratar de investigar qué estaba rompiendo en las especificaciones de memoria de GCC asm.
  • Intente construir su propio GCJ de trabajo a partir de las últimas cosas sin seguir un script de compilación de distribución. Yo Te reto.
Zan Lynx
fuente
Encontramos muchos problemas con IA64 (Itanium). No tenemos muchos clientes para esa plataforma, por lo que reducir el nivel de optimización es nuestra corrección de errores habitual. Esto vuelve a las otras respuestas, los compiladores de idiomas populares para arquitecturas populares generalmente han tenido suficiente exposición del usuario y suficiente soporte para ser bastante buenos, pero a medida que avanza hacia las arquitecturas y / o idiomas menos populares, debe esperar que la confiabilidad se vea afectada.
Omega Centauri
@ Omega: recortar la optimización parece ser lo que todos hacen. Desafortunadamente, Itanium requiere compiladores de alta optimización para funcionar bien. Oh, bueno ...
Zan Lynx
Te escucho. Francamente, la arquitectura ya era obsoleta cuando salió, afortunadamente AMD forzó la mano de Intels con x86-64 (que desprecia sus muchas verrugas no es tan malo). Si puede dividir sus archivos de origen, es posible que pueda aislar el problema y encontrar una solución alternativa. Eso es lo que hacemos si es una plataforma importante, pero para IA64, no.
Omega Centauri
@ Omega: Desafortunadamente, realmente me gusta Itanium. Es una arquitectura maravillosa. Considero que los x86 y x86-64 son obsoletos pero, por supuesto, nunca morirán.
Zan Lynx
El x86 es un poco raro. Siguen agregando cosas nuevas, por lo que crece una verruga a la vez. Pero, el motor de ejecución fuera de orden funciona bastante bien, y el nuevo material SSE => AVX proporciona cierta capacidad real para aquellos que estén dispuestos a codificarlo. Es cierto que hay muchos transistores dedicados a hacer cosas semi-obsoletas, pero ese es un precio que uno paga por la compatibilidad heredada.
Omega Centauri
5

Muchas rasones:

  • Los escritores del compilador " comen su propia comida para perros ".
  • Los compiladores se basan en principios bien entendidos de CS.
  • Los compiladores están construidos con una especificación muy clara .
  • Los compiladores se prueban .
  • Los compiladores no siempre son muy confiables .
Kramii reinstala a Monica
fuente
4

Suelen ser muy buenos en -O0. De hecho, si sospechamos un error del compilador, comparamos -O0 versus cualquier nivel que estemos tratando de usar. Los niveles de optimización más altos conllevan un mayor riesgo. Algunos incluso lo son deliberadamente y están etiquetados como tales en la documentación. Me he encontrado con muchos (al menos cien durante mi tiempo), pero recientemente se están volviendo mucho más raros. Sin embargo, en la búsqueda de buenos números de referencia (u otros puntos de referencia importantes para el marketing), la tentación de superar los límites es grande. Hace unos años tuvimos problemas en los que un proveedor (sin nombre) decidió hacer una violación del paréntesis predeterminado, en lugar de alguna opción de compilación especial claramente etiquetada.

Puede ser difícil diagnosticar un error del compilador frente a una referencia de memoria perdida, una recompilación con diferentes opciones puede simplemente codificar el posicionamiento relativo de los objetos de datos dentro de la memoria, por lo que no sabe si es el Heisenbug de su código fuente o un buggy compilador. Además, muchas optimizaciones realizan cambios legítimos en el orden de las operaciones, o incluso simplificaciones algebraicas a su álgebra, y estas tendrán diferentes propiedades con respecto al redondeo de punto flotante y bajo / desbordamiento. Es difícil desenredar estos efectos de errores REALES. La computación de punto flotante de núcleo duro es difícil por esta razón, porque los errores y la sensibilidad numérica a menudo no son fáciles de desenredar.

Omega Centauri
fuente
4

Los errores del compilador no son tan raros. El caso más común es que un compilador informe un error en el código que debe ser aceptado, o que un compilador acepte un código que debería haber sido rechazado.

Kevin Cline
fuente
desafortunadamente no podemos ver la segunda clase de errores: el código compila = todo está bien. Entonces, probablemente la mitad de los errores (suponiendo una proporción dividida de 50-50 entre las dos clases de errores) no sean encontrados por las personas sino por medio de las pruebas de la unidad del compilador
Gianluca Ghettini
3

Sí, ayer encontré un error en el compilador ASP.NET:

Cuando utiliza modelos fuertemente tipados en las vistas, hay un límite en la cantidad de parámetros que pueden contener las plantillas. Obviamente, no puede tomar más de 4 parámetros de plantilla, por lo que ambos ejemplos a continuación hacen que sea demasiado difícil de manejar para el compilador:

ViewUserControl<System.Tuple<type1, type2, type3, type4, type5>>

No se compilaría tal cual, pero lo hará si type5se elimina.

ViewUserControl<System.Tuple<MyModel, System.Func<type1, type2, type3, type4>>>

Se compilaría si type4se elimina.

Tenga en cuenta que System.Tupletiene muchas sobrecargas y puede tomar hasta 16 parámetros (es una locura, lo sé).

usuario8685
fuente
3

¿Alguna vez has encontrado un error en el compilador? ¿Qué era y cómo te diste cuenta que el problema estaba en el compilador mismo?

¡Sip!

Los dos más memorables fueron los dos primeros que encontré. Ambos estaban en el compilador Lightspeed C para Macs 680x0 alrededor de 1985-7.

El primero fue donde, en algunas circunstancias, el operador de postincremento entero no hizo nada; en otras palabras, en un código particular, "i ++" simplemente no le hizo nada a "i". Me estaba arrancando el cabello hasta que vi un desmontaje. Luego hice el incremento de una manera diferente y envié un informe de error.

El segundo fue un poco más complicado, y fue realmente una "característica" mal considerada que salió mal. Los primeros Macs tenían un sistema complicado para realizar operaciones de disco de bajo nivel. Por alguna razón, nunca entendí, probablemente teniendo que ver con la creación de ejecutables más pequeños, en lugar de que el compilador solo generara las instrucciones de operación del disco en el lugar en el código objeto, el compilador de Lightspeed llamaría una función interna, que en tiempo de ejecución generó la operación del disco instrucciones en la pila y saltó allí.

Eso funcionó muy bien en las CPU 68000, pero cuando ejecutaba el mismo código en una CPU 68020, a menudo hacía cosas raras. Resultó que una nueva característica del 68020 era una caché de instrucciones de 256 bytes de instrucciones primitivas. Al ser los primeros días con los cachés de la CPU, no tenía la noción de que el caché estuviera "sucio" y necesitara ser rellenado; Supongo que los diseñadores de CPU de Motorola no pensaron en el código auto modificable. Entonces, si realizó dos operaciones de disco lo suficientemente juntas en su secuencia de ejecución, y el tiempo de ejecución de Lightspeed construyó las instrucciones reales en la misma ubicación en la pila, la CPU pensaría erróneamente que tuvo un golpe de caché de instrucciones y ejecutaría la primera operación de disco dos veces.

Una vez más, descubrir eso requirió un poco de trabajo con un desensamblador y muchos pasos en un depurador de bajo nivel. Mi solución era prefijar cada operación de disco con una llamada a una función que hizo 256 instrucciones "NOP", que inundaron (y borraron) el caché de instrucciones.

En los últimos 25 años desde entonces, he visto cada vez menos errores de compilación con el tiempo. Creo que hay un par de razones para eso:

  • Hay un conjunto cada vez mayor de pruebas de validación para compiladores.
  • Los compiladores modernos generalmente se dividen en dos o más partes, una de las cuales genera código independiente de la plataforma (por ejemplo, LLVM apunta a lo que podría considerarse una CPU imaginaria) y otra que lo traduce en instrucciones para su hardware de destino real. En los compiladores multiplataforma, la primera parte se usa en todas partes, por lo que recibe toneladas de pruebas en el mundo real.
Bob Murphy
fuente
Una de las razones para evitar el código auto modificable.
Technophile
3

Encontró un error evidente en Turbo Pascal hace 5,5 años. Un error presente en la versión anterior (5.0) ni en la siguiente (6.0) del compilador. Y uno que debería haber sido fácil de probar, ya que no se trataba de una caja de esquina (solo una llamada que no se usa con tanta frecuencia).

En general, ciertamente los creadores de compiladores comerciales (en lugar de proyectos de pasatiempo) tendrán procedimientos de prueba y control de calidad muy extensos. Saben que sus compiladores son sus proyectos emblemáticos y que las fallas se verán muy mal en ellos, peor de lo que se verían en otras compañías que fabrican la mayoría de los otros productos. Los desarrolladores de software son un grupo implacable, nuestros proveedores de herramientas nos decepcionan, es probable que busquemos alternativas en lugar de esperar una solución del proveedor, y es muy probable que comuniquemos ese hecho a nuestros pares que bien podrían seguir nuestro ejemplo. En muchas otras industrias ese no es el caso, por lo que la pérdida potencial para un fabricante de compiladores como resultado de un error grave es mucho mayor que eso para decir un fabricante de software de edición de video.

jwenting
fuente
2

Cuando el comportamiento de su software es diferente cuando se compila con -O0 y con -O2, entonces ha encontrado un error de compilación.

Cuando el comportamiento de su software es diferente de lo que espera, es probable que el error esté en su código.

Mouviciel
fuente
8
No necesariamente. En C y C ++, hay una cantidad molesta de comportamiento no especificado e indefinido, y eso puede variar legítimamente según el nivel de optimización o la fase de la luna o el movimiento de los índices de Dow Jones. Esa prueba funciona en lenguajes más definidos.
David Thornley
2

Los errores del compilador ocurren, pero tiendes a encontrarlos en rincones extraños ...

Hubo un error extraño en el compilador VAX VMS C de Digital Equipment Corporation en la década de 1990

(Llevaba una cebolla en mi cinturón, como era la moda en ese momento)

Un punto y coma extraño en cualquier lugar anterior a un bucle for se compilaría como el cuerpo del bucle for.

f(){...}
;
g(){...}

void test(){
  int i;
  for ( i=0; i < 10; i++){
     puts("hello");
  }
}

En el compilador en cuestión, el bucle se ejecuta solo una vez.

ve

f(){...}
g(){...}

void test(){
  int i;
  for ( i=0; i < 10; i++) ;  /* empty statement for fun */

  {
     puts("hello");
  }
}

Eso me costó mucho tiempo.

La versión anterior del compilador PIC C que (solíamos) infligir a los estudiantes con experiencia laboral no podía generar código que usara la interrupción de alta prioridad correctamente. Tuviste que esperar 2-3 años y actualizar.

El compilador MSVC 6 tenía un error ingenioso en el enlazador, fallaba en la segmentación y moría de vez en cuando sin ninguna razón. Una construcción limpia generalmente lo solucionó (pero no siempre suspira ).

Tim Williscroft
fuente
2

En algunos dominios, como el software de aviónica, existen requisitos de certificación extremadamente altos, tanto en el código y el hardware, como en el compilador. Acerca de esta última parte, hay un proyecto que tiene como objetivo crear un compilador de C verificado formalmente, llamado Compcert . En teoría, este tipo de compilador es tan confiable como parece.

Axel
fuente
1

He visto varios errores del compilador, reporté algunos yo mismo (específicamente, en F #).

Dicho esto, creo que los errores de compilación son raros porque las personas que escriben compiladores generalmente se sienten muy cómodos con los conceptos rigurosos de la informática que los hacen realmente conscientes de las implicaciones matemáticas del código.

Presumiblemente, la mayoría de ellos están muy familiarizados con cosas como el cálculo lambda, la verificación formal, la semántica denotacional, etc., cosas que un programador promedio como yo apenas puede comprender.

Además, generalmente hay una asignación bastante directa de entrada a salida en compiladores, por lo que depurar un lenguaje de programación es probablemente mucho más fácil que depurar, por ejemplo, un motor de blog.

Rei Miyasaka
fuente
1

Encontré un error en el compilador de C # no hace mucho tiempo, puedes ver cómo Eric Lippert (que está en el equipo de diseño de C #) descubrió cuál era el error aquí .

Además de las respuestas ya dadas, me gustaría agregar algunas cosas más. Los diseñadores de compiladores suelen ser muy buenos programadores. Los compiladores son muy importantes: la mayoría de la programación se realiza utilizando compiladores, por lo que es imperativo que el compilador sea de alta calidad. Por lo tanto, lo mejor para las empresas es hacer compiladores para poner a sus mejores personas en él (o al menos, muy buenos: a los mejores no les gustará el diseño de compiladores). A Microsoft le gustaría mucho que sus compiladores C y C ++ funcionen correctamente, o el resto de la compañía no puede hacer su trabajo.

Además, si está creando un compilador realmente complejo, no puede simplemente hackearlo. La lógica detrás de los compiladores es altamente compleja y fácil de formalizar. Por lo tanto, estos programas a menudo se construirán de una manera muy 'robusta' y genérica, lo que tiende a generar menos errores.

Alex ten Brink
fuente