Introdução
Esta postagem abordará os principais detalhes de dois dos principais paradigmas de programação existentes. Inicialmente, serão apresentados detalhes específicos de cada um paradigma e logo após será traçado uma relação de prós e contras de ambos os paradigmas.
Paradigma de programação é um padrão ou estilo que agrupam linguagens com certas características comuns.Programação Imperativa
A Programação Imperativa é um conceito baseado em estados, definidos por variáveis, e ações que são manipuladoras de estado, procedimentos. Pelo fato de permitir o uso de procedimentos como estruturação, também é conhecido como, Programação Procedural.
Devido ao uso de sub-rotinas pode-se dividir o código para uma maior modularização de um sistema computacional.
A Figura 1 mostra graficamente a estrutura da Programação Imperativa. Tal figura, é apresentada sempre nos cursos de computação simulando a idéia de entrada, processamento e saída.
Figura 1. Programação ImperativaSão exemplos desse paradigma a maioria das linguagens conhecidas em uso no mercado, visto que as linguagens Orientadas à Objetos herdam as características das imperativas e implementam seus próprios conceitos.
- Pascal
- C
- Cobol
- Python
A Programação Declarativa, ao contrário da Programação Imperativa que informa ao computador "COMO" as instruções devem ser executadas, preocupa-se em apenas dizer ao computador "O QUE" precisa ser feito, cabendo ao computador decidir qual a melhor solução para essa solicitação.
As linguagens definidas por este paradigma não podem ser consideradas como linguagens de programação, e sim, como sub-linguagens. O grande mercado que envolve a computação utiliza-se bastante destas linguagens. Tem-se como seus principais representantes:
- XML
- SQL
Vantagens: Programação Imperativa
- Eficiência
- Modelagem natural dos problemas do mundo real
- Dominância de mercado
- Bem estabelecido
- Facilidade de acesso a banco de dados(SQL)
- Conversão de objetos complexos(Pessoa, Empregado) por Binding para trafegar pela rede(XML)
- Focaliza o "COMO" e não o "QUE" precisa ser feito
- Difícil legilibilidade
- Ilegilidade do código(Quando usada de forma funcional)
Quando juntos, estes dois paradigmas formam a base da maioria dos sistemas de computação presentes no mercado. É claro que torna-se necessário acoplar à Programação Imperativa os conceitos de Orientação à Objetvos. Tais paradigmas se unem formando a base de todo o mercado de desenvolvimento.
Referências
- DESCOBRE. Tipos de Linguagem de Programação. Disponível em <http://www.descobre.com/forum/showthread.php?t=697>. Acesso em 09. jan. 2009.
Clube de Revista
9 comentários:
12 de janeiro de 2009 às 09:33
Grande Zé Mauro!
Boa postagem, cara! Para começar as discussões, gostaria de saber alguns detalhes:
1. As linguagens declarativas são mais usadas para armazenagem de dados, em vez da modelagem efetiva de um sistema. Isso também se justificaria pelo foco delas estar no quê precisa ser feito. As duas linguagens que você citou, são grandes exemplos disso. Há alguma linguagem declarativa que permita a modelagem de um sistema a nível de comportamento, ou não?
2. Você cita como desvantagem da programação imperativa, a ilegibilidade. Contudo, cita Python como uma linguagem imperativa. Python é reconhecidamente uma linguagem que acaba por produzir, queira o programador ou não, códigos muito limpos e legíveis, sendo o próprio PEP8 um exemplo disso "Legibilidade conta." O nosso próprio pensamento é imperativo. Mesmo uma pessoa que não programa computadores se programa de forma imperativa (vou fazer isso, depois aquilo e depois aquilo outro...). Qual foi o seu embasamento para tal afirmação? (Note que não estou dizendo que você está errado, quero apenas saber o que você levou em conta para afirmar isso).
3. Há duas frases que eu gostaria de uma explicação:
3.1. Quando você cita como vantagem da programação declarativa: Conversão de objetos complexos(Pessoa, Empregado) por Binding para trafegar pela rede(XML)
3.2. E como desvantagem da programação declarativa: Ilegilidade do código(Quando usada de forma funcional)
>>> Há como programar de forma funcional em programação declarativa? Nesse caso não seria desvantagem de outro paradigma?
Abraço!
12 de janeiro de 2009 às 09:55
Fala Zé.... Deu sinal de vida rapaz, qdo for assim deixa um sinal de fumaça.
Vamos as perguntas.
Pelo que pude observar das linguagens declarativas existentes, que eu conheço é claro, tanto o XML quanto o SQL de certa forma tratam o sistema de nível comportamental. Por quê?
XML: Pelo fato de poder transpor um objeto de uma comlexidade maior em um arquivo de código puro, ao meu ver, do seu jeito ele trabalha de forma comportamental.
SQL: Este acredito que não haverá nenhum controversia no jeito de pensarmos. Quando criamos store procedures e functions, dizemos como fazer e não o que fazer, tratando assim o nível comportamental.
A segunda pergunta sem dúvida foi um pouco contraditório da minha parte, mas vamos lá. O Python aborta tanto a programação imperativa, OO e funcional. Mas ela é classificada em um nível mais abstrato, imperativo, agora imagine unir-se a ela um pouco de programação funcional, isso sem dúvida poderia obscurecer o código. Sem contar que até mesmo sem utilizar tal recurso, dependendo do programador o código não ficará nada claro.
A pergunta 3.1 é o seguinte: As coisa que mais necessitamos em um ambiente de rede é segurança e banda de transmissão. Com essa técnica de Binding, obtemos as duas, como? Por exemplo, ao instanciarmos um objeto não deveriamos fazê-lo a nível de cliente pois todas suas características estariam em trafego pela rede, tal técnica faz com que ao realizar uma solicitação de nova instância(ou qualquer outra informação) o servidor realize o conversão de XML para o objeto a ser instanciado ou recuperado. Acontece o inverso da codificação nas duas pontas.
A última pergunta você está certo em dizer que é uma desvantagem de outro paradigma, mas como as linguagens declarativas, também herdam algumas características das linguagens funcionais, ao meu ver também herdam seus defeitos.
E pra vc quais são as principais vantagens e desvantages de ambos os paradigmas?
Abraço.
12 de janeiro de 2009 às 11:16
Salve!
A troca do blog está consumindo meus pensamentos e esse final de semana eu fiquei off...
Vamos lá:
Quanto ao XML, eu discordo que modele o comportamento de um sistema. Note que comportamento neste caso é relacionado a respostas do sistema a estímulos do usuário. XML é uma [sub]linguagem ótima para armazenar dados de quaisquer tipos, mas não implementa, que eu saiba, instruções de controle de fluxo e acho que ela é usada puramente para armazenagem. SQL é uma linguagem para acesso a dados e sim, concordo com o que você disse sobre a linguagem, lembrei, inclusive dos triggers.
Python é imperativa, OO e funcional. Se você programa imperativamente, ela é imperativa, se programa OO, ela é OO e se programa funcionalmente, ela é funcional. Isso é óbvio. Por isso, se você programa funcionalmente em Python e julga o código ilegível, não é uma desvantagem do paradigma imperativo, mas sim do funcional. ;-)
Sobre a questão de binding, eu entendi a frase agora. Contudo, você não acha que esta é uma vantagem da ferramenta que você utiliza e não do paradigma em si?
Sobre a segunda pergunta, ficou uma dúvida: o paradigma declarativo foi criado com base no funcional? Se sim, quais as características mais evidentes que ele herda? (sem querer entrar no paradigma funcional, que será tema de uma próxima discussão, claro...)
Para mim, quanto ao paradigma imperativo, a principal vantagem é ele estar intimamente ligado ao nosso modo de pensar. Como citei, nós pensamos imperativamente, damos ordens imperativamente. Por isso fica fácil programarmos. A desvantagem seria a legibilidade do código no sentido em que é facílimo misturar o comportamento do programa, com interface e tratamento de dados, ou seja, uma falta de legibilidade a nível de semântica e não sintática.
Já quanto ao declarativo, a vantagem é para tratamento/armazenagem de dados. A desvantagem é a legibilidade, pois é complicado entender o que está gravado num arquivo HTML, por exemplo.
Inté! ;-)
12 de janeiro de 2009 às 13:26
Quanto ao XML vc tem razão ela pode ser considerada mais a nível de transporte. No SQL discordo de você quanto a trigger, pois na verdade vc não tem muito controle, e sim, apenas manda incrementar algum evento. Mas isso é questão de pontos de vista diferentes.
Com certeza vc tem uma série de abordagens para Python, isso é fato. Só que você não cria um código so imperativo, OO ou funcional, geralmente, é uma mescla de todos, na maioria das vezes dos dois primeiros.
Quanto ao binding não é a nível de ferramenta, acredito que qualquer linguagem de alto nível implemente a transição de um objeto complexo para sua representação em XML, binário, o que quer que seja, a nível de aplicações web.
O paradigma declarativo foi baseado sim no modelo funcional. A grande evidencia, ao meu ver, e não englobar nos conceitos imperativos de ações.
Você disse:
"...Python é imperativa, OO e funcional. Se você programa imperativamente, ela é imperativa, se programa OO, ela é OO e se programa funcionalmente, ela é funcional..."
Você acha possível desvencilhar os paradigmas? Não só esses mas também incluo o declarativo neste contexto?
[]s
12 de janeiro de 2009 às 17:12
Com certeza é possível desvenciliar os paradigmas. Eu, por exemplo, não programo funcionalmente em Python, mas há quem use Python só pra programação funcional. Já o OO e o Imperativo, quando comparados, mostram o OO como um nível de organização de código imperativo e não um paradigma propriamente dito. É como se OO fosse uma extensão do imperativo, herdando tudo que ele contém e acrescentando funcionalidades.
Se Python permite a programação em vários paradigmas, é uma peculiaridade da linguagem, já os paradigmas permanecem intactos. Obviamente há quem se aproveite disso e utilize vários paradigmas como imperativo e funcional no mesmo código, mas nesse caso fica claro onde está cada um, pois os componentes funcionais de Python (e.g., lambda) são bem definidos.
Você disse que qualquer linguagem de alto nível implementa a transição do objeto para representações em XML, binário etc. Anteriormente você disse que isso se justificava por questões de desempenho e segurança. Você sabe citar alguma linguagem que faz isso? E o que vou ganhar em segurança ao transmitir um objeto pela rede em XML, uma vez que um arquivo em XML pode ser aberto num editor de textos qualquer?
[]!
12 de janeiro de 2009 às 19:50
Concordo com você a primeira parte sobre o paradigma funcional e que a OO é estendido da linguagem imperativa. Mais vc não respondeu minha segunda pergunta sobre desvencilhar a OO-Imperativa, das linguagens declarativas? Vc acha esse fato possível?
Kra to vendo isso com o C#, vc tem um trafego de rede mais leve porque vc vai transportar um arquivo texto simples. A nível de segurança vc não tem o cliente acessando diretamente ao atributos do seu sistema, vc vai fazer o cliente converter do arquivo XML para aplicação e o servidor converte de XML para o objeto que for. Não falo somente a nível arquivos XML. Pode-se usar tbem com o protocolo SOAP que é bem difundido para aplicações web.
abraço.
12 de janeiro de 2009 às 20:13
Salve!
Desculpe. Pra mim, as linguagens declarativas não se confundem com OO/Imperativa. Na verdade, eu acredito que elas trabalham muito bem em conjunto, vide Python/XML, PHP/SQL... Neste caso, as linguagens OO/Imperativas ficam com o trabalho de modelar o comportamento do sistema e as declarativas em modelar a armazenagem dos dados. Então temos o COMO e O QUE trabalhando em conjundo, cada um com suas potencialidades, em prol do resultado final.
Por isso, não acho que elas se misturam, mas cada uma trabalha na sua, em conjunto com a outra... ;-)
12 de janeiro de 2009 às 21:49
Concordo em gênero, número e grau, com sua colocação.
Em qualquer sistema computacional decente os dois paradigmas vivem entrelaçados. Um muito comumente utilizado em bancos(CEF, BB, Itau)é o arquivo .OFC que é espécie um XML, para extratos bancários.
Abraço brow!
eh nois!!!!
18 de outubro de 2016 às 15:37
Qual a diferença de linguagem imperativa, declarativa, funcional e lógica.
Postar um comentário