Leído por ahí… – otro blog más

Lecturas (2026.III)

Seguimos a un ritmo bien relajado de lectura (el anterior Lecturas fue justo después de Sant Jordi), pero menos es nada…

Thinking in Bets
Making Smarter Decisions When You Don't Have All the Facts
Annie Duke

Comienzo por el libro que no me he acabado. Annie Duke es una exjugadora de póker de éxito considerable que ahora escribe sobre la toma de decisiones en situaciones de incertidumbre. El libro está bien, pero no es lo que yo buscaba: ideas sobre cómo lidiar con la incertidumbre en la vida real. El póker, efectivamente, es un juego de habilidad y azar marcado por la incertidumbre, pero no se traslada a la vida real: en el póker se juegan centenares de partidas siguiendo las mismas normas y cada decisión tiene un alcance limitado, mientras que en la vida real cada decisión es diferente y su alcance, potencialmente vital. Me quedé algo más allá del primer tercio del libro sin demasiadas expectativas (ni indicaciones en el índice) de que fuese a dar algún salto de un entorno a otro. Una vez sabido esto, puede ser una lectura interesante.

Segundo chapuzón en Borges, y segunda vez que salgo encantado (en todos los sentidos), con la sensación de haberme perdido la mitad pero con ganas de más. Tremendo.

Like, literally, dude. Arguing for the Good in Bad English
Valerie Fridland

Más divulgación sobre lingüística desde un punto de vista descriptivista y tolerante con el cambio. Muy bien escrito (no podía ser de otra forma) e interesante. Me ha gustado especialmente la atención al género: al menos en inglés, deja claro que si quieres saber cómo se hablará dentro de unos años, deberías prestar especial atención a cómo hablan las niñas (al menos en inglés, que es de lo que habla el libro, pero me imagino que en el resto de idiomas también será válido) y otras comunidades poco privilegiadas.

To be taught if fortunate
Becky Chambers

Novelita (apenas 136 páginas) de ciencia ficción que viene a ser «El Marciano pero al revés». La autora tiene un premio Hugo, y es fácil ver por qué. Extremadamente recomendable (ya he pasado por caja a comprarme otro de sus libros), aunque no desvelaré nada más del argumento.

Proving Ground
The untold story of the six women who programmed the world's firts modern computer
Kathy Kleiman

Y cierro con un libro importante. No creo en las lecturas obligatorias… pero nadie debería salir de una carrera de informática sin haberse leído este libro. Además de ser la historia de Fran Bilas, Jean Jennings, Kay McNulty, Marlyn Wescoff, Betty Snyder y Ruth Lichterman (pongo los «nombres de soltera», que a mí las manías anglosajonas del cambio de nombre en el matrimonio se me hacen muy raras), las seis primeras programadoras, y el ninguneo que sufrieron duarnte décadas (y que aún dura), es un pedazo imprescindible de la historia de la informática y del siglo XX en general.

En lo negativo, dice el «blurb» de la portada que la prosa de Kleiman es detallada… porque, como narración de la historia oral que es, no es la más apasionante… excepto cuando habla de su propia historia descubriendo la historia de «las seis del ENIAC». Aun así, el libro está pidiendo a gritos ser convertido en miniserie de prestigio. Si obtiene los derechos un equipo como el de los creadores de Halt and Catch Fire, podría salir algo maravilloso.

Y lo dejamos aquí. A ver si me da tiempo a leer algo más antes de que acabe el año…

#breBytes La familia Motorola 68000

La vida de la familia 68000 de Motorola fue breve (dejó de fabricarse en 1996), pero intensa, siendo el procesador de nuestro adorado Amiga y del Atari ST, pero sobre todo la primera arquitectura sobre la que se construyeron los Macs (y el Lisa antes de eso). Apple se pasó a los PowerPC en 1994, y eso acabó con los 68k. Pero hace 40 años, en septiembre de 1986, la familia 68000 prometía muchísimo: lo suficiente como para ser portada de Byte.

Portada de la revista Byte de septiembre de 1986, dedicada a la familia 68000 de procesadores. Ilustran la portada algunos chips de la familia y pequeñas fotos de un Mac, un Atari ST y un Amiga 1000.

