Paradigma de programacin

A lo largo de la historia, el trmino paradigma fue objeto de muchas interpretaciones.

En su origen griego, significaba modelo, ejemplo o patrn. Sobre este punto de
partida, podemos hablar de un paradigma como un conjunto de creencias, prcticas y
conocimientos que guan el desarrollo de una disciplina durante un perodo de
tiempo. En diversas ramas de la ciencia, un conjunto de ideas en vigencia puede ser
reemplazado drsticamente por otro que entre en conflicto con l y se demuestre ms
acertado. La programacin tiene sus propios paradigmas, pero el trmino paradigma de
programacin no necesariamente representa un modelo nico que deba ser respetado
hasta que aparezca otro mejor. De hecho, actualmente muchos paradigmas coexisten en
armona.
Un paradigma de programacin es un estilo de desarrollo de programas. Es decir, un
modelo para resolver problemas computacionales. Los lenguajes de programacin,
necesariamente, se encuadran en uno o varios paradigmas a la vez a partir del tipo de
rdenes que permiten implementar, algo que tiene una relacin directa con su sintaxis.
Cules son los principales paradigmas de programacin?
Imperativo. Los programas se componen de un conjunto de sentencias que
cambian su estado. Son secuencias de comandos que ordenan acciones a la
computadora.

Declarativo. Opuesto al imperativo. Los programas describen los resultados

esperados sin listar explcitamente los pasos a llevar a cabo para alcanzarlos.

Lgico. El problema se modela con enunciados de lgica de primer orden.

Funcional. Los programas se componen de funciones, es decir, implementaciones

de comportamiento que reciben un conjunto de datos de entrada y devuelven un
valor de salida.

Orientado a objetos. El comportamiento del programa es llevado a cabo por

objetos, entidades que representan elementos del problema a resolver y tienen
atributos y comportamiento.
Otros son de aparicin relativamente reciente y no forman parte del grupo principal:

Dirigido por eventos. El flujo del programa est determinado por sucesos
externos (por ejemplo, una accin del usuario).

Orientado a aspectos. Apunta a dividir el programa en mdulos independientes,

cada uno con un comportamiento bien definido.
Cada paradigma es ideal para la resolucin de un conjunto de problemas particular, por

lo que no puede decirse que uno sea necesariamente mejor que otro.

Paradigma Funcional
Introduccin
El objetivo del paradigma funcional es conseguir lenguajes expresivos y matemticamente
elegantes, en los que no sea necesario bajar al nivel de la mquina para describir
el proceso llevado a cabo por el programa, y evitando el concepto de estado del cmputo.
La secuencia de computaciones llevadas a cabo por el programa se regira nica y
exclusivamente por la reescritura de definiciones ms amplias a otras cada vez ms
concretas y definidas, usando lo que se denominan definiciones dirigidas.
Todo esto con el objetivo de familiarizar a los estudiantes con un lenguaje elegante en el
cual se pueda manejar ms fcilmente y as los programas sean menos extensos y
complejos.
Otro de los objetivos primordiales de dicho paradigma es buscar satisfacer las
necesidades del usuario con respecto a operaciones matemticas y convertirse en un
lenguaje ms expresivo.
Historia
Sus orgenes provienen del Clculo Lambda (o -clculo),
una teora matemtica elaborada por Alonso Church como apoyo a sus estudios sobre
Computabilidad. Un lenguaje funcional es, a grandes rasgos, un azcar sintctico del
Clculo Lambda.
Clculo Lambda
Los orgenes tericos del modelo funcional se remontan a la dcada del 30, mas
precisamente al ao 1934, cuando Alonso Church introdujo un modelo matemtico
de computacin llamado lambda calculo.
A pesar de que en esta poca las computadoras aun no existan el lambda clculo se
puede considerar como el primer lenguaje funcional de la historia y sus fundamentos
fueron la base de toda la teora de la programacin funcional y de los lenguajes
funcionales desarrollados posteriormente. Se puede decir que los lenguajes funcionales
modernos son versiones de lambda clculo con numerosas ayudas sintcticas.
Aunque cuando aparece el clculo lambda, an no existan las computadoras, resulta ser
una herramienta simple que se adelanta a su poca, que abarca dos operaciones:
a.
Definir alguna(s) funcin(es) de un solo argumento y con un cuerpo especfico,
denotado por la siguiente terminologa:
b.
i.
ii.

lx.B, en donde:
x: Define el parmetro o argumento formal.

a.

iii.

B: Representa el cuerpo de la funcin.

iv.

Es decir f(x) = B.

REDUCCION:
Consiste en aplicar alguna de las funciones creadas, sobre un argumento real (A);
resultado de sustituir las ocurrencias del argumento formal (x), que aparezcan en el
cuerpo (B) de la funcin, con el argumento (A),
es decir: (lx.B)
Ejemplo:
(lx.(x+5))3, indica que en la expresin x + 5, debemos sustituir el valor de x por 3.
Cuando ya no es posible reducir una funcin, se dice que sta se encuentra en su estado
normal, o sea hemos encontrado el valor de la funcin, que depender nicamente de los
argumentos y siempre tendr la consistencia de regresar el mismo valor para los mismos
argumentos.
Lo anterior es la transferencia referencial y al no contar con variables globales, permiten
al sistema la ejecucin de procesos en forma paralela para incrementar su eficiencia.
Sobre estos simples conceptos est basada la programacin funcional, aunque existen
otros, usados para identificarla y aumentan su potencial en el desarrollo de aplicaciones.
Caractersticas
Los programas escritos en un lenguaje funcional estn constituidos nicamente por
definiciones de funciones, entendiendo stas no como subprogramas clsicos de un
lenguaje imperativo, sino como funciones puramente matemticas, en las que se verifican
ciertas propiedades como la transparencia referencial (el significado de una expresin
depende nicamente del significado de sus subexpresiones), y por tanto, la carencia total
de efectos laterales.
Otras caractersticas propias de estos lenguajes son la no existencia de asignaciones de
variables y la falta de construcciones estructuradas como la secuencia o la iteracin (lo
que obliga en la prctica a que todas las repeticiones de instrucciones se lleven a cabo por
medio de funciones recursivas).
Existen dos grandes categoras de lenguajes funcionales: los funcionales puros y los
hbridos. La diferencia entre ambos estriba en que los lenguajes funcionales hbridos son
menos dogmticos que los puros, al admitir conceptos tomados de los lenguajes
procedimentales, como las secuencias de instrucciones o la asignacin de variables.
En contraste, los lenguajes funcionales puros tienen una mayor potencia expresiva,
conservando a la vez su transparencia referencial, algo que no se cumple siempre con un
lenguaje funcional hbrido.
Entre los lenguajes funcionales puros, cabe destacar a Haskell y Miranda. Los lenguajes
funcionales hbridos ms conocidos son Lisp, Scheme, Ocaml y Standard ML (estos dos
ltimos, descendientes del lenguaje ML).
La programacin funcional, es un modelo basado en la evaluacin de funciones
matemticas, entendidas como mecanismos para aplicar ciertas operaciones sobre
algunos valores o argumentos, para obtener un resultado o valor de la funcin para tales
argumentos.

Sin embargo, tanto argumentos como resultado de una funcin, pueden ser otra funcin,
o incluso la misma, tal como una forma de recursividad, que constituye una poderosa
herramienta de la programacin funcional
Lenguajes Funcionales
Los matemticos desde hace un buen tiempo estn resolviendo problemas usando el
concepto de funcin. Una funcin convierte ciertos datos en resultados. Si supiramos
cmo evaluar una funcin, usando la computadora, podramos resolver automticamente
muchos problemas.
As pensaron algunos matemticos, que no le tenan miedo a la mquina, e inventaron los
lenguajes de programacin funcionales. Adems, aprovecharon la posibilidad que tienen
las funciones para manipular datos simblicos, y no solamente numricos, y
la propiedad de las funciones que les permite componer, creando de esta manera, la
oportunidad para resolver problemas complejos a partir de las soluciones a otros ms
sencillos.
Tambin se incluy la posibilidad de definir funciones recursivamente.
Un lenguaje funcional ofrece conceptos que son muy entendibles y relativamente fciles
de manejar para todos los que no se durmieron en las clases de matemticas. El
lenguaje funcional ms antiguo, y seguramente el ms popular hasta la fecha, es LISP,
diseado por McCarthy [1] en la segunda mitad de los aos 50. Su rea de aplicacin es
principalmente laInteligencia Artificial. En la dcada de los 80 hubo una nueva ola
de inters por los lenguajes funcionales, aadiendo la tipificacin y algunos conceptos
modernos de modularizacin y polimorfismo, como es el caso del lenguaje ML.
Programar en un lenguaje funcional significa construir funciones a partir de las ya
existentes. Por lo tanto es importante conocer y comprender bien las funciones que
conforman la base del lenguaje, as como las que ya fueron definidas previamente. De esta
manera se pueden ir construyendo aplicaciones cada vez ms complejas.
La desventaja de este modelo es que resulta bastante alejado del modelo de la mquina
de von Neumann y, por lo tanto, la eficiencia de ejecucin de los intrpretes de lenguajes
funcionales no es comparable con la ejecucin de los programas imperativos
precompilados. Para remediar la deficiencia, se est buscando utilizar arquitecturas
paralelas que mejoren eldesempeo de los programas funcionales, sin que hasta la fecha
estos intentos tengan un impacto real importante.
Los dos mecanismos bsicos presentados anteriormente se corresponden con los
conceptos de abstraccin funcional y aplicacin de funcin; si le agregamos un conjunto
de identificadores para representar variables se obtiene lo mnimo necesario para tener
un lenguaje de programacin funcional. Lambda calculo tiene el
mismo poder computacional que cualquier lenguaje imperativo tradicional.
Las ventajas de tener un lenguaje tan simple son:
Permite definiciones simples.

Facilita el estudio de aspectos computacionales.

Su carcter formal facilita la demostracin de propiedades.

Aplicaciones
Compilacin de lenguajes funcionales.

Especificar semntica a lenguajes imperativos.

Formalismo para definir otras teoras.

