Las buenas maneras de las llamadas recursivas

The Power of 10 Rules (El poder de las 10 reglas) es una guía para código seguro creada en 2006 por Gerard J. Holzmann del Laboratorio de Software Fiable de la NASA/JPL.

Las reglas prohíben ciertas prácticas de codificación en C que dificultan la revisión o el análisis estático del código. Estas reglas son un complemento a las directrices MISRA C y se han incorporado en el mayor conjunto de estándares de codificación de JPL.

Las diez reglas

1. Restrinja todo el código a construcciones de flujo de control muy simples. No utilice sentencias GOTO, construcciones set jmp o long jmp, ni recursividad directa o indirecta.
2. Todos los bucles deben tener un límite superior fijo. Debe ser trivialmente posible para una herramienta de comprobación demostrar estáticamente que no se puede superar un límite superior preestablecido en el número de iteraciones de un bucle. Si el límite del bucle no puede demostrarse estáticamente, se considera que se ha infringido la norma.
3. No utilice la asignación dinámica de memoria después de la inicialización.
4. Ninguna función debe ser más larga de lo que se puede imprimir en una sola hoja de papel.
5. Use un mínimo de dos aserciones en tiempo de ejecución por función. Las aserciones siempre deben estar libres de efectos secundarios y deben definirse como pruebas booleanas.
6. El scope de los datos debe ser el más pequeño posible.
7. Cada función de llamada debe comprobar los valores de retorno de función no vacíos, y la validez de los parámetros debe comprobarse dentro de cada función.
8. El uso del preprocesador debe limitarse a los headers y definiciones de macros simples.
9. El uso de punteros debe estar restringido a un nivel de des referencia. No se permiten punteros a funciones.
10. Todo el código debe ser compilado, desde el primer día de desarrollo, con todas las advertencias del compilador habilitadas en la configuración más estricta del compilador. Todo el código debe ser comprobado diariamente con al menos un analizador estático de código fuente actualizado, y debe pasar los análisis con cero advertencias.

La primera regla prohíbe el uso de llamadas recursivas. Las normas de la NASA se centran en la robustez de sistemas de tiempo real que son siempre críticos y inaccesibles para mantenimiento: La recursión puede ser impredecible en sistemas embebidos o de tiempo real.El consumo de recursos no acotados (pila/stack), es crítico en hardware con memoria limitada (ej.: satélites, rovers). Dificultad para verificación formal (requerida en software de seguridad crítica).

Recursión Eficiente: Optimización del Compilador

Para hacer que la recursión sea eficiente y segura, los compiladores modernos aplican optimizaciones clave, pero requieren que el código cumpla ciertas condiciones.

Tail-Call Optimization (TCO)

El compilador reemplaza la llamada recursiva por un bucle (jump) si la recursión está en posición de cola (tail position), evitando crecimiento de la pila (stack). La llamada recursiva debe ser la última operación de la función. Compiladores como GCC/Clang la optimizan con -O2 o -O3.

Trampolining (para lenguajes sin TCO nativo)

Transforma la recursión en un bucle usando una estructura intermedia ("trampolín").

Memoization (Cache de Resultados)

Almacena resultados previos para evitar recalcular en recursión múltiple.

Conversión Manual a Iteración

Si el compilador no optimiza, transforma la recursión en un bucle manualmente.

Fuentes:

NASA JPL Institutional Coding Standard for the C Programming Language (2009).

DO-178C (Estándar para software aeronáutico).

Resumen y extractos en el repositorio técnico de la NASA: NASA Technical Reports Server (NTRS) (Busca "JPL C Coding Standard 2009")

Versión similar y pública (JPL Power of Ten Rules): NASA JPL Power of 10 Rules (Reglas clave resumidas).

DO-178C (Estándar para Software Aeronáutico) Documento oficial: Publicado por RTCA (Requiere compra): RTCA DO-178C (Costo aproximado: $200 USD).

Guías gratuitas relacionadas:

FAA Advisory Circular 20-115C (basado en DO-178C): FAA.gov (Busca "AC 20-115C"). 

Automatización de Pruebas Matemáticas

Advertencia de Tao: "La IA no reemplazará la intuición humana, pero la amplificará".

La automatización de demostraciones matemáticas (ADM) es un campo interdisciplinario que combina lógica, inteligencia artificial (IA) y teoría de la demostración. Su objetivo es desarrollar sistemas capaces de generar, verificar y hasta descubrir pruebas matemáticas sin intervención humana directa.

Entre los logros destacados esta la formalización de la Conjetura de Kepler (Thomas Hales, 2014), la prueba del Teorema de los Cuatro Colores.

El desafíos clave es la complejidad computacional. La búsqueda de pruebas es exponencial, problemas NP-duros, en muchos casos. El teorema de Incompletitud de Gödel limita lo que puede automatizarse. Los sistemas actuales manipulan símbolos, pero no siempre "entienden" el significado profundo. Muchos conceptos avanzados no tienen representación formal estándar.

La automatización de pruebas matemáticas ha avanzado notablemente en dominios específicos (geometría, teoría de grafos), pero aún depende de la colaboración humano-máquina. Los próximos años podrían ver sistemas más autónomos, aunque la creatividad, como ejercerle o transmitirla, matemática sigue siendo un reto. Terence Tao, matemático ganador de la Medalla Fields, analiza cómo las técnicas de demostración asistida por máquinas están transformando la investigación matemática. Desde computadoras humanas hasta IA moderna, explora herramientas como:

• Resolvedores SAT (para problemas de lógica).
• Asistentes de prueba formal (Coq, Lean).
• Algoritmos de aprendizaje automático (como AlphaGeometry).

Tao destaca el potencial de combinar estas tecnologías para:

• Colaboración a gran escala (ej.: proyectos colaborativos como Mathlib en Lean).
• Explorar problemas complejos que humanos solos no podrían abordar.
• Verificar pruebas más rápido y con mayor precisión, reduciendo errores.

El 25% de las pruebas en arxiv.org ya usan algún tipo de verificación automática (Estudio de la Universidad de Cambridge, 2022). Terence Tao Tao propone 3 escenarios para el 2030:

1. Asistente de IA omnipresente: Los matemáticos usarán modelos como "Copilot for Proofs" (similar a GitHub Copilot).
2. Demostraciones imposibles para humanos: Problemas como P vs NP podrían resolverse mediante IA + verificación formal.
3. Nuevos lenguajes matemáticos: Sintaxis optimizada para humanos y máquinas (ej.: MathLang).

Peor es mejor

El artículo "Lisp: Good News, Bad News, How to Win Big" (Richard P. Gabriel, 1991), escrito en los años 90 por uno de los pioneros de LISP, durante el declive comercial de Lisp frente a lenguajes como C++ y Java, analiza por qué Lisp, pese a su elegancia técnica, no triunfó en la industria.

