O paradigma de programação orientada a objeções está desatualizado, pois é antimodular e anti-paralelo? [fechadas]


23

Eu li o controverso artigo Ensinando FP a calouros postado por Robert Harper, que é professor na CMU. Ele afirmou que a CMU não ensinaria mais a programação orientada a objetos no curso introdutório, pois é "inadequado para um currículo moderno de CS".

E ele afirmou que:

A programação orientada a objetos é totalmente eliminada do currículo introdutório, pois é antimodular e antiparalela por sua própria natureza.

Por que considerar o POO como antimodular e antiparalelo?



14
Buhwaaaah ?! OO facilita a modularidade e o paralelismo do que no procedimento e não é mutuamente exclusivo do FP. Cor me confuso.
Matt Ellen

4
Eles redesenharam seu currículo para que ele tenha que vender o novo programa e está fazendo afirmações ousadas, com absolutamente nenhum dado. Não há evidências de que programas funcionais complexos sejam mais paralelos ou modulares do que seus colegas de OOP.
Davidk01

4
@ Matt Ellen: OOP é decididamente mutuamente exclusivo da FP. O FP é baseado em vários conceitos-chave, dos quais um é a ausência de estado mutável. OOP baseia-se na existência de um estado mutável cujo acesso é controlado envolvendo-o em "objetos". Estado mutável e estado imutável são mutuamente exclusivos por definição. Sim, é verdade que você pode programar em um estilo funcional com muitas linguagens OOP, mas isso não é o mesmo que usar uma linguagem FP. E sim, é verdade que nem todas as linguagens FP são puras. Isso não está dizendo que o FP seja compatível com OOP, no entanto.
APENAS MINHA OPINIÃO correta

2
@ APENAS: Eu tenho uma idéia diferente de exclusividade mútua para você. Eu vejo o FP puro e impuro como subconjuntos do FP, e assim o OOP não é mutuamente exclusivo do FP se você assumir que a mutabilidade é essencial para o OOP. Também não concordo que a mutabilidade seja essencial para o POO. Você poderia obter um sistema OO inteiramente usando a passagem de mensagens e nunca sofrer alterações.
Matt Ellen

Respostas:


30

Por favor, considere que as necessidades de Harper para ministrar uma aula introdutória de currículo de CS são muito diferentes das necessidades de um projeto da vida real . Seu trabalho é ensinar conceitos fundamentais (por exemplo, modularidade, paralelismo, indução) a calouros. Como tal, é muito importante que a linguagem (e o paradigma) escolhidos possam expressar esses conceitos com o mínimo de cerimônia (sintática e conceitual) possível. Familiaridade, suporte de ferramentas, bibliotecas disponíveis, desempenho de execução etc. são completamente irrelevantes nesse contexto. Portanto, lembre-se disso ao considerar o seguinte ...

A visão de que OO é anti-modular resulta do grande número de dependências para outras classes, mesmo objetos de classes bem projetadas tendem a acabar. Isso é um problema - mesmo aos olhos dos defensores do OO - fica claro quando você olha para a proliferação de estruturas , artigos, livros e postagens de blog de injeção de dependência nos últimos anos (também é interessante a ascensão de zombarias e tocos).

Outra dica é a importância dos Padrões de Design e a complexidade de implementá-los - em comparação com outros paradigmas de programação - por exemplo, Fábricas, Construtor, Adaptador, Ponte, Decorador, Fachada, Comando, Iterador, Mediador, Observador, Estratégia e Método de Modelo e talvez de alguma forma, o Composite está relacionado à melhoria da modularidade do código OO.

A herança também é problemática (por exemplo , problema frágil de classe base ) e o polimorfismo (subtipo) seduz a pessoa a espalhar a implementação de um algoritmo entre várias classes, onde as mudanças podem se espalhar por toda a cadeia de herança (para cima e para baixo!).

A acusação de ser anti-paralelo está relacionada à ênfase do estado em comparação com a computação (também conhecida como mutabilidade versus imutabilidade). O primeiro envolve a expressão de dependências de subcomputações (que é a opinião de Harper sobre paralelismo!), Pois geralmente não é possível inferir a partir do local em que o estado é gerenciado (também conhecido como arquivo, onde a variável de instância é declarada) que atores externos vai mudar em que momento.

Uma ênfase na imutabilidade e computação facilita muito a expressão de dependências de subcomputações, pois não há gerenciamento de estado, apenas funções / cálculos que são combinados no local em que você deseja expressar as dependências de subcomputações.


