thegoodfellas/blogset-br huggingface dataset:
ocorrer um fato, ainda nao determinado, no futuro. Meu pai de santo se recusou a fazer consultas compulsorias.Claro, esta metamorfose nao teria ocorrido se minha capacidade de dizer nao estivesse mais apurada. Isto nao importa. O fato e que o projeto nao se materializa como producao porque foi andar no infindo caminho da busca da perfeicao.Neste meu estudo de caso perdido, pude notar que o perfeito de agora e simplesmente o imperfeito de anteontem. E que o perfeito de ontem, e um caso a ser estudado, mas que nao necessariamente e necessario. Ou seja, o projeto deve ser orientado a conjunturas e especulacoes.Uma outra coisa que pude notar e o receio de que o projeto nao fique a cara do adjunto de avaliacao tecnica, mesmo que ele sequer vai usar o projeto, neste caso um sistema. Assim, o meu nao mais cliente usa de um pre-contexto: a sua experiencia devera prevalecer da forma que e contextualizada no seu conhecimento.Se fossemos capazes de interpretar estas variacoes do conhecimento, a producao de software estaria num patamar futuristico. Isto porque nosso conhecimento se apresenta em funcao das necessidades intelectuais de um determinado momento. Ocorre um problema, e se ele nos e desconhecido nosso raciocinio e direcionado a encontrar a maneira mais rapida de soluciona-lo, nao a melhor. Se este mesmo problema ocorre novamente, e simples para o cerebro recobrar uma solucao ja aplicada, nos dando tempo para projetar uma outra solucoes e entao poder avalia-la como melhor ou pior, e assim sucessivamente. Assim formamos a experiencia.No entanto e individual, depende de quantas vezes o problema e apresentado a cada pessoa e em que tipo de ambiente. E, claro, qual a solucao rapida de cada um, que originou o ciclo pessoal da experiencia.A busca pela perfeicao aplicada a este meu projeto, o torna um celeiro de experimentacoes, que jamais tera fim. Nenhuma tentativa sera boa o suficiente a partir de amanha, e todas serao obsoletas depois de amanha, podendo ser o algo perfeito no mes que vem.Para este caso, nao ha solucao. A impressao de um projeto inacabado ja esta presente no adjunto de avaliacao tecnica, que neste momento retorna a crisalida e volta a ser cliente. E faz uma distincao de papeis: o cliente e quem se aborrece, o adjunto tem meritos das boas ideias, mas se nao vai para producao ou nao termina nunca a culpa e do desenvolvedor.Qual a melhor saida neste caso? Continuar a busca pela perfeicao? Abandonar o projeto? Acredito que um debate, nao embate, e sempre a melhor opcao. Claro, nao sera uma especificacao assinada com sangue com resolvera os problemas. Ao contrario, pode ate piorar.Neste meu caso em especifico, tentei mostrar ao cliente sua posicao de Stakeholder, como uma parte interessada para que ele pudesse se manifestar em entregas e nao em projecoes que ainda nao foram desenvolvidas. Solicitei que analisasse o quao generico deveria ser a aplicacao, para que outras opinioes fossem ouvidas. E o principal, que o todo fosse repartido em partes, segundo o negocio, para que cada uma fosse avaliada em particular.Mas nao e uma solucao,
e sim um paliativo. Nao e possivel saber quanto tempo meu cliente se comportara como cliente. Tudo isto porque houve uma falha de planejamento: a da definicao de papeis. Ou seja, a culpa realmente e do desenvolvedor.
Hoje, conversando com o #dynaum, comentei sobre minha falta de inspiracao para compor um novo post. E engracado, pois particularmente nao creio muito neste negocio de inspiracao neste modelo quase divino, muito propagado por ai. No meio de um assunto sem fim (trabalho), acabamos por falar sobre algo um tanto nada haver: a capacidade de julgamento do ser humano.Falavamos sobre a triste realidade de, algumas pessoas, usarem de criancas para esmolar. Comentei que para a crianca, aquilo pode nao ser bom ou ruim, uma vez que ela nao conhece outras realidades para compor uma comparacao. Bom, como nenhum de nos e um sociologo, ou antropologo, o assunto morreu por ai mesmo.Para minha satisfacao, julguei ter encontrado inspiracao para este post: como julgamos uma LP, um OS ou mesmo uma metodologia de trabalho sem conhecer outras a que comparar? Afinal, precisamos mesmo comparar para aceitar?Costumamos acreditar que algo e bom, e melhor pelo fato de apenas ser mais simples, ou parecer mais simples. E estariamos errados? Lembro-me dos meus primeiros passos, digo, pedaladas com a bicicleta de um amigo meu. Era uma Caloi 10 e a gente se enfiava no meio do quadro e tentava pedalar. Prestava atencao no pedal, esquecia o caminho, dava com a cara no chao.Apos alguns tombos, consegui andar. E apos muitos tombos, consegui virar uma esquina. Eu havia aprendido a andar de bicicleta. Mas nao dava para chegar onde eu queria, se que quisesse ir a uma cidade vizinha. No entanto, consegui isto, certa vez, com a moto de meu irmao. Nao cai, mas foi bem dificil guardar como se passava as marchas, apertar a embreagem ao inves do freio, frear com o pe, regras de transito, tec. Pode parecer ridiculo, mas o instante do aprendizado, seja ele no que for, nao nada ridiculo ou facil. A gente praticamente nao se assume aprendiz, mas adora contar que e tudo muito facil. Claro, apos nos garantirmos. O caso e que andar de moto e mais complexo, porem acho melhor que andar de bicicleta. Assim, nem tudo que aparenta maior simplicidade eu julgo como o melhor. Porem, acho a moto melhor pelo fato de que ela torna o meu esforco motor mais simples. Nao vou morrer de cansaco por subir um morro de moto, a nao ser que eu precise subir empurrando-a.Bom, se e assim, julgaria que algo e melhor por minimizar meus esforcos. E o que eu ganharia com isto? Tempo? E o que eu faria com o tempo? Procuraria algo melhor e mais simples para fazer, do tipo, tirar um cochilo?Ainda assim, o julgamento e subjetivo, particular a cada ser. Assim sendo, o que faz com que um grande numero de programadores eleja esta ou aquela Linguagem, sendo que a mesma e a unica em seus curriculos? Subjetividade coletiva? Vou deixar isto para o C. G. Young.Nao e uma critica, serio. O caso e que se torna mais e mais constante ouvir de algumas empresas: escolhemos a linguagem X porque ha mais programadores no mercado. E pelo fato destes programadores serem mais baratos, nao estamos abertos a novas
tecnologias. Exagero meu? Imagino que cada um tenha sua historia para contar. Espero nao estar criando um silogismos, mas vejamos:Se a linguagem X tem mais programadores, e a mais simples.Se e mais simples e porque ha mais codigos na net (mais gente posta)Se ha mais codigos tem-se menos esforco para criar, posso simplesmente juntar os codigos.Se junto os codigos...Brincadeiras a parte, isto nao esta relacionado a LP, mas ao programador. Infelizmente, ha varios fatores que fazem com que as pessoas migrem para o ramo da programacao. E como e um espaco bastante concorrido, e preciso estar pronto de imediato, o que faz a relacao do menor esforco uma causa viavel.Mas ate quando tal fato se perdura? Eu sei, eu sei, e mais um caso subjetivo. Porem, os danos sao mensuraveis. Voce se consultaria com um medico que nao se recicla ha mais de quatro anos? Que entende somente de polegares direitos? Se voce machucou o polegar esquerdo, porque confia o seus software a quem nao se recicla? Nao posso, nem deveria, julgar os motivos de uma nao reciclagem. No entanto, quem e capaz de desenvolver sem acesso a internete? Eu mesmo fiquei quatro anos estacionado em vb pelo simples fato de que me proporcionava dinheiro. Nao mais nem menso que o suficiente para o meu momento. Ganhei quatro anos um bom salario ou perdi quatro anos de novas tecnicas e tecnologias.Como garantir que nao necessitaremos desta ou daquela linguagem? Devemos lembrar que necessidades surgir surgirao que ainda nem sao pensadas. Alguem senti necessidade de um iPhone em 1985? Como desenvolvedores, estamos na contra-mao do menor esforco: somos nos quem o produzimos. Proporcionamos menor esforco para outras pessoas, os usuarios, nao para nos. Criar algo simples requer trabalho. Dedicacao. Esforco maior.O fato eu apenas conhecer vb impediu-me de comparar meus ganhos financeiros a outros desenvolvedores, de outras linguagens, de outras plataformas. Cheguei ao ponto de ridicularizar a web, pois sempre cria na evolucao das aplicacoes desktop. Como resultado, entrei no mercado tarde, desatualizado e, o pior, por necessidade e nao por opcao.Nao digo que todos devem ser poliglotas em programacao, mas e preciso conhecer para comparar. Nao existe melhor ou pior em programacao. Eu programo em linguagem X porque gosto, assim como gosto de vermelho. (Palavras do Henrique Bastos). E e assim mesmo que deve ser. Porem gosto de vermelho porque acho o azul chato, porque a linguagem y tem menos escalabilidade. Ou seja, sei do que gosto, porque sei comparar. Para finalizar, penso que o conhecimento e intransbordavel... (Se e que esta palavra existe)
Fui aconselhado, dia desses, a nao utilizar termos como paradigmas, conceitualizacao, empreendedorismo. Que eu deveria medir palavras, olhar antes com quem estava conversando. A justificativa e que meu modo entusiasmado de conviver com o novo, por vezes assusta.Como nao pretendo ser assombracao de ninguem, resolvi seguir o conselho. Mas para isto ha um custo: deverei deixar de ser eu mesmo. E claro que ninguem solicitou tal absurdo, mas esta bem implicito, nas entrelinhas.Lembrei-me de uma passagem biblica que diz quando eu era crianca falava como crianca. Ou coisa parecida. Nao importa. O caso e que, assustadoramente, os tais termos realmente assustam. Tambem lembrei-me de um pedreiro, certa vez em minha casa, que na falta de um ferramental de esquadro, mediu 60cm de uma lado, 80cm do outro, alinhou com uma vara de 1m. Ele disse: pronto, esta esquadrado. E eu disse: isto e Pitagoras, mas ele: nao, eu so esquadrei. Ele nao sabia porque, ou como, mas usou a hipotenuza, um triangulo retangulo, um teorema, elevou ao quadrado, tirou raiz, mas no fundo, apenas esquadrou, sem saber o que aquilo significava. E quantas vezes agimos da mesma forma? Quantas vezes decoramos uma sintaxe e acreditamos dominar uma linguagem de programacao?Seria hora que quebrar conceitos ou de quebrar galhos? Sejamos ecologicamente corretos: quebrar um galho e uma agressao a natureza. Assim, sejamos fieis a nossa natureza inovadora e nao a agredamos com conceitos de protecao. Os conceitos de protecao sao aqueles que garantem o andamento de nossa vidinha mais ou menos, que mantem o status de assim esta tudo bem e nos mantem inertes na escalada evolutiva.Sim, nos evoluimos sim. A cada dia, a cada codigo, a cada logica reformulada. Quebrar conceitos e mais do que mudar de ideia, e mais do que mudar de rumo. Ate porque, nao e possivel mudar de um local para lugar nenhum. Quebrar conceitos significa avaliar e experimentar o novo. Mas o que fazer com o entusiasmo, tao presente e fascinante em nossa vida? Seria o caso de nos fazermos atores, nos aderirmos ao senso comum? Infelizmente, a resposta a estas questoes pode estar ligado ao legado financeiro de cada um. Ou seja, se eu nao me adequar, estarei fora. E nao precisamos de mais desempregados. Vejamos uma breve tabela de sinonimos divergentes: Ousadia Desrespeito Hierarquico Empreendedorismo Vai sair e abrir o proprio negocio Dedicacao Puxa saco Paradigma Algo muito mal Critica Tecnica Agressao Pessoal E neste cenario que muita gente trabalha, e nao somente no ramo da programacao, mas em qualquer esfera profissional. E um fato, nao ha o que fazer. Mas acredito mesmo que e possivel mudar. As mudancas tecnologicas, climaticas, historicas acabam por forcar a humanidade a evoluir. E sempre ha espaco na evolucao.Deixar de ser voce mesmo, nem pensar. Medir palavras e um sinal de bom senso. O que nao significa ter que abandonar conviccoes. Nao devemos nos proteger de nos mesmos. Isto seria um re-trabalho. E hora parar de esquadrar e comecar a compreender Pitagoras. Ao inves de fazer porque mandaram, compreender o como fazer. E o mais importante: saber o que
se fez.E possivel fazer uma casa apenas com galhos quebrados? Ha possibilidade de se aprender carpintaria exercendo o oficio de quebrar galhos com o proprio peso? Ao pensar nas questoes vitais do tipo: quem somos, para onde vamos; vamos tentar pensar antes em: o que somos e como vamos.
Lendo um artigo do Henrique Bastos sobre programadores lentos, por sinal muito bom, fiquei tentado a divagar sobre o assunto. Como de costume, fiquei horas e copos pensando e formulando, revendo minha pobre experiencia de vida e acabei por cair no tema, de cara. O Henrique tem razao sobre a posicao da atitude na qualificacao de um programador, quica na qualificacao de uma pessoa, como ser humano. Mas minhas ponderacoes seguiram um outro rumo, embora adjacente ao tema: ate quando e possivel exercer a atitude?Ta bom, eu sei que o tema e piegas, batido, mas fazer o que? Este tema incomoda-me profundamente. Sempre que posso, gasto lentamente meu tempo a seu favor. A que serve a atitude se ela nao e vista como tal?Este tipo de post e daqueles que nao pretendem mudar o mundo ou o seu modo de pensar. Vai mais como um desabafo, um chororo causado pela droga do talento. Sim, talento e uma droga. Nao simplesmente pelo fato de ser viciante. Todo mundo tem um talento e e viciado nele. Mas tambem trazer tantos transtornos.A atitude nao e uma virtude, mas uma obrigacao. Porem esta relacionada ao carater, e este e um ponto que nao vale o debate: ou se tem, ou nao se tem; oito ou oitenta.Porque relacionei atitude e talento? Pelo simples fato de que considero a atitude como sendo a materializacao do talento. Quando alguem trabalha minuciosamente um projeto, buscando nao a perfeicao, mas simples usabilidade daquilo que esta sendo produzido, e tal qual o oleiro a moldar sua obra de arte. Sim, porque programar e uma arte, um talento. E para tal, exige mais do que dedicacao, exige paixao. Ou seja, a paixao e uma atitude.Mas o talento continua sendo uma droga. Quantas pessoas voce conhece que sao chamadas de talentosas? Eu conheco poucas, embora chame a muitos por este codinome. Agora, vamos mudar a pergunta: quantas pessoas voce conhece que sao chamadas de nerdes, de cientistas malucos, de inventadores de moda?Se o numero cresceu, fique satisfeito: voce conhece muita gente talentosa e, claro, tambem vitimas de um preconceito, como todos, infundado, de nossa sociedade moderna. Este mesmo preconceito deixa, por vezes, um certo medo de se ter talento. Nao raro o mercado dispensa profissionais altamente talentosos na mesma proporcao que dispensa os ruins. E a explicacao e bem simples: ambos estao nas pontas, e certas empresas preferem a mediocridade que obedece, que nao questiona.Talvez, digo talvez, tudo esteja relacionado ao conceito de produtividade. O que e a produtividade? Se um programador esta lendo, ele esta produzindo? E se ele desenvolve um sistema, e todo dia o monitora afim de que o mesmo siga sem problemas, ele esta produzindo? E se o programador simplesmente pensa, estara ele produzindo?O que e producao, afinal? E passar o dia inteiro digitando codigos? Ora, o programador foi contratado para produzir e isto denota que ele ja sabe tudo o que precisa saber. Ou nao?Mas a culpa e do talento, dessa droga de talento. Se nao fosse o talento, nao haveria possibilidade de comparacao. Nao haveria a ponta, apenas
mediocridade e coisas menos. Seriamos menos tristes sem ele, mas jamais mais felizes. Nao sem a paixao.Acho que chega de lagrimas. Essa droga do talento sempre me deixa assim, meio jururu. Mas isto nao importa, pois tenho comigo o orgulho de ser, desde crianca, o cientista maluco do colegio.
e, pessoalmente preocupei-me mais com a Linguagem de Programacao aplicada do que com o problema em si. Intimamente ja sabia que o primeiro ia para o ultimo, o segundo para o primeiro e o terceiro esperava. Sim, eu sabia. Dificuldade mesmo era na declaracao de um array especifico que queria-mos usar.Ate que uma boa alma pergunta: e se forem quatro ou cinco mictorios?E preciso confessar que somente neste instante me deparei que o trivial nao era tao simples quanto se mostrava. Divaguei em minhas reflexos, conversei com meus botoes, tentei formulacoes matematicas, e apenas descobri que um problema e sempre um problema. Nem dificil e nem facil, apenas problema.Em meus pensamentos pude notar um certo remorso, pois fui logo pensando em algumas solucoes antigas que utilizei no passado, o quanto eu desrespeitei o problema em si. Sim, foi mesmo desrespeito e, claro, tive re-trabalho.Sempre acreditei que, nestes casos, a analise era incompleta, mas na verdade era falha mesmo. O problema foi considerado simples e a analise foi apenas simples. Logo, no lugar de uma solucao simples, produzi algo imaturo, que nem era solucao.Como julgar se o problema e simples ou complexo? Nao julgue, problemas sao problemas. Alias, em termos de programacao, nao julgue nunca, tenha sempre certeza. E isto possivel? Bom, encerro com uma outra questao: acaso duvida que 2 + 2 = 4?
Como comecar um artigo sobre a compreensao do paradigma funcional? Primeiramente e necessario entender porque eu quero deixar de ser um deus para ser um reles tita. Sim, porque programar em modelos imperativos me tornam um deus: faca isto, faca aquilo... E os erros, ah os erros, eles vem depois. No momento, somos apenas eu e a maquina a me obedecer. Entendamos por este exemplo:declare mundo booleandeclare trevas booleandeclare luz booleaninicio trevas = true escreva(Criar Luz?) leia(luz) se(luz == true) faca trevas = false mundo = true escreval(Houve luz) escreval(O Mundo foi Criado) senao escreval(So existe trevas) fimdose fimJa deu para perceber quem e que manda aqui, nao e? Eu disse haja luz e houve, e o mundo foi criado, e as trevas deixaram de existir. Se nao der pau no programa, claro. Isto e linguagem imperativa: faca isto, faca aquilo. Sou eu quem determina o que deve ser feito, sou o proprio manda-chuva, senhor de meu universo. Tenho o poder de dar vida ao criar uma variavel, interfiro em seu destino simplesmente alterando o seu valor, e posso gerar consequencias, caso queira, definindo estruturas de decisao. E o melhor, posso dar fim em tudo, afinal, eu sou deus. Como pode-se perceber, neste meu creation of the world, como um bom deus, indiquei sequencialmente minhas ordens de como fazer. O que haveria de ser feito dependeria de um fator variante, ou seja, daquilo que recebi como entrada. Se eu lesse false em minha entrada de luz, de acordo com minha condicao, as trevas permaneceriam, e se a entrada fosse banana, nao haveria cosmos, e sim caos, pois nao fiz um tratamento de excecao.Quando falamos em um modelo imperativo de programacao, estamos entendendo (compreendendo?), como algo muito proximo de nossa linguagem. E isto esta correto. Lembram dos verbos no modo imperativo?Fazei, vos!Gracas a um outro deus , Von Neumann, de forma imperativa utilizamos um modelo matematico que busca processar uma unica instrucao de cada vez, procurando manter a integridade dos dados executados. Nem e preciso dizer que este paradigma e dominante que esta estabelecido.Alias, o que vem a ser paradigma?De acordo com o Priberam,paradigma (grego paradeigma, -atos)s. m.1. Algo que serve de exemplo geral ou de modelo. = padrao2. Gram. Conjunto das formas que servem de modelo de derivacao ou de flexao. = padrao3. Ling. Conjunto dos termos ou elementos que podem ocorrer na mesma posicao ou contexto de uma estrutura.Bom, podemos entender como ponto de vista. Porque nao? E bem mais simples do que parece. Os paradigmas: orientado a objetos, a funcoes, a excecoes, etc, nada mais sao do que pontos de vista sobre melhores formas de se programar em dadas situacoes, determinados problemas. Ao menos nao deveriam ser: um unico paradigma, a solucao de todos os problemas. Isto tem um nome que nao me lembro. Ah, sim, isto e fundamentalismo.Bom, no ponto de vista utilizado na interpretacao da minha criacao do mundo, como disse, e claramente definido o como fazer, e as nuances derivadas sao diretamente ligadas ao o que fazer. Isto pode ser uma desvantagem, uma vez que o como
fazer nao garante o que deve ser feito e nem se foi feito. Estas garantias estao ligadas a mais comandos, mais codigos.Mas apesar de tudo, ainda sou um deus. E se olhar mais a diante, posso criar santos a que chamarei de classes, que intercederao a mim. Sim, estou falando de orientacao a objetos, que em suma, seria uma forma de organizar o modo de como fazer. Ou seja, um nivel de organizacao e nao um paradigma de fato. Algo como:Inicio campeonato se(Vitoria(Galo) ==true) faca escreva(Galo campeao!!!) fimdosefim campeonatoOnde:Vitoria(time) { ganha = true}Que executaria:Inicio campeonato se( Vitoria(time) { ganha = true }==true) faca escreva(Galo campeao!!!) fimdosefim campeonatoEmbora eu tenha sido o deus do como fazer, botaram o Flamengo no o que fazer e o meu galo ficou a deus dara. E mesmo sendo um deus, me frustrei. Isto por que, por mais que possa controlar o destino de uma variavel, alterando o seu valor, ela ainda sera uma variavel, variante...Depois de uma breve e singela pincelada sobre paradigmas e linguagem imperativa, vamos passar a orientacao funcional, onde passamos a ser titas, o melhores amigos, tambem deuses, do homem.Vamos a nossa teogonia!Como esta analogia poderia ficar extensa com a infinidades de titas gregos, brinquemos apenas com Prometeu, um dos titas mais conhecidos. O que o cara fez, e o porque do castigo? Se ele foi castigado, eu deixando de ser deus tambem serei? Estou saindo do contexto, voltemos.Prometeu, segundo uma das lendas, foi dado a ele e seu irmao Epimeteu a tarefa de criar os homens e todos os animais. Epimeteu encarregou-se da obra e Prometeu encarregou-se de supervisiona-la. Na obra, Epimeteu atribuiu a cada animal os dons variados de coragem, forca, rapidez, sagacidade; asas a um, garras outro, uma carapaca protegendo um terceiro, etc. Porem, quando chegou a vez do homem, formou-o do barro. Mas como Epimeteu gastara todos os recursos nos outros animais, recorreu a seu irmao Prometeu. Este entao roubou o fogo dos deuses e o deu aos homens. Isto assegurou a superioridade dos homens sobre os outros animais. Todavia o fogo era exclusivo dos deuses. Como castigo a Prometeu, Zeus ordenou a Hefesto que o acorrentasse no cume do monte Caucaso, onde todos os dias uma aguia (ou corvo) dilacerava seu figado que, todos os dias, regenerava-se. Esse castigo devia durar 30.000 anos.Reparem a utilizacao do verbo atribuir, ou o que fazer. Tentando traduzir:function atribuirdom(bicho,[dons]){ bicho dom + atribuidom(dons - 1)}Por questoes obvias, esta expressao nao pertence a nenhuma linguagem de programacao especifica. Esta funcao atribui um do ao bicho, recursivamente, de acordo com a quantidade de dons que foram disponibilizados. O fato e: foi claramente indicado o que fazer, que no caso seria atribuir dom ou dons a um bicho qualquer. Isto e o paradigma funcional, um tratamento por avaliacao de funcoes matematicas. As funcoes podem ou nao possuir parametros, assim como podem ser parametros de outras funcoes. A definicao da funcao descreve de que forma ela sera avaliada por outra funcao. Por exemplo, Epimeteu tem a funcao de f{atribuirdons, sob a funcao f{supervisao de Prometeu.Como a funcao
f{supervisao retornou algo estranho a funcao f{ordem, de Zeus, este procedeu a funcao f{dilarecafigado. Brincadeiras a parte, o modo de compreensao a orientacao funcional nao e diferente do modo que funciona nosso pensamento. E bem provavel que pouca gente pensa orientado a objetos. E mais facil pensar orientado a funcao, uma vez agir (o que fazer), nos e sempre mais natural que pensar(como fazer).Nao tenho a intencao de ensinar esta ou aquela linguagem funcional. No momento, estou me dedicando a erlang. Este esboco foi originado na tentativa de compreender os principios de uma linguagem. O mais importante e compreender onde e quando utilizar. Parafraseando o pessoal da 37signals, se uma linguagem nao for boa para voce, nao a use. Vou continuar postando minhas analises de compreensao dos paradigmas, especificamente o funcional. Para terminar, alguns paradigmas a nao seguir:POG - Programacao Orientada a GambiarraPOF - Programacao Orientada a FalaciasPOMEE - Programacao Orientada ao Menor Esforco Educacional.Sugiram outras a nao se seguir.