Palestra de modelo : Paradigmas de programação

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar
WikiProject Ciência da Computação (Classe de modelo avaliado)
Ícone do projeto WikiEste modelo está dentro do escopo do WikiProject Computer science , um esforço colaborativo para melhorar a cobertura de artigos relacionados à ciência da computação na Wikipedia. Se você quiser participar, visite a página do projeto, onde você pode participar da discussão e ver uma lista de tarefas em aberto.
Modelo Este modelo não requer uma classificação na escala de qualidade do projeto .
 
Coisas com as quais você pode ajudar a Ciência da Computação do WikiProject:

Resposta ao aparente árbitro do inglês

A Programação Matemática é ao mesmo tempo um paradigma da Matemática e simultaneamente um da Programação de Computadores e está, na verdade, mais bem estabelecido como este último do que qualquer um dos outros na lista (atual) como tal, sendo aproximadamente co-avaliado com o desenvolvimento da computação eletrônica. Espero não ter que documentar isso. Licurgo ( conversa ) 14:45, 10 de janeiro de 2009 (UTC)Reply[responder]

Além disso, se eu seguisse o (uso relativamente negligente/desleixado) do restante do modelo, poderia adicionar alguns subparadigmas, como as abordagens da Informatik para criar sistemas de informação como problemas de otimização no domínio dos fluxos de informações do problema, como os de Langefors , et. al., paradigmas de custo e dimensionamento/estimativa como os de Barry Boehm , et. al. 72.228.150.44 ( conversa ) 14h50, 10 de janeiro de 2009 (UTC)Reply[responder]
É bom saber que há mais pessoas interessadas em melhorar este modelo. Na minha opinião, uma boa forma de proceder para chegar a um consenso sobre a inclusão (ou não inclusão) da programação matemática (ou qualquer outro elemento aqui apresentado como paradigma de programação ) é a seguinte.
Acho que devemos documentar aqui apenas os paradigmas de programação que foram declarados como tal nos artigos correspondentes e aceitos por consenso entre os editores do artigo individual em questão. Por exemplo, se a programação matemática é de fato um paradigma de programação , então isso deve ser documentado primeiro no artigo correspondente (juntamente com a citação de uma ou mais fontes respeitáveis) antes de adicionar uma nova entrada a este modelo. Dessa forma, poderemos manter neste modelo apenas as entradas que obtiveram consenso nos artigos correspondentes, liberando este modelo da maioria das possíveis disputas.
Quanto ao uso desleixado do " paradigma de programação " para as entradas atuais deste modelo, o conteúdo do modelo está sempre aberto para revisão. Nesse caso, sinta-se à vontade para criar uma seção nesta página de discussão para cada entrada que você deseja desafiar. Estamos abertos para ouvi-lo e colaborar com você na melhoria do conteúdo deste modelo. -- Antonielly ( conversa ) 16:33, 10 de janeiro de 2009 (UTC)Reply[responder]

Adicionando o modelo às páginas envolvidas

Acho que devemos seguir o exemplo da maioria dos outros templates "categóricos" (como Template:Software Engineering e Template:GUI widgets ) e adicionar este template a todos os artigos referenciados por ele. No entanto, o layout atual deste modelo é complicado para adicioná-lo a outras páginas além do paradigma de programação . Por exemplo, fiz duas tentativas de ajustá-lo a um artigo, mas não coube bem devido a problemas de layout. Acredito que devemos mudá-lo de alguma forma, mas o novo layout ainda deve preservar as hierarquias de paradigmas de programação e (se possível) os contrastes destacados de paradigmas "opostos/duais". Como poderíamos remediar isso? -- Antonielly ( fala) 17:07, 21 de janeiro de 2009 (UTC)Reply[responder]

