Programação Incondicional VIII

Após sub-repticiamente introduzir o Power Sort ao mundo, decidi investir mais tempo no seu aprimoramento. O primeiro passo é permitir a ordenação de inteiros negativos. O algoritmo original utiliza uma variável para acumular potências de 2. Os negativos poderiam ser guardados na parte fracionária, mas achei mais simples e mais eficiente usar um segundo acumulador.

O código Perl abaixo mostra como os números negativos são acumulados numa variável ($pn) e os positivos noutra ($pp). Depois, os números positivos são devolvidos à lista em ordem decrescente, do fim para o início. Os negativos são inseridos do início para o fim, até encontrarem os positivos.

sub psort {
 my @sorted=@_;
 my $index=scalar(@_);

 my $pp=0;
 my $pn=0;

 foreach my $n (@_) {
   $pp+=(2**$n) * ($n>=0);
   $pn+=(2**abs($n)) * ($n<0);
 }

 my $log2=log(2);

 while($pp>0) {
   my $n=int(log($pp)/$log2);
   $sorted[--$index]=$n;
   $pp=$pp-(2**$n);
 }

 $index=0;
 while($pn>0) {
   my $n=int(log($pn)/$log2);
   $sorted[$index++]=-$n;
   $pn=$pn-(2**$n);
 }

 return @sorted;
}
my @sorted=psort(-2,19,8,3,20,16,13,-22,11,52,5,2,-33,
                 18,-4,4,15,1,9,14,6,7,10,17,12,27,50,0,-13);
print join ',', @sorted;

O primeiro laço usa um truque baixo para evitar os ifs, porque, embora existam alternativas mais condizentes com a filosofia da Programação Incondicional, elas são um tanto crípticas.

Então, o próximo ramo de pesquisa da Programação incondicional são as fórmulas que produzam 0 ou 1 para identificar números positivos ou negativos.

Programação Incondicional VII

Já estabeleci que é possível escrever algoritmos recursivos sem ifs. Agora, resolvi atacar os algoritmos de ordenação.

Antes de alterar os algoritmos estabelecidos, resolvi criar um algoritmo inerentemente incondicional. O algoritmo não tem jeito de ser original, mas não encontrei outro semelhante no Google. Por isso, tomo a liberdade de batizá-lo: Power Sort. Logo se verá por que ele tem esse humilde nome.

O algoritmo funciona da seguinte forma:

1. Inicializa-se uma variável p com 0;
   
2. Para cada número n da lista, soma-se 2ⁿ a p;
3. O último elemento da lista é a potência do maior múltiplo de 2 que caiba em p;
4. Repete-se o passo 3 tantas vezes quantos elementos houver na lista.

O código abaixo mostra o algoritmo em Perl.

sub psort {
 my @sorted=@_;
 my $length=scalar(@_);

 my $p=0;
 foreach my $n (@sorted) {
  $p+=2**$n;
 }

 my $log2=log(2);
 for(my $i=$length-1; $i>=0; $i--) {
  my $n=int(log($p)/$log2);
  $sorted[$i]=$n;
  $p=$p-(2**$n);
 }

 return @sorted;
}
my @sorted=psort(19,8,3,20,16,13,11,52,5,2,18,
 4,15,1,9,14,6,7,10,17,12,27,50,0);
print join ',', @sorted;

As vantagens são:

1. Não tem ifs!
2. Requer pouquíssima memória (não precisa de array auxiliar);
3. Não executa trocas;
4. Tem complexidade O(n).

E as restrições são:

1. Não pode haver números repetidos (embora funcione, de quando em vez);
2. Não funciona com arrays grandes, porque a soma cresce muito rapidamente;
3. Não funciona com números negativos.

Em linguagens que permitem números maiores, como Lisp e Tcl, podem ser ordenadas listas maiores. Em Java, é possível usar BigDecimal para representar números maiores. Em linguagens sem facilidades para números realmente grandes, fica-se restrito a listas relativamente pequenas.

Com base e, ele ficaria mais simples e rápido, mas o número máximo de elementos seria menor.

Bom Amiga, Mau Amiga

Está prometido para 2010 um novo Amiga. O nome dele será X1000, em homenagem ao Amiga 1000, de 1985. Mas a verdade é que ele não é um Amiga. O hardware é completamente diferente e o sistema operacional também. O nome foi escolhido só para atiçar os fãs do Commodore Amiga.