La revista le dedica un buen espacio a las diferentes máquinas 68000 (incluyendo un apartado dedicado a Unix), pero nosotros ya sabemos cuál era la mejor. Y es que, ¿qué otra máquina podía producir gráficos así?

Anuncio a página completa del Commodore Amiga, con una imagen a todo color de una ilustración de la imagen clásica del emperador egipcio Tutankamón.

Y claro, lo que más nos interesa de la sección es esta comparación entre el Amiga y el Mac, aunque está hecha desde el punto de vista del programador:

AMIGA VS. MACINTOSH

by Adam Brooks Webber

A programmer's comparison of the system calls on two 68000~based machines

I HELPED IMPLEMENT the True BASIC language system on the Macintosh. The project has been completed for some time now and we've all recovered our perspective and good humor, but at the time I felt that if I saw that smiling "Welcome to Macintosh" message one more time I would scream. It was in this frame of mind, on my way to see the Amiga for the first time, that I wrote out a list entitled "Why I Hate the Macintosh."

That incident led to this article. I have now completed the same project on the Amiga and have many gripes about that machine, too. In this article I compare the system software, of the two machines.

Implementing a language system is a good way to get to know a machine. True BASIC is not just a compiler and interpreter, it's a screen editor, a graphics program, and a number cruncher. It makes sounds, it prints, it manipulates files— in short, it uses most of a system's software. My comparison of the Macintosh and the Am\ga is necessarily limited, but I have tried to choose areas that are of general interest and that are representative of the differences between the two machines. These are the user interface, graphics primitives, printers and other devices, multitasking, and memory management.

The User Interface

The user interface of a system is usually examined from the user's point of view. You ask, "Is it intuitive? Is it powerful? Is it forgiving of error?" as you consider how to communicate with a program. I am interested in another point of view: What does a program have to do to communicate with the user? For some machines, communicating with the user means reading characters from the keyboard and writing text to the screen. Adding windows, menus, and mouse operations makes things more complicated, lust how complicated is shown by the Macintosh user interface software, which determines the structure of every Mac program more or less completely. The program must have a main loop that is executed as often as possible, usually 60 times a second. (One rule of thumb: The quality of system software is inversely proportional to the number of things a program must do "as often as possible.") The main loop checks for events like keystrokes, mouse clicks, and disk insertions and responds to them.

Responding to an event is usually a lot of work because the Mac's user interface software provides little assistance. Figure 1 shows, in pseudocode, a simple example of what a program must do to allow a window with a scroll bar to change in size— something that most Mac programs have to deal with. The system software does offer significant help in two areas of user interface: text editing and file access. TextEdit is a subsystem that provides a mechanism for displaying and editing text in a window. (True BASIC doesn't use TextEdit, but only because we have our own internal string-handling procedures.) For...

Nótese, por cierto, que el artículo está escrito por un graduado del Dartmouth College, el lugar de nacimiento de BASIC. La comparación, por cierto, es favorable al Amiga en cuanto a la programación de la interfaz, gestión de dispositivos, multitarea (no es una sorpresa enorme, teniendo en cuenta que el Mac no era multitarea en 1986) y gestión de memoria, y al Mac en lo que se refiere a primitivas gráficas. Pero esto no le salvaría la vida al Amiga, lamentablemente.

Un poco más adelante, en su Chaos Manor Jerry Pournelle seguía enamorado del Amiga y nos hablaba de ese clásico que fue Deluxe Paint (con el que se hizo el Tutankamón de aquí arriba, si no me equivoco, y que ocuparía el lugar en el imaginario que le dedicamos a Photoshop si viviésemos en la línea temporal correcta), pero ya veía los primeros pasos de la muerte de Commodore…

Amiga

My top pick of Spring COMDEX was the Amiga.

The Amiga did have some problems. For instance, when Ken Sheldon and l approached the Atari booth, they practically ran out to grab us; I stood in the Amiga booth for 15 minutes before anyone spoke to me. Atari software was demonstrated by hackers; most of the Amiga software was demonstrated by clerical employees from Commodore headquarters.

None of that really mattered. What was important was that the Amiga booth was jammed. 1 could feel the excitement. It reminded me of the early days of microcomputers. Moreover, once I got past the clerks and secretaries, there were plenty of real hackers.