Uma solução poderia ser manter {{ Programming paradigms }} como está (como um modelo de navegação vertical) e criar uma versão horizontal talvez {{ Programming paradigms footer }} para uso na parte inferior da página. Com uma versão horizontal, pode ser mais difícil mostrar hierarquia. Ambos os modelos também teriam que ser mantidos separadamente, mas poderíamos mitigar os problemas tendo avisos em ambas as páginas do modelo indicando que quaisquer alterações devem ser replicadas no outro modelo. Outra pergunta: por que o modelo vertical não deve ser inserido mais alto na página? LinguistAtLargeMsg 14:25, 24 de janeiro de 2009 (UTC)  Reply[responder]
Precisamos dessa caixa bastante intrusiva para começar? O leitor seria mais bem servido por algum artigo de visão geral que fornecesse essa mesma lista e talvez uma frase ou duas em cada uma. Colocar isso em artigos aleatórios sobre tópicos aleatórios só porque eles têm a palavra "programação" não é muito útil, não melhora a navegação, não torna o artigo principal mais legível ou compreensível. Na maioria das vezes fica no caminho e é uma distração. linas ( conversa ) 14:42, 26 de maio de 2011 (UTC)Reply[responder]

Mais um paradigma

A programação de representação de conhecimento deve ser adicionada. -- 4º-otaku ( conversa ) 21:38, 6 de agosto de 2009 (UTC)Reply[responder]

Eu não acho que isso seja um paradigma em si. -- Cybercobra ( conversa ) 22:55, 6 de agosto de 2009 (UTC)Reply[responder]

As linguagens orientadas a pilha devem ser adicionadas a esta lista? 168.105.238.51 ( conversa ) 00:40, 3 de dezembro de 2009 (UTC)Reply[responder]

Todo funcional é declarativo?

A linguagem funcional que é apenas digitada em cálculos lambda (apenas construção "se" e sem correspondência de padrões) com operações de memória de acesso aleatório e tipo de unidade pode ser considerada declarativa? — Comentário não assinado anterior adicionado por 194.85.160.55 ( conversa ) 18:22, 19 de dezembro de 2009 (UTC)Reply[responder]

A programação baseada em autômatos não deve ser subordinada à orientação a objetos

A programação baseada em autômatos não deve ser subordinada à orientação a objetos, não depende do paradigma OO ken ( talk ) 04:39, 31 March 2010 (UTC)Reply[responder]

Orientado a objetos não implica imperativo

Observe que orientado a objeto e imperativo são propriedades ortogonais, portanto, orientado a objeto não deve aparecer sob imperativo. Existem linguagens declarativas orientadas a objetos como Logtalk , Visual Prolog , CLOS , Needle , CLOVER e FOOPS . pgr94 ( conversa ) 14:53, 22 de junho de 2010 (UTC)Reply[responder]

Se não houver objeções, alterarei o modelo para que a orientação a objetos seja uma entrada de nível superior. pgr94 ( conversa ) 02:12, 3 de julho de 2010 (UTC)Reply[responder]
Ninguém manifestou qualquer oposição, então fui em frente e fiz a mudança. pgr94 ( conversa ) 00:38, 15 de julho de 2010 (UTC)Reply[responder]

Adicionar programação alfabetizada

A programação alfabetizada é certamente seu próprio paradigma e merece menção. Não tenho certeza se pertence à categoria de metaprogramação ou não. 128.101.155.71 ( conversa ) 19h17, 6 de abril de 2011 (UTC)Reply[responder]

Eu acho que a programação alfabetizada é declarativa. Arturotena ( conversa ) 18:25, 9 de abril de 2012 (UTC)Reply[responder]

Não estou satisfeito com este modelo

Não que eu tenha tempo para trabalhar nisso, mas é uma "lista gigante" de paradigmas quase esquecidos, digamos lógica abdutiva (quem usa isso agora?) e muitos outros. Eu poderia sugerir brincando uma mudança para "paradigmas de programação de ontem". Eu sugiro que vocês voltem aqui e tenham botões de mostrar/ocultar que escondam os itens esquecidos sob "paradigmas menores" e que os paradigmas principais apareçam primeiro. História2007 ( conversa ) 22:50, 8 de fevereiro de 2012 (UTC)Reply[responder]