Gabriel muestra como Lisp es el lenguaje más potente (meta programación, macros, REPL); favorece abstracción pura y rapidez de desarrollo (ej.: IA simbólica). Gabriel critica la cultura UNIX/C por priorizar simplicidad sobre corrección, pero admite que eso las hizo más populares.

La sintaxis con paréntesis y la flexibilidad extrema de LISP asustaban a los desarrolladores. Los dialectos (Common Lisp vs. Scheme) fragmentaron el ecosistema. Lisp requería máquinas costosas (Lisp Machines) y no se adaptó a la era PC. Gabriel termina advirtiendo que la superioridad técnica no garantiza el éxito comercial.

Actualmente, ya en el segundo cuarto del siglo XXI, la IA permite meta programación implícita, es decir generar código desde descripciones en lenguaje natural). Asistentes como ChatGPT actúan como "REPLs cognitivos". La IA reduce la barrera de entrada, se afirma que ya no se requiere saber programar. Pero la ambigüedad es un problema fundamental que compromete la confiabilidad de los sistemas o aplicaciones desarrolladas por o con la asistencia de IA.

El ensayo de Edsger W. Dijkstra "On the Foolishness of Natural Language Programming" (EWD667, 1978) argumenta que el lenguaje natural es inadecuado para la programación debido a su ambigüedad inherente, y que la programación debe tratarse como una demostración matemática formal, donde la precisión es esencial. La ambigüedad del lenguaje natural lo hace propenso a malinterpretaciones, lo que es catastrófico en programación. La corrección del software solo puede garantizarse mediante pruebas formales (como en matemáticas), no mediante descripciones informales. Dijkstra criticaba los intentos de "programación en lenguaje natural" de su época, COBOL, por generar código inseguro y difícil de verificar.

El término "alucinaciones" en el contexto de la IA se refiere a situaciones en las que un modelo genera respuestas factualmente incorrectas o, específicamente en programación, código sintácticamente válido pero lógicamente erróneo (por ejemplo, un algoritmo de ordenación que no ordena correctamente). El término es ampliamente aceptado en la literatura (ej: estudios de OpenAI, DeepMind y MIT). Se aplica tanto a respuestas incorrectas como a código mal generado (Sutskever et al., 2023).

La IA genera código a partir de descripciones en lenguaje natural, lo que reproduce el problema de ambigüedad que Dijkstra señaló en sus críticas a la programación basada en lenguaje natural. Los modelos de lenguaje de gran escala (LLM, por sus siglas en inglés) no construyen demostraciones matemáticas del código ni verifican su corrección formal; en cambio, predicen secuencias de tokens basándose en patrones estadísticos aprendidos de su corpus de entrenamiento. Estos modelos no "comprenden" el código en un sentido lógico o semántico, sino que imitan estructuras recurrentes en los datos. Por lo tanto, no pueden garantizar la corrección del código generado, ya que carecen de razonamiento lógico formal (como los sistemas de tipos avanzados o demostradores de teoremas).los modelos LLM carecen de capacidad de verificación rigurosa más allá de la coherencia estadística. Su funcionamiento se basa en probabilidades, no en lógica deductiva (Bender et al., 2021). GitHub Copilot ha sugerido implementaciones de criptografía inseguras (estudio de NYU, 2022).

 Un modelo puede, por ejemplo,  generar un quicksort que funciona en el 90% de los casos, pero falla en edge cases (ej: listas vacías). La IA puede generar código con licencias conflictivas o soluciones sesgadas (ej: algoritmos de contratación discriminatorios). 

Alan Kay (Premio Turing): "La IA actual es como un loro que repite código sin comprenderlo. Necesitamos sistemas que razonen como humanos, no solo estadística."

Leslie Lamport (TLA+, Verificación Formal): "Los modelos generativos son útiles para prototipos, pero la corrección exige métodos formales."

Según un estudio del MIT (2023), solo el 40% del código generado por GPT-4 pasa pruebas formales de corrección. Google DeepMind (2024) propone combinar LLMs con *verificadores automáticos (ej: Lean, Coq).

En situaciones potencialmente catastróficas como la falla en un avión es esencial determinar quien es responsable. UE AI Act (2024) exige transparencia en sistemas de alto riesgo, pero no resuelve la verificación formal. Estamos entusiásticamente entrando en un proceso de automatización de errores: Si la IA escala la generación de código incorrecto, ¿aumentarán los desastres por software defectuoso? Si los programadores confían ciegamente en la IA, ¿se perderá el pensamiento crítico?

Dijkstra acertó en que el lenguaje natural es ambiguo y la programación exige precisión. La IA generativa agrava el problema, pues escala la generación de código no verificado. El futuro requiere modelos híbridos (IA + verificadores formales) y nuevos marcos legales para responsabilidad en código generado. Es necesario entrenar a los programadores en pensamiento crítico para que no deleguen ciegamente en la IA. La tecnología no triunfa solo por ser superior, sino por resolver problemas reales de manera accesible.

Lecturas clave:

Dijkstra, EWD667 (1978).

"Formal Verification in the Age of AI" (Communications of the ACM, 2024).

"Who is Liable for AI-Generated Bugs?" (Stanford Law Review, 2023).

Dijkstra on prompt engineering

Taken from here.

EWD 667

On the foolishness of "natural language programming".

Since the early days of automatic computing we have had people that have felt it as a shortcoming that programming required the care and accuracy that is characteristic for the use of any formal symbolism. They blamed the mechanical slave for its strict obedience with which it carried out its given instructions, even if a moment's thought would have revealed that those instructions contained an obvious mistake. "But a moment is a long time, and thought is a painful process." (A.E.Houseman). They eagerly hoped and waited for more sensible machinery that would refuse to embark on such nonsensical activities as a trivial clerical error evoked at the time.

Machine code, with its absence of almost any form of redundancy, was soon identified as a needlessly risky interface between man and machine. Partly in response to this recognition so-called "high-level programming languages" were developed, and, as time went by, we learned to a certain extent how to enhance the protection against silly mistakes. It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.) The (abstract) machine corresponding to a programming language remained, however, a faithful slave, i.e. the nonsensible automaton perfectly capable of carrying out nonsensical instructions. Programming remained the use of a formal symbolism and, as such, continued to require the care and accuracy required before.

In order to make machines significantly easier to use, it has been proposed (to try) to design machines that we could instruct in our native tongues. this would, admittedly, make the machines much more complicated, but, it was argued, by letting the machine carry a larger share of the burden, life would become easier for us. It sounds sensible provided you blame the obligation to use a formal symbolism as the source of your difficulties. But is the argument valid? I doubt.

We know in the meantime that the choice of an interface is not just a division of (a fixed amount of) labour, because the work involved in co-operating and communicating across the interface has to be added. We know in the meantime —from sobering experience, I may add— that a change of interface can easily increase at both sides of the fence the amount of work to be done (even drastically so). Hence the increased preference for what are now called "narrow interfaces". Therefore, although changing to communication between machine and man conducted in the latter's native tongue would greatly increase the machine's burden, we have to challenge the assumption that this would simplify man's life.