Programacin funcional:
La crtica de John Backus a los "lenguajes convencionales de von Neumann" llam
la atencin hacia la programacin funcional (hacia 1978). El estilo de programacin
adoptado por Backus fue denominado FP (Functional Programming).
El componente bsico de los lenguajes funcionales es la nocin de funcin y
su estructura de control esencial la aplicacin de una funcin. Entre los lenguajes
funcionales se encuentran ISWIM, ML, LISP y todos sus derivados, como Scheme. Las
caractersticas fundamentales de los lenguajes funcionales de programacin son, segn
[SET92]:
1. El valor de una expresin depende slo de los valores de sus subexpresiones, si las
tiene. La programacin funcional pura es una programacin sin asignaciones. En
realidad, la mayora de los lenguajes funcionales son impuros, ya que permiten
asignaciones. Sin embargo, su estilo de programacin es diferente al de los lenguajes de
programacin imperativa.
2. Almacenamiento implcito. El programador no debe preocuparse en manejar el
almacenamiento de datos. Una consecuencia de esto es que la implementacin del
lenguaje debe realizar una "recoleccin de basura" para recuperar la memoria que se ha
usado y no se volver a utilizar.
3. Las funciones son valores de primera clase. Una funcin puede ser el valor de una
expresin, pasarse como argumento o colocarse en una estructura de datos. Esto permite
potentes operaciones.
Al decir que un lenguaje de programacin es funcional, se suele hacer referencia al
paradigma de programacin funcional.
En trminos general, al desarrollar software en el paradigma de programacin, en
contraste con el paradigma de programacin imperativo, se tiende a enfatizar ms la
evaluacin de expresiones que la ejecucin secuencial de comandos.
En el fondo, para ejecutar programas los computadores ejecutan, de manera secuencial,
instrucciones de cdigo de mquina. De cierta forma, sto hace que los lenguajes
imperativos sean ms cercanos a la manera en que funcionan los computadores, al forzar
a los programadores a formular sus algoritmos como una serie de pasos que se realizarn
de manera secuencial.
Los lenguajes funcionales, por otro lado, son ms cercanos a la manera en que funciona
la mente humana, pues tienden a permitirle a los programadores describir sus algoritmos
como expresiones que sern evaluadas.
Hay varias consecuencias del nfasis en la evaluacin de expresiones que son comunes a
la mayora de lenguajes funcionales:
Los procedimientos son ciudadanos de primera categora Los procedimientos y
funciones son objetos visibles que pueden ser almacenados dentro
de estructuras complejas, pasados como argumentos, construidos en tiempo de ejecucin y
manipulados al igual que otros tipos como los nmeros y las cadenas.

Manejo automtico de memoria El programador no necesita llevar

un registro manual de la memoria utilizada por cada objeto y liberarla; la implementacin
del lenguaje se encarga de eso de manera automtica.
Los lenguajes funcionales han permanecido en uso por mucho tiempo y han mostrado
todo el poder de su gran nivel de expresividad. Al permitir la creacin de procedimientos
en tiempo de ejecucin, permiten un gran nivel de modularidad que, de acuerdo con sus
proponentes, difcilmente puede alcanzarse en otros paradigmas de programacin.
Dentro de los lenguajes funcionales se encuentran Lisp, Haskell, CaML y muchos otros.
El lenguaje provee algunas funciones basicas, que son primitivas para construir
funciones ms complejas. Se definen algunas estructuras para representar datos en los
parmetros y resultados de las funciones. Este paradigma normalmente se implementa
mediante interpretadores, pero tambien se pueden compilar.
Funciones
Los primeros ordenadores se construyeron en los aos cuarenta. Pronto se almacenaron
los programas en la memoria del ordenador, haciendo que los primeros lenguajes de
programacin hicieran su entrada. En aquel tiempo el uso de un ordenador era muy
costoso y era lgico que el lenguaje de programacin guardara mucha relacin con
la arquitectura del ordenador.
Un ordenador consta de una unidad de control y una memoria. Por eso un programa
consista en instrucciones para cambiar el contenido de la memoria. La unidad de control
se encargaba de ejecutarlas. De esta manera se creo el estilo de programacin imperativa.
Los lenguajes de programacin imperativa como Pascal y C se caracterizan por la
existencia de asignaciones ejecutadas consecutivamente.
Antes de la existencia de los ordenadores se inventaron mtodos para resolver problemas.
Por tanto, no exista la necesidad de hablar en trminos de una memoria que cambie por
instrucciones en un programa.
En la matemtica de los ltimos cuatrocientos aos son muy importantes las funciones.
Estas establecen la relacin entre los parmetros (la entrada) y el resultado (la salida) de
procesos definidos. Con cada computacin, el resultado depende de una u otra forma de
los parmetros. Por esa razn, una funcin es una buena manera de especificar una
computacin. Esta es la base del estilo de programacin funcional. Un programa consiste
en la definicin de una o mas funciones.
Para la ejecucin de un programa, se dan parmetros a una funcin y el ordenador tiene
que calcular el resultado. Con este tipo de computacin existe libertad en la manera de
ejecucin. Por qu tendra que describirse en qu orden deben ejecutarse las
computaciones parciales?
Con el tiempo, al bajar los precios de los ordenadores y al subir los precios de los
programadores, llega a ser ms importante describir las computaciones en un lenguaje
que est ms cerca del mundo del hombre, que cerca del ordenador. Los lenguajes
funcionales se unen a la tradicin matemtica y no estn muy influidos por la
arquitectura concreta del ordenador.
Scheme
Scheme es un lenguaje funcional, derivado de LISP. Scheme es un lenguaje compacto con
un alto grado de abstraccin, por lo cual resulta adecuado para cursos introductorios de
computacin, donde el nfasis est en la metodologa de resolucin de problemas. Scheme
permite resolver problemas complejos con programas cortos y elegantes. De este modo, el

lenguaje se convierte en un aliado para resolver problemas, no un problema ms que

resolver.
Historia
El desarrollo de los lenguajes funcionales ha sido influenciado a lo largo de la historia por
muchas fuentes, pero ninguna tan grande ni fundamental como el trabajo de Alonzo
Church en el Clculo Lambda.
El Clculo Lambda fue asimismo el fundamento en que se bas el desarrollo del Lisp,
pero el propio John McCarthy ha negado ese hecho3. El impacto del Clculo Lambda en el
desarrollo inicial del Lisp fue mnimo y no ha sido sino hasta recientemente que el
popular lenguaje ha comenzado a evolucionar de acuerdo con los ideales del mismo. Por
otra parte, Lisp ha tenido una gran influencia en el desarrollo de los lenguajes
funcionales que le siguieron.
La motivacin original de McCarthy para desarrollar Lisp fue el deseo de contar con un
lenguaje para procesamiento de listas algebraicas que pudiera usarse para llevar a
cabo investigacin en inteligencia artificial.
Uno de los primeros intentos por desarrollar un lenguaje de tal naturaleza fue realizado
por McCarthy, con el llamado FLPL (FORTRAN - compiled List Processing Language), que
se implement en el FORTRAN con que contaba la IBM 704 en 1958. Durante los aos
subsiguientes McCarthy dise, refin e implement Lisp (List Processor), en parte porque
FLPL no contaba con recursividad ni con condicionales dentro de las expresiones.
Lisp no es slo uno de los lenguajes ms viejos que existen, sino tambin el primero en
proporcionar recursividad, funciones como ciudadanos de primera clase, recoleccin
de basura y una definicin formal del lenguaje (escrita asimismo en Lisp). Las diversas
implementaciones de Lisp desarrolladas a travs de los aos han sido tambin pioneras
en cuanto al uso de ambientes integrados de programacin, los cuales combinan editores,
intrpretes y depuradores.
Las primeras implementaciones de Lisp tuvieron, sin embargo, algunos problemas que las
hicieron perder popularidad, como por ejemplo su tremenda lentitud para efectuar
clculos numricos, su sintaxis basada por completo en parntesis que suele causar gran
confusin entre los usuarios novatos y su carencia de tipos que hace difcil la deteccin
de errores y el desarrollo de compiladores.
Adems, problemas adicionales tales como la carencia de verdaderas funciones como
ciudadanos de primera clase y el uso de reglas de mbito dinmicas, bajo las cuales el
valor de una variable libre se toma del ambiente de activacin, hicieron que Lisp se
mantuviera durante un buen tiempo como un lenguaje restringido a los laboratorios de
investigacin, lejos del alcance de un nmero significativo de usuarios. El mismo
McCarthy afirm que su lenguaje no era apropiado "para los programadores novatos o los
no programadores", pues se requera una cierta cantidad de "conocimientos sofisticados
para apreciar y usar el lenguaje efectivamente".
A partir de 1962, el desarrollo del Lisp divergi en un gran nmero de dialectos, entre los
que destacan MacLisp y ZetaLisp en el Instituto Tecnolgico de Massachusetts (MIT),
Franz Lisp en la Universidad de California en Berkeley, ICI-Lisp en la Universidad de
Stanford, y el InterLisp, un producto comercial desarrollado por Bolt, Boranek y Newman
(en un laboratoriode investigacin privado de los Estados Unidos).
En el otoo de 1975 Gerald Jay Sussman y Guy Lewis Steele Jr. se encontraban
estudiando la teora de los actores como un modelo de computacin desarrollada por Carl
Hewitt en MIT.