Mais problemático, é claro, é a suposição subjacente deste modelo de que os "paradigmas" de programação formam uma estrutura semelhante a uma árvore. Ruud 22:56, 8 de fevereiro de 2012 (UTC)Reply[responder]

Vamos começar do zero

Sugiro começar do zero. Por favor, forneça as fontes ao fazer alterações. Eu forneci a fonte para os 4 principais paradigmas no artigo de paradigma de programação . Carbo1200 ( conversa ) 18:33, 4 de julho de 2012 (UTC)Reply[responder]

Não que eu esteja apegado ao modelo antigo, mas como começar do zero – sem uma ideia clara de como redesenhar esse modelo – vai ajudar? Ruud 19:13, 4 de julho de 2012 (UTC)Reply[responder]
Permitirá verificar as fontes e, assim, confirmar a relevância e precisão das novas entradas. Isso não deve ser uma lista de compras. Carbo1200 ( conversa ) 19:37, 4 de julho de 2012 (UTC)Reply[responder]
Carbo1200, estou claramente de acordo com você aqui (mas para AOP, talvez). Hoje alguém voltou à velha lista de compras - estarei ausente e não quero editar-guerra: é preciso chegar a um acordo com eles. Boa sorte! Chiswick Chap ( conversa ) 09:29, 9 de julho de 2012 (UTC)Reply[responder]
Por exemplo, eu ficaria tentado a remover a programação orientada a aspectos da lista (ela acabou de ser adicionada): é um paradigma ou apenas um estilo / técnica de programação? Eu tenderia a dizer que é o último e não deveria estar na lista (ou certamente não no primeiro nível de recuo). Mas quem sou eu para dizer? Em vez disso, devemos encontrar uma fonte que diga que é um paradigma. Carbo1200 ( conversa ) 19:43, 4 de julho de 2012 (UTC)Reply[responder]
Desafios da Tecnologia Orientada a Aspectos, RT Alexander e James M Bieman, Workshop sobre Qualidade de Software, Orlando, Flórida, 2002. Chiswick Chap ( conversa ) 20:01, 4 de julho de 2012 (UTC)Reply[responder]
Outra opção seria listar os 4 principais paradigmas e um link para a categoria:paradigmas de programação . Dessa forma, o modelo tem um tamanho razoável e ainda fornece navegação para outros tópicos (estou muito hesitante em chamá-los de "paradigmas", mas ei). O que você acha ? Carbo1200 ( conversa ) 17:23, 19 de julho de 2012 (UTC)Reply[responder]
As barras laterais são para navegar pelo conteúdo. Uma barra lateral que tem apenas quatro links é inútil. Eu reformatei o conteúdo antigo de uma maneira mais compacta e retirei todos, exceto os marcadores de nível superior. Este é um esqueleto melhor para uma reescrita. Chris Cunningham (usuário:thumperward) ( conversa ) 10:56, 18 de agosto de 2012 (UTC)Reply[responder]
Estou mais feliz com este formato - o antigo-novo, como você diz, continha tão pouca informação que era quase inútil. Dito isso, não estou convencido de que reduzir a lista de paradigmas tenha sido uma boa ideia; Sinto falta de alguns que eu chamaria de importantes, e outros parecem ser paradigmas muito menores, chavões ou não paradigmas. Prefiro recomeçar com alguns paradigmas de boa fonte, mas usando este formato de modelo. 85.226.59.251 ( conversa ) 17:56, 21 de agosto de 2012 (UTC)Reply[responder]
Sinta-se livre para brincar com ele. Esta foi apenas uma tentativa grosseira de acertar o layout básico para o futuro: minha seleção do que manter era tão arbitrária quanto a de qualquer outra pessoa. Chris Cunningham (usuário:thumperward) ( conversa ) 15:02, 23 de agosto de 2012 (UTC)Reply[responder]

