Barrapunto

El libro sobre el kernel... la verdad, que levanten la mano los que hayan hecho algo más con el código del kernel que compilarlo y/o aplicarle algún parche que necesitaban. Innecesario para la mayoría

El libro está muy bien escrito y comenta de forma práctica muchas de aquellas cosas que en la universidad se estudian como solo teoría.
Además es muy inspirador. Al ver como se toman las decisiones en el kernel de Linux puede ayudarte a tomar tus propias decisiones al desarrollar un proyecto. Es uno de aquellos libros inspiradores que te hacen sentir más inteligente cuando los lees. Lo que en el libro de Tanenbaum cuesta de recordar debido a su densidad, el libro de Robert Love te lo enseña a través de ejemplos reales con anécdotas incluidas.

Para todos aquellos que han tenido la mala suerte de experimentar en sus profesores aquello de "el que sabe lo hace y el que no se dedica a la enseñanza" el libro de Love les dará una visión más cercada al mundo real del desarrollo de un sistema operativo.

8) Mucha programación procedural y OO (que para mí es un subconjunto de la procedural), pero nada de programación funcional o lógica. ¡Ni un libro de Lisp de esos que tanto gustan a los informáticos sobrados! Todo el mundo pone el SICP en sus listas, hombre...

Estaba pensando lo mismo que tú (aunque yo considero que la programación procedural es un subconjunto de la imperativa). De vez en cuando es bueno mirar otros paradigmas de programación. Aunque al final no los termines usando, descubrirás nuevas maneras de hacer las cosas.

Si hubiera puesto el SICP, le habrías dicho algo parecido a lo del TAOCP ¿no? O te haces el listo en un plan o en el otro, pero no en los dos a la vez, un poquito de consistencia, por favor.

Fuera de coña, el TAOCP no creo que se lo haya leído nadie, no son exactamente libros para leer. Pero utilizarlo, seremos por lo menos cien.

y ese de hopcroft de automatas, y te haces una maquineta en compiladores... por cierto, el del drangon es el que nombran en [paraguaabierto:on]Hackers[sigoconelparaguasabiert o:on]

Cuando empecé a hacer compiladores, alguien me dijo "Joder, ¿no te has leído 'El Dragón Rojo'? Es que si no te has leído eso, no te has leído nada". Bueno, información para el viajero. Está muy bien, muy gracioso, y todo eso. Pero tengamos en cuenta que fue escrito cuando el tiempo de compilación era CRITICO. Tenías que optimizar al máximo posible. Es una guarrada increíble hacer análisis semántico en el analizador sintáctico, pero en las facultades lo siguen enseñando así porque nadie tiene los cojones de defender ante una clase que los conocimientos de Aho y Ullman no son absolutos y se quedan desfasados con el tiempo. No existen libros que deban estar hasta el fin de los tiempos en la estantería de un ingeniero informático, pero desde luego, el Dragón Rojo debería ser un libro para leer una vez y basta. Eso sí, existen otros libros de Aho y Ullman bastante más interesantes (mucho más teóricos) y que pueden ser más útiles al escribir un compilador y, en general, al leer cualquier fichero de entrada desde un programa.

Claramente. No hay ninguno en esa lista sobre desarrollo de compiladores. Precisamente, diseño de lenguajes es una de las áreas donde los ingenieros informáticos tienen (tenemos) mucho que decir.

Algunos errores que aparecen en implementaciones de Java y .NET todavía hoy, ya están comentados en este y otros libros de compiladores y procesadores de lenguajes.

¿Dos libros de UML? La ingeniería del software, más que otras areas de la informática, va a modas. El UML está muy de moda ahora, pero probablemente no sea el buque insignia de aquí a unos años. Dos libros son excesivos.

Te aclaro 2 puntos:

• Sólo hay un libro de UML ahi. El otro libro va del Proceso Unificado de Modelado (UP) [amazon.com]. UML es un lenguaje de modelado. El UP es una metodología de desarrollo software. Quiero decir, aparte de sus creadores, no tienen nada que ver ambos conceptos. Es habitual el error de pensar que UML es un método de desarrollo. UML es un lenguaje del la mayor parte de usuarios sólo conoce su notación gráfica. Lenguaje y método de desarrollo son dos cosas totalmente distintas, aunque tienen los mismos creadores: los "Three Amigos"
• UML no es una moda por Dios. Ruby, Java o PHP pueden ser modas. UML es un lenguaje de modelado. Que tiene sus detractores y defensores. Pero es un lenguaje de modelado software de propósito general, el más extendido. Esto significa que, en el caso de que sepas modelar, UML te permite especificar modelos de una manera estándar, y cualquiera puede entenderlos. Que puedes usar diferentes herramientas que usan la notación. Que puedes hacer esbozos de tus modelos en una pizarra durante una reunión. Que puedes alimentar herramientas generadoras de código con ellos. Etc. Vamos, las ventajas derivadas de ser un estándar.

Mucha programación procedural y OO (que para mí es un subconjunto de la procedural)

Te compadezco si realmente piensas eso, porque significa que no has entendido nada.

No debería de puntuarse positivamente un comentario que contiene errores conceptuales de tal calibre. La gente que no sepa del tema recibe información incorrecta bien valorada con el consecuente "desaprendizaje". Y estamos hablando de errores de concepto que afectan al desarrollo de software como una disciplina de ingeniería, por lo que considero el asunto serio.