| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Guido van Rossum: Planning is good and bad. If you know where you're going, planning is good. If you don't know what you'll encounter on the way, you should be more open-minded and improvisational. I certainly see a place for planning, but if the language forces you to plan everything, there may be trips you'll never undertake because it would require too much thinking ahead. Right... Nao sei sou so' eu, mas a impressao que eu tenho e' que esta afirmacao deveria ser precisamente ao contrario. Se um problema e' conhecido entao o nivel de planeamento necessario e' pequeno e/ou informal (ninguem faz um mapa todas as manhas para ir para o trabalho) -- mas quando o problema e' desconhecido entao e' necessario planear cuidadosamente (se conduzirmos de Lisboa a Paris temos certamente o cuidado de planear a rota). Planear serve precisamente para reduzir o risco, num dominio onde ja' os conhecemos (porque ja' resolvemos problemas semelhantes) o planeamento e' minimo -- num dominio onde os riscos sao desconhecidos certamente vamos ter o cuidado de os tentar reduzir 'a priori para minimizar as surpresas. A comparacao entre o Python e o Java em termos de "maintainability" tendo em conta apenas o numero de linhas de codigo tambem me parece algo ingenua... mas pronto, e' uma forma de promover a linguagem que ele criou. Parece-me que qualquer pessoa inteligente sabe ver para alem de uma comparacao feita em cima do joelho.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | | | Leitao, acho que fizeste confusão entre "saber como se vai" e "saber para onde se vai". O teu exemplo lisboa-paris é igual ao casa-trabalho neste último caso, porque em ambos sabes exactamente *para* onde vais. A diferença é que no primeiro não sabes *como* vais. Se o teu objectivo for sair de lisboa com destino algures ao médio oriente, qual é a planificação que podes fazer? Provavelmente vais pensar em demasiadas coisas que não se vão concretizar e deparar com muitas para as quais não estavas preparado. Quanto às linguagens que mencionas, eu tenho o (des)prazer de conhecer ambas bastante bem, e posso-te garantir que o python é de facto elegância em toda a linha. Agora, não posso dizer que seja mais fácil ou difícil manter uma ou outra, porque felizmente nunca mantive código de terceiros. Mas o conceito de "maintainability" baseado no número de linhas de código já não vem de agora, e não foi concerteza o GVR que o inventou para promover a sua linguagem. O número de linhas de código, além das tretas métricas do costume, pode significar simplicidade (logo facilidade de manutenção) quando em pequeno número em relação à funcionalidade. A ideia é que é mais fácil absorver pouco texto, ainda que mais complexo, do que dezenas de páginas de coisas simples. Por exemplo, este pedaço de código em C não é trivial, no entanto a maior parte das pessoas é capaz de entender o que faz em pouco tempo: main(){char*s="se ";printf("%c%c%s%s%x\n",s[0]-2,2+0[s],&1[s],s,61658);}
-- carlos |
| | | | | Leitao, acho que fizeste confusão entre "saber como se vai" e "saber para onde se vai". Parece-me ser o mesmo problema -- neste caso o Python e' uma boa ferramenta para prototipar "onde queres ir", mas isso nao quer dizer que nao devas tentar perceber o mais possivel "para onde vais". Ou seja, planear continua a ser uma fase importante.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | O que me pareceu desse comentário é que Python é para coisas em cima do joelho, pequenos programas, programas GPL sem limites de tempo e dinheiro, etc... em que não se precisa saber pôr onde se vai nem quanto tempo demora.
Infelizmente o mundo não é assim. A parte do planeamento é sem sombra de duvidas a parte mais importante em qualquer projecto TI. Não só os custos são muito menores em tempo e dinheiro no longo prazo, como sem plano não há aprovação do projecto. As empresas quando encomendam um projecto querem saber quanto custa e quanto demora e isso não é possivel calcular sem um bom planeamento. Tambem niguem dá dinheiro para um projecto sem ver um plano detalhado e de como se chega aos objectivos.
Pedro Esteves |
| | | | Não percebeste a coisa: o problema é que nunca consegues projectar tudo. A meio do caminho vais ter problemas (colando-me à analogia do Leitão, um furo, um acidente na auto-estrada, etc). Isto significa que tens de ter flexibilidade para lidar com o inesperado. Ou então vais replanear tudo cada vez que deres de caras com o inesperado.
O comentário inicial do Leitão deve-se (penso eu de que) ao facto de que o comentário do Guido pôr demasiado ênfase na flexibilidade em desfavorecimento do planeamento, porque estava demasiado ocupado a promover o Python face ao Java em vez de pensar no que está a dizer. ;-)
E sim, o Python é bom para coisas em cima do joelho. Mas não só. Afinal, o que te impede de planear o que vais fazer em Python? Ou noutra linguagem qualquer?
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | Não percebeste a coisa: o problema é que nunca consegues projectar tudo. A meio do caminho vais ter problemas (colando-me à analogia do Leitão, um furo, um acidente na auto-estrada, etc). Isto significa que tens de ter flexibilidade para lidar com o inesperado. Ou então vais replanear tudo cada vez que deres de caras com o inesperado. Nao... ate' pelo contrario -- o planeamento ajuda a compreenderes melhor o que fazeres no caso de acontecer o inesperado (e' uma area chamada risk management e contingency/mitigation planning).
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded." |
| | | | Eu não pretendia dizer que flexibilidade e planeamento são mutualmente exclusivos.
Estava mais a falar em, uma vez encontrado um problema inesperado e teres determinado uma solução para ele, tens ou não a flexibilidade para fazer o que tem que ser feito? Ou vais ter de repensar e refazer uma boa parte do trabalho?
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | Pegando de novo no exemplo das estradas, no caso do Python, se uma das estradas planeadas se encontrar fechada, podes com facilidade recuar e seguir noutra direcção, no caso do Java(dependendo da quantidade do código já existente que interage com o que se está a fazer) , será mais díficil isto acontecer, porque provávelmente vai haver um numero enorme de alterações que podem levar a que haja mais bugs.
Básicamente o que digo é que é bom planear, mas é bom usar uma linguagem que permita que se houver mudança de planos as perdas não sejam muito grandes.
No woman ever falls in love with a man unless she has a better opinion of him than he deserves. |
| | | | | Básicamente o que digo é que é bom planear, mas é bom usar uma linguagem que permita que se houver mudança de planos as perdas não sejam muito grandes. A linguagem nao me parece ser a melhor forma de atingir "reusabilidade" (que e' o que parece estares a sugerir). Utilizacao de paradigmas OO, desenvolvimento por componentes, etc parecem-se ser factores mais relevantes.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Neste caso não se estava a falar de reusabilidade de código, mas sim de flexibilidade (ou adaptabilidade). Usar componentes como dizes, ajuda bastante, mas pode não chegar. No caso do java, a linguagem suporta (i.e. facilita) uma série de conceitos/paradigmas úteis, mas claramente não chegam. Se eu uso uma interface para modelar xpto, alterar essa interface significa alterar todo o código que toque na mesma. Em python isso é evitado. Este é claramente um dos tradeoffs dynamic-static binding. Outro dos tradeoffs é o java apanhar montanhas de erros em compile time enquanto o java rebenta em runtime, se por acaso uma determinada porção de código correr com um determinado estado das variáveis. Por isso coisas como "refactoring" ganharam nova vida com o java, enquanto coisas como static-code-coverage são mais apropriadas ao python (pychecker).
-- carlos |
| | | | Penso que o Guido Van Rossum se referia a um planeamento técnico e não ao planeamento burocrático, é sempre possível prever quanto se irá demorar a fazer algo, apesar de técnicamente não se ter ainda a certeza de qual o melhor caminho a tomar!
No woman ever falls in love with a man unless she has a better opinion of him than he deserves. |
| | | | Mas o conceito de "maintainability" baseado no número de linhas de código já não vem de agora, e não foi concerteza o GVR que o inventou para promover a sua linguagem. O número de linhas de código, além das tretas métricas do costume, pode significar simplicidade (logo facilidade de manutenção) quando em pequeno número em relação à funcionalidade. A ideia é que é mais fácil absorver pouco texto, ainda que mais complexo, do que dezenas de páginas de coisas simples. Há uns tempos li este artigo muito porreiro do Eric Raymond, onde ele diz que o Python, embora à primeira vista pareça algo *esquisito* (afinal de contas, a identação é significativa), é óptimo para manter e para construir aplicações gandes (ele chega a afirmar que é bem melhor que Perl para grandes projectos). Tudo isso pela sua simplicidade sintáctica... Outra coisa que me pareceu muito interessante foi que o Python aprende-se muito depressa e rapidamente se programam as coisas bem e à primeira: hat was my first surprise. My second came a couple of hours into the project, when I noticed (allowing for pauses needed to look up new features in Programming Python) I was generating working code nearly as fast as I could type. When I realized this, I was quite startled. An important measure of effort in coding is the frequency with which you write something that doesn't actually match your mental representation of the problem, and have to backtrack on realizing that what you just typed won't actually tell the language to do what you're thinking. An important measure of good language design is how rapidly the percentage of missteps of this kind falls as you gain experience with the language. When you're writing working code nearly as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features! Bem, isto é a opinião dele e cada um tem a sua.. Eu não tenho opinião, mas um dia gostaria de experimentar Python, uma vez que nunca tive oportunidade para isso e parece-me ser uma linguagem engraçada :) PS: Já alguém teve o privilégio de verificar o poder expressivo da linguagem funcional Haskell? Parece-me muito potente para prototipar e é muito engraçado programar em Haskell... :) Cumprimentos a todos.
|
| | | | Pessoalmente acredito numa abordagem mista: anarquia para desbravar o desconhecido e planeamento para fazer alguma coisa eficientemente e reprodutivel. Demasiado controle e tao nocivo como demasiada liberdade (sem ilacoes politicas, sff).
## I live the way I type; fast, with a lot of mistakes. |
| | | por Anonimo Cobarde em 24-02-03 18:09 GMT (#8)
|
| Não sei se sabes, mas a linguagem python é bastante utilizada na bioinformática (qualquer busca no google comprovar-te-á isso mesmo), e assim sendo, é uma linguagem bastante útil e poderosa em determinados projectos...
|
| | | | | Se um problema e' conhecido entao o nivel de planeamento necessario e' pequeno e/ou informal (ninguem faz um mapa todas as manhas para ir para o trabalho) -- Nao, mas como conhece o caminho sabe que pode levar o Audi TT e nao dar cabo dele. mas quando o problema e' desconhecido entao e' necessario planear cuidadosamente (se conduzirmos de Lisboa a Paris temos certamente o cuidado de planear a rota). Se sabes que vais de Lisboa a Paris *podes* planear a rota. E, se escolheres auto-estradas, podes levar o Audi TT. Mas se sais um fim de semana e não sabes para onde vais, o que dá mesmo jeito é levar um todo-terreno... se levas o Audi TT "there may be trips you'll never undertake because it would require too much thinking ahead". Ou entao davas cabo dele. Cumprimentos Mario Valente
|
| | | | | Se isto e' a coisa mais inteligente que consegues dizer, honestamente mais valia estares calado.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Ouch... tenho a impressao que a do Audi TT tocou nalguma parte mais sensivel. Desculpa lá mas pensei que estivesses no grupo "pessoa inteligente sabe ver para alem de uma comparacao feita em cima do joelho". Mas, é como diz a tua .sig: you win... Cumprimentos Mario Valente
|
| | | | | Quando a comparacao tem conotacoes obviamente pessoais por razoes que nao sao bem entendidas, deixa de ser feita a um nivel intelectual mas sim a um nivel pessoal. Mas ja' agora, gostava de saber o que e' que o Audi TT tem a ver com a conversa... tens alguma coisa contra Audi's ou contra mim ? E' que se for o ultimo caso podes meter as tuas opinioes "where the sun don't shine".
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Mas ja' agora, gostava de saber o que e' que o Audi TT tem a ver com a conversa... tens alguma coisa contra Audi's ou contra mim ? Nada, nem num caso nem noutro... mas prefiro de longe o meu carrinho a um para senhoras. Cumprimentos Mario Valente
|
| | | | | Quer dizer, conduzes um SLK (um carro unanimemente reconhecido como o favorito dos cabeleireiros), e achas que um TT reconvertido para 275BHP, e 0-100km/h em 5.7s e' para senhoras ?!? Right...
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Gostei do "unanimemente" :-).... e da homofobia declarada. Tenho a certeza que só continuam a abonar em teu favor. Garantidamente já perdeste um dos unicos votos (o meu) que tinhas para editor. Cumprimentos Mario Valente
|
| | | | | Garantidamente já perdeste um dos unicos votos (o meu) que tinhas para editor. Pfffff... espera ai, deixa-me ir ali ao canto chorar um bocado.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | Ora, esta parece uma resposta esperada de quem nunca programou a serio nem em Python nem em Java. Nem em C ou em Assembler. Como ja usei estas linguagens (e sao as que continuo a usar), nao posso de deixar de concordar com o Guido. Muitas vezes, o dominio do problema nao e perfeitamente conhecido. Nem Africa, o era, e la vei o Capelo Ivens fazer «De Angola a Contracosta» um lider de vendas. Nao creio que ele tenha planeado encontrar aquele leao no caminho. Francisco Colaço P. S. -- O Gama tambem nao tinha planeado encontrar a ilha dos amores (Lusiadas, Canto IX). O Autor tentou-a localizar no Indico, em Madagascar ou Diego Garcia, mas falhou rotundamente. Se alguem souber onde se encontra, faça o favor de divulgar pelo Gildot. Obrigado!
|
| | | | | Ora, esta parece uma resposta esperada de quem nunca programou a serio nem em Python nem em Java. Nem em C ou em Assembler. Define, "a serio"... Como ja usei estas linguagens (e sao as que continuo a usar), nao posso de deixar de concordar com o Guido. Muitas vezes, o dominio do problema nao e perfeitamente conhecido. Claro que nao, e nem eu disse o contrario. Mas o que ele diz (i.e., que quando o problema e' desconhecido mais vale improvisar do que planear) esta' simplesmente errado -- basta pensares em exemplos como o programa Apollo: o problema era desconhecido (ir 'a lua) e no que originou foi em muitas das disciplinas de gestao de projectos e de analise de risco que se usam hoje. Ou achas que eles limitaram-se a "improvisar" ?
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | basta pensares em exemplos como o programa Apollo São situações MUITO diferentes. Estamos a falar de casos em que nada foi deixado ao acaso e fez-se pagar por isso. Não foi somente planeamento, mas muita recolha de dados e simulações. Só para simular a entrada das cápsulas na atmosfera, usavam-se um carrinhos que deslizavam nuns carris com uma quantidade brutal de água despejada em cima. Acho que cada experiência dessas custava uma fortuna (só para a simulacao da entrada na atmosfera!). nao sao realidade comparaveis, IMO.
-- carlos |
| | | | | o problema era desconhecido (ir 'a lua) Mas o *objectivo* era conhecido. Por isso puderam planear. Cumprimentos Mario Valente
|
| | | | | Ok -- espera ai, entao estas a sugerir que voltando ao Python, quando se desenvolve uma aplicacao o *objectivo* nao e' conhecido ? Estilo, o Python e' uma boa linguagem para "escrever uma aplicacao, mas nao sei qual esta e'..." ? E' que nesse caso sugiro uns livrinhos de engenharia de software.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | E' que nesse caso sugiro uns livrinhos de engenharia de software. Depois de uns anos a lê-los, cheguei à bela conclusão que software não é engenharia, é arte. É mais arquitectura do que engenharia. E uma das coisas que me leva a tirar essa conclusão é precisamente o *objectivo*: não, na maior parte dos desenvolvimentos de software o *objectivo* total, final e completo, não é conhecido. Há sempre mais esta feature, mais aquela funcionalidade, mais outra possibilidade e mais uma ideia. O Python é bom para isso. Para artesãos, para artistas. Para os construtores civis^H^H^H engenheiros há de facto outras ferramentas; são mais robustas e mais sólidas, mas também mais restritivas e menos flexiveis. Cumprimentos Mario Valente
|
| | | | | Depois de uns anos a lê-los, cheguei à bela conclusão que software não é engenharia, é arte. De facto, sempre me pareceu que eras um artista (ate' conduzes um SLK)... mas passando 'a frente. É mais arquitectura do que engenharia. E uma das coisas que me leva a tirar essa conclusão é precisamente o *objectivo*: não, na maior parte dos desenvolvimentos de software o *objectivo* total, final e completo, não é conhecido. Gostei do teu paralelo com arquitectura -- software e' sem duvida uma mistura de arquitectura e engenharia. Mas se pensares bem, engenharia de software nao e' muito mais do que qualquer outra engenharia -- e' uma mistura de arte (conceptual) e engenharia (replicavel). *Mas*, a concepcao de muita gente quando se fala de software e' naturalmente "biased" devido 'a forma como o software e' aplicado e desenhado hoje em dia: os requisitos sao diversos, mal compreendidos e raramente identificados completamente. Quando constrois uma ponte ou um edificio acontece o mesmo, mas a um nivel muito mais reduzido: isto pois os humanos andam a construir edificios/pontes 'a milhares de anos, e software 'a 40 -- ou seja, ocorreu um processo natural de passagem de "arte" para "engenharia" no ramo da engenharia civil, mas (ainda) nao no ramo da engenharia do software. Ou seja, o facto de algumas pessoas considerarem o software uma "arte" -- deve-se ao facto de nao verem a "big-picture", daqui a 10, 20 ou 30 anos o software vai ser tanto uma arte como hoje e' considerado artistico construir frigorificos. E' uma questao dos processos e das ferramentas evoluirem. Repara que 'a 25 anos atras escrever software era restricto a um grupo pequeno de pessoas que tinham o conhecimento especifico para tal, enquanto hoje qualquer "artista" usa VisualBasic ou Python para desenvolver "software" -- daqui a 25 anos as praticas vao estar mais estabelecidas, e vai ser ainda mais facil/melhor compreendido como desenvolver software. O Python é bom para isso. Para artesãos, para artistas. Exacto! O Python e' bom para os artistas do software! Para o pessoal que ate' tem uma ideia do que anda a fazer (e acredita que sao muitos) existem outras ferramentas.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Leitão: vai-te foder. Cumprimentos Mario Valente PS - Plonk!...
|
| | | | | Ok -- ja' vi que toquei o teu nervo artistico.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Ou seja, o facto de algumas pessoas considerarem o software uma "arte" -- deve-se ao facto de nao verem a "big-picture", daqui a 10, 20 ou 30 anos o software vai ser tanto uma arte como hoje e' considerado artistico construir frigorificos. A grande diferença a esta analogia é que um frigorífico com 25 anos era feito para durar, e um frigorífico de hoje em dia tem um tempo médio de vida de 5 anos. Daí que talvez o que se chama de produto de qualidade seja muitas vezes atribuido a produtos com um tempo de vida útil elevado.Claro que esta analogia fica um pouco inadequada quando aplicada a software. Voltando à arte, e uma vez que preferes dar a conotação negativa ao dizer que python é para "artistas", só te posso dizer que depois de ver alguns exemplos de software feito em python, acho que vou chegar ao pé do meu pai e dizer, "Pai, decidi, vou ser artista!". Já agora, estou curioso em saber que ferramentas usa o "pessoal que tem uma idea do que anda a fazer". É que assim pode ser que deixe de conduzir um belo e sonoro Mercedes 220D de 1974 e possa ter dinheiro para comprar um carrito de "artista" (ripo um NSU ro 80 ou um mais moderno Mazda RX7), já que em questão de carros prefiro sempre obras produzidas por verdadeiros artistas do que por malta que sabe o que anda a fazer. Esses não têm piada absolutamente nenhuma =)
|
| | | | | Voltando à arte, e uma vez que preferes dar a conotação negativa ao dizer que python é para "artistas", só te posso dizer que depois de ver alguns exemplos de software feito em python, acho que vou chegar ao pé do meu pai e dizer, "Pai, decidi, vou ser artista!". Percebeste-me mal -- o que estou a tentar explicar e' que as ferramentas (Python, Java, C/C++, Perl, whatever) nao interessam. O que de facto faz a diferenca e' o resto: a forma como uma organizacao/individuo faz uso do software e como o desenvolve. Os assuntos que me preocupam (e que infelizmente sao os assuntos ao que os "techies" nao ligam) estao um nivel de abstraccao acima da "ferramenta".
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | O que de facto faz a diferenca e' o resto: a forma como uma organizacao/individuo faz uso do software e como o desenvolve Pois, tal como eu te disse logo desde o inicio, tens estado sempre a confundir (ou será antes a misturar?) planeamento técnico com planeamento organizacional (coordenação). A frase que mencionaste do GVR era sobre planeamento técnico. Aquilo a que os "techies" ligam. E isso parece consensual que não pode ser completamente previsto (logo planeado) de antemão, excepto a custos incomportáveis. Quando inicias um processo de desenvolvimento de software sabes quantas classes java (por exemplo) vão existir? Ou coisas de mais alto nível, relacionadas com a arquitectura, como quantos interfaces, ou quantos EJBs? Se não, é porque não consegues fazer um planeamento técnico completo. É isso que muitos teóricos informáticos tentam fazer: antes de começarem a escrever uma linha de código, saberem quantas classes, quantas funções, etc vão ter. Escusado será dizer que acabam por fazer mais refactoring (==code rewriting assistido), ou mais provavelmente re-escrita pura e ter mais bloat code, porque não conseguiram prever coisas que surgiram durante o desenvolvimento por um lado, e por outro, previram coisas que adicionaram complexidade sem serem necessárias. Agora, se tentas meter ao barulho o projecto como um todo (e não apenas a vertente técnica), sim, deve haver um planeamento abrangente, mas que páre ao nível da concretização.
-- carlos |
| | | | | Acho que vamos ter que concordar em discordar ;-). Mas como achega, da minha experiencia o pleneamento/controlo nao para na concretizacao. Ate' pelo contrario.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Although in a sense Basic was aimed at the same audience, non-programmers using computers Humm... makes sense!
Finalmente uma explicação de porquê que hoje em dia existem tantos fans de VB, convém reparar que relativamente ao ABC ele diz "ABC was intended to be(...)taught to intelligent computer users who were not computer programmers or software developers" enquanto relativamente ao BASIC s só diz "(...)non-programmers using computers"
No woman ever falls in love with a man unless she has a better opinion of him than he deserves. |
| | | | Acho que o meu comentario poderia ser apenas "bla bla bla nothing new." mas, dada a possibilidade de uma audiencia menos conhecedora destes assuntos de linguagens vou acrescentar mais umas coisas.
1º Já existem linguagens "interpretadas" (porquê as aspas? R: o codigo pode ser compilado) mais maduras, com provas dadas, todas artilhadas com "namespaces" (aka modulos, packages ...), macros (há macros em python?), baseadas em objectos (linguagens exclusivamente OO que deram inicio às interfaces como as conhecemos hoje: smalltalk), com garbage collection (nao, nao foi inventado para o java ou para o .Net, ja existia), etc, etc, etc... (ex: common lisp)
2º ja existem linguagens que compilam codigo tao bom ou melhor que um compilador C (com isto quero dizer que geram ASM tao ou mais eficiente), sem ser necessario declaraçoes de tipos para prototipagem rapida (claro que para ter codigo eficiente é preciso declarar os tipos ;)), programaçao exploratoria, programas de alta complexidade, ... (ex: common lisp uma vez mais)
conclusao:
Para quê re-inventar a roda?
E perguntam voces: se ja existe um "common lisp" que faz isso tudo porque é que nao é mais usado?
R: http://www.franz.com/success/
http://www.lispworks.com/products/success.html
Estao ai clientes como a nasa, ESA e afins, ha empresas a fazer jogos para PS2, muita coisa de IA (a linguagem é bastante usada em IA),etc... Claro que também tem defeitos, ha tradeoffs em tudo... mas nao vale a pena estarem a re-inventar coisas que ja estao inventadas, mudando-lhes apenas o nome. Portanto, pela minha parte, DISPENSO ler sobre tentativas de re-invençoes
sentriun
|
| | | | | | | Sem querer tar a aprofundar a discussão em torno de linguagens de programação pois o meu conhecimento de Common Lisp é praticamente nulo, queria apenas comentar a tua afirmação sobre "reinventar a roda" Pois eu fico muito atento a re-invenções, aliás sou adepto delas. eu compreendo o que queres dizer com o re-inventar a roda, mas não me parece adequado, pois não se está a tentar re-inventar a programação, muito pelo contrário, no caso de Python tenta-se criar uma linguagem de programação com bases profundas noutras linguagens mas que tente trazer o que de melhor existe noutras linguagens. Claro que não quer dizer que será perfeita. Seguindo a tua associação de ideias (e chegando ao exagero), para quê programar em algo que não seja pura linguagem assembler. O interesse do aparecimento de novas técnicas tem na maior parte dos casos o objectivo quer de facilitar a vida a quem usa uma dada tecnologia, ou então de adicionar novas características de acordo com novas situações. A tua ultima questão é no entanto estranha. Ora se já temos sapatilhas que nos permitem andar em todo o tipo de terrenos, porque não usamos sapatilhas em todo o lado? Uma ferramente all-in-one não é a ferramenta adequada para todo o tipo de trabalhos. Trabalhos específicos requerem ferramentas específicas. Daí que talvez para areas de IA como dizes o common lisp esteja mais divulgado e seja mais utilizado mas por exemplo nas áreas das matemáticas e físicas ainda haja muitos adeptos de fortran. Agora, uma vez que afirmas que python é a re-invenção de outra linguagem, apenas mudando o nome, peço-te que me digas qual é essa linguagem.
|
| | | | Vou tentar responder de forma curta e directa.
" ...pois não se está a tentar re-inventar a programação, muito pelo contrário, no caso de Python tenta-se criar uma linguagem de programação com bases profundas noutras linguagens mas que tente trazer o que de melhor existe noutras linguagens."
O que eu quis dizer foi que os conceitos que o autor do python publicita, já existem noutras linguagens que já deram provas da sua eficiência nas areas que ele publicita.
" A tua ultima questão é no entanto estranha. Ora se já temos sapatilhas que nos permitem andar em todo o tipo de terrenos, porque não usamos sapatilhas em todo o lado? Uma ferramente all-in-one não é a ferramenta adequada para todo o tipo de trabalhos."
Nao disse que lisp fazia tudo. Disse que lisp fazia tudo o que o python faz ;) (nao no sentido turing complete, mas no sentido de fazer eficientemente o que o python se propoe fazer ou seja, uma linguagem interactiva, de desenvolvimento rapido, com a possibilidade de ser eficiente.)
Quanto ao nome acho que está mais que respondido ;)
sentriun
|
| | | | | "O que eu quis dizer foi que os conceitos que o autor do python publicita, já existem noutras linguagens que já deram provas da sua eficiência nas areas que ele publicita." Ok, então fui eu que entendi mal. Mas isso é perfeitamente normal, até me lembro de estar a assistir a uma apresentação da plataforna .net no auditório da minha faculdade onde basicamente ele falava de toda a estrutura .net (bytecode, virtual machine, bla bla) como inovadora, até que lhe perguntaram o que é que isso trazia de novo em relação a java =) Em relação a isso como disse não posso falar uma vez que o meu conhecimento de list é muito pequeno. Bem, uma coisa posso dizer, um código de python é bem mais agradável de ler que um de lisp =)
|
| | | | - A roda dentada é uma reinvenção da roda e não deixa de ser extremamente útil por isso ;)
- Também há histórias de sucesso com Python. O Zope é talvez a mais famosa (e não é um pequeno projecto de programação de scr1pts em cima do joelho): http://www.zope.org
- Nunca usei Lisp nem nenhum dos seus dialectos. Mas há quem o tenha usado e mesmo assim considere o Python como linguagem a utilizar para alguns dos seus programas. Como o Eric Raymond: http://www.linuxjournal.com/article.php?sid=3882
Cumps.
Antonio Manuel Dias http://maracuja.homeip.net - hold fast to the one noble thing - |
| | | | | Já agora, mais uma achega. O "common lisp" não faz *tudo* o que o python faz. Por exemplo, não há um binding de common lisp para Qt, nem para GTK+.
Eu sei que são exemplos rebuscados, mas provavelmente a biblioteca standard do python (da qual não fazem parte as bibliotecas que referi) têm alguns exemplos como esses, e esses exemplos demonstram uma característica que diferencia as duas linguagens:
O python é uma linguagem cuja implementação principal é software livre (sob GPL) e com uma larga base de programadores a colaborar no seu desenvolvimento.
Cumps.
Antonio Manuel Dias http://maracuja.homeip.net - hold fast to the one noble thing - |
| | | | "Já agora, mais uma achega. O "common lisp" não faz *tudo* o que o python faz. Por exemplo, não há um binding de common lisp para Qt, nem para GTK+."
http://www.cons.org/cmucl/ports.html
|
| | | | Binding para GTK+ -- estamos sempre a aprender. Tks.
No entanto, após uma consulta rápida ao site, vejo que o meu argumento tem alguma razão de ser. Basta tomar como exemplo a documentação on-line das bibliotecas das duas linguagens:
http://cvs2.cons.org/ftp-area/cmucl/doc/cmu-user/
http://www.python.org/doc/current/lib/lib.html
Esta diferença não se pode atribuir objectivamente às características da linguagem, mas a quantidade de módulos da biblioteca standard do python diz bem da quantidade de programadores envolvidos no seu desenvolvimento.
Cumps.
Antonio Manuel Dias http://maracuja.homeip.net - hold fast to the one noble thing - |
| | | por Anonimo Cobarde em 25-02-03 14:27 GMT (#30)
|
| | ...há tradeoffs em tudo... Para mim, este é o busílis da questão. Conhecendo Smalltalk, Lisp, Pascal, C, C++, Perl, sh, awk, TCL, forth, e outras, creio que o Python conseguiu uns "tradeoffs" muito interessantes. Durante muitos anos usei Perl para scr-i-pting: eficiente qb, muito expressiva, mas torna-se muito difícil alterar um programa de 100 linhas ao fim de seis meses. Neste momento, recorro ao Python sempre que faz sentido usar uma classe. Tive de ultrapassar a questão da sintaxe; tal como a do Smalltalk, torna-se incrivelmente natural com o uso, coisa que por exemplo o Perl nunca conseguiu. E a biblioteca do Python começa a ser completa em algumas áreas. Embora o Perl tenha o completíssimo CPAN, a verdade é que o Python lida muito melhor com programas acima de 100 linhas. O Python é menos eficiente que o Perl; mas o meu computador actual é mais rápido, compensando perfeitamente os ganhos na minha produtividade! pxquim@clix.pt PS: Quem acha que scr-i-pting se escreve com 1 a ponto de martelar as submissões era melhor que se fosse entreter com pr0n ou, melhor ainda, com a vizinha do lado.
|
| | | | | I am sorry. Isto apesar de não fazer a mínima idéia como o 1 substituiu o i na tal palavra. Reparei logo nele quando reli o post depois de publicado, mas acredita: é um bug, não uma feature. Escrevo muito pouco para o gildot, muito pouco mesmo, mas se fizeres uma pesquisa por todos os meus posts vais ver que não encontras nada semelhante. Aliás, mesmo abreviaturas uso pouco. Também porque escrevo pouco para aqui, não sei o que queres dizer com martelar as submissões. E porque não costumo usar esses maneirismos na minha escrita, também não estou a ver o que é um pr0n (anyone?). Quanto às minhas vizinhas do lado, uma ainda não tem idade para essas coisas; a outra já não tem idade para essas coisas :) Cumps.
Antonio Manuel Dias http://maracuja.homeip.net - hold fast to the one noble thing - |
| | | | PS: Quem acha que scr-i-pting se escreve com 1 a ponto de martelar as submissões era melhor que se fosse entreter com pr0n ou, melhor ainda, com a vizinha do lado.
Talvez devesses saber que isto é uma feature do slashcode para evitar inserções maliciosas de código, e não martelanços de submissões ou cousas do género
Um pouco de delicadeza ficava-te bem....
Ou então não estou estou a entender a razão deste P.S.
Yours,
McB!
They told me it need Windows 95 or better, so I chose Linux |
| |
|
