PC Toledo

Senhores participates do Fórum mais especificamente nesse tópico,

Se me permitem voltar ao assunto que, ao meu ver, a resposta já foi dada e diga-se, de várias formas, percebi ao longo das 13 respostas (até agora) dadas que o assunto acabou tomando um outro rumo do tipo "eu uso o USE" ou... "não use o USE use uma função" ou ainda... "não use função de 3os., faça vc mesmo a sua" e assim por diante... pois bem... não sei se os nobres colegas vão concordar comigo mas, como minha intenção é de colaborar digo o seguinte:

Há muito tempo atrás, quando o Clipper ainda era a linguagem do momento, me recordo de ter lido em algum livro do Antonio Rocha Vidal, um dos "papas" do Clipper no Brasil, alguns comentários dele a respeito de "comandos" e "funções" nativas da nossa nobre linguagem assim como falava também da possibilidade de nós mesmos, programadores, criarmos nossas próprias funções, libs etc... e nesse mesmo comentário ele dizia que: - "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...." 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..."

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.

Sendo assim... Eu uso o USE !!!

"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.

Bom dia Maligno e colegas.

Maligno, quando voce mencionou que não usava o comando USE, a principio, fiquei um tanto espantado mas, logo depois foi possivel entender a sua colocação.

Agora, novamente estou surpreso.....

Voce nunca leu nenhum livro sobre clipper?

Amigo Maligno,

Antes de qqr coisa, quero que saiba que para mim, sem nenhuma demagogia, você, juntamente com outros frequentadores como o Toledo, Vagner, Rochinha, Dudu-XBase e outros, que figuram entres os frequantadores deste Fórum, são os mais reispeitados e conhecedores do assunto a que ele se propõe, pelo menos no meu conceito por isso, me sinto lisonjeado em ter sido merecedor da sua resposta que, como não poderia deixar de ser, veio acompanhada de uma "aula" e era exatamente esse o meu propósito quando da minha colocação sobre a literatura por mim evidenciada, ou seja, provocar uma reação por parte de todos sobre o que cada um pensa em relação a nobre linguagem que tanto nos dá prazer.

Na realidade senti necessidade em expressar minha idéia sobre o assunto prq, ainda que eu não me faça presente com tanta frequencia no Fórum através de mensagens (perguntas e respostas), sempre que posso estou verificando os assuntos abordados e, por muitas vezes, obtive respostas sem precisar perguntar mais tbm observei que muitas vezes as respostas através de "trechos.prg" são quilométricas com trocentas linhas utilizando mil e uma funções "não nativas" que eu olho... analiso... verifico a eficássia do algorítimo e da lógica utilisados... e não consigo entender prq usar de tanto "conhecimento" e "tempo" quando a linguagem já trás em seu conteúdo "standard" digamos assim, que se bem usadas com apenas 10 ou 15 linhas farão a mesma coisa e com a mesma eficiência, talvez até mais... aí eu chego a conclusão que: O programador que construiu essa(s) função(ões) é muito bom !!! Só que não leu o livro até o final ou não consultou o manual nas páginas seguintes...

Questões como essa é que me levaram a "questionar" se as funções de 3os. são SEMPRE ou quase sempre necessárias em detrimento das nativas...

É fato que o livro foi escrito na época do lançamento do Clipper 5.01 portanto lá se vai algum tempo, não tanto quanto vc colocou mais... que seja. De tudo que vc disse eu concordo em grande parte, diria que "quase" na totalidade não fosse no tocante ao desenvolvimento tecnológico das máquinas de hoje em relação as de 15 anos atrás onde vc prega que não há mais necessidade de se preocupar com performance, produtividade etc... me desculpe e reflita comigo:
Se a preocupação com o desempenho (velocidade) já existia naquela época (AT, XT, 486, 586 etc) e para tal foram criadas funções e comandos capazes de terem um excelente rendimento naqueles processadores, o que elas não farão nos de hoje Se o comando era rápido num processador lento é óbvio que ele será muito mais rápido num processador mais rápido... Concorda ??

Bem... para encerrar, como vc mesmo disse ao final do seu colóqueo - "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." faço das suas minhas palavras...

Augusto, embora você tenha ignorado meu nome, dentre os que citou, farei um esclarecimento a quem se interessar.

