A seguir apresentamos alguns elementos do fenômeno da programação de com- putadores cuja análise poderia ter enriquecido ainda mais a obra de Tanaka-Ishii, e que acreditamos que teriam sido levados em conta numa abordagem baseada na semiótica peirceana. Evidentemente não pretendemos que a lista seja completa.
5.2.1
Contexto da programação de computadores
O esforço de criação de software não é um esforço de programação somente (ver 2.5). Determinar o que vai ser programado não é uma tarefa trivial, exceto em casos muito simples. Os programas de computador mais complexos são gerados a partir de especiĄcações que podem ter características semióticas dignas de nota. Além disso, o próprio processo de criação de um programa possui uma dinâmica cuja análise semiótica certamente enriqueceria a obra, mesmo sendo essa voltada para níveis semânticos (ver p. 49) que não levam em conta o contexto.
Uma outra lacuna que não se pode deixar de observar nesse nível é o contexto em que a própria autora considera sua obra. Inferimos, a partir do conteúdo do Capítulo
8 - Uma instância versus A instância, que o contexto em que os programas se inserem
são dentro de uma moldura de utilização do computador para narrativas em linguagens naturais. De modo geral, ousamos aĄrmar que, uma vez que a semiótica de Peirce é uma teoria da cognição, não só o livro se enriqueceria, como o próprio trabalho da autora talvez tivesse a ganhar com a apreciação mais profunda da obra de Peirce.
5.2.2
O programa como signo e o problema da decisão
Em nossa opinião uma abordagem peirceana da programação de computadores não poderia prescindir da análise da semiose do programa em si como signo, mesmo quando se exclui o contexto em que está inserido. Como vimos em 2.4 e em 2.5.2, o programa de computador tem o duplo papel de prescrever uma função pretendida e permitir que a partir dele se crie um software. O programa é portanto um signo que sofre diversas semioses, em dois momentos principais:
5.2. Lacunas na compreensão do escopo 115
∙ No momento da programação, temos um caso de raciocínio que se assemelha ao raciocínio diagramático que vimos em 4.3.1. Aqui o desaĄo do programador é identiĄcar qual conjunto de sequencias válidas (dentro da linguagem de programação) descrevem o diagrama que representa a função pretendida pelo programa. É um tipo de raciocínio que possivelmente guarda semelhanças com o raciocínio matemático utilizado na criação de demonstrações.
∙ No momento da compreensão do programa, quer por seres humanos, quer por máquinas. Há aqui duas semioses: a humana, que quer entender o que faz o programa escrito, e a da máquina, que cria o software a partir do programa. Segundo Peirce (ver 4.3.2), são semioses muito semelhantes entre si.
Admitindo corretas as considerações sobre ambos os momentos, temos uma consequência semiótica que mereceria atenção, a saber:
1. Qualquer programa não-trivial é criado a partir de um raciocínio diagramático. Em algum momento de sua especiĄcação alguém cria um ícone mental da função pretendida e a partir desse ícone prescreve ou o programa em si ou um texto a partir do qual o programador pode estritamente deduzir o programa. O processo de observação desse diagrama é da natureza da primeiridade.
2. O programa em si pode ser transformado em software e este submetido à execução. Essa transformação é da natureza da secundidade. De fato, quase todas as ações do software podem ser deduzidas a partir do texto do programa Ůos programas em que isso não acontece escapam do conceito de algoritmo e de computação e, embora possíveis, são indesejados; os programadores se esforçam para que todas as ações do software sejam dedutíveis a partir do programa, e é considerado inadequado o programa em que isso não acontece.
3. Portanto, o comportamento do software gerado por um programa adequadamente escrito é dedutível, sendo essa dedução da natureza da secundidade.
4. A consequência é que a partir do programa adequadamente escrito é impossível deduzir o diagrama inicial utilizado na sua geração, não importando a linguagem de programação em que seja escrito. A simples leitura, por um ser humano, do texto do programa pode induzir à formação de algum diagrama mental, mas nada garante que esse diagrama gerado a partir dessa leitura tem alguma correspondência com o diagrama inicial que gerou a especiĄcação do programa.
Portanto, do ponto de vista semiótico é impossível, dado um programa, inferir se o software derivado dele cumpre a função pretendida que em algum momento foi pensada como um
diagrama. Para que essa inferência ocorresse seria preciso uma forma de ter acesso ao diagrama inicial que foi utilizado na prescrição do programa. Esse acesso, entretanto, não pode ser feito a partir do programa através de inferências da natureza exclusiva da secundidade, ou seja, não pode ser feito por um outro programa. Isso frustra, de certa forma, qualquer intenção de procurar uma ŞespeciĄcação semântica consistenteŤ para os programas (ver p. 37, na qual citamos Sebesta (2012)) Ůintenção de resto já frustrada, ao menos na óptica peirceana e dentro do escopo de abrangência das linguagens naturais, pela vagueza intrínseca destas últimas (ver 4.3.3). Chama a atenção, também, a semelhança desse resultado com o de Turing (1936), que aĄrma que não há procedimento computável para julgar a efetividade de um procedimento computável.
Observemos também que esse resultado não contradiz Hoare (1969), apresentado na página 40: determinar os valores que as variáveis do programa devem assumir para cumprir a função pretendida corresponde a criar um diagrama mental da função pretendida e descrevê-lo sob a forma de valores de variáveis em programas Ůesse passo corresponde à inferência baseada na primeiridade. A descrição da função pretendida sob a forma de valores de variáveis pode ser utilizada na dedução ŮsecundidadeŮ de um programa.
No momento podemos somente especular, mas eventualmente casos de sucesso ou fracasso na construção de software (ver 2.5.1) podem estar associados aos diagramas icônicos utilizados na especiĄcação deste.
5.2.3
Os signos num programa
A autora indica as variáveis, ou identiĄcadores, como os principais signos dignos de nota nos programas de computador. São, de fato, signos muito importantes para o programador, pois ele os vê, como a própria autora coloca, como estruturas de dados e funções (ver p. 49).
Entretanto, diferentes tipos de estruturas de dados e funções são passíveis de serem representadas em variáveis. No Capítulo 5 - Ser e fazer em programas a autora dá um exemplo em que o mesmo problema pode ser solucionado por softwares gerados por programas que, não obstante serem escritos na mesma linguagem (Java), são dife- rentes em sua estrutura. Ou seja, as variáveis num e noutro programa representam não somente estruturas diferentes, mas tipos de estruturas diferentes. Num programa, a classe ŚRectangleŠ (uma variável) herda estruturas de dados e funções da classe ŚShapeŠ (outra variável), no outro programa a classe ŚRectangleŠ implementa as interfaces ŚPolygonŠ e ŚAreaŠ (ambas são variáveis também): nesse outro programa o programador não vê o