jueves, febrero 26, 2009

Lo que Paul Graham ha aprendido con Hacker News

Hacker news es un sitio de envío y comentario de noticias muy al modo de reddit (o digg o menéame), pero con temática muy definida (temática técnica, hacker en el sentido MIT ), con editores estrictos y con políticas severas de ontopic. Pues Paul Graham, su creador ha escrito What I've Learned from Hacker News, o sea, lo que ha aprendido con el sitio. Se puede estar de acuerdo o en desacuerdo en algunas cosas, pero es sin duda interesante. Extracto, lo que me ha llamado la atención:

Recuerda, la motivación original pata Hacker News fue testear un lenguaje nuevo, uno centrado en experimentar con el diseño de lenguajes, no en el rendimiento. Cada vez que el sitio se vuelve lento, me refuerzo a mi mismo recordando la famosa cita de McIlroy y Bentley:
La clave del rendimiento es la elegancia, no un batallón de casos especiales.

Y busco los cuellos de botella que puedo eliminar con menos código. Así he sido capaz de mantener un rendimiento mediocre a pesar de que el crecimiento se ha multiplicado por catorce.


Probablemente lo más importante que he aprendido acerca de la "disolución" es que se mide más por comportamiento que por usuarios. Es el mal comportamiento lo que hay que mantener alejado más que a las malas personas. El comportamiento de los usuarios es sorprendentemente maleable. Si se espera de la gente que se comporte bien tiende a hacerlo. Y viceversa.


Lo más peligroso de la portada son las que es demasiado fácil votar positivo. Si alguien prueba un nuevo teorema, le lleva tiempo al lector decidir si vota positivo o no.Un cómic divertido cuesta menos. Una crítica con un slogan como título cuesta cero, porque la gente lo vota sin ni siquiera visitar el enlace.


La forma más peligrosa de de comentario estúpido no es el argumento largo pero equivocado sino el chiste tonto. Los argumentos largos pero equivocados son bastante raros. Hay una gran correlación entre la calidad y la longitud del comentario.


[...]Visitar un foro online sólo cuesta un clic y se parece mucho superficialmente a trabajar. Puedes estar gastando tu tiempo, pero no estás parado. Alguien esta equivocado en Internet, y tú estás arreglando el problema.


Digg es conocido por su falta de trasparencia. La raíz del problema no son los tipos que llevan Digg sean especialmente furtivos, sino que usan un algoritmo equivocado para generar la portada. En lugar de subir conforme van teniendo más votos, como en Reddit, las historias empiezan arriba y las nuevas que van llegando las van empujando hacia abajo.

La razón de la diferencia es que Digg deriva de Slashdot mientras que Reddit de delicious/popular. Digg es Slashdot con votos en lugar de editores y Reddit es delicious/popular con votos en lugar de agregar a favoritos (Aún se pueden ver los fósiles de sus orígenes en sus diseños gráficos.)


Otra cosa que he aprendido de este experimento es que si vas a distinguir a las personas, hazlo bien. Este es uno de esos problemas en los que no funciona al prototipado rápido.

De hecho este es el argumento intelectualmente honrado para no discriminar a varios tipos de personas. La razón no es que todo el mundo es igual, sino que es malo hacerlo de modo incorrecto y es difícil hacerlo bien.
Yo particularmente estoy de acuerdo en casi todo. Sólo puntualizaría que hay honrosas excepciones en la correlación entre longitud y calidad. Un enlace relevante, una cita, a veces es breve pero muy relevante en la discusión. De todos modos por eso habla de correlación :)

La misma entrada y más comentarios en Lo que Paul Graham ha aprendido con Hacker News en barrapunto

martes, febrero 17, 2009

¿Varios pájaros de un tiro?

Vía intertwingly, el blog de Sam Ruby, me encuentro con una cita extraída de una de las listas del W3C que traduzco sin más:
Un error muy común que los ingenieros de software cometen al diseñar una arquitectura es fijarse en cinco problemas, ver lo que tienen en común e intentar resolver los cinco a la vez. El resultado es casi siempre una solución por debajo de lo estándar para todos ellos.

