Por que escrever “certo”?

Surgiu pela milésima vez o assunto “Por que escrever certo? A língua não evolui?” num fórum e a minha resposta ficou absurdamente longa. Resolvi escrever aqui e deixar lá so o link. E aqui ainda posso colocar uns subtítulos para separar melhor as idéias. Pelo que conheço dos meus poucos leitores regulares, eles já sabem de tudo isso (tem gente até mais viciada em usar o idioma corretamente do que eu), então não é pra eles que escrevo.

Durabilidade e alcance da informação

Hoje historiadores se valem muito de livros e manuscritos, mas talvez no futuro a internet seja uma fonte de pesquisa histórica. Não seria legal se o que você escreveu pudesse ser lido daqui a 200 anos por um pesquisador tibetano interessado em saber as opiniões dos internautas do Brasil em 2010? Ele terá bem menos trabalho se você escrever direito.

Para nós, “iço” é entendível, mas coitado do estrangeiro (no presente ou no futuro), que vai ir no dicionário, pensando que é uma palavra desconhecida e não vai encontrar. Ele provavelmente deduzirá o significado algum tempo depois, mas terá mais trabalho tudo porque a pessoa que escreveu não quis fazer o mínimo esforço de pôr em prática o que todo mundo aprende no primeiro ano da escola: escreve-se “isso”, não “iço”. A pronúncia é a mesma, mas a padronização traz benefícios.

Facilidade e rapidez de leitura

Até para um brasileiro, encontrar as palavras escritas sempre da forma correta facilita a leitura, pois o cérebro reconhece mais rápido as palavras. Se eu encontro “esta” no lugar de “está” (ou vice-versa), muitas vezes eu tenho que reler a frase pra ver se fui eu que li errado (posso ter pulado uma palavra ou uma pontuação) ou se o texto está errado mesmo.

Não-humanos

É sempre engraçado e irritante quando vejo um desses analfabetos colocar num tradutor automático uma frase como: “Ela esta feliz” (me faltou uma frase mais realista), e pega a tradução “She this happy” como se fosse um inglês perfeito e sai por aí postando em legenda de foto no Orkut, postando em ingrêis nos fóruns gringos, etc. Se ao menos se desse o trabalho de acentuar corretamente o “está”, teria muito mais chance da tradução sair correta (os tradutores automáticos já são ruins, imagina se a gente fica atrapalhando com grafias fora do padrão).

Outros casos de não-humanos seriam leitores de tela para pessoas com algum tipo de deficiência visual (não quero nem imaginar como um leitor leria algo em miguxês… droga, já imaginei) e, é claro alienígenas.

Concessões e gentilezas

A primeira vez que eu vi a abreviação “vo6” eu não entendi porra nenhuma. É que aqui na minha região, a gente fala “vocês”, não “voceis”. Não seria legal se combinássemos de escrever todos do mesmo jeito? Bom, nesse caso já está combinado de todos escreverem “vocês”.

Por acaso pode parecer que eu levo uma certa vantagem porque a forma escrita “vocês” é mais parecida com o jeito que eu falo, mas em outros casos não é. Eu por exemplo, se fosse escrever como eu falo, escreveria “trabisseiro”, mas eu faço uma concessão (se quiser, pode considerar como uma “gentileza”) ao resto dos falantes do português e escrevo como foi padronizado: “travesseiro”, para facilitar o entendimento de todos.

União

Nossa língua, apesar de estar entre as mais faladas do mundo, não é tão poderosa. Se quisermos nos comunicar com o resto do mundo, precisamos aprender inglês, espanhol, francês, etc. Se ainda tivéssemos que aprender (ou ensinar aos estrangeiros) português de Portugal, português gaúcho, português nordestino, português angolano, seria pior ainda. A língua ensinada nas escolas, que é um pouco diferente do que falamos no dia-a-dia, é um jeito de nos manter mais unidos.

Línguas como o alemão e o italiano têm vários dialetos, mesmo que os países sejam menores que o Brasil. Mas os viajantes estrangeiros podem ficar sossegados que existe o alemão padrão e o italiano padrão que podem ser entendidos por toda a extensão de seu país correspondente (assim ouvi falar. Não sei alemão nem italiano).

Elitismo

Após defender o uso “correto” (coloco entre aspas porque na verdade acho que a melhor palavra seria padronizado) da língua, pode parecer que sou do time de pessoas que acham que simplificar a ortografia tiraria a “beleza”, a “riqueza”, o “valor”, e/ou a “história” da língua e por isso deveríamos fazer como o francês e o inglês que mantêm suas complicadas ortografias. Não concordo com eles. Na verdade, o que eu acho que eles querem dizer é que uma ortografia complexa serve pra distinguir os eruditos da plebe. Mas isso não é problema, porque a natureza se encarregará de criar idiotas suficientes para escrever errado em qualquer ortografia. Defendo, sim, que deve haver evolução, mas tem que ser algo razoavelmente organizado.

Evolução

Bom, acima expliquei as vantagens da padronização. Sei que há várias evoluções e simplificações possíveis na nossa ortografia. A minha reclamação é que as grafias miguxas, internéticas e assemelhadas não são uma evolução coerente da língua em direção a uma grafia simplificada. São uma bagunça. Se fosse uma coisa coerente, até eu apoiaria. Eu também gosto de testar novas grafias, como escrever “mause” (fica meio feio, né?) e “extender” (de onde tiraram a idéia de padronizar o “estender” com S e “extensão” com X?), mas sempre em doses leves, não em todas as palavras do texto.

Mas é muito difícil conseguir consenso sobre uma nova ortografia e aplicá-la globalmente a um mundo de livros, revistas, sites e programas de computador (corretores, tradutores e qualquer coisa que venham a inventar). Mesmo assim, fizeram uma reforma ortográfica no Brasil ano passado…

O artigo abaixo, aparentemente publicado antes da reforma de 2009, explica o tortuoso (mas interessante) caminho percorrido pela nossa língua até chegar ao estado atual. Na minha opinião, houve mudanças demais neste século passado. A mudança inicial salvou o português de ser uma bagunça como o inglês no quesito ortografia, mas as outras alteraram minúcias que serviram mais pra confundir a cabeça do povo, que mal consegue manter uma ortografia na cabeça.

http://revistalingua.uol.com.br/textos.asp?codigo=11184

Anúncios

Comparação de desempenho (2)

Este post não tem introdução nem desenvolvimento: já começa com as conclusões.

Link para os testes originais


P1: Tempo para analisar 261 PDFs em 1 único processo P2: Tempo para analisar 261 PDFs abrindo seqüencialmente 1 processo para cada P2÷P1
C++ 1,65s (64 bits) 3,53s (64 bits) 2,14
D 2,75s (32 bits) 5,71s (32 bits) 2,08
F# 3,35s
(64 bits / .NET 4.0)
71,54s
(64 bits / .NET 4.0)
21,36
Java 1,91s (64 bits) 40,93s (64 bits) 21,43

Boo 10,56s
(32 bits / .NET 3.5)
28,07s
(32 bits / .NET 3.5)
2,66
C++ debug 8,87s (64 bits) 11,20s (64 bits) 1,26
Lua 10,10s (64 bits) 12,38s (64 bits) 1,23
Python 9,28s (64 bits) 22,73s (64 bits) 2,45
Ruby 10,00s (32 bits) 23,49s (32 bits) 2,35

Resultados

Dividi os resultados em 2 categorias: a primeira, das linguagens que conseguiram tempos menores que 5 segundos; a segunda das outras. Como curiosidade, incluí uma versão de C++ na versão “debug” (sem otimizações), mostrando que o desempenho acaba ficando na segunda categoria. Então, se você sempre roda seus programas em modo debug, você não está usando todo o potencial da linguagem…

Destaquei em verde os dois melhores tempos em cada categoria. Na segunda coluna, destaquei também em vermelho piores tempos de cada categoria, porque as diferenças foram enormes e merecem atenção. Não dei o mesmo destaque na primeira coluna porque as diferenças não eram tão significativas.

Embora seja fácil analisar os resultados pelas cores, reenfatizo aqui pontos interessantes: como a inicialização do processo é absurdamente custosa em Java e F# (nas versões 64 bits), bastante custosa em Boo, Python e Ruby e pouco custosa em C++, D e Lua. Destaque para Lua, que é uma linguagem dinâmica (e muitas vezes executada a partir do código fonte) como Python e Ruby, mas tem uma inicialização rápida como C++ e D. Ruby 1.8 tinha a fama de ser muito lento (não testei). Já a versão 1.9 melhorou e compete diretamente com Python, embora não o alcance ainda.

Desta vez, não incluí o uso de memória, mas coloquei a proporção entre os tempos da primeira e da segunda colunas.

Melhorias no código fonte

O código fonte foi melhorado usando um profiler. A mudança principal está na função PdfXref::add_obj, que agora não chama read_number (removida), que era a função que mais degradava o desempenho. Quase todas as diferenças de desempenho entre os testes anteriores e estes se devem a esta melhora em add_obj. A única exceção é explicada a seguir.

Na implementação em D, houve uma correção que muda a classificação final. A variável pdfFile é agora passada e armazenada em PdfTokenReader por ponteiro, como deveria ser. Isso corrige o problema que fazia o scope(exit) ser necessário (embora haja em D um certo problema em ter structs com destrutores dentro de classes, no meu caso a culpa era minha mesmo). O resultado prático dessa mudança é que agora a implementação em D é consistentemente mais rápida que a implementação em F#.

Os códigos estão nas seguintes páginas. Mantive as implementações originais em C++, D, Java, Python e F# e adicionei as novas.

Edit 2014-04-12: Todos os fontes no BitBucket (o repositório é Git):
https://bitbucket.org/marcuscf/pdfpagecount/commits/tag/v2010-10-27

Código fonte em Java

Código fonte em C++

Código fonte em D

Código fonte em F#

Código fonte em Python

Código fonte em Lua

Código fonte em Boo

Código fonte em Ruby

32 ou 64 bits?

Para simplificar a tabela, não incluí versões 32 bits onde eu tinha disponível o compilador/interpretador de 64 bits. Mas alguns testes de 32 bits eu fiz, e pude concluir que as proporções continuam as mesmas para todas as linguagens: uma pequena mas consistente vantagem de desempenho na versão 64 bits, com a exceção da inicialização do Java e do F# onde há um grande impacto na performance em 64 bits. Portanto, os resultados do teste anterior ainda podem ser usados como referência.

Outras condições do teste

Outras variáveis não se alteraram. Usei a mesma máquina, exatamente os mesmos 261 arquivos de entrada e repeti o teste algumas vezes para obter o menor tempo atingível. Repeti cada teste 3 vezes no mínimo e repeti algumas vezes mais enquanto estivesse conseguindo obter tempos menores (isso foi diferente no teste anterior, onde repeti sempre 3 vezes cada execução).

Implementações usadas

Foram usadas as mesmas implementações de compiladores e interpretadores dos testes anteriores.

Nas linguagens a seguir, que rodam a partir dos fontes, não foi usada pré-compilação mesmo quando ela estava disponível (.pyc, luac, etc.):

Python 3.1.2, distribuição oficial para Windows, 64 bits

Ruby 1.9.2-p0, distribuição RubyInstaller para Windows, 32 bits.

Lua 5.1.4, inicialmente usei a distribuição LuaForWindows v5.1.4-40 (32 bits), mas como era bem fácil de fazer, substituí os executáveis e DLLs por versões de 64 bits a partir do projeto LuaBinaries.

A última linguagem adicionada foi Boo 0.9.3, usando o SharpDevelop 3.2.0 (build 5777). Ela não roda a partir do fonte, como Python, mas sim compila para o .NET Framework. Infelizmente, ainda não é compatível com o .NET 4.0, então não dá pra fazer uma comparação direta com F#. O desempenho ficou comparável ao das outras linguagens dinâmicas, apesar de Boo usar tipos estáticos.

Fim

Pronto, terminei de fazer todos os testes que eu queria fazer, finalmente. Foi interessante perceber a diferença na qualidade de documentação, ferramentas e comunidade das linguagens consolidadas (C++, Java, Python, Ruby, Lua) e das em desenvolvimento (D2 e Boo, deixando F# numa categoria intermediária). Por exemplo, uma linguagem consolidada que não muda muito dá a impressão de ser “estável”: ela não sofre atualizações tão freqüentes mas todo mundo usa e fala sobre ela; enquanto que uma linguagem aspirante sem um anúncio de nova versão no grupo de discussão oficial parece “abandonada”. Uma linguagem consolidada que passa por atualizações, parece “ter futuro”, ser “moderna”. Já no caso de uma aspirante, muitas novas funcionalidades podem por descuido não ter sua documentação atualizada (ou o contrário: existe documentação sobre um recurso que não está completo) e isso faz a linguagem parecer “instável”, “problemática”.

Antes de fazer o teste eu não gostava muito de Ruby, por parecer um “Python mais complicado”, como a confusão na definição de procs e lambdas e na precedência de operadores (ver este exemplo:

irb(main):058:0> true or false and false
=> false
irb(main):059:0> true || false && false
=> true

) mas usando deu pra perceber que é uma linguagem muito prática, que procura tornar fáceis as tarefas comuns (exemplos: attr_reader, attr_accessor, case/when, regexps, interpolação de strings, uso do símbolo @, ranges, etc.), ainda que as regras da linguagem sejam um pouco mais complicadas do que o necessário. Ah, e espero que a página da linguagem em português se atualize, pois está bem atrás da versão em inglês (compare: http://www.ruby-lang.org/pt/ e http://www.ruby-lang.org/en/)

Misinterpretações

Eu acho que o prefixo mis é muito útil e poderia ser usado em português. Por exemplo, eu frequentemente (e aí, uso trema ou não uso?) misinterpreto algumas frases com resultados engraçados. Tanto é que desde que eu criei este blog existe a categoria “Diálogos bizarros”, porque eu sabia que volta e meia eu ia ter algo pra postar sobre isso.

Caso 1:

— Olha, são marrecos!

E eu (em pensamento):

— São Marrecos? Que santo é esse?

 

Caso 2:

— Imagina se eu tivesse nascido 100 anos antes!

E eu (em pensamento):

— Se tivesse nascido sem ânus?

Mas quando ouvi a palavra “antes”, fiz reparse na frase e entendi.  Ainda bem que ele não disse “100 anos atrás”, hehehehe :-D