Processual

Muito novo para adicioná-lo sozinho, mas a programação procedimental é discutida nestes artigos aqui vinculados como um paradigma de programação , bem como toneladas na web não-WP. Parece valer a pena uma lista aqui -? "alyosha" (conversa) 19:34, 25 de agosto de 2012 (UTC)Reply[responder]

Compactação ilegível

Olá, Squiver ! Desculpe por reverter sua tentativa de compactação, que sem dúvida exigiu uma quantidade significativa de tempo e esforço, mas transformou o modelo em uma coisa excessivamente compactada e ilegível.... Se for ilegível, dificilmente será usado quando exibido. Espero que você concorde. —  Dsimic  ( conversa  |  contribs ) 17:29, 3 de fevereiro de 2015 (UTC)Reply[responder]

Se o objetivo é tornar o modelo mais compacto, podemos tentar usar (ou algum outro modelo, se houver um que se adapte melhor) aos marcadores de nível superior ramificados, mantendo o layout geral existente. —  Dsimic  ( conversa  |  contribs ) 17:41, 3 de fevereiro de 2015 (UTC){{Collapsible list}}Reply[responder]
Existe um, ou talvez o modelo tenha muitos sub-balas de sub-balas / sub-colchetes de sub-colchetes? Squiver ( conversa ) 20:35, 3 de fevereiro de 2015 (UTC){{Sidebar with collapsible lists}}Reply[responder]
Isso é incrível, se encaixaria muito bem, veja o exemplo (incompleto e impreciso) que adicionei. Pensamentos? —  Dsimic  ( conversa  |  contribs ) 21:39, 3 de fevereiro de 2015 (UTC){{Sidebar with collapsible lists}}Reply[responder]
Obrigado por isso. Estou pensando "Deve ser alinhado à esquerda?", "As seções recolhidas devem ser agrupadas?" e "Os contrastes devem ter sua própria seção em vez de tornar os títulos longos?". Squiver ( conversa ) 09:50, 4 de fevereiro de 2015 (UTC)Reply[responder]
Em poucas palavras – não, não e não. :) Mais seriamente, centralizar mataria a estruturação por recuo, agrupar seções recolhidas a tornaria ilegível e adicionar outra seção para paradigmas contrastantes a tornaria muito menos utilizável. No entanto, sugiro que transformemos esses "(contraste: XYZ)" em notas usando o modelo. Espero que você concorde. —  Dsimic  ( conversa  |  contribs ) 16:00, 4 de fevereiro de 2015 (UTC){{Efn}}Reply[responder]
Ok, sem centralização, agrupamento ou seção de contrastes, mas dei ao protótipo aqui algum preenchimento para reduzir sua sensação geral de peso à esquerda e movi os contrastes para fora dos subtítulos. Eu também:
  • Reduzido o número de "contentX="s em uso;
  • Converteu a computação simultânea em uma entrada padrão, pois tinha apenas um membro (programação relativística);
  • Dado o link da planilha (list6) para o texto "Cell-orientated" antes dele, caso contrário, seria o único texto não vinculado nas listas;
  • Fez os contrastes Modular e de nível de valor em notas de rodapé como você sugeriu, então achou que não era realmente necessário?{{efn}}