Influenciado por um autor de livro ou por um mal compreendido texto dele, você vem afirmando que um COMMAND é mais rápido que o seu equivalente em FUNCTION.

Não posso me calar num momento deste, pois isto é uma grande inverdade.

Se você ainda não sabe, ao serem compilados pelo Clipper, todos os PRG são pré-compilados antes (arquivo PPO que pode ser observado usando -p) e neste processo todos os COMMAND são substituídos por seus equivalentes FUNCTION, como pode ser visto principalmente no STD.CH que é o mais usado dos arquivos .CH do Clipper.

Portanto, afirmar por exemplo que o USE é mais rápido que o DBUSEAREA(), é simplesmente falar sem base técnica alguma.

Espero que o Maligno (embora ele me ignore) fique ao meu lado pelo bem dos Colegas, que se não avisados acabam levando em conta afirmações absurdas e até disseminando elas aqui e ali, aumentando ainda mais a desinformção, que já é muito grande.

O Jorge está corrétissimo na colocação.

Desta forma depois de compilado e linkado tanto faz...

A=SPACE(10)
ou
A=" "
ou
A=SPACE(5)+SPACE(5)

RESTORE SCREEN FROM TELA
ou
RESTSCREEN(TELA)

Pois tudo é convertido pelo pré-processador...

Na verdade a sugestão dada pelos autores que você mencionou é justamente ao contrário, que se dê preferencia ao uso de funções ao invés de comandos, você pode ver isso em qualquer manual de Clipper 5.2 em que são mencionados vários comandos como obsoletos e sugerido que sejam trocados por funções. Exemplos : DECLARE, USE, CANCEL, CLEAR ALL, DIR, RESTORE SCREEN, SAVE SCREEN, etc...

Até logo.

Marcelo

quando voce mencionou que não usava o comando USE, a principio, fiquei um tanto espantado mas, logo depois foi possivel entender a sua colocação.

Aquilo foi um mal-entendido. E aproveitando sua deixa, aproveito para ressaltar um ponto: não faz tanta diferença como o serviço será feito, desde que seja. Se a qualidade se mantém ou aumenta, não importa quanto código será utilizado, desde que não se perca performance. Ou seja, os fins justificam os meios (se bem utilizados).

Voce nunca leu nenhum livro sobre clipper?

Realmente não. O único livro que li sobre XBase foi o "dBase III Plus" de Edward Norton (capa vermelha), mas usei apenas para conhecer como os DBFs, os comandos e funções do dBase (só o interpretador mesmo - que depois troquei pelo FoxBase). Não cheguei a terminar de ler. Vi só o que achei suficiente. Aliás, lembro muito bem o dia em que instalei o meu disco do Autumn'86, que ganhei de um amigo que o trouxe de São Paulo. Foi difícil entrar para o mundo dos .EXE (não haviam livros sobre Clipper). Mas não reclamo; foi divertido.

[]'s
Maligno
http://www.buzinello.com/prg

provocar uma reação por parte de todos sobre o que cada um pensa em relação a nobre linguagem que tanto nos dá prazer.

Por vezes, direcionar o rumo das discussões para a área filosófica pode ser tão ou mais proveitoso (principalmente para os novatos) do que nos mantermos apenas na área técnica. É claro que o fórum tem a intenção de dedicar-se à área técnica. Mas isso me lembra uma coisa que costumo dizer, quando me perguntam como aprender a programar. Respondo "no início, longe do computador".

respostas através de "trechos.prg" são quilométricas com trocentas linhas utilizando mil e uma funções "não nativas" que eu olho... analiso... verifico a eficássia do algorítimo e da lógica utilisados... e não consigo entender prq usar de tanto "conhecimento" e "tempo" quando a linguagem já trás em seu conteúdo "standard" digamos assim, que se bem usadas com apenas 10 ou 15 linhas farão a mesma coisa e com a mesma eficiência, talvez até mais... aí eu chego a conclusão que: O programador que construiu essa(s) função(ões) é muito bom !!! Só que não leu o livro até o final ou não consultou o manual nas páginas seguintes...

Mas veja que o Clipper, nú e crú, é uma ferramenta quase que primitiva. Não tinham em mente a qualidade que hoje almejamos, à época em que o fizeram. Desde o Winter'85 a interface embutida no Clipper foi melhorando gradualmente. Mas ainda assim, à ótica de quem exige qualidade máxima, sempre foi necessário acrescentar complementos que o "pacote Clipper" não tinha. Pode-se, claro, construir aplicações excelentes com esse Clipper "standard". Mas os usuários do Clipper (programadores) podem ter exigências que esse pacote não atende. E na outra ponta, a do usuário da aplicação, podem existir essas exigências também. A partir daí, muitos sentem necessidade de incrementar o pacote básico com a adição de outras bibliotecas, ou até mesmo desenvendo as suas, como foi o meu caso.

A questão da velocidade, como eu disse na outra mensagem, não conta muito, haja visto que as máquinas atualmente têm poder suficiente para aguentar o código "extra" ou mais que fosse. A questão que mais preocupava no passado era a relativa ao consumo de memória. Mas até isso já foi superado há tempos. Felizmente.

Questões como essa é que me levaram a "questionar" se as funções de 3os. são SEMPRE ou quase sempre necessárias em detrimento das nativas...

Vai da sensibilidade de cada um. Sou contra o programador querer reinventar a roda. Se ela existe pronta, é melhor fazer bom uso dela. Mas adicionar recursos inexistentes, ou mesmo aprimorar o que não parece tão bom, é sempre saudável. Desde que a "saúde", ou qualidade, do código não seja deteriorada. Neste ponto a questão é de perícia técnica.

em relação as de 15 anos atrás onde vc prega que não há mais necessidade de se preocupar com performance, produtividade etc...

Não. Você me confundiu. Mesmo com máquinas super-poderosas, você consegue encontrar programas feitos em C/C++/OPascal/etc que contém diversos blocos de ASM. Todas as funções de manipulação de string do Delphi, por exemplo, foram feitas em ASM. Assim, performance é sempre uma preocupação. Minha também. Só não me preocupo da forma como você se preocupa. É diferente. Eu não poupo código, nem deixo de aprimorar o Clipper por medo de matar a performance do programa. Faço o que tenho de fazer e, na etapa de testes, verifico se o sistema se comporta como esperado. Normalmente a velocidade se mantém ou até aumenta.

reflita comigo: Se a preocupação com o desempenho (velocidade) já existia naquela época (AT, XT, 486, 586 etc) e para tal foram criadas funções e comandos capazes de terem um excelente rendimento naqueles processadores, o que elas não farão nos de hoje Se o comando era rápido num processador lento é óbvio que ele será muito mais rápido num processador mais rápido... Concorda ??

Discordo do seu pensamento. É claro que, na medida em que você obtém um acréscimo na velocidade do conjunto (CPU, barramento, RAM, I/O, etc), seus comandos passam a ser executados mais rapidamente. Mas a partir de um certo ponto, qualquer acréscimo de velocidade passa a ser inócuo. Já não fará mais diferença. Aumentar essa velocidade apenas dará mais tempo de ociosidade ao sistema.

Por aí eu reforço minha discordância também no pensamento do Vidal. Como eu disse antes, acredito realmente que hoje ele já deve ter uma posição diferente sobre este assunto.

[]'s
Maligno
http://www.buzinello.com/prg

Pois tudo é convertido pelo pré-processador...

Vocês se confundiram em um ponto da frase do Augusto. Ele confirmou que os comandos são funções, pois tudo é convertido na etapa de pré-processamento. Só não foi explícito, pois não se referiu diretamente ao pré-processamento. Veja:

Augusto escreveu:"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..."

O erro está na parte em negrito. É algo que não faz sentido, pois se o comando é convertido para função, não pode ser executado mais rápido que ela, já que após o pré-processamento o comando deixa de existir. O que achei mais errado, e que refutei, diz respeito à forma de processamento, diretamente pelo processador. Isso não procede. Só instruções de máquina contidas em objetos compilados por outras linguagens podem ser executadas diretamente no processador. Além do código da VM, obviamente.

Isso se foi erro dele próprio. A informação passada é uma citação do livro do Vidal. Ele pode ter transcrito de forma errada. Mas, como ele não disse nada a respeito, imagino que é coisa do livro. E assim, erro do Vidal.

Na verdade a sugestão dada pelos autores que você mencionou é justamente ao contrário, que se dê preferencia ao uso de funções ao invés de comandos

Essa sugestão se contrapõe à mecânica do pré-processamento. Não há porquê trocar comandos por funções, se os comandos serão convertidos em funções. Sendo assim, seria o mesmo que trocar seis por meia-dúzia. Não faz diferença nenhuma, a não ser em compile-time (diferença desprezível, diga-se). E com relação à legibilidade também, que se perde. Os comandos existem justamente como um meio de aumentar a legibilidade. Trocá-los por funções significa perder legibilidade e dificultar a manutenção futura.

você pode ver isso em qualquer manual de Clipper 5.2 em que são mencionados vários comandos como obsoletos e sugerido que sejam trocados por funções. Exemplos : DECLARE, USE, CANCEL, CLEAR ALL, DIR, RESTORE SCREEN, SAVE SCREEN, etc...

Dividi a frase aqui porque agora trata-se de uma idéia diferente. E devo dizer que concordo. Realmente justifica-se a troca de um comando, que tornou-se obsoleto, por um outro comando (ou mesmo uma função) melhor. Mas são poucos casos.

[]'s
Maligno
http://www.buzinello.com/prg

Caros amigos do forum :

Existe um velho ditado que diz o seguinte:

PARA QUE DESCOMPLICAR SE EU POSSO COMPLICAR...


É verdade que programar é igual a nariz, cada um tem o seu, e ninguém é igual, somos seres humanos e fomos criados com defeitos, errar é humano. (até programar em D...)

Jorge Adourian escreveu:Augusto, embora você tenha ignorado meu nome, dentre os que citou, farei um esclarecimento a quem se interessar.

Jorge, quer me parecer que você ficou enciumado, ou coisa que o vália quando da não citação do seu nome... não se sinta mal por isso... vc está incluso no "e outros" ok ??

Jorge Adourian escreveu:Espero que o Maligno (embora ele me ignore) fique ao meu lado pelo bem dos Colegas

Bem quanto a isso eu não posso fazer nada, se realmente ele te "ignora" ele deve ter suas razões... Prq não pergunta a ele ??

Por outro lado devo dizer que vc tbm não me é muito simpático, talvez pela forma como escreva e como trata as pessoas do Fórum... (coisa de paulista... né ?? +o( ) caso vc não lembre, já tivemos nossos desentendimentos e por isso deixei de discutir qqr tópico no qual vc estivesse participando, sendo assim essa será a minha última participação neste tópico.

Senhores, já atingi meu objetivo com as informações dadas pelo Toledo, Maligno, Marcelo, Domenico e até pelo Renato que escreveu pouco e disse muito... diferentemente do Jorge (citei seu nome, viu ??) que não me disse nada...

:-#

Ebaaaaaa !!!!

Ele citou meu nome....

Eu tinha magoado, agora desmagoei... (desmogoei é ótimo !) agora que tô desmagoado vou me preparar para tomar umas bohemias para desafogar minhas mágoas que agora estão desmagoadas....



Até a próxima mágoa....epa ! Digo. Até logo.

Marcelo

Olá a todos!
Algum amigo participante deste tópico (fórum) pode nos dar uma lista de comandos em que seja ESSENCIAL trocá-lo pela função equivalente?

janio escreveu:Algum amigo participante deste tópico (fórum) pode nos dar uma lista de comandos em que seja ESSENCIAL trocá-lo pela função equivalente?

Um comando só será um BOM candidato a troca se ele for considerado obsoleto. Caso contrário, trocar um comando por sua função seria o mesmo que trocar seis por meia dúzia, operacionalmente. Isso porque todo comando é substituído por função, na etapa de pré-processamento.
No NG você verá um asterisco após os nomes de comandos/funções que são considerados obsoletos. Ex: CALL, CANCEL, DIR, FIND, etc.

Mas, ainda assim, há casos em que a troca se justifica, mesmo que não haja obsolescência. É você quem deverá saber o que fazer, levando em conta a legibilidade que ganhará.

[]'s
Maligno
http://www.buzinello.com/prg

Programo há muito tempo, mas conheço pouco a partir da versão Summer 87 ate a versao 5.3, mas "pra mim" comandos como FIND,ACCEPT,JOIN, INPUT, entre outros, JÁ NASCERAM MORTOS.



Poka