Por sugestão da Patrícia, fomos assistir ontem “Nise - O Coração da Loucura”, excelente filme sobre o trabalho da psiquiatra Nise da Silveira, pioneira da psicologia junguiana no Brasil. Glória Pires viveu o papel de Nise, e o filme me cativou do começo ao fim.

No final da película, porém, imagens de arquivo com um depoimento da própria Nise (falecida em 1999 aos 94 anos) me reservaram uma surpresa: Nise da Silveira era nordestina!

Como pode um filme que se propõe a retratar a batalha dessa mulher contra as convenções da época apagar esse fato?

Em uma das primeiras cenas do filme, Nise entra em um auditório no Centro Psiquiátrico Pedro II no Rio de Janeiro, onde são apresentadas as técnicas mais “modernas” da época para lidar com doenças mentais: lobotomia e eletrochoque. Nise, a única mulher da sala — e de fato, uma das primeiras mulheres formadas em Medicina do Brasil — pede a palavra e questiona as técnicas barbáricas. E esse foi apenas o primeiro de muitos conflitos dela com os médicos ao longo do filme. Embora não falada, a barreira que se apresenta ali àquela mulher buscando respeito no meio de um grupo homogêneo de homens é evidente. Se além de mulher ela tivesse também uma fala nordestina, as cenas dela confrontando os médicos certamente iriam adquirir uma dimensão ainda mais forte.

Mas aparentemente o diretor carioca Roberto Berliner não julgou importante retratar isso no filme, ou achou que bastaria mostrar Nise no epílogo para que isso se tornasse uma não-questão. Não é. Esse é apenas mais um epiósdio que mostra como a produção cultural no Brasil é homogeneizante e a nossa diversidade vai sendo apagada.

Por mais industrializada que seja a produção americana ela me parece ter um respeito um pouco maior pela diversidade que a nossa. Alguém consegue imaginar se, num hipotético filme biográfico sobre uma médica da Louisiana quebrando tabus em Nova York, o sotaque sulista dela seria “neutralizado” (com muitas aspas, pois adotar um sotaque dominante em nada é torná-lo neutro)?

O Brasil esconde os seus sotaques na arte, a não ser quando é para fazer deles caricatura. Já vi no cinema um Getúlio Vargas que falava como carioca do início ao fim do filme exceto em uma cena onde “queria comer um churrasco”. E ainda assim isso não é comparável, pois os gaúchos não sofrem o preconceito sistemático que os nordestinos sofrem no resto do Brasil.

Lembro de uma pichação que vi nos muros da cidade: MACHADO DE ASSIS ERA NEGRO. Lembro do meu choque quando aprendi esse fato somente na vida adulta. Espero que as escolas hoje em dia façam um trabalho melhor de que no meu tempo. Espero também que no futuro o cinema faça um trabalho melhor do que no tempo de hoje.

Em suma, o que eu gostaria de dizer é: assistam ‪”Nise - O Coração da Loucura”, é realmente muito bom, mas não esqueçam: Nise da Silveira era alagoana, formada na Bahia, e não falava com o sotaque carioca da Glória Pires.

Pra vocês que daqui a pouco vão estar soltando foguetes sobre como a economia “vai melhor no governo Temer”: olhem os gráficos, a economia tá em franca recuperação desde janeiro puxada pelo ritmo de alta do petróleo (”olhem pros gráficos”, tecla que eu já venho batendo aqui nos meus posts há uns dois anos). A crise veio por causa lá de fora, ele vai acabar por causa lá de fora.

As coisas seguirão no curso, o que vai mudar é o discurso dos jornais e TV.

A “crise” que todo mundo fala eram na verdade duas:

• a crise econômica, que já vinha cedendo desde o início do ano — há meses temos indicadores positivos, eles são negativos se comparados com 12 meses (como os telejornais faziam até ontem) por causa da descendente do ano passado. Não é São Temer e o corte do Ministério da Cultura que vai botar as contas do país nos eixos, é a alta do petróleo.
• a crise política, que era o caos institucional causado pelo PMDB no Congresso com suas “pautas-bomba” — leia-se: prejudicar o país de propósito pra fazer o circo pegar fogo e gerar insatisfação popular. Agora que eles obtiveram o que queriam, essa crise fabricada por eles mesmos “acaba”.

E a tal da corrupção sobre a qual tanto gritavam nas ruas? Pois é…

I decided to stop running XSane as root. Here’s what I had to do:

* Restored the ownership of ~/.sane back to my user: sudo chown -R hisham ~/.sane
* Made /var/lock/sane writable by a regular user: sudo chmod a+rwxt /var/lock/sane
* As a quick-and-dirty fix, as suggested here, I gave permissions to my USB devices: sudo chmod a+rw -R /dev/bus/usb/*
* For a more permanent (and still untested) fix, I added a 40-libsane.rules file (found here) in /etc/udev/rules.d. This file already includes the USB id for my scanner. You may have to add yours.

Coisas que o Hisham pensa enquanto toma banho:

“Todo mundo lembra do que é um triângulo retângulo… e acho que triângulo equilátero também… afinal, equi-látero, lados iguais.

Mas acho que ninguém lembra do que diabos é um “triângulo escaleno”… que nome horrível. Como é o nome daquele com dois lados iguais, é escaleno mesmo? Não lembro! Pra tu ver. A diferença que um nome bom como “equilátero” e um nome ruim como “escaleno” fazem. Um deles a gente sempre lembra qual é.

Taí um bom problema: e se eu fosse dar um nome melhor para aquele triângulo com dois lados iguais, que nome seria? Duolátero? Bom, aí parece que o triângulo só tem dois lados, o que é um absurdo. Bom, o triângulo com dois lados iguais é aquele que se tu traçar uma reta saindo bem meio da “ponta” ela corta bem no centro do lado oposto, né… ficam dois triângulos retângulos iguaizinhos um de cada lado. Taí: “triângulo simétrico”. Aposto que se esse fosse o nome todo mundo ia lembrar qual triângulo é esse! Problema resolvido!”

Rice’s Theorem, proved in 1951, states that it is impossible to write a program that performs precisely any non-trivial analysis of the execution of other programs. More precisely, that’s impossible to code an analyzer for some non-trivial property that is able to decide whether an any given analyzed program has that property or not. And by “trivial property” we mean a property that either _all_ algorithms in the world have or _none_ has. So, yeah, “non-trivial property” is basically any property you can think of: “does it ever calculate 5 + 2”, “does it always use less than 10MB of memory”, “does it ever print something to the screen”, “does it ever access the network”?

At this point you might say “wait! I can write a program that checks if programs access the network or not! We can parse the code and if there are no calls whatsoever in it to any networking code such as connect(), then it doesn’t access the network!”. Sure, you can do that: but if the code has calls to connect(), you can’t decide for sure that it will access the network when it’s executed.

In 1936 Alan Turing proved that it is impossible to write a program that solves the Halting Problem, that is, to write an analyzer that checks programs and tells if it always terminates (”halts”) or it might enter an endless loop given some specific input. Okay, that’s a classic result, but that’s one property, how can Rice’s Theorem say we can’t make an analyzer for any property at all, even the silliest ones?

The proof for this amazingly powerful theorem is surprisingly simple. Turns out that if we had an analyzer for any silly property, we could use it to make a Halting Problem analyzer (which Turing proved to be impossible). Like this:

bool my_halting_problem_analyzer(Code analyzedProgram) {
   Code modifiedProgram = analyzedProgram + "; someCodeWithSillyProperty();"
   return my_silly_property_analyzer(modifiedProgram);
}

If the code in analyzedProgram always terminates, then the code in modifiedProgram will always reach the part that has the silly property, so my_silly_property_analyzer will return true, and my_halting_problem_analyzer returns true as well. If there is some input that makes the analyzedProgram hang in a loop, that means there’s some input that makes the silly property fail, resulting in false. Yay, we solved the Halting Problem using the silly property analyzer! Not.

Of course, this explanation is quite simplified¹ (in particular, (1) I’m ignoring in the pseudo code the input of the analyzedProgram, which should be an argument of my_halting_problem_analyzer; (2) Rice’s Theorem is formally stated about partially recursive functions, but the formalism maps to Turing Machines and therefore the result applies to programming languages in general; (3) I didn’t stress enough that the “non-trivial properties” should be on the functions themselves (that is, their input-output pairs) and not their specifications (their “code”), but I believe I conveyed the general idea), so head to Wikipedia and your favorite formal languages book for the precise details. But the point stands that general semantic analysis of programs is impossible.

In particular, you can’t write a program that takes versions 1.0 and 1.1 of any program X and answer the question: “do they behave the same?”. In other words, it’s impossible to write an analyzer that looks at your master branch before you make a release and answers the question “should your new release tag be a major, minor or tiny release” according to the rules of SemVer (or any other API-compatibility-bound set of rules, for that matter).

This is because API compatibility is not only based on syntactically-expressible issues (that is, type signatures for functions and data structures). Any semantic changes to the code also break compatibility. A function may change its behavior but not its type signature (it still returns a string, but it used to be lower-case and it’s now upper-case), a struct can change they way it is used but the fields remain the same (field foo returned numbers from 0 to 10 and -1 when executed on Sundays, now it returns -1 on Saturdays as well). An automated tool won’t catch all this.

So, it is possible only to write a “pessimistic” tool, that may detect lots of situations syntactically and give the bad news: “hey, you must increment the major version here!”. But you can’t write a tool that is always able to look at code semantically and say the good news: “I assure you that no API behaviors have changed, you can safely name this a tiny version increase.”²Edit: It was pointed out to me that I missed the “always” in the previous version of the last sentence. Yes, of course you can write an analyzer that checks for API-comptabiility between versions for some cases: a silly example would be an analyzer that detects if the code is identical save for carefully renamed local variables, or that has some no-op x = x; assignments sprinkled in it — yep, the code is different, but evidently behaves the same. It’s a silly example but it shows that it is possible to catch some cases. My point is that it is impossible to write a program that reaches a conclusive answer on API compatibility on all cases, so the conclusion stands that making versioning decisions fully automated is impossible. Further, writing one that would catch even a significant amount of positive cases would be impractical. There are hard limits to semantic analysis. However, given that lots and lots of API breakage happen in function signatures and data types, those are not hard to detect, as they are syntactically specified: that’s why the “pessimistic” tools are much more practical.

Yes, you can use test suites as an approximation for detecting semantic changes in API behaviors beyond type signatures and data structures. That would certainly improve your pessimistic analyzer — you’d be able to detect more situations where “you must increment major”. But even then it can only go so far, because in practice one can’t test for every possible input/output combination, so you still can’t be 100% sure. fuzz testing has uncovered bugs and unexpected behaviors even in programs with extensive test suites; as Dijkstra famously said, “Testing shows the presence, not the absence of bugs.” — likewise, test suites can show inconsistencies to the API specification, but not their adherence. So they can’t be taken to represent the semantics of a program entirely.

Anyway, in the end of the day, Rice’s Theorem shows us that general bullet-proof analysis of program behavior is not attainable, so no tool will ever be able to compare codebases and always tell us precisely that a new release is really “tiny-safe”. Semantic versioning just can’t be automated.