Espero que esteja tudo bem. Squiver ( conversa ) 10:51, 5 de fevereiro de 2015 (UTC)Reply[responder]
Emendei a nota de rodapé, mas talvez algo diferente fosse preferível. Além disso, talvez as lacunas antes das seções Declarativa e Estruturada recolhidas signifiquem que pode ser melhor usar, por exemplo, uma única seção/lista em uma Barra Lateral padrão com Declarativa e Estruturada como s dentro?{{Collapsible list}}
Parece muito melhor, obrigado, mas eu diria que devemos manter cada entrada "folha de nível superior" como uma entrada separada |contentX=( já que é assim que o modelo deve ser usado) ou entrar em uma personalização baseada em . Para mim, agrupar várias entradas em uma única anula o propósito do modelo. Com relação ao preenchimento adicional à esquerda, tudo bem, mas sugiro que o mantenhamos na faixa de 0,5–1 em. Ah, e ter notas como parte do próprio template, ao invés de usar , é muito melhor. —  Dsimic  ( conversa  |  contribs ) 15:01, 5 de fevereiro de 2015 (UTC){{Sidebar with collapsible lists}}{{Collapsible list}}|contentX={{Sidebar with collapsible lists}}{{Efn}}Reply[responder]
Obrigado por ter paciência comigo enquanto eu descubro mais sobre o que faz o que etc. Eu pensei que o que eu tinha feito da última vez tornou o modelo muito complicado (talvez ainda seja), então tentei mantê-lo simples (r) sem perder layout ao incorporar seus pontos - exceto um: o preenchimento. Parece estranho aqui se o conteúdo não estiver alinhado com o título, então eu o mantive (e o corrigi um pouco). Mas, se você preferir que ele seja definido de maneira diferente ou removido, vá em frente.
Fico feliz que você tenha pensado que as notas de rodapé funcionaram - obrigado - mas elas foram a principal coisa que parecia complicada quando vi o modelo novamente, então as coloquei de volta no conteúdo, mas usando e o mais curto "compare... " em vez de "contrastar com..." texto.{{smaller}}
Há algo mais, mas não consigo imaginar o que é agora... Espero não ter retrocedido. Squiver ( conversa ) 19:43, 5 de fevereiro de 2015 (UTC)
PS: Você sabe se existe uma maneira mais limpa do que (por exemplo) "padding-top:0.2em; padding-bottom:0.2em;" definir algum preenchimento superior/inferior enquanto deixa qualquer preenchimento esquerdo/direito sozinho? Eu estava pensando em algo como "padding:0.2em herdar;", mas isso não parece funcionar (e provavelmente não deveria de qualquer maneira).Reply[responder]
Desculpe pela minha resposta atrasada... De nada, e obrigado por fazer todo o trabalho pesado. :) Você está certo, também precisamos ter em mente a manutenção posterior do modelo, então seu código Wiki deve ser mantido o mais simples possível.
Em relação ao preenchimento, eu diria que não devemos nos preocupar em alinhá-lo com o título do modelo – isso depende muito da plataforma e do navegador que o renderiza, e praticamente nada pode ser esperado lá. Mover as notas de rodapé de volta para o corpo do modelo é bom para mim, mas como vamos lidar com "folhas de nível superior" dessa maneira? Quer dizer, se não houver notas de rodapé, onde vamos colocar notas de "comparação/contraste" para itens que não se expandem?
Em relação ao código CSS necessário para definir apenas preenchimentos específicos, sempre preferi algo como padding-top: 0.2em; padding-bottom: 0.2em;, pois é altamente legível e de fácil manutenção. —  Dsimic  ( conversa  |  contribs ) 13:21, 9 de fevereiro de 2015 (UTC)Reply[responder]
A propósito, também podemos querer ver como o template faz uma coisa semelhante. —  Dsimic  ( conversa  |  contribs ) 06:31, 11 de fevereiro de 2015 (UTC){{OSIModel}}Reply[responder]

Ei, Ruud Koot ! Conforme observado em meu revert , peço desculpas por reverter sua edição , o que foi bom pois a necessidade de compactação é óbvia, mas o novo exemplo de layout aqui apresentado está bastante incompleto (serve apenas como exemplo de trabalho), causando-nos uma perda de muitos (sub)tipos de paradigma quando colocados ao vivo como tal. Nós só precisamos revisitar a coisa toda um pouco, resolver quaisquer problemas restantes de formatação/alinhamento, concluir a refatoração e colocar as alterações ao vivo. Talvez Squiver também gostaria de participar? —  Dsimic  ( conversa  |  contribs ) 04:40, 22 de agosto de 2015 (UTC)Reply[responder]

