Una entrevista con Brian Kernighan por Mihai Budiu
Julio 2000

1. Introducción
2. Sobre la traducción
3. La entrevista

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top]

[Contents]

[Index]

[ ? ]

1. Introducción

Durante el verano de 1999 tuve la oportunidad de trabajar como investigador interno en los Laboratorios Bell, el brazo investigativo de Lucent Technologies. Me atreví entonces a pedirles un autógrafo a Dennis Ritchie y Brian Kernighan sobre su libro de C.

En el verano de 2000 volví a los Laboratorios Bell para un periodo de investigación. En esta ocasión, valientemente me aventuré a pedirle una entrevista a Brian Kernighan para la revista de computación Rumana PC Report Romania, en la que trabajo como editor asistente. Él muy gentilmente me respondió:

    Date: Mon, 10 Jul 2000 14:52:15 -0400
    To: mihaib@research.bell-labs.com
    From: "Brian Kernighan"
    Subject: re: odd request
    
    sure, no problem.  i'm probably pretty boring, but since
    i don't read romanian, you can make things up...
    
    come by any time; i'm mostly around.
    
    brian

---

    Date: Mon, 10 Jul 2000 14:52:15 -0400
    To: mihaib@research.bell-labs.com
    From: "Brian Kernighan"
    Subject: re: solicitud extraña
    
    claro, no hay problema. soy quizás bastante aburrido, pero
    ya que no leo rumano, puedes inventar cosas...

    ven en cualquier momento; por lo general me encuentro
    por aquí.
  
    brian

La entrevista apareció en la edición de Agosto de la revista en Rumano. Sin embargo, he reconocido que las opiniones del Sr. Kernighan pueden constituir una lectura muy interesante para una audiencia angloparlante también, así que decidí revelarla (con su aprobación) también en Inglés. Aquí está; ¡disfrute! A propósito: ¡nada es inventado!

2. Sobre la traducción

Este documento fue traducido a partir del original en Inglés, tomado de http://www-2.cs.cmu.edu/~mihaib/kernighan-interview/index.html

Entrevista realizada en Julio de 2000.

Los comentarios y correcciones sobre esta traducción son bienvenidos. -- Leonardo Boshell

Updated: Thu 17 Jul 2003, 11:37.

3. La entrevista

Mihai:

¿Cuál es la forma correcta de pronunciar su nombre? He escuchado que no es en la forma obvia.

Kernighan:

Se pronuncia Kernihan, la `g' es muda.

Mihai:

Usted eligió trabajar en ciencias de la computación cuando esta no era una opción de carrera obvia. ¿Puede hablarnos sobre cómo tomó esta decisión y qué piensa sobre ella en retrospectiva?

Kernighan:

Es verdad que inicié trabajando con computadoras probablemente entre mediados y finales de los sesenta, cuando las cosas eran en realidad prematuras, y fue completamente por accidente. Creo que ví mi primer computadora en 1963; era una vieja IBM 650. No practiqué la programación seriamente hasta 1964 cuando estaba en mi último año de universidad. Pero fue divertido, y fue antes de que las ciencias de computación fueran de alguna forma un campo. Cuando fui a hacer una especialización existía un programa de Ciencias de la Computación en el Departamento de Ingeniería Eléctrica en Princeton. Esto era considerablemente típico en muchos lugares: las ciencias de computación no eran un campo académico por separado, eran sólo parte de algún departamento que pudiera tener una máquina o personas interesadas en la computación, así que entré en eso, puramente por accidente. Ha sido un accidente afortunado, porque obviamente en el campo han ocurrido muchas cosas interesantes.

Mihai:

Ha estado en este campo por un largo rato, y ha sido un importante protagonista en la evolución de la ciencia computacional. Parte de su trabajo ha tenido un profundo impacto. ¿Puede señalar algunas cosas que considere que sean avances fundamentales en la ciencia computacional en los últimos 30 años, algunos cambios de paradigma que hayan ocurrido?

Kernighan:

Pienso que ha habido un número considerable de cambios, no necesariamente en "ciencia computacional", sino en la computación en general. Obviamente el hecho de que el hardware se haya vuelto enormemente más rápido: la ley de Moore, aunque se trata sólo de un cambio cuantitativo, su crecimiento exponencial aplicado durante 30 años hace una diferencia enorme; algo de eso se debe a la ciencia computacional, pero no mucho. Al mismo tiempo, algo con lo que me encuentro más familiriazado, y más interesado técnicamente, es el uso de varios tipos de lenguajes de programación, de forma que somos capaces de expresarle a una máquina de una mejor forma lo que queremos hacer. El crecimiento de los lenguajes, de la tecnología para entender cómo expresarle cosas a una máquina, ha tenido un impacto enorme también. Por supuesto, en la medida en que las máquinas se han hecho más poderosas, usted se puede dar el lujo de invertir más recursos y utilizar lenguajes que no eran eficientes hace 25 o 30 años pero que ahora son utilizables. Otros cambios importantes son las mejoras algorítmicas, las cuales hacen realmente parte de la ciencia computacional; también la idea de la perfección-NP, la cual nos permite pensar sobre lo que es sencillo y lo que es difícil. Pero en lo que me concierne, aquello que encuentro más interesante es el crecimiento de los lenguajes de programación.

Mihai:

A lo largo de los años ha trabajado usted en varias áreas diferentes: algortimos gráficos, ingeniería de software y herramientas de software, tipografía digital, pero la mayor parte de su investigación ha sido en lenguajes de programación. ¿Cuáles son sus intereses actuales en investigación?

Kernighan:

[riendo] Es interesante, lo que he estado haciendo en el último par de días es una labor de hackeo(1) de vuelta casi a mis primeras raíces en la preparación de documentos computarizados, o tipografía digital si así lo desea. He estado trabajando en tomar `eqn', el cual es un programa que Lorinda Cherry y yo escribimos en 1974, y convertirlo para que produzca su salida en XML o HTML, de modo que podamos colocar términos matemáticos de forma más simple en páginas web. Hay muchas personas que han realizado varios intentos en esto, pero ninguno de ellos parece ser muy bueno o al menos estar listo para su uso aun. Tenemos una necesidad local por esa aplicación, así que me siento y trabajo en ello, un programa de C que escribí literalmente hace más de 25 años. Es un programa pequeño en C, y me estoy divirtiendo bastante tratando de arreglarlo. Eso es parte de lo que hago en el momento, algo muy pequeño, pero es divertido en cierta forma volver a tomar y reconstruir algo en lo que dediqué mi tiempo hace tantos años.

