Everything is an AI remix

Llevaba yo tiempo (meses) con una pestaña del navegador abierta en la última versión de ese maravilloso vídeo que es el Everything is a remix

…con la intención de buscarle la relectura «en tiempos de IA generativa». Y resulta ser que en el último enlace del #67 de Interaccions, la maravillosa newsletter de Sergi Muñoz Contreras, este me descubre que, de hecho, esa relectura ya se la ha hecho su propio autor, Kirby Ferguson. Y después de verla, opino que es de lo mejor que se ha dicho sobre el tema (y es que en muchísimas ocasiones, incluso cuando el discurso se alinea con mis ideas, me parece que la capacidad de argumentación es escasa).

Mi recomendación es que, aunque vieseis alguna de las múltiples versiones del Everything en su momento, la reveáis ahora con calma antes de ver el segundo vídeo.

Y solo añadiré que, siendo uno muy, muy fan del Everything, y estando bastante de acuerdo (pero no del todo) con la relectura, creo que se salta lo que yo llamo «el problema del aprendiz» (que seguro que tiene un nombre mejor): pareciéndome determinados (muchos, incluso, potencialmente) usos de la IA como herramienta (como los propuestos en AI is remixing, por ejemplo) lícitos (estoy obviando los charcos tamaño océano de la sostenibilidad y del respeto a la propiedad intelectual, ciertamente), la IA es un arma de destrucción masiva del proceso de aprendizaje que convierte al aprendiz en maestro, y que eso es algo que me aterra. Creo que lo resolveremos algún día. Pero me aterra.

Scott y Mark y la enseñanza de la programación

Scott Hanselmann es un tipo majísimo, con un podcast muy recomendable (de los últimos episodios, me quedo con el del Interim Computer Museum o el de Anne-Laure Le Cunff, pero el nivel medio es alto). Scott es, además, el vicepresidente de «developer community» de una pequeña compañía llamada Microsoft (cosa que le permitió abrir el código del BASIC de Microsoft para el 6502, que enseñó a programar a mucha gente en el Apple II, y los Commodore PET, VIC 20 y Commodore 64, con el que aprendí yo, y que con eso yo ya le estaría agradecido eternamente).

En Microsoft Scott conoce a Mark Russinovich, cuyo LinkedIn dice que es «CTO, Deputy CISO and Technical Fellow, Microsoft Azure«, pero que igual os suena más (a los que tengáis una edad, os guste la informática y uséis Windows) de SysInternals. Y Scott y Mark tienen otro podcast, muy apañado también, Scott and Mark Learn To…, que en los últimos episodios ha hablado bastante de un producto que vende intensamente Microsoft, la programación con IA generativa. Y de todos esos episodios, me quedo con este fragmento y lo que dice Russinovich hacia el final. Os dejo el vídeo en el momento indicado, acompañado de la transcripción en inglés, primero, y la traducción al español, después.

Solo comentar antes, que…

  • ….hablan de informática, pero aplica a muchos otros campos, si es que no a todos,
  • que no es la opinión más original del mundo, pero está bien que lo diga quien lo dice,
  • que lo de que las universidades no tienen un buen modelo es rigurosamente cierto, pero a ver quién es el guapo o guapa al que se le ocurre una solución que no sea brutalmente intrusiva o imposiblemente cara,
  • y que destaco un fragmento de la conversación, pero que también está muy bien (traducido: alineado con lo que pienso yo, que es un tema que también me toca de relativamente cerca) sobre las empresas y lo que buscan / deben buscar al contratar gente joven, y que en general todo el episodio, y todo el podcast, son bastante recomendables.

Y eso, os dejo con el vídeo, la transcripción y la traducción.

Otro día, más.

Transcripción

(A partir de la transcripción de YouTube, corregida y editada ligeramente por mí para hacerla algo más legible (espero). Las negritas son mías.)

—So as we end… we’re at an inflection point. What should university students that are studying CS right now, sophomores, juniors, seniors, in CS, be thinking about as we are in that point?

— I have a friend that’s got a student in computer science that’s a junior and he said he was talking to them and said asking them, do you use AI and he says, like, yeah a lot of my fellow students are using AI. I don’t use AI, because I want to learn, the hard way.

— I think both is the right answer, though, I feel.

— I think both, but here’s what I’ll tell you right now. I think that universities don’t have a good model, you know, consistent.

— They’re behind. Academia might, but research level academia.

— But not for teaching undergrads. And, actually, I think what is coming into view for me is that you need classes where using AI for certain projects or certain classes is considered cheating. Not to say that you don’t have classes and projects in some classes where the student is told to use AI, but you need to have the main basis for the education on computer science and programming to be AI-less, because that’s the only way the student’s going to learn.

— I’ve been saying «drive stick shift». And I get told that I’m being gatekeepy when I say that.