Há reedições do Amiga como o Minimig e o Natami, que são versões melhoradas do projeto original usando FPGAs. No Brasil, os MSX foram muito populares e quem tem saudades deles pode comprar um 1chipMSX, que implementa o padrão MSX 2.

Nessa categoria de projetos, o mais curioso é o Uzebox, que é uma implementação de um videogame ao estilo antigo, embora não imite nenhum console em especial. Ele pode ser comprado em kit e montado em casa; tem pouquíssimas peças. Ele usa um processador de 8 bits ATmega644 (rodando a 28MHz), tem 4KB de RAM e suporta programas de até 64KB em cartões SD/MicroSD. A tela tem que ser montada com sprites, porque não há memória suficiente para guardar todos os bits. Essa restrição já dá um sabor de estar programando um equipamento antigo. Por outro lado, ele suporta 256 cores.

O hardware atual está tão poderoso que há emuladores de micros antigos escritos em Javascript, como o JSSpeccy, que emula um ZX Spectrum. Logo vai ser possível emular um Amiga em Javascript. Ter o hardware não é realmente necessário e nomear projetos novos com nomes de micros antigos é pura nostalgia. Ou seria falsa nostalgia?

O Caso Unitron

O Direito é uma área que me interessa pouco fora dos episódios de Law & Order, com exceção ao ramo da propriedade intelectual (PI). Ela me interessa por dois motivos. Em primeiro lugar, porque me parece absolutamente artificial. Em segundo, porque pouca gente parece perceber o quão artificial é.

Não estou dizendo que não tenha nem seu lugar, nem sua utilidade, mas que ela tem sempre que ser vista somente à luz de sua utilidade. Propriedade intelectual é um ferramenta econômica, não um direito fundamental do homem. Há 200 anos, o conceito que temos hoje de pirataria seria inconcebível. No entanto, hoje as pessoas o têm como absolutamente natural.

Em 1985, a Unitron lançou o Uniton Mac 512. Ele era um clone do Mac, mas com mais memória. A Unitron havia tentado obter licença da Apple para produzi-lo no Brasil, mas não conseguiu porque ela exigia 51% do negócio e a lei brasileira proibia que uma empresa estrangeira fosse majoritária.

Quando a Unitron lançou o Mac 512, a Apple sequer havia registrado patentes no Brasil. Além disso, como o Mac da Unitron havia sido desenhado a partir de engenharia reversa, não havia sombra de dúvida sobre sua legalidade. Para obter a licença, a Unitron havia até se comprometido a produzir drives de 3,5", já que só eram produzidos no país os de 5,25".

Mesmo assim, a Apple acusou a Unitron de pirataria (através de uma campanha na mídia local), assim como a Xerox a acusaria de copiar seus projetos e como a própria Apple acusaria a Microsoft de copiar sua interface gráfica. Havia uma semelhança inegável do Mac com o Xerox Alto, tanto no desenho como na interface gráfica. O mouse e o teclado eram praticamente iguais.

No Brasil, todos os computadores eram cópias de máquinas estrangeiras. Os CP da Prológica eram cópias do ZX81 e do TRS80; os TK da Microdigital eram cópias dos micros da Sinclair, do TRS80 ou do Apple II; e a maioria dos micros profissionais eram clones do IBM PC. Assim como no leste europeu, não havia impedimento para clonar um micro europeu ou gringo, porque as leis de lá simplesmente não se aplicavam aqui. O resultado é que alguns projetos eram até melhores que os originais.

A Apple não buscou uma ação judicial contra a Unitron, porque sabia que não havia base para uma. Ela foi ao Departamento de Estado dos Estêites e este, por sua vez, ameaçou impor sanções comerciais ao Brasil. Eles sobretaxariam laranjas e sapatos se a Unitron não desistisse. Não havendo questão legal a resolver, a Apple simplesmente alavancou a força da maior economia do mundo sobre a Unitron.

O governo brasileiro, por sua vez, perdeu uma excelente oportunidade de negociar uma saída. Certamente, teria sido vantajoso para a Apple entrar no mercado brasileiro antes que todos os concorrentes. E o mercado nacional finalmente teria um micro avançado.

O comportamento da Apple deixou patente que não era uma questão de propriedade intelectual, mas de disputa comercial. O projeto, mesmo sendo perfeitamente legal, acabou sendo proibido, além de ser falsamente retratado na mídia como pirata. O investimento e o conhecimento adquiridos no desenvolvimento do Mac brasileiro foram perdidos.

Com esse tipo de apoio, foi melhor mesmo que a reserva de mercado tenha sido extinta.