El modelo de Hewitt estaba orientado a objetos y con una fuerte influencia del Smalltalk.
De acuerdo con l, cada objeto era una entidad computacionalmente activa capaz de
recibir y de reaccionar a los mensajes. A estos objetos y los mensajes que intercambiaban,
Hewitt los llam actores. Dado que Sussman y Steele afrontaban dificultades para
entender algunos aspectos tericos y prcticos del trabajo de Hewitt, decidieron construir
un pequeo intrprete de este lenguaje usando MacLisp, a fin de poder experimentar con
l. Como Sussman haba estado estudiando Algol en aquella poca, le sugiri a Steele
comenzar con un dialecto de Lisp que tuviera reglas de mbito esttico (i.e., el valor de
una variable libre se toma de su ambiente de definicin).
Esta decisin les permiti crear actores con la misma facilidad con que se crean las
funciones en Lisp (y usando casi los mismos mecanismos). El paso de mensajes se podra
entonces expresar sintcticamente en la misma forma en que se invoca una funcin. La
nica diferencia entre un actor y una funcin era que una funcin regresaba un valor y
un actor no regresaba nada, sino que ms bien invocaba una continuacin, o sea, otro
actor que saba de su existencia.
Sussman y Steele se sintieron tan satisfechos con su mini-intrprete que decidieron
llamarlo "Schemer", pensando que con el tiempo se convertira en otro lenguaje que se
pudiera utilizar en inteligencia artificial, tal y como PLANNER, el lenguaje desarrollado
por Hewitt. Sin embargo, el sistema operativo ITS limitaba los nombres a 6 letras, por lo
que el apelativo del intrprete hubo de ser truncado a "Scheme", que es como se le conoce
hoy en da.
Persuadidos de que su intrprete pareca capturar muchas de las ideas que circulaban
entonces sobre lenguajes de programacin, Sussman y Steele decidieron publicar la
definicin de Scheme en la forma de un memo del laboratorio de inteligencia artificial del
MIT. Esta primera definicin del lenguaje era sumamente austera, con un mnimo de
primitivas (una por concepto), pero marc el inici de lo que se convertira en un lenguaje
de programacin sumamente popular en las esferas acadmicas.
En 1976, Sussman y Steele publicaron dos artculos en los que se hablaba sobre
semntica de los lenguajes de programacin usando Scheme: "Lambda: The Ultimate
Imperative" y "Lambda: The Ultimate Declarative", en los cuales los autores enfatizaran el
hecho de que Scheme poda soportar eficientemente los principales paradigmas de
programacin actuales (i.e., imperativo, funcional y orientado a objetos). Esta ltima
publicacin se convirti de hecho en la propuesta de tesis de maestra de Steele, que
culmin en el desarrollo de un compilador de Scheme llamado RABBIT.
Histricamente, Scheme contribuy a estrechar la brecha entre los tericos (que
estudiaban el Clculo Lambda y el modelo de actores) y los prcticos (implantadores y
usuarios de Lisp) en el rea de lenguajes de programacin. Adems, Scheme hizo la
semntica denotacional mucho ms accesible a los programadores y proporcion una
plataforma operacional que permitiera a los tericos realizar sus experimentos. Por su
reducido tamao, no haba necesidad de tener una versin centralizada del lenguaje que
tuviera que soportar un gran nmero de plataformas, como suceda con Lisp.
De tal forma, brotaron por todas partes implementaciones y dialectos de Scheme hacia
inicios de los 80. Un ejemplo es el Scheme 311, desarrollado en la Universidad de Indiana
varios aos antes de que alguien hiciera un intento por producir una implementacin
aislada del lenguaje (i.e., que no tuviera que montarse sobre Lisp).
Conclusin
Hoy en da Scheme es un lenguaje simple, pero poderoso; pequeo, pero flexible. Su
naturaleza lo hace ideal para la enseanza, incluso como primer lenguaje de

programacin, por su notable facilidad para incorporar diversos paradigmas con slo un
puado de primitivas.
Como lenguaje imperativo, conserva la pureza y elegancia que le proporcionan la
recursividad y las funciones de orden superior, superando as a muchos de los lenguajes
que hoy gozan de gran popularidad, tales como Pascal y C. Como lenguaje orientado a
objetos, hace alarde de un sistema de paso de mensajes y de manipulacin de objetos
equiparable nicamente al de Smalltalk. Su mecanismo de continuaciones proporciona
procedimientos de escape como ciudadanos de primer orden, condenando a la
obsolescencia a los mecanismos similares con que cuentan otros lenguajes.
El uso de streams permite implementar la evaluacin concisa, convirtiendo al lenguaje en
una herramienta idnea para cursos avanzados de lenguajes de programacin. Una de
sus pocas desventajas estriba en su carencia de tipos, aunque existen versiones de
Scheme que incorporan un sistema similar al de ML (por ejemplo, Scheme 48).
Desde una perspectiva ms pragmtica, podemos decir que su sintaxis es
extremadamente simple, lo que permite que el lenguaje pueda dominarse fcilmente en
slo 6 meses. Los estudiantes suelen preferirlo, sobre todo, cuando se trata del primer
lenguaje de programacin que aprenden, y los instructores lo elogian porque facilita la
enseanza de ideas de abstraccin y diseo de algoritmos, tan tiles para formar buenos
programadores.
Con la sabia filosofa de proporcionar slo una primitiva que haga lo que queremos en vez
de varias, como en otros lenguajes, Scheme se erige en la cima de los lenguajes preferidos
por las nuevas generaciones, ya no slo como una mera curiosidad cientfica, como se vi
a Lisp en otra poca, sino como una herramienta efectiva que sirve para aprender a
programar y a resolver problemas del mundo real.

Paradigma funcional

Diagrama del funcionamiento de una subrutina.

En ciencias de la computacin, la programacin funcional es un paradigma de
programacin declarativa basado en la utilizacin de funciones aritmticas que no maneja
datos mutables o de estado. Enfatiza la aplicacin de funciones, en contraste con el estilo
de programacin imperativa, que enfatiza los cambios de estado. La programacin

funcional tiene sus races en el clculo lambda, un sistema formal desarrollado en los
aos 1930 para investigar la definicin de funcin, la aplicacin de las funciones y la
recursin. Muchos lenguajes de programacin funcionales pueden ser vistos como
elaboraciones del clculo lambda.
En la prctica, la diferencia entre una funcin matemtica y la nocin de una "funcin"
utilizada en la programacin imperativa es que las funciones imperativas pueden tener
efectos secundarios, al cambiar el valor de clculos realizados previamente. Por esta razn
carecen de transparencia referencial, es decir, la misma expresin sintctica puede
resultar en valores diferentes en diferentes momentos dependiendo del estado del
programa siendo ejecutado. Con cdigo funcional, en contraste, el valor generado por una
funcin depende exclusivamente de los argumentos alimentados a la funcin. Al eliminar
los efectos secundarios se puede entender y predecir el comportamiento de un programa
mucho ms fcilmente, y esta es una de las principales motivaciones para utilizar la
programacin funcional.
Los lenguajes de programacin funcional, especialmente los que son puramente
funcionales, han sido enfatizados en el ambiente acadmico principalmente y no tanto en
el desarrollo de software comercial. Sin embargo, lenguajes de programacin importantes
tales como Scheme, Erlang, Rust, Objective Caml y Haskell, han sido utilizados en
aplicaciones comerciales e industriales por muchas organizaciones. La programacin
funcional tambin es utilizada en la industria a travs de lenguajes de dominio especfico
como R (estadstica), Mathematica (matemticas simblicas), J y K (anlisis financiero),
F# en Microsoft.NET y XSLT (XML). Lenguajes de uso especfico usados comnmente
como SQL y Lex/Yacc, utilizan algunos elementos de programacin funcional,
especialmente al procesar valores mutables. Las hojas de clculo tambin pueden ser
consideradas lenguajes de programacin funcional.
La programacin funcional tambin puede ser desarrollada en lenguajes que no estn
diseados especficamente para la programacin funcional. En el caso de Perl, por
ejemplo, que es un lenguaje de programacin imperativo, existe un libro que describe
como aplicar conceptos de programacin funcional. JavaScript, uno de los lenguajes ms
ampliamente utilizados en la actualidad, tambin incorpora capacidades de programacin
funcional. Python tambin incorpora particularidades de los lenguajes funcionales como
listas de comprensin y funciones de tratamiento de listas como matemtica de
conjuntos. Java en su versin 8, esta incorporando la programacin funcional, as como
el uso de las expresiones lambda.
Utilidad
El objetivo es conseguir lenguajes expresivos y matemticamente elegantes, en los que no
sea necesario bajar al nivel de la mquina para describir el proceso llevado a cabo por el
programa, y evitar el concepto de estado del cmputo. La secuencia de computaciones

llevadas a cabo por el programa se rige nica y exclusivamente por la reescritura de

definiciones ms amplias a otras cada vez ms concretas y definidas, usando lo que se
denominan "definiciones dirigidas".
Caractersticas
Los programas escritos en un lenguaje funcional estn constituidos nicamente por
definiciones de funciones, entendiendo stas no como subprogramas clsicos de un
lenguaje imperativo, sino como funciones puramente matemticas, en las que se verifican
ciertas propiedades como la transparencia referencial (el significado de una expresin
depende nicamente del significado de sus subexpresiones), y por tanto, la carencia total
de efectos colaterales.
Otras caractersticas propias de estos lenguajes son la no existencia de asignaciones de
variables y la falta de construcciones estructuradas como la secuencia o la iteracin (lo
que obliga en la prctica a que todas las repeticiones de instrucciones se lleven a cabo por
medio de funciones recursivas).
Existen dos grandes categoras de lenguajes funcionales: los funcionales puros y
los hbridos. La diferencia entre ambos estriba en que los lenguajes funcionales hbridos
son menos dogmticos que los puros, al admitir conceptos tomados de los lenguajes
imperativos, como las secuencias de instrucciones o la asignacin de variables. En
contraste, los lenguajes funcionales puros tienen una mayor potencia expresiva,
conservando a la vez su transparencia referencial, algo que no se cumple siempre con un
lenguaje funcional hbrido.
Funciones de primera clase y de orden superior
Funciones de orden superior son funciones que pueden tomar otras funciones como
argumentos o devolverlos como resultados. En clculo , un ejemplo de una funcin de
orden superior es el operador diferencial d / dx , que devuelve la derivada de una funcin
f.
Las funciones de orden superior estn estrechamente relacionadas con las funciones de
primera clase en las cuales las funciones de orden superior y las funciones de primera
clase pueden recibir como argumentos y resultados otras funciones. La distincin entre
los dos es sutil: "de orden superior", describe un concepto matemtico de funciones que
operan sobre otras funciones, mientras que la "primera clase" es un trmino informtico
que describe las entidades del lenguaje de programacin que no tienen ninguna
restriccin de su utilizacin (por lo tanto funciones de primera clase pueden aparecer en
cualquier parte del programa que otras entidades de primer nivel como los nmeros
pueden, incluidos como argumentos a otras funciones y como sus valores de retorno).

Las funciones de orden superior permiten la aplicacin parcial, una tcnica en la que se
aplica una funcin a sus argumentos uno a la vez, con cada aplicacin devolver una
nueva funcin que acepta el siguiente argumento. Esto le permite a uno expresar, por
ejemplo, la funcin sucesor como el operador de suma aplicada parcialmente al nmero
natural uno.
Funciones puras
Las funciones puramente funcionales (o expresiones) no tienen efectos secundarios
(memoria o E/S). Esto significa que las funciones puras tienen varias propiedades tiles,
muchas de las cuales pueden ser utilizados para optimizar el cdigo:

Si no se utiliza el resultado de una expresin pura, se puede eliminar sin afectar a

otras expresiones.

Si una funcin pura se llama con parmetros que no causan efectos secundarios,
el resultado es constante con respecto a la lista de parmetros (a veces llamada
transparencia referencial), es decir, si la funcin pura se llama de nuevo con los
mismos parmetros, el mismo resultado ser devuelto (esto puede habilitar las
optimizaciones de almacenamiento en cach).

