<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.1.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: La complejidad del software</title>
	<link>http://blog.herraiz.org/archives/193</link>
	<description>Trabaja como si no necesitaras dinero, ama como si nunca te hubieran herido y baila como si nadie te estuviera mirando.</description>
	<pubDate>Sat, 22 Nov 2008 07:47:01 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.1.3</generator>

	<item>
		<title>by: Carlos Paramio</title>
		<link>http://blog.herraiz.org/archives/193#comment-57816</link>
		<pubDate>Thu, 15 Nov 2007 00:23:08 +0000</pubDate>
		<guid>http://blog.herraiz.org/archives/193#comment-57816</guid>
					<description>Otro detalle está en la expresividad de los lenguajes. Hay lenguajes que, en pocas líneas, son capaces de expresar funciones que otros requerirían centenares de ellas para lograr los mismos resultados. No tendría mucho sentido comparar resultados de complejidad de un programa escrito en C, con otro programa escrito en Ruby, teniendo en cuenta únicamente los aspectos indicados en el artículo. No quiero decir nada si a esto sumamos que, con un supuesto como este, la aplicación en Ruby utiliza técnicas de metaprogramación, o hace que no debas preocuparte por la desasignación de memoria pues para ello está el recolector de basura. Tampoco se pueden comparar los resultados en general obtenidos por lenguajes procedurales con los obtenidos por lenguajes funcionales, orientados a objetos, y otras hierbas.

La verdad es que has escogido un tema dificilillo para tu tesis :-)  Admiro mucho el trabajo que estás haciendo.</description>
		<content:encoded><![CDATA[	<p>Otro detalle está en la expresividad de los lenguajes. Hay lenguajes que, en pocas líneas, son capaces de expresar funciones que otros requerirían centenares de ellas para lograr los mismos resultados. No tendría mucho sentido comparar resultados de complejidad de un programa escrito en C, con otro programa escrito en Ruby, teniendo en cuenta únicamente los aspectos indicados en el artículo. No quiero decir nada si a esto sumamos que, con un supuesto como este, la aplicación en Ruby utiliza técnicas de metaprogramación, o hace que no debas preocuparte por la desasignación de memoria pues para ello está el recolector de basura. Tampoco se pueden comparar los resultados en general obtenidos por lenguajes procedurales con los obtenidos por lenguajes funcionales, orientados a objetos, y otras hierbas.</p>
	<p>La verdad es que has escogido un tema dificilillo para tu tesis <img src='http://blog.herraiz.org/wp-images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />   Admiro mucho el trabajo que estás haciendo.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Carlos Paramio</title>
		<link>http://blog.herraiz.org/archives/193#comment-57801</link>
		<pubDate>Thu, 15 Nov 2007 00:12:57 +0000</pubDate>
		<guid>http://blog.herraiz.org/archives/193#comment-57801</guid>
					<description>Yo ponderaría los resultados con las siguientes variables: Proporción de líneas de comentarios respecto al total del programa, proporción de nombres de funciones o de variables construidos como palabras compuestas de un diccionario (ya que son más legibles que otras en formato abreviado), y cosas así. Comparar el código objeto tiene un problema, y es que un programa ofuscado y otro con nombres de funciones o variables con sentido que generen el mismo código serán vistos en comparación como dos códigos de complejidad semejante. Hay que distinguir la complejidad del código fuente (que parece ser que es lo que te interesa) de la complejidad del código objeto.

Me gusta mucho más el concepto de búsqueda de patrones. ¿No sería genial disponer de una herramienta que, mediante una pequeña base de datos con los patrones más comunes, y algo de heurística, fuese capaz de detectar cuántos patrones típicos utiliza una aplicación? Cuando se usan patrones, un programador decente será capaz de detectarlos fácilmente y entender rápidamente el código. Es más, incluso un programador que desconozca un patrón determinado podría aprenderlo sin demasiada dificultad si lo encuentra por doquier en el código del programa, de manera que acabará acostumbrándose a interpretarlo en pocos segundos.</description>
		<content:encoded><![CDATA[	<p>Yo ponderaría los resultados con las siguientes variables: Proporción de líneas de comentarios respecto al total del programa, proporción de nombres de funciones o de variables construidos como palabras compuestas de un diccionario (ya que son más legibles que otras en formato abreviado), y cosas así. Comparar el código objeto tiene un problema, y es que un programa ofuscado y otro con nombres de funciones o variables con sentido que generen el mismo código serán vistos en comparación como dos códigos de complejidad semejante. Hay que distinguir la complejidad del código fuente (que parece ser que es lo que te interesa) de la complejidad del código objeto.</p>
	<p>Me gusta mucho más el concepto de búsqueda de patrones. ¿No sería genial disponer de una herramienta que, mediante una pequeña base de datos con los patrones más comunes, y algo de heurística, fuese capaz de detectar cuántos patrones típicos utiliza una aplicación? Cuando se usan patrones, un programador decente será capaz de detectarlos fácilmente y entender rápidamente el código. Es más, incluso un programador que desconozca un patrón determinado podría aprenderlo sin demasiada dificultad si lo encuentra por doquier en el código del programa, de manera que acabará acostumbrándose a interpretarlo en pocos segundos.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
