| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Outro paradigma que vejo sendo pouco explorado nos últimos tempos é o do scr1pting, o uso de uma linguagem tipo tcl/python/ruby, mas não sendo usada sozinha, porém em conjunto com o C, servindo de "cola" para unir funções C, ferramentas já prontas no sistema, ou bibliotecas já existentes, criando uma aplicação realmente de "mais alto nível".
Não te esquecestes do perl? conhecido como the swiss army knife (ou swiss army bazooka para os mais extremistas) 'e uma das lingugens "cola tudo" por excelencia, e muito utilizada também.
Pessoalmente utilizo-a para scr1pting, front ends, servidores soap, web (adoro o embperl).
Poucas linguagens dao tanta liberdade ao programador como ela, poucas tem um suporte tão alargado e um conjunto de modulos disponiveis para todo o tipo de problemas.
Z
|
| | | | | por Anonimo Cobarde em 14-06-02 13:29 GMT (#2)
|
| Desculpe-me. Evidentemente perl é uma alternativa bastante popular, apesar de pessoalmente não gostar muito dela por produzir programas "read-only". Outra que a cada dia se torna mais presente, é o PHP, projetada mais para aplicaçõés web/cgi, mas bastante difundida. Acho também interessantes linguagens que se parecem com o C, como o ICI, inclusive para uso didático. É uma espécie de C com cara de "basic" :)
Rildo Pragana
|
| | | | não gostar muito dela por produzir programas "read-only".
read only? q entendes por isso?
|
| | | | Acho que a ideia era dizer "write-only" :-)
|
| | | | | O perl parece mais um swiss army bunker... :^) Quer a nível psicológico e social (a malta "entra" nele e defende-se de todas as investidas do mundo exterior), quer a nível do código gerado (a linguagem é tão legível que as ideias que entram em código perl nunca mais de lá saem!). (Ok, concedo: O elemento de "bunker psicológico" existe para todas as linguagens; é uma característica das pessoas e não das linguagens: toda a gente defende a "sua" linguagem -- que apenas é "sua" porque calhou ser aquela que primeiro satisfez as suas necessidades.)
|
| | | Java. (Pontos:4, Informativo) |
| | | Uma das facilidades introduzidas pelo C, o uso de ponteiros, é inexistente no java, por se considerar "perigosa". O Java tem "references" -- que esta' muito perto de ponteiros. De resto existem 1001 razoes porque OO e' um modelo "melhor" que "procedural languages" como o C. Aconcelho-te a ler o "Design Patterns".
echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP'|dc
|
| | | | | | O Java tem "references" -- que esta' muito perto de ponteiros.(...)
No método de passar parâmetros apenas, porque todos os restantes benefícios (e malefícios) dos apontadores ficam para trás.
(...)De resto existem 1001 razoes porque OO e' um modelo "melhor" que "procedural languages" como o C.(...)
Ai sim? Dá exemplos dessa superioridade. Se te referes á encapsulação que é o argumento mais frequente (entre outros) nos defensores da OO desiste porque a encapsulação é uma necessidade que atravessa qualquer linguagem e a imposição sintactica é um benefício altamente discutível. Mas estou aberto a que me provem o contrário.
-- Carlos Rodrigues
|
| | | | | Ai sim? Dá exemplos dessa superioridade. Se te referes á encapsulação que é o argumento mais frequente (entre outros) nos defensores da OO desiste porque a encapsulação é uma necessidade que atravessa qualquer linguagem e a imposição sintactica é um benefício altamente discutível. Mas estou aberto a que me provem o contrário A vantagem do OO nao tem nada a ver com os mecanismos da linguagem -- mas sim com o paradigma de desenvolvimento e arquitectura. Perl e PHP teem um pseudo-suporte de OO e no entanto ninguem os usa -- razao ? Porque Perl e PHP nao sao normalmente usados para sistemas muito complexos. Por alguma razao e' que as ferramentas de CASE surgiram maioritariamente com o surgimento do OO, e tambem porque o paradigma OO adapta-se bem 'a automacao do software.
echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP'|dc
|
| | | | Não tenho formacao de programador.
A minha escolha da linguagem/paradigma de programacao esta quase sempre condicionada por factores externos. O principal deles é a pré-existencia de codigo já testado, a disponibilidade de compiladores ou interpretadores para a plataforma em causa ou a ausencia de /bindings/ para a minha linguagem favorita.
Pessoalmente prefiro o paradigma OO, indo a minha perdileccao de linguagem para o c++, que permite uma simbiose entre OO e procedimentos. Est simbiose permite usar o melhor dos dois mundos. A relativa compatibilidade do c++ com o c e um bonus nao desprezavel.
--- |
| | | | | O PHP não é considerado scr1pting? Acho que é das coisas que está mais na moda para webdesign, já para não falar de ASP que não sei bem se será considerada uma linguagem de programação também...
"Se vi mais além do que outro, é porque estava nos ombros de gigantes."
Sir Isaac Newton
|
| | | | | No artigo fala-se em limitação do Java por não ter ponteiros como no C... Eu vejo isso como uma vantagem e não estou a ver nenhum caso em que fique mais limitado por não os ter... Acho que o Java "obriga" os programadores a escreverem melhor código... Sobre o paradigma de scr1pting, não creio que esta designação exista.
A maioria das linguagens enunciadas são procedimentais (imperativas): perl, php, etc. As linguagens de programação podem ser divididas em 4 grandes paradigmas: lógico, funcional, procedimental e orientado a objectos. Mas há muitos outros.
|
| | | | | | Desde quando é que retirar uma carecteristica é uma vantagem?
Se ela estiver lá, podes escolher utiliza-la ou não, se ela não estiver, só tens mesmo a segunda hipótese!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
| | | | A partir do momento que essa "carecterísristica" ( cof cof cof ;) ) , provoca 99.9% de todos os erros , bugs e afins que eu conheço desde que programo ...
Embora prefira de longe C a Java para os trabalhos que mais gosto de fazer :)
|
| | | | Então podes não a utilizar, mas quem preferir utiliza-la tem essa opção!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
| | | | "Desde quando é que retirar uma carecteristica é uma vantagem?"
A questão não é essa! Java não retirou essa caracteristica, simplesmente a "escondeu", tornando-se invisivel para o programador.
|
| | | | É exactamente um dos motivos porque gosto de utilizar o Linux é que regra geral nada fica escondido para quem souber como lhe aceder!
Se penso assim em relação aos SO's porque pensar diferente em relação às linguagens de porgramação?
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
| | | | Mas então nesse caso levanta-se outra questão, que é a da produtividade!!
Mas acima de tudo, C e Java são linguagens diferentes, com objectivos diferentes, não sei se será muito justo este tipo de comparações.
|
| | | | Linux, como qualquer OS que eu conheça (bom, os exo-kernels talvez sejam a excepção) esconde o sistema sob abstracções.
Um disco rigido é representado pela abstracção block device (à uns tempos por acaso li qualquer coisa sobre a necessidade de dar ao driver dos filesystems mais informação e controlo sobre a localização fisica dos dados).
C também fornece uma abstracção do CPU. Se precisares de ir mais baixo, usas assembly.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | Atenção que eu disse "regra geral nada fica escondido para quem souber como lhe aceder" não sou contra o facto de haver uma "abstraction layer" mas sim contra o facto de não haver maneira de lhes dar a volta!
Tu podes pôr bocados de código asm, no meio dos teus programas em C, o C permite-te isso!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
| | | | | Retirar uma característica é uma vantagem sempre que tenhas que ler código escrito por outros, pois nesse caso não depende de ti usá-la ou não e acabas por ter que aprender e dominar todas as maneiras malucas de fazer coisas que o autor da linguagem se lembrou de implementar. Parece mentira, mas ter muitas opções nem sempre é bom.
|
| | | | Se o autor original resolveu utilizar essa característica da linguagem é porque lhe pareceu vantajosa, provávelmente se ela não existir ele vai escolher outra linguagem para o fazer!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
| | | Hein? (Pontos:3, Interessante) |
| | (...)Acho que o Java "obriga" os programadores a escreverem melhor código...(...)
Isto não é uma Good Thing(tm) no meu entender e no que respeita à programação. Deviam ser as técnicas e a disciplina a obrigar a escrever melhor código e não a linguagem a restringir o que deve ou não fazer. Mas se calhar isto sou só eu a querer acreditar que o meu curso vai servir para alguma coisa e que não vou ser preterido em favor de mouse-engineers de VB e pseudo-programadores mal formados incapazes de se impedir a si próprios de dar um tiro na cabeça com features de certas linguagens, até nos casos mais óbvios.
-- Carlos Rodrigues
|
| | | | | Então não é? Se me faz escrever melhor código, mesmo quando eu sou um tanso que não sabe programar, não dignifica a linguagem, por ter a capacidade de turnar burros em programadores capazes de talvez fazer algo de jeito? Se a facilidade de a usar, aliada ao facto de a sua estructura me alicia/ensina a estructurar bem o meu código e me faz programar melhor do que eu seria capaz sem essas caracteristicas, então...
É sem sombra de dúvida uma coisa boa. Agora a outra dúvida é se a minha potêncialidade como programador experiênte e com um curso superior em cima deve ser desperdiçada a programar, quando um mouse-engineer com dois dedos de testa e uma linguagem de programação que é uma "Ama-seca" são capazes de fazer o mesmo que eu faria.
Mas aposto que existem outras mil coisas onde o mouse-engineer nem sequer se atreve a fazer e no entanto um jovem com um canudo porreiro, está nas suas sete quintas. Além disso, o mouse-engineer pode saber programar nessa linguagem, mas sequalhar não sabe porque é o que lhe mandaram programar se faz na dita linguagem. E tu, com curso, provavelmente foste tu a decidir isso. Já que és tu quem sabe decidir o que deve ou não ser feito na dita linguagem, ou noutra qualquer.
Miguel F. M. de Sousa Filipe handle: m3thos email: mmsf@rnl.ist.utl.pt More Human than Human.
|
| | | | (...)quando um mouse-engineer com dois dedos de testa e uma linguagem de programação que é uma "Ama-seca" são capazes de fazer o mesmo que eu faria.(...)
O problema é que pelos trabalhos de sapateiro (com o devido respeito aos sapateiros) que se veem por aí, eu ainda não estou convencido que as features de ama-seca realmente resultem para alguma coisa sem ser para se ficar com algo que funciona mal e porcamente e que na maioria das vezes poderia ser feito em menos tempo e com melhor qualidade por quem não precisa de amas-secas. É que as vezes penso se RAD não quer dizer Reles-Application-Development Mas isto sou só eu a puxar a brasa a minha sardinha.
-- Carlos Rodrigues
|
| | | por Anonimo Cobarde em 14-06-02 17:04 GMT (#10)
|
| Eu tambem nao sou fa de orientacao a objetos, mas que eh util eh, para aqueles que aprenderam a pensar orientado a objetos. Tanto eh verdade que os inventores da ideia de OO ganharam o Turin Award do ano passado, pela sua contribuicao para a computacao.
|
| | | | | | (...)os inventores da ideia de OO(...)
Isto é importante, o OO é uma ideia e não necessáriamente uma característica da sintaxe de uma linguagem.
-- Carlos Rodrigues
|
| | | por Anonimo Cobarde em 14-06-02 17:17 GMT (#11)
|
| | | | | | | É um GRANDE excesso! (neste caso, de parentesis) :-)
|
| | | | (...)Entretanto, o que se vê é que se uma linguagem ou ferramenta não suporta OO, está praticamente descartada do arsenal do programador moderno. Por exemplo, comparemos C e C++. Com C puro, conseguimos escrever a maioria dos programas livres que aí estão, sem precisar de usar as extensões que o C++ proporcionam.(...)Uma das facilidades introduzidas pelo C, o uso de ponteiros, é inexistente no java, por se considerar "perigosa".
x = *shoot_myself_in_head;
Os apontadores são definitivamente uma arma carregada e se não forem tratados com cuidado podem estourar muitas cabeças. Penso que o Java até é uma linguagem bastante bem pensada (apesar da sua biblioteca de classes estar em constante fluxo) e a ausência de apontadores é nela uma Good Thing(tm). Porquê? Porque o Java não é uma linguagem de programação de sistema, é apontada ao desenvolvimento de programas mais "business logic" rapidamente. Em muitos campos a sua lentidão torna-se evidente e as funcionalidades destinadas a proteger os programadores dos bugs mais frequentes tornam-se entraves muitas vezes exasperantes. Ter que circundar restrições da linguagem é logo sinal que já se devia estar a usar outra. Mas há muita gente que ainda se guia por aquele lema de se temos um martelo suficientemente grande todos os problemas são pregos.
C
O C é definitivamente a minha linguagem favorita pois dá liberdade para fazer o que é preciso (incluíndo dar um tiro no pé) sem ser demasiado baixo-nível e não deixa de ser uma linguagem elegante dentro do seu estilo. Mas tal como eu dizia acima, é bonito mas não serve para tudo, é sempre preciso adequar as ferramentas aos problemas.
C++
O C++ é definitivamente a linguagem mais horrível alguma vez desenhada (ok, é altamente discutível se foi mesmo desenhada) pois parece um amontoado de funcionalidades muitas vezes contraditórias. Além disso é sempre chato quando certas funcionalidades da própria linguagem podem gerar bugs sem que o programador se dê conta (memory leaks com operator overloading é um exemplo). Acho que durante o desenvolvimento do C++ se entrou numa loucura desenfreada por incluír tudo e mais alguma coisa achando que mais é melhor, acabando com uma linguagem overkill.
Mas curiosamente o C++ até é a minha linguagem de eleição a seguir ao C (e a primeira em OO) porque se se escolher um subset com o qual se consiga fazer tudo até se torna uma linguagem bastante elegante (o operator-overloading é algo que fica imediatamente de fora, quando eu faço a + b quero poder ler o código e saber o que faz o + imediatamente sem ter de vasculhar documentação (a ausência propositada no Java é um ponto a seu favor).
(...)As linguagens funcionais, e também as derivativas do prolog (lógicas), também estão impopulares, apesar de muitas delas terem atingido um grau de eficiência muito próxima das linguagens imperativas.(...)
Prolog? Naaa....
Impopulares no mundo real porque no mundo académico estão mais fortes que nunca, principalmente as declarativas.
Este tipo de linguagens são muito populares no meio académico porque são mais formais, mais limpas mas quando se trata de resolver problemas a sério são na maioria das vezes inadequadas. Tiro como exemplo o Prolog, que é um ódio de estimação meu (que nenhum professor meu leia isto). O Prolog é uma linguagem extremamente poderosa, que permite resolver mil e um problemas (definitivamente complexos) em meia dúzia de linhas. Mas é demasiado alto-nível para mim, eu gosto de programar e pode-se discutir se programar em Prolog é realmente programar, porque tal como eu li algures, para dar um tiro no pé em Prolog diz-se onde se quer acertar e ele por backtracking inventa a arma.
-- Carlos Rodrigues
|
| | | | | | PS: nunca recuperei do trauma do problema das torres de Hanói resolvido em Prolog em 3 linhas.
-- Carlos Rodrigues
|
| | | | Eu so uso o subset de c++ com o qual me sinto confortavel e que me causa menos dissabores.
Uso operator overloading quando me da jeito, mas evito-o como a peste em classes mais ou menos complexas visto poderem acarretar problemas de performance se nao se tem cuidado. Prefiro usar funcoes membros inline sempre que possivel.
Estou para testar isto quando tiver tempo:
http://www.oonumerics.org/blitz/
A publicidade diz que sao classes de matrizes e vectores, com performance equiparada ao fortran. Faz um uso extensivo de operator overload, templates e expression templates.
--- |
| | | | Lendo o teu artigo consigo encontrar pelo menos 10 (excelentes) razões para chumbares a PL! :-)
Matem-me, mas ninguém me consegue convencer que prolog não é uma linguagem para teóricos, pq é que há-de ser o compilador a escolher como fazer as coisas em vez do programador? Dá-me uma sensação de impotencia completa cada vez que olho para o prolog que nem imaginam (provavelmente tb por nunca ter assimilado bem a linguagem).
Conclusão, linguagem que não tem a instrução "return" não é linguagem :-)
Cumprimentos
|
| | | | prolog não é uma linguagem para teóricos
pois quando utilizas as funcionalidades restrictas da students o que e que pensas que estas a usar????
caso nao saibas algumas das coisas que este sistema faz "NÃO" são possiveis de implementar com uma base de dados relacional!!!
Cumps e vai fazer o trab de lp2!!!
|
| | | | (...)pois quando utilizas as funcionalidades restrictas da students o que e que pensas que estas a usar????(...)
Há com cada maluco... prolog como cgi... por isso é que aquilo não funciona lá muito bem na altura das inscrições, estão meia dúzia a usar o sistema e nem dentro da rede da faculdade se consegue usar...
(...)caso nao saibas algumas das coisas que este sistema faz "NÃO" são possiveis de implementar com uma base de dados relacional!!!
Como por exemplo... é que por trás daquilo está uma base de dados relacional.
-- Carlos Rodrigues
|
| | | | é por isso que na altura das matriculas as inscrições pela net estão limitadas à rede do campus...
Eficiência meu caro, para o que é que eu quero uma linguagem que me faz o trabalho de lp2, aed2 e compilação tudo sozinha e ainda tira cafés, mas que demora 6 meses e não pode chover nem haver lua cheia durante esses mesmos meses?
Resposta: Para rigorosamente NADA!
|
| | | | Não, isso é porque não são dezenas nas centenas de hits por minuto a utilizar cifragem forte e eles não compraram nenhum cluster dedicado para fazer aquilo..
depois eu prefiro esperar uns minutos em casa para me inscrever do que perder manhães, tardes ou dias para ficar nas filas ... mas pronto, pode haver alguém que prefira o convívio social que isso proporciona!!
Cumps
|
| | | | Não, isso é porque não são dezenas nas centenas de hits por minuto a utilizar cifragem forte e eles não compraram nenhum cluster dedicado para fazer aquilo..(...)
Errr, vários minutos para entrar na página... até parece o site do bigbrother há uns tempos.
A cifragem não puxa assim tanto processamento e os hits não são assim tantos mas mesmo que fossem um PC vulgar seria mais que suficiente para aguentar a carga, principalmente da rede interna. Das três uma ou os cgis deles são extremamente lentos, ou ineficientes, ou o miau é um 386.
Remember, somos só 6000 alunos e nem todos fazem as inscrições pela net.
-- Carlos Rodrigues
|
| | | | Lendo o teu artigo consigo encontrar pelo menos 10 (excelentes) razões para chumbares a PL!(...)
Como já fiz não corro esse risco agora IIA...
-- Carlos Rodrigues
|
| | | | | (...) Ademais, C é a linguagem de escolha para se escrever software de baixo nível, tais como device drivers, e é a mais usada no mundo do software livre. Qual o motivo dessa escolha? Eu diria que C, por ser mais simples, e ficar menos "no caminho do programador", é mais fácil de ser dominada, e portanto, o programador C em menos tempo torna-se produtivo.(...) Parte do motivo é porque C foi inventado ao mesmo tempo que foi o Unix (um pouco antes) e desde muito cedo existiram compiladores e outras ferramentas para C.
Outra parte do motivo é porgue as outras linguagens existentes não tinham compiladores com qualidade suficiente para a linguagem poder ser bem usada e ser rápida (ver na FAQ da Linux Kernel Mailing List porque é que o kernel do linux está em C)
Outra razão é sem dúvida porque C é uma linguagem que reflecte a genialidade dos seus criadores dada a sua simplicidade, flexibilidade e potêncialidade.. Também é verdade que programar em C é muito mais dificil do que o fazer em Scheme, Lisp, Java, bash. Isto é muito discutivel, mas quando usamos uma linguagem para um determinado fim, o tempo que se precisa para a dominar C é MUITO MAIOR... .. falo por mim, que tenho 3/4 anos de programação activa em cima. Digo isto porque tenho muito mais problemas com C do que tenho com Lisp ou Java, em que com a API de java disponivel ou o livro de Common Lisp ao lado, sempre acabo por fazer o que pretendo e dou poucos erros semanticos ou sintáticos... agora com C?
Epá, posso ter a biblia de C (the ANSI C programing language), as man pages, etc.. mas dominar a manipulação de ponteiros, gestão de memória, criar estructuras de dados, manipuladores, identificadores, e mais o raio que a parta... aliás.. muitos daqui devem saber o que é andar á caça de um segmentation fault, ou desvendar porque raio é que o pipe não está a funcionar(ainda estou por perceber..).. C por ser de baixo nivel é muito fléxivel e potente, mas isso torna-a mais dificil de ser dominada.
Java por exemplo por ser de mais alto nivel e de ter uma API para uso com bibliotecas ao dispôr, Gestão de memória e o facto de quando rebenta dar um backtrace MUITO fixe, facilita muito mais a vida a qualquer pessoa, é mais facil de aprender e mais facil de usar. Quem sabe java pode não saber C.
Mas quem sabe C certamente que se orienta com Java. Em relação a lisp/scheme, também têem a gestão de memória e de ponteiros, e por isso também facilitam as coisas. São muito potentes, estranhas para alguns, e muito loucas para outros, para mim, por serem muito diferentes de C em termos de paradigma, não dá pra comparar, cada uma tem a sua utilidade. Básicamente, em programação, não existe o "One Ring", nem uma excalibur, e muito menos Santo Graal, cada linguagem tem a sua utilidade própria, vantagens e desvantagens.
Embora ache que C é o autêntico Canivete Suiço da programação, fazer programas que já fiz em Java em C daria-me tanto trabalho que nem sei se conseguiria faze-lo em tempo util. Também não me passa pela cabeça fazer o que estou a fazer agora em java, ou em lisp.
E como é obvio, o projecto que fiz de IA, só considero a possibilidade de o fazer em lisp. C++, e de Perl, não falo porque não sei... ainda... mas dá-me a sensação que são linguagens incontornáveis(ou perto disso).
Prolog, PHP, C#, SQL, tcl, asp, Python, html, flash, Shell, Fortran, etc... enfim.. todas as linguagens e mais algumas devem ter o seu valor, umas mais do que outras, umas próprias para umas coisas, outras para outras, e ainda outras, apenas porque tinham mesmo de ser inventadas.. eheheh
Miguel F. M. de Sousa Filipe handle: m3thos email: mmsf@rnl.ist.utl.pt More Human than Human. |
| | | | | por Anonimo Cobarde em 15-06-02 3:58 GMT (#22)
|
| ...C foi inventado ao mesmo tempo que foi o Unix...
Na realidade o primeiro unix foi escrito em assembly (do PDP-5 se não me engano). O C foi criado como um assembler portável, porque a arquitetura das CPUs que vieram em seguida não possuiam words (palavras de memória) homogêneas para inteiros e "floating point". Mas isso não tem muita importância na discussão. Quanto a APIs o C tem sim, e muito mais que o java. Não é só a libc, mas um inúmeras bibliotecas para uma variedade de aplicações que você consiga imaginar estão disponíveis, além de interfaces para bancos de dados, multimídia, o X Window System (todo escrito em C e com APIs diversas como Xlib, Xt, etc, tudo pronto para ser usado), e muito, muito mais.
Quanto aos ponteiros, não são tão difíceis assim. Dê uma olhada no código do TinyCOBOL (meu projeto que tanto me orgulha, apesar de não ser nenhuma pérola de programação) e você verá ponteiros sendo usados nas mais diversas formas. A linguagem C suporta encapsulamento se você toma algum cuidado. Na verdade o mais importante é que a linguagem lhe dê flexibilidade, não fique no seu caminho. E que essa flexibilidade seja usada com responsabilidade. Nenhuma linguagem dispensa cuidados de uma fase de definição e análise do problema, escolha dos algorítmos mais adequados, etc. Não digo que se possa ser proficiente em C tão rapidamente (tenho mais de 25 anos de C) como, por exemplo, em pascal (que foi inventada para ser uma linguagem didática). Já programei em dúzias de linguagens diferentes (por exemplo, o depurador do precussor do TinyCobol, o escrevi em prolog; passei uns 2 anos programando em Smalltalk, o predecessor do Simula; algum contato com ML, Scheme...), mas sempre retorno ao C quando encontro um problema do "mundo real".
O que muda essencialmente de uma linguagem para a outra? Na maioria casos, o programador fica exposto às limitações das arquiteturas de Von Neuman, a quase totalidade das implementações dos computadores (Lisp machine, anyone? Is dead!). Ou seja, tudo é sequencial! Talvez um arquitetura neural venha mudar esse gargalo no futuro...
Uma mudança qualitativa que encontrei foi combinar uma linguagem de scr1pting com o C, com um aumento considerável na produtividade. Mas deixemos isso para uma outra discussão.
|
| | | | Espectaculo, que simplicidade....
E com isso acabaste de resolver 90% dos problemas de programação em C...
|
| | | | | Nao tenho tempo para uma resposta mais "calculada", vou de ferias :-). Mas nao queria deixar de comentar/rebater alguns pontos. Sucesso do Java ? Not! E o uso cada vez maior de OO languages nao seria com certeza devido ao "sucesso" do Java. Concordo que o OO não é o melhor modelo para *todos* os problemas a resolver programaticamente. Existem dominios (p.ex. AI) onde o modelo será preferencialmente outro. Mas, muito importante, o melhor modelo de ABSTRACCAO (factor fundamental em qq linguagem de programacao) é neste momento o modelo OO. Dai o sucesso das linguagens OO (e nao do "sucesso do Java"). Com C puro podemos de facto implementar qq dos programas livres que estao ai. Alias, com assembler puro tambem. E "na boa" fazemos o mesmo a ligar e desligar interruptores correspondentes a cada bit de RAM. Nao o fazemos porque nos dá jeito um nivel de ABSTRACCAO maior. O C tem alguma abstracao. Uma linguagem OO tem mais. Isto é como com uma piscina: tb dá para a despejar com uma colherinha de sobremesa... O C, "fácil de ser dominado" e "mais produtiva em menos tempo" ? Estas em que planeta ? Eu tenho 20 anos de programacao em cima, fiz um sistema de email distribuido com 50 mil linhas de codigo C e nem sequer me considero proficiente em C. O C é o Windows das linguagens de programacao: está lá, toda a gente tem, toda a gente conhece, resolve os problemas mais "populares" e há montes de livros sobre o tema. Para alem disso há montes de libs para fazerem o trabalho por mim e é mais kewl dizer "eu coding só em C" do que "eu actualmente estou a programar em Ruby". Da-me vontade de responder "entao se és tao macho faz lá um sistema pericial com um 'cat | as'. Isso é q é de homem de barba rija. C é para maricas...." Ponteiros: porque introduzir restricoes ao programador ? Porque é dificil, impossivel ou perfeitamente inconsequente pedir-lhe responsabilidades sobre a morte de um doente ou a queda de um aviao porque o gajo usou mal um pointer e gerou um Segmentation Fault num sistema mission critical. Algumas linguagens sao menos populares, como é o caso das funcionais que referes ou as de knowledge declaration (Prolog-like), porque têm aplicacoes em dominios especificos. Nao quer dizer que nao dê para fazer um sistema de gestao de salarios em Prolog. Ou em C (como referiste). Ou em assemble (como eu disse). O problema é que nao bate a bota com a perdigota. O modelo de abstraccao da linguagem nao bate certo com o modelo de abstraccao do problema. SCR1PTing: nao confundas "scr1pting" com um paradigma/modelo de programacao. Dentro do scr1pting tens tambem linguagens procedimentais, declarativas, funcionais, OO, etc. O facto de serem interpretadas em runtime (e nao compiladas) nao as torna num modelo à parte. Mas o que de facto fazem é, como referes, permitir criar aplicacoes de "mais alto nivel". Com um maior nivel de *abstraccao*. Qual a sua idéia sobre os paradigmas de programação? Qual é o problema para resolver ? Diz-me qual o problema e eu dir-te-ei qual o paradigma :-) A linguagem e o seu modelo/paradgima de programacao deve ser escolhida com um nivel de abstraccao identico ao nivel de abstraccao do problema. O resto é RTFM, chavetas, parentesis e pontos e virgula (ou nao, se usares Python :-) Cumprimentos Mario Valente PS - Nao queria deixar de referir que existem outros "paradigmas" mais recentes e com maiores niveis de abstraccao recomendando uma procura no Google por "Aspect Oriented Programming" aka AOP
|
| | | | | | | Sucesso do Java ? Not! E o uso cada vez maior de OO languages nao seria com certeza devido ao "sucesso" do Java. Planet Earth Calling Mario Valente. Java neste momento e' talvez a linguagem mais comunmente utilizada fora do mundo do "Visual Basic". Isso de Java nao ter sido um sucesso so' se for em Portugal.
echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP'|dc
|
| | | | | Podes fundamentar ? É que nao encontro em lado nenhum dados estatisticos concretos sobre a tua afirmação. Parece que, como eu, muita gente pensa o contrario. A fonte nao será a melhor :-) mas foi a unica que encontrei. Cumprimentos Mario Valente
|
| | | | | Podes fundamentar ? É que nao encontro em lado nenhum dados estatisticos concretos sobre a tua afirmação. Posso -- Vais ao Jobserve, e pesquisas o numero de ofertas de emprego de acordo com a linguagem. Hoje (18/06/2002) temos: - Java: 1869
- C: 1373
- Perl: 387
- PHP: 74
- Zope: 0
E' certamente uma melhor medida que um "rules/sucks'o'meter". Regards,
echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP'|dc
|
| | | | . C++: 2212 (19/06/02)
-- carlos |
| | | | De entre muitas coisas, no mundo real (fora do mundo académico) OOP serve para padronizar a programação baseada em componentes.
Quem questiona o interesse da programação por objectos, normalmente são pessoas que não compreendem a sua importância e muitas vezes protestam contra os que a defendem por se sentirem excluídos, devido à sua ignorância no assunto, de uma comunidade da programadores cada vez mais aderente a este paradigma.
|
| | | | | | A mim parece-me que o que se passa não é bem isso, uma grande parte do pessoal que programa em linguagens orientadas por objectos, é porque é só aquilo que conhecem, muitos porque começaram no VB, e grande parte deles não tiram partido do facto de estarem a utilizar uma linguagem OO.
Quanto à minha opinião, não tenho nada contra os objectos, gosto de os criar e utilizar quando acho adequado, mas não gosto destas linguagens em que todas as keywords ou funções da própria linguagem pertencem a uma determinada classe!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
| | | | | Boas, Ao ver esta discussão, lembrei-me de uma página que li, talvez já há um ano, em que um autor apresenta a sua visão das limitações da programação orientada a objectos: Object Oriented Programming Oversold!
http://www.geocities.com/tablizer/oopb ad.htm O mesmo autor tenta promover um outro conceito : Table Oriented Programming
http://www.geocities.com/tablizer/top.htm Espero que alguns possam achar a leitura destas páginas interessante. Eu, pelo menos, achei :) Como é natural, concordei com algumas coisas e discordei de outras. Mas, sobretudo, concordo com o que já foi aqui dito nesta discussão do Gildot: a natureza do problema é um factor importante (embora não o único) a ter em conta na busca da melhor solução e linguagem de programação.
Um abraço a todos, Ricardo |
| | | | Na minha opinião a única forma de escrever código bem escrito e a prova de bala, é recorrendo aos métodos formais de programação ( muitos só de ouvir este nome já ficam com arrepios, não sei porquê!). Com estes métodos podemos raciocinar sobre os problemas de várias formas, com esquemas e desenhos (não não é o UML!) mas sim desenhar programas, aplicando regras de forma a derivar novas soluções a partir de algoritmos existentes, aplicar construções como [cata|ana|hylo|para]morfismos, e outras, decompor algoritmos nos seus "genes", calcular programas, construir modelos (mais uma vez não é o UML), "pointfree programming", e muitas outras coisas. Se fossem utilizados de certeza que não existiriam tantos "bugs" a corrigir.
Não é o facto de usares a linguagem XPTO que te vai obrigar a escrever bom código, porque se quiseres escrever mau código podes escreve-lo à mesma.
Cumprimentos.
PS: Se o software que controla aviões/satélites/centrais núcleares/... não falha, de certeza que não é devido a bons programadores, daqueles que programam a "olho", mas devido aos métodos formais.
|
| | | | | Boas! Não sabes em que linguagem programar? Qual o melhor paradigma? Este artigo é a solução para o teu problema! Certamente já te disseram que se usares a linguagem errada para um dado problema, podes dar um tiro no pé! Agora já podes saber como na tua linguagem preferida! :-D
|
| | | | | Das 41 contribuicoes q estao na "pilha" se tirarmos as antigas/desactualizadas, as tipo "publicidade à socapa" e as que mandam uma bujarda qq sem links ou referencias ficamos com... 2 ou 3 tiradas das ultimas do Slashdot. Editores: não acham que está na hora de dar uma olhada naquela pilha de 50 contribuições e tentar arranjar umas 5 Leitores, nao acham que esta na hora de arranjar umas contribuicoes originais e com um minimo de sentido e de referencias ? Eu ja' dei a minha volta de hoje pelos sites do costume e.... a oeste nada de novo. Olha toma lá um link para a unica banda q me tem surpreendido nos ultimos tempos e q com sorte trás o rock de volta: Andrew W.K. Cumprimentos Mario Valente
|
| | | | | | Sem pretender ofender susceptibilidades, eu até preferia ver as ditas contribuições tipo "publicidade à socapa" e as que mandam uma bujarda qq em vez das cópia traduzidas das últimas do Slashdot.
Eu penso que se este site pretende ser comunitário, deveria reflectir mais a comunidade tal como ela é com publicidade à socapa e bujardas, do que tentar ser uma coisa que não é apenas com artigos de assuntos copiados de uma comunidade que não é a deste site.
Pessoalmente não me posso queixar porque todos os meus artigos foram aceites, mas imagino como todos aqueles que não tiveram essa aceitação devem estar a sentir uma certa ingratidão por terem tentado contribuir em vão.
Assim, a organização do GilDot acaba por passar uma imagem elitista em que apenas as contribuições de uns poucos priviligiados são aceites.
Suspeito que se a organização não tentar se orientar mais no sentido desta comunidade (não da do Slashdot que certamente não somos nós), mais tarde ou mais cedo algum outro site vai ocupar esse vazio que poderia ser ocupado pelo Gildot mas hoje em dia ainda não é.
Nota: Esta mensagem não é uma bujarda, mas apenas uma crítica apenas com intenção construtiva. Espero que seja vista como tal.
|
| |
|