10
As alegações de paralelismo do campo funcional são muitas vezes exageradas. Os compiladores para linguagens funcionais trabalham com uma teoria fundamental mais limpa, para que os implementadores tenham mais maneiras de reorganizar o código antes que ele se transforme em código de máquina, mas isso não significa que se você fornecer aos programadores de OO as abstrações adequadas para o paralelismo, eles não serão capazes para escrever um código paralelo limpo. Até agora, os programadores procedimentais obtiveram apenas bloqueios e threads e se saíram muito bem, eu acho, com essas ferramentas.
Davidk01

2
Embora eu geralmente concorde com tudo o que você diz aqui, gostaria de salientar que os padrões de design estão em todos os paradigmas de programação. Para programação funcional, eu apontaria coisas como mônadas e mapear / reduzir.
Anm

@ davidk01 Pegue o Go Go, por exemplo. Ele suporta programação orientada a objetos e possui ótimas primitivas de simultaneidade. Mais importante, ele está decolando para programação simultânea sem ser puramente funcional.
weberc2

19

Esta é provavelmente uma afirmação ousada a ser feita, mas, de alguma forma, suspeito que Robert Harper nunca tenha realmente escrito software real em sua vida. Tudo o que ele parece se preocupar é com sistemas ML e estáticos. Por maior que seja a contribuição, não vejo como suas alegações sobre OOP têm relevância.

Este artigo não é controverso. A controvérsia envolve exame, argumento e discussão. O que você tem aqui é um acadêmico ignorante que apresenta duas acusações fundamentais em apenas uma única afirmação, sem se dar ao trabalho de apresentar argumentos.

  1. A alegação de que a OOP é anti-modular é simplesmente um absurdo. Eu nem sei como responder a isso, não apenas nenhum argumento foi fornecido, mas também OOP por design é uma abordagem para estabelecer modularidade com muito baixo acoplamento entre módulos individuais por meio de encapsulamento e abstração.

  2. Reivindicar OOP é anti-paralelo apenas demonstra uma falta de entendimento. OOP não trava nenhuma decisão sobre simultaneidade. OOP apenas exige ocultá-los: se construído corretamente, você não pode dizer se a implementação de um objeto é paralela ou não.
    Assim, finalmente, a OOP e a programação paralela são ortogonais. O modelo de ator é um modelo elegante de simultaneidade que pode ser refletido diretamente em um sistema de objetos (mas não precisa ser), produzindo uma combinação formidável de ambos.

O problema do POO é que poucas pessoas realmente o entendem no sentido em que Alan Kay o definiu.

  1. OOP é uma abordagem. Em alguns idiomas, ele é implementado usando padrões; em outros, você pode usar diretamente os idiomas internos (por exemplo, Ruby, Objective-C, Smalltalk, Io ).
  2. Contrariamente à crença comum, OOP não é sobre classes. Trata-se de objetos e objetos são sobre a passagem de mensagens ou uma maneira igualmente ininterrupta de encapsulamento e abstração.

É por isso que Java é OOP o que bastões pontiagudos são para o combate naval. Isso também é verdade para muitas outras "linguagens OOP", mas o que acontece com Java é que parece ser uma crença comum nas universidades que o Java deve ser usado para ensinar OOP.

Concordo com todos aqueles que pensam que as introduções ao OOP com Java devem ser removidas dos currículos de CS. Eu também acho que as pessoas que claramente não têm uma compreensão fundamental do POO não devem ensiná-lo. Portanto, provavelmente é melhor se Bob se apegar ao ML em seus cursos e simplesmente ensinar o que ele tem um entendimento firme.
No momento, o POO é mais uma etiqueta da moda, que as pessoas gostam de manter em tudo. Isso prejudica o POO e disse as pessoas. OOP não está desatualizado. Idade de ouro do OOP ainda está para vir, quando as pessoas finalmente entender o que é sobre o que é não sobre (por exemplo, resolver todos os problemas possíveis, usando a palavra-chave class500 vezes).


1
+1 na passagem de mensagens e +1 no 'com Java'. Infelizmente, se eles removessem o Java, eles o substituiriam por C # e continuariam seu legado.
Gbjbaanb

@ back2dos +1 para os críticos, -1 para Java. Certamente, o Smalltalk é "muito mais OO" que o Java, mas quem o usa? Objetivo-C é difícil para iniciantes, assim como C é.
Maaartinus

