- Incluso después de que terminara la serie web, Crafting Interpreters necesitó 15 meses adicionales de trabajo para convertirse en un libro real, y finalmente quedó listo en edición impresa, ebook y PDF
- Para convertir un paquete de Markdown y PNG en un libro, hubo que crear desde cero un sistema de build en Dart, importación de XML a InDesign, automatización con JavaScript y validación de composición
- El resultado final fue un volumen de 8×10 pulgadas, 640 páginas, más de 200 mil palabras, 1,133 fragmentos de código y cientos de ilustraciones, con restricciones de layout mucho más exigentes que las del contenido web común
- Después vinieron 5 meses de revisión completa, copy editing profesional, 2 meses de composición, 2 semanas de trabajo en el índice, revisión de pruebas impresas y automatización para comparar PDFs
- En un libro técnico autopublicado, no basta con escribir: la automatización de build, layout, validación y distribución determina la calidad y el nivel de acabado del libro
Trabajo pendiente incluso después de terminar el contenido web
- El texto principal de Crafting Interpreters ya estaba terminado, pero en ese momento el resultado consistía en archivos Markdown y PNG convertidos en un sitio web mediante código Python
- Desde el principio, la meta era un libro físico de verdad, y después de subir el último capítulo a la web, el autor descansó alrededor de un mes
- Después de escribir todos los días durante casi 4 años, estaba bastante agotado, y la situación de inicios de 2020 tampoco era un buen momento para seguir trabajando
Un sistema de build rehecho en Dart
- Primero corrigió erratas y errores que los lectores habían reportado en issues de GitHub
- Después reescribió en Dart todo el sistema de build del libro
- El script de build del primer libro era un solo script en Python que renderizaba archivos Markdown por capítulo a HTML e insertaba fragmentos de código
- En Crafting Interpreters había que construir gradualmente, a lo largo de 30 capítulos, el código completo de dos intérpretes, así que se necesitaba un build más complejo
- El nuevo sistema de build podía generar como programa el código del intérprete hasta cierto capítulo o incluso hasta un punto específico dentro de un capítulo, compilarlo y ejecutarlo en pruebas automáticas
- Las herramientas basadas en Python eran más difíciles de mantener según el nivel de experiencia del autor y además eran lentas
- La versión en Dart generaba exactamente el HTML y el código de syntax highlighting que quería, y era 10 veces más rápida que la versión anterior en Python
- Tener mayor control sobre el procesamiento de Markdown también resultó útil más adelante para exportar XML para InDesign
Diseño del libro y elección del formato
- Diseñar el libro se parecía más a crear primero un framework y luego verter el contenido dentro, como en desarrollo web o de videojuegos
- En InDesign se configuran masters para definir márgenes y grillas de página, y styles para definir tipografías, estilos y colores de textos y objetos
- Crafting Interpreters tenía muchos elementos difíciles de diseñar
- Mucho texto principal
- Muchas notas laterales largas que explican justo al lado ciertas frases, código o ilustraciones
- Mucho código, y junto a cada fragmento de código había una explicación sobre su ubicación dentro del programa final
- El ancho horizontal tenía que considerar al mismo tiempo líneas largas de código, el espacio para notas laterales y el margen interior de un libro grueso
- Muchos libros típicos de CS en su estante medían 7.5 pulgadas de ancho, pero era difícil acomodar código, notas laterales y márgenes, así que decidió usar un ancho de 8 pulgadas
- En autopublicación había que usar los formatos limitados que soportan KDP e IngramSpark, y con 8 pulgadas de ancho, la opción razonable era 8×10 pulgadas
- En sentido vertical, el texto se alineó con una baseline grid clásica de 12 pt
Pipeline de XML para llevarlo a InDesign
- InDesign no entiende directamente Markdown ni el sistema de build del autor, así que copiar y pegar manualmente no era realista
- InDesign soporta importación de XML y aplicación automática de estilos según etiquetas
- Pero su soporte de XML tiene limitaciones para manejar etiquetas anidadas, así que no procesa bien algo como una etiqueta en cursiva dentro de un encabezado, como sí lo haría HTML
- Como el autor controlaba por completo el sistema de build, escribió un exportador XML personalizado que generaba etiquetas más fáciles de aceptar para InDesign
Automatización con JavaScript en InDesign y sus límites
- La importación de XML crea en InDesign un “story”, es decir, un flujo continuo de texto principal que sigue la cadena de cajas de texto
- El texto principal y los fragmentos de código entraban en ese flujo principal, pero las notas laterales y los location markers tenían que sacarse hacia un costado
- En el libro anterior, movía manualmente las notas laterales cortándolas y pegándolas en nuevas cajas de texto, pero en este libro había 1,133 fragmentos de código, así que ese método era inviable
- InDesign soporta scripting en JavaScript, pero la documentación y el entorno de depuración eran muy deficientes
- Sin depurador
- Sin stack traces
- Sin debug print normal
- Solo se podía usar
alert(), y cada llamada detenía el script
- El script en JavaScript encontraba las notas laterales y los location markers, los sacaba del flujo principal y los convertía en cajas de texto separadas
- La automatización del posicionamiento no llegó a completarse por completo
- Intentó colocarlos usando la función de anchor de InDesign y Object Style, pero en algunos casos desaparecía el borde de los fragmentos de código cercanos
- Al final, algunos location tags tuvieron que posicionarse manualmente
Edición y copy editing
- Hizo un pase de edición releyendo todo el texto principal de principio a fin
- Cada capítulo ya había pasado por tres drafts durante la escritura, pero lo revisó una vez más para ver el flujo del libro completo
- Ese trabajo tomó 5 meses, y corrigió la mayoría de los chistes repetidos
- Después contrató a la copy editor profesional Kari Somerton
- El workflow editorial habitual suele usar Microsoft Word y Track Changes, pero el autor quería mantener un workflow basado en plaintext y Git
- Kari Somerton aprendió a usar Git y el sistema de build personalizado, revisó todo el libro y encontró cientos de errores
- Aunque ya existían cuatro drafts y cientos de issues reportados por lectores, una copy editor profesional todavía encontró muchos problemas
Las restricciones de componer 640 páginas
- Una vez suficientemente pulidas las palabras, pasó a la composición por capítulo en InDesign
- El trabajo por capítulo repetía el siguiente flujo
- Crear un nuevo archivo de InDesign
- Exportar XML
- Importar el XML a InDesign
- Sacar notas laterales y location markers con JavaScript
- Configurar los anchors de los elementos de barra lateral
- Ajustar los espacios en blanco al final de las páginas
- Las primeras cinco etapas podían resolverse en unos 30 minutos por capítulo, pero el último ajuste de espacios era lo más difícil
- En la composición de libros hay varias restricciones de colocación vertical
- No se pueden cortar ilustraciones a la mitad de una página
- Es más fácil de entender si una nota lateral cabe dentro de una sola página
- También conviene evitar partir fragmentos de código entre páginas si es posible
- Hay que evitar que quede solo un encabezado al final de página
- También conviene evitar widows and orphans
- En estas situaciones, InDesign empuja contenido a la página siguiente, pero eso puede dejar grandes espacios en blanco al pie de página
- Las ilustraciones y los fragmentos de código se comportaban como un problema entrelazado de bin-packing, y por eso la composición de todos los capítulos tomó 2 meses
- Para reducir los espacios vacíos, fue necesario dividir fragmentos de código en dos, ajustar márgenes alrededor de imágenes o cambiar la altura de ilustraciones
Ilustraciones, índice y material preliminar/final
- Para las ilustraciones eligió dibujos en tinta y negro amigables para impresión, y en el escaneo inicial los capturó a 1200 DPI
- Exportarlos como bitmaps de alta resolución era fácil, pero colocarlos en el layout de página era difícil
- Como el texto no usaba el estilo de “ver Figura 123”, sino oraciones que apuntaban directamente a la ilustración de al lado, era necesario que las imágenes quedaran cerca
- En vez de contratar a un indexador profesional, volvió a recorrer todos los capítulos él mismo durante 2 semanas para crear el índice
- La función de índice de InDesign podía convertir texto seleccionado en entradas de índice y generar el índice completo, pero agregar las entradas en sí era repetitivo y tedioso
- Al final del libro iba el índice, y al principio iban la portada interior, la página de derechos, la dedicatoria, los agradecimientos y una tabla de contenido generada por InDesign
Diseño de portada
- El autor pensaba que la dimensión artística de la portada de un libro técnico quizá no era tan importante como la de una novela, pero como no estaba en una posición de obligar ventas por su cargo de profesor, dedicó mucho tiempo a la portada
- Al principio quiso usar una foto tomada por él mismo, pero no encontró una adecuada
- Al final decidió usar el lenguaje visual del libro: ilustraciones a pluma y tinta
- Redibujó en mayor tamaño y con más detalle una ilustración montañosa que explica el proceso de compilación, y también rehizo el lettering del título para darle una sensación manuscrita
- El título se basó en Acumin Pro Extra Condensed, impreso y luego calcado a mano para darle un aspecto imperfecto, y eligió una paleta de colores parecida a la de manuales scout mimeografiados de los años 50
Pruebas impresas y validación de cambios en PDF
- Subió el PDF a KDP, pidió una prueba impresa y una semana después recibió una caja pesada
- Solo al ver el libro físico pudo dimensionar la magnitud del proyecto como objeto material y no solo como archivos de datos
- Como en el proceso de composición había mucho trabajo manual, leyó directamente la prueba impresa para encontrar errores y los marcó con sticky notes
- Puso los archivos de InDesign en un repositorio Git, pero como eran archivos binarios grandes y opacos, no se podían ver diffs como con código fuente
- InDesign a veces cambiaba archivos aunque no pareciera haber modificaciones reales, lo que dificultaba saber qué había cambiado
- El autor escribió un script en Dart que extraía todas las páginas del PDF del libro y las convertía en una sola imagen PNG mosaico grande
- En cada commit exportaba el PDF, generaba la imagen mosaico y, con una acción de Photoshop, dibujaba bordes rojos sobre los píxeles distintos entre dos imágenes para encontrar las páginas modificadas
- Este método no mostraba directamente el detalle del cambio, pero sí indicaba qué páginas había que inspeccionar visualmente y permitía confirmar que solo se hubieran hecho los cambios esperados
Ebook y lanzamiento
- Después de terminar las correcciones de la prueba impresa, también produjo los ebooks para Kindle y EPUB
- Modificó su propio sistema de build para poder exportar el XHTML antiguo, los metadatos y el manifest que exige EPUB
- Con unas cuantas ejecuciones por línea de comandos generó los ebooks para Kindle y EPUB, y fue ajustando el CSS mientras los probaba en varios lectores
- Una vez listos los archivos finales, actualizó la primera página del sitio web del libro para enlazar a los puntos de compra, y también acomodó las fotos y el layout responsive
- Solo después de terminar la carga a las tiendas, actualizar el sitio y avisar a la mailing list, el libro quedó “realmente” terminado
Planes posteriores
- Incluso después de terminar el último capítulo, la gente le preguntaba cuál sería su siguiente trabajo o el tema de su próximo libro
- Después de pasar 6 años entregado a un solo proyecto, el autor no quería planear un libro nuevo por un buen tiempo
- También había muchas cosas pospuestas durante la pandemia, y por ahora su plan era descansar sin decidir todavía qué hacer
- Menciona posibilidades como hacer música, pescar, pasar tiempo con amigos y familia, o trabajar en un proyecto roguelike, pero no toma una decisión inmediata
- Dice que quizá algún día vuelva a querer hacer otro proyecto grande, pero que no le gustaría volver a dedicar 6 años a uno solo
1 comentarios
Comentarios de Hacker News
Esta página tiene tanto el enlace para comprar el libro como el enlace a la versión gratuita en línea: https://craftinginterpreters.com/
Definitivamente vale la pena comprar este libro. Solo el esmero que Nystrom puso en el diseño del libro físico ya basta para cualquiera a quien le gusten las ediciones impresas, y con las ilustraciones dibujadas a mano y la excelente redacción, diría que supera al 99% de los libros técnicos
Fue de lejos uno de los mejores libros técnicos que he leído. La forma en que cada capítulo deja código que evoluciona gradualmente y un programa ejecutable es una idea increíble, y me impresiona que el autor realmente haya logrado llevarla a cabo
Ya había escrito algo parecido antes, así que hojeé la parte del intérprete de recorrido de árboles, y aprendí mucho más siguiendo el intérprete de bytecode basado en C
Pensé que el artículo era reciente y que había salido una segunda edición
Quisiera felicitar al autor. Este libro es un recurso excelente que te mantiene enganchado no solo por la profundidad técnica en el área de lenguajes, sino también por los pequeños detalles del diseño y los gráficos. Se siente como un libro que seguirá vigente durante mucho tiempo
Empecé a seguir Crafting Interpreters en 2017 y, mientras avanzaba por la primera mitad del libro, escribí mi implementación de lox en Scala en lugar de Java, y en el proceso el tokenizador/analizador léxico/parser/intérprete dejaron de parecerme algo misterioso
Antes pensaba que era una especie de territorio visionario que solo cierto tipo de programadores podía tocar, y creo que eso se debió a la gran calidad de escritura de Nystrom y a su comprensión profunda del tema. Empecé a escribir el segundo intérprete en Rust, pero la vida se puso ocupada, no avancé mucho y al final no lo terminé. Creo que ya es momento de volver a ello. Este artículo es de hace varios años, pero no sabía que lo habían publicado como libro físico y, aunque no sea la forma óptima para mí de aprender, me dan ganas de comprar una copia para tenerla y apoyar al autor
Fue de lo mejor entre todos los libros técnicos de computación que he leído. De verdad fue una lectura muy disfrutable y aprendí muchísimo
Además del gran contenido técnico, está muy bien escrito, es entretenido y las ilustraciones también son muy buenas. Lo considero un logro monumental
Vale la pena escuchar esta excelente entrevista en la que Bob habla sobre este libro: https://corecursive.com/032-bob-nystrom-on-building-an-inter...
Irónicamente, me tomó 15 meses leer y terminar el libro :). Me identifiqué mucho con la situación del autor. Es un gran libro escrito por un autor constante y talentoso, y le agarré tanto cariño que hasta hice una página basada en lo que aprendí: https://hexmos.com/compiler
¿El autor pasó de ser diseñador gráfico a ingeniero de compiladores? Sorprendente e impresionante
Tengo este libro en mi estante. Será el siguiente libro sobre intérpretes que lea después de “Writing an interpreter in Go”, y ese libro tiene unas 200 páginas, lo cual me encanta
Acabo de terminar el analizador léxico en Rust en vez de Java, y tengo muchas ganas de seguir con el resto. Hasta ahora ha sido un libro excelente