Micro Men

A BBC produz documentários excepcionais e Micro Men (exibido pela BBC Four em 2009) é dos melhores. Ele conta a história da disputa entre a Sinclair e a Acorn pelo domínio do mercado incipiente de microcomputadores no Reino Unido.

Havia uma cerrada competição entre as duas empresas, porque Chris Curry tinha sido funcionário de Clive Sinclair e não tinha conseguido convencer o chefe a investir na criação de um computador doméstico. Ele então saiu e formou a Acorn com o austríaco Hermann Hauser.

Um tema importante do filme é que ambos pareciam não saber bem para que os computadores seriam usados. Sinclair parece ter ficado bastante aborrecido com o fato de que seu maior sucesso, o ZX Spectrum foi usado principalmente para rodar jogos.

Outro elemento interessante é o de que a tecnologia e os profissionais estavam disponíveis e só faltava alguém com visão para criar um produto. Os criadores dos micros da Acorn estavam na universidade e faziam coisas como programar implementos agrícolas.

A disputa entre as duas para conseguir um contrato com a BBC para produzir um micro educacional é o ponto alto do documentário. Os executivos da BBC entram no laboratório da Acorn no exato instante em que o protótipo começa a funcionar; Sinclair, ao saber da derrota, arremessa o telefone através do escritório.

O filme se passa principalmente em Cambridge, mas, infelizmente, pouco mostra dessa cidade histórica. Por outro lado, ele recria muito bem a estética da época. Em alguns momentos parece até ter sido filmado com equipamento dos anos 80 e trechos de programas de então são inseridos sem que pareçam fora do lugar.

As duas empresas não existem mais, embora a Acorn tenha deixado os processadores ARM como legado.

No Brasil, a história da Unitron, pelo menos, seria interessante contar. O Mac 512 foi um projeto brilhante que provocou um confronto diplomático entre o Brasil e os Estêites. O nosso governo, que parecia tão interessado em desenvolver nossa indústria de informática (afinal, tínhamos uma reserva de mercado), acabou abandonando a Unitron (com campanha na mídia, como insulto final) em favor dos interesses de exportadores de laranjas e sapatos. E é isso, até hoje, que exportamos.

Mídias d'outrora

Por incrível que pareça, ainda há quem publique software em fita cassete. A empresa inglesa Retro Software lança jogos para micros da Acorn:

• The Krystal Connection
• Zap

Obviamente, não há muito dinheiro nesse nicho. Nem fama. Nem mulheres.

Havia um padrão chamado Kansas City Standard para gravar dados em fitas cassete. Os micros da Acorn usavam (ou melhor, usam) uma versão melhorada que gravava a 1200 baud, quando o padrão original usava 300 baud. Isso significa que era possível gravar cerca de 120 bytes (960 bits) por segundo de fita contra 30 bytes do padrão original. Um jogo de 32KB levava cerca de 4,5 minutos para carregar, mas a maior parte era menor que isso. Outra vantagem do padrão da Acorn é que ele permite voltar um pouco a fita se um erro de leitura ocorrer; no padrão original, seria preciso voltar ao início.

Havia fitas de 15 minutos (7 por lado) que eram feitas especialmente para guardar um programa por lado. Era possível colocar vários arquivos num lado, mas não era prático. O sistema operacional suportava o Cassette Filing System, além do Disk Filing System (que necessitava de um ROM adicional de 16KB).

As fitas funcionam muito bem no curto prazo, mas nenhuma das fitas antigas (mais de 20 anos) que testei recentemente funcionou. Alguns dos disquetes de 5.25" ainda funcionam, principalmente os que ficaram guardados em capas individuais (capas robustas de plástico, não as capinhas de papelão que são mais comuns).

Era uma mídia baratíssima e muita gente já tinha gravadores em casa. As pessoas não compravam drives de disquetes, porque o investimento inicial em um computador já era alto. Invariavelmente, acabavam comprando um drive, porque as fitas eram só para monges budistas.

Hoje em dia é difícil encontrar um tocador de fitas. E todo mundo tem um micro com drive de disquete que não usa, porque os disquetes têm pouca capacidade e não são confiáveis.

Cotas ou Quotas?

Nas grandes polêmicas nacionais, dificilmente alguém se dá ao trabalho de analisar os números. Somos uma nação rica em retórica e pobre em realidade.

Com relação à cotas nas universidades, tenho a impressão de que não sejam o suficiente. Para muitos, o problema não está no ingresso, mas na falta de meios para completar o curso. Estudar é caro, mesmo quando é de graça.