Sí, una tendencia común, más acusada curiosamente en los desarrolladores que se intentan preocupar por la calidad de su trabajo. Para no caer inercialmente en ella habría que evaluar lo económico del desarrollo con lo limitado de las soluciones, algo que demasiadas veces no se hace.

Me ha recordado además a un "cartel motivador" sobre el principio de responsabilidad única que vi hace poco en reddit (Aquí se pueden ver todos los carteles, por si a alguien le son de utilidad :)

Ah, ya que estoy aquí, recomiendo la lectura del blog de Sam y de las listas relativas al HTML5 para ver flames de altura :)


Actualización egórica: A través de una detección automática de referencias Sam se ha enterado de mi enlace y le ha gustado mi referencia al "cartel motivador", que le da más argumentos en el flame. Y me ha enlazado en un comentario. Nunca lo hubiera pensado :)

La misma entrada y más comentarios en ¿Varios pájaros de un tiro? en barrapunto

jueves, febrero 05, 2009

Epigramas sobre programación

Siguiendo un enlace en technovelty he llegado a un artículo de Alan J. Perlis en el que a través de ciento treinta epigramas trató, en 1982, de capturar algunos de los aspectos más curiosos, desconcertantes y antiintuitivos de la computación en general y la programación en particular. Han pasado más de veintiséis años, pero mucha de su naturaleza creo que sigue intacta. Algunos creo haberlos leído en otra parte y supongo que al que lea esto le pueden sonar, pero me gustan, así que aquí van. Traduzco los que me han parecido mejores:

Epigramas:

7. Es más fácil escribir un programa incorrecto que entender uno correcto.

8. Un lenguaje de programación es de bajo nivel cuando sus programas requieren atención sobre lo irrelevante.

9. Es mejor tener 100 funciones operando sobre una estructura de datos que 10 funciones sobre 10 estructuras de datos.

14. A la larga cualquier programa se vuelve rococó. Después escombros.

15. Todo debería desarrollarse de arriba a abajo, excepto la primera vez.

17. Si alguien parece que está asintiendo cuando le explicas tu programa, despiértale.

19. Si un lenguaje no cambia el modo en el que ves la programación es que no merece la pena.

21. La optimización dificulta la evolución.

31. La simplicidad no precede a la complejidad, la sigue.

40. Hay dos modos de escribir programas sin errores. Sólo la tercera funciona.

57. Es más fácil cambiar la especificación para que se ajuste al programa que al contrario.

58. Los locos ignoran la complejidad. Los pragmáticos la sufren. Algunos pueden evitarla. Los genios la eliminan.

63. En computación, los invariantes son efímeros.

65. No te equivoques: los ordenadores procesan números, no símbolos. Medimos nuestro conocimiento (y control) de una actividad en la medida en la que podemos arimetizar.

75. Debido a su vitalidad la informática está a la busca desesperada de nuevos clichés: la banalidad calma nuestros nervios.

93. Cuando alguien diga "Quiero un lenguaje de programación en el que sólo tenga que decir lo que deseo hacer", regálale una piruleta.

95. No tengas buenas ideas si no eres capaz de responsabilizarte de ellas.

104. La prueba del valor de un sistema es su existencia.

115. Mucha gente encuentra el concepto de programar obvio, pero hacerlo les resulta imposible.

MetaEpigramas:

124. Los epigramas son macros, porque son ejecutados en tiempo de lectura.

125. Los epigramas cristalizan incongruencias.

127. Los epigramas desdeñan los detalles y lo hacen con intención: son una documentación de alto nivel excelente.
El lector atento verá que si se juntan la 8 y la 93 no existen lenguajes de alto nivel. Pero si se mezcla con la 125 ya no está tan claro. Bueno, para pensar un rato. Pero no demasiado, que luego hay que codificar :)


La misma entrada y más comentarios en Epigramas sobre programación en barrapunto

miércoles, febrero 04, 2009

5 Secrets To Ninja Writing

5 Secrets To Ninja Writing. (Vía reddit)

Es mucho más recomendable pinchar en el enlace anterior si conoces el blog de Jeff Atwood, Coding Horror.

Está muy logrado, sobre todo la parodia del abuso de la autorreferencia, un vicio muy de blogstar, muy feo :)

La misma entrada y más comentarios en 5 Secrets To Ninja Writing en barrapunto