— I don’t think you are, because there is a great study of three months ago from MIT where they took, um, not students, but they took people in careers, already in the workforce, and they divided them into three cohorts and had them write essays from the SAT, and they had one cohort just do it with their own closed book, just write the essay. They had another cohort that got to use Google, and they had another cohort that got to use ChatGPT, and they looked at their EEGs, and they quizzed them afterwards, right after, and then like a week later, and the results were exactly what you would expect. The people that wrote it could answer questions about what they wrote, even a week later, and their EEGs showed that they were burning a lot of wattage. The people that were using ChatGPT, an hour after they wrote the essay, they couldn’t remember what they’d written.

— That’s the thing. It’s just not even there. That makes me really sad. I very much enjoy using AI to brainstorm, to plan, but then I want to do the writing part. To vibe your way through life has me concerned.

— You lose the critical thinking. And they call this critical thinking deficit, that is what it’s creating…

— Which we already have from social media.

— Yeah, we already have. And if you’re talking about the early and career programmers that we’ve been talking about wanting to hire at a company, you want them to know what a race condition is. You don’t want them to have vibed it and AI is like, «Yeah, a race condition. AI will fix that.» Because at some point, as we’ve said, I think with the limitations of AI and software programming, at least for the foreseeable future somebody needs to know.

Traducción

(Con ChatGPT y revisado por mí. Las negritas siguen siendo mías.)

—Así que, para cerrar… estamos en un punto de inflexión. ¿Qué deberían estar pensando los estudiantes universitarios que estudian informática ahora mismo?

—Tengo un amigo que tiene un hijo que estudia informática, está en tercer año, y me dijo que le preguntó: “¿Usas IA?” Y él respondió: “Sí, muchos de mis compañeros la usan. Yo no, porque quiero aprender por el camino difícil.”

—Creo que ambas cosas son la respuesta correcta, sinceramente.

—Sí, ambas, pero te diré algo: creo que las universidades no tienen un modelo adecuado, coherente.

—Van por detrás. Quizás la academia investigadora sí, pero…

—Pero no en la enseñanza de grado. De hecho, creo que lo que se está haciendo evidente es que necesitamos clases en las que usar IA para ciertos proyectos o asignaturas se considere hacer trampa. No porque no debas tener otras clases o proyectos donde se indique explícitamente al estudiante que use IA, sino porque la base principal de la formación en informática y programación debe ser sin IA, porque es la única forma en que el estudiante realmente aprenderá.

—Yo suelo decir “hay que aprender a conducir con cambio manual”. Y me dicen que eso es una postura elitista1.

—No creo que lo sea, porque hay un estudio excelente de hace tres meses del MIT donde tomaron… no estudiantes, sino profesionales ya en activo, y los dividieron en tres grupos para que escribieran ensayos del tipo de la selectividad. A un grupo le dijeron que lo hiciera sin ayuda, a otro que podía usar Google, y a otro que podía usar ChatGPT. Luego midieron sus electroencefalogramas y los evaluaron justo después y una semana más tarde. Los resultados fueron exactamente los que esperarías: las personas que escribieron el ensayo por sí mismas eran capaces de responder preguntas sobre lo que habían escrito incluso una semana después, y sus elecroencefalogramas mostraban mucha actividad cerebral. En cambio, quienes usaron ChatGPT, una hora después ya no recordaban lo que habían escrito.

—Eso es. Es que ni siquiera está ahí. Y eso me pone muy triste. Me gusta mucho usar la IA para generar ideas, para planificar, pero luego quiero escribir yo. Esa actitud de “vibear”2 la vida me preocupa.

—Se pierde el pensamiento crítico. Y eso está generando un déficit de pensamiento crítico…

—Que ya teníamos por culpa de las redes sociales.

—Sí, ya lo teníamos. Y si hablamos de los programadores jóvenes o principiantes que queremos contratar en una empresa, quieres que sepan lo que es una condición de carrera (race condition). No quieres que lo hayan “vibeado” y que la IA les diga: “Sí, una condición de carrera, la IA lo arreglará.” Porque, como ya hemos dicho, con las limitaciones de la IA en la programación de software, al menos en el futuro cercano, alguien tiene que saberlo.

  1. «Gatekeepy» en el original. En este caso «to gatekeep» sería poner barreras de acceso innecesarias, o «pedir carnets». ↩︎
  2. «Vibear» es mi traducción de «to vibe code«, crear programas a base de prompts a IAs generativas, sin escribir una línea de código. ↩︎

Byte, junio del 85

Pues nada, seguimos con nuestro proyecto de leernos cada mes la revista Byte… de hace cuarenta años. Y le toca el turno al número de junio de 1985. Encontraréis todos los números en esta colección de archive.org, y el que leemos hoy, en concreto, dedicado a las técnicas de programación.