Mike Lehman, who originally wrote Pascal MT+ and was later a vice president of Digital Research, has started a new company called Maxisoft. The product is MaxiPlan, a combination spreadsheet and database with chart capability. MaxiPlan knows how to do a lot of statistical calculations. It will make databases and charts, and it will talk to you through the Amiga's speech synthesizer. You'll spend a while on the manual— this thing is powerful, and the instructions can be complicated— but it's worth the investment. Highly recommended.

TDI Software has Modula-2 compilers for both the Atari and Amiga machines. The Atari version is a new release that fixes some problems with the original. Both versions work and should make it simpler to transport programs from Atari to Amiga. Longtime readers know I'm a Modula-2 fan; this is a reasonable implementation, and TD1 is working to make it better. The chief problem is the documentation: TDI needs to give more and better examples of just how to write and compile simple programs. Pournelle's law of software documentation: You can't have too many examples. I wish TDI would learn it.

The Amiga is known for its graphics; one of the best graphics programs is Deluxe Paint by Electronic Arts. Alas, they use an obnoxious copy-protection scheme. That's its only real fault; otherwise. Deluxe Paint is glorious. There's just very little you can't do with it. You can color-cycle portions of your drawing, so that waterfalls have running water; zoom in for fine details; and suchlike. It's a lot of fun. EA also has various games, some interesting, some boring.

Mindscape is another company that has developed some interesting Amiga software. The Halley Project is a spaceflight game that's part arcade but largely strategic; it helps to know something about planetary astronomy.

Activision has a whole bunch of Amiga software, including Music Studio, which 1 haven't much got into but which looks wonderful, and a series of illustrated text adventure games, including Hacker, which some say is the most difficult adventure of that type ever written.

In other words, there's a great deal of Amiga software: business, games, educational, programming tools. That, however, wasn't the real hit.

What was really impressive was the Amiga Sidecar, a box that turns an Amiga into a 99 percent PCompatible. Moreover, since the Amiga is a multitasking machine, they were able to run PC software as just one job. It was eerie to watch Flight Simulator running as if on a PC and still see the famous Amiga bouncing ball in the background and a word-processing program running in the foreground. The Sidecar has both 8088 and 8087 chips and is supposed to sell for significantly less than a thousand dollars. An Amiga plus Sidecar plus hard disk would be one of the most powerful combinations around, and I had no problem designating that the number one pick of Spring COMDEX.

Problems

One problem I've had with the Amiga is that while I kept hearing about all the new software for it, I never got any. Commodore's people sent catalogs, while the Atari people sent software. At COMDEX, Bob Pariseau, vice president for software development and one of the original Amiga development team, promised to fix all that. He also arranged to get me a Sidecar as soon as it was available. 1 left COMDEX convinced that the Amiga was likely to be the product of the year.

Two weeks later, Commodore laid off nearly 200 people, including Bob Pariseau. There were 55 Amiga people in the West Coast office; 20 were let go. Moreover, many who didn't leave immediately were put on notice; others, seeing the handwriting on the wall, quietly began sending out their resumes. The rumor I hear is that the investment bankers want Commodore to reduce their payroll by 50 percent; given Commodore's financial situation, the company is in no position to argue.

The question, then, is whether Commodore has— and can keep— enough high-tech people to support the Amiga properly. Commodore says they can. So do Amiga enthusiasts.

Me, I don't know. The situation is made vastly more complicated because many of those laid off were required to sign, as a condition for getting a few more severance benefits, a particularly severe— I would say obnoxious— nondisclosure agreement, the first term of which is that the agreement itself is secret. This has made it very difficult to get a decent picture of what has really happened at Commodore, and as I write this in early June I don't think anyone knows.

So. I like the Amiga, and I was much impressed by the enthusiasm of the Amiga people at COMDEX. Of course, even then the Commodore top brass must have known that many of those enthusiasts wouldn't be with the company two weeks later. By the time you read this, we may know the end of the story. I can't say I'm very fond of Commodore's management, but I do wish the Amiga well. It's a heck of a machine.

Y no me voy sin rescatar este anuncio, con el que se lanzaba lo que sería el estándar oro de los monitores durante muchísimos años: los NEC Multisync, capaces de trabajar con básicamente cualquier ordenador de la época, y que en esta, su primera encarnación, era capaz de alcanzar los 800 por 560 de resolución en sus 13 pulgadas :-).

