+\layout Section
+
+Conclusiones
+\layout Standard
+
+Para analizar si el lenguaje cumple sus objetivos, vamos a analizar esos
+ objetivos (ver página
+\begin_inset LatexCommand \pageref{sub:Objetivo-del-lenguaje}
+
+\end_inset
+
+) punto por punto.
+ Para el análisis se asume que todo lo propuesto en el lenguaje está correctamen
+te implementado (que, como vimos a lo largo de este documento, no es necesariame
+nte cierto).
+\layout Paragraph
+
+Reducir el costo de desarrollo en al menos un 10% agregando características
+ que mejoren la productividad y ajustando las características del lenguaje
+ para que los errores más comunes que más cuestan reparar sean evitados
+ de base.
+\layout Standard
+
+Es difícil evaluar la ganancia en el costo de desarrollo (más aún si no
+ está claro en comparación a qué se quiere reducir el costo), pero sin dudas
+ el disponer de un recolector de basura, propiedades y otras muchas característi
+cas muy deseables deben reducir de forma considerable el costo de desarrollo.
+\layout Standard
+
+Con respecto a los mecanismos para evitar los errores más comunes, por lo
+ que he probado del lenguaje parece cumplirlo bastante bien, si uno se toma
+ el trabajo de utilizar todas las herramientas que se le provee, en particular
+ de las comentadas en la sección
+\begin_inset LatexCommand \vref{sec:Programación-segura}
+
+\end_inset
+
+.
+\layout Standard
+
+En términos generales podría decirse que sí, cumple este objetivo.
+\layout Itemize
+
+Hacer más fácil escribir programas portables entre compiladores, arquitecturas
+ y sistemas operativos.
+\layout Paragraph
+
+Soportar programación multi-paradigma; es decir, como mínimo, soportar los
+ paradigmas: imperativo, estructurado, orientado a objetos y programación
+ genérica.
+\layout Standard
+
+Definitivamente cumple con estos objetivos mínimos, es un lenguaje netamente
+ imperativo, con soporte de estructuras y todos los requerimientos de la
+ programación orientada a objetos (a través de las clases, ver sección
+\begin_inset LatexCommand \vref{sec:Orientación-a-objetos}
+
+\end_inset
+
+).
+ Además provee un mecanismo para programación genérica, a través de templates
+ (ver sección
+\begin_inset LatexCommand \vref{sub:Polimorfismo-estático}
+
+\end_inset
+
+).
+\layout Paragraph
+
+Tener una curva de aprendizaje corta para programadores que se sienten a
+ gusto con C o C++.
+\layout Standard
+
+Aunque tiene varias diferencias con C y C++, la sintaxis es muy similar
+ y su uso en general también.
+ Particularmente encuentro bastante molesto y confuso que las instancias
+ de clase se manejen por referencia (en realidad encuentro confuso que sean
+ una excepción).
+ A pesar de esto, sin dudas la curva de aprendizaje es corta (aunque no
+ nula), así que creo que este objetivo también lo cumple satisfactoriamente.
+\layout Paragraph
+
+Proveer acceso irrestricto de bajo nivel cuando sea necesario.
+\layout Standard
+
+Definitivamente también lo cumple.
+ Soporta punteros (pág.
+
+\begin_inset LatexCommand \pageref{sub:Punteros}
+
+\end_inset
+
+), assembly embebido (pág.
+
+\begin_inset LatexCommand \pageref{sub:Assembly-embebido}
+
+\end_inset
+
+), alocación de memoria manual (pág.
+
+\begin_inset LatexCommand \pageref{sub:Variables}
+
+\end_inset
+
+), control sobre el recolector de basura (pág.
+
+\begin_inset LatexCommand \pageref{sub:Recolección-de-basura}
+
+\end_inset
+
+), etc.
+\layout Paragraph
+
+Hacer que implementar un compilador sea mucho más sencillo que para C++.
+\layout Standard
+
+Esto tampoco puede ser evaluado certeramente de forma sencilla, pero viendo
+ como se simplificaron varias características de C++ que son particularmente
+ complicadas de implementar (como la herencia múltiple) es de esperarse
+ que hacer un compilador de D sea más sencillo que uno de C++, pero no podría
+ afirmarlo porque tampoco conozco las complicaciones que adhiere D con las
+ características no presentes en C++, como para saber cómo sale en el balance.
+\layout Paragraph
+
+Ser compatible con la ABI local de C.
+\layout Standard
+
+Lo cumple, puede interactuar con C sin inconvenientes.
+\layout Paragraph
+
+Tener gramática libre de contexto.
+\layout Standard
+
+Tampoco es algo que haya podido probar de forma sería, pero se eliminan
+ construcciones de C que dependían del contexto como
+\family typewriter
+(foo) - p;
+\family default
+ que en C/C++ puede ser interpretado como la resta de
+\family typewriter
+ p
+\family default
+ a
+\family typewriter
+foo
+\family default
+ si
+\family typewriter
+ foo
+\family default
+ es una variable o como
+\family typewriter
+-p
+\family default
+
+\emph on
+casteado
+\emph default
+ a
+\family typewriter
+foo
+\family default
+ si
+\family typewriter
+foo
+\family default
+ es un tipo definido por el usuario.
+ En D esa expresión es la resta, ya que para hacer el
+\emph on
+cast
+\emph default
+ hay que usar el operador:
+\family typewriter
+cast(foo) - p
+\family default
+.
+\layout Standard
+
+Entonces, si bien no puedo asegurar que el objetivo esté cumplido, sí puedo
+ asegurar que está más cercano a tener una gramática menos dependiente del
+ contexto que C/C++.
+\layout Paragraph
+
+Escribir fácilmente aplicaciones internacionalizadas.
+\layout Standard
+
+Tengo la sensación de haber visto en algún momento que había una forma de
+ poner literales de string internacionalizables en el lenguaje, con el siguiente
+ formato:
+\family typewriter
+_
+\begin_inset Quotes erd
+\end_inset
+
+hola
+\begin_inset Quotes erd
+\end_inset
+
+
+\family default
+.
+ Esa característica parece que no existe más, al menos en la documentación,
+ así que realmente no veo de qué manera se cumple este objetivo.
+\layout Paragraph
+
+Incorporar Programación por Contrato y metodologías de casos de prueba.
+\layout Standard
+
+Lo cumple muy bien, utilizando todo lo visto en la sección
+\begin_inset LatexCommand \vref{sec:Programación-segura}
+
+\end_inset
+
+.
+\layout Paragraph
+
+Ser capaz de construir programas independientes y livianos.
+\layout Standard
+
+Los programas son sin dudas menos livianos e independientes que los de C,
+ porque además de depender de la biblioteca estándar de C (aunque no depende
+ necesariamente, la biblioteca estándar de D la usa extensivamente), depende
+ de la biblioteca propia de D, que incluye al código del recolector de basura.
+ Compilando estáticamente, un programa que no hace nada:
+\layout LyX-Code
+
+int main()
+\layout LyX-Code
+
+{
+\layout LyX-Code
+
+ return 0;
+\layout LyX-Code
+
+}
+\layout Standard
+
+su versión en C y C++ ocupan 460KB, mientras que la versión en D ocupa 1.2MB.
+\layout Standard
+
+Sin embargo, si hacemos el clásico ejemplo de
+\emph on
+hello world
+\emph default
+:
+\layout LyX-Code
+
+int main()
+\layout LyX-Code
+
+{
+\layout LyX-Code
+
+ printf("hola mundo!
+\backslash
+n");
+\layout LyX-Code
+
+ return 0;
+\layout LyX-Code
+
+}
+\layout Standard
+
+Si la versión en C++ la escribimos usando la STL
+\begin_inset Foot
+collapsed false
+
+\layout Standard
+
+Standard Template Library (la biblioteca estándar de C++)
+\end_inset
+
+:
+\layout LyX-Code
+
+#include <iostream>
+\layout LyX-Code
+
+int main()
+\layout LyX-Code
+
+{
+\layout LyX-Code
+
+ std::cout << "hola mundo!
+\backslash
+n";
+\layout LyX-Code
+
+ return 0;
+\layout LyX-Code
+
+}
+\layout Standard
+
+En C sigue ocupa 461KB, en D sigue ocupando 1.2MB y la versión en C++ pasa
+ a ocupar 1.1MB, lo que pone en evidencia la alta complejidad de la biblioteca
+ estándar de C++.
+\layout Standard
+
+Por lo tanto, si bien D no puede ser tan liviano como C, sí puede sacarle
+ una buena ventaja a C++ en lo que es el manejo de
+\emph on
+strings
+\emph default
+ u otras estructuras que provee la STL en C++ que son muy complejas.
projects / z.facultad / 75.31 / presentacion.git / blobdiff