Re: Critérios de correção

["Rubens Altimari" <rubens@bcc2000.net>]

>O desconto foi uniforme, ou seja, errou alguma coisa, perdeu um ponto.

De toda a discussão, acho que só não concordo com isto aqui.

Que nomes diferentes, por exemplo, atrapalhem uma correção automatizada, é
óbvio e deve ser de fato enervante - além disso, concordo também que deva
ter algum decréscimo na nota, já que alguém que acertou tudo "merece" (as
aspas são para outra discussão) ter uma nota maior. O mesmo vale para outros
problemas ou falhas ao cumprir a especificação.

Agora, não vejo relação entre "desconto uniforme" e um critério justo. Pode
ou não haver. Afinal, "errou alguma coisa, perdeu um ponto" pode ser fácil
de aplicar, e aparentemente muito lógico, mas por que deveria ser assim? Por
que um erro, digamos, na apresentação, deveria ter o mesmo peso que um erro
na implementação? Ou na qualidade do algoritmo? Como contar quantos erros há
em uma dada situação (depende de como se conta, etc.)?

Enfim, Nelson, acho que você poderia rever a política de descontos em busca
de algo que se aproxime mais de cumprir o objetivo primário, seja ele qual
for (para mim, seria exercitar o conteúdo da disciplina e demonstrar este
exercício e a apreensão de cada um). Lembro de um colega de minha turma,
quando foi monitor pela primeira vez, que argumentava: "vou tirar 3 pontos
por má indentação - pombas, se o cara não sabe indentar, não sabe nem o
mínimo!". Foi uma luta convencê-lo a ser mais generoso... (que é a palavra
adequada, na minha opinião).

Aliás, aproveito o email para comentar e sugerir o seguinte: achei que este
EP acabou ficando na regra 80-20: 80% do tempo e esforço dedicados às
questões periféricas, como I/O em C (que é um saco), formatos do Makefile
(idem, duas vezes), etc. De grafos, realmente, foram 20%... Este foi o
comentário, a sugestão é a seguinte: que os EPs seguintes ao terceiro não
sejam assim, e fiquem mais nos grafos propriamente ditos. Ou, por exemplo,
que se continue a usar este Make, já que a parte administrativa já está
pronta.

Já entendi que a disciplina é um laboratório de programação, mas grafos são
bem mais divertidos que fazer entrada e saída em C... Aliás, não resisto a
comentar: o Knuth é um gênio, etc., e do ponto de vista de algoritmos, não
há o que ninguém possa dizer (muito menos eu). Mas é um hacker, e quando ele
diz, a respeito daquele maldito gerenciamento de memória, que "the
implementation of this scheme is almost ridiculously easy", tenho vontade de
jogar um grafo na cabeça dele.

Tudo isto, claro, é só uma opinião...

Rubens