Concordo com grande parte do que disseste, contudo há uma coisa que não entendo...
O que é uma "Linguagem de Programação"?
Para mim uma linguagem de programação é um conjunto de keywords e sintaxe que permite descrever de forma textual comportamentos do hardware que o vai executar.
Assembler, C, C++, C#, Java, Pascal, Cobol, PHP, entre muitas outras, têm uma coisa em comum entre elas, embora se baseiem todas umas nas outras (naturalmente) nenhuma é compatível entre si pois utilizam keywords e sintaxes diferentes.
Arduino, ObjectiveC, SWING, AWP, entre outras, são APIs, blocos de código compatíveis com uma linguagem base que permitem estende-la facilitando assim a vida ao programador evitando estar sempre a repetir código.
Vamos então olhar para writing_digital.c da API Arduino:
http://code.google.com/p/arduino/source/browse/trunk/hardware/arduino/cores/arduino/wiring_digital.c
void pinMode(uint8_t pin, uint8_t mode)
{
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);
volatile uint8_t *reg;
if (port == NOT_A_PIN) return;
// JWS: can I let the optimizer do this?
reg = portModeRegister(port);
if (mode == INPUT) *reg &= ~bit;
else *reg |= bit;
}
Como se pode ver, de forma muito clara, esta função é um call a um boloco de código em C-AVR que permite alterar o modo de funcionamento do pin em questão para o segundo argumento passado.
Comparemos com o meu código para ARM:
http://code.google.com/p/lpc210x/source/browse/trunk/libs/io.c
void pinMode(int pin, int mode){
if (mode)
io_write_U32(GPIO + IODIR, io_read_U32(GPIO + IODIR) | (1 << pin));
else
io_write_U32(GPIO + IODIR, io_read_U32(GPIO + IODIR) & ~(1<<pin));
}
void io_write_U32(U32 addr, U32 val)
{
*(U32 *) addr = val;
}
Mais uma vez, uma call para um bloco de código que modifica o funcionamento de um pin nesta em C-ARM.
O que quero dizer é que no meu ponto de vista (muitos poderão discordar e gostava de ouvir porque para poder reeducar-me se achar que estou errado) são meras APIs, isto é, blocos de código que facilitam a vida ao programador, mas não são uma linguagem de programação pois não são conjuntos de keywords e sintaxes que permitem escrever código de forma diferente, apenas escondem parte das rotinas pois elas são tipicamente iguais.
Espero que todos estejam cientes que as minhas palavras são apenas minhas, neste meu processo critico de aprendizagem onde tento expor o que sei e o que penso para que possamos em conjunto criticar as minhas observações e molda-las para um conhecimento mais correcto.
Boas Tiago,
Uma API (Application Programming Interface) é uma definição da implementação de uma interface
com o objectivo de fornecer ao programador uma forma de interagir com as funcionalidades
fornecidas por um determinado sistema computacional. Existem APIs implementadas por sistemas
operativos, sistemas de ficheiros, base dados, redes, etc., mas o denominador comum é que uma
API é implementada e disponibilizada por um software ou serviço já existente.
Traduzindo isto para Layers do modelo OSI, eu diria que uma API não fica abaixo do layer 5, sendo
que no layer 1 temos o hardware.
Compreendo, e acaba por ser frequentemente usado, que uma lib (biblioteca como se diz em
português) seja por muitos considerada uma API, mas não é correcto considerar um conjunto de
funções que interagem directamente com o hardware (layer 1) como uma Application Programming
Interface, uma API está a um nível muito mais alto, e é muito mais abstracta para o programador a
nível de implementação.
Por exemplo, numa verdadeira API nunca terias acesso à implementação da função pinMode como
exemplificaste.
Não se esqueçam que estamos a falar de Embedded Systems , e a coisa que mais perto se pode
ficar de uma API é usar as funcionalidades disponibilizadas por um RTOS, e mesmo assim, se
recorrermos mais uma vez à analogia OSI, estamos a trabalhar num layer muito baixo.
Por isso, considero que o uso do termo API para descrever as funções disponibilizadas pelas libs
(biblioteca) fornecidas com o do IDE Arduino não é correcto, afinas de contas não passam disso
mesmo, um conjunto de funções de baixo nível. Mas compreendo a ideia por detrás do uso do termo
API neste contexto.
Voltando às linguagens.
Como tu dizes, e bem, as linguagem de programação caracteriza-se pela sua sintaxe, um pouco de
forma análoga ao que se passa nas linguagens e idiomas humanos.
Na base temos as instruções em Assembler, que são as que no fundo cada processador, seja ele um
AVR ou um Intel, entendem. As datasheets indicam o que cada instrução executa, e indicam um
opcode para cada uma dessas instruções. Como tudo o que um processador entende é números, o
que o compilador de Assemler faz é converter o nosso código assembler em opcodes e operandos,
que são depois executados pelo processador.
Tudo o que as linguagem de médio e alto nível fazem é introduzir uma forma ,de nós humanos,
escrevermos código de uma forma mais natural e mais simples do que usando Assembler ou os
opcodes directamente. Existem compiladores de linguagens de alto nível que geram directamente os
opcodes, outros geram assembler que é posteriormente compilado usando o compilador de
assembler especifico para cada processador, isto claro de forma transparente para o programador.
C, C++, C#, Java, Pascal, Cobol, PHP, ObjectiveC, e todas as outras são linguagens de
programação. O Arduino implementa uma variante de C/C++, mas ao fazê-lo ganhou o direito de
ser considerada uma linguagem, pois afinal de contas tem uma sintaxe, tem uma flow, e tem as
duas regras.
Por exemplo, na implementação C/C++ do IDE do Arduino a função “main”, que é o ponto de
entrada executado depois do código startup correr (todos os compiladores/processadores geram
código startup e corre antes do “nosso” código, e que é na maioria só está acessível se formos à
procura dele), esta função “main” não é o ponto de entrada do nosso programa. Dai eu ter dito que
o código C/C++ Arduino não ser portável directamente para qualquer outro compilador de C/C++.
Cada linguagem tem a sua especificidade, algumas linkam com libs externas, outras o próprio
compilador insere código/chamadas que serão linkados internamente.
Para evitar divagar muito vamos somente cingir-nos ao C/C++. Tudo o que o compilador entende
está descrito nas especificações do mesmo, existe um padrão ANSI que define a implementação e
a sintaxe que um compilador de C/C++ deve perceber, essa especificação engloba também algumas
funções padrão, tais como o “printf”, “atoi”, “scanf”, etc, etc. Geralmente estas funções padrão são
as que podemos encontrar nos headers “stdio.h”, “stdargs.h”, “stddef.h”, “stdlib.h”, etc, etc.
Estas funções, e outras que possam acompanhar um qualquer compilador com header específicos,
são geralmente contidas em libs (bibliotecas) que são depois incorporadas no código final pelo linker
(lincador/linkador?).
Depois temos as nossas próprias funções, aquelas que nós escrevemos, e que podemos incluir numa
lib existente ou criar a nossa lib, ou podemos simplesmente incluir a fonte junto com o resto do
nosso código.
Tal como qualquer outra função, seja interna (nossa) seja ela externa (vinda de uma lib) esses
“blocos de código” como tu lhes chamas, são isso mesmo, são simples funções contidas numa lib.
Uma função pode interagir com o hardware, ou pode simplesmente efectuar um qualquer
processamento lógico ou de dados, mas será sempre uma função, e como dizes, e bem, evita
duplicar código e poupa trabalho, mas mesmo as que interagem com o hardware, a este nível, nunca
podem ser consideradas uma API são meras funções... no máximo a este nível podemos
chamar-lhes “drivers” (controladores).
Pela sua própria definição, um “blocos de código reutilizável” é uma função, quer existe no código
quer exista numa lib e seja posteriormente linkada.
Mas como já disse, compreendo a tua ideia por trás do uso do termo API.
Existe muito mais coisas interessantes a dizer sobre estes assuntos, mas este post já vai longo
e maçador, qualquer dia voltamos a falar sobre isto.
Abraços
Paulo A.
