Paradigmas de Programação + PolyglotProgramming + Craftsmanship 09/Jan/2010
O meu percurso enquanto SoftwareDeveloper tem sido como que aleatório.
Os conceitos base que devia ter adquirido em cada etapa / nível não foram adquiridos porque o objectivo final era o mais importante – em vez do percurso / caminho. Daí ter aprendido sobre tecnologias e sistemas de informação e sobre e linguagens de programação através de tele-transporte de conhecimento em vez de uma fluída sequência de saltos evolucionários.
Com esta introdução começo então a abordar neste artigo os 3 termos que acho estarem intimamente ligados entre si e que deveriam ser a base e o objectivo principal de qualquer 1ª etapa na vida de um SoftwareDeveloper: entender e equilibrar paradigmas de programação; conhecer, dominar e usar diversas linguagens de programação sem preconceitos; fazer com que os trabalhos feitos e soluções desenvolvidas “falem por si” bem das capacidades do SoftwareDeveloper.
Eu tenho aprendido linguagens de programação de forma obrigatória para resolver os problemas do momento actual. Ou seja, em vez de ter aprendido as linguagens de programação enquanto formas de comunicar quer com o computador quer com outros SoftwareDevelopers na resolução adequada de problemas – de forma geral em vez de forma concreta – tenho aprendido sem qualquer método. Em vez de aprender por motivação ( de forma activa ) tenho aprendido de forma reactiva, passando de uma linguagem qualquer para outra próxima linguagem qualquer. E nessa passagem, porque assim sem método é complicado, tenho tentado facilitar o percurso através de utilização de analogias: se na linguagem A fazia assim então na linguagem B devo poder fazer algo assim.
No entanto, as linguagens de programação – regra geral – ou são multi-paradigma ou são ícones de um dos paradigmas. A linguagem Oz, no entanto, é uma das poucas linguagens com a ambição de ser “todos-os-paradigmas”.
O que quer dizer que eu devia ter aprendido primeiro que existem n paradigmas de programação, dos quais 2 tem maior relevância visto serem – provavelmente – os mais usados quer pelos SoftwareDevelopers quer pelo tamanho do conjunto de linguagens de programação que permitem algoritmos nesses paradigmas:
Cada um destes 2 paradigmas sub-divide-se em paradigmas de âmbito menos lato:
- Imperativo:
- Com base em classes
- Com base em protótipos
No entanto, apesar de cada vez com maior aplicação prática, não é comum falar-se noutros paradigmas:
E para cada um destes paradigmas, bem como todos os outros restantes paradigmas que aqui não abordo, têm uma ou mais linguagens de programação representativas. Assim, e é dado início ao conceito PolyglotProgramming, depois que se entendam os conceitos base de cada paradigma estará então o SoftwareDeveloper mais capaz de escolher a linguagem de programação mais adequada para resolver os problemas de um dado domínio. Um SoftwareDeveloper iniciante terá um conjunto menor de linguagens ao seu dispôr – menor conhecimento e experiência – enquanto que um outro SoftwareDeveloper mais avançado terá um vasto leque de linguagens para escolher.
As linguagens que considero representativas de cada paradigma acima indicado são também aquelas que eu deveria ter aprendido como base da programação:
- Imperativo.Procedimental: Pascal, C
- Imperativo.OrientadoObjectos.Classes: Smalltalk
- Imperativo.OrientadoObjectos.Protótipos: Self
- Declarativo.Funcional: Haskell, Lisp – nas variantes CommonLisp e Scheme
- Declarativo.Lógico: Prolog
- Concorrencial: Erlang, Clojure
De notar que não indico nem Assembly, nem BASIC, nem Fortran, em COBOL, nem C++, nem Java, nem C#, nem Tcl, nem Perl, nem PHP, nem Eiffel, nem Ruby, nem Python, nem Lua, nem JavaScript, nem Scala entre tantas outras linguagens cada vez mais em voga. Apenas destaquei as linguagens que considero serem os “ícones” de cada paradigma. Destes ícones, apenas C é que tem sido a linguagem que tem usado profissionalmente. E também destes ícones o pouco que sei de Pascal, Lisp e Prolog foi porque aprendi na Universidade. Os restantes ícones ainda nem sequer aprendi ( mas tenciono aprender cada um destes ícones… )
De notar também que algumas das linguagens que indico são normalmente associadas a linguagens que requerem compilação enquanto que outras são normalmente associadas a linguagens interpretadas ou linguagens scripted. Estes conceitos têm vindo a decair com a evolução das linguagens de programação e há também ainda outros conceitos base que são importantes dominar: tipificação forte vs. tipificação fraca e tipificação dinâmica vs. tipificação estático.
Se apenas pudesse escolher uma das linguagens ícones para aprender todos os paradigmas habituais, então a escolha teria que ser somente Lisp. Isto porque é a única que indico enquanto ícone que permite programar segundo os paradigmas procedimental, orientado a objectos ( CommonLisp, com CLOS ), funcional e meta. Além de que influenciou outras linguagens emblemáticas, tais como Smalltalk, Perl, Python, Ruby, Lua e JavaScript. Mas ainda assim ficariam de fora os paradigmas lógico e concorrencial ( se bem que existe Clojure que, enquanto dialecto de Lisp, podia muito bem colmatar esta falta ). Este ponto serve para evidenciar que mesmo sabendo muito bem uma linguagem ainda assim se fica aquém do conhecimento e experiência que um SoftwareDeveloper deve ter ( e que pode adquirir se conhecer e dominar múltiplas linguagens: PolyglotProgramming ).
É minha forte opinião de que um curso de Ciência da Computação deveria primeiro introduzir os paradigmas de programação mais comuns, para depois – através de pequenos projectos comuns entre as linguagens – ir introduzindo cada uma das linguagens ícones. Estes pequenos projectos comuns também teriam que ir evoluindo ao longo do curso, não só seguindo as linguagens e os conceitos, mas também seguindo o caminho de modo consola, modo TUI, modo GUI, modo Web e modo RIA.
As linguagens de programação mais “usadas” – podendo-se considerar aqui o índice TIOBE – seriam depois aprendidas em curtos CrashCourses ao longo da vida profissional. Linguagens como Java, C#, Perl, Tcl, Python, Ruby e Scala seriam, de forma mais fácil e rápida e também profunda, assimiladas pelos SoftwareDevelopers. Com a vantagem de se falar sobre e dominar conceitos de base sem ambiguidades e sem desinformação.
O dominar diversas linguagens, cobrindo dessa forma um largo espectro de paradigmas, deveria significar que seria mais fácil e directo escolher a tecnologia que seja suficientemente adequada para resolver problemas de um dado domínio. Significa também que, para problemas muito complexos, uma só linguagem e um só paradigma podem não ser suficientes. É preciso saber escolher a “ferramenta” mais adequada pra cada trabalho de forma análoga a um carpinteiro que tem à sua disposição várias ferramentas para “comunicar” à madeira qual a solução final que pretende. E ninguém espera de um carpinteiro o mesmo esforço e trabalho em fazer um simples banco de madeira ou em fazer uma complexa mobília de quarto. É pedido um orçamento e uma estimativa de esforço, que nos casos mais complexos implica também não ser linear substituir um carpinteiro por um escultor ou até mesmo por outros dois carpinteiros para ter a solução em menos tempo ou mais bonita.
E assim termino, procurando que o parágrafo final acima acenda algumas luzes sobre se um SoftwareDeveloper é ( ou não ou pode ser ou não deve ser ) um Craftsman.
- Posted in : doCoding
- Author : José Carlos Monteiro
Comments»
Tens de meter aqui o Sociable para a gente promover os artigos sem espinhas
Plugin: http://blogplay.com/sociable-for-wordpress/
DoMelhor e outros: http://www.box.net/shared/vur1d3b8ks
sm00sh: http://smsh.me/7k5l
1,
Lopo
Boa dica, vou investigar isso. És o máximo! Thanks.