Si no hay una dependencia de datos entre dos expresiones puras, entonces su

orden puede ser invertido, o pueden llevarse a cabo en paralelo y que no pueda
interferir con los otros.

Si el lenguaje no permite efectos secundarios, entonces cualquier estrategia de

evaluacin se puede utilizar, lo que da la libertad al compilador para reordenar o
combinar la evaluacin de expresiones en un programa (por ejemplo, usando la
poda).

La mayora de los compiladores de lenguajes imperativos detectan funciones puras

automticamente y realizan la eliminacin de subexpresiones comunes. Sin embargo no
siempre es posible detectarlo en bibliotecas pre-compiladas, porque por norma general no
dan esta informacin. Esto provoca que no se puedan realizar optimizaciones que podran
aplicar a dichas funciones externas. Algunos compiladores, como gcc, s que aaden
palabras claves adicionales para que el programador marque explcitamente como puras
aquellas funciones externas que proceda, de modo que se le apliquen las optimizaciones
pertinentes. Fortran 95 tambin permite que declarar funciones "puras".
Recursividad
Iterar en los lenguajes funcionales es normalmente llevado a cabo mediante recursividad.
Las funciones recursivas se invocan a s mismas, permitiendo que una operacin se
realice una y otra vez hasta alcanzar el caso base. Aunque algunas recursividades
requieren el mantenimiento de una pila, la recursividad mediante una cola puede ser

reconocida y optimizada mediante un compilador dentro del mismo cdigo utilizado, para
implementar las iteraciones en un lenguaje imperativo. El estndar del esquema del
lenguaje requiere implementaciones para conocer y optimizar la recursividad mediante
una cola. La optimizacin de la recursividad mediante una cola puede ser implementada
transformando el programa a un estilo de pase de continuidad durante la compilacin,
entre otros enfoques.
Los patrones comunes de recursividad puede ser factorizados usando funciones comunes
ms grandes, con catamorfismos y anamorfismos (pliegues y despliegues), siendo
estos los ejemplos ms evidentes. Tal y como las mayores funciones ms comunes tienen
un rol anlogo para construir estructuras de control se tienen los iteradores en los
lenguajes imperativos.
La mayora de los lenguajes de programacin funcional de propsito general permiten la
recursividad sin restricciones y superan el test de Turing, lo que hace que el programa
que se interrumpe no pueda tomar un decisin, lo que puede causar una falta de solidez
en el razonamiento ecuacional y generalmente requiere introducir inconsistencia dentro
de la lgica expresada por los tipos del sistema del lenguaje. Algunos lenguajes de
propsito especial como Coq permiten tan slo recursividad bien fundamentada y tienen
una normalizacin fuerte(clculos no finalizados pueden ser expresados tan slo con
flujos de valores infinitos llamados codata) En consecuencia, estos lenguajes fallan el test
de Turing y declarar funciones ciertas en ellos es imposible, pero pueden declarar una
amplia clase de clculos interesantes mientras evitan los problemas producidos por la
recursividad sin restricciones. La programacin funcional limitada a la recursividad bien
construida con unas cuantas restricciones ms se llama programacin funcional total.
Evaluacin estricta frente a la no estricta
Los lenguajes funcionales pueden ser clasificados por el hecho de usar evaluacin
estricta(eager) o no estricta(lazy), conceptos que hacen referencia a cmo los argumentos
de las funciones son procesados cuando una expresin est siendo evaluada. La
diferencia tcnica est en la notacin semntica de las expresiones que contienen clculos
fallidos o divergentes. Bajo la evaluacin estricta, la evaluacin de cualquier trmino que
contenga un sub-trmino fallido har que este sea de por s fallido.
Por ejemplo, la expresin:
print length([2+1, 3*2, 1/0, 5-4])
fallar bajo evaluacin estricta por la divisin por cero en el tercer elemento de la lista.
Utilizando evaluacin no estricta, el tamao de la funcin devolver un valor de 4( por
ejemplo el nmero de elementos de la lista) ya que evaluar esto no afectar al estar
evaluando los que componen la lista. En resumen, la evaluacin estricta evala por

completo los argumentos a menos que sus valores requieran evaluar la propia funcin que
se llama a s misma.
La implementacin de la estrategia comn para evaluacin no estricta en los lenguajes
funcionales es la de reduccin mediante un grafo. La evaluacin no estricta es utilizada
por defecto en multitud de lenguajes funcionales puros, incluidos Miranda, Clean y
Haskell.
Hughes (1984) defenda la evaluacin no estricta como un mecanismo para mejorar la
modularidad de los programas a travs de la separacin de tareas, a partir de la
implementacin de productores y consumidores de flujos de datos de forma fcil e
independiente. Launchbury (1993) describe algunas dificultades que tena la evaluacin
no estricta, particularmente al analizar los requisitos de almacenamiento de los
programas, y propone una semntica operacional para ayudar durante el anlisis. Harper
(2009) propone incluir ambas tcnicas (evaluacin estricta y no estricta) en el mismo
lenguaje, utilizando los tipos del sistema del lenguaje para distinguirlas.
Tipo de sistemas
Especialmente desde el desarrollo de tipos de inferencia de Hindley - Milner en la dcada
de 1970, los lenguajes de programacin funcionales han tendido a utilizar el clculo con
tipo lambda, en comparacin con el clculo lambda sin tipo utilizado en Lisp y sus
variantes (tales como el lenguaje scheme). El uso de tipos de datos algebraicos y la
coincidencia de patrones hace que la manipulacin de estructuras de datos complejas
convenientes y expresivos, la presencia de comprobaciones estrictas de tipos en tiempo de
compilacin hace que los programas sean ms fiable, mientras que la inferencia de tipos
libera al programador de la necesidad de declarar manualmente los tipos para el
compilador.
Algunos lenguajes funcionales orientados a la investigacin, tales
como Coq, Agda, Cayenne y Epigram se basan en la teora de tipo intuicionista, que
permite a los tipos a depender de los trminos. Estos tipos se denominan tipos
dependientes. Estos sistemas de tipo no tienen un tipo decidible inferencia y son difciles
de entender y programar con plantillas de citacin. Pero tipos dependientes pueden
expresar proposiciones arbitrarias en la lgica de predicados.
A travs del isomorfismo de Curry-Howard, entonces, mecanografiados a programas en
estas lenguas se convierten en una forma de escribir las pruebas matemticas formales
de las que un compilador puede generar cdigo de certificado. Si bien estas lenguas son
principalmente de inters en la investigacin acadmica (incluyendo las matemticas
formalizadas), han comenzado a ser utilizado en la ingeniera tambin. Compcert es un
compilador para un subconjunto del lenguaje de programacin C que se escribe en Coq y
verific formalmente. Una forma limitada de tipos dependientes llamados tipos de datos
algebraicos generalizados (GADTs) puede ser implementado de una manera que ofrece

algunos de los beneficios de la programacin dependiente escrito, evitando la mayor parte