Anuncio de la gama de monitores de tubo NEC Multisync

Un día de estos, más :-).

#breBytes C++

Aprovechando la canícula, seguimos con nuestra versión light del repaso a la revista Byte de hace cuarenta años. Y suerte que nos hemos pasado al modelo light, porque el número de agosto del 86 no venía especialmente fuerte. Pero no puedo saltarme la sección de crítica de libros, porque ahí tenemos uno de los clásicos de la informática, la presentación de C++ por parte del creador del lenguaje, Bjarne Stroustrup. (Si no he buscado mal, la cuarta y última (de momento) edición se publicó en 2011.)

Book Reviews

THE C++ PROGRAMMING LANGUAGE

Reviewed by G. Michael Vose

One of the tenets of evolutionary theory states that changes in the environment cause subtle mutations in an organism that transform it into a new organism. The changing nature of the hardware environment of computers causes an analogous evolution of programming languages. Bjarne Stroustrup's The C++ Programming language describes one recent language mutation.

Following the example of its parent, Brian W. Kernighan and Dennis M. Ritchie's The C Programming language (also known as K&R or the "white" book), this book defines the superset of C called C++. Both books provide multiple chapter tutorials for their respective languages as well as the languages' official reference manuals. Both contain examples and exercises for readers to solve.

Stroustrup's book assumes a familiarity with C (referring the beginning reader to K&R) but is nearly 100 pages longer than the white book. C++ adds considerably to the complexity of an already obtuse lexicon. Furthermore, C++ provides the tools to allow an objectoriented approach to programming in C.

Evaluating a book like Stroustrup's is difficult because microcomputer implementations of C++ are just becoming available (see the What's New section). I have no concrete experience with the language and no facility for using the tutorial sections of the book. Therefore, the judgments I can make are limited to two areas: Does the book adequately describe the concepts of C++, and do the C++ extensions seem useful? The historical significance of both the book and the language will have to wait for the judgment of some future reviewer.

People familiar with C instantly recognize the significance of the name C++. C's increment operator is symbolized using two plus signs (++). The suggestion is that C++ increments the power of the language, and this is certainly true. But for many C programmers, adding new constructs takes a back seat to fixing some of the awkward aspects of the original language. The authors provide some of these fixes.

Programmers enjoy using C because of the freedom of expression it provides due to a rich set of operators and great flexibility in declaring and manipulating data types. C++ increases this freedom substantially by offering additional data types and constructs that permit programmers to more easily build complex data structures (a process known as data abstraction). The emphasis in C++ is on types and structure.

Y me tenéis que reconocer que es divertido leer la crítica de un libro en la que el revisor te dice cosas como que C++ suma considerablemente a la complejidad de un léxico ya obtuso (no seré yo el que le lleve la contraria, pero pegarle así a C…), para a continuación explicarte que evaluar el libro es complicado en ausencia de implementaciones de C++ (vamos, sin haber probado el lenguaje), y después explicar qué es eso de los objetos en programación (la orientación a objetos, como paradigma, data de finales de los cincuenta (del siglo pasado), pero no se había prodigado mucho hasta la llegada de C++ y sus diferentes «primos» (por mucho que Smalltalk ya llevase unos cuantos años corriendo por el mundo)). No está mal, por cierto, permitirse darse el lujo de darle una collejita a nada más y nada menos que Stroustrup (en aquel momento no era la leyenda que es hoy, claro) por permitirse el lujo de usar palabras como «clase» antes de definirlas. Ni dudar (razonablemente, dada la juventud y novedad de la cosa) del éxito de un lenguaje que, cuarenta años más tarde, se disputa la segunda posición del ranking de lenguajes de TIOBE con «papá C».

Se publica la crítica, por cierto, dentro de un número dedicado a la programación orientada a objetos (ya os decía que el tema comenzaba a popularizarse en aquella época) en el que escribe, entre otros, el creador de Objective C, el lenguaje de desarrollo para Apple hasta nada más y nada menos que 2014.