@maaartinus: Você achará o Squeak amplamente utilizado na área educacional e acadêmica, se isso responder à sua pergunta. Também no Java: você pode gostar, eu não. Assim como o café, é uma questão de preferência pessoal e não faz sentido discutir isso. No entanto, Java não é adequado para uma introdução ao OOP é IMHO uma implicação inegável da natureza do Java e do conceito de OOP, e foi exatamente isso que eu disse. A popularidade de Java não fará com que isso desapareça. Quanto a C, sugiro que você leia joelonsoftware.com/articles/ThePerilsofJavaSchools.html .
back2dos

@ back2dos O Squeak pode ser usado nessas áreas, mas na universidade eu aprendi ML. Ambos são igualmente inutilizáveis ​​na indústria e vale a pena aprender, devido a seus conceitos. O artigo apontado é o pior artigo de Joel que eu já li, é muito longo e, à primeira vista, a mensagem parece ser a importância de lidar com segfaults. : D Eu realmente sugeriria Java para ensinar OOP.
Maaartinus

@maaartinus: O que você aprendeu na universidade pouco importa na questão do que deve ser ensinado . Você ainda não deu razões pelas quais alguém deveria usar Java para ensinar OOP, enquanto eu dei o que considero uma razão bastante sólida para não fazê-lo. Obviamente, você também não conseguiu entender a essência do artigo: as pessoas que não conseguem lidar com problemas com a mesma dificuldade que C não devem estudar CS em primeiro lugar. Eu acho que CS não deve se deixar levar pelo que todas as crianças que gostam de computadores podem entender. Se não concordarmos com isso, uma discussão mais aprofundada é uma perda de tempo e minha.
back2dos

12

Você recebe fanáticos de todas as faixas.

A programação orientada a objetos não é uma bala de prata. Isso nunca foi. O que é, é vítima de exageros. Inevitavelmente, as pessoas ficam cansadas do hype e uma reação começa a se desenvolver (independentemente da utilidade real do paradigma).

Daqui a vinte anos, sem dúvida, teremos outra reação contra a programação funcional.


1
Já existe!
quant_dev

1
++ "Você recebe fanáticos de todas as faixas." Eu era acadêmico e minha experiência foi essa . Os acadêmicos adoram expressar opiniões provocativas, impressionando talvez seus alunos.
precisa saber é o seguinte

5

Não posso responder a essa pergunta por completo, porque só podemos adivinhar os pensamentos vagos de seu autor. Eu suspeito fortemente que este artigo esteja prestes a causar algum constrangimento ao seu autor. Não há nada sobre OOP que sugira que ele não seja modular nem paralelo:

Modularidade : Uma faceta principal do POO é que ele é de fato modular (mas modularidade significa coisas diferentes em contextos diferentes). Portanto, independentemente de o autor estar falando sobre generalização ou programação estática, ele está incorreto.

Paralelização : Quanto à programação paralela, a maioria das estruturas oferece suporte a interrupções, depois a encadeamentos e agora a paralelização adequada, como o que vemos no .Net framework 4.0 e nas linguagens OOP que se encaixam nela.

Suspeito que o autor tenha se tornado uma vítima da moda, pois há um equívoco de que a programação funcional e a POO sejam mutuamente exclusivas no uso. Existem estilos funcionais nos idiomas OOP que estão bem documentados, por exemplo, Oliver Sturm publicou nesta área.


4

O autor sustenta que o POO é muito difícil para os programadores de calouros entenderem, o que pode ser verdade - embora eu duvide, devido aos requisitos de entrada para a CMU! As declarações anti-modulares e anti-paralelas podem ser verdadeiras em um contexto estreito quando comparadas a linguagens puramente funcionais, mas dificilmente são uma condenação de todo o paradigma (que parece funcionar muito bem para quem sabe usá-lo).

O currículo proposto ensinaria programação funcional em uma turma, programação imperativa (procedural) em outra turma e estruturas de dados em outra turma. Depois que um calouro dominar essas três coisas, ele / ela deve estar pronto para aprender OOP.

Pessoalmente, acho que isso é um exagero, mas os acadêmicos gostam de tentar coisas novas e extremas. Como contrapeso, o MIT costumava (e ainda pode) ensinar todos os principais paradigmas de programação em uma turma de calouros.

Curiosamente, ambas as escolas produziram alguns bons programadores. Vai saber.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.