de su inconveniencia. GADTs estn disponibles en elGlasgow Haskell Compiler, en OCaml
(desde la versin 4.00) y en Scala y se han propuesto como adiciones a otros idiomas,
incluyendo Java y C#.
La programacin funcional en lenguajes no funcionalesEs posible utilizar un estilo de
programacin funcional en lenguajes que tradicionalmente no se consideran lenguajes
funcionales. Por ejemplo, tanto D y Fortran95 se apoyan explcitamente en funciones
puras. Funciones de primera clase, se han aadido lentamente a los lenguajes
principales. Por ejemplo, a principios de 1994, el apoyo a lambda, filtro, mapa, y reducir
esta en Python. Luego, durante el desarrollo de Python 3000, Guido van Rossum pidi la
eliminacin de estas caractersticas. Sin embargo, ms tarde cambi de opinin, y slo la
reduccin fue eliminado, a pesar de que sigue siendo accesible a travs de los mdulos de
biblioteca functools estndar. Funciones de primera clase tambin fueron introducidas
en PHP 5.3, Visual Basic9, C#3.0 y C++11.
En Java, las clases annimas a veces pueden ser utilizados para simular
[[Clausura_(informtica)|clausuras]. Sin embargo, las clases annimas no son siempre los
reemplazos completos de las clausuras, ya que tienen capacidades ms limitadas. Por
ejemplo, Java 8, incluye expresiones lambda para reemplazar determinadas clases
annimas. Sin embargo, la presencia de excepciones con comprobaciones en este lenguaje
puede desaconsejar el uso de programacin funcional, ya que puede ser necesario para
capturar las excepciones que se deben controlar para despus volverlas a lanzar ellos
(problema este que sin embargo no se produce en otros lenguajes sobre JVM que no
tienen excepciones comprobadas, como es Scala).
Muchos patrones de diseo orientado a objetos se pueden expresar en trminos de
programacin funcional por ejemplo : el patrn de estrategia simplemente dicta el uso de
una funcin de orden superior, y el patrn de visitantes corresponde aproximadamente a
un catamorfismo, o doble tambin conocido como reducir, comprimir, o inyectar, se refiere
a una familia de funciones de orden superior que analiza una estructura de datos
recursiva y se recombinan con el uso de una operacin de combinacin.
Del mismo modo, la idea de los datos inmutables de la programacin funcional se incluye
a menudo en lenguajes de programacin imperativa, por ejemplo, la tupla de Python, que
es una matriz inmutable.
Ventajas de usar un paradigma funcional
Entre las ventajas que suelen citarse de usar un paradigma funcional en la programacin
de computadoras, estn las siguientes:1

Ausencia de efectos colaterales

Proceso de depuracin menos problemtico

Pruebas de unidades ms confiables

Mayor facilidad para la ejecucin concurrente

Simulacin de estados
Hay tareas (como por ejemplo, el mantenimiento del saldo de una cuenta bancaria) que a
menudo parecen implementadas con estados. La programacin funcional pura acta
sobre esas tareas, tareas de entrada/salida de datos tales como entrada de datos por
parte del usuario y mostrar resultados por pantalla, de una forma diferente.
El lenguaje de programacin funcional Haskell lo implementa usando mnadas,
estructura que representa clculos que se describen como una secuencia de pasos,
derivada de la teora de categoras.
Las mnadas ofrecen una forma de abstraer ciertos tipos de patrones computacionales,
incluyendo (pero no limitado a) el diseo de operaciones con estados cambiantes (y otras
acciones secundarias tales como entrada/salida de datos) de una manera imperativa sin
perder la pureza. Mientras las mnadas existentes pueden ser fciles de aplicar en un
programa usando las plantillas y ejemplos adecuados, muchos estudiantes tienen
problemas para entenderlo conceptualmente, por ejemplo cuando se les pide definir
nuevas mnadas. (lo que a veces resulta necesario para ciertos tipos de libreras)2
Otra forma en la que los lenguajes funcionales pueden simular estados es rodeando una
estructura de datos que representa el estado actual como un parmetro para llamadas a
funciones. En cada llamada a funcin, se crea una copia de esta estructura de datos que
se diferencia con el resultado de la funcin. Esto se conoce como estilo de paso de
estado.
Los lenguajes funcionales no puros normalmente incluyen mtodos para gestionar el
cambio de estado ms directamente.Clojure por ejemplo, usa una gestin de referencias
que pueden ser actualizadas aplicando funciones puras al estado actual. Este tipo de
enfoque permite el cambio de estado, promoviendo el uso de funciones puras como la
mejor forma de realizar clculos.
Mtodos alternativos como Hoare logic, el cual es un sistema formal con un conjunto de
reglas lgicas que sirven para razonar con rigor acerca de la correccin de programas, y la
singularidad han sido desarrollados para realizar un seguimiento de los efectos
secundarios en los programas. Algunos lenguajes de investigacin modernos usan
sistemas de efectos para hacer explcita la presencia de efectos colaterales.
Cuestiones de eficiencia
Los lenguajes de programacin son tpicamente menos eficientes en el uso de CPU y
memoria que los lenguajes imperativos como pueden ser C y Pascal. Esto est relacionado

con el hecho de que algunas estructuras de datos de tamao indefinido como los vectores
tienen una programacin muy sencilla usando el hardware existente, el cual es
unamquina de Turing bastante evolucionada. Se puede acceder muy eficientemente a las
posiciones del array con CPUs con un alto grado de perfeccionamiento, haciendo pre
bsquedas eficientemente a travs de las memorias cach o manejado con
instrucciones SIMD. Y no es fcil crear componentes homlogos inmutables de propsito
general con la misma eficiencia. Para lenguajes puramente funcionales, el peor caso
descendente es el logartmico en el nmero de celdas de memoria usadas, porque las
estructuras de memoria que cambian de tamao pueden ser representadas por
estructuras de datos puramente funcionales con tiempo de acceso logartmico, como por
ejemplo un rbol equilibrado. Sin embargo, tales retrasos no son universales. Para
programas que realizan clculos numricos intensivos, los lenguajes funcionales tales
como OCaml y Clean son algo ms lentos que C. Para programas que manejan grandes
matrices y bases de datos multidimensionales, los vectores de los lenguajes funcionales,
como J y K, fueron diseados optimizando su velocidad.
La inalterabilidad de los datos puede llevar en muchos casos a ejecuciones eficientes
permitiendo al compilador hacer suposiciones que en un lenguaje imperativo resultaran
arriesgadas, aumentando las probabilidades para la expansin en lnea, que es una
optimizacin del compilador que sustituye en el lugar de la llamada a una funcin con el
cuerpo del destinatario de la llamada mejorando el uso del tiempo y espacio en tiempo de
ejecucin.
La evaluacin perezosa es una estrategia de evaluacin que retrasa el clculo de una
expresin hasta que su valor sea necesario, tambin puede mejorar la velocidad del
problema, incluso asintticamente, mientras que puede reducir la velocidad por un factor
constante, sin embargo puede producir prdidas de memoria si se usa de manera
incorrecta. Launchbury 1993 discute de manera terica los problemas relacionados con
las prdidas de memoria de evaluacin perezosa, y OSullivan et al. 2008 da algunos
consejos prcticos para el anlisis y la solucin de estos problemas. Sin embargo, las
implementaciones ms generales de evaluacin perezosa hace un uso extensivo de cdigo
sin referencia y los datos llevan a cabo un funcionamiento pobre en los procesadores
modernos con un alto grado de paralelismo y cachs multinivel, donde un fallo de
cach puede producir un coste de cientos de ciclos de reloj.
Lenguajes funcionales
Entre los lenguajes funcionales puros, cabe destacar a Haskell y Miranda. Los lenguajes
funcionales hbridos ms conocidos
son Scala, Lisp, Clojure, Scheme, Ocaml, SAP y Standard ML (estos dos ltimos,
descendientes del lenguajeML). Erlang es otro lenguaje funcional de programacin
concurrente. Mathematica permite la programacin en mltiples estilos, pero promueve la
programacin funcional. R tambin es un lenguaje funcional dedicado a la

estadstica.3Recientemente Microsoft Research est trabajando en el

lenguaje F# (Functional#).
Entre otros lenguajes que se podran utilizar para programacin funcional se podran
incluir a Perl, pues, aunque es un lenguaje de propsito muy general, se pueden realizar
programas usando exclusivamente funciones definidas por el usuario; as como Python,
como lenguaje que incorpora el paradigma funcional; o Ruby.
Estilos de codificacin
Mientras que los programas imperativos tienden a proporcionar los pasos a dar por un
programa, los funcionales tienden a enfatizar la composicin y disposicin de las
funciones, sin especificar pasos de manera explcita.
Uso en la industriaLa programacin funcional es ms popular en el mbito acadmico
que en mbitos industriales. Sin embargo se ha empezado a usar importantes lenguajes
de programacin funcionales en sistemas comerciales o industriales. Un ejemplo de
lenguaje de programacin usado en el mbito industrial es el Erlang, el cual fue
desarrollado para poner en prctica el sistema de tolerancia a fallos en las
telecomunicaciones. Importantes empresas como WhatsApp, Facebook, o T-Mobile
optaron por Erlang como lenguaje en alguno de sus desarrollos. Otro ejemplo de uso de
los lenguajes de programacin funcionales en la industria es el caso del uso
del Scheme de Lisp, que fue usado como base en el desarrollo de aplicaciones para los
primeros ordenadores de la firma Apple Macintosh. De hecho, hoy en da,est siendo
usado para desarrollo de sistemas de simulacin y de control de telescopio. Haskell, es un
ejemplo de lenguaje que cre con propsito de lenguaje de investigacin pero que se ha
usado para el desarrollo de sistemas aeroespaciales, programacin web y diseo
hardware. Otros lenguajes de programacin funcionales han sido usados en mbitos
comerciales y financieros.
Paradigma funcional.
Se basa en el concepto de funcin (que no es ms que una evolucin de los predicados),
de corte ms matemtico.
Caractersticas de la programacin funcional
Histricamente, los ordenadores se han programado utilizando lenguajes muy cercanos a
las peculiaridades de la propia mquina: operaciones aritmticas simples, instrucciones
de acceso a memoria, etc. Un programa escrito de esta manera puede ocultar totalmente
su propsito a la comprensin de un ser humano, incluso uno entrenado. Hoy da, estos
lenguajes pertenecientes al paradigma de la Programacin Imperativa han evolucionado
de manera que ya no son tan crpticos.

En el paradigma de la programacin funcional, un programa se considera una funcin

matemtica, la cual describe una relacin entre una entrada y una salida y donde el
concepto de estado o variable se elimina completamente. Sabemos que una funcin
matemtica es una regla que asocia a cada x de un conjunto X de valores, un nico y de
otro conjunto Y de valores; se representa por: f:X Y por y = f(x) Si ignoramos cmo un
programa computa sus datos y nos fijamos slo en qu computa, podemos ver al mismo
como una funcin matemtica que dada una entrada, devuelve una salida; se representa
por Programa : Input -> Output output = Programa(input). De aqu que la
implementacin de un lenguaje que permita crear programas con el enfoque de una
funcin matemtica, deba ser basado en el recurso funcin de los lenguajes de
programacin.. Ahora bien, entre la concepcin de una funcin matemtica y la de una
funcin en los lenguajes de programacin tradicionales, existan diferencias:

Lenguajes de programacin: Hay distincin entre la definicin de la funcin

(descripcin de lo que va a hacer la funcin mediante los parmetros formales) y la
aplicacin de la misma (llamada con los parmetros actuales). Las variables
refieren una zona de memoria donde se almacena un valor

Matemticas: La distincin no es clara, a menudo el trmino " variable

independiente " se usa tanto para el parmetro formal como actual.

Ejemplo: Si se tiene la expresin "Sea x tal que f(x) = 2 , no se distingue con claridad si
se refiere a la definicin de la funcin constante de valor 2 o al punto x especfico en el
que una funcin f ya definida toma el valor 2. Las variables siempre se refieren a un valor
y no a una localizacin de memoria. No hay concepto de localizacin de memoria y por
tanto la expr. x=x+1 no tiene sentido.
La programacin funcional debe por esto eliminar el concepto de variable excepto como
nombre de un valor. Por lo anterior, se concibi que en la Programacin Funcional la
asignacin no fuera permitida como instruccin.
En programacin funcional pura no existen variables, slo existen constantes, parmetros
y valores, an cuando en la prctica la mayora de los lenguajes de programacin
funcionales no son puros pues retienen algunas nociones de variables y asignaciones.
Como no hay variables ni asignacin, tampoco existen los ciclos al estilo de los de los
lenguajes tradicionales ya que los mismos trabajan con una variable de control que se va
reasignando (decrementando o incrementando). Esto se logra en un lenguaje funcional
mediante la recursin.

Si lo programamos funcionalmente en un lenguaje procedural como ADA, quedara como

sigue :
procedure MCD(u,v:integer):integer;

begin
if (v=0) then return u
else
return MCD(v,u mod v);
end; {MCD}
Consecuencias de ausencia de variables y asignacin
Otra consecuencia de la ausencia de variables y de asignacin es el hecho de que el valor
de cualquier funcin depende solamente de los valores de sus parmetros y no de
llamados previos a otras o a la misma funcin, as como que el valor de cualquier funcin
no depende del orden de evaluacin de sus parmetros, lo cual se conoce por el nombre
de transparencia referencial, lo que facilita el empleo de la programacin funcional se
utiliza en aplicaciones concurrentes. El hecho de que en los lenguajes funcionales no
existen las variables y existe la transparencia referencial, hacen la semntica de los
programas funcionales particularmente conveniente:

No existe estado, ya que no existe concepto de localizacin de memoria ni de

variable.

El ambiente de ejecucin asocia valores con nombres, no con localizaciones de

memoria; una vez que un nombre entra al ambiente, su valor no cambia. Es por
esto que se habla en este caso de semntica de valores, para distinguir este tipo de
semntica de la usual (semntica de almacenamiento o semntica de
apuntadores).

En la programacin funcional, debemos estar listos para manipular funciones sin

restricciones arbitrarias. En particular, las funciones deben ser vistas como
valores en s ellas, las cuales pueden ser ejecutadas por otras funciones y las
cuales pueden ser tambin parmetros de otras funciones, esto se expresa
diciendo que estas funciones son valores de primera clase.

Caractersticas
Las caractersticas ms generales de la programacin funcional se resumen en:

Ausencia de efectos colaterales

El valor de una expresin solo depende de los valores de sus subexpresiones, si las
tiene.

Se dice que una funcin (f x y z) tiene un efecto colateral si los valores de x, y, y/o z
cambian en el entorno de llamada durante la aplicacin de la funcin a sus argumentos,
o si alguna otra accin ocurre mientras se evala f.
Una funcin definida con todos los parmetros por valor y donde no se hacen
asignaciones a las variables globales, no tiene efectos colaterales.
La mayora de las implementaciones de LISP incorporan algunos efectos colaterales y
tipos de datos integrados. stos han sido incluidos para hacer ms sencillo un cdigo
fcilmente legible y las implementaciones eficientes.
Semntica limpia
Algunas de las caractersticas que hacen que un lenguaje sea til y confiable son en las
cuales el lenguaje significa lo que dice -no es ambiguo- y los resultados de un programa
pueden verificarse. En un lenguaje funcional f(3) siempre devolver el mismo resultado,
mientras que en un lenguaje imperativo, como Pascal, ste puede no ser el caso.

El manejo del almacenamiento de los datos es implcito, ciertas operaciones

asignan almacenamiento en el momento necesario y cuando se vuelve inaccesible
o no referenciado se libera automticamente, con uso de recoleccin de basuras,
cdigo de programa ms simple y corto.

Las funciones son valores de primera clase. Eso significa que las funciones tienen
la misma jerarqua que cualquier otro valor. Una funcin puede ser el valor de una
expresin, puede pasarse como argumento y puede colocarse en una estructura de
datos.

Cuestiones finales
El estilo de la programacin funcional puede ser usado y lo est siendo cada vez ms en
lenguajes imperativos (Ejemplo: PASCAL) por las mismas razones por las cuales el uso de
los lenguajes funcionales se ha incrementado: la simplicidad de la semntica y la
resultante claridad de los programas. El requerimiento bsico para programar
funcionalmente en cualquier lenguaje es que el mismo permita la recursin as como un
mecanismo de funciones general y adecuado.
Un problema tpico en este estilo de programacin es el costo de ejecucin de los ciclos
mediante la recursin. Incluso con los procesadores modernos, que reducen
sustancialmente la sobrecarga de la llamada a procedimiento, las implementaciones
recursivas son ms lentas que las que usan los ciclos standard.

Paradigma Dirigido por eventos

La programacin dirigida por eventos es un paradigma de programacin en el que el

flujo del programa est determinado por eventos o mensajes desde otros programas o
hilos de ejecucin.
Las aplicaciones desarrolladas con programacin dirigida por eventos implementan
un bucle principal o main loop donde se ejecutan las dos secciones principales de la
aplicacin: El selector de eventos y el manejador de eventos.
La mayora de libreras para el desarrollo de aplicaciones con GUI como GTK o Qt estn
diseados para ser dirigidos por eventos, de ah el famoso sistema de ranuras y seales
de Qt que no es ms que un patrn de diseo observer bastante currado.
Un poco de historia
A finales de los 70, los sistemas estaban pensados para trabajar como cadenas de
ensamblajedonde un programa usaba una entrada y produca una salida que sera
utilizada por otro programa como entrada para producir otra salida y as hasta finalizar el
proceso. Este proceso mental de construir software es la base del desarrollo
estructurado.
El padre del desarrollo estructurado (que no de la programacin estructurada ojo) fue
Larry LeRoy Constantine bajo el ala del Instituto de Investigacin de Sistemas de IBM.
Uno de los mayores expertos y defensores de los mtodos estructurados es Edward
Yourdon, tanto que las expresiones Yourdon y mtodos de anlisis y diseo
estructurado son sinnimos.
Constantine y Yourdon definieron nuevos modelos de control del flujo de datos
implementando lo que llamaron transacciones que en realidad son un patrn de diseo
de manejadores de eventos.

En el diagrama de la derecha se muestra el siguiente proceso:

Un flujo de datos invoca eventos o lo que Constantine y Yourdon llamaron

transacciones

Un disparador los enva a manejadores especializados, Constantine y Yourdon lo

llamaron centro de transacciones

un conjunto de manejadores que se encargan de realizar operaciones sobre el flujo

de datos

El trabajo del disparador es analizar los eventos para determinar su naturaleza y

entonces enviarlos al manejador adecuado que es capaz de trabajar con eventos de esa
naturaleza. El disparador tiene que procesar un flujo de eventos, as que su lgica debe
incluir un bucle de eventos para poder enviar un evento a un manejador y volver a
escuchar a la espera de nuevos eventos que disparar.
Es comn que exista un evento especial que rompa el bucle y salga de la aplicacin, a
ese evento se le llama evento finalizador y es muy comn en todas las libreras para
escribir aplicaciones GUI. Tambin puede ocurrir que el disparador capture un evento de
naturaleza desconocida o para el que no exista un manejador adecuado, en esos casos,
el disparador debe descartar el evento o lanzar una excepcin.
En algunas ocasiones es comn que el disparador y los manejadores no sean capaces de
procesar los eventos con la suficiente premura conforme van llegando por lo que la
mayora de aplicaciones basadas en GUI implementan una cola de eventos. Esta lgica
es muy delicada y si no se implementa bien puede ser producto de cuellos de
botella fatales.
Con la aparicin en los noventa de la programacin orientada a objetos nuevos diseos
vieron la luz como ESA (Essential Systems Analysis) y JSD (Jackson System Development)
que rompieron de forma brutal con la antigua manera de pensar en mtodos
estructurados.
Arquitectura cliente-servidor
La arquitectura cliente-servidor es claramente una implementacin del patrn de diseo
de manejadores de eventos. Podemos pensar en el servidor como un disparador de
eventos que espera a la escucha de una peticin de un cliente que enva un evento y
entonces el servidor lo re-enva a un manejador que lo procesa y devuelve un resultado.
El servidor implementa el bucle de eventos que escucha de forma continua y procesa las
peticiones reenvindolas a partes ms especialistas del servidor donde son procesadas y
devueltas al cliente como respuesta. Si el bucle de eventos recibe una peticin extraa,
sencillamente la descarta y emite un mensaje de error al cliente emisor.

Programacin GUI
La programacin grfica o programacin de GUI es dura, sobre todo si vienes del
desarrollo web. Para empezar, todo elemento que conforma la interfaz de usuario de la
aplicacin debe de serdefinido con detalle. Su posicin, tamao, color, aspecto,
comportamiento, etc, etc. Por eso existen los IDEs y los Frameworks, para hacernos la
vida ms sencilla a los desarrolladores.
En segundo lugar, la programacin con GUI es difcil por que existen muchos detalles y
conceptos que dependen completamente del manejo de eventos. Cualquier Widget en la
interfaz de usuario tiene uno o ms eventos asociados y a su vez emite uno o ms eventos
hacia el mundo exterior. El hardware de entrada como el ratn y el teclado, tambin
generan eventos y esos eventos tambin pueden ser capturados por los widgets de la
interfaz de usuario.
La mayora de herramientas de creacin de interfaces grficas de usuario se distribuyen
como frameworks. Los frameworks implementan el bucle de eventos y la cola de
eventos para que no tengamos que implementarlos nosotros mismos. Eso est bien, pero
el mecanismo queda encerradodentro del framework y si no estamos acostumbrados a la
programacin dirigida por eventos algunos conceptos pueden resultar
realmente confusos.
Y no solo esos bucles quedan ocultos dentro del funcionamiento del framework, sino que
tambin quedan ocultas mecnicas bsicas que es necesario comprender para llegar a
tener un entendimiento claro de la magia detrs de este paradigma. Un ejemplo claro es
el patrn observer.
El patrn Observer
La idea principal detrs del patrn observer es que existe una entidad con estados
cambiantes y una o ms entidades observndola. Los observadores esperan a que la
entidad observada les informe de un cambio de estado a travs de un evento que puede
ser de su inters, por lo que los observadores se registran con la entidad observada.
Cuando ocurre un evento, la entidad observada mira en su lista de observadores y
notifica a aquellos que se registraron para recibir eventos de ese tipo. Los
observadores dejaron instrucciones detalladas de como puede la entidad observada
ponerse en contacto con ellos para recibir los eventos. A este patrn tambin se le
llama El Principio de Hollywood como parodia de la tpica frase de Hollywood te
llamaremos en cuanto tengamos un papel para ti.
El sistema de ranuras y seales de Qt y el sistema de seales de GTK son ambos
implementaciones del patrn de diseo Observer.

Eventos y MVC
En el patrn de diseo MVC los eventos y el patrn de diseo observer conforman
el ncleo durodel funcionamiento interno del sistema. En en patrn de diseo MVC,
el Modelo es un objeto que gestiona los datos y el comportamiento de la aplicacin, es
la entidad observable en el patrn observer.
Las Vistas se registran con el Modelo como observadores del mismo. Cuando
el Controlador realiza cambios en el Modelo, notifica esos cambios a sus observadores
registrados que modifican la interfaz de la aplicacin.
En el patrn de diseo MVC los objetos de evento incluyen grandes cantidades de
datos que viajan de una parte a otra de la aplicacin a travs del viejo y rado patrn de
manejadores de eventos.
Programacin asncrona
La programacin asncrona pretende llevar este patrn de diseo a todos los aspectos del
desarrollo de software por medio de mecanismos que articulan de una u otra forma el uso
de eventos, seales y callbacks en todas las llamadas a funciones y mtodos llevados a
cabo por la aplicacin utilizando adems mltiples hilos de ejecucin normalmente en
una pila o piscina de hilosgestionada por un bucle de eventos extremadamente complejo.
Algunos lenguajes como .NET lo incorporan como parte del lenguaje de facto (versin 3.0
o superiores). Otros lenguajes disponen de libreras, herramientas o frameworks que
implementan la programacin asncrona. As tenemos Twisted para Python, EventMachine
para Ruby, Node.js para JavaScript, y muchas otras que seguramente desconozco para
muchos otros lenguajes.
En esta pequea introduccin a la programacin dirigida por eventos hemos hecho un
repaso por la historia de este paradigma de programacin que lleva con nosotros mucho
tiempo aunque para algunos es casi desconocido. En prximas entregas hablaremos
sobre las diferentes herramientas a nuestra disposicin a la hora de programar de forma
asncrona en escenarios donde se requiere de un tiempo de respuesta y rendimiento
superior a lo normal.

Programacin orientada a aspectos

La Programacin Orientada a Aspectos o POA (en ingls: aspect-oriented

programming) es un paradigma de programacin relativamente reciente cuya intencin
es permitir una adecuada modularizacin de las aplicaciones y posibilitar una mejor
separacin de incumbencias.
Gracias a la POA se pueden encapsular los diferentes conceptos que componen una
aplicacin en entidades bien definidas, eliminando las dependencias entre cada uno de
los mdulos. De esta forma se consigue razonar mejor sobre los conceptos, se elimina la
dispersin del cdigo y las implementaciones resultan ms comprensibles, adaptables y
reusables. Varias tecnologas con nombres diferentes se encaminan a la consecucin de
los mismos objetivos y as, el trmino POA es usado para referirse a varias tecnologas
relacionadas como los mtodos adaptativos, los filtros de composicin, la programacin
orientada a sujetos o la separacin multidimensional de competencias.
Objetivo
El principal objetivo de la POA es la separacin de las funcionalidades dentro del sistema:

Por un lado funcionalidades comunes utilizadas a lo largo de la aplicacin.

Por otro lado, las funcionalidades impropias de cada mdulo.

Cada funcionalidad comn se encapsular en una entidad.

Conceptos Bsicos
Debido a la escasa literatura en espaol sobre el tema, se presenta la terminologa
original en ingls.

Aspect (Aspecto) es una funcionalidad transversal (cross-cutting) que se va a

implementar de forma modular y separada del resto del sistema. El ejemplo ms
comn y simple de un aspecto es el logging (registro de sucesos) dentro del
sistema, ya que necesariamente afecta a todas las partes del sistema que generan
un suceso.

Join point (Punto de Cruce o de Unin) es un punto de ejecucin dentro del

sistema donde un aspecto puede ser conectado, como una llamada a un mtodo,
el lanzamiento de una excepcin o la modificacin de un campo. El cdigo del
aspecto ser insertado en el flujo de ejecucin de la aplicacin para aadir su
funcionalidad.

Advice (Consejo) es la implementacin del aspecto, es decir, contiene el cdigo que

implementa la nueva funcionalidad. Se insertan en la aplicacin en los Puntos de
Cruce.

Pointcut (Puntos de Corte) define los Consejos que se aplicarn a cada Punto de
Cruce. Se especifica mediante Expresiones Regulares o mediante patrones de
nombres (de clases, mtodos o campos), e incluso dinmicamente en tiempo de
ejecucin segn el valor de ciertos parmetros.

Introduction (Introduccin) permite aadir mtodos o atributos a clases ya

existentes. Un ejemplo en el que resultara til es la creacin de un Consejo de
Auditora que mantenga la fecha de la ltima modificacin de un objeto, mediante
una variable y un mtodo setUltimaModificacion(fecha), que podran ser
introducidos en todas las clases (o slo en algunas) para proporcionarles esta
nueva funcionalidad.

Target (Destinatario) es la clase aconsejada, la clase que es objeto de un consejo.

Sin AOP, esta clase debera contener su lgica, adems de la lgica del aspecto.

Proxy (Resultante) es el objeto creado despus de aplicar el Consejo al Objeto

Destinatario. El resto de la aplicacin nicamente tendr que soportar al Objeto
Destinatario (pre-AOP) y no al Objeto Resultante (post-AOP).

Weaving (Tejido) es el proceso de aplicar Aspectos a los Objetos Destinatarios para

crear los nuevos Objetos Resultantes en los especificados Puntos de Cruce. Este
proceso puede ocurrir a lo largo del ciclo de vida del Objeto Destinatario:

Aspectos en Tiempo de Compilacin, que necesita un compilador especial.

Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el

Objeto Destinatario es cargado. Requiere un ClassLoader especial.

Aspectos en Tiempo de Ejecucin.

Problemas de otros paradigmas

Muchas veces nos encontramos, a la hora de programar, con problemas que no podemos
resolver de una manera adecuada con las tcnicas habituales usadas en la programacin
imperativa o en la programacin orientada a objetos. Con stas, nos vemos forzados a
tomar decisiones de diseo que repercuten de manera importante en el desarrollo de la
aplicacin y que nos alejan con frecuencia de otras posibilidades.
A menudo, hace falta escribir lneas de cdigo que estn distribuidas por toda o gran
parte de la aplicacin, para definir la lgica de cierta propiedad o comportamiento del
sistema, con las consecuentes dificultades de mantenimiento y desarrollo. En ingls este
problema se conoce como scattered code, que podramos traducir como cdigo disperso.
Otro problema que puede aparecer, es que un mismo mdulo implemente mltiples
comportamientos o aspectos del sistema de forma simultnea. En ingls este problema se
conoce como tangled code, que podramos traducir como cdigo enmaraado. El hecho es

que hay ciertas decisiones de diseo que son difciles de capturar, debido a que
determinados problemas no se pueden encapsular claramente de igual forma que los que
habitualmente se resuelven con funciones u objetos.
Desarrollo en POA
AspectC++] es un compilador que permite desarrollar aspectos en C++.
AspectJ es una extensin Java del proyecto Eclipse para ayudar en el desarrollo orientado
a aspectos.
Aspect, un mdulo Perl disponible en CPAN para la Programacin Orientada a Aspectos
(en ingls).
PHP-AOP (AOP.io) es una lib que proporciona todo el paradigma de la POA en PHP.
phpAspect es una extensin PHP para implementar el paradigma de la POA, que,
mediante rboles de decisin XML, realiza el weaving del software para ser ejecutado
como PHP estndar.
FLOW3 es un framework MVC de PHP incluye un mdulo para poder realizar
Programacin orientada a Aspectos en nuevos desarrollos.
AOP con SpringFramework 2.5 es un Framework de Java que permite programar en el
paradigma de Aspectos utilizando Anotacin Java
Aspyct AOP es un mdulo de Python que permite incluir Programacin orientada a
Aspectos a programas ya existentes escritos en Python o a nuevos desarrollos.