Si queréis seguir hojeando el número, en la misma sección de libros se critica también el Mind Over Machine del filósofo Hubert Dreyfus y su hermano Stuart, algo menos famoso pero aún así profesor emérito en Berkeley, que se dice pronto. El libro argumenta (siempre según la crítica) que nunca tendremos una verdadera inteligencia artificial porque los ordenadores carecen de intuición. La historia no se repite, pero rima, dicen. El crítico también se fija en un capítulo dedicado a los temores sobre la implantación de la IA en la educación. 1986.

Y también se puede recomendar, creo, pero para valientes, el discurso del recientemente fallecido Tony Hoare (ya premio Turing por aquel entonces), Mathematics of programming. Por aquello de incidir en que lo que se publicaba en los ochenta en revistas generalistas de informática tenía en muchas ocasiones un nivel estratosférico, entre otras cosas.

En fin. Algún otro día, más, pero como muy pronto, en septiembre.

devLecturas (II)

Cinco enlaces más de cosillas de desarrollo web entendido en sentido amplio (la edición anterior es de principios de junio, no sé yo si esto va a tener mucha continuidad, pero lo seguiremos intentando).

De los vídeos de la commit, celebrada a principios de junio, me han llamado la atención un par de charlas. La primera, una «nueva manera de testear el frontend», «test while developing«.

Y la segunda, la de Ramón Corominas sobre evaluación automática de accesibilidad:

Aprovechando que estoy con uno de accesibilidad, hace apenas unos días Olga Carreras repasaba la WCAG Evaluation Methodology (WCAG-EM) 2.0.

Volviendo a principios de junio, Manuel Matuzovic hablaba de encabezados «concientes de su contexto». La idea, si los navegadores acaban dándole soporte, es que finalmente podamos escribir bloques de código dándoles título con un <h1>, y que sea luego el navegador el que lo convierta en el h-loquesea conveniente usando un «offset» y le aplique el CSS adecuado, cosa especialmente interesante si se trabaja con componentes. De momento solo se está implementando en Firefox. Dedos cruzados para que lo adopten el resto de navegadores 🤞.

Y para cerrar (el enlace es más antiguo, pero yo la encuentro ahora), tenemos esta Retro UI library que no creo que use nunca, pero que me parece absolutamente maravillosa.

#breBytes El Commodore 128

Dijimos hace nada que dejaríamos de hacer nuestras lecturas mensuales de la revista Byte de hace cuarenta años, pero que amenazábamos con buscar alternativas. Isma señalaba en los comentarios lo que básicamente tenéis aquí abajo, y que a mí también se me había pasado por la cabeza: ya que el ejercicio de lectura en sí lo voy a seguir haciendo, no obligarme a hacer la entrada mensual y exhaustiva, pero, si aparece alguna noticia que me apetezca destacar, pues recogerla por el procedimiento habitual.

Y siempre hemos tenido la norma de que si aparece Commodore, lo recogemos…

¿Iba perdida Commodore en el 86? Pues el Amiga y sus 16/32 bits ya llevaban una buena temporada en el mercado, pero el 64 seguía vendiendo de manera mas que considerable, y alguien tuvo la idea de crear un «monstruo» con doble CPU, heredero del 64 pero con unos masivos 128 Ks de RAM y el doble también de velocidad de procesador, hacerlo compatible con el 64 hasta ser un 64 si se le pedía con un mínimo de amabilidad (G0 64, eran las palabras mágicas) y, por si dos ordenadores en uno no fuesen suficiente, un modo CP/M, cuando el CP/M seguía siendo un sistema operativo más que interesante.

Sobre el papel, una idea muy interesante: una máquina capaz de ejecutar la infinidad de soft que se había desarrollado para el 64 y para las máquinas CP/M, y de ir más allá con el 128. En la práctica, Commodore no vendió ni una máquina más que si hubiese seguido con el 64, nadie del mundillo CP/M le prestó la más mínima atención, y el software desarrollado para el 128 fue, redondeando un poco… absolutamente ninguno. Y todo ello costó un dinero en desarrollo y le quitó parte del poco marketing que se podían permitir las eximias cuentas de Commodore al Amiga, que ya no iba muy fino en su batalla con Macs y PCs. Commodore no moriría hasta mediados de la década de los 90, pero la cosa ya no pintaba bien :-(.

Compárteme:

Compárteme:

Compárteme:

Compárteme:

Compárteme: