"Quanto mais vc usar as funções e/ou comandos nativos da linguagem, melhor para o desempenho do seu sistema, prq ?? - Prq essas funções e comandos foram escritas em "C" e/ou Assembler ao passo que, as funções desenvolvidas por 3os. serão tão somente desenvolvidas no próprio Clipper o que obriga ao compilador a fazer um esforço dobrado para realizar as instruções contidas nessas funções não originais...."
Pondere um pouco mais a respeito. Primeiro que nem todas as funções do Clipper são em C ou ASM, e nem todas as funções de terceiros são desenvolvidas em XBase. Entendi perfeitamente o que o tal Vidal quis dizer. Mas discordo totalmente, mesmo levando em conta que esse "conselho" foi dado (imagino) numa época em que o "top" era o 486, talvez há 15 ou 20 anos. Avalie o pensamento dele no momento atual, em que as máquinas estão consideravelmente mais rápidas. Você talvez prefira achar que o conselho ainda é válido hoje em dia. Mas considere também que, no momento atual, há um componente a mais, que não pode ser desprezado, e cujo valor está em alta: a produtividade. Isso faz muita diferença.
De qualquer forma, e em qualquer tempo, eu jamais poderia aceitar o pensamento dele, pois mais me parece uma forma de engessar o programador.
Me veio à lembrança meu sistema GET. Totalmente modificado, ficou incrivelmente grande. Nada de C ou ASM. Apenas XBase. Mas acredite: além de ter ficado mais fácil e flexível, ficou também muito mais rápido que o sistema nativo do Clipper. Isso vai contra o que preconiza(va) esse autor. Aliás, eu até arrisco dizer que hoje em dia o pensamento dele deve ser bem diferente do que você leu naquele livro.
e disse mais... - "Os chamados comandos, aqueles que não são acompanhados dos parenteses, também são funções internamente a linguagem e são executadas de forma mais rápida ainda do que a função propriamente dita, isto porque ela é endereçada diretamente ao processador para a execução da tarefa sem que seja necessária uma preparação prévia a exemplo das funções aquelas acompanhadas dos parenteses..."
Que eu saiba, todos comandos e funções internos do Clipper são convertidos pelo compilador em opCodes, que deverão ser interpretados pela máquina virtual, o núcleo do Clipper, que é o mecânismo que vai passar os mnemônicos "executáveis" para o processador. A título de exemplo: numa função interna, os parâmetros são empilhados um a um, assim como o opCode da função interna (ou comando), e só então é disparada sua execução pela VM. Isso é natural no Clipper, no XHarbour, e o que mais usar VMs do tipo. Até na tecnologia .NET o esquema é semelhante.
Faça um teste: compile um PRG no xHarbour, apenas para gerar seu código equivalente em C. Não precisa gerar o EXE. Apenas abra o arquivo C resultante num editor qualquer e repare como é feito este empilhamento. No Clipper o esquema é o mesmo. Seja com um comando interno ou não.
Portanto senhores, não que eu seja contra a criação e utilização das "funções não nativas", digamos assim, até porque tbm as uso quando necessário, mais sempre que posso, uso aquilo que o Clipper já traz em seu pacote e, pelo memos até agora, não me arrepemdi.
Tudo é muito relativo. Se nos dias de hoje as máquinas já são mais do que suficientemente rápidas, qualquer latência adicional provocada pelo acúmulo de mais alguns comandos extras não será perceptível. Mesmo que dentro de um sub-sistema como o que criei, que é relativamente grande.
Mesmo assim, repare que a construção de um mecânismo (apenas em código XBase) como o que descrevi, traz uma grande vantagem, que até compensaria uma certa perda de velocidade, se tal perda existisse. Me refiro ao ganho de produtividade. Imagino que você notou que meu exemplo, na outra mensagem, tornou o trabalho de abertura de arquivos muito mais simples. Então, porque eu haveria de pensar em poupar código XBase, se pude fazer bom uso dele? Me tornei mais produtivo e meu código ficou mais barato e fácil de manter. E o cliente não vai perceber nenhuma queda de desempenho.
Aliás, uma analogia, para efeito de ilustração: código C. A maioria de nós sabe que C é uma linguagem de médio nível e é tão rápida quanto ASM, graças aos novos compiladores, super-otimizados. De fato, há quem diga que hoje em dia não é fácil encontrar programador ASM que consiga otimizar código melhor que um bom (e moderno) compilador C. Mas, ainda assim, há quem use C++, que é, a grosso modo, C acrescida do paradigma da orientação a objetos. Se você analisar com cuidado, vai verificar que OOP é uma excelente forma de matar o desempenho de um programa. O overhead produzido pelo código extra, que substancia a OOP, é incrivelmente alto. Ainda assim, há quem use OOP. E muito. Por quê?. Por conta dos dois fatores que citei: 1) as máquinas de hoje já são bem rápidas, a ponto de não percebermos queda de performance; 2) OOP traz um ganho de produtividade que compensa (muitíssimo) o seu uso.
Se os programadores levassem em consideração os conselhos deste tal Vidal ou se achassem que seu pensamento ainda se aplica aos dias de hoje, certamente ninguém usaria OOP em linguagem nenhuma.
Filosofias de trabalho à parte, dei minha opinião a respeito do seu ponto de vista, que tem todo meu respeito. Acho muito saudável que os colegas conheçam nossas diferenças.
[]'s
Maligno
http://www.buzinello.com/prg
PS1: Caso resolva perguntar: nunca li livro algum deste Vidal. Nem Ramalho. Aliás, nenhum sobre Clipper, nacional ou estrangeiro.
PS2: Não acho uma boa idéia levar tão a sério o que esses autores escrevem. Para quem vive de informações técnicas, como os programadores, o melhor é manter o senso crítico sempre bem aguçado, para podermos perceber o quê devemos aceitar ou descartar.
Se o comando era rápido num processador lento é óbvio que ele será muito mais rápido num processador mais rápido... Concorda ?? 