Paradigma orientado a objetos

Introduccin
Actualmente una de las reas ms candentes en la industria y en el mbito acadmico es
la orientacin a objetos. La orientacin a objetos promete mejoras de amplio alcance en la
forma de diseo, desarrollo y mantenimiento del software ofreciendo una solucin a largo
plazo a los problemas y preocupaciones que han existido desde el comienzo en el
desarrollo de software: la falta de portabilidad del cdigo y reusabilidad, cdigo que es
dificil de modificar, ciclos de desarrollo largos y tecnicas de codificacion no intuituvas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres caractersticas basicas:
debe estar basado en objetos, basado en clases y capaz de tener herencia de clases.
Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres.
La barrera ms difcil de sortear es usualmente la herencia.

El concepto de programacin orientada a objetos (OOP) no es nuevo, lenguajes clsicos

como SmallTalk se basan en ella. Dado que la OOP. se basa en la idea natural de la
existencia de un mundo lleno de objetos y que la resolucin del problema se realiza en
trminos de objetos, un lenguaje se dice que est basado en objetos si soporta objetos
como una caracterstica fundamental del mismo.
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos
definir un objeto como un conjunto complejo de datos y programas que
poseen estructura y forman parte de una organizacin.
Esta definicin especifica varias propiedades importantes de los objetos. En primer lugar,
un objeto no es un dato simple, sino que contiene en su interior cierto nmero de
componentes bin estructurados. En segundo lugar, cada objeto no es un ente aislado,
sino que forma parte de una organizacin jerrquica o de otro tipo.
ESTRUCTURA DE UN OBJETO
Un objeto puede considerarse como una especie de cpsula dividida en tres partes:
1 - RELACIONES
2 - PROPIEDADES
3 - METODOS
Cada uno de estos componentes desempea un papel totalmente independiente:
Las relaciones permiten que el objeto se insterte en la organizacin y estn formadas
esencialmente por punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte de
la misma organizacin y tiene valores que dependen de la propiedad de que se trate. Las
propiedades de un objeto pueden ser heredadas a sus descendientes en la organizacin.
Los mtodos son las operaciones que pueden realizarse sobre el objeto, que normalmente
estarn incorporados en forma de programas (cdigo) que el objeto es capaz de ejecutar y
que tambin pone a disposicin de sus descendientes a travs de la herencia.
Encapsulamiento y ocultacin
Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y
programas, todos ellos relacionados entre s, como si estuvieran encerrados
conjuntamente en una cpsula. Esta propiedad (encapsulamiento), es una de las
caractersticas fundamentales en la OOP.

Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los
programadores conozcan cmo est distribuda la informacin o qu informacin hay
disponible. Esta propiedad de los objetos se denomina ocultacin de la informacin.
Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un
objeto y a lo que contiene. Si as fuera no se podra hacer gran cosa con l. Lo que sucede
es que las peticiones de informacin a un objeto. deben realizarse a travs
de mensajes dirigidos a l, con la orden de realizar la operacin pertinente. La respuesta
a estas ordenes ser la informacin requerida, siempre que el objeto considere que quien
enva el mensaje est autorizado para obtenerla.
El hecho de que cada objeto sea una cpsula facilita enormemente que un objeto
determinado pueda ser transportado a otro punto de la organizacin, o incluso a otra
organizacin totalmente diferente que precise de l. Si el objeto ha sido bien construdo,
sus mtodos seguirn funcionando en el nuevo entorno sin problemas. Esta cualidad
hace que la OOP sea muy apta para la reutilizacin de programas.
Organizacin de los objetos
En principio, los objetos forman siempre una organizacin jerrquica, en el sentido de que
ciertos objetos son superiores a otros de cierto modo.
Existen varios tipos tipos de jerarquas: sern simples cuando su estructura pueda ser
representada por medio de un "arbol". En otros casos puede ser ms compleja.
En cualquier caso, sea la estructura simple o compleja, podrn distinguirse en ella tres
niveles de objetos.
-La raz de la jerarqua. Se trata de un objeto nico y especial. Este se caracterza por
estar en el nivel ms alto de la estructura y suele recibir un nombre muy genrico, que
indica su categora especial, como por ejemplo objeto madre, Raz o Entidad.
-Los objetos intermedios. Son aquellos que descienden directamente de la raz y que a su
vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy
generales o muy especializados, segn la aplicacin. Normalmente reciben nombres
genricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA,
CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de
otra clase o subclase.
-Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no
tienen descendientes. Suelen llamarse casos particulares, instancias o tems porque
representan los elementos del conjunto representado por la clase o subclase a la que
pertenecen.
Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".