Resolvi comparar os números do meu vestibular, que não tinha cotas, com o deste ano, que tem.

Em 1992, meu curso (Ciências da Computação da UFRGS) tinha 72 vagas e 1.390 candidatos (19,3 por vaga, portanto).

Em 2010, 18 anos mais tarde, há 160 vagas e 1.220 candidatos. São 7,6 por vaga. Apenas 112 dessas vagas são de livre ingresso; as demais são reservadas para alunos de escolas públicas e descendentes de africanos.

Então, há 55% mais vagas de livre acesso e 12% menos candidatos ao total.

E, supondo que seja verdadeira a proposição de que as cotas estejam roubando vagas de alunos mais preparados, vou subtrair do total os candidatos às cotas. Para as vagas de livre ingresso, candidataram-se 447 alunos para as 70 vagas de Ciências da Computação (6,38 por vaga) e 244 para as 42 vagas de Engenharia de Computação (5,81 por vaga).

Então, como pode alguém estar usurpando vagas, se todos têm mais?

Um Método Lúdico: casos de uso

O UML é restrito no sentido de que ele pressupõe que o analista e o cliente sejam completamente lúcidos e racionais. Todos nós sabemos que isso nunca acontece.

O cliente não sabe o que é importante para seu negócio, principalmente porque, na maioria das vezes, o cliente do analista não é o dono do negócio. Ele pode até ser um bom funcionário, leal ao seu chefe e tudo mais, mas ele nunca pensa como o dono do negócio. Logo, os sistemas saem com algumas deficiências.

Um tipo de caso de uso muito comum é o descaso de uso. O descaso de uso é um elemento inútil do sistema, mas que, mesmo assim, é o mais popular entre os usuários. Por exemplo, numa intranet, invariavelmente, as páginas mais usadas são: a lista de aniversariantes do mês e o cardápio da cafeteria.

O descaso de uso é como o pato de borracha na banheira. Água, sabonetes e toalhas são essenciais para o banho, mas o pato de borracha é o que o torna realmente divertido (ouvi dizer, pelo menos). Então, o descaso de uso é representado dessa maneira:
O caso de uso pato de borracha (descaso de uso para os mais formais) é proximamente relacionado ao caso de desuso. Ambos são inúteis para o negócio, mas o caso de desuso ainda é pior, porque não serve para nada mesmo. Em geral, o caso de desuso toma a forma de um relatório obscuro, difícil de interpretar e que ninguém lembra quem pediu.

Por exemplo, um gerente num surto psicótico pode solicitar um relatório de vendas realizadas por funcionários com filhos de menos de 10 anos. Ou de notas emitidas para cidades do noroeste catarinense, exceto por aquelas de colonização alemã. O analista logo vê a inutilidade da criatura, mas não consegue convencer o cliente a tentar algo mais abrangente (e útil), como um relatório por região ou uma ferramenta de Data Warehouse, para que o gerente possa brincar sem perturbar sua equipe.

O caso de desuso é representado por uma teia de aranha:
Finalmente, temos o frankencaso. É o caso de uso com múltiplas personalidades. Ele provavelmente reflete a personalidade do cliente que o solicitou. Ou sua taxa de glicose. Um relatório de vendas que, quando disparado na segunda-feira antes das 10h, dispara um workflow que atualiza a tabela de comissões é um ótimo exemplo de frankencaso. Os usuários acabarão aprendendo a disparar o relatório quando quiserem atualizar suas comissões, numa reação pavloviana, mas nunca serão capazes de explicar aos novatos por que a coisa funciona dessa maneira.

O frankencaso é representado assim:
No exemplo que segue, vê-se um ator paranóico usando a página de aniversários para descobrir se não esqueceu de dar um tapinha nas costas do chefe.


Um Método Lúdico leva a ánalise de sistemas a um novo patamar de realismo, aproximando o analista ao cliente e eliminando formalismos bestas.

Orientação a Estrutura

Os cursos de OO costumam ensinar a criar objetos que representam entidades do domínio do problema e a criar métodos para executar seus comportamentos. A verdade é que essa é uma péssima maneira de escrever sistemas.

Acho que isso acontece por que a maior parte dos professores universitários não gastou muito tempo de fato escrevendo programas orientados a objetos.

Olhando sistemas bem escritos, vejo que os tipos de classes estão divididas em:

• Domínio - representam entidades do mundo real e não precisam ter métodos além dos necessários para encapsular dados;
• Utilitárias - são classes para problemas recorrentes, como para gerenciar listas ou representar datas;
• Estruturais - são as classes que dão estrutura ao sistema e que determinam quais os pontos de configuração ou extensão;
• Comportamentais - são as classes que executam as tarefas-fim do sistema.

Então, dificilmente uma classe de domínio faz alguma coisa além de guardar dados relativos a uma entidade. Uma instância que representa uma pessoa pode guardar nome, data de nascimento, número de identidade, etc. Mas não precisa fazer nada além disso.

A tabela abaixo mostra uns exemplos de classes de cada tipo:

Tipo	Exemplos
Domínio	Pessoa, Conta, Processo
Utilitárias	Date, ArrayList, BigDecimal
Estrutura	Controller, Scheduler
Comportamentais	Actions, DAOs, Views

Por isso, acho que é preciso ensinar programação de uma maneira diferente. No lugar de aprender escrevendo, seria mais interessante antes analisar programas escritos por pessoas experientes. Padrões de Projeto são um passo interessante nessa direção, mas não suficiente.

A melhor aula de programação que eu tive foi de Lisp, porque a professora estava acostumada a escrever muitos programas em Lisp.

A máquina do tempo III

Os micros de 8 bits eram incrivelmente silenciosos comparados aos micros atuais pelo simples motivo de não terem um cooler sobre a CPU. Em condições normais, eles não esquentavam. Não importava nem o que estavam fazendo nem por quanto tempo estavam ligados.

Uma atividade com a qual eu consumi muitos ciclos de um pobre 6502 era a de gerar imagens. Eu gastava horas gerando conjuntos de Mandelbrot, Julia, ou curvas de Lissajous.

Nos dias quentes de verão, era preciso colocar um ventilador sobre o micro, para que não derretesse.

Nesses últimos dias de calor, tenho tido receio de ligar um Pentium 4 de 3.2GHz, com medo de queimar o micro. Ele tem um cooler sobre a CPU e o gabinete tem um cooler adicional. Mesmo assim, logo após iniciar, eles começam a girar a toda velocidade e o micro exala um vento quente.

Extrapolações precárias

O salário médio mensal de um analista de sistemas em Porto Alegre é R$2.457. Essa informação, por si só, diz pouco. O Brasil é um dos campeões da desigualdade, apesar dos avanços dos últimos anos, e a média, portanto, deve ficar enviesada para o lado mais alto.

O coeficiente de Gini de Porto Alegre para 2003 é 0,45, segundo o IBGE. Isso não quer dizer que o coeficiente seja o mesmo para a categoria dos analistas de sistemas com contrato celetista, mas, nas falta de mais informação, esse número terá de servir.

Um universo possível de 13 analistas de sistemas com distribuição salarial com média R$2.500 e coeficiente de Gini de 0,45 é este:

Salário	Profissionais
R$1.000	6
R$1.500	3
R$2.500	2
R$7.000	1
R$10.000	1

Então, a maior parte ganha a média ou menos. Apenas 15% ganham mais. A diferença média é R$2.461,53, o que não é surpreendente, já que o coeficiente de Gini é metade da diferença média normalizada (0,45 * 2 * R$2.457 = R$2.211).

O país mais igualitário do mundo é a Dinamarca. O coeficiente de Gini dos vikings é 0,247. Mantendo o valor total dos salários e redistribuindo-os dentro do nosso pequeno universo (e mantendo a média, claro), podemos chegar ao resultado abaixo (o coeficiente é 0,25).

Salário	Profissionais
R$1.000	3
R$1.500	1
R$2.000	3
R$3.500	4
R$4.000	2

E a diferença média é R$1.371,79 (para R$2.457 e 0,247 seria R$1.213). Temos 46% dos salários maiores que a média, e os menores salários estão muito mais próximos do topo.

Estes números, é claro, podem estar longe da real distribuição de salários, mas creio que jogam alguma luz sobre o que significa a desigualdade brasileira. Para o Brasil como um todo, o coeficiente de Gini é 0,57. É bastante alto e reflete as diferenças regionais: o norte e o nordeste simplesmente não podem ser comparados ao sul e ao sudeste. Mesmo assim, dentro dos centros desenvolvidos, a desiguldade ainda é muito superior às dos países ricos.

P.S. O salário mínimo para o cargo de Analista de Sistemas, conforme o acordo coletivo com o Sindppd-RS é R$1.874,51.