Hmm.... Estou começando a ter ainda mais dúvidas sobre este template, agora você menciona "completude".
Se você deseja que este modelo seja "completo" (ou seja, liste todos os artigos em Category:Programming paradigms ), ele deve ser convertido em uma navbox. Ter essas "caixas de navegação na barra lateral" só é aceitável se forem mantidas muito curtas. Isso só pode, neste caso, ser alcançado tornando-o incompleto. O truque de colapso também não funcionará por uma razão indireta: os paradigmas de programação não podem ser ordenados em uma estrutura de árvore não arbitrária se você quiser que ela seja muito inclusiva (bem, ou uma árvore que esteja muito ampla no root, o que anula o propósito).
Veja o horror que está acontecendo agora na Recursion (ciência da computação) . Ruud 10:44, 22 de agosto de 2015 (UTC)Reply[responder]
Eu me referi à "completude" no sentido de incluir todos os artigos que descrevem paradigmas de programação; IMHO, deveríamos estar felizes por ter tantos artigos assim. :) Francamente, eu apenas transformaria a barra lateral em um formulário recolhido por enquanto, o que certamente seria uma melhoria, e veria o que mais fazer mais tarde. Ah, e a Recursão (ciência da computação) parece esticada. :) —  Dsimic  ( conversa  |  contribs ) 17:55, 22 de agosto de 2015 (UTC)Reply[responder]

E a programação orientada a retorno?

Olá,

Acho que falta esse paradigma: https://en.wikipedia.org/wiki/Return-oriented_programming

Atenciosamente Julien — Comentário não assinado anterior adicionado por 141.35.40.184 ( conversa ) 12:39, 28 de novembro de 2016 (UTC)Reply[responder]

É um exploit de segurança do computador , então provavelmente não pode ser classificado como um paradigma de programação. Jarble ( conversa ) 20:21, 20 de setembro de 2017 (UTC)Reply[responder]

Processual não está em Estruturado

A programação procedural começa com "A programação procedural é um paradigma de programação, derivado da programação estruturada", mas aqui o procedural está sob imperativo. Não deveria estar subestruturado? Orenmn ( conversa ) 15:18, 26 de outubro de 2017 (UTC)Reply[responder]

Alguns deles são mais importantes do que outros

Sugiro repensar como isso é apresentado para enfatizar os paradigmas e tipos importantes .Reply[responder]

Removido Programação em Linguagem Natural

Eu removi a entrada Natural Language Programming, pois não é um paradigma até onde eu saiba. Se alguém quiser mantê-lo, forneça algumas fontes para estabelecer notabilidade. Foi em Pulido-Prieto, O. e Juárez-Martínez, U., 2017. Um levantamento das tecnologias de programação naturalista. ACM Computing Surveys (CSUR), 50(5), p.70. Teste escrito em linguagem natural como no desenvolvimento orientado por comportamento como definitivamente uma coisa. Qual é o critério de inclusão para este modelo? Notgain ( conversa ) 03:50, 13 de julho de 2019 (UTC)Reply[responder]

linguagem de consulta adicionada como sub de declarativa

Tendo navegado em todos os comentários acima, aprecio que haja vários problemas com este modelo, mas não tenho grandes ideias sobre como reconstruí-lo do zero. Como um DBA eu estava procurando onde o SQL se encaixaria e me surpreendi por não encontrá-lo em Declaratives, então verifiquei a página SQL e ela se refere à página da linguagem Query, que por si mesma se declara parte do paradigma Declarative, então parecia uma correção de consistência. Embora a página de linguagem de consulta possa usar algum trabalho. Helvetius ( conversa ) 11:56, 3 de janeiro de 2022 (UTC)Reply[responder]