Portada de la revista Byte de junio de 1985. La imagen de portada es un cubo de Rubik en que cada una de las pequeñas caras del cubo es un una palabre clave informática. Entre ellas, tenemos char, DUP, UNIT, CAT, REM, puts, NULL, GREP, COND, FOR, GOTO...

Tampoco es que sea el número de mi vida, pero tiene sus cosillas. La primera en que me paro tiene que ver con accesibilidad:

Products Will Aid Visually Disabled Computer Users

Computer Aids, Fort Wayne, IN, introduced several microcomputer products for the disabled. One product, Small-Talk, uses a modified Epson HX-20 and a speech synthesizer to allow blind users to perform word-processing tasks. With a printer, microcassette tape drive, and special word-processing software, the computer will cost about $2000.

Que sí. Que hace décadas que hay gente que piensa en usar la informática para ayudar a las personas con discapacidad (en este caso visual). Lástima que tanta otra gente se olvide del tema.

Siguiente parada, anuncio de ordenador de esos que te hace añorar el diseño industrial ochentero:

Anuncio a doble página de la marca apricot. En la página izquierda, los restos de un albaricoque  que alguien se acaba de comer, con el texto Past. A la derecha, un albaricoque entero, con el texto Present and Future. En la esquina inferior izquierda de la página, una miniatura de un ordenador de diseño ochentero. Más detalles en la siguiente imagen.

¿Me vais a decir que no es precioso? Bueno. Me vais a decir que no se ve. Hagamos un enhance it:

Zoom de la imagen anterior. Tenemos un portátil en tres piezas. La primera tiene la pantalla (de fósforo verde) y seguramente la CPU. El teclado está en otra pieza, y hay una tercera pieza con lo que parece ser un trackball. La imagen viene con el texto The APricot Portable. 521K RAM, 720K diskette. 80x25 line LCD. MS-DOS. $2495

¿Es o no precioso el Apricot Portable? Había salido a la venta en octubre del 84 y, recomonozcámoslo, le daba sopas con honda a los portátiles de la época (incluido mi adorado SX-64). Ni siete kilos, pesaba. Y las piezas separadas se comunicaban ¡por infrarrojos! ¡El futuro! ¡En 1984! Hasta tenía reconocimiento de voz (aunque habría que poner «reconocimiento» entre toneladas de comillas: dice la Wikipedia que se le podían entrar 4096 palabras, 64 de las cuales simultáneamente en memoria). Y su MS-DOS pasaba de los famosos 640 Ks (para llegar a 768, tampoco nos emocionemos más de la cuenta). En cualquier caso, una preciosidad.

Seguimos avanzando y nos encontramos con otro anuncio:

Anuncio. Vemos la foto de una pantalla de un PC de IBM, con lo que parece una interfaz gráfica del estilo de un Windows antiguo y un programa de dibujo en el que alguien ha creado lo que parece un post it con la palabra hi escrita a mano

¿Qué es eso de GEM? Aquí, otra versión del anuncio:

De nuevo, una pantalla de un IBM PC, con un entorno gráfico de ventanas (también se ve un ratón en la página) y la caja de un software, GEM Desktop, y su precio ($49.95). Se explica que el software era, efectivamente, un entorno gráfico para usar los PCs de IBM sin tener que teclear comandos crípticos.

GEM era el entorno gráfico que desarrolló Digital Research (la compañía de CP/M, fundada en 1974 y que sería adquirida por Novell en 1991 ) principalmente para los Atari ST, pero también para PCs con MS-DOS, entre otros. Y es ver una captura de GEM y que se me caiga la lagrimita. Esnif.

Volviendo a nuestro clásico «¿créias que esto era nuevo?», hoy toca…

Turning a common AI operation into silicon

Logic programming is a staple of artificial-intelligence (AI) software and is often dominated by the pattern-matching process of unification (see the "Resolution and Unification" text box on page 173). In fact, when logic-programming languages such as Prolog and LOGLISP are used, as much as 50 to 60 percent of a computer's processing time is spent on unification. When a single algorithm is used that frequently, it is natural to consider implementing it as custom hardware. When that same algorithm lends itself to parallelism and concurrency because of its recursive, treesearch characteristics, it practically begs for VLSI (very large scale integration) implementation.

SUM History