Lo otro en lo que estoy trabajando es en un lenguaje llamado AMPL el cual hicimos David Gay, Bob Fourer y yo; AMPL es un lenguaje para especificar problemas de optimización, para declarar cosas como problemas de programación lineares. Estamos intentando encapsularlo de modo que pueda ser usado como parte de procesos mayores. Estamos colocándole una interfaz orientada a objetos, de modo que pueda incrustarse en medio de otros programas o usado como un objeto COM u ORBA.

Esas son dos cosas que estoy haciendo en el momento.

Mihai:

Hablando de lenguajes de programación, ¿aun compila el programa `eqn'?

Kernighan:

Si, aun compilaba, no lo había hecho probablemente por cinco o diez años y compiló sin ningún problema. Es un programa de C simple y pequeño; probablemente lo convertí a ANSI C a finales de los '80s. Lo que he estado haciendo es más que todo desechar cosas porque el lenguaje de salida es ahora más simple que antes.

Mihai:

La mayoría de la gente quizás lo conozca a causa del libro de C(2), así que permítame formularle un par de preguntas sobre el lenguaje C. Ciertamente C ha tenido una influencia muy profunda; ¿cuáles considera que son las características más importantes del lenguaje C?

Kernighan:

C es el mejor balance que he visto entre poder y expresividad. Usted puede hacer casi cualquier cosa que desee programándolo de forma considerablemente directa y tendrá un muy buen modelo mental sobre lo que pasará en la máquina; puede predecir razonablemente bien qué tan rápido se va a ejecutar, entiende qué está pasando y le da una completa libertad para hacer lo que desee. C no coloca obstáculos en su camino, no lo obliga a utilizar un estilo de programación particular; por otra parte, no provee muchas facilidades, no tiene una librería enorme, pero en términos de conseguir algo hecho sin mucho esfuerzo, no he visto nada hasta el día de hoy que me guste más. Existen otros lenguajes que son convenientes para cierto tipo de aplicaciones, pero si estuviera abandonado en una isla desierta con sólo un compilador, querría un compilador de C.

Mihai:

De hecho C es también mi lenguaje de programación favorito, y he escrito varios programas en él, pero desde que comencé a escribir compiladores para C, debo confesar que he empezado a quererlo menos. Algunas cosas son muy difíciles de optimizar. ¿Podría hablarnos sobre las peores características de C, desde su punto de vista?

Kernighan:

No puedo comentar sobre lo `peor', pero recuerde, C es enteramente el trabajo de Dennis Ritchie, yo no soy más que un popularizador y en particular no puedo decir qué es mas fácil o mas difícil de compilar en C. Hay algunas cosas triviales que están mal en C: la declaración `switch' pudo haberse diseñado mejor, la precedencia de algunos operadores es incorrecta, pero esas son cosas menores y todo el mundo ha aprendido a vivir con ellas. Creo que el verdadero problema con C es que no le da a usted suficientes mecanismos para estructurar problemas realmente grandes, para crear `muros' dentro de los programas de modo que se puedan mantener separadas varias partes. No es que no se puedan hacer todas esas cosas, que no se pueda simular programación orientada a objetos u otra metodología que desee en C. Lo puede simular, pero el compilador, el lenguaje mismo no le ofrece ninguna ayuda. Pero considerando que este es un lenguaje que tiene casi 30 años de edad ahora y fue creado cuando las máquinas eran minúsculas comparadas con las que existen ahora, es un trabajo realmente espléndido y ha pasado la prueba del tiempo extremadamente bien. No hay mucho que yo quisiera cambiar.

Es cierto que algunas veces escribo C++ en lugar de C. Pienso que C++ es básicamente un lenguaje demasiado grande, aunque hay una razón para casi todo lo que incluye. Cuando escribo un programa en C de cualquier tamaño, probablemente termine haciendo uso de un 75, 80 o 90% de las características del lenguaje. En otras palabras, la mayor parte del lenguaje es útil en casi cualquier programa. En contraste, si escribo en C++ probablemente no use siquiera el 10% del lenguaje, y de hecho el otro 90% es algo que no creo entender. En ese sentido yo argumentaría que C++ es demasiado grande, pero es cierto que C++ le ofrece muchas de las cosas que necesita para escribir programas grandes: realmente le hace posible crear objetos para proteger la representación interna de la información, de modo que presente una agradable fachada y no se pueda ver detrás de ella. C++ tiene una enorme cantidad de mecanismos que considero muy útiles, y que C no ofrece.

Mihai:

Tengo una pregunta sobre investigación en el diseño de lenguajes. Es interesante ver cómo Java provoca bastante excitación y la comunidad se divide en argumentos respecto a los méritos y fallas del lenguaje. El lenguaje ciertamente ha adquirido algunas características interesantes propuestas por investigadores en el área (como la recolección de basura), pero también los investigadores señalan algunas de sus debilidades (como los arreglos que son covariantes y no deberían serlo). En estos días hay todo un bloque de investigación creado en lenguajes de programación, y un cuerpo de investigación muy interesante en lenguajes de programación funcionales, pero usted no ve que esta investigación tenga una influencia real en el mundo, es decir, en lo que la gente realmente usa dia a dia. En lugar de eso aparecen todo tipo de lenguajes intermedios como Perl o Python o cosas por el estilo. ¿Dónde ve usted la falla; qué es lo que no está bien?

Kernighan:

Esa es desafortunadamente una muy buena pregunta, y existe una cierta cantidad de discusión aquí en los laboratorios Bell entre un grupo muy fuerte en lenguajes de programación funcionales y un grupo usando lenguajes muy ad-hoc, pragmáticos. Honestamente no se porqué los lenguajes funcionales no tienen éxito. Por ejemplo ML, del cual se puede decir que es la mejor combinación, quizás el elegido que debía tener éxito: a pesar de ser un lenguaje muy bien diseñado, bastante pensado por muchas personas de calidad por un largo tiempo, incluyendo una enorme cantidad de esfuerzo en tecnología de compilación, aun no parece ser usado ampliamente. Voy a hacer una gran simplificación, y probablemente ofenderé a mis amigos, diciendo que lo único que la gente hace con ML es crear compiladores de ML. [riendo] Exagero intencionalmente, pero la situación es un poco por ese estilo, y realmente no entiendo porqué. Creo, y hablo sólo por mi, que parte de la razón por la que ML en particular, y los lenguajes de programación funcionales en general no han impactado más globalmente, es que están dirigidos a personas que tienen sofisticación matemática, que son capaces de pensar en formas más abstractas, con las que muchas otras personas, entre las que me incluyo, tenemos problemas. En vista de que lenguajes como C son bastante operacionales, usted puede ver cómo cada parte de ellos se relaciona con lo que sucede en la máquina en un sentido muy, muy directo. Si yo hubiera aparecido en un momento diferente en el tiempo y en un entorno diferente quizás estaría completamente cómodo con ML y encontraría C inseguro, un poco peligroso, no muy expresivo. Pero mi apreciación es que los lenguajes funcionales provienen de una comunidad considerablemente matemática y requieren una línea de razonamiento bien matemática y por esto son difíciles para la gente allí fuera.

Mihai:

Así que supongo, ¿la recomendación para los investigadores es que de alguna forma hagan el nivel del lenguaje más bajo, para promover las buenas cualidades?

Kernighan:

En realidad no contesté la otra parte de su pregunta, sobre porqué la investigación en lenguajes no ha tenido tanto efecto como podría. Pienso que de hecho sí ha habido un efecto, en sitios como la tecnología de analizadores sintácticos, la generación de código; el lenguaje es irrelevante: la investigación ha tenido un gran efecto en la construcción de herramientas de lenguaje, pero menos en el diseño de lenguajes como tal.

Los lenguajes que han tenido éxito son bastante pragmáticos, y con frecuencia son poco elegantes porque tratan de resolver problemas reales. C++ es un excelente ejemplo de un lenguaje que en muchos sentidos padece de serias fallas. Una de las fallas es que se esforzó mucho en ser compatible con C: compatible al nivel de objetos, compatible de forma muy cercana en el nivel de código fuente. Por esta razón existen lugares en donde existe algo desagradable en el lenguaje, extraños problemas sintácticos, comportamientos semánticos irregulares. En cierto sentido esto es malo, y nadie debería hacer algo semejante, pero una de las razones por las que C++ triunfó fue precisamente que era compatible con C, era capaz de usar las librerías de C, era utilizable para la base existente de programadores de C, y por lo tanto las personas podían apoyarse en él y usarlo de modo considerablemente efectivo sin tener que apegarse a un modo completamente nuevo de hacer las cosas. Y ese no es el caso de ML, el cual estaba siendo creado en el mismo periodo de tiempo y, al menos en parte, en casi el mismo lugar, pero que adoptó una vista del mundo completamente distinta. Como algo pragmático, C++ es extremadamente exitoso pero tuvo que pagar cierto precio por ser compatible con un lenguaje previo.

Mihai:

Así que usted es entonces un partidario de la evolución incremental.

Veo que es usted autor de cerca de ocho libros, todos ellos en colaboración con otros autores. ¿Quiere decir esto que usted tiene un estilo de investigación colaborativo?

Kernighan:

Si se va a escribir un libro, resulta muchísimo más fácil conseguir a alguien que haga gran parte del trabajo [riendo]. He sido muy afortunado al haber tenido excelentes colaboradores en todos esos libros y en ese sentido el trabajo resulta tremendamente simple. Es más fácil completar algo como un libro, que requiere entre seis meses y un año de trabajo, si cuenta con alguien más que esté trabajando en él con usted. También es un modo de chequear la integridad del trabajo, ayudándole a uno a cerciorarse de que no se está concentrando demasiado en una dirección en particular: se tiene a alguien más tirando de la dirección hacia donde él cree que es la dirección correcta.

Creo que todo lo que hecho, lo he hecho con alguien más: es más divertido trabajar con alguien que encerrarse en una oficina y hacerlo todo uno mismo. Y pienso que probablemente me va mejor escuchando y encontrando a alguien que tenga una buena idea para luego trabajar con esa persona en las buenas ideas, que tratar de inventar una por mi cuenta.

Mihai:

Hablando de chequeos de integridad, en este momento estoy trabajando en un proyecto que involucra la manipulación de una extensa base de código; algunas funciones deben ser editadas por varias personas: ellos constantemente cambian el estilo de sangrado y los identificadores del código. Usted ha publicado algunos libros que hablan sobre el estilo de escritura del código: ¿su estilo personal siempre coincide con el estilo de su co-autor, o tienen problemas conciliando el tema?

Kernighan:

[riendo] Esa es una buena pregunta también. Ocasionalmente he tenido, "problemas" no es el término apropiado, pero con los co-autores han habido discusiones sobre dónde colocar los corchetes, dónde colocar los espacios y cómo escribir los nombres de diferentes identificadores. Muchas de estas cosas han sido bastante triviales, en parte debido a que mis co-autores han estado en este entorno y hemos crecido en el mismo tipo de fondo cultural. Pero por ejemplo cuando Rob Pike y yo estábamos trabajando en "The Practice of Programming" (3) hace un par de años, tuvimos discusiones bastante intensas sobre cosas triviales como ¿dónde colocamos los espacios?, ¿cuántos espacios colocar? Personalmente me gusta colocar espacios después de cosas como if, while y for y a Rob no. Yo vencí en esa parte de la batalla, pero hubo otra parte en la que perdí, ya ni siquiera recuerdo cuál era. Definitivamente no coincidimos 100%, pero llegamos a un acuerdo amistoso en cuanto a todo el asunto.

En la medida en que hayan más personas trabajando en algo y el programa sea más grande, el proceso será más difícil, y en algún punto habrá que existir un conjunto de estándares concertados a los que todos se sometan, y herramientas mecanizadas como pretty-printers(4) que los impongan mediante reglas, porque de otra manera se perderá mucho tiempo y existe un riesgo real de cometer errores.

Mihai:

Acaba de hablar de pretty-printers; ¿qué otras herramientas y entornos de programación recomienda?

Kernighan:

Cuando tengo la opción de elegir, todavía realizo toda mi programación en Unix. Utilizo el editor de Rob Pike sam, no uso Emacs. Cuando no puedo usar sam, utilizo vi por razones históricas, y aun me siento bastante cómodo con ed [riendo]; lo sé, eso es de cuando ustedes jóvenes ni siquiera habían nacido. Y en parte es una cuestión de historia: yo conocí a Bill Joy cuando él estaba trabajando en vi.

No utilizo depuradores sofisticados, utilizo sentencias print y no utilizo un depurador para nada más que obtener eventualmente un rastreo de pila cuando un programa falla inesperadamente. Cuando escribo código en windows utilizo por lo general el entorno de desarrollo de microsoft: éste sabe dónde se encuentran todos los archivos, y cómo obtener todos los archivos para inclusión y por el estilo, y lo uso, aun cuando en muchos aspectos no satisface mi modo de hacer las cosas. También utilizo las buenas herramientas de antaño de Unix; cuando trabajo sobre windows generalmente importo cosas como el conjunto de herramientas mks y tengo programas estándar a los que estoy acostumbrado para la búsqueda de cosas y comparaciones y cosas así.

Mihai:

Cambiaré de tema una vez más. Cuando vine a los Estados Unidos me encontré sorprendido al descubrir que existe investigación de muy buena calidad y también investigación básica -- investigación que no está necesariamente orientada a la creación de un producto o crear dinero -- tal tipo de investigación no solo se lleva a cabo en las universidades, sino también en algunas empresas grandes. ¿Qué puede decirnos acerca de la investigación en Lucent, una empresa de gran tamaño, la cual solía ser parte de AT&T, una empresa aun mayor?

Kernighan:

Le daré la visión oficial de la empresa al respecto, aunque pienso que todavía mucho de ella es válido aun. La investigación ha sido parte de esta empresa cuando era llamada "El Sistema Bell", AT&T, o Lucent, por un largo tiempo: los laboratorios Bell tuvieron su aniversario número 75 este año. Creo que la investigación inició como un reconocimiento del hecho de que existían ciertas cosas que la gente no sabía cómo hacer pero tenían que averiguar el modo de lograrlas si querían mejorar el producto o servicio que iban a ofrecer. Por supuesto, en tiempos de antaño, se trataba del servicio telefónico; hace 30 o 40 años la tecnología del teléfono comenzó a ganar un componente computacional significativo y eso nos lleva a la investigación en ciencias de computación aquí. Pienso que el mismo tipo de cosas han sido válidas en empresas como IBM, la cual administra laboratorios de investigación muy efectivos también; esa es ciertamente otra compañía que ha tenido una larga tradición apoyando el entorno investigativo.

Existe la interesante cuestión de "cómo justifica una empresa el dinero que emplea en investigación". Lucent en este momento tiene 150,000 empleados más o menos; la parte de ella que es investigación, parte que nos incluye a usted y a mí, es algo como menos del 1% de eso, quizás son unas 1000 o 1500 personas. Las ganancias anuales de la empresa fueron 38 billones de dólares en 1999, de modo que estamos empleando cerca de 400 millones de dólares anualmente en investigación para mantenernos a nosotros dos sentados en oficinas cómodas, pensando en cosas importantes. De hecho, esa parece una forma muy razonable de invertir una parte de sus bienes, los cuales se colocan en un modelo de alto-riesgo pero potencialmente de alta-gratificación. Usted debe estar pensando "¿dónde estaremos de aquí a unos años?", qué tipo de problemas tenemos ahora, a los que tenemos que encontrarles algún tipo de solución, que no necesitamos de momento; sería bueno si tuviéramos esas soluciones ahora, pero sabemos que las necesitaremos realmente en el futuro. Desafortunadamente es muy difícil hallar el modo de hacer estas cosas, a veces incluso lograr definir cuáles son los problemas correctos. Creo que el mejor mecanismo que alguien haya encontrado jamás es tomar una pequeña cantidad de dinero, digamos un 1%, y contratar un montón de gente brillante, y ponerlos en un entorno en el que se sientan alentados a comunicarse entre ellos, a comunicarse con el resto de gente de la empresa, a encontrar qué tipo de problemas tiene el resto de gente de la empresa; las personas en el resto de la empresa son animadas también a llegar y decir "¿pueden ayudarnos con este problema que tenemos?", y la esperanza que se tiene es que por un proceso casi aleatorio, que ciertamente es en muchas formas aleatorio...

Mihai:

[interrumpiendo] Pero no solo eso; usted encuentra investigación y desarrollo en muchas otras empresas; ¡en los laboratorios Bell también se le anima a publicar!

Kernighan:

... pienso que la pregunta es "¿en qué modo es distinta esta compañía de otras, dado el hecho de que nosotros publicamos?". Hay muchas cosas que pueden observarse aquí. Una es que la escala es mucho mayor; los laboratorios Lucent Bell pueden ser aun los laboratorios de investigación industrial más grandes del mundo, realizando investigación del tipo que encontraría en las universidades en el pasado, escencialmente investigación no dirigida, no centrada en los productos inmediatos. IBM al menos se le puede comparar, y Xerox en cierta medida, y hay otras empresas por el estilo. Uno de los asuntos es que la investigación aquí, al menos en el grupo de ciencias de computación, y en todas las ciencias físicas, se encuentra en el medio de los entornos puramente industrial, en donde básicamente hacen investigación que es fuertemente influenciada en un producto, y el académico, en donde básicamente se hacen cosas por curiosidad o para profundizar. Un laboratorio industrial de gran tamaño debe extenderse para cubrir los dos campos: tiene un foco mayor en las cosas que pueden ser prácticas, pero al mismo tiempo tiene un dedo sobre el mundo académico, tiene conexiones con el mundo académico. Y tiene que hacerlo, porque, entre otras cosas, ese es el mecanismo de reclutamiento: la razón por la que usted está aquí en lugar de Cisco, digamos, es que Cisco no realiza investigación; Cisco compra empresas. No es que Cisco sea un mal lugar, Cisco es un grandioso lugar en muchos sentidos, pero hace sus negocios en modo distinto a Lucent.

Otra cosa más que hacemos al jugar tanto en el mundo académico como en el desarrollo industrial es que somos capaces de interactuar con gente de universidades como colegas iguales, y por lo tanto podemos arrastrar a personas como usted, que vienen a trabajar con nosotros en el verano, y quizás vuelvan de modo permanente. En esta manera, recibimos un flujo constante de gente buena. Pero para hacer eso se necesita colocar algo de vuelta al sistema. Debemos dejarle entrar, debemos mostrarle todas las cosas interesantes, y debemos permitirle que escriba trabajos, y nosotros debemos asi mismo escribir trabajos, porque de otra manera la gente no creería que hacemos nada interesante. Así que tenemos que ser miembros ampliamente participativos de la comunidad científica o académica al mismo tiempo que estar contribuyendo al bien de la compañía. Ese es un problema interesante y no resuelto, cómo hacer ambas cosas y evitar involucrarse demasiado en uno u otro campo.

Mihai:

Ha mencionado a Rob Pike; ha escrito dos libros con él; me gustaría hacer una pregunta sobre una charla controversial que él realizó, en la que argumenta que la investigación en las ciencias de computación está prácticamente muerta: ¿Qué opina de este pronunciamiento?

Kernighan:

Siendo justos, Rob casi siempre tiene razón, aunque no se lo diría en la cara [risas]. Yo sólo leí las diapositivas de esa charla hasta hace poco, no estuve presente en ella, pero creo que en muchos sentidos él tiene razón. Su observación es que es difícil hacer trabajo de sistemas: la escala de las cosas es muy grande para los entornos académicos algunas veces, los mecanismos de recompensa en los entornos académicos pueden estar equivocados. Como resultado, mucho de lo que sucede en el trabajo de sistemas reales tiende a ser incremental, evaluación de rendimiento en lugar de sintetizar combinaciones interesantes nuevas. No sé porqué es ese el caso: puede que sea difícil obtener un apoyo apropiado en un ambiente académico, puede que tome demasiado tiempo -- el punto de Rob es que los sistemas reales toman cinco años o más, y esa es a duras penas la duración de los estudios de grado -- de modo que es difícil obtener algo que se acople a la carrera de un estudiante. Yo no diría que la investigación en sistemas está "muerta", pero ciertamente no está tan viva como podría.

Mihai:

Hablando de la academia, he notado que usted ha dictado al menos dos clases en Princeton. Quisiera preguntarle acerca de su opinión sobre la educación en ciencias de computación, ya que he escuchado quejas provenientes de la industria, que dicen que los estudiantes de pregrado en ciencias de computación dominan demasiadas habilidades teóricas inútiles y que no conocen mucho sobre programas de desarrollo reales.

Kernighan:

He dictado cuatro cursos en Princeton y Harvard en los últimos cuatro o cinco años, en varios niveles, pero eso no es suficiente para describirme como "experto" en la educación de ciencias de computación. Esas son dos universidades muy particulares y lo que he enseñado han sido cosas bastante básicas. No creo que las universidades deban estar en el plan de enseñar cosas que pueden aprenderse en una escuela técnica; no creo que sea el rol de una universidad el de enseñarle a las personas a usar, digamos, Visual C++ y su Entorno de Desarrollo Integrado. Pienso que el rol de la universidad es enseñarle a sus estudiantes cómo programar bajo una implementación particular de un lenguaje que tiene por ejemplo una naturaleza de orientación a objetos, ayudarle a los estudiantes a entender las características y diferencias que se involucran en familias de lenguajes, como C, C++ y Java, y cómo estos se relacionan con lenguajes que tienen una postura diferente, como los lenguajes funcionales. Enseñarle a los estudiantes habilidades específicas para que puedan ir de inmediato a una tienda de desarrollo en windows y sean capaces de escribir programas COM no está bien.. Eso no es lo que deberían estar haciendo las universidades; las universidades deberían estar ensañando cosas que tienen un considerable chance de perdurar, por toda una vida si se tiene suerte, pero al menos por 5 o 10 o 20 años, y eso quiere decir principios e ideas. Al mismo tiempo, deberían estar ilustrándoles con los mejores ejemplos posibles tomados de prácticas actuales.

Dicté en Princeton un curso de nivel básico, una combinación de ingeniería de software y programación avanzada: los estudiantes allí, al menos los más avanzados de la clase, tenían bastante experiencia en el tipo de cosas que la industria probablemente busca. Ellos estaban familiarizados con Visual C++, sabían cómo obtener componentes de la red y reunirlos, y podían escribir aplicaciones en Java de una considerable sofisticación. Mucho de eso pudo haberse aprendido mediante empleos de verano. Si la industria desea personas que tengan más que conocimiento teórico "inútil" [risas], lo que debería estar haciendo es asegurarse de acaparar a estos chicos brillantes de las universidades y darles trabajos de verano interesantes que pongan en práctica las ideas teóricas y los conocimientos generales con los detalles específicos de una aplicación en particular. La gente aprende ese tipo de cosas remarcablemente rápido y si hacen cosas interesantes en trabajos de verano, entonces traen eso de vuelta a sus carreras académicas. Me impresionó bastante lo mucho que sabían los estudiantes, cosas que no habían aprendido en clase.

Mihai:

Hablando de estudiantes, ¿qué consejo podría darle a un estudiante de ciencias de computación que desea seguir una ruta de investigación? ¿Quizás usted percibe algunas áreas que pueden ser más gratificantes que otras, y quizás otras áreas que ya no son interesantes?

Kernighan:

Pues, no sigan mis recomendaciones sobre carreras [risas]. Desafortunadamente, no pienso que exista algún consejo remarcable. Lo interesante, perdón, no debería decir "interesante" -- las áreas que son difíciles son solo dos: una es que es muy difícil escribir programas que funcionen, y la otra es que es muy difícil usar las computadoras. Así que si quiere algo en qué trabajar, este es un par de cosas que puede intentar. Por supuesto, puestas de un modo muy general [risas], hay muchos casos especiales con los que se puede jugar. Si logra algún progreso en absoluto, en cualquier respecto, entonces tiene una oportunidad de ir y perseguir el lado puramente académico del asunto o alternativamente puede tratar de crear fortuna con una iniciativa propia. Y en este punto pareciera que muchas personas prefieren ir a crear fortunas con sus iniciativas, que dedicar 5 o 6 años a obteren un Ph.D. Quizás usted está desorientado [risas]... Pienso que por desgracia el mejor consejo que se le puede dar a alguien es "haga lo que crea que es interesante, haga algo que usted considere divertido y valioso, porque de otra forma no hará nada correctamente después de todo". Pero eso no es ninguna ayuda en verdad.

Mihai:

Quizás pueda ayudarme siendo un poco más concreto: ¿podría recomendarnos algunos libros, sobre ciencias de computación u otros, que piense que han tenido una gran influencia en usted?

Kernighan:

El único libro de ciencia computacional que he leido más de una vez, que de hecho retomo cada ciertos años y del que vuelvo a leer algunas partes de nuevo, es The Mythical Man-Month por Fred Brooks, un excelente libro. Por una parte está muy bien escrito y por otro lado las recomendaciones que incluye, aun después de más de 25 años, son todavía muy relevantes. Por supuesto hay detalles que son diferentes, algunas cosas las enfrentamos de manera distinta debido a que tenemos más mecanización y más potencia computacional, pero hay una enorme cantidad de buenos juicios en él, de modo que lo recomiendo altamente. Ese es el único libro de ciencia computacional que se me ocurre que puede ser leído por una combinación de placer y conocimiento.

Hay otros libros que he releído que son relevantes en la computación. Libros sobre cómo escribir, escribir en Inglés en mi caso en particular, como "The Elements of Style" por Strunk y White. Eventualmente vuelvo a él y lo releo con cierta frecuencia también, porque pienso que la habilidad de comunicarse es probablemente tan importante para muchas personas como la habilidad de sentarse y escribir código. La habilidad de dar a entender qué es lo que uno hace es muy importante.

También hay un excelente libro, How to Lie with Statistics(5), que usted puede encontrar útil en su propia investigación [riendo].

Mihai:

Cambiaré el curso de nuevo. Unix y C fueron creados en AT&T y fueron liberados bajo una licencia que para ese entonces era prácticamente una licencia open-source(6), ya que AT&T tenía que hacerlo: siendo un monopolio, sostenía un acuerdo con el gobierno, tal y como lo entiendo, para asegurarse de no ganar dinero mediante la industria de computadoras. Muchas personas le atribuyen a este hecho, a esta licencia de caracter liberal, la popularidad e influencia que han tenido tanto Unix como C. Recientemente Lucent ha liberado Plan 9(7) bajo una licencia de código-abierto. ¿Qué opina de este "nuevo" fenómeno del código-abierto?

Kernighan:

Creo que es algo bueno en general. La licencia original de Unix fue, como lo ha dicho, creada en gran parte en ese modo porque a AT&T no le era permitido estar involucrado en negocios aparte de la telefonía, así que no podían hacer dinero realmente mediante ningún tipo de software. Por esta razón fueron forzados a tomar una desición bastante sensible, que era básicamente entregar gratuitamente Unix a las universidades. Es cierto que lo vendieron comercialmente por una cantidad que constituía una carga incómoda, pero a las universidades se les repartió gratuitamente y como resultado una generación entera de estudiantes y sus facultades crecieron pensando que Unix era el modo en el que se realizaba la computación. Unix era ciertamente mucho más productivo que los sistemas operativos comerciales que se encontraban disponibles en ese entonces, y debido a que venía acompañado del código fuente, era sencillo ver lo que sucedía internamente, y era sencillo hacerle mejoras al sistema. Creó una comunidad de personas que estaban interesadas en él, motivados por las mismas cosas, quienes estaban en capacidad de contribuir y de ese modo desarrollar sus propias habilidades.

Pienso que el movimiento de código-abierto actual conserva mucha de esa misma naturaleza. Muchas de las herramientas desarrolladas en el modelo de código-abierto están basadas en los modelos de Unix. Linux es el elemento más obvio, siendo, al menos en el exterior, basado directamente en Unix; muchas de las cosas que provienen de la Fundación de Software Libre(8) son reimplementaciones de herramientas y lenguajes estándar de Unix.

Hay por supuesto otros proyectos, que surgen debido a curiosas presiones comerciales, como Mozilla, el código de Netscape, que ahora se encuentra en el dominio público, y que recibe contribuciones de la gente también.

Pienso que el movimiento del código-abierto es en general algo positivo. No estoy seguro de que llegue a reemplazar a los productos específicos, profesionales, fuertemente estables que son vendidos por un beneficio económico. Pero lo que puede lograr en muchos casos, y pienso que realmente lo ha hecho en cosas como compiladores de C, es proveer una implementación de referencia y un estándar que es muy bueno y que las demás implementaciones deben imitar o de otro modo ¿porqué la gente habría de pagar por productos diferentes? Creo que en ese sentido es algo muy útil.

En cuanto a Plan 9, creo que ya es muy tarde, desafortunadamente. Pienso que Plan 9 era una excelente idea y debió ser liberado bajo una licencia abierta cuando fue creado por primera vez, hace ocho años, pero nuestros guardianes legales no lo hubiesen permitido. Creo que cometieron un grave error. La licencia de código-abierto actual definitivamente vale la pena pero no resulta claro si Plan 9, al menos como un sistema operativo de propósito general, ejercerá mucha influencia en el mundo con excepción de un nicho considerablemente pequeño. Tiene muchas cosas que juegan a su favor que lo hacen valioso un diferentes áreas, particularmente en situaciones en donde se necesita un sistema operativo pequeño y altamente portable, pero ¿le arrebatará el liderazgo en este campo a Linux? Probablemente no.

Mihai:

Ya me encuentro cerca de finalizar en una nota mucho más ligera, pero primero formularé otra pregunta un poco más profunda. Haciendo una interpolación de la evolución del área de las ciencias computacionales hasta el momento, ¿qué otros progresos notables espera en el corto, y no sé si me atrevo a preguntar, largo plazo en el campo?

Kernighan:

[riendo] Si pudiera predecir el futuro entonces realizaría inversiones más sabias y no tendría que hacer estas entrevistas mal pagadas(9). Vaya, sabe, por desgracia soy muy malo para predecir cosas... Voy a arriesgarme y decir que en cierto sentido la situación en la computación seguirá siendo casi la misma: habrá mucho progreso, seremos capaces de enfrentar proyectos más grandes, podremos construir cosas que serán mucho más interesantes y sofisticadas de lo que pudiéramos haber hecho hace 10 años. Si observa el tipo de cosas que se ejecutan en el PC frente a nosotros ahora, son enormemente más poderosas, y flexibles de lo que eran las aplicaciones hace 10 años. Pero la cantidad de código desordenado, intrincado, horripilante que no funciona muy bien y que está por debajo de todo eso también ha aumentado enormemente. En cierto sentido creo que continuaremos haciendo progresos, pero siempre será en cierto sentido un poco sucio y con un caracter de productos no-realmente-listos-aun. A causa de que la gente siempre está tomando cosas que son más de lo que pueden manejar razonablemente, siempre se están excediendo los límites, y parece que nunca se regresa a limpiar las cosas que fueron hechas previamente.

La otra cosa de la que estoy de hecho un poco preocupado es que las computadoras son intrusivas, están en todas partes, en todo lo que uno hace. Es imposible darse la vuelta y no involucrarse con algo que depende en cierta forma crucial de una computadora, y cada vez más de esas cosas son realmente importantes para nosotros. No importa mucho si la grabadora de sonidos de windows funciona o no...

Mihai:

¡En este momento importa!(10)

Kernighan:

... si perdiéramos esto [la entrevista], qué mas da. Pero por ejemplo, cuando usted viaje de vuelta a Pittsburgh, usted realmente querrá que las computadoras que controlan el pilotaje del Airbus 320 funcionen correctamente y no cometan ningún error. Esa es tan solo una de las cosas que dependen de manera crucial de nuestra habilidad para escribir software que funcione y construir hardwade que lo opere, y no creo que sepamos cómo hacer eso muy bien todavía. Estamos progresando, es definitivamente mejor ahora, la combinación de lenguajes y técnicas como la verificación ayudan, pero aun tenemos el mismo problema: a medida que entendemos mejor cómo funcionan las cosas pequeñas, pasamos a cosas mayores y más complicadas, de modo que en cierto sentido simpre estamos hundidos hasta los hombros entre los cocodrilos.

Mihai:

La última pregunta de mi lista es acerca de sus hobbies.

Kernighan:

[riendo] ¿Quién tiene tiempo para hobbies? Si echara un vistazo en este momento a lo que constituyen mis hobbies, diría que se reducen a la lectura. Cuando no me encuentro rondando por ahí con tonterías o jugando con computadoras o haciendo cosas que se relacionen con mi trabajo, me encuentro leyendo. Usualmente libros de historia; no sé por qué, es un poco raro, pero me gusta leer libros de historia. En mi vida, en los últimos 20 o 30 años, he tenido fases en las que me he involucrado con algo profundamente por 3, 4, 5 años. Pasé por una fase en la que intenté aprender Japonés, por ejemplo; y puedo decirle, ¡toma más de 3 años aprender Japonés! De modo que eso fue un fracaso. Cuando era un estudiante universitario dediqué casi cinco años a la práctica del karate y llegué a un punto en el que más o menos podía sobrevivir, pero lo abandoné, ya no es parte de mi vida. Y pasé por una fase en la que me interesé mucho en las inversiones, y eso tampoco cambió mi vida, así que obviamente no era muy bueno en eso. Así que lo único que hago en este punto es principalmente leer bastante.

Mihai:

¡Muchas gracias!

(1)

Si el término hack le es extraño, probablemente le interese aprender sobre su significado. No olvide que Google es su amigo.

(2)

Se refiere al famoso libro The C Programming Language.

(3)

Es castellano, La Práctica de la Programación.

(4)

pretty-printers son herramientas específicas a un lenguaje que le dan formato a un programa fuente para que cumpla con un estándar de presentación determinado.

(5)

En castellano, podría titularse Cómo mentir con estadísticas.

(6)

Más información sobre código-abierto y sus licencias puede hallarse en http://www.opensource.org/.

(7)

Plan 9 es un sistema distribuido creado en los laboratorios Bell, construido a partir de terminales, servidores de CPUs y servidores de archivos.

(8)

Sitio web de la Free Software Foundation: http://www.fsf.org.

(9)

Nota del entrevistador: la entrevista fue gratis.

(10)

Nota del entrevistador: esta entrevista está siendo grabada usando una PC y software de audio.

1. Introducción
2. Sobre la traducción
3. La entrevista

1. Introducción
2. Sobre la traducción
3. La entrevista

• 1. Section One
• 1.1 Subsection One-One
• ...
• 1.2 Subsection One-Two
• 1.2.1 Subsubsection One-Two-One
• 1.2.2 Subsubsection One-Two-Two
• 1.2.3 Subsubsection One-Two-Three     <== Current Position
• 1.2.4 Subsubsection One-Two-Four
• 1.3 Subsection One-Three
• ...
• 1.4 Subsection One-Four