Bueno, pues tras la breve presentación que hice el otro día (bueno sí, hace 2 meses, perdón por el retraso), aquí vamos a empezar con mis divagaciones sobre el primer asunto que nos concierne: Programación Procedural Clásica vs Programación Orientada a Objetos, o mejor: PP vs POO (y lo voy a abreviar así siempre, que es un poco peñazo escribir todo el texto cada vez).
Os pongo en antecedentes para que os podáis situar bajo mi punto de vista:
Aprendí a programar yo solo con mi primer ordenador, unToshiba MSX-HX10 como el de la imagen de al lado, con sistema operativo BASIC. Esto debió ser a los 10 años, que fue cuando me lo pude comprar con los ahorros (los míos y los de mi hermana, le dije que así podíamos jugar también y coló, que tampoco fue mentira porque jugamos un montón).
En aquel momento triunfaban los concursos de preguntas y respuestas en la tele, así que decidí hacer uno en el ordenador. En total eran 25 preguntas y una chapuza de INPUTS e IF anidados… que funcionaba.
Desde entonces hasta ahora, la PP siempre me ha acompañado fielmente. En la carrera, la POO todavía era algo “novedoso” y sin mucha implantación aún, así que nos enseñaron PP y toda la teoría y las prácticas eran así: Pascal, C, Cobol y todos los lenguajes anecdóticos de la época (como Fortran o la Lista Interminable de Soporíferos Paréntesis, más conocida como LISP[1] ).
Ni siquiera nos enseñaron Visual Basic, que ya por entonces era el lenguaje más popular de todos, al que más cariño le tengo (los puristas me crucificarán por esto, pero qué se le va a hacer) y con el que me he sacado las castañas del fuego durante 15 años ya, aunque ahora apenas lo toque (sniff).
Mi primer contacto real (la teoría es muy bonita, pero si no la llevas a la práctica…) con la POO fue con Java en el año 2004, cuando por temas de mi trabajo precisaba una aplicación de consola que corriese en Linux o Windows y atacase a una base de datos Informix por un lado y Oracle por otro. Ahí fue cuando descubrí lo complejo que es cambiar de mentalidad para pasar de PP a POO (y viceversa). Y ahora sí, podemos entrar en temática.
La Programación Procedural (PP)
Antes de nada, debo aclarar que a veces se puede uno referir también a la programación funcional y meterlo todo en el mismo saco, pero éste no es el término exacto de lo que voy a definir, ya que la programación estrictamente funcional está basada únicamente en funciones (no procedimientos). Según la Wikipedia, “La programación funcional es un paradigma de programación declarativa basado en la utilización de funciones matemáticas“.
Con esta definición, lenguajes como Visual Basic o C no entrarían ahí. Por eso aclaro que a veces se habla de la Programación Funcional queriendo incluir la Programación Procedural (PP) o, también llamada Programación Estructurada. Por ello, para resumir y no decir tantas palabras feas, cuando hable de PP en general me quiero referir tanto a PF como a PP, ya que al final todo son funciones o procedimientos colocados de una forma estructurada y coherente que dan vida a un programa.
Dicho esto, ¿qué es la PP (o, recordemos, estructurada)? Bueno, veamos la definición de la wikipedia: “La programación estructurada es una forma de escribir programas de ordenador de manera clara.” Y tan clara, añado yo… siempre que el programador tenga claro el concepto. He llegado a ver auténticos churros de código, sin sentido aparente, de recién licenciados en la carrera (lo cuál no decía nada bueno de ellos, porque una cosa es la inexperiencia y otra “el churro”).
Bien, básicamente lo único que se necesita para usar esta técnica es un poco de sentido común, ni más ni menos. Reglas tan sencillas como “si alguna operación puede ser repetida más de una vez, crea una función que la realice“. De esta forma sólo tendrás que corregir el código en un único sitio cuando falle (que fallará, casi seguro, al menos una vez). Si se tiene esto en cuenta, la PP es tan sencilla como (teniendo ya en mente el programa y, al menos, definidas sus partes básicas):
- Definir las constantes y variables que necesitarás a priori, ya sean globales (sí, sí, las variables globales son válidas si se emplea el sentido común) o locales.
- Definir las funciones y procedimientos que se necesitan.
- Indicar el flujo del programa desde el inicio hasta el final.
No parece complicado, ¿verdad? En realidad no lo es, de ahí mi favoritismo por esta metodología de trabajo. Básicamente sería algo como esto:
Bloque de variables y constantes
Bloque de procedimientos y funciones: Procedimiento 1(); Procedimiento 2(); Función 1();
Función principal donde se controla el flujo del programa: Inicio del programa; Mis cálculos; Llamo a Procedimiento 1(); Llamo a Función 1(); Llamo a Procedimiento 1(); Más cálculos; Fin del programa¿Ventajas de esta metodología?:
- Lo primero que salta a la vista: sencillez y claridad. Cualquiera entiende esta forma de trabajo fácilmente, se adapta pronto y, también, se adopta pronto.
- Es fácil seguir un programa, sólo hay que seguir el “hilo”.
- Alguien que no haya escrito el programa puede coger el código y entenderlo con cierta facilidad (esos comentarios que tan poca gente pone de forma adecuada… ¡¡ay!! ).
- Modificarlo es sencillo y rápido.
- ¿He dicho ya sencillez y claridad?
¿Problemas principales de esta metodología?:
- No está muy indicada para trabajar en grupo, dado que tú te lo comes y tú te lo guisas hasta el final. Si te organizas muy bien sí puedes trabajar en grupo (por ejemplo se desarrollan cada uno de los procedimientos por separado y luego uno los junta todos en el código final y se prueba), pero se complica mucho el asunto por las variables globales y locales, ya que no sabes qué va a hacer el otro con ellas.
- Si el programador no es metódico y responsable en su trabajo puede liarla, y bien, con las variables globales y locales, dada su libertad de uso.
- Si el programa es muy grande, te pueden salir auténticos chorizos de código, pero esto es algo que siempre puedes arreglar si eres una persona ordenada y divides el código en partes que incluyes en procedimientos. Veamos un ejemplo de este último punto:
Esto sería el código “spaguetti”, que se suele llamar (indeseable):
Procedimiento 1()( Mucho código por aquí... Sigue mi código porque tiene muchos cálculos... Más código... Y más código... ... (y muchas líneas después...) Más código... Fin del Procedimiento )Y esto el código corregido, que sería el deseable:
Procedimiento 1()( Mucho código por aquí... Sigue mi código porque tiene muchos cálculos... Llamar a SubProcedimiento 1_1(); (esto contendrá parte de los cálculos) Llamar a SubProcedimiento 1_2(); (esto contendrá otra parte de los cálculos) Fin del Procedimiento )Bien, aunque aquí no se aprecie por haber puesto “y muchas líneas después“, lo cierto es que cuando ves que eso equivale a varias páginas de texto te das cuenta de que es casi ilegible y te llega a marear. Así y todo, aún siendo malo, el código es “seguible“, cosa que con la POO se complica bastante más.
Tan buena es la PP que cualquiera puede hacer un programa con escasos conocimientos del lenguaje que elija, lo cual ha dado lugar a auténticas chapuzas, por supuesto, que, aún así, visualmente hacían lo que debían. Y es que no siempre “el fin justifica los medios“. Es fácil hacer algo chapucero que ofrezca el resultado esperado, pero que mañana, cuando haya que modificarlo, no haya por donde cogerlo.
La libertad que ofrece este modelo es, a su vez, su mayor peligro. Los que hayan vivido en el mundo empresarial desde el año 1990 hasta prácticamente el 2005 habrán podido experimentar en vivo el boom de universitarios “informáticos” que eran la “leche“, pero que no aplicaban precisamente las mejores técnicas de programación. Me incluyo yo ahí. El primer año que trabajé como programador de Visual Basic fue el de mi aprendizaje, con el viejo sistema de prueba/error: hacía un programa y aprendía Visual Basic a la vez. Todo iba, en realidad, pero al año siguiente, al tener que coger y aumentar funcionalidades al programa, aparecían los problemas: mal diseño, mala codificación, y nula documentación. “Nunca máis” me dije, y empecé a aplicar buenas prácticas y a diseñar un manual para la empresa de “diseño de aplicaciones en La EMPRESA” que el resto de programadores debían seguir (yo fui el primero de la empresa y luego llegaron 4 más). Hoy soy un hombre feliz, y cuando veo el código de aquellos programas, aún sé qué hacen y como modificarlos 
.
Con la introducción masiva de Java (POO) en nuestras vidas de programador, se ha perdido este encanto. Si bien C++ ya existe desde hace muchos años, la auténtica revolución del nuevo ejército de programadores POO llegó con Java. Antes, la guerra era tal que así:
- Hola buenos días.
- Hola qué tal.
- ¿Tú en qué programas?
- Yo en Visual Basic.
- Bah, eres un programador junior con poca idea, VB es de “mariquitas” que no saben usar POO. Lo auténtico es el C++, eso si que es para machotes, con sus punteros a Null y sus miles de líneas de código eficiente…
- Ya bueno, yo es que tengo que hacer un programa de gestión para dentro de un mes y con C++ tardo 3 meses…
- Bueno, pero sería altamente eficiente ¡y con código reusable!
- Sí, bueno, pero si le doy de plazo 3 meses al cliente (con un coste 3 veces superior) me dice que lo haga Rita.
- No tenéis ni idea de manejar clientes…
Ahora… la cosa es tan diferente… que si .NET, que si Java, que si C++… pero ninguno de estos emplea los métodos tradicionales, son todos (básicamente) POO: ¡¡ nos están aniquilando !! Ya no hay guerra, con lo divertida que era. Bueno, que ya empiezo a desviar el tema.
En la próxima entrada analizaré brevemente la POO y os ofreceré mi punto de vista final (que ya vais viendo por dónde va). La verdad es que el tema es muy amplio, pero sólo trato de dar una ligera aproximación, porque si no, nos da para un libro en vez de una página. Espero vuestras opiniones. 
- Lots of Insipid and Stupid Parenthesis, que decían los angloparlantes [↩]
The Informática: esos locos, con sus locos cacharros – Programación procedural clásica (PP) vs Programación orientada a objectos (POO) (1 de 2) by Manuel Conde Vendrell, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.
{ 29 } Comentarios
Bienvenido, Eagle, y enhorabuena!! Muy buen artículo.
Y estoy francamente de acuerdo con tus apreciaciones sobre la forma de programar las aplicaciones en estos últimos tiempos… me llamarán dinosaurio, pero me gustaba más lo de antes.
Un ejemplo palpable: El programa PADRE (con el que los españolitos nos hacemos la Declaración de la Renta). Tenía un formato determinado y conocido por todo hijo de vecino, razonablemente bien hecho y con una interfaz adecuada, que llevaba funcionando al menos doce o quince años, y que comenzó distribuyéndose en diskette…
Este año 2010, alguien ha decidido que era de una tecnología anticuada, y había que modernizarlo, “objetizarlo”. El resultado:
Más bonito, más dibujitos y más iconos (supérfluos). Más a la moda, vaya, con muchos colorines y eso.
Un interfaz criminal. Por ejemplo, antes, cuando tenías unos ingresos de intereses “comunes”, por ser atribuidos a ambos miembros de la familia por igual, decías “COMUN”, metías la cantidad y el programa lo repartía. Si era atribuido sólo a uno de los dos, lo decías y yastá… Ahora tienes que meter DOS veces el mismo dato, la mitad de lo que realmente has cobrado, una vez diciendo que es tuyo, y otra vez, lo mismo, pero de tu cónyuge. Y así con todo. ¿Quién demonios habrá diseñado esta barbaridad¿ Es el Anti-interfaz… Pues ahí está. Para “tu comodidad”. como esos teléfonos 902 que proliferan y proliferan…
Es lentísimo. Para cambiar de página, que antes era inmediato, ahora tarda sus buenos treinta segundos. Será Java del bueno, pero… vaya castaña!!!
La distribución ocupa el doble. El año pasado, 12 Megas. Este año, 23. Y… ¿pa qué?
Ya ves, todo mejoras…. y lo que más me duele es la fortuna que habrá pagado la Agencia Tributaria a alguien por tener que reescribir algo que funcionaba perfectamente para dejarlo así de mal… ¡y eso que este año apenas ha habido cambios en la legislación!
Bueno, ya paro, que cuando me tocan la programática fibra sensible….
Enhorabuena otra vez, y un Saludo.
Macluskey
La verdad, se te nota que no te gusta nada de nada la POO. Yo, sin embargo, en cuanto la entendí, me enamoré, aunque no en el sentido de “todo, todo, absolutamente todo tiene que ser un objeto, cueste lo que cueste”, sino en plan “es una herramienta más que, en determinados casos es muy útil porque simplifica el código final”.
No creo que se deba plantear una guerra PP/POO, sino que debe escogerse cual se adapta mejor a cada problema, sin miedo a mezclar ambas si se considera necesario.
Muy buen artículo, realmente esto de la PP es algo que siempre se me hizo mas sencillo de utilizar y con la que se lograban buenas cosas. La POO por otra parte a significando un reto a poder dominar, a cambiado todo lo que conocí durante mis estudios universitarios.
Un Saludo y en espera del siguiente de la serie.
Buen artículo. Te lo dice otro que aprendió a programar con un MSX.
Me parece curioso como disfrutas con la programación estructurada y hay cosas que me inquietan un poco. Parece que simplificas muchos la programación estructurada al concepto de la creación de funciones que realicen las funciones repetitivas y el flujo principal del programa y las variables globales y constantes.
No se si realmente cuando desarrollas una aplicación con programación estructurada sigues usando ese método. Pero yo, como ya aprendí mucho en el mundo de la orientación a objetos prácticamente desde el principio (poco estuve con la programación estructurada), tengo una manera de trabajar con programación estructurada algo diferente aparentemente.
En general yo lo que hago es trabajar con TADs, pero uno puedo llegar a pensar que los TADs están bien, para eso, para lo que son, TADs (listas, árboles, etc…). Yo además en ese lote meto todo lo que podría ser en orientación a objetos una clase. Me refiero a que en C tiendo a definir módulos que encapsulan una estructura de datos y una serie de funciones que piden como primer argumento un puntero a esa estructura de datos y luego los argumentos que necesite. Para ello además incluyo la funcion createEntidad y destroyEntidad donde se reserva memoria y se devuelve el puntero (equivalente a hacer un new Entidad()) y el destroy liberaría la memoria de ese puntero. Para los métodos estáticos simplemente las funciones simplemente no exigen el puntero a la estructura.
Igual puedes pensar que estoy tratando de usar los TADs para emular orientación a objetos y te admito que si, porque además a base de punteros a funciones, también me permito el lujo de crear TADs que tienen la implementación de los métodos vacía y así poder hacer una especie de herencia (como si fuese una mezcla entre la herencia por extensión y la herencia por composición).
Hola Eagle. A costa de ponerme pesado (ya comente algo en el primer post), creo que sigues confundiendo programación funcional con programación estructurada y eso puede generar confusión a los lectores.
Los lenguajes de programación pueden dividirse en dos grandes familias, los lenguajes imperativos (A) (llamados asi porque instruyen con ordenes directas al computador cada uno de los pasos a dar de manera muy directa y normalmente secuencial) y los lenguajes declarativos (B) (donde por contra se “declara”, se describe el problema en lugar de dar los pasos para su resolución, que suelen quedar a merced de un motor de reglas, de ejecución o de resolución).
Desde luego, hay más clasificaciones posibles: http://en.wikipedia.org/wiki/List_of_programming_languages_by_category
Como bien dices, Basic permite usar funciones y procedimientos. Pero esas funciones (entendidas como rutinas que retornan valores) son “otra cosa” muy diferente a lo que la programación funcional llama también “funciones” (y no porque prescinda de procedimientos como comentas). El termino aquí está sobrecargado. ¡OJO, las funciones en cada ámbito son definiciones realmente diferentes!
Un detalle adicional: cuando hablas de código espagueti es bueno recordar también que se llama así por el abuso de GOTO que conllevaba. Cuando tratas de dibujar el control del programa y los saltos que pegas, acabas dibujando algo realmente enmarañado. http://en.wikipedia.org/wiki/Spaghetti_code
A ver primero me presento profesionalmente De pequeño tambien empezé con un MSX y con BASIC por supuesto . En la carrera nos empamos de cosas como teoremas de Bohem y Jacopini , los algoritmos de Dijkstra, Diseños de Jackson y demas cosas que ahora parecen cosas del pasado . 13 años currando en el area de informática , de ellos 12 de programador , este último ya con tareas de gestión . He pasado por DBASE Clipper,Cobol, C, Delphi, C++, Java y C# ; y Si citamos plataformas conozco algunas .
Creo que estás totalmente confundido , la programación orientada a objetos salió a la luz con el C++ que si bien es una implementación con ciertos defectos ha sido, y de hecho sigue siendo el espejo en el que se han mirado los lenguajes que luego han aparecido.
Culpar al lenguaje y al paradigma de la orientación a objetos de la calidad actual de software es falso, la situacion de arte es el resultado de la falta de planificación, documentacion y el desprecio que la empresas están realizando a la experiencia en el ambito de la informática ( y en esto me ciño sólo a españa , porque en otros paises no pasa ).
Esta frase es la mejor de todas “Tan buena es la PP que cualquiera puede hacer un programa con escasos conocimientos del lenguaje que elija” Es el ejemplo mas claro , el programador DEBE conocer las herramientas que usa y el lenguaje lo mejor posible para poder sacar provecho y obtener un buen rendimiento y tambien se aplica un conocimiento del diseño de aplicaciones , antes eso se llamaba metodología ahora no lo se si se llama así pero es lo típico que primero se ignora . Los problemas que tu culpas a la OOP son errores de diseño de aplicaciones que no son responsables el lenguaje y que se pueden extender a todos los lenguajes.
¡ vaya rollo ! pero llevo sufriendo esto muchos años y me da mucha rabia este tipo de articulos
@Mac
Se te olvida un PEQUEÑO detalle. Yo hasta este año NO podía usar el programa PADRE y YO también he pagado por él.
Será una castaña, pero por lo menos ahora los usuarios de otros sistemas operativos lo podemos usar. Esperemos que en próximas versiones valla algo mejor, pero por lo pronto, creo que es una mejora MUY SIGNIFICATIVA.
@cruzki: Tienes razón, desde luego, pero no me estaba refiriendo a eso… Podían haber sacado un PADRE que funcionara en Mac o en Linux sin necesidad de semejante cagada… digo yo.
Como bien dicen algunos comentarios anteriores, el que una aplicación o sistema esté bien o mal diseñado, programado y probado, que tenga un interfaz bueno o malo y que tenga un buen o mal rendimiento, todo eso poco tiene que ver con si está hecho de una u otra forma, en un sistema u otro o con uno u otro lenguaje.
Yo me quejo, sobre todo, de que a los informáticos se nos ha olvidado escribir sistemas. Y estoy completamente de acuerdo con lo que dice Eagle sobre ese sentimiento de superioridad que, siempre que tienes una sana discusión con un colega javero tienes, y que bien dice Eagle: “Bah, eso de escribir en Cobol/Visual Basic/etc es para mariquitas del pleistoceno… ahora lo que mola es darle al Java con la máquina virtual 9.7 que ni siquiera ha salido todavía y que, cuando salga, me pondrá patas arriba la aplicación entera y tendré que reprogramarla de arriba abajo… pero ¡eso es lo que mola!
Pues no. Eso no mola. Lo que mola (o debería molar) es escribir aplicaciones sencillas, eficientes, fáciles de usar, y que sean estables. Muy estables. Cuanto estables más mejor… Ah! pero, claro, como todo está subcontratado, es mejor que conti¡ínuamente haya que modificarla, tocarla y apañarla (siempre por culpa de los demás, claro), que así me sigues contratando, y pagando, per saecula saeculorum… amén.
En fin. No creo que la discusión sea “Orientación a Objetos vs. Programación Estructurada (o funcional o declarativa o lo que sea)”, sino “Sistemas bien diseñados y programados vs. Sistemas desastrosos”…
Saludos!
@Mac: como siempre tus apreciaciones son muy valiosas. Java tiene el problema de su lentitud respecto a otros lenguajes, pero a cambio tienes portabilidad total. Nunca he usado el PADRE, pero imagino que ahora se puede ejecutar tanto en Windows como en Linux o MacOS, etc. En cualquier caso, nunca tendrás programas más rápidos que los antiguos de pantallas de MS-DOS, eso está claro (solo recordar cómo los usuarios pulsaban el nº exacto de intros para llegar a la casilla que ya conocían me da “morriña”).
@Sergio: no es que no me guste la POO, es que me gusta más la sencillez de la PP. Verás que con la continuación del artículo, que habla de POO, destaco muchas de sus virtudes.
@Zarovich: es cierto que lo simplifico, porque precísamente ese era mi propósito, acercar los conceptos a gente no acostumbrada a esto. De ahí que no ponga ni una línea de código real. Pero está claro que puedes simular POO con PP, aunque nunca será completa, por las propias características de la POO. De hecho, con VB6 se emulaba casi toda la POO mediante PP. Buenas apreciaciones las tuyas, gracias.
@Pedro: nuevamente estoy de acuerdo con tus comentarios (al final respondí a tu primer post cuando, mes y pico después, vi los comentarios). Sin embargo en estos temas puedes profundizar tanto como quieras, al tiempo que se complican a cada nueva inmersión. Por eso no quiero dar tantos datos, para no liar demasiado. Por ejemplo, cuando hablas de lenguajes imperativos o declarativos, es una clasificación, por supuesto, pero en este tema me estoy queriendo concentrar solo en PP vs POO. Añadir otros datos, otras clasificaciones, no afecta al asunto principal. De hecho, siguiendo tu sugerencia, cambié el título de PF a PP, para evitar la confusión. De todas formas ya te das cuenta de que mis explicaciones, si bien pueden no ser todo lo formales que gustarían, tratan de ser lo más sencillas posibles para alguien ajeno a la programación (los que ya saben no necesitan estas explicaciones). Eso sí, por favor, no dejes de comentar lo que veas, no vas a ser pesado por ello. Las conversaciones se enriquecen a base de opiniones.
@Lemurido: Dices que la frase que más te gusta es “Tan buena es la PP que cualquiera puede hacer un programa con escasos conocimientos del lenguaje que elija”. Fíjate lo que pongo luego: “lo cual ha dado lugar a auténticas chapuzas”. Es evidente que, independientemente del lenguaje que elijas para trabajar, siempre debes intentar hacerlo de la forma más correcta y óptima. Como dices tu, “conociendo el lenguaje y sus posibilidades”. Lo que pasa es que la PP permite trabajar ya, con escasos conocimientos y la POO no. O te crees que yo con 10 años iba a poder hacer aquél programa de preguntas con POO…
@Mac otra vez: coincido contigo.
Por cierto muchachos, no olvidemos que la historia en informática va por ciclos y, muchas veces, se repiten. Por ejemplo, ahí tenemos los primeros terminales tontos enganchados a un mainframe… y ahora viene Google, el más moderno del mundo mundial, y nos quiere meter ChromeOS que es… LO MISMO!!!
Lo que quiero decir con esto es que no nos extrañe que vuelva la PP a la palestra. Bueno, de hecho nunca ha llegado a irse del todo. Aunque está de moda Java y C#/VbNet (que es casi lo mismo), también se ha puesto de moda Python, que es una mezcla de POO y PP, por su peculiar forma de trabajar. Google trabaja con Python, por ejemplo.
@eagle La PP permite empezar muy rápidamente si pero en este punto esta su principal defecto en la creencia que se puede picar codigo y pensar simultaneamente . La POO ‘facilita” a pensar primero porque los resultados en codigo serán fructiferos . La experiencia en el desarrollo es muy importante porque a parte que tu productividad se eleva te puedes enfrentar a problemas dificiles y darles soluciones acertadas y que incluyan que el sistema sea mantenible.
Con 10 años metia todo en un monton de if anidados una subrutina y un par de goto y me quedaba tan ancho ahora (me da igual el lenguje) lo haría un pelí mejor, pero tambien es posible que este programa lo haga un recien entrado y que sea supervisado por otra persona y que le corriga y le enseñe que es lo que tiene que hacer en funcion de una normas/metodología de la empresa pero para eso hace falta tiempo y eso en este negocio escasea muchísimo
@Lemurido: qué bien lo acabas de definir en tu última frase “pero para eso hace falta tiempo y eso en este negocio escasea muchísimo”.
Leía estos días acerca de las “charcuterías” en las que se han convertido las consultoras. La gente entra y sale como si fueran carne, a granel. Cualquier, y repito cualquier, profesión necesita de tiempo para aprenderse. La informática no es ajena a esto, por mucho que quieran los que mandan que sí lo sea. Da igual que uses POO o PP, si no tienes experiencia la cagarás en ambos modelos. Será menos cagada en POO, porque es muy estricta y ya, de salida, no irá nada si no está bien hecho. Pero en POO puedes hacer muchos pequeños objetos bien y juntarlos muy malamente (mala concepción del proyecto).
No digo yo que debas programar “al vuelo”, siempre se debe planificar lo que se quiere hacer, es de base ya en la carrera (metodologías de programación), en eso no influye que uses PP o POO.
Te remito a que leas la segunda parte del artículo, que ya está enviada (falta ver cuando la publican) y habla de esto brevemente.
Ya lo he visto en los comentarios pero para mi el código spaghetti siempre ha sido por los saltos que va pegando un programa en su ejecución que además deben de ser adelante y atrás sin vaciar nunca la pila con lo que al final se produce un desbordamiento de esta, y no poner una parrafada larga que se ejecuta en un solo sentido.
Otra cosa es que considerar que la POO es mas complicada que la PP es sencillamente no conocer lo que la POO es. La mayoría de proyectos con una cierta complejidad se convierten en cosas mucho mas sencillas usando POO. Para mi la PP es lo que es difícil! difícil porque como bien apuntas una vez hecho el código al cabo de unos días es imposible saber que pone.
@Guillem: cierto, no he dejado claro en el texto que, además del chorizo de código que tiene que haber (pues sino, por muchos GOTOs que haya, poco se puede enmarañar), la expresión se refiere también a que haya muchos saltos en el flujo del programa.
Conozco la POO y, ciertamente, es MUCHO más complicada. Ya solo a nivel de “conceptos”, en la POO hay muchísimos más que aprenderser. Otra cosa es que tú te hayas acostumbrado a trabajar con ella, pero nunca será más sencilla.
En PP, si está bien diseñado y comentado, siempre conseguirás seguir el flujo del programa de forma sencilla.
@Eagle: siento discrepar, pero la POO no es mucho más complicada, simplemente es pensar de una manera diferente, lo que en muchos escenarios supone una ventaja al simplificar muchísimo el código a escribir.
Respecto a tu última frase, cualquier metodología permite seguir el flujo de un programa si el código está bien diseñado y comentado. El problema de PP es que permite trabajar en plan “me siento y escribo”, lo cual es un grave error, salvo para programas relativamente pequeños. La POO te obliga a pararte a pensar un poco antes de ponerte a programar. Podemos verlo como una especie de corsé que obliga al programador a hacer las cosas con un poco de orden. ¿Es un método mágico? Para nada (bajo mi punto de vista, coincido plenamente con Joel Spolsky: la verdadera revolución en el desarrollo del software no ha sido la orientación a objetos, ni la componentización ni el uso de máquinas virtuales, sino la gestión automática de memoria); de hecho, hay casos en que no compensa utilizar POO, pero en los casos que sí, ayuda mucho a organizar el código de una manera más limpia.
@Sergio: como siempre, estos temas son controvertidos. Pero hay un hecho que debería eliminar la duda sobre si la POO es o no es más complicada: herencia, abstracción, polimorfismo y encapsulamiento. Esos cuatro términos complican la POO, ya solo para entenderlos, respecto a la PP. De ello hablo en la segunda parte que, como decía, ya está enviada, de la que espero vuestros comentarios.
Ahora párate a pensar un programa en POO que emplee herencia a saco y me dices si es fácil seguir su hilo y sus “porqués” (por qué habrá hecho el programador eso…). Bueno, esta frase la entenderás mejor cuando leas la segunda parte.
Eagle: es que soy de los que piensa que un buen profesor hace fácil cualquier asignatura
Espero ansioso la segunda parte, aunque sólo sea para seguir discutiendo (sí, lo reconozco: mi lema es “¿De qué se habla, que me opongo?”
)
xD! ¡Gran artículo, en forma y fondo! De acuerdo en casi todo.
Llevo 10 años programando, y también pasé una etapa por VB, lenguaje que recuerdo con gran cariño. Sobre P. estructurada ó POO, en un 95% por cierto de los casos habituales es más ágil y rápido programar de forma estructurada. Para un proyecto decenas de personas, con varias empresas implicadas y que vaya a crecer continuamente de forma sustancial a lo largo del tiempo, elegiría POO. Pero la gran mayoría de aplicaciones no son tan exigentes ni mastodónticas, y ponerse a definir clases, heredar, etc. es como matar moscas a cañonazos: más costoso y menos efectivo.
¡Y que demonios,estructurar es mucho más divertido!
Por cierto, para que nadie se líe, GOTO es una indeseable instrucción que en la práctica NO SE USA en P. Estructurada (tampoco en POO).
Ojo de hablar de POO como si fuera simplemente cuestión de elección de un lenguaje. POO no deja de ser una metodología que puedes implementar con un lenguaje que dispone de construcciones que lo facilitan como puede ser C++ o Java, o implementas esas técnicas de otros modos. De hecho, encontrareis muchos proyectos escritos en ANSI-C y orientados a objetos. Al final la base no dejan de ser estructuras de datos con funciones asociadas para manipularlas y eso lo puedes hacer con C también. Lo que ocurre es que a eso hay que añadirle el tema de PPP, polimorfismo etc… El ejemplo contrario también existe, puedes hacer código procedural o estructurado (que no funcional, la programación funcional es otro mundo error!! lease Haskell) con un lenguaje como Java. Basta que te hagas una clase llamada Application y declares todo como estático.
Acerca del programa PADRE, el de este año puede ser más pesado y algo más incómodo pero al menos cumple con el derecho de poder acceder al servicio desde otras plataformas. El programa original era nativo de Windows y bueno, si ya hacer una aplicación realmente multiplataforma en Java no es tan trivial porque enseguida puedes caer en el uso de determinada librería nativa .. con esa ni lo quiero pensar.
“Por eso aclaro que a veces se habla de la Programación Funcional queriendo incluir la Programación Procedural (PP) o, también llamada Programación Estructurada. Por ello, para resumir y no decir tantas palabras feas, cuando hable de PP en general me quiero referir tanto a PF como a PP, ya que al final todo son funciones o procedimientos colocados de una forma estructurada y coherente que dan vida a un programa.”
Por último y ya me callo, aclarando que salvo este detalle y estando en desacuerdo en lo subjetivo, el artículo me parece excelente. No señores, la programación funcional no tiene nada que ver con la programación procedural o estructurada, es una metodología distinta de la cual de hecho, se están cogiendo muchas ideas en lenguajes POO como por ejemplo las expresiones Lambda. No me voy a extender más porque ya hay un excelente artículo en la wikipedia : http://en.wikipedia.org/wiki/Functional_programming
Veréis que http://en.wikipedia.org/wiki/Procedural_programming no es para nada el mismo artículo.
@lector: Ya. Claro. Ahora veo claro lo del PADRE… Gracias por explicármelo.
A ver si lo entiendo: Durante muchos, muchos años existía una versión de PADRE rápida, cómoda, con un interfaz mejorable, es cierto, pero bastante sencillo e intuitivo, bien establecido, y que todo el mundo conocía. Pesaba poco, era muy rápido arrancando y cambiando de página, y eficaz. Eso sí, sólo funcionaba en Windows… más que nada porque inicialmente se distribuía en diskette para MD/DOS (yo aún conservo esos proto-padres de 1992, 93 y así), y ha ido evolucionando conforme los padres de la patria han ido modificando la Ley año tras año, pero siempre conservando el interfaz básico y su velocidad.
Ahora hay muchíiiiiiisimos usuarios que no tienen Windows. Por lo menos, por lo menos… digamos un 8%?? un 10%, quizá, entre los diversos Linux y Mac/OS, siendo generosos?? Usuarios que además, siempre que sea cualquiera de los setecientos sabores cuasi-incompatibles de Linux, en casi todos los casos tienen instalado un Windows sobre el Linux… o bien tienen un portátil con Windows, o en el curro usan Windows…
Mi bien fundada impresión es que la cantidad de usuarios del PADRE que usan exclusivamente un sistema no-Windows deben ser pocos… muy pocos, en realidad.
Bueno, pues a todos esos usuarios entre los que me encuentro que usamos Windows porque somos así de inútiles, lerdos o veteranos, esta versión del PADRE nos ha fastidiado sobremanera. La misma declaración metida en el sistema del año pasado y en el de éste (he hecho la prueba por puro masoquismo) pasa de necesitar cuatro minutos y medio a… ¡diecisiete minutos!
Está rematadamente mal construida, es lentísima en carga y en operación, el interfaz es un desastre desde el punto de vista de la ergonomía de uso… una castaña pilonga, sin duda alguna. Por cierto, entre esos miles y miles de usuarios de Windows está la propia Agencia Tributaria: Todo su parque de colaboradores para ayudar a hacer la declaración de la renta en las Delegaciones usa Windows… vamos, que dichos colaboradores están que trinan, y lo digo con conocimiento de causa.
Pero, claro, es que había que hacerla en otra tecnología para garantizar la compatibilidad de uso con ese digamos 2% de usuarios que no usan Windows… Y mucha gente, en varios foros, usa este argumento (la multiplataforma) como excusa.
Bueno, pues mira: ESO NO ES EXCUSA. La aplicación está mal hecha. Rematadamente mal. Y sé perfectamente que, poniendo a hacerlo a alguien competente, hacerlo en Java o en Perl o en Haskell o en Cobol para dinosaurios, o en lo que sea, puede funcionar perfectamente. No tiene nada que ver con la tecnología, sino con la competencia de diseñadores y programadores. Como tantas veces, en este tema la Agencia ha querido marcarse el tanto tantas veces utilizado del “servicio a las minorías” para hacer una chapuza en toda regla.
Claro que sé que la tecnología no tiene nada que ver… ¡Eso es lo que me pone de los nervios!! Lo mal que se hacen últimamente las cosas en nuestra profesión. He vivido mucho, he visto mucho, he olvidado más aún… y cada vez me parece que trabajamos peor.
Cualquier día nos ponen mirando a Pamplona…
(Perdón por la filipica; es que este tema de la incompetencia supina galopante que nos atenaza me pone enfermo…)
Saludos.
Macluskey, aka Un Viejo trasnochado.
@Macluskey
Los problemas que mencionas tienen poco que ver con el hecho de que el programa sea multiplataforma. Por otro lado, el API de Windows también va cambiando, un programa con tantos años con Windows 7 tampoco se llevaría bien me atrevo a decir. Acerca de si los usuarios que suman los que utilizan Mac+Linux te diré que eso es una métrica pero hay otra métrica como la idoneidad de que un programa pagado con dinero público funcione en el sistema operativo de un único fabricante. Acerca de lo de los “setecientos sabores cuasi-incompatibles de Linux” pecas de gran exageración ya que como mucho puede haber prroblemas en cuanto a diferentes empaquetados porque a nivel de librerías y binarios todos son compatibles. De hecho a menudo se distribuyen ficheros “.bin” que funcionan en todos los Linux.
“ESO NO ES EXCUSA. La aplicación está mal hecha. Rematadamente mal. Y sé perfectamente que, poniendo a hacerlo a alguien competente, hacerlo en Java o en Perl o en Haskell o en Cobol para dinosaurios, o en lo que sea, puede funcionar perfectamente. No tiene nada que ver con la tecnología, sino con la competencia de diseñadores y programadores.”
100% de acuerdo, pero lo que dices por arriba no tiene coherencia con esa conclusión. Un programa multiplataforma puede ser perfectamente usable. De hecho, dudo que el programa se haya hecho en Java para soportar estas plataformas. El problema también existía con el propio Windows que acabaría requiriendo ejecutar PADRE en modo de compatibilidad como mucho.
@lector: Aaah, qué discusión más interesante!!
Lo primero, que estoy de acuerdo en prácticamente todo con lo que dices. Pero no veo la inconsistencia entre una parte y otra de mi comentario anterior.
Intentaré explicarme. Pongámonos en la piel del Director de TI de la Agencia Tributaria, sin ir más lejos, en algún momento de fines del 2009, cuando ya se conocen los cambios de legislación del año…
Situación actual: Existe un programa basado en tecnología antigua, pero probada, eficaz, rápido y muy conocido. No requiere formación entre versiones, su interfaz es muy ergonómico y sencillo, y ya está más que pagado y amortizado. Además, introducir los diferentes cambios de la legislación es relativamente rápido y sencillo (y barato!!).
Su problema es que sólo funciona en Windows, que es lo que usa la propia Agencia, pero deja fuera a una serie de usuarios que no quieren Windows ni en pintura por alguna razón. Cierto, no son muchos, pero hacen mucho ruido, así que es bueno hacer el programa lo más universal posible. Por tanto, estudiemos cómo conseguir esta universalidad de plataforma sin perder funcionalidad ni rendimiento ni interfaz, y por el menor coste posible.
Alternativa Uno: La solución “soviética”: Tiramos todo lo que hay y lo hacemos nuevo. Y que salga el sol por donde pueda…
Alternativa Dos: La solución pragmática: Mantengamos la versión Windows, al menos este año, para aquellos usuarios del Cretácico que usen esta antigualla (entre estos usuarios están los miles y miles de colaboradores de la propia Agencia, no lo olvidemos), y creamos una nueva versión para Linux, Mac y demás, incluyendo Windows, para irla rodando. El coste es ligeramente superior a la de la primera opción (modificar el programa del año pasado es muy poco costoso, pues la legislación ha cambiado poquísimo este año), y permite garantizar el servicio para la mayoría en las mismas condiciones que siempre, y detectamos erroes y fallos en la nueva, con la idea de que a corto plazo se convierta en la única aplicación, para evitar duplicidad de costes de mantenimiento.
En mi modesta opinión, ésta última opción de usar red al hacer las cabriolas en el columpio de la tecnología es mucho más razonable y correcta teniendo en cuenta que se trata de uno de los programas más difundidos en España.
El Resultado:
. El 95%, al menos, de los usuarios de PADRE cabreados, indignados, perdiendo tiempo, dividiendo por dos los rendimientos de tu cuenta conjunta con tu cónyuge para meterlos dos veces en vez de meterlos una sola vez, como antes, y todo ello con un pésimo rendimiento.
. Colas insufribles en las Delegaciones de la Agencia Tributaria. Como han seguido dando hora cada diez minutos, como siempre, que era una media muy razonable, y ahora se tarda cerca del doble, las colas se van alargando y alargando conforme pasa el día. Funcionarios y colaboradores cabreadísimos, usuarios indignados… y todo pa ná.
. Una minoría de usuarios, como es tu caso, contentos porque pueden, mal que bien, usarlo en su plataforma habitual, en vez de irse a casa de su primo como el año pasado.
No es que desprecie a esas minorías, entiéndeme bien, no me llames clasista o machista windosero o lo que sea, no es eso: creo que ellos tienen tanto derecho como los demás a usar un programa al fin y al cabo pagado con sus dineros en la plataforma que les pete… pero si esto es a cambio de fastidiar a la gran mayoría de usuarios… me parece fatal, al fin y al cabo, el PADRE también lo hemos pagado nosotros con nuestros dineros…
En fin. Esta discusión, en realidad, no va sobre tecnología, sino sobre la forma de entender el negocio informático que se ha extendido en los últimos años por doquier…
Parece que nos hemos olvidado de que nuestras creaciones no son para ponerlas en un museo, sino para que la gente las use, de la forma más sencilla, rápida y eficaz posible. Viendo cada una de las “nuevas versiones” de aplicaciones, sistema y programas diversos, creo que vamos derechitos al pozo. Nos hemos convertido en unos tipos muy malos escribiendo software. Y quizá fuera bueno recordar para qué nos pagan nuestros sueldos nuestras compañías, o nuestros clientes o usuarios…
¡Encantado de debatir contigo, lector!
Hasta otra. Mac
@Macluskey
Lo de la inconsistencia lo digo porque las deficiencias que comentas poco tienen que ver con el hecho de que el programa sea multiplataforma, más bien es consecuencia de que está poco probado e incluso no muy bien analizado. Esto habría ocurrido también si el programa fuera nativo. ¿Cómo puede haber llegado el programa en ese estado a producción?. Se puede imaginar fácil, subcontrataciones de subcontrataciones, demoras y plazos que si de por sí suelen acortarse para el cliente, se acortan aún más internamente para disminuir los costes de desarrollo, programación asignada a gente con poca experiencia a la que pagar poco. Es decir, puede ser un programa presupuestado para hacerlo en 1 año y hecho realmente en 3 meses más probado un par de semanas. Una beta que han colado a producción ni más ni menos. ¿Dónde está el informe de pruebas por ejemplo? Es algo que habría que exigir como clientes que somos.
Ahí l’as dao, lector, ahí l’as dao…
Lo mismito digo yo. El resultado es un desastre por todas esas cosas que tú dices, y seguro que algunas más, que en mi opinión de viejo cascarrabias obsoleto se resume en que, simple y llanamente, a la grey informática se nos ha olvidado trabajar. Nos preocupamos mucho de los aspectos financieros y formales del proyecto, pero no de si el resultado del mismo, es decir, el software resultante, cumple o no las expectativas… ¡o simplemente si funciona!
Eso mismo que tú te preguntas me lo pregunto yo: ¿Quién rayos ha hecho la especificación del interfaz? ¿Quién demonios probó en la empresa fabricante del software? ¿Quién porras hizo las pruebas de aceptación y dio el OK a la aplicación?
Me puedo imaginar todas las razones que tú dices y algunas más… pero el resultado está ahí: los usuarios habituales del PADRE vais a acordaros este año de los ancestros de los desarrolladores.
En fin. Como dije antes, y tú recalcas también, la culpa no está en realidad en la tecnología utilizada, sino en cómo se usa, y en cómo se usa una u otra tecnología como arma arrojadiza en multitud de foros de internet donde el personal olvida que lo más importante para el éxito de un Sistema es el factor humano.
Saludos otra vez.
Mac
Lamento que tengas esa visión de LISP (aunque lo comprendo, ya que hasta hace un par de años yo también la tenía). LISP es una maravilla de lenguaje (los paréntesis son anecdóticos, una vez que empiezas a programar con cierta soltura ni los notas). Yo he programado (y he enseñado en la universidad) mucho tiempo en C, C++, Java, etc y después de descubrir LISP para mí no hay color. Parece mentira que sea un lenguaje diseñado a finales de los años 50 por la potencia que tiene. Como mucha gente dice LISP no fue inventado, sino que fue descubierto por John McCarthy.
Cuando descubres cosas como la programación funcional, el diseño bottom-up, etc. utilizando LISP, te das cuenta de que todo lo que tenías asumido acerca de la programación no es del todo cierto. Hay otras formas de programar y de especificar algoritmos (que además puedes aplicar, aunque de forma más limitada a los lenguajes procedimentales o de POO). De hecho, lenguajes como Java (James Gosslin de hecho era un experto programador de LISP cuando lo creó), python, etc. en el fondo no son más que intentos de acercar los lenguajes derivados del ALGOL a LISP.
Si realmente te gusta programar, hacerlo en LISP es una maravilla. Es cierto que cuesta “pillarle el punto” pero cuando lo haces, al menos en mi caso, no quieres volver a programar en otro lenguaje.
Un saludo y felicidades por el artículo
@Luis: quieto paraooo, que yo no he dicho nada en contra de LISP
, solo que en mi época eran (y entiendo que siguen siendo) lenguajes anecdóticos, por su poco uso. Hice mis prácticas correspondientes y no me desagradó, simplemente fue una cosa más a conocer. Pero me gustan los lenguajes más próximos al lenguaje natural.
@lector y Mac: que interesante conversación habéis tenido, y yo ni me había enterado (¿cómo hago para recibir avisos si se escriben comentarios en el tema?). Y ambos estáis en lo correcto, de hecho, ninguno rebatíais lo que el otro decía, sino que os complementábais. Cuando hable del tema de las “capas” creo que volverá a salir algo parecido, ya que el ejemplo que voy a dar (vivido por mí) deja claro como las modas, a veces, estropean las cosas.
Escribe un comentario