October 2008 - Artículos
Siguiendo con la reflexión expuesta en el primer capítulo de esta serie, otro fenómeno en el cual estaremos renunciando a cierto nivel de control sobre nuestros desarrollos a cambio de un incremento en nuestra productividad es la adopción de un lenguaje de tipo declarativo (también conocido como descriptivo o funcional). Este fenómeno va incluso más allá de una simple renuncia a nuestro nivel de control, también en cierto modo estamos renunciando al código. Y con esto último no sólo quiero decir que terminaremos escribiendo aplicaciones con la misma funcionalidad y menor cantidad de líneas de código, sino que además estaremos cambiando de paradigma de programación.
El repaso y análisis sobre los diferentes paradigmas de programación existentes bien merece un capítulo aparte en esta serie (y por tanto, trataré de publicarlo lo antes posible aquí), pero adelantándonos un poco a dicho capítulo, diremos que el cambio de paradigma procedimental por un paradigma declarativo implica aprender a describir qué queremos que suceda en una aplicación y dejaremos el cómo llevarlo a cabo a las capas subyacentes del compilador y la plataforma que estemos empleando.
En la programación procedimental (también conocida como imperativa y, dicho sea de paso, el uso de la palabra “procedural” es apropiado en lengua inglesa para referirnos a este concepto, pero no es una palabra reconocida por la Real Academia Española de la Lengua) generalmente debemos pensar y elaborar el cómo nosotros mismos. No hay ninguna diferencia entre el hecho de que estemos programando en ensamblador o en otro lenguaje como C, C++, C#… El modo de construir nuestro programa será articular una por una las instrucciones que queremos que se ejecuten, ya que de ningún otro modo serán ejecutadas. En la programación procedimental sólo se ejecuta aquello que nosotros, imperativamente, exigimos que sea ejecutado.
Por el contrario, en la programación declarativa, el concepto imperativo de órdenes desaparece casi por completo. Mientras que en ciertas ocasiones aún deberemos (y por supuesto, podremos) especificar una serie de acciones a ejecutar, los detalles relativos a “procesos” y/o “procedimientos” desaparecen de nuestra realidad cotidiana, de igual modo que los exámenes parciales desaparecieron de mi realidad cotidiana cuando salí de la Universidad (ánimo amigos!). Definitivamente, dejaremos estas tareas en manos del compilador subyacente, que se encargará de procesar en el momento oportuno cada sentencia declarativa y generar al vuelo su equivalente conjunto de órdenes procedimentales de la forma más optimizada posible. Remarcando el concepto, habremos definido qué queremos obtener, y nuestro compilador se habrá encargado de los detalles relativos a cómo obtenerlo de una manera eficiente.
Ofreciendo una analogía no relacionada con la Informática, la programación declarativa es bastante similar al modo en que diseñaríamos una casa y dejaríamos los detalles técnicos en manos de quien la fuera a construir. Describiríamos la distribución de habitaciones, el color de las paredes, la ubicación de puertas y ventanas… Es decir, especificaríamos cuál es el aspecto de lo que queremos obtener finalmente. No obstante, dejaríamos en manos de los constructores aquellas cuestiones internas como el cableado eléctrico, el sistema de tuberías, etc.
Obviamente, en el proceso de construcción de nuestra casa no deseamos que se emplee el doble de metros de cableado eléctrico de lo que es realmente necesario, pero a menos que deseemos meternos directamente en un nivel de abstracción muy bajo, como el nivel en que se desenvuelve un programador procedimental, dejaremos estas decisiones en manos de arquitectos u obreros, de igual modo que haríamos con nuestro compilador en el contexto software y confiaremos en su buen hacer, en favor de la eficiencia.
Llegados a este punto de la serie hemos analizado la importancia de escoger un nivel de abstracción apropiado en nuestros desarrollos software, y también hemos establecido una serie de diferencias entre paradigmas de programación (qué queremos conseguir y cómo conseguirlo)… evaluando los pros y contras de una y otra alternativa. De este modo, hemos transitado por el puente desde los lenguajes imperativos de más bajo nivel de abstracción (lenguaje máquina) hasta los lenguajes descriptivos de alto nivel, que nos permitirán gozar de una potencia expresiva suficiente para crear nuestras propias abstracciones, nuestros propios modelos. Pero eso será en el próximo capítulo, por ahora realizaremos una parada y disfrutaremos de otro bello paisaje en Stanley Park…
Entre un anuncio y otro del PDC, comenzaré con la “Serie Filosófica” que os prometí llevar a cabo durante esta semana. Puesto que lo prometido es deuda, ahí va la primera entrega…
Seguro que muchos de vosotros habréis pensado en numerosas ocasiones acerca de estos tres términos: “control”, “poder” y “confianza”. Al igual que vosotros, yo también he pensado, luego existo (probablemente en un lugar cercano a 0xFF4A7C dentro del LR, aka, Life Runtime)…
Preguntad a cualquier desarrollador con bastantes años de experiencia (o a vosotros mismos) y seguramente será capaz de recordar el momento exacto en que tuvo que renunciar a cierto nivel de control a cambio de adoptar un lenguaje de programación de más alto nivel. Si alguno de vosotros comenzó a escribir sus programas en lenguaje ensamblador, en algún momento tomaría la decisión de dejar de ser Todopoderoso y darle a algún compilador como el de C la oportunidad de tomar el control sobre ciertas secuencias de instrucciones del lenguaje máquina generado. Si por el contrario comenzaste directamente escribiendo código en C, en algún momento darías el brazo a torcer y asumirías que conocerlo todo, todo y todo acerca de cada puntero resulta interesante en muchos aspectos pero a pesar de ello no es una de las pautas más recomendables para llevar un ritmo de vida sano, feliz y socialmente aceptable. Fue en ese momento cuando decidiste aportarle un “plus” a tu vida como desarrollador, o más bien dos, y comenzar a sacar partido de las ventajas del lenguaje C++. Finalmente, decidiste dejar las cuestiones relativas a la gestión de memoria en manos de tu compilador, de igual modo que cuando te marchas de vacaciones le dejas las llaves de casa al vecino para que riegue tus plantas, y en función de donde vivas tu vecino se llamará Visual Basic, C# o Java, por citar algunos.
Aquellos programadores capaces de llevar a cabo esta transición de manera satisfactoria son los que antes o después tuvieron que abordar una cuestión existencial en la vida del Ser Humano, y los lenguajes de programación como conjunto de reglas y modelos para la representación de una realidad no han sido ajenos a este fenómeno: En muchas áreas del conocimiento humano, la pérdida de control sobre los hechos se traduce irremediablemente en una pérdida de poder sobre las decisiones que los guían.
Afortunadamente en la materia de estudio que nos ocupa en esta serie, esta ecuación no se cumple. Por varios motivos: el primero de ellos, sacrificar cierto nivel de control sobre nuestros programas es siempre una elección nuestra; y en segundo lugar, dicho sacrificio se ve compensado por un incremento en potencia expresiva y productividad. Expresándolo en términos más cotidianos, diremos que tras cada una de las transiciones de un lenguaje a su inmediato superior en nivel de abstracción, comentadas en el segundo párrafo, éramos capaces de alcanzar los mismos objetivos, con menor cantidad de código. De este modo, las eventuales pérdidas de rendimiento que se puedan producir, entre la optimización realizada ad-hoc por el programador ante cada fragmento de código y las optimizaciones genéricas automatizadas por parte del compilador, se veían compensadas con una considerable mejora en los niveles de fiabilidad y mantenibilidad (expresándolo en términos puristas diremos que la gráfica evolutiva que representa esta ecuación se aproxima a la universalmente conocida Ley de Moore)
La cuestión clave que estamos asumiendo aquí nos lleva al tercer término de los citados en el título del post: confianza. Deberemos depositar nuestra confianza en el compilador de turno, de la plataforma de turno, que nos ofrezca esta simplificación. Es decir, garantizaremos los niveles de fiabilidad y rendimiento de nuestras aplicaciones basándonos en dichos compiladores, en su fiabilidad y en su rendimiento a la hora de llevar a cabo la tarea para la cual fueron designados (simplificar la nuestra!).
En el fondo, lo que estaremos haciendo es depositar nuestra confianza en los desarrolladores de dichos compiladores, en su integridad, profesionalidad y habilidades como Ingenieros. Afortunadamente, podemos presumir de una buena salud en este punto, de profesionales altamente cualificados desarrollando compiladores y herramientas al servicio del resto de profesionales… y, en última instancia, ante eventuales fallos deberemos empujar en la misma dirección que ellos. ¿Cuál es esta dirección? Vertical. ¿En qué sentido vectorial? Hacia arriba… ¿Respecto a qué magnitud? Nivel de abstracción. ¿Y qué es la abstracción? Como he tratado de dejar patente a lo largo de este post, la abstracción, amigos míos, es ignorancia selectiva.
Por fin comenzó el PDC, hace unas 5h, y ya ha sido desvelada la primera de las grandes sorpresas reservadas para la ocasión: Microsoft Azure. Veamos detenidamente qué es Azure, qué objetivos persigue, cuál es su arquitectura y analicemos a fondo capa por capa de la mano del propio Director del equipo de desarrollo de Azure.
¿Qué es Microsoft Azure?
Azure es un sistema operativo basado en cloud services, dichos servicios proporcionan soporte para desarrollo, alojamiento de servicios remotos y gestión del propio sistema, todo ello en la nube. El propósito fundamental de Azure es proporcionar a aquellos desarrolladores que deseen construir aplicaciones en la nube una serie de herramientas de desarrollo y un entorno donde alojar sus propios servicios (un datacenter remoto).
Por el momento, no se han revelado detalles acerca del precio que tendrá este producto en el mercado, su fecha de salida o el tipo de licencia bajo el que será distribuido. A lo largo del día de hoy se hará pública la primera CTP de Azure, la cual constará de una SDK y de acceso al DataCenter remoto (gestionado por Microsoft).
Desde un punto de vista arquitectural, este es el aspecto de Azure:
Como podemos apreciar, se trata de una arquitectura dividida en capas, son las siguientes:
-
Capa 0: Global Foundational Services (GFS), los cuales no están reflejados en el diagrama de arquitectura puesto que se trata del nivel de abstracción más básico y no forma parte realmente del entorno de Azure que "veremos" los usuarios de dicho sistema. Por asimilarlo con algo conocido, GFS sería el equivalente a la capa de abstracción hardware de Windows. Esta capa es la encargada de comunicarse directamente con el hardware del servidor.
-
Capa 1: Capa fundamental del sistema operativo Azure, previamente conocida con el codename "Red Dog". Esta capa es la encargada de gestionar y coordinar mediante mecanismos de virtualización el funcionamiento de las N máquinas que ejecuten Windows Server 2008 y que forman el ya citado Data Center. Si echamos un vistazo de alto nivel, podremos observar cuatro pilares fundamentales en Red Dog:
-
Gestión del Almacenamiento (sistema de ficheros virtual distribuido).
-
Controlador del "repositorio": Sistema de gestión para el modelado y despliegue de aplicaciones.
-
Sistema de virtualización para la ejecución de aplicaciones.
-
Entorno de desarrollo: Este entorno permitirá emular Red Dog desde nuestras máquinas, para de este modo integrarlo con Visual Studio y poder desarrollar desde nuestros propios equipos para la nube. Además de Visual Studio, se soportarán otros IDEs como por ejemplo Eclipse.
-
Capa 2: Conjunto de servicios para la creación de aplicaciones. El uso de estos servicios será opcional y dependerá de cada proyecto en concreto, podremos no usar ninguno, usar uno, o combinar cuantos queramos. En esta primera versión de Azure, los servicios existentes son:
-
Live Services (donde destaca especialmente Live Mesh, podéis repasar un análisis previo que hice
aquí)
-
SQL Server Data Services, los cuales ahora pasan a llamarse SQL Services a secas.
-
.Net Services, antes conocidos como Zurich.
-
Sharepoint Services
-
Dynamics CRM Services
-
Capa 3: Aplicaciones alojadas dentro de Azure. Al margen de todas aquellas que podamos crear nosotros mismos, Microsoft incluye algunas por defecto, a saber: Sharepoint Online, Exchange Online y Dynamics CRM Online. En el futuro, también Live Meeting formará parte de este grupo de aplicaciones incluídas en Azure, e incluso se habla de otras como
Forefront Online y
System Center Online.
Como punto final para el post, os dejo una más que interesante entrevista en Channel 9 a Manuvir Das, director del equipo de desarrollo de Microsoft Azure, en la cual explica todo esto que os he ido contando de una forma más técnica, gráfica y extensa.
Sirva este post como introducción a una serie de posts (3-4) que voy a intentar publicar durante esta semana con motivo de la Professional Developers Conference (PDC) que va a tener lugar en Los Ángeles (California). Este evento organizado por Microsoft es probablemente la conferencia anual más importante en todo el mundo, acerca de temas relacionados con desarrollo de software. Durante esta semana vamos a conocer de primera mano muchas novedades que saldrán de Redmond durante los próximos meses y años, algunas tan importantes en el panorama de la industria del desarrollo software como por ejemplo las características de la próxima versión de .Net (.Net 4), Visual Studio (Visual Studio 2010) y una nueva tecnología, o más bien, la integración de una serie de esfuerzos conjuntos en diferentes productos que supondrán una revolución en lo que a la manera de desarrollar software se refiere: Oslo. Todo ello por no hablar del anuncio que dará la vuelta al mundo, más allá de las comunidades técnicas, y estará en boca de todos (desarrolladores, usuarios, medios de comunicación) que no es otro que el esperado y deseado Windows 7.
No obstante, y a pesar de que trataré de aportar bastante información sobre estos anuncios y en especial sobre Oslo (tecnología en la que tengo el gran honor de estar aportando algunos bits), mi propósito en esta serie de posts es tomar algo de perspectiva y realizar un análisis de tipo filosófico sobre la evolución de los lenguajes de programación: ¿de dónde venimos? ¿dónde estamos? ¿hacia dónde vamos?
Debo confesar además que el contenido de estos posts va a ser de un nivel de abstracción bastante alto, porque de hecho los he redactado mentalmente durante un paseo de 3 horas en bicicleta, recorriendo los parques y playas de mayor atractivo paisajístico de la ciudad de Vancouver. Así que con vuestro permiso, y puesto que hace unas semanas prometí reportajes fotográficos sobre esta hermosa ciudad, voy a dividir la serie en etapas a modo de vuelta ciclista, al término de cada etapa incluiré una foto de los parajes que iremos recorriendo.
La primera parada no puede ser otra más que la entrada a Stanley Park, parque de unos 12 km de perímetro situado en el centro de Vancouver, a lo largo del cual iremos descubriendo algunos pensamientos abstractos sobre los lenguajes de programación pasados, presentes y futuros.
Tras aproximadamente un año de desarrollo como parte del proyecto Dev Labs , hoy S.Somasegar ha hecho público un nuevo lenguaje de programación: Small Basic.
Este nuevo lenguaje va enfocado a entornos educativos y su meta fundamental es “convertir la programación en algo divertido”. El lenguaje está totalmente integrado en un IDE bastante intuitivo y óptimo para que niños y/o personas sin conocimientos previos de programación den sus primeros pasos en este maravilloso mundo de la programación.
Small Basic funciona sobre la plataforma .Net y a nivel conceptual y de paradigma deriva en parte de “su abuelo” Basic. No obstante, se trata de una versión bastante reducida (tan sólo 15 palabras reservadas) y que emplea conceptos minimalistas para mantener un nivel de complejidad bajo, de modo que prácticamente cualquier persona pueda comprenderlo sin mayores dificultades.
El entorno de desarrollo es bastante minimalista igualmente, aunque incluye algunas características que seguro serán bien recibidas por sus usuarios como por ejemplo Intellisense y ayuda instantánea contextual. Además de ello, Small Basic permite el uso de librerías de terceros, de modo que tanto el lenguaje como la plataforma tienen indudables posibilidades de evolución, especialmente en comunidades educativas.
A continuación os dejo una serie de links relacionados con este interesante proyecto:
Un saludo!
Después de mi último post de actualización sobre novedades, y dado que el centro de desarrollo de Microsoft en el que estoy trabajando es de reciente creación (Septiembre 2007) y no muy conocido, creo que os resultará interesante dar un paseo por él, de forma similar a como hice el año pasado en el Campus de Redmond
En mi modesta opinión, este centro está bastante bien. Por varios motivos, el primero de ellos es que se trata de un lugar muy tranquilo y fácilmente puedes concentrarte en tu trabajo. Comparado con Redmond (unos 110 edificios), este centro es "de juguete" (tan solo 2, y un 3º en proyecto). Así que aquí es posible encontrar cualquier cosa que necesites, ya que todo está a tiro de piedra. Otro factor positivo que he encontrado es que, al ser menos gente y también de edad media inferior a los 30 años, hay mucho compañerismo y cualquiera está por la labor de echar una mano a los novatos como yo en estos primeros días... Como siempre cuando hablamos de Microsoft, el intercambio cultural es realmente impresionante. A modo de curiosidad, comentar que mis vecinos de oficina son originarios de Pakistán, Turquía, Líbano, Rusia... También hay algún que otro español más por aquí, algo que siempre se agradece. Y hasta el momento ya he tenido ocasión de aprender nociones básicas de idiomas que hasta ahora me eran desconocidos, e incluso hablar sobre fútbol con algún compañero, por supuesto felicitándome por la victoria de España en la Euro'08 :-)
En esta ocasión, no he tenido siquiera tiempo de sacar unas fotos del entorno, pero encontré algunas por internet y, precisamente hoy, se han publicado una serie de vídeos sobre el MCDC (no confundir con AC/DC...). No obstante, una de las cosas que me he propuesto es subir semanalmente fotos de Vancouver y alrededores, puesto que los paisajes son realmente impresionantes y también para darle un poco de envidia a Octavio (como muestra, arriba tenéis una vista del centro de Vancouver desde Coal Harbour, uno de los puertos deportivos de la ciudad).
Sin más dilación, ahí va el vídeo. Espero que lo disfrutéis. ¡Hasta pronto!
Con el fin de no saturar Geeks.ms con una oleada de posts con tag Personal y Off-Topic, voy a agrupar 3 posts en uno para contaros algunas novedades de importancia relevante para mí a nivel personal, jeje.
Miguel.SetLocation(“Vancouver”)
La primera de ellas hace referencia al hecho de que desde el pasado fin de semana me he trasladado a vivir a Vancouver (British Columbia, Canadá). Con el fin de dedicarme en cuerpo y alma a tiempo completo a mi trabajo como Software Development Engineer in Test en Microsoft Corp. Como algunos de vosotros ya sabéis, trabajaré dentro de Connected Systems Division, concretamente siendo parte del equipo de OSLO.
Este hecho no significa ni mucho menos un adiós a la comunidad española, aunque si bien me tendré que conformar con participar en ella de forma virtual a través de este blog. Aprovecho para dar las gracias a los muchos amig@s que con el paso de los años he ido haciendo en esta comunidad, gracias por todo lo que me habéis enseñado y también por todo aquello que hemos podido ir aprendiendo juntos, a base de ilusión.
Miguel.Blogs.Add(“MSDN.com”)
La segunda novedad es consecuencia directa de la primera… Desde hoy mismo he comenzado un nuevo blog en MSDN, en el cual me voy a lanzar a bloguear en la lengua de Shakespeare.
La temática de dicho blog será muy parecida a la de éste, en principio. Así que también pretendo mantener el ritmo habitual de posts, sólo que en dos idiomas diferentes.
Podéis encontrarlo en http://blogs.msdn.com/mllopis y espero que lo disfrutéis.
Miguel.Years++
En último lugar, pero no por ello menos importante, comentar que hoy (9 de Octubre) es mi 24º cumpleaños. Muchos de vosotros me habéis felicitado vía email, messenger y facebook a lo largo del día pero por motivos de cambio horario yo apenas me acabo de levantar… así que siento no haberos contestado y aprovecho para daros las gracias :-)
Creo que no me dejo nada más en el tintero, seguiré informando próximamente.
¡Hasta pronto!
Siguiendo con la semana del gran anuncio sobre Visual Studio 2010, a continuación os detallo la agenda de vídeos y webcasts que se van a publicar en Channel 9 por parte de gente del propio equipo de producto de VSTS.
Como comentábamos en el post anterior, hay una gran cantidad de novedades orientadas a mejorar la productividad en nuestros desarrollos mediante una serie de herramientas enfocadas a incrementar la agilidad e interacción entre roles. Es tal la importancia de estos roles en Visual Studio Team System que incluso para la planificación de esta semana de anuncios de novedades se ha distribuido en base a dichos roles.
La agenda es la siguiente:
Por mi parte, me voy a tomar la libertad de ver detenidamente cada vídeo y realizar un análisis diario comentando qué novedades me parecen más interesantes, así como su relación con otros esfuerzos paralelos a Visual Studio 2010 que Microsoft está realizando y que, sin duda, van a cambiar (para mejor, se entiende) la forma en que concebimos el desarrollo software en .Net
Como bien dice Jorge: “Que empiece la función”