Professor lohn Oldfield and a team of researchers at Syracuse University are developing the SUM (Syracuse Unification Machine), a coprocessor for computers geared toward AI programming. The project combines the resources of the Syracuse CIS (Computer and Information Science) department. ECE (Electrical and Computer Engineering) department, and the CASE Center (Computer Applications and Software Engineering Center, set up by New York State). Key SUM individuals are Dr. Oldfield himself (who contributed CAD [com-

puter-aided design| and VLSI expertise). Professor Alan Robinson (who is the head of the logic-programming efforts at Syracuse), and Kevin Greene (who made the initial designs of the SUM). Because of a famous 1965 paper, Dr. Robinson is often credited with inventing unification. He is more modest, pointing to the work of Herbrand in the 1930s and the studies of Prawitz and Kenger concerning unification. Dr. Robinson contends that he was just the first to formalize the unification process and apply it to resolution.

In 1981, the Syracuse CIS logic-programming group learned that Caltech (California Institute of Technology) student Sheue-Ling Lien had designed a chip that embodied Dr. Robinson's original unification algorithm (see the "Unification on a Chip" text box, page 1 74). Dr. Robinson and his colleagues were somewhat taken aback that someone else had taken this step. Lien's report was a major inspiration for the development of the SUM, even though the chip it described was never actually made. Because ECE had been developing custom VLSI

chip-design capability and had a strong logic-programming group, combining the pursuits "seemed a natural thing" according to Dr. Oldfield.

Coprocessor Strategy

As Dr. Oldfield explains, "Although we started talking about a unification chip, following along the lines of the Caltech one. it soon became fairly clear that at present levels of integration that was fairly ridiculous. You could make a chip, but it would be limited to solving such small problems that it wouldn't be worthwhile." The SUM group wanted to design a full-blown, practical processor. Besides. Lien's chip used Dr. Robinson's original 1965 algorithm. Much more efficient algorithms have been developed since.

When they realized that a single chip wasn't realistic, the members of the group looked at the possibility of a coprocessor, initially for the LMI

Sí, queridas, podríais pensar que TPUs y NPUs y demás son una cosa acabada de inventar, pero cada vez que la IA se pone de moda, alguien piensa en hardware para acelerarla…

Siguiente cosa que me ha interesado: ¿cómo elegir lenguaje de programación?

CHOOSING A PROGRAMMING 
LANGUAGE

by Gary Elfring

It's a three-step process

IF YOU WERE a carpenter building a new house, the first thing you would do would be to collect your tools. The tools you'd select would vary depending on the type of job. The same thing should be true if you are a programmer. You have a wide range of tools available, and you just choose the right tools for the job. Your tools are the languages that you program in and the environments needed to support those languages.

How do you go about selecting the right tool for the job? There are more programming languages available for microprocessors than most people could learn in a lifetime. What you need is a methodology that can be used to select one language from all the rest for a given application.

This article presents a practical method for comparing programming languages. It has an inherent bias toward compiled high-level languages. Compiled languages are faster than interpreted ones, and most interpreted languages also offer a compiler version. Since program speed is often an issue, I chose compilers over interpreters.

The actual process of evaluating a group of programming languages can be broken down into three major steps. The first step is to characterize the application the language is being selected for. Then you must identify the features that a language should have in order to deal with the previously described application. Finally, you should take into account practical considerations to further narrow down the language selection.

The Application

You can't choose a tool unless you know what you intend to do with it. You have to describe your application. Once you have this information you can then proceed to determine whether or not the existing language choices are the right tools for the job. To describe an application, you must consider both the type and size of the application. These questions must be answered before you can proceed any further in the language evaluation:

What is the type or class of application? What level of language is needed?

There are a number of different classes of program applications. An application can belong to a single class or several. Identifying the class of your application is relatively simple and helps narrow the list of acceptable languages. Some of the more common classes include scientific, business, and system programming; text processing; expert systems; and real-time control.

Most programming languages are better suited to solving one particular class of problem than another. COBOL is one example. While it is easy to write maintainable business programs with COBOL, no one would expect to use this language to solve real-time control problems.

Another consideration is the level of programming that the application will require. If you need low-level control of various machine-dependent features, then a very high level language...

La cosa comienza dando preferencia a compilados sobre interpretados por temas de velocidad (cosa más importante hace cuarenta años que ahora, que les pregunten a JavaScript y Python). Sigue proponiendo que el tipo de programa es muy importante (y dando COBOL como ejemplo de lenguaje para aplicaciones de negocios), y a continuación proponiendo si lenguajes de alto o bajo nivel… Comencé a leer el artículo pensando que lo que dijese sería siendo bastante actual. Curiosamente, donde uno esperaba más estabilidad… va a ser que no. Pero claro, entonces llega este artículo sobre componentes reutilizables:

SOFTWARE-ICs

by Lamar Ledbetter and Brad Cox

A plan for building reusable software components

THE SOFTWARE WORLD has run headlong into the Software Crisis—ambitious software projects are hard to manage, too expensive, of mediocre quality, and hard to schedule reliably. Moreover, all too often, software delivers a solution that doesn't meet the customers' needs. After delivery, if not before, changing requirements mean that systems must be modified.

We must build systems in a radically different way if we are going to satisfy tomorrow's quantity and quality demands. We must learn to build systems that can withstand change.

Some system developers are already building software much faster and of better quality than last year. Not only that, the systems are much more tolerant of change than ever before, as a result of an old technology called message/object programming. This technology, made commercially viable because of the cost/performance trends in hardware, holds the key to a long-awaited dream— software reusability. A new industry is developing to support the design, development, distribution, and support of reusable Software-ICs (integrated circuits). A forthcoming series in UNIX/World will address message/object programming.

Message/Object Programming and software-ICs

In this article we'll look at the concepts of message/object programming and how they support the building of "Software-ICs," as we call them, by satisfying the requirements for reusability.

A Software-lC is a reusable software component. It is a software packaging concept that combines aspects of subroutine libraries and UNIX filter programs. A Software-IC is a standard binary file produced by compiling a C program generated by Objective-C.

The notion of objects that communicate by messages is the foundation of message/object programming and fundamental to Software-ICs. An object includes data, a collection of procedures (methods) that can access that data directly, and a selection mechanism whereby a message is translated into a call to one of these procedures. You can request objects to do things by sending them a message.

Sending a message to an object is exactly like calling a function to operate on a data structure, with one crucial difference: Function calls specify not what should be accomplished but how. The function name identifies specific code to be executed. Messages, by contrast, specify what you want an object to do and leave it up to the object to decide how.

Requirements for Reusability

Only a few years ago, hardware designers built hardware much as we build software today. They assembled custom circuits from individual electrical components (transistors, resistors, capacitors, and so on), just as we build functions out of low-level components of programming languages (assignment statements, conditional statements, function calls, and so on). Massive reusability of hardware designs wasn't possible until a packaging technology evolved that could make the hardware environment of a chip (the circuit board and adjoining electrical components)...

Ojo a los dos primeros párrafos:

El mundo del software ha chocado con la Crisis del Software: los proyectos ambiciosos son difíciles de gestionar, demasiado caros, de calidad mediocre y difíciles de programar con fiabilidad. Además, con demasiada frecuencia, el software ofrece una solución que no satisface las necesidades de los clientes. Tras la entrega, o incluso antes, los cambios en los requisitos obligan a modificar los sistemas.

Debemos construir sistemas de una forma radicalmente diferente si queremos satisfacer las demandas futuras de cantidad y calidad. Debemos aprender a construir sistemas que resistan el cambio.

¿Escritos en 1985? ¿1995? ¿2025? ¿Nos jugamos algo a que los podremos reutilizar sin tocar una coma en 2065?

En fin… Si queréis saltar de este mes de junio del 85 a nuestra relectura del número de mayo, aquí lo teneís. y el mes que viene, más (espero).

Byte, abril del 85

Continuamos con el proyecto de leer mensualmente la revista Byte… de hace cuarenta años (tenéis las entradas anteriores en la etiqueta Byte del blog, aunque a ver si encuentro el momento de currarme un índice un poco más currado (que muy probablemente solo usaría yo, ciertamente)).

Decía el mes pasado que este número venía cargadito, y así es:

Portada  de la revista Byte de abril de 1985. El tema de portada es la inteligencia artificial. La ilustración es iuna mano humana dibujando una mano robótica junto a una mano robótica dibujando una mano humana

…pero no cargado de las cosas que suelo destacar, sino de una buena cantidad de artículos sobre IA. Pongo yo unos cuantos «plus ça change» en estas entradas, pero en esta ocasión todo el bloque central de la revista es un «plus ça change». Tanto que, del resto, solo me voy a quedar con la inocentada:

Foto de un accesorio para el Mac que es un afilador de cuchillos. El texto que acompaña a la foto (en inglés) es el siguiente:

Knife the Mac

Ennui Associates has announced MacKnifer,a hardware attachment that mounts on the side of your Macintosh and sharpens knives, scissors, lawn-mower blades – anything that needs sharpening. With MacKnifer's patented double-action grinding wheel, you can easily sharpen any utensil in less time than it takes the Mac to open a file. According to the manufacturer, MacKnifer is so easy to use that you can opearte it within 30 minutes of taking it out of the box. Turn your spare computing time into extra cash with a knife-sharpening business on the side... of your Macintosh.

For more information on MacKnifer, contact Ennui Associates, 52502 Marginal Avenue, Somnolencia, CA, 90541.

Aquí la entrada correspondiente de hoaxes.org: https://hoaxes.org/af_database/permalink/the_macknifer, por si a alguien le hiciese falta.

(Por cierto, he decidido cambiar de «proveedor» para las revistas, a esta página de archive.org, y en la medida de lo posible (léase, cuando me acuerde) intentaré enlazar los artículos y piezas que comente.)

Entrando en materia, la cosa comienza con nada más y nada menos que Marvin Minsky:

COMMUNICATION WITH ALIEN INTELLIGENCE
by Marvin Minsky

It may not be as difficult as you think

WHEN FIRST WE MEET those aliens in outer space, will we and they be able to converse? I believe that, yes, we will— provided they are motivated to cooperate— because we'll both think in similar ways. I propose two kinds of arguments for why those aliens may think like us, in spite of having very different origins. These arguments are based on the idea that all intelligent problem solvers are subject to the same ultimate constraints – limitations on space, time, and materials. For animals to evolve powerful ways to deal with such constraints, they must have ways to represent the situations they face, and they must have processes for manipulating those representations. These two requirements are:

Economics: Every intelligence must develop symbol systems for representing things, causes, and goals, and for formulating and remembering the procedures it develops for achieving those goals.

Sparseness: Every evolving intelligence will eventually encounter certain very special ideas— e.g., about

arithmetic, causal reasoning, and economics— because these particular ideas are very much simpler than other ideas with similar uses.

The economics argument is that the power of a mind depends on how it manages the resources it can use. The concept of thing is indispensable for managing the resources of space and the substances that fill it. The concept of goal is indispensable for managing how we use the time we have available—both for what we do and what we think about. Aliens will use these notions too, because they are both easy to evolve and because there appear to be no easily evolved alternatives for them.

The sparseness theory tries to make this more precise by showing that almost any evolutionary search will soon find certain schemes that have no easily accessible alternatives, that is, other different ideas that can serve the same purposes. These ideas or processes seem to be peculiarly isolated in the sense that the only things that resemble them are vastly more complicated. I will discuss only

the specific example of arithmetic and conjecture that those other concepts of objects, causes, and goals have this same island-like character.

Critic: What if those aliens have evolved so far beyond us that their concerns are unintelligible to us and their technologies and conceptions have become entirely different from ours?

Then communication may be infeasible. My arguments apply only to those stages of mental evolution in...

Artificial-intelligence pioneer Marvin Minsky is Donner Professor of Science in the Department of Electrical Engineering and Computer Science at Massachusetts \nstitute of Technology (545 Technology Square, Cambridge, MA 02139). Ik the late 1950s, Minsky, together with John McCarthy [now at Stanford), created MIT's AI laboratory, of which Minsky was the director for several years. Minsky has long been interested in SETI [the Search for Extraterrestrial Intelligence) and participated in the important 1971 conference on communication with extraterrestrials, held in Soviet Armenia and organized by Carl Sagan.

Minsky fue cofundador del laboratorio de IA del MIT, había recibido el premio Turing en 1969, inventó el primer «head mounted display», codiseñó con Seymour Papert la tortuga de Logo, y para su tesis doctoral construyó a principios de los años cincuenta SNARC, uno de los primeros intentos de construir una máquina que imitara el comportamiento del cerebro humano, diseñada para simular una red neuronal, específicamente un conjunto de neuronas artificiales interconectadas, que emulaba el comportamiento de ratas recorriendo laberintos, y aprendía gradualmente a encontrar el camino correcto basándose en recompensas (lo que ahora llamamos aprendizaje por refuerzo). Ojo: Minsky (fallecido en 2016) estuvo asociado con Jeffrey Epstein y estuvo en su isla privada, aunque la mujer de Minsky, que estuvo allí con él, defiende que nunca hizo nada moralmente cuestionable allí.

Minsky, que estaba muy interesado en SETI, el proyecto para buscar vida extraterrestre, plantea en el artículo su hipótesis de que toda inteligencia, alienígena o no, debe ser similar y que, por tanto, no debería ser muy difícil la comunicación, a no ser que la otra inteligencia haya ido más allá del estado de preocuparse por su supervivencia, la comunicación y expandir su control del mundo físico. Para ello se apoya en un experimento mental de exploración de máquinas de Turing, y en la universalidad de la aritmética, para acabar llegando a la inevitabilidad, a su vez, de muchos aspectos del lenguaje (el razonamiento me suena a Chomsky, por algún motivo). No me atrevo para nada a resumir ni a juzgar el artículo, pero es curioso combinar la IA de la inteligencia artificial con la IA de la inteligencia alienígena, cuando menos…

THE QUEST TO UNDERSTAND THINKING

Roger Schank and Larry Hunter

It begins not with complex issues but with the most trivial of processes

ARTIFICIAL INTELLIGENCE, or AI, takes as its subject matter some of the most daunting questions of our existence. What is the nature of mind? What are we doing when we are thinking, feeling, seeing, or understanding? Is it possible to comprehend how our minds really work? These questions have been asked for thousands of years, but we've made little tangible progress at answering them.

AI offers a new tool for those pursuing the quest: the computer. As anyone who has used one can attest, computers often create more problems than they solve. But for probing the issues of mind and thought, that is just what we need.

The fundamental use of computers in helping us understand cognition is to provide a testbed for our ideas about what the mind does. Theories of mind often take the form of process descriptions. For example, a theory of question answering might claim that people first translate a question into an internal representation, use that representation as an index into memory, translate the recalled memory into an appropriate form for an answer, and then generate the words to communicate it. (This example is offered not as a real theory of question answering but as an example of what a process theory of mind might look like.)

Process theories seem to be a good way of describing what might go on inside the brain. One problem with them, however, is that all too often what looks like a good description really isn't specific enough to make the theory clear. "Use the representation as an index into memory" isn't a good explanation of the processes behind remembering a fact. How are facts recalled? How is the memory organized? What happens when memory gets very large? What if a fact isn't directly encoded in memory but can be inferred from something that is? A researcher trying to write a program that embodies the above simplistic theory would run into all of these problems and more. That's why we need to write programs. Programming forces us to be explicit, and being explicit forces us to confront the problems with our theories.

Not long ago, AI researchers like ourselves focused on what they considered to be manifestations of highly intelligent behavior; playing chess, proving mathematical theorems, solving complex logical puzzles, and the like. Many AI researchers devoted a lot of energy to these projects and found powerful computational techniques for accomplishing such "intelligent" tasks. But we discovered that the techniques we developed are not the same ones that people actually use to perform these tasks, and we have instead begun to concentrate on tasks that almost any adult finds trivial: using language, showing common sense, learning from past experiences.

Language

We began studying these "trivial" tasks by trying to write programs that...

El siguiente artículo también tiene autores «wikipediables»: Roger Schank se doctoró en lingüística después de graduarse en matemáticas, fue profesor de informática y psicología en Yale , donde en 1981 fundó el Yale Artificial Intelligence Project y en 1989 haría lo mismo con el Institute for the Learning Sciences de Northwestern. Investigaba sobre comprensión del lenguaje natural y razonamiento basado en casos. Y, me temo, no solo conocía también a Epstein (ayuda que este se dedicase de vez en cuando a financiar investigación en IA), como Minsky, sino que le mostró su apoyo cuando comenzó a destaparse el pastel :-S. Lawrence Hunter, por su parte, se dedica hoy en día a la biología computacional, campo al que llegó a través del razonamiento basado en casos para el diagnóstico del cáncer de pulmón.

¿Y el artículo? El artículo toca, primero, un tema que se me antoja vital y, a la vez, absolutamente ausente del debate actual: cómo la inteligencia artificial podría ser una muy buena herramienta para ayudar a entender qué es y cómo funciona la inteligencia «natural», y luego se centra en algunos de los problemas de procesar el lenguaje natural, como la ambigüedad, el contexto o la memoria (la de recordar, no necesariamente la RAM).

Me estoy pasando con la cuenta de palabras, o sea que solo citaré The LISP tutor y PROUST, An automatic debugger for Pascal programs, que como podrá imaginar el lector, se centran en los usos , que ahora parecen más cercanos, pero ya veremos, de la IA para enseñar a programar y ayudarnos a programar.

Y cerramos con…

LEARNING IN PARALLEL NETWORKS

Simulating learning in a probabilistic system

THE BRAIN is an incredibly powerful computer. The cortex alone contains over 10^10 neurons, each connected to thousands of others. All of your knowledge is probably stored in the strengths of these connections, which somehow give you the effortless ability to understand English, to make sensible plans, to recall relevant facts from fragmentary cues, and to interpret the patterns of light and dark on the back of your eyeballs as real three-dimensional scenes. By comparison, modern computers do these things very slowly, if at all. They appear very smart when multiplying long numbers or storing millions of arbitrary facts, but they are remarkably bad at doing what any five-year-old can.

One possible explanation is that we don't program computers suitably. We are just so ignorant about what it takes to understand English or interpret visual images that we don't know the appropriate data structures and procedures to put into the machine. This is what most people who study artificial intelligence (AI) believe, and over the last 20 years they have made a great deal of progress in reducing our ignorance in these areas.

Another possible explanation is that brains and computers work differently. Perhaps brains have evolved to be very good at a particular style of computation that is necessary in everyday life but hard to program on a conventional computer. Perhaps the fact that brains store knowledge as connection strengths makes them particularly adept at weighing many conflicting and cooperating considerations very rapidly to arrive at a common-sense judgment or interpretation. Of course, any style of computation whatsoever can be simulated by a digital computer, but when one kind of machine simulates a very different kind it can be very slow. To simulate all the neurons in a human brain in real time would take thousands of large computers. To simulate all the arithmetic operations occurring in a Cray would take billions of people.

It is easy to speculate that the brain uses quite different computational principles, but it is hard to discover what those principles are. Empirical studies of the behavior of single

neurons and their patterns of connectivity have revealed many interesting facts, but the underlying computational principles are still unclear. We don't know, for example, how the brain represents complex ideas, how it searches for good matches between stored models of objects and the incoming sensory data, or how it learns. In this issue Jerome A. Feldman describes some current ideas about how parallel networks could recognize objects (see "Connections" on page 277). I will describe one old and one new theory of how learning could occur in these brain-like networks. Please remember that these theories are extreme idealizations; the real brain is much more complicated.

Associating Inputs with Outputs

Imagine a black box that has a set of input terminals and a set of output

… nada más y nada menos que un Nobel de física (y premio Turing, y premio Príncipe de Asturias, y no sé cuántos premios más), Geoffrey Hinton. Lo de darle un Nobel en física a un graduado en física y doctor e investigador en IA es algo en lo que no entraré ahora, pero marcarse el punto de publicarle cuando era un mero profesor ayudante en Carnegie Mellon, junto a figuras al menos aparentemente de mucho más relumbrón que él, me lo vais a tener que reconocer, no está nada mal. Más si lo que está explicando es, si no lo he entendido mal, el trabajo en entrenamiento de redes neuronales que es uno de los pilares por los que ha acabado ganando todo el reconocimiento y los premios con los que cuenta.

Y no me alargo más, pero toda la tabla de contenidos del especial merece como mínimo una ojeada rápida…

Y, en cualquier caso, que cuarenta años no son nada.

Si queréis seguir leyendo, aquí tenéis mis notas sobre el número de marzo. Y el mes que viene, con un poco de suerte, más.

La ética de las inteligencias artificiales… y de las naturales

Diría que Aral Balkan no pensaba en lo mismo que yo cuando respondió esto al tuit con la pieza de la BBC, pero eso no va a evitar que lo utilice como introducción de esta entrada. Y es que la pregunta es esencial… y me parece extrañamente ausente del debate creciente sobre el tema.

En primer lugar, aceptar la evidencia: aunque la explosión de noticias en los medios sobre el advenimiento de las inteligencias artificiales salidas directamente de un guión de Hollywood es un tanto exagerada, sí es cierto que cada vez hay más algoritmos que controlan nuestras vidas, y que muchos de ellos carecen de la más mínima transparencia exigible. Si uno quiere leer una historia de miedo verdaderamente aterradora, Machine Bias, publicada a finales de mayo pasado por Propublica, es un excelente lugar por el que comenzar (y si uno sospecha del sesgo humano al hablar de los sesgos de la inteligencia artificial, también podéis leer la pieza a partir de la pieza Inspecting Algorithms for Bias, del MIT Technology Review, un medio absolutamente limpio de sospechas de ludismo). Resumiendo lo de Propublica: analizan los resultados de un software que se está usando en Estados Unidos para asistir en la toma de decisiones judiciales… y resulta ser que es bastante fácil y natural acusar de racista al algoritmo. Y es muy difícil leer la pieza sin escandalizarse bastante. Sin negar la utilidad de usar algoritmos para ayudarnos a tomar decisiones, es absolutamente imprescindible que estos cumplan unos mínimos. En este sentido, a mí personalmente me atrae el Statement on Algorithmic Transparency and Accountability (PDF) de los comités estadounidense y europeo de políticas de la ACM, que establece siete principios para la transparencia y responsabilidad algorítmicas (conciencia, acceso y rectificación, responsabilidad, explicación, origen de datos, auditabilidad y validación y testeo) pero, en cualquier caso, hay mucho trabajo por hacer y corre prisa (y si a alguien le apetece leer más sobre el tema, me permito apuntarle a esta lista de lecturas).

Y una vez dicho esto… ¿qué es lo que echo en falta en el debate? Lo de siempre. Cada vez que criticamos (muchas veces con razón) el fin del mundo que nos trae la innovación tecnológica de turno tendemos, bien a olvidarnos de cómo era la realidad anterior, bien a idealizarla directamente. Y si hablamos de sesgo algorítmico… ¿no deberíamos ligar la conversación a la ya existente sobre los sesgos humanos y preguntarnos, como decía Aral Balkan en su tuit, cómo llevamos la ética los humanos, al tiempo que hablamos de la ética de los algoritmos?

La pregunta me lleva al fantástico libro de Daniel Kahneman Pensar rápido, pensar despacio (que este mes cumple seis añitos ya), y que contiene una colección de sesgos profundamente humanos que no tienen desperdicio y que nos deberían escandalizar también bastante, incluyendo un estudio sobre la correlación entre las decisiones judiciales sobre libertades condicionales y el hambre de los jueces (el 65% de libertades condicionales se concedían justo después de comer: si alguna vez os tienen que conceder —o no— la condicional, haced todo lo posible para no pillar al juez con hambre). Si queréis más ejemplos, a por el libro, que no os defraudará. Y supongo que no hará falta que ponga ningún ejemplo de la capacidad humana para el racismo…

En cualquier caso, y dando por aceptado que estamos muy pero que muy lejos de podernos fiar de las decisiones tomadas de forma algorítmica (si es que alguna vez llegamos a ese punto, que personalmente lo dudo muchísimo)… mi pregunta sin responder es: una vez encontrado un sesgo en un proceso de toma de decisiones, ¿es más fácil corregirlo si el proceso es algorítmico o humano? Y no tengo respuesta.