A short look at the history of mathematics shows how justified this challenge is. Greek mathematics got stuck because it remained a verbal, pictorial activity, Moslem "algebra", after a timid attempt at symbolism, died when it returned to the rhetoric style, and the modern civilized world could only emerge —for better or for worse— when Western Europe could free itself from the fetters of medieval scholasticism —a vain attempt at verbal precision!— thanks to the carefully, or at least consciously designed formal symbolisms that we owe to people like Vieta, Descartes, Leibniz, and (later) Boole.

The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.

Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve. (This was evidently not understood by the author that wrote —in 1977— in the preface of a technical report that "even the standard symbols used for logical connectives have been avoided for the sake of clarity". The occurrence of that sentence suggests that the author's misunderstanding is not confined to him alone.) When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.

It may be illuminating to try to imagine what would have happened if, right from the start our native tongue would have been the only vehicle for the input into and the output from our information processing equipment. My considered guess is that history would, in a sense, have repeated itself, and that computer science would consist mainly of the indeed black art how to bootstrap from there to a sufficiently well-defined formal system. We would need all the intellect in the world to get the interface narrow enough to be usable, and, in view of the history of mankind, it may not be overly pessimistic to guess that to do the job well enough would require again a few thousand years.

Remark. As a result of the educational trend away from intellectual discipline, the last decades have shown in the Western world a sharp decline of people's mastery of their own language: many people that by the standards of a previous generation should know better, are no longer able to use their native tongue effectively, even for purposes for which it is pretty adequate. (You have only to look at the indeed alarming amount of on close reading meaningless verbiage in scientific articles, technical reports, government publications etc.) This phenomenon —known as "The New Illiteracy"— should discourage those believers in natural language programming that lack the technical insight needed to predict its failure. (End of remark.)

From one gut feeling I derive much consolation: I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.

Plataanstraat 5 5671 AL NUENEN The Netherlands

prof.dr.Edsger W.Dijkstra Burroughs Research Fellow

---

transcribed by Tristram Brelstaff
revised Fri, 19 Nov 2010

Ariane 5

El 4 de junio de 1996, el cohete Ariane 5 lanzado por la Agencia Espacial Europea estalló 38 segundos después de su despegue desde Kourou, en la Guayana Francesa. El Ariane explotó en su primer viaje, después de una década de desarrollo, y las pérdidas se estimaron en 500 millones de dólares.

La causa de la explosión fue un error en el software. Un error no detectado por falta de control de la calidad del software crítico del cohete. Todo sucedió porque un número real de 64 bits (coma flotante) relacionado con la velocidad horizontal del cohete se convirtió en un entero de 16 bits. Ese mismo año, en 1996, a Alain Deutsch, del INRIA, le encargaron averiguar cuál fue el error. Y para ello se puso manos a la obra usando herramientas que automatizaban el control de la calidad del software crítico. Concretamente, usó un prototipo de analizador estático (IABC) de código fuente Ada, el cual había desarrollado para su doctorado.

Automatizando la evaluación de la calidad del software crítico, del código fuente, encontró el error,  y demostró la eficacia del análisis estático (os dejo un artículo para más detalles). Hoy en día el análisis estático del código es práctica usual, y prácticamente obligatoria, para controlar la calidad del software crítico, y del software embebido. Fue a raíz de esta experiencia cuando se creó la empresa PolySpace, con el objetivo de comercializar la herramienta de evaluación de la calidad del software crítico que se utilizó para encontrar el fallo del Ariane. Y hoy las herramientas de PolySpace son unas de las más usadas para el control de la calidad del software crítico.

Depreciación de funciones en Visual Studio C/C++

Uno de los problemas que se presenta al actualizar una aplicación en Visual Studio C/C++ es la depreciación de funciones. La motivación de muchos de estos cambios es hacer el código más seguro.



Existen varias maneras de eliminar las advertencias para las funciones obsoletas o depreciadas. Las más sencilla es definir _CRT_SECURE_NO_WARNINGS o usar el pragma warning. Lo más recomendable es usar la versión segura equivalente.

Referencias:

strcpy_s, wcscpy_s, _mbscpy_s

Security Enhancements in the CRT

Clear code that works

A partir de una visión clara e intima del proceso de desarrollo de software, Kent Beck a creado un enfoque metodológico que  a primera vista pareciera contra intuitivo pero que ha resultado exitoso y ampliamente aceptado en la comunidad de programadores.

En Test Driven Development: By Example (Addison-Wesley Signature Series), el libro seminal de TDD, Beck aplica el refrán de divide y vencerás al precepto de calidad en la producción de código:  Clear code that works.
Beck propone contracorriente que es posible separar las consideraciones de calidad de código, desde la perspectiva de ingeniería de software, de la verificación de la funcionalidad, y que el primer paso en cada iteración del proceso de desarrollo es definir y aplicar las pruebas de funcionalidad.
Beck utiliza un proceso de refactorización para pasar de código funcional a código limpio, utilizando la eliminación de redundancia o duplicidad  como guía metodológica.
Haciendo una analogía con un semáforo,  Beck describe un proceso iterativo de 3 pasos:

1. Rojo. Empezar con una prueba que debe fallar, tal ves ni compilar siquiera.
2. Verde. Hacer que el código pase la prueba de la manera más expedita y simple, sin consideración alguna a normas y patrones de calidad de código.
3. Refactorizar. Eliminar redundancia en código, pruebas, y datos.

De tan sencillo enfoque Beck elabora la metodología de desarrollo dirigido por pruebas.

Levantamiento de requerimientos

El siguiente escenario es tí­pico: Un consultor trabaja con los usuarios para describir los procesos de negocio que serán soportados por el software. El equipo de desarrollo recibe la descripción del consultor pero no están familiarizados con los términos de negocio y consideran la descripción demasiado informal. Los desarrolladores escriben su propia descripción desde un punto de vista técnico. El usuario no entiende esta descripción pero la acepta para que el proyecto avance. El resultado puede ser un sistema que desde el punto de vista del usuario es difícil de usar y que no cumple con sus expectativas.

Parte de este problema es metodológico, y en parte es intrínseco a las caracterí­sticas de los usuarios. Algunas de las problemáticas que se presentan:

• Los usuarios no saben que es lo que quieren
• Los usuarios no aceptan como un compromiso los requerimientos escritos
• Los usuarios insistirán en nuevos requerimientos después de fijar costos y agendas.
• Los usuarios no están disponibles y la comunicación con ellos es lenta
• Los usuarios no participan en revisiones de avance.
• Los usuarios no entienden el proceso de desarrollo y no les interesa.

Existen herramientas y metodologías para el levantamiento de requerimientos. Casos de uso y UML son medios para formalizar este proceso. Que diagramas UML es apropiado usar dependerá del sistema a desarrollar.

Una guía simple en términos de la complejidad del sistema:

• Aplicación mono usuario
  • Diagrama de casos de uso.
  • Diagrama de clases.
  • Diagrama de interacción.
• Aplicación mono usuario, con manejo de eventos:
  • Añadir: Diagrama de estados.
• Aplicación cliente servidor:
  • Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
• Aplicación compleja distribuida:
  • Todos.

Para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. El diagrama de casos de uso puede modelar el contexto de un sistema o los requisitos del mismo. Se puede extender la colección de elementos base de UML utilizando estereotipos.

Referencias:

• Database answers es un repositorio con más de 450 esquemas de datos para diferentes aplicaciones. Algunos usados como referencia en la documentación de Microsoft SQL Server 2005
• En el caso de .Net, Design patterns, AJAX Design Patterns, and .NET training , tiene ejemplos en C# y VB
• https://www6.software.ibm.com/developerworks/education/r-rsmvisual/
• http://www.programacion.net/tutorial/uml/
• http://www.clikear.com/manuales/uml/
• http://odl-skopje.etf.ukim.edu.mk/uml-help/

eXtreme Programming

Uno de los problemas fundamentales con las metodologías de desarrollo, de hecho, con cualquier esfuerzo de normalizar un proceso entre personas, es que el deber ser en un sentido moral idealista obscurece el es. eXtreme Programming es un enfoque contra intuitivo para aumentar la productividad de los programadores.

A pesar de los esfuerzos heroicos del equipo de mercadotecnia y de la necesidad de los usuarios de mantener los costos bajos, un programador es productivo alrededor de 2 a 4 horas diarias en promedio. Un monstro en el closet pero una realidad. Esto anuado al hecho de la programación es una arte en al que unos pocos virtuosos pueden realizarla con soltura, 5% de los programadores (o menos) hacen 95% del trabajo (o más). Por eso los beneficios de programación en pares en realidad no implican un costo en productividad. Antes al contrario, probablemente un equipo de 2 de programadores trabajando bajo el esquema de programación extrema sea 2 a 3 veces más productivo que los mismos programadores trabajando de manera aislada.

El énfasis en diseño y pruebas es simplemente una realidad del ciclo de desarrollo:

• Un defecto en codificación es un defecto, aunque corregirlo puede generar más defectos.
• Un error en la fase de diseño produce más de 10 defectos en código
• Un error en la fase de levantamiento de requerimientos produce más de 100 defectos en código

Por eso el esfuerzo de desarrollo debe concentrarse en el análisis y realizar iteraciones cortas donde rápidamente la funcionalidad del sistema sea aparente al usuario final y este pueda dar la retroalimentación necesaria para mantener las cosas en la dirección correcta de manera eficaz.

El esfuerzo de desarrollo debe seguir aproximadamente la siguiente ponderación:

• 40 % análisis y diseño
• 5 % codificación
• 30 % pruebas y soporte
• 25 % más análisis, diseño, pruebas.

Referencias

• Extreme Programming: A gentle introduction.
• http://www.objectmentor.com/resources/articles/ObjectiveView3.pdf
• Extreme Programming Explained: Embrace Change (2nd Edition) (XP Series)
• Planning Extreme Programming (XP Series)

Technorati Tags: error,Extreme,desarrollo,productividad,programadores,equipo,productivo,programación,diseño,pruebas,defecto,codificación,defectos,fase,código,análisis

Los operadores de copia e igualdad.

Una de las trampas de la orientación a objetos en lenguajes como C# son los operadores de copia e igualdad.



En C# al usar el operador = o ==, la igualdad entre objetos referenciados solo se da si en realidad es el mismo objeto y de manera similar al hacer una copia nos podemos llevar una sorpresa si no tenemos cuidado de estar copiando la referencia o el contenido. Por eso la interfaz ICloneable es controversial porque su significado es ambiguo

Referencias:

Implementar ICloneable mediante serialización



ICloneable Interface

Should we Obsolete ICloneable (The SLAR on System.ICloneable)

IClonable deep vs shallow, best practise

Creating and Using Attributes in your .NET application

IEquatable Generic Interface

Libreria empresarial del grupo de patrones y practicas de Microsoft

La última versión de la Enterprise Library del grupo de Patterns and Practices de Microsoft se libero en mayo del 2007 y es compatible con .Net 2.0 y 3.0.

Información actualizada y material didactico se puede localizar en el sitio comunitario de la libreria empresarial.

Enterprise Library: La evolución de los .NET Application Blocks de patterns & practices

Entlib - Enterprise Library es la evolución de los Bloques Aplicativos .NET que han sido desarrollados por el Grupo PAG (Microsoft Platform Architecture Guidance) dentro de Microsoft. Este grupo genera guías y arquitecturas de referencia, patrones de diseño, y código fuente desarrollado con la implementación de diversos escenarios tecnológicos.

Los desarrolladores en su momento puden usar la guía para comprender las mejores prácticas referenciadas y sugeridas por Microsoft para aplicaciones .NET; o incorporar el bloque aplicativo como tal dentro de sus desarrollos, en su formato original y/o extendido.

Los “Bloques Aplicativos .NET" que en su momento fueron liberados son los siguientes:

• Authorization and Profile Application Block


• Caching Application Block for .NET


• Configuration Management Application Block for .NET


• Data Access Application Block for .NET


• Exception Management Application Block for .NET


• Logging Application Block


• Smart Client Offline Application Block


• Updater Application Block for .NET


• User Interface Process Application Block - Version 2.0


• User Interface Process Application Block for .NET


• Web Service Façade for Legacy Applications

Por la forma gradual en que fueron desarrollados dichos bloques aplicativos, los mismos estaban desintegrados y la experiencia de utilización e extensibilidad eran diferentes entre si. Además que la utilización de cada uno de dichas piezas de software obligaba a la instalación de componentes de software independientes.

Con estas áreas de oportunidad la nueva versión de los “.NET Application Blocks” se integró con la nueva etiqueta de Enterprise Library. El grupo de PAG ha anunciado lo siguiente:

Entlib es una librería de activos de software reutilizable que atenderá los retos comunes en el desarrollo del software empresarial.

Entlib está focalizado en la consistencia, extensibilidad, fácil utilización e integración de los diversos bloques aplicativos existentes y futuros.

Es importante aclarar que Enterprise Libray no es un producto como tal, sino que es un componente de software que es proporcionado como está, pero del cual se puede contratar soporte directamente de Microsoft, tratado bajo un esquema parecido al código escrito por los usuarios.

Recursos relacionados:

1. Web Service Software Factory


2. Smart Client Software Factory


3. Web Client Software Factory


4. Guidance Automation Extensions and Guidance Automation Toolkit

Requerimientos:

• Sistema oprativo: Windows Server 2003; Windows Vista; Windows XP

Note: If you already have the Enterprise Library 3.0 installed, you must uninstall it before installing the Enterprise Library 3.1. However, you can install the Enterprise Library 3.0 or the Enterprise Library 3.1 when 2.0 is already installed.

• Microsoft .NET Framework 2.0 or 3.0. You need .NET Framework 3.0 for the
  Application Block Software Factory and the WCF adapters for the Validation
  Application Block and Exception Handling Application Block


• Microsoft Visual Studio 2005 development system (any of the following
  editions):
  
  
  
  • Microsoft Visual Studio 2005 Standard Edition
  
  
  • Microsoft Visual Studio 2005 Professional Edition
  
  
  • Microsoft Visual Studio 2005 Team Edition for Software Developers
  
  
  • Microsoft Visual Studio 2005 Team Edition for Software Testers
  
  
  • Microsoft Visual Studio 2005 Team Edition for Software Architects
  
  
  • Microsoft Visual Studio 2005 Team Suite
  
  
  
  


• To use the Application Block Software Factory and the Strong-Naming
  Guidance Package, you need the Guidance Automation Extensions (GAX). To
  modify these guidance packages, you also need the Guidance Automation
  Toolkit (GAT).


• Some blocks and samples require the use of Microsoft SQL Server or other
  database products.


• Visual Studio Team System or NUnit 2.2 is required if you want to
  execute unit tests.

Referencias:

Enterprise Library 3.1 - May 2007

Juan Carlos Lozada's WebLog

Acropolis

More Information

 

	Enterprise Library The patterns & practices Enterprise Library is a library of reusable and extensible application blocks designed to assist developers with common enterprise development challenges. Enterprise Library 3.0 contains application blocks for Caching, Cryptography, Data Access, Exception Handling, Logging, Policy Injection, Security and Validation.
	Caching Application Block The Caching Application Block is a component of Enterprise Library which provides a flexible and extensible caching mechanism for use in client and server-side .NET development projects.
	Smart Client - Composite UI Application Block Are you building applications with complex user interfaces? Do you want to take full advantage of the power of the Microsoft Windows desktop? Check out this recently released application block that provides guidance on building world-class, enterprise ready, client applications. Available both in C# and Visual Basic .NET.
	Cryptography Application Block The Cryptography Application Block is a component of Enterprise Library which makes it easier to include cryptographic functionality in .NET applications. The block provides a simple interface to DPAPI, symmetric encryption and hashing, and uses the Enterprise Library configuration tool to simplify key management.
	Data Access Application Block The Data Access Application Block is a component of Enterprise Library which reduces the amount of custom code that you need to create, test, and maintain when building data access layers in .NET applications.
	Exception Handling Application Block The Exception Handling Application Block is a component of Enterprise Library that makes it easier to implement consistent exception handling policies at logical tiers in an application. Exception policies can be configured to perform tasks such as logging exceptions, wrapping or replacing exception types.
	Logging Application Block The Logging Application Block is a component of Enterprise Library that allows developers to instrument their applications with logging and tracing calls. Log and trace messages can be filtered, formatted and routed to a choice of trace listeners, including the event log, text files, database or WMI.
	Policy Injection Application Block The Policy Injection Application Block is a component of Enterprise Library which allows developers to specify the crosscutting behavior of objects in terms of a set of policies. Crosscutting concerns are the necessary tasks, features, or processes that are common across different objects. Examples are logging, authorization, validation, and instrumentation.
	Security Application Block The Security Application Block is a component of Enterprise Library that builds on the capabilities of the Microsoft .NET Framework to help you perform authentication, authorization, check role membership and access profile information.
	Validation Application Block The Validation Application Block is a component of Enterprise Library which provides a common approach to defining validation rules for your business objects that allows them to be reused across different layers of your application.
	Web Service Facade for Legacy Applications This guide discusses best practices for interfacing with legacy applications by using Microsoft® ASP.NET Web services and the Microsoft .NET Framework. The .NET Framework provides the foundation for creating a Legacy Application Interface solution using Microsoft technologies. This guide provides a sample solution using a Microsoft FoxPro® database as the legacy application and connecting it to a .NET-based application using ASP.NET Web services and SOAP. The specific technologies involved are ASP.NET, C# or the Microsoft Visual Basic® .NET development system, the .NET Framework, XML, Visual Basic, COM, and ADO.

La reutilización de código

Ahora, como antes, más que antes, como siempre, la reutilización de código se presenta como un valor fundamental en el desarrollo de sistemas. Uno de sus aspectos es la interoperabilidad de los códigos. Por decirlo de alguna manera, la compatibilidad de una aplicación con diferentes versiones de un sistema operativo y con diferentes sistemas operativos.

Por un lado Microsoft, por otro los demás. El imperio contra los rebeldes republicanos y los feudos vecinos. Pero dentro del mismo imperio se hablan distintas lenguas y los rebeldes tienen diferentes agendas.



Una aplicación que trabaja en Windows 95 no necesariamente funciona en Windows XP, Visual Basic 6 y Visual Basic .Net son animales distintos. Una aplicación Linux que funciona en la distribución Red Hat no necesariamente funciona en la distribución SuSe. La frase platform independent source en la practica marca una prueba de iniciación para hechiceros.

En el caso de Microsoft, algunas de estas incompatibilidades son de origen mercadológico. ¿Cuál es la diferencia entre Windows XP Home Edition y Windows XP Pro? Limitaciones artificiales en la versión casera con respecto a la versión profesional. Desde el punto de vista de Microsoft este modelo funciona, Vista no tiene 2 versiones distintas sino n, cada una definida por un segmento de mercado. Las utilidades de MS aumentaron 65% con respecto al año pasado y podemos esperar más de lo mismo por lo menos en el corto plazo.

En el caso del movimiento Open Source las incompatibilidades son de origen sociocultural. Distintos grupos trabajan con combinaciones distintas de herramientas y enfoques metodológicos. Estos herramentales se yuxtaponen unos con otros y las combinaciones son infinitas. La versión de gcc pude ser la diferencia clave para que un paquete se construya correctamente.

Una iniciativa que no termino de entender es Mono. El concepto es bueno, pero ya va un par de veces que trato de construir una aplicación .Net para fallar miserablemente. Al revisar la letra chiquita del readme aparece que la aplicación es Mono ¿Cuál es el caso de incluir archivos de solución y proyecto de Visual Studio si VS no puede construir la aplicación? ¿Si se requiere reproducir el ambiente de trabajo del desarrollador con librerí­as y variables de entorno porque no documentar esas dependencias? Entiendo que son pecadillos del bien intencionado pero se me escapa la motivación fundamental del chango.

http://www.go-mono.com/docs/
http://www.codeproject.com/cpnet/hellomono.asp

Un aspecto problemático del desarrollo í­nter plataforma son las interfaces graficas de usuario (GUI). Cada sistema operativo tiene su look-and-feel caracterí­stico y el manejo eficiente de ventanas requiere el uso del API nativo correspondiente.

Un enfoque que se puede tomar es agregar una capa intermedia entre la aplicación y el sistema operativo que abstraiga la interacción entre la capa lógica y la interfase grafica a cambio de una penalización en el rendimiento. Algunos problemas que se pueden presentar con librerí­as de este tipo:

• El uso de una capa intermedia adicional disminuye el rendimiento de la aplicación.


• La librerí­a necesaria para soportar la funcionalidad adicional de múltiples sistemas operativos aumenta le tamaño de las aplicaciones más alla de lo que se justifica con la funcionalidad de la aplicación misma. Por lo mismo el soporte para plataforma móvil no es adecuado


• La apariencia de la aplicación no corresponde a la de una aplicación nativa y los diálogos son distintos a los que los usuarios usan normalmente.


• La necesidad de definir un mí­nimo común denominador hace que se pierda la oportunidad de usar las características más avanzadas de un sistema operativo en particular.


• El uso de librerí­as fuera de la esfera de influencia del sistema operativo anfitrión saca a la aplicación del ciclo de vida del mismo y dificulta el proceso de mantener alineadas las actualizaciones de la aplicación con cambios en el sistema operativo.

La tabla siguiente muestra un comparativo de librerí­as para desarrollo ínter plataforma.

Liberarí­a	Tamaño (MB)	Tamaño comprimido (MB)
Java	30+	15
GTK+	9+	4
QT	4+	2
wxWidgets	<1	<.5

Java es una norma abierta que funciona bien como propuesta í­nter plataforma. La maquina virtual de java (JVM) aísla la aplicación del sistema operativo anfitrión y esta disponible normalmente en todas partes. Sin embargo las aplicaciones de java tienden a ser chupa recursos. Si revisas los procesos en una estación XP con Firefox instalado, Firefox es normalmente el campeón en memoria utilizada.

GTK+ es un grupo importante de bibliotecas o rutinas para desarrollar interfaces gráficas de usuario (GUI) para principalmente los entornos gráficos GNOME, XFCE y ROX de sistemas Linux. GTK+ es la abreviatura de GIMP toolkit (conjunto de rutinas para GIMP). Es software libre (bajo la licencia LGPL), multiplataforma y parte importante del proyecto GNU. Inicialmente fue creado para desarrollar el programa de manejo de imágenes GIMP, sin embargo actualmente es muy usada por muchos otros programas en los sistemas GNU/Linux. Cabe mencionar que Qt es una alternativa a GTK que también es muy utilizada (en el entorno KDE, por ejemplo).

GTK+ se ha diseñado para permitir programar con lenguajes como C, C++, Java (Sun), Perl o Python.

GTK ha sido portada a Windows pero el look-and-feel no es nativo.

Qt es una biblioteca multiplataforma para desarrollar interfaces gráficas de usuario. Fue creada por la compañía noruega Trolltech. Qt es utilizada en KDE, un entorno de escritorio para sistemas como GNU/Linux o FreeBSD, entre otros. Utiliza el lenguaje de programación C++ de forma nativa y además existen bindings para C, Python (PyQt), Java (Qt Jambi), Perl (PerlQt) y Ruby (QtRuby) entre otros. El API de la biblioteca cuenta con métodos para acceder a bases de datos mediante SQL, así­ como uso de XML y una multitud de otros para el manejo de ficheros, además de estructuras de datos tradicionales. Inicialmente Qt apareció como biblioteca desarrollada por Trolltech (en aquel momento "Quasar Technologies") en 1992 siguiendo un desarrollo basado en el código abierto, pero no libre. Se usó activamente en el desarrollo del escritorio KDE (entre 1996 y 1998), con un notable éxito y rápida expansión.

Qt cuenta actualmente con un sistema de doble licencia: una GPL para el desarrollo de software de código abierto (open source) y software libre, y otra de pago para el desarrollo de aplicaciones comerciales. Las librerí­as Qt son también liberadas bajo licencia GPL para Windows y Mac.

wxWidgets son unas bibliotecas multiplataforma, freeware/Open Source para el desarrollo de interfaces gráficas programadas en lenguaje C++. Es una librería pequeña que encapsula en una interfase común llamadas al API nativo de cada sistema operativo.

wxWidgets usan una licencia GPL, concretamente la licencia L-GPL, similar a la GPL con la excepción de que el código binario producido por el usuario a partir de ellas, puede ser propietario, permitiendo desarrollar aplicaciones empresariales sin coste.

Las WxWidgets proporcionan una interfaz gráfica basada en las bibliotecas ya existentes en el sistema (nativas), con lo que se integran de forma óptima y resultan muy portables entre distintos sistemas operativos. Están disponibles para Windows, MacOS, UNIX/Linux, OpenVMS y OS/2. También pueden ser utilizadas desde otros lenguajes de programación, aparte del C++: Java, Javascript, Perl, Python, Smalltalk, Ruby

Lisp y Scheme

Una de las cosas que me llaman la atención es la convicción tan grande que los programadores de Lisp tienen en el poder de sus paréntesis.



Aún en el contexto de desarrollo Web Paul Graham ha llamado a Lisp su arma secreta, y en el manual de como convertirse en un Hacker de Eric Steven Raymond, Lisp se presenta como un experiencia mística. Peter Norvig, en Teach Yourself Programming in Ten Years, recomienda aprender lenguajes que soporten abstracción de clases (como Java), abstracción funcional (como Lisp), abstracción sintáctica (como Lisp), especificación declarativa (como Prolog), corutinas (como Scheme), y paralelismo (como Sisal).

El enfoque funcional parece ser fundamental y, por ejemplo, el equipo de desarrollo de C# ha hecho un esfuerzo por soportar este paradigma en la nueva versión a través del mecanismo de delegados.

Es claro que el río suena porque agua lleva. Para el interesado hay material introductorio abundante pero lograr la iluminación requerirá tiempo y esfuerzo.

Para Lisp, como lo indica su nombre, todo son listas y los comando básicos (constructors, selectors y recognizers) son para manipular las mismas:

quote para diferenciar una lista de una llamada a función.
first y rest para separar listas en sus partes.
cons para construir listas.
null y consp para ver si una lista esta vacía.
member para verificar si un elemento es miembro de una lista.
append para unir listas.

Lisp tiene varios dialectos: Common Lisp y Scheme son algunos de los más difundidos. CLisp es un implementación de Common Lisp y Visual CLisp es un puerto a Windows con un GUI. Otra alternativa es CMUCL.

Dorai Sitaram tiene un sitio con ligas a recursos sobre Scheme y Common Lisp, incluyendo un tutorial bastante bueno.

drscheme incluye varias implementaciones de Scheme bajo una interfaz común orientada a un ambiente académico.
Las funciones de Scheme para manipular listas son:

cons

toma dos argumentos y regresa un par o lista.

(cons '1 '2)              is   (1 . 2)

El primer ejemplo es un par y los otros son listas. Pares o listas se pueden utilizar para implementar registros.

car

regresa el primer miembro de una lista o par.

(car '(123 245 564 898))             is   123

cdr

regresa la lista sin el primer elemento.

(cdr '(7 6 5))               is  (6 5)

null?

regresa \#t si el objeto es la lista nula. En cualquier otro caso regresa la lista nula.

list

regresa un alista construida de los argumentos.

(list 'a)                          is  (a)

length

regresa la longitud de la lista.

     (length '(1 3 5 9 11)) is  5

reverse

regresa la lista invertida.

     (reverse '(1 3 5 9 11)) is  (11 9 5 3 1)

append

regresa la concatenación de dos listas.

     (append '(1 3 5)  '(9 11))  is  (1 3 5 9 11)

Expresiones condicionales son de la forma:

(if test-exp then-exp)

(if test-exp then-exp else-exp).

Definiciones son de la forma:

     (define id exp)

Expresiones Lambda son funciones anónimas de la forma:

         (lambda (id...) exp )

Definiciones locales se introducen con las funciones let, let* y letrec. let se aplica en paralelo, let* es secuencial, y letrec permite definiciones recursivas.

apply regresa el resultado de aplicar el primer argumento al segundo.

1 ]=>  (apply + '(7 5)) 

;Value:   12 

1 ]=>  (apply max '(3 7 2 9))
 

;Value:   9

map regresa una lista que es el resultado de aplicar el primer argumento a cada elemento del segundo.

1 ]=>   (map odd? '(2 3 4 5 6)) 

;Value: (() #T () #T ())

Referencias:

The Allegro Common Lisp Open Source Center

Allegro CL

http://www.cs.berkeley.edu/~fateman/generic/

Richard J. Fateman

Algoritmos en Scheme

Taller sobre Scheme

Hobbit versión 5 compila R4RS Scheme a código C, que se puede usar con SCM Scheme Implementation

El paquete SLIB es una librería portable del lenguaje Scheme que funciona en varias plataformas e implementaciones, incluyendo Guile.

Generación automática de código

Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.


Surge entonces la necesidad de mecanizar el proceso de producción de software, y además hacerlo de manera flexible y ágil que permita incorporar la parte variable de manera robusta.

Un enfoque es desarrollo Cut-and-Paste usando programadores experimentados en el desarrollo de aplicaciones similares a la que se esta haciendo. Este modelo tiene sus limitaciones y no es realmente escalable. Por un lado es propenso a errores y consume horas-hombre que serian mejor empleadas en actividades que se beneficien de la capacidad creativa y visión del desarrollador. Por otro lado, realmente no permite de manera natural institucionalizar y transferir experiencias entre desarrolladores y entre grupos de desarrolladores.

En el ciclo de vida y desarrollo de una aplicación se requieren distintas perspectivas y niveles de abstracción. En un proceso mecanizado de desarrollo debe haber herramientas que idealmente nos permita partir de la conceptualización de las necesidades de negocio y de manera automática llegar a la implantación bajo tecnologí­as especí­ficas.

El grupo de patrones y prácticas de Microsoft ha desarrollado el concepto de fábricas de software como paquetes de referencia que incluyen una serie de artefactos que permiten mecanizar el desarrollo de familias de aplicaciones. Estos artefactos incluyen modelos, marcos (frameworks) y herramientas.

Introducción a Perl

Practical Extraction and Reporting Language.

There is more than one way to do it

Puntos a favor de perl:

• perl es un lenguaje de alto nivel


• perl es gratis


• perl puede escribir y leer archivos binarios


• perl puede tener múltiples archivos de entra y salida abiertos al mismo tiempo


• Tiene un generador de reportes


• Maneja expresiones regulares


• Maneja arreglos lineales y asociativos


• Es poderoso y simplifica la programación


• Puede procesar archivos muy grandes sin limites en el tamaño de registro


• perl incluye un conjunto amplio y poderoso de instrucciones para manejo de cadenas de caracteres y arreglos


• Cualquier cosa se puede realizar de múltiples formas

Ejemplo de programa en Perl:

# Este sencillo programa copia registros de un archivo # y agrega un prefijo a cada línea con un numero en secuencia while (< >){ # while () {} genera un lazo de control que continua mientras el # enunciado en paréntesis es verdadero. # la instrucciones en el lazo están dentro de los corchetes {} # < > es un símbolo especial # Le dice a Perl que busque en la línea de comando y vea si se # especificaron algunos archivos. # Si es el caso, entonces se lee cada uno en turno. # Si no se especifica ningún archivo entonces se lee de # la entrada normal (standard input) # Cualquiera que sea el caso los caracteres que se leen se guardan # en la variable especial $_ # Cuando <> llega al fin de archivo (end-of-file), regresa un valor de falso, # lo cual termina el lazo. print STDOUT ++$i, $_;# print es un método simple sin formato de impresión # STDOUT es una referencia de archivo normal (standard filehandle) # para la salida normal (Standard Output). # Filehandles se especifican en MAYUSCULAS en perl. # ++$i indica incrementar el valor de $i y dejar el valor disponible # para la instrucción print # Todos los valores escalares ( es decir cualquier cosa menos una instrucción, # un arreglo lineal, un arreglo asociativo, filehandle, o nombre de procedimiento) # empieza con $ en perl # $_ es el operador de default de cualquier instrucción # en este caso, $_ contiene el último registro que leyó la instrucción<> # ; termina cada instrucción en perl }

Breve revisión de la sintaxis de perl

• En perl es significativo el caso de los caracteres y se diferencia entre mayúsculas y minúsculas


• No utilice nombres que empiezen con un numero, ya que estos comúnmente son símbolos especiales para perl, por ejemplo $1, $2, etc.


• Todas las instrucciones en perl terminan con punto y coma ;


• Comentarios se pueden insertar en un programa con el símbolo #, y cualquier cosa después de # hasta el fin de línea será ignorado


• perl identifica cada tipo de variable o nombre de dato con un prefijo. Estos caracteres son:
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  Tipo	Carácter	Comentario
  Escalar	$	Un numero o cadena de caracteres
  Vector lineal	@	Un arreglo referenciado por un numero índice. Subí­ndices entre paréntesis cuadrados []. @cosa se refiere al arreglo completo. $cosa[1] se refiere al escalar que ocupa la segunda posición en el arreglo
  Vector asociativo	%	Un vector referenciado por una llave de texto, no necesariamente un número. Subí­ndices entre{}. %cosa se refiere al vector completo. $elemento{"x"} se refiere al escalar que corresponde a la llave "x"
  filehandle	UC	Los apuntadores se archivo se escriben en mayúsculas
  Subrutina	&	Una subrutina
  Etiqueta	xx:	Objeto de goto

  
  


• Valores entre paréntesis () son listas. Las listas se usan frecuentemente como argumentos para una subrutina o llamada a función. No es necesario usar paréntesis si solo se usa un argumento o el programa conoce el limite de la lista.


• Las variables $x, @x. %x, y &x, no necesitan estar relacionadas entres si, sin mencionar $X, @X, %X y &X.


• Existen variables especiales, las más importantes son:

  $_

  Es el valor escalar de default. Si no se especifica un nombre de variable en una función donde se usa una variable escalar, se usa $_. Esto se usa bastante en perl

  @_

  Es la lista de argumentos a una subrutina

  @ARGV

  Es la lista de argumentos especificada en la línea de comando cuando el programa se ejecuta

Instrucciones básicas y control

Los corchetes {} se usan para contener un bloque de enunciados. Es posible tener variables locales dentro de un bloque. Bloques se usan como los objetos de la mayoría de los comandos de control

Asignación simple:

• Asignación escalar


• Listas de escalares


• Lista a vector


• Vector a lista


• Vectores asociativos necesitan un llave, pero aparte de eso, funcionan como se espera de un vector


• Al asignar un vector a un escalar se obtiene el numero de elementos del vector

Operaciones aritméticas

• perl cuenta con las operaciones usuales y algunas más.


• Modificadores


• Funciones

if-then-else

• 
  
  
  
  
  

  if( condición ) { rama verdadera } else { rama falsa }

  
  


• 
  
  
  
  
  

  if (condición) {instrucciones} elsif (condición) {instrucciones} elsif (condición) {instrucciones}

  
  


• 
  
  
  
  
  

  unless (condición) { rama verdadera }

  
  


• La condición tiene una gama amplia de operadores comparativos. Es importante observar la diferencia entre operadores numéricos y de cadenas de caracteres.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  Numérico	Cadenas	Significado
  = =	eq	igual
  !=	ne	no igual
  >	gt	mayor que
  <	lt	menor que

  
  


• Cadenas de caracteres. que no están compuestas por números tienen un valor de cero.


• perl cuenta con un conjunto extenso de pruebas de archivo:
  
  
  
  • -T cierto si archivo es de texto
  
  
  • -B cierto si archivo es binario
  
  
  • -M regresa el número de días desde la última modificación
  
  
  • -A regresa el número de días desde el último acceso al archivo
  
  
  • -C regresa el número de días desde la creación del archivo
  
  
  
  

Lazos de control

Los lazos más comunes son for y while

• for ($i = 0; $i < 10; $i++) { instrucciones }


• foreach $i (@items) { instrucciones }


• foreach $i ($first .. $last) { instrucciones }


• while (condición) { instrucciones }


• until (condición) { instrucciones }


• Las instrucciones next, last, redo, y continue se usan para escapar de un lazo.

Entrada/Salida

Abrir

Como en Unix, los tres primeros manejadores de archivos se abren automáticamente y son STDIN, STDOUT, y STDERR. Otros archivos se deben abrir explícitamente. La forma de la instrucción open es la siguiente:
open (FILEHANDLE,XFY);
donde X y Y son caracteres opcionales

X = <

Para abrir archivo F solo lectura

X = >

Para abrir archivo F solo escritura

X = > >

Para agregar datos al final de archivo F

X = |

Para escribir a un tubo (pipe) hacia programa F

Y = |

Para leer a un tubo (pipe) desde programa F

Si solo se da el nombre F, el archivo se abre de lectura/escritura

Lectura

La forma más básica de lectura es poner el manejador de archivos dentro de <>. Si no se provee una variable escalar para el registro, este se guarda en $_.

Escritura

La mayor parte de la escritura se hace usando la instrucción print o printf. Estas instrucciones se utilizan aún si el resultado no se va a imprimir realmente.

Cerrar

perl cierra automáticamente cualquier archivo al salir. Cuando se necesita cerrar un archivo se puede hacer con un cierre explicito.

Mensajes de error:

• die se usa para imprimir un mensaje de error y terminar la ejecución


• warn se usa para imprimir un mensaje de error pero continuar

Manejo de cadenas de caracteres:

• split se usa para extraer fichas (tokens) o campos de una cadena a un vector.


• sort ordena una lista o vector.


• study optimiza operaciones de cadenas.

Codificación binaria:

• pack empaca datos en una cadena usando un machote de formato


• unpack recupera datos de una cadena usando un machote de formato


• Existe una larga lista de formatos que se pueden usar


• Se puede usar más de un formato a la vez
  
  
  
  • l long 32 bit signed integer
  
  
  • L long 32 bit unsigned integer
  
  
  • s short 16 bit signed integer
  
  
  • S short 16 bit unsigned integer
  
  
  • f float 32 bit floating point
  
  
  • d double 64 bit floating point
  
  
  • A ASCII string
  
  
  • c char a single byte (character)
  
  
  
  

Expresiones regulares:

perl añade un conjunto de caracteres al conjunto normal. Uno uso importante de expresiones regulares (RE) es el uso de () para seleccionar subconjuntos de la expresión regular. perl facilita el uso del operador (). Existen dos maneras de usar expresiones regulares en perl: Match y Substitute

Una expresión regular esta contenida en slashes, y el operador =~ evalúa.

Las expresiones regulares son sensitivas a mayúsculas y minúsculas

El operador !~ se usa para detectar diferencias.

Algunos caracteres especiales:

.

Cualquier Carácter menos newline

^

El principio de lí­nea o de cadena

$

El fin de línea o cadena

?

Cero o más del último Carácter

+

Uno o más del último Carácter

[]

Cualquiera de los caracteres dentro de los corchetes []

|

o inclusivo

()

Agrupar

\

Los caracteres especiales $, |, [, ), \, / deben ir precedidos por backslash para usarse en expresiones regulares

$` $& $'

$` , $& y $' se pueden usar para ver cuales fueron los caracteres que se encontraron antes, durante, y después de un empate

Referencias

Active State

Active Perl

Live tutorials

Distribuciones binarias

Open Perl IDE

Documentación.

Introduction to Perl

Programación orientada a aspectos

Tal vez sea porque estamos a principios de siglo o simplemente un espejismo pero pareciera que estamos en los albores de un cambio paradigmático en el desarrollo de software post orientación a objetos.




Uno de los ideales del desarrollo de software es la capacidad de modificar el funcionamiento de un sistema sin tocar una línea de código. Algunos enfoques en este sentido es inyección de dependencias y programación orientada a aspectos (AOP).


David Hayden en su bitácora presenta un ejemplo, en el contexto de la librería empresarial del grupo de patrones y practicas de Microsoft, del uso del bloque de aplicación de inyección de políticas para guardar registros de llamadas a métodos y se quejaba de que la librería en realidad no soporta el patrón de inyección de dependencias. Lo cual provoco una demostración de las capacidades de Windsor para soportar AOP.

Referencias:

"In-flght" profiling with AOP
Aspect# Integration Facility
Castle
Windsor AOP - Policy Injection Application Block - Best Way to Use Windsor AOP?
Building the Policy Injection in 40 Minutes with Windsor
Castle Windsor AOP - Dependency Injection and Aspect-Oriented Programming - Policy Injection Application Block
Policy Injection Application Block Example
ObjectBuilder is Getting Some Love for the CodePlex Container
.NET Community Downloads and Sample Code