1. RELACIONES
Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto
relacionarse con aquellos que forman parte de la misma organizacin.
Las hay de dos tipos fundamentales:
-Relaciones jerrquicas. Son esenciales para la existencia misma de la aplicacin porque la
construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer
objeto se encuentra situado inmediatamente encima del segundo en la organizacin en la
que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del
primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos de B; en la fig. 3,
los objetos B y C son padres de F, que a su vez es hijo de ambos).
Una organizacin jerrquica simple puede definirse como aquella en la que un objeto
puede tener un solo padre, mientras que en una organizacion jerrquica compleja un hijo
puede tener varios padres).
-Relaciones semnticas. Se refieren a las relaciones que no tienen nada que ver con la
organizacin de la que forman parte los objetos que las establecen. Sus propiedades y
consecuencia solo dependen de los objetos en s mismos (de su significado) y no de su
posicin en la organizacin.
Se puede ver mejor con un ejemplo: supongamos que vamos a construir
un diccionario informatizado que permita al usuario obtener la definicin de una palabra
cualquiera. Supongamos que, en dicho diccionario, las palabras son objetos y que la
organizacin jerrquica es la que proviene de forma natural de la estructura de nuestros
conocimientos sobre el mundo.
La raz del diccionario podra llamarse TEMAS. De ste trmino genrico descendern tres
grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida)
comprender las ciencias biolgicas: Biologa y Medicina. El segundo (mundo), las
ciencias de la naturaleza inerte: las Matemticas, la Fsica, la Qumica y la Geologa. El
tercero (hombre) comprender las ciencias humanas: la Geografa, la Historia, etc.
Veamos un ejemplo: estableceremos la relacin trabajo entre los objetos NEWTON y
OPTICA y la interpretaremos diciendo que significa que Newton trabaj en ptica (vase la
fig. 4). La relacin es, evidentemente, semntica, pus no establece ninguna connotacin
jerrquica entre NEWTON y OPTICA y su interpretacin depende exclusivamente
del significado de ambos objetos.
La existencia de esta relacin nos permitir responder a preguntas como:
Quin trabaj en ptica?

En qu trabaj Newton?
Quien trabaj en Fsica?
Las dos primeras se deducen inmediatamente de la existencia de la relacin trabajo. Para
la tercera observamos que si Newton trabaj en ptica automticamente sabemos que
trabaj en Fsica, por ser ptica una rama de la Fsica (en nuestro diccionario, el objeto
OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la
tercera pregunta sin necesidad de establecer una relacin entre NEWTON y FISICA,
apoyandonos slo en la relacin definida entre NEWTON y OPTICA y en que OPTICA es
hijo de FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de
informacin que tendremos que definir para todo el diccionario ser mnima.
2. PROPIEDADES
Todo objeto puede tener cierto nmero de propiedades, cada una de las cuales tendr, a
su vez, uno o varios valores. En OOP, las propiedades corresponden a las clsicas
"variables" de la programacin estructurada. Son, por lo tanto, datos encapsulados dentro
del objeto, junto con los mtodos (programas) y las relaciones (punteros a otros objetos).
Las propiedades de un objeto pueden tener un valor nico o pueden contener un conjunto
de valores mas o menos estructurados (matrices, vectores, listas, etc.). Adems, los
valores pueden ser de cualquier tipo (numrico, alfabtico, etc.) si el sistema de
programacin lo permite.
Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar
de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de
maneras diferentes:
-Propiedades propias. Estn formadas dentro de la cpsula del objeto.
-Propiedades heredadas. Estan definidas en un objeto diferente, antepasado de ste
(padre,"abuelo", etc.). A veces estas propiedades se llaman propiedades miembro porque
el objeto las posee por el mero hecho de ser miembro de una clase.
3. METODOS
Una operacin que realiza acceso a los datos. Podemos definir mtodo como
un programa procedimental o procedural escrito en cualquier lenguaje, que est asociado
a un objeto determinado y cuya ejecucin slo puede desencadenarse a travs de un
mensaje recibido por ste o por sus descendientes.
Son sinnimos de 'mtodo' todos aquellos trminos que se han aplicado tradicionalmente
a los programas, como procedimiento, funcin, rutina, etc. Sin embargo, es conveniente
utilizar el trmino 'mtodo' para que se distingan claramente las propiedades especiales
que adquiere un programa en el entorno OOP, que afectan fundamentalmente a la forma

de invocarlo (nicamente a travs de un mensaje) y a su campo de accin, limitado a un

objeto y a sus descendientes, aunque posiblemente no a todos.
Si los mtodos son programas, se deduce que podran tener argumentos, o parmetros.
Puesto que los mtodos pueden heredarse de unos objetos a otros, un objeto puede
disponer de un mtodo de dos maneras diferentes:
-Mtodos propios. Estn includos dentro de la cpsula del objeto.
-Mtodos heredados. Estan definidos en un objeto diferente, antepasado de ste
(padre,"abuelo", etc.). A veces estos mtodos se llaman mtodos miembro porque el
objeto los posee por el mero hecho de ser miembro de una clase.
Polimorfsmo
Una de las caractersticas fundamentales de la OOP es el polimorfsmo, que no es otra
cosa que la posibilidad de construir varios mtodos con el mismo nombre, pero con
relacin a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto
conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos
objetos recibiran el mismo mensaje global pero responderan a l de formas diferentes;
por ejemplo, un mensaje "+" a un objeto ENTERO significara suma, mientras que para un
objeto STRING significara concatenacin ("pegar" strings uno seguido al otro)
Demonios
Es un tipo especial de mtodos, relativamente poco frecuente en los sistemas de OOP, que
se activa automticamente cuando sucede algo especial. Es decir, es un programa, como
los mtodos ordinarios, pero se diferencia de estos porque su ejecucin no se activa con
un mensaje, sino que se desencadena autmticamente cuando ocurre un suceso
determinado: la asignacin de un valor a una propiedad de un objeto, la lectura de un
valor determinado, etc.
Los demonios, cuando existen, se diferencian de otros mtodos por que no son heredables
y porque a veces estn ligados a una de las propiedades de un objeto, mas que al objeto
entero.
CONSIDERACIONES FINALES
Beneficios que se obtienen del desarrollo con OOP
Da a da los costos del Hardware decrecen. As surgen nuevas reas de aplicacin
cotidianamente: procesamiento de imgenes y sonido, bases de
datos multimediales, automatizacin de oficinas, ambientes de ingeniera de software, etc.
An en las aplicaciones tradicionales encontramos que definir interfases hombre-mquina
"a-la-Windows" suele ser bastante conveniente.

Lamentablemente, los costos de produccin de software siguen aumentando; el

mantenimiento y la modificacin de sistemas complejos suele ser una tarea trabajosa;
cada aplicacin, (aunque tenga aspectos similares a otra) suele encararse como
un proyecto nuevo, etc.
Todos estos problemas an no han sido solucionados en forma completa. Pero como los
objetos son portables (tericamente) mientras que la herencia permite la reusabilidad del
cdigo orientado a objetos, es ms sencillo modificar cdigo existente porque los objetos
no interaccionan excepto a travs de mensajes; en consecuencia un cambio en
la codificacin de un objeto no afectar la operacin con otro objeto siempre que los
mtodos respectivos permanezcan intactos. La introduccin de tecnologa de objetos como
una herramienta concepual para analizar, disear e implementar aplicaciones permite
obtener aplicaciones ms modificables, fcilmente extendibles y a partir de componentes
reusables. Esta reusabilidad del cdigo disminuye el tiempo que se utiliza en el desarrollo
y hace que el desarrollo del software sea mas intuitivo porque la gente piensa
naturalmente en trminos de objetos ms que en trminos de algoritmos de software.
Problemas derivados de la utilizacin de OOP en la actualidad
Un sistema orientado a objetos, por lo visto, puede parecer un paraso virtual. El
problema sin embargo surge en la implementacin de tal sistema. Muchas compaas oyen
acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad
de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es
ajena a los programadores actuales. Especficamente los siguientes temas suelen aparecer
repetidamente:
Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma
nica. Involucra la conceptualizacin de todos los elementos de un programa, desde
subsistemas a los datos, en la forma de objetos. Toda la comunicacin entre los objetos
debe realizarse en la forma de mensajes. Esta no es la forma en que estn escritos los
programas orientados a objetos actualmente; al hacer la transicin a un sistema
orientado a objetos la mayora de los programadores deben capacitarse nuevamente antes
de poder usarlo.
Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un
sistema orientado a objetos, en la prctica existen muchas dependencias. Muchos
lenguajes orientados a objetos estn compitiendo actualmente para dominar el mercado.
Cambiar el lenguaje de implementacin de un sistema orientado a objetos no es una tarea
sencilla; por ejemplo C++ soporta el concepto de herencia multiple mientras que
SmallTalk no lo soporta; en consecuencia la eleccin de un lenguaje tiene ramificaciones
de diseo muy importamtes.
Determinacion de las clases. Una clase es un molde que se utiliza para crear nuevos
objetos. En consecuencia es importante crear el conjunto de clases adecuado para un

proyecto. Desafortunadamente la definicin de las clases es ms un arte que una ciencia.

Si bien hay muchas jerarquas de clase predefinidas usualmente se deben crear clases
especficas para la aplicacin que se este desarrollando. Luego, en 6 meses 1 ao se da
cuenta que las clases que se establecieron no son posibles; en ese caso ser necesario
reestructurar la jerarqua de clases devastando totalmente la planificacin original.
Performance. En un sistema donde todo es un objeto y toda interaccion es a travs de
mensajes, el trfico de mensajes afecta la performance. A medida que la tecnologa avanza
y la velocidad de microprocesamiento, potencia y tamao de la memoria aumentan, la
situacion mejorar; pero en la situacin actual, un diseo de una aplicacin orientada a
objetos que no tiene en cuenta la performance no ser viable comercialmente.
Idealmente, habra una forma de atacar estos problemas eficientemente al mismo tiempo
que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos.
Deberia existir una metodologa fcil de aprender e independiente del lenguaje, y facil de
reestructurar que no drene la performance del sistema .