[Akitando] #117 - Linguagem Compilada vs Interpretada | Qual é melhor? | AkitaOnRails.com\n[Akitando] #117 - Linguagem Compilada vs Interpretada | Qual é melhor?\n2022 April 15, 17:34 h\nHoje você vai ganhar uma fundação mais sólida pra entender linguagens da maneira correta e é o pré-requisito pros próximos videos onde finalmente vou discutir as linguagens mais famosas da atualidade.\n00:00:55 - Pré-Requisitos\n00:01:53 - Hello World em C e Java\n00:03:03 - ELF vs CAFE\n00:03:41 - 1a tentativa: compilador vs interpretador\n00:04:45 - Estudo de Linguagens\n00:07:37 - Análise Léxica\n00:10:59 - Análise Sintática\n00:14:39 - Abstract Syntax Tree (AST)\n00:15:48 - Notação Polonesa\n00:17:58 - Otimização de Bytecode\n00:22:55 - Pra que serve um Programador?\n00:27:04 - Linters\n00:28:00 - Backus, Naur, BNF e História\n00:31:57 - Parsers e "DOM"\n00:32:58 - Interpretadores e Máquinas Virtuais\n00:36:56 - Linguagens Dinâmicas\n00:38:58 - Otimização Binária\n00:42:52 - As Fases de um Compilador\n00:46:23 - Just-In-Time Compiler (JIT)\n00:50:33 - Linkers\n00:59:24 - JIT de novo\n01:02:30 - Google V8\n01:05:25 - Por que dinâmico em vez de estático?\n01:07:42 - 2a tentativa: compilador vs interpretador?\n01:10:45 - Bônus: Bloopers (novidade)\nANSI C Grammar (https://www.lysator.liu.se/c/ANSI-C-grammar-y.html#compound-statement)\nEcmaScript 2023 (https://tc39.es/ecma262/#sec-ecmascript-language-statements-and-declarations)\nList of Java bytecode instructions (https://en.wikipedia.org/wiki/List_of_Java_bytecode_instructions)\nWhy the New V8 is so Damn Fast (https://nodesource.com/blog/why-the-new-v8-is-so-damn-fast/)\nV8 Bytecode.h (https://github.com/v8/v8/blob/master/src/interpreter/bytecodes.h)\nLLVM Analysis and Transform Passes (https://llvm.org/docs/Passes.html)\nTodo bom iniciante que se preza mais cedo ou mais tarde vai se engajar numa discussão sobre porque sua linguagem favorita é melhor que dos outros. E invariavelmente um dos argumentos que vai aparecer é que ser compilado é melhor, é mais performático, ou que ser interpretado é melhor porque é mais produtivo. E certamente todos que estão participando dessa discussão estão errados de maneiras que vocês nem imaginam.\nHoje quero falar um pouco sobre o que significa uma linguagem ser compilada ou interpretada e porque a maioria dos programadores interpreta isso errado (no pun intended). O objetivo não de hoje não é dizer qual é melhor, e sim porque sua linha de raciocínio não leva em conta diversos outros fatores que são mais importantes. No final do video você vai enxergar todas as suas linguagens de uma forma diferente.\nPra todo mundo que tá estudando ou já se formou em ciências da computação: não, eu não vou falar do livro do dragão de compiladores. Também não vou falar do livro de sistemas operacionais do Tanenbaum. Porém todo mundo que estudou essas duas matérias vai ter um aproveitamento melhor desse video. Aproveitem pra discutir os detalhes técnicos com seus colegas ou fazer mais perguntas pros seus professores na faculdade e nos cursos.\nCompiladores e sistemas operacionais são conteúdos pra pelo menos um ano ou mais no curso de ciências da computação. Partes desses assuntos eu já expliquei em videos como o guia mais hardcore de introdução à computação e hello world como você nunca viu antes, e todos os outros na playlist de "Como Seu Computador Funciona". Mas pra ter uma idéia, na faculdade, um dos trabalhos é fazer seu próprio compilador. Se nunca fez, depois do video fica de desafio tentar fazer o seu próprio. E pra isso já dou spoiler pra pesquisar tutoriais sobre a ferramenta ANTLR. Mas não vou falar especificamente de ANTLR hoje também.\nVamos começar do começo. Isso aqui é um Hello World em C. Agora, isso aqui é um terminal de Linux no WSL2 do meu PC e compilamos esse arquivo texto com o código em C num binário ELF compatível com Linux usando o compilador "cc", que significa "Compiler Collection". E pronto, isso é tudo que a maioria tem na cabeça quando se pensa em transformar código texto em um executável e no video sobre arquivos texto e binários eu explico como realmente as coisas funcionam e como um executável funciona. Mas vamos pra outro exemplo.\nAgora, isso aqui é um Hello World em Java. Novamente vamos pro Terminal e é assim que se aprende na faculdade, roda javac Hello.java e ele vai gerar um Hello.class. E pra rodar é só fazer java Hello e voilá. Muita gente costuma dizer que Java é uma linguagem "compilada", entre aspas. Só que olha o que estamos fazendo: chamando o executável "java" antes e dando como parâmetro a classe "Hello" que acabamos de compilar. Se fosse realmente compilado, no sentido clássico, deveria dar pra só fazer ./Hello.class, mas isso não funciona, o sistema operacional não tem nenhuma idéia de como executar isso, porque um binário .class não é um executável em formato ELF.\nComo tinha explicado no video de arquivos, pro Linux saber que um binário pode ser executado, ele precisa estar num formato chamado ELF, que significa Executable and Linkable Format. Em particular, todo binário ELF começa com a sequência que em hexadecimal seria 7f 45 4c 46, que propositalmente é ASCII pra string "ELF". Isso é totalmente arbitrário e quem inventou o ELF só definiu que é assim e pronto. Mas se abrirmos os primeiros bits da classe Hello de Java, o que vemos nos primeiros bytes é a sequência hexadecimal cafe babe. Obviamente uma piada de café e java que o James Gosling escolheu pra serem os primeiros bytes de todas as classes Java.\nSe definirmos que compilar é o processo de pegar um código fonte texto, por exemplo em C, passar por uma ferramenta como o "cc", que vai cuspir um binário que o sistema operacional vai conseguir executar diretamente, então não, o Java não é compilado. Por outro lado vamos definir um interpretador. Um interpretador é um programa que vai pegar ou o arquivo texto do código ou uma representação intermediária, como esse ".class" e vai traduzir pro binário de máquina que, aí sim, o sistema operacional e o processador vão entender. Portanto, por essa definição, Java é uma linguagem interpretada.\nIsso é o que você vai encontrar na bolhadev, e na verdade o que acabei de falar não tá nem totalmente certo, nem totalmente errado. Tanto C quanto Java são linguagens compiladas. E antes de explicar qual a diferença, preciso começar explicando o que é o processo de compilação. Esse processo tem diversos passos mas minha intenção não é escovar bits hoje, mas sim fazer com que vocês tenham um modelo mental fácil na cabeça pra não cairem em pegadinhas de discussão online e conseguir entender as principais diferenças.\nO estudo de linguagens de programação é meio que um sub-conjunto do estudo de linguagens em geral, tipo português ou inglês. Em ciência da computação, na teoria formal de linguagens, as linguagens de programação como C ou Java ou Python são o que chamamos de linguagens regulares. Por sua vez, uma linguagem regular é uma linguagem formal que pode ser definida por expressões regulares, sabe o regex que você usa todo dia pra validar formato de emails ou cpfs? E por sua vez uma expressão regular pode ser definida como uma linguagem que pode ser reconhecida por um autômato finito. Älguns de vocês já devem ter esbarrado no termo "máquinas de estado finito", que é outro nome que se dá a autômatos de estado finito.\nMas relaxa, nem eu sei tudo em todos os detalhes e não vou descer na matemática por trás de autômatos não, mas é pra saber que existe esse campo de estudo. Na prática, pense assim. Temos um texto em português. O que é um texto? É uma coleção de parágrafos. E o que são parágrafos? É uma coleção de frases. E o que é uma frase? É uma coleção de palavras. Palavras são coleções de letras separadas por espaço ou outras pontuações, como vírgula ou ponto.\nEntão, se eu juntar quaisquer letras, vou ter palavras? Se eu juntar quaisquer palavras, vou ter frases? Não. Existe uma ordem que funciona. Conjuntos de letras só formam palavras se elas existem num dicionário, que é uma coleção arbitrárias de conjuntos de letras, que a gente definiu. Se eu juntar as letras "h", "e", "l", "l", "o", um atrás do outro, no dicionário em inglês, isso define uma saudação e uma forma de iniciar uma comunicação por telefone, por exemplo. Tire um "l" dessa palavra e já não significa a mesma coisa.\nPra formar frases, não pode sair juntando quaisquer palavras. Elas precisam obedecer uma gramática. Sujeito, predicado, adjetivos, pronomes, tempos verbais e tudo mais que fazem uma frase ter sentido. Se eu disser a frase "não vai ter jeito", significa que não tem mais conserto, fodeu já. Mas se na verdade faltou uma vírgula nessa frase depois do não, então seria "não, vai ter jeito", que é exatamente o significado oposto. Uma única vírgula faz diferença. Quem já programou e teve bug porque esqueceu uma vírgula, em português, também tem bug se esquecer uma pontuação.\nVoltando pro código C. Pro computador, um texto, é só um linguição de bytes, um linguição de caracteres. Tem letras, tem espaços, tem chaves, mas não quer dizer nada. Mesmo pra você, ser humano assistindo, se nunca programou, esse texto também não quer dizer bulhufas. Eu preciso dar um jeito de fazer o computador juntar letras que formam palavras, que no caso chamamos de "tokens", que fazem sentido. "int" é um conjunto de letras que faz sentido. "printf" é outro conjunto de letras que faz sentido. Então preciso conseguir quebrar esse texto todo em uma lista de tokens. Pra isso vou "tokenizer", ou "lexar", e isso é o trabalho de uma ferramenta que faz análise léxica.\nNa realidade precisamos definir os lexemes da linguagem, o equivalente de dicionário. Podemos definir que dígitos são todos os caracteres de zero até 9. E definimos como não-dígitos, todas os caracteres de "a" até "z", em mínusculo e maiúsculo. Também definimos que pontuação são todos estes outros caracteres como parênteses, colchetes, vírgula, ponto e tudo mais. Alguns desses caracteres podem repetir em outra definição. Parênteses podem ser operadores, assim como sinal de mais, de menos, asterisco. E assim por diante. Agora um analisador léxico como um chamado flex pode pegar meu código em C e entender que tem sinais, strings, digitos, operadores e traduzir isso numa lista de tokens.\nUma vez tendo essa lista de tokens, precisamos saber o que significam. Eu preciso que o computador entenda que, o que vai entre parênteses depois do token "printf", é um argumento. Eu preciso que ele entenda que o "return 0" na última linha entre chaves se refere ao tipo "int" declarado no começo da função "main". Elas precisam estar seguindo alguma regra. Uma vez tendo uma lista de tokens, precisamos checar contra uma gramática.\nAs primeiras linhas é o jeito mais porco de pegar um argumento da linha de comando. Vou executar fazendo "./stupid.js hello.stupid", igual o Java faz com "java Hello" antes, lembra. Pra isso botei um shebang na primeira linha que vai executar o Node automaticamente e carregar o resto do script nele. Depois pego o primeiro argumento e uso a biblioteca path pra formar o caminho absoluto até esse arquivo.\nDaí uso a biblioteca "fs", de filesystem, pra ler o arquivo. Se eu passar um arquivo que não existe vai dar um erro e sair. Senão eu pego o conteúdo do arquivo, limpo coisas no final como o caracter de nova linha, caso tenha, sabe o "\_n"? E aí simulo o que seria o trabalho do tal analisador léxico, que vai tokenizar o conteúdo do arquivo.\nEssa minha linguagem é tão besta que não precisa de um analisador sintático. Eu só faço um switch case e vejo o 2o token da lista. Se for "add" eu faço uma soma, se for "sub" eu faço uma subtração. E é isso aí. Eu posso adicionar quantas operações quiser seguindo esse formato. E no final, se colocar um operador que não tá declarado, vai dar erro de sintaxe e sair.\nSe tiver um pouquinho de imaginação vai conseguir criar linguagens bem simplinhas usando só esse esquema. Mas dando spoilers já adianto onde que vai dar nó na cabeça. E se eu quisesse suportar uma expressão com mais de 2 números? Tipo fazer 1 + 2 + 3, como você faria? E se eu quisesse adicionar multiplicação e quiser que 1 + 2 * 3 dê a resposta correta? Note que multiplicação tem precedência, então 2 * 3 tem que vir antes de somar por 1. E dá pra ir complicando. E se eu quiser suportar variáveis? E se eu quiser suportar funções?\nObviamente isso é um problema já resolvido. E o primeiro conceito é separar a análise de sintaxe da execução propriamente dita, que é o que costumamos chamar de "tempo de compilação" e "tempo de execução". Recapitulando, a análise léxica só dividiu o texto em tokens, e agora análise sintática vai dar significado pra esses tokens. Pra isso vai precisar de uma gramática que define o que são expressões, o que são funções, o que são condicionais. Por exemplo, podemos ver a gramática da linguagem C.\nAs ferramentas tradicionais que aprendemos na faculdade são lex ou flex, pra definir a análise léxica, e o bison ou yacc pra definir a gramática. Se procurar no GitHub é fácil de achar a gramática de todas as linguagens. A gramática do C em yacc é bem curtinha. Você imagina que definir uma linguagem deve ser milhares de linhas, mas na realidade não é mais que meia dúzia de page down, algumas centenas de linhas. Isso não é o compilador todo, só o parser, claro.\nSe olharmos lá no fim da gramática, eis a definição do que é uma função de C, literalmente ele nomeia como "function definition". E pode ser construído de 4 formas diferentes. A 1a são especificadores de declaração, seguido de declarador, seguido de lista de declaração e terminando com composição de statements. Em português não sei como chamam "statements", alguns chamam de expressão, mas a definição de expression e statement são diferentes. Eu acostumei a chamar de statement então vai assim mesmo.\nMas o que tudo isso quer dizer? Esses nomes são como etiquetas, a definição de cada uma tá mais pra cima. Por exemplo, vamos ver o que "compound statement" quer dizer. Olha só, pode ser também 4 coisas: um bloco entre chaves vazias, ou uma lista de statements entre chaves, ou uma lista de declarações entre chaves e por último pode ser uma lista de declarações seguida de uma lista de statements, mas o principal é que estamos olhando pra declaração oficial, completa e não-ambígua do que o C chama de "função". Não há espaço pra discussão, esta é gramática que define o C.\nAgora o que é um statement list? Aqui vemos a definição e ela pode ser um statement ou vários statements, isso é meio que uma definição recursiva, por ser ela mesma várias vezes. Mas isso só define que pode ter um ou mais statements, agora precisamos ver o que é um statement. E agora sim, um statement pode ser de diversos tipos como labeled statement, compound statement que vimos antes, mas o interessante vai ser esse iteration statement.\nE olha só, é isso que C chama de statements de iteração. Pode ser um while, pode ser um do while, pode ser for. E o for pode ser de dois jeitos diferentes, com ou sem uma expressão no final. E assim por diante. Se você tiver paciência pra ler a definição léxica e a gramática de yacc, tecnicamente é toda a sintaxe e semântica do C definida em 2 arquivos razoavelmente curtos, dá pra decorar e saber de cabeça. Claro, não é um iniciante que vai ler esses arquivos e entender tudo. Mas se alguma vez você já se perguntou, onde que tem a definição exata de uma linguagem? São nesses arquivos, e não em blog post.\nMas beleza, essa é a gramática mas e daí, pra que serve? O objetivo é quebrar seu código fonte, que é um texto, em uma listona de tokens e depois usar a gramática pra organizar esses tokens em uma estrutura de dados que podemos manipular programaticamente. O objetivo é transformar seu código em uma árvore, mais especificamente uma Parse Tree. Lembram? Eu sempre falo que uma das estruturas de dados mais importantes é uma árvore, por isso dediquei um video inteiro só sobre isso. No final seu código fonte vai ficar mais ou menos assim: (imagem)\nAliás, tudo que expliquei até agora sobre analisadores léxicos e sintáticos, o processo de transformar um texto de código em tokens e reorganizar esses tokens numa árvore, é o que muita gente chama de "parser", mas na realidade a primeira etapa de tokenizar é feito por um lexer, e a segunda parte de pegar os tokens e transformar em árvore é feita por um parser. Pra simplificar, vou pular a explicação do que é uma Parse Tree e ir direto pra mostrar outra representação da mesma árvore, que é a árvore de sintaxe, Syntax Tree, ou mais especificamente uma Abstract Syntax Tree ou AST.\nLembra daquela minha linguagem de programação mais estúpida do mundo, que só aceita uma linha e só faz soma de dois elementos? Digamos que eu evolua ela pra fazer conta com mais de dois elementos e queira escrever aquele 1 + 2 * 3. Essa é a notação que chamamos de infixa onde operadores como o sinal de mais e o asterisco vão no meio dos operandos, que são os números. É a notação, ou forma de escrever, que nós humanos estamos mais acostumados a ver, mas não é a única notação e nem a melhor.\nQuem tá acostumado com as boas e velhas calculadoras de engenharia da HP conhece a famosa notação RPN ou notação polonesa reversa onde começamos digitando 3, depois 2, depois asterisco. Daí ele multiplica o 3 pelo 2, que dá 6. Continuamos digitando o 1 e só depois o sinal de soma, que vai somar o 1 com o resultado parcial 6, e isso vai dar 7.\nNotação polonesa reversa é o que chamamos de pósfixa. Portanto notação polonesa é a préfixa. E numa árvore de sintaxe escrevemos de forma préfixa. O importante é saber que o que você considera "bom senso", nem sempre é, tem formas melhores. Vamos ver como fica. A árvore pra essa conta começa com um nó raiz que seria o sinal de mais. Começamos pelo operador, por isso préfixo. Daí divide em dois galhos, o nó da esquerda poderia ser o asterisco e o nó da direita o número 1. Embaixo do nó de asterisco, divide um nó a esquerda pra ser o 2 e outro a direita pra ser o 3.\nEssa representação seria o equivalente a escrever direto em polonês como +(*(2, 3), 1). Já viram isso antes? Vamos mudar o símbolo de "+" e chamar de somar e trocar asterisco por multiplicar, daí ficaria somar(multiplicar(2, 3), 1). Ficou mais claro agora?\nÉ assim que você programa. A maioria das linguagens de programação, no caso especial de contas aritmeticas, como soma ou multiplicação, deixa você escrever da forma infixa, mas internamente, depois do parsing, o compilador tá mudando pra forma préfixa na árvore, assim como todo o resto das suas funções. Isso tudo foi pra ilustrar rapidamente que a forma que você escreve o código não é a forma como o computador vai executar.\nVamos ver como isso funciona. Vamos fazer outro programinha idiota em Java, que pegue os 3 primeiros parâmetros, converta o texto em número, que vai ser os números 1, 2 e 3 que usamos no exemplo anterior. Então precisa chamar o método estático parseInt da classe Integer. Daí vou imprimir no console com System.out.print a soma de a com b vezes c, exatamente como no exemplo. Agora compilamos com javac e podemos chamar java Calc 1 2 3 e deu 7, como deveria. Nenhuma surpresa aqui.\nMas o que de fato executou? Pra quem não sabe existe a ferramenta javap que vem no JDK de Java que serve pra desassemblar, pra mostrar o assembly de bytecodes de Java. Lembra no episódio do guia mais hardcore de introdução a computadores que eu mostrei uma parte do assembly da CPU 6502 que era usado no antigo Nintendinho? Mesma coisa, a ferramenta javac vai passar nosso código por um parser, fazer algumas mágicas que já vou explicar e cuspir instruções binárias de máquina, o que comumente se chama de bytecodes ou assembly. E o javap só mostra esses bytecodes na tela de forma que nós humanos conseguimos ler.\nParece complicado, mas pra esse exemplo simples não é. Esse trecho que vai até a linha 21 são as instruções pra pegar os argumentos que passamos e converter em inteiro, aquele Integer.parseInt. Percebam que a gente só escreveu uma linha de código pra cada um dos três parâmetros, mas pra cada um ele gerou pelo menos 4 instruções, isso sem contar esse invokestatic que chama seja lá o que o parseInt faça.\nNovamente, o que você escreve na sua linguagem sempre vira bem mais instruções depois de compilado, e esse é o objetivo. Antigamente, até antes dos anos 90, era super comum escrever direto em assembly, em linguagem de máquina, porque era mais eficiente. Não havia nem memória, nem processamento suficiente pra existir um compilador inteligente como os de hoje.\nMas agora os compiladores evoluíram tanto que geram assembly muito melhor do que é possível fazer na mão. Além disso os programas que escrevemos hoje são muito maiores, seria impossível escrever tudo em assembly. Se alguém já se perguntou se seria mais eficiente escrever tudo em assembly, não, não é, tirando raríssimas exceções, nenhum programador hoje é melhor que um compilador.\nDe qualquer forma, a parte que importa são as linhas 24 a 28. Aqui esse bytecode iload vai empilhando na Stack os números que converteu. Daí chama o bytecode imul que, como dá pra ver pelo nome, é a multiplicação. Ele desempilha os últimos 2 números, multiplica e empilha de volta o resultado. Chega na instrução iadd que desempilha os últimos dois valores na Stack, soma e empilha o resultado. Lembram? Eu expliquei pilhas no episódio de Hello World como você nunca viu. Se não sabe como um sistema baseado em pilha funciona, assista esse episódio depois.\nOs mais espertos aí assistindo talvez tenham notado, mas porque eu fiz essa forma complicada de ter que passar os números como parâmetros na linha de comando? Por que não deixei hardcoded direto no código o 1 + 2 * 3? Vamos fazer isso agora. Deixa eu criar uma nova classe chamada Calc2 e fazer direto System.out.print(1 + 2 * 3).\nAliás, ignorem a nomenclatura de classes que estou usando, tá bem porco mesmo só pra ir mais rápido, mas obviamente não façam nomes como "Calc2" em projeto de verdade, né? Enfim, agora salvamos, compilamos de novo com javac e podemos executar com java Calc2 e devolve 7 de novo. Se for como no exemplo anterior, agora deve ter cortado aquele monte de bytecodes de parseInt mas deve ter as mesmas instruções de iload pra empilhar e imul e iadd pra multiplicar e somar, né?\nVamos conferir. Fazemos javap -c Calc2 e olha só, ué, cadê a multiplicação e adição? Não tem, em vez disso tem aqui esse bytecode bipush que quer dizer "empilhe este número inteiro na Stack", no caso o número 7 que já é direto o resultado de 1 + 2 * 3. Sacaram? Na hora de compilar o javac já viu: cara, essa conta vai dar 7 sempre, nunca vai mudar, então pra que vou refazer o cálculo toda vez? Deixa eu já pré-calcular e dar direto o resultado. Assim ele economizou 3 chamadas de iload, e as chamadas pra imul e iadd. Em vez disso ficou só uma chamada bipush pra empilhar direto o resultado final 7 e daí já pula pra chamada que vai imprimir o texto no console. O compilador literalmente reescreveu meu código.\nLembram daquele meu interpretador pra linguagem mais estúpida do mundo? Ele pega o código do meu programa, tokeniza e coloca os tokens num array, e faz um switch case, se achar o operador "add" executa uma soma, se achar um "mul" faz multiplicação. E olhando pra isso, vocês poderiam pensar, "ah, isso faz sentido, pra que precisa de tanto trabalho pra converter os tokens numa árvore e depois da árvore converter em instruções de máquina em vez de direto já cuspir instruções?" E esse é um dos motivos. Vamos filosofar um pouco.\nNão importa que sintaxe de linguagens você ache mais bonita ou mais elegante ou mais produtiva. Não importa se você gosta de usar chaves pra delimitar funções como no Java ou se prefere usar identação como em Python. Não importa se prefere dividir tudo em várias pequenas funções de poucas linhas ou prefira o jeito go-horse de entuchar o máximo de linhas dentro de uma função. Não importa se gosta ou não de colocar comentários detalhados antes de cada função. Tudo isso é totalmente irrelevante pro computador.\nDepois que seu código for parseado e compilado, o que vai sobrar são instruções de máquina. Muito do que você escreveu vai ser reescrito, o compilador vai pensar "porque esse idiota deixou um cálculo hardcoded que sempre dá a mesma resposta? vou reescrever e deixar direto só a resposta, foda-se." Sim, o compilador vai jogar fora tudo que você escreveu e vai reescrever tudo do zero da forma que ele acha mais eficiente. É isso que o computador vai ver no final e executar.\nMas então, tudo que sempre me falaram de Código Limpo, boas práticas, serve pra que então? Se no final o computador tá cagando e andando, pra que eu tô perdendo tempo organizando todo meu código, escolhendo nomes fáceis de entender e tudo mais? Porque você não está e nem deve estar programando pro computador, você programa pra outras pessoas. Entenda essa verdade: o seu trabalho não é programar pro computador e sim pra que outras pessoas entendam. Incluindo você daqui alguns dias ou meses.\nSe como eu você curte retrogames, já deve ter assistido videos explicando os truques que programadores faziam antigamente pra conseguir extrair o máximo de máquinas de processadores super fracos como o Z80 ou 6502, com quase nada de RAM, na faixa de 2 kilobytes. Pensa que o Super Mario World inteiro, com todos os gráficos, fases e lógica ocupa meio megabyte. Em meio megabyte hoje você não consegue fazer nada.\nQualquer página web simples precisa de múltiplos megabytes. E isso porque antigamente ciclos de CPU e RAM eram hiper caras. Pelo mesmo preço que se comprava um Nintendinho nos anos 80, hoje você compra um Playstation 5. Literalmente, no começo dos anos 80 um nintendinho custava quase 180 dólares, que se ajustar pra inflação dá quase 500 dólares, que é o preço de um PS5.\nPor isso antigamente era hiper importante economizar ciclos e bytes ao máximo, mesmo que fosse ao custo de dificultar a vida dos programadores, porque o custo do hardware era muito maior que o custo de programadores. 10 kilobytes a mais de RAM que desperdiçasse em 1983 era 200 dólares a mais. Por isso escovar bits era a coisa mais importante. Mas o tempo passou e agora 200 dólares você compra mais de 16 giga de RAM. Por isso que desperdiçar 1 ou 2 gigas de RAM, por mais absurdo que pareça, não é mais grande coisa.\nPor outro lado o que subiu foi a hora de programador. Se o programador tem que gastar o dia todo pra descobrir que diabos é esse número 7 e que a conta original era 1 + 2 * 3, que se estivesse explícito no código ia custar 2 segundos pra entender, faz muita diferença. Toda boa prática de código é feito pra economizar hora de programador e não hora da máquina. E mesmo se você trabalha sozinho, as boas práticas e código limpo continuam fazendo sentido, porque o você de amanhã, às 2 horas da manhã numa emergência, vai te agradecer por ter feito tudo organizado e fácil de ler.\nLógico, não estou dizendo que você não tem que saber programar direito sabendo como a máquina vai se comportar. Nem o melhor compilador do mundo vai melhorar seu código bosta que dá "select *" numa tabela gigante do banco só pra pegar uma linha, porque ele não tem como saber, durante a compilação, que pode ter uma tabela de um milhão de linhas sendo consumido e causando vazamento de memória. Ele vai fazer o melhor possível, mas não existe limites pra programador ruim dificultar a vida do compilador.\nPor baixo dos panos ele passou pelo parser do V8, gerou a estrutura de árvore e tá processando os nós dessa árvore. Os nós podem conter metadados que apontam de volta qual linha do código que representa, e assim dá pra analisar e devolver a análise pro editor mostrar bonitinho pra você. Todo linter funciona assim. Um linter ou ferramentas de análise estática, tentam te orientar pra escrever código melhor e apontar coisas que seriam ambíguas pro compilador, daí ele pode te dizer o equivalente a "tem certeza que é isso que você quer fazer?"\nO que mostrei até aqui é a fase de parsing. Essa idéia de criar uma gramática livre de contexto veio de ninguém menos que John Backus, criador do Fortran, provavelmente a primeira linguagem de alto nível de sucesso comercial, lá nos anos 60. E não só ele fez a linguagem como se inspirou nos trabalhos de pesquisadores como o grande Turing ou Noam Chomski, cujo foco era linguagens no termo mais genérico, tipo língua portuguesa ou inglês, mas os resultados poderiam ser aplicados em linguagens de computador.\nO Backus inventou essa idéia de uma linguagem que descreve outra linguagem, ou seja, uma meta-linguagem, e usou pra definir uma nova linguagem chamada IAL, que viria a se tornar o ALGOL. Muita gente costuma pensar em C como o avô das linguagens, mais por causa dos blocos com chave e statements terminando com ponto e vírgula. Outros consideram o C muito novo pra ser avô e o verdadeiro avô seria o COBOL.\nMas eu penso diferente. No máximo, COBOL é mais avô de coisas como linguagens de stored procedures de banco de dados. A real linguagem avô do que chamamos de "linguagens de uso genérico", anterior ao C, é o ALGOL. Antes do C ser inventado, o Ritchie e Kerninghan trabalharam no BCPL que poderíamos chamar de linguagem "B" e pra mim a linguagem "A" é o ALGOL.\nAinda em Cambridge tentaram simplificar o CPL com o Basic CPL ou BCPL do Martin Richards, pra ser "só as coisas boas do CPL". Poucos anos depois o Ken Thompson chefiou o projeto de UNIX pras máquinas PDP/11 e fez um compilador pra uma versão reduzida do BCPL que chamou de linguagem B. Mas tanto BCPL quanto B eram limitadas. B era alto nivel demais e como eu disse antes, isso custava recursos escassos e caros de hardware. Por esses e outros problemas, surgiu Dennis Ritchie pra reescrever a linguagem que seria a sucessora do B pra ser mais "próxima da máquina" e daí surgiu o C.\nMas independente disso, está claro que as raízes das principais funcionalidades que reconhecemos hoje numa linguagem de uso geral surgiram com o Algol e por isso podemos considerar que ela é a verdadeira linguagem A. E a linguagem C é a versão que realmente vingou e serviu de inspiração pra linguagens mais modernas como C++, Objective-C, que inspiraram depois Java, Python, C# e todo o resto que vocês usam hoje.\nDe qualquer forma, o cientista da computação Peter Naur reconheceu o poder da idéia de metalinguagem do Backus e como já existia o termo "Chomski Normal Form", ele decidiu que a notação do Backus deveria se chamar "Backus Normal Form" ou BNF. Mas tecnicamente não era uma forma normal, como apontou o lendário Donald Knuth e foi ele que sugeriu que BNF deveria ser pra "Backus-Naur Form", e é assim que chamamos até hoje.\nMas como falei antes, poucos programadores hoje, eu incluso, estudam as definições matemáticas por trás das notações de linguagens, com o rigor que deveria, porque ferramentas como flex, bison, yacc simplificam tudo isso e a gente tem mais que se preocupar com o design da linguagem propriamente dita, que começa em escrever a tabela de lexemes e a gramática no formato que mostrei antes. Em particular, se tiver interesse em estudar mais sobre geradores de parsers, a que eu vejo que povo considera mais moderna é o ANTLR, que por acaso é feita em Java.\nSabe quando você carrega um arquivo texto de HTML num navegador e agora dá pra inspecionar usando as ferramentas de debug? Você que é de front-end sabe disso, ele se transforma no tal do DOM ou Document Object Model. E o que é o DOM? É uma árvore, é resultado de passar o HTML por um parser. E como o navegador desenha as coisas na tela? Navegando pode Node a Node do DOM. O DOM está pra HTML assim como AST está pra uma linguagem de programação. E da mesma forma que você pode modificar nós do DOM, o compilador manipula nós do AST pra melhorar seu código e gerar binários mais eficientes.\nTanto o que você chama de compilador quanto o que chama de interpretador começam com um lexer e um parser. Mas a história não acaba aqui. Agora vem a parte interessante da história. Lembra quando fizemos o disassembly do binário compilado de Java? Ele não era uma árvore né, era uma sequência de instruções, o que em Java se chama de bytecodes. Depois que o javac gerou o AST, checou que a sintaxe tá correta e as dependências estão corretas, daí navega nó a nó da árvore e cospe os bytecodes correspondentes pra gerar o arquivo ".class" no final.\nVamos recapitular, o que é um bytecode? É literalmente isso, um código de byte. Cada instrução como aquela aaload, iload, imul, iadd são mnemônicos pra um código binário. Por exemplo, aaload é o hexadecimal 32 ou o binário 0011 0010. Lembra, a máquina hardware, a CPU, só entende binário e internamente tem instruções que são representadas por certas sequências de bits.\nAssista o episódio de Hello World ou outros videos da série "Como Computadores Funcionam" pra relembrar disso. Mas agora vem uma pergunta, que diabos de instrução é isso de aaload, iload, imul. Isso não é assembly de x64, que é o que roda em Intel ou AMD aí no seu PC ou notebook. Também não são instruções de ARM como os Mac M1 ou Qualcomm do seu Android. Que diabo de instruções são essas? E aqui vem a parte que confunde a diferença entre um compilador puro e um interpretador. Essas instruções são pra uma máquina virtual que não existe em forma de hardware.\nA gente tá acostumado a pensar em máquina virtual só como um Virtualbox ou Parallels ou erroneamente um Docker - que não é máquina virtual. Pensamos como programas que podemos instalar num Mac M1 pra conseguir rodar outros programas compilados como binários de Intel e interpretar em tempo real pra rodar numa máquina ARM. Tecnicamente, toda máquina virtual é um interpretador, no sentido que ele interpreta uma instrução de uma máquina pra instrução de outra máquina.\nDentre várias coisas que podem ser diferentes é que normalmente quando falamos de interpretadores é quando temos algumas facilidades de desenvolvimento, como um REPL que é acrônimo pra Read-Eval-Print-Loop, que é a linha de comando que abre quando você digita python ou node no terminal e pode sair digitando código que ele vai executando imediatamente, ou seja, ele lê, faz evaluation, imprime o resultado e volta pro loop e fica nisso até apertar Ctrl+D pra sair. Aliás, a linha de comando do seu terminal, seja Bash, ZSH ou Fish, é um interpretador também.\nSendo mais específico, um interpretador costuma manter o AST num formato que podemos modificar, depois dos arquivos do programa terem todos passados pelo parser. Toda vez que dentro do console de Python a gente define um novo método, estamos adicionando nós na árvore AST. É isso que define o que muitos chamam de "linguagem dinâmica". Mesmo Java, apesar de mais chatinho, tem como modificar o AST que tá em memória. Eu posso mandar o classloader da JVM carregar outros arquivos ".class" que ainda não tinha carregado, ou usar a API de Reflection pra modificar o código em tempo real.\nClaro, apesar de parecerem máquinas virtuais, interpretadores são diferentes de um VirtualBox. Um VirtualBox da vida de fato tenta ao máquina esconder tudo sobre a máquina host por baixo, pra fazer os programas rodando dentro acreditar que estão numa máquina de verdade. Quando um programa lá dentro pede pra fuçar o disco, o Virtualbox vai dar pra ele um disco virtual e não acesso ao disco de verdade.\nQuando o programa pede pra conectar na internet, ele não vai ter acesso ao TCP da máquina de verdade, mas sim à uma rede virtual interna, como se fosse uma rede externa separada que faz ponte com a rede da máquina de verdade. E assim por diante. Já um interpretador não tenta esconder nada. Quando o programa de python pede acesso ao disco, o interpretador dá acesso ao disco de verdade. Quando o programa pede pra abrir um socket de rede, ele passa pela rede de verdade.\nJá vou voltar no assunto de interpretadores e máquinas virtuais, mas o importante é saber que depois da fase de parsing, o objetivo é transformar a árvore abstrata de sintaxe em instruções de máquina, seja lá pra qual arquitetura de CPUs: uma de verdade como x64 ou arm64 ou uma virtual como a JVM. A história não acaba aqui.\nMesmo o compilador de C como GCC ou o clang de LLVM não sai da AST depois do parsing e já transforma direto em instrução de Intel. Não, acho que hoje em dia praticamente todos os compiladores trabalham com uma representação intermediária. O compilador de DotNet, por exemplo, chama isso de Intermediate Language ou IL. No mundo LLVM isso se chama Intermediate Representation ou IR. No mundo do GNU Compiler Collection ou GCC que todo mundo conhece, ele trabalha com RTL que é o Register Transfer Language. No mundo de shaders como pra rodar em Vulkan no SteamDeck, existe o padrão Standard Portable Intermediate Representation ou SPIR-V. E o que diabos é isso de linguagem intermediária?\nAgora é a parte da mágica que eu falei antes que vou simplificar bastante, entenda que essa parte é absurdamente extensa na realidade. Vou usar o exemplo mais besta de todos. Lembra aquele exemplo da calculadora que escrevi em Java pra dar print em 1 + 2 * 3 e depois de compilar, fizemos o desassembly pra ver as instruções e só tinha um bipush direto do resultado 7? Pois é, o compilador foi inteligente em saber que não precisa traduzir instrução a instrução, a multiplicação e soma e, em vez disso, já pré-calculou e deixou direto o resultado, economizando várias instruções. Ou seja, ele otimizou o código e deixou tanto mais rápido quanto economizou ter que guardar os números 1, 2 e 3 na memória.\nEssa é a otimização mais trivial e besta de todas, mas o compilador tem a capacidade de fazer centenas de outras otimizações. Por exemplo, digamos que seu código tenha trechos que nunca usa. Dependendo da linguagem e agressividade da otimização, ele pode até escolher jogar fora esse trecho e nem traduzir. Sim, o compilador pode escolher jogar seu código fora. Ele pode simplificar chamadas. Se a ordem dos fatores não influir no resultado, pode mudar a ordem do seu código pra CPU processar de forma mais eficiente.\nEssa fase de otimização pode passar por todo o código mais de uma vez, é o que se chama de "passes". Isso pra conseguir fazer coisas como achar constantes duplicadas e fazer ambas apontarem pro mesmo lugar. Eliminação de código morto, ou seja, trechos que nunca são executados e podem ser eliminados. Tail Call elimination, pra remover chamadas recursivas que podem ser otimizadas. E muito, muito mais. Isso é o que o LLVM chama de Transformation Passes.\nEntre aspas é como se você tivesse um Linus Torvalds e um John Carmack juntos, reescrevendo seu código da maneira mais otimizada possível. Na prática essa etapa é o real trabalho de um compilador e onde se gasta mais tempo e mais recursos, porque tem um gerador de código varrendo tudo que você escreveu, exaustivamente, várias vezes, e reescrevendo da melhor forma que se conhece sem quebrar, nem gerar bugs.\nAgora, imagine o seguinte: tá vendo essa lista de transformações e otimizações? Imagine se toda vez que inventa uma nova linguagem, se precisasse reescrever todas essas estratégias tudo de novo pra linguagem nova. Seria um trabalho absurdo, que ia gerar dezenas de bugs, e as otimizações seriam ruins porque criar essas rotinas levou anos e milhares de horas homens pra aperfeiçoar até ficarem perfeitas. Por isso que o comum é que toda nova linguagem, no final do parsing, seja convertida numa linguagem intermediária, que é sempre igual. E essa linguagem costuma ser tipo um assembly pra uma máquina virtual, que não precisa se preocupar nesse ponto com as limitações de design e legado de uma CPU de verdade com um x64.\nDaí todas essas estratégias de otimização são executadas nessa linguagem interdiária. Um compilador como GCC ou derivados de LLVM na verdade são programas grandões que podemos dividir em 3 grandes funções diferentes. O primeiro é o front-end, que tem a responsabilidade de pegar linguagens como C, C++, Go, Rust, Swift e fazer o lexing, o parsing, gerar a árvore de sintaxe e dela cuspir as instruções de máquina virtual intermediária, sem quase nenhuma otimização. Essas instruções intermediárias são o RTL, no caso de GCC, ou IR no caso de LLVM, ou IL no caso de DotNet. O clang de LLVM seria o front-end de C pra LLVM, o conjunto das definições de lexer e gramática do parser.\nAgora o 2o programa pega esse IR não otimizado e gasta um tempão lendo, relendo e reescrevendo, e a saída vai ser outro IR agora totalmente otimizado. Esse programa do meio poderia ser chamado de "middle-end". E relembrando, cada uma das otimizações ou transformation passes que ele faz poderia ser tema de um paper de Ph.D. Não são coisas triviais como o exemplo que eu mostrei. E finalmente temos o 3o programa, que chamamos de "back-end", que vai pegar o IR otimizado e traduzir finalmente pras instruções da máquina de verdade, ou seja, converter de instruções assembly de IR pra instruções assembly de x64 ou arm64 da vida. E esse é o binário final que pode ser executado.\nQuando um designer de chips como uma Apple inventa um novo como os tais M1, ele só precisa fazer a parte back-end, a parte que pega o IR já otimizado e converte em instruções de máquina. Amanhã a Qualcomm lança um novo chip SnapDragon ARM, ele só precisa atualizar o back-end do compilador, todo o resto continua igual. A AMD lança a nova série 6000 do Ryzen, só precisa atualizar o back-end dos principais compiladores se teve alguma mudança nas suas instruções. Entenderam?\nEu expliquei isso no video de Apple e GPL, mas além obviamente do hardware, qual é o grande segredo da Apple em conseguir migrar tudo pra M1 tão rápido? É eles terem investido quase 2 décadas melhorando suas tecnologias de compiladores em cima de LLVM. Com isso conseguiram migrar de PowerPC pra Intel nos anos 2000 e com isso migraram de Intel pra ARM muito rápido. E tudo que só o compilador não consegue resolver, eles tem como desenhar no chip pra compensar. E com isso temos as performances absurdas que vocês assistem nos diversos reviews de como programas originalmente compilados pra Intel rodam liso em ARM sem recompilar, só sendo interpretados em tempo real.\nVou fazer outro exemplinho bem besta só pra vocês terem uma imagem na cabeça. Vamos voltar pro exemplo em Java de fazer um cálculo. Quem lembra como calcula a circunferência de um círculo? Lembra? Duas vezes Pi vezes Raio? 2 pi r. Então vamos fazer uma nova classe, método estático main, e System.out.print, 2 vezes 3.141592 etc que é PI mas vou colocar poucos dígitos pro exemplo, e vezes 10 que é o raio que quero usar. Salvamos, saímos, compilamos com javac, rodamos e voilá, 62.83 bla bla é a circunferência pra um raio 10.\nSe fizermos disassembly com javap olha aqui embaixo essa instrução ldc2_w que puxa uma constante do pool de constantes e manda pra stack, e no comentário gerado temos que essa constante é um double 62.83 bla bla que é o valor pré-calculado. Ele fez a mesma otimização que no caso do 1 + 2 * 3. Top, é o esperado. Mas como eu disse antes, olha como essa continha no código é feio, mesmo sendo simples. Quem curte código limpo tem gatilho só de ver isso. Dá pra melhorar isso.\nVamos escrever uma nova classe. Eu poderia começar definindo uma constante double chamada PI e escrever ali, 3.141592. Mas isso seria idiota porque obviamente Java já tem uma constante estática double de PI, que tá na classe Math. Ah, mas como eu ia adivinhar? Sempre pense: coisas triviais assim, as chances são que já existe. Na dúvida procurar no Google, "Java constant PI" e olha só, nos primeiros links já vem Math.PI. Quando você não acha as coisas não é que não existem ou são difíceis de achar, você que não procurou direito.\nEnfim, continuamos fazendo uma função estática que retorna double chamada circunferencia que recebe como argumento uma variável double chamada raio. Dentro calculamos o 2 vezes Math.PI vezes a variável raio. E agora sim, no método main vamos dar System.out.print, como antes, mas o argumento vai ser o resultado do método circunferencia passando o valor 10. Pronto, salvamos, saímos, compilamos com javac e executamos e tá aí, 62.83 bla bla como tinha dada na outra versão.\nCompara a versão antiga com a nova. Ficou maior, mas a intenção do código tá muito mais clara. Se daqui 1 mês eu for editar esse código, dá pra saber o que ele faz imediatamente. E claro, dava pra ter feito bem mais bonito que isso, fazer uma classe chamada Circulo ou um módulo chamado Geometria ou qualquer coisa assim, mas hoje não é design de orientação a objetos, então não impliquem muito com isso hoje.\nMas vamos ver como fica fazendo disassembly com javap e olha que estranho, tem a instrução ldc2_w que puxa a contante 10 que é o raio que eu defini e puxa pra stack, daí invoca a função circunferencia e dá jump aqui pra cima. Daí faz outro ldc2_w pra puxar a constante de PI pra stack também, na verdade a constante de 2 * Pi, veja o comentário que ele gerou mostrando que é o dobro de PI, então ele otimizou isso. Mas aí chama a instrução dmul que é multiplicação de double e desempilha os últimos dois valores que colocamos na stack pra calcular, retorna e finalmente dá invokevirtual no printf pra imprimir na tela.\nMas 2 * pi * 10 é tudo constante, porque ele não otimizou o suficiente pra arrancar fora essa função circunferencia, ela não seria desnecessária? Eu não disse que o compilador reescreve tudo pra ficar mais eficiente? Não dava pra ter pré-calculado como antes e só guardar a constante com o resultado final? Então, aqui que a coisa começa a complicar. Toda função que criamos no Java se torna uma interface. Se o compilador quisesse ser agressivo ele poderia arrancar tudo fora e deixar só a constante, porém a gente não sabe se ninguém mesmo vai usar essa função. Lembra? Java também é uma linguagem interpretada, dinâmica, cujo código pode ser alterado dentro da JVM.\nSe pensar isoladamente só nessa classe, não teria problema, mas classes Java não vivem no vácuo, elas foram pensadas pra serem reusadas. Por exemplo, no mesmo diretório posso criar um novo arquivo e escrever uma nova classe assim, fazendo de novo um System.out.print, chamando Calc3.circunferencia direto assim mesmo e passando 20 como raio. Se eu sair e compilar só esse arquivo calc5.java, posso executar java Calc5 e tudo funciona. Note que nem na hora de compilar e nem na hora de executar eu mencionei o Calc3, porque ele tá no mesmo diretório, então quando a JVM carrega a classe Calc5 automaticamente faz o Class Loader carregar o Calc3 junto. Mas ele não precisou recompilar o Calc3 de novo.\nE se eu apagar o Calc3.class e tentar executar o Calc5? Agora vai dar a erro de NoClassDefFound. Faz sentido né? Java foi feito de tal maneira que eu não preciso recompilar tudo do zero toda vez que alguma coisa muda. Ele compila cada classe individualmente, e pra garantir que outras classes não quebrem, pelo menos mantém a interface entre eles estável, o que significa que não pode sair otimizando demais e eliminando métodos, mesmo se naquela classe ela não é usada. E mesmo se eu tivesse declarado como private, ainda assim não daria pra apagar o método, porque Java tem sistema de Reflection que permite manipular métodos privados. Portanto, qualquer otimização que quebre a interface não pode ser feita.\nAntes de continuar, agora precisamos entender rapidamente o que é uma interface. No mundo binário, não existe o conceito de abstração, tudo são instruções e endereços. Quando precisa chamar uma função, a máquina na verdade vai guardar o endereço que estamos executando na pilha, vai fazer o jump, vai executar o que precisa, e no final vai retornar pro endereço que tinha guardado, pra continuar de onde parou. Eu expliquei isso no video do Hello World.\nAgora, pra isso funcionar, quando eu compilei a classe Calc3, o compilador precisaria ter anotado que a função circunferencia vai estar disponível num endereço X, faz de conta 9000 0000. Daí quando eu compilei a classe Calc5 que chama essa função, nesse ponto o compilador precisaria saber que precisa escrever um jump pro tal endereço 9000 0000. Mas lembram que eu não passei o Calc3 como parâmetro nem nada? Como que o Java sabe pra qual endereço tem que dar jump?\nAqui estou especulando, mas imagino que quando a JVM carrega essas classes, nesse momento que ela vai preenchendo uma tabela interna que diz, "ok, carregar classe Calc3, ela tem um método circunferencia, vou colocar ela no endereço que tem vago aqui, 9000 0000". Depois carrega a Calc5 e quando executa a função main dela e de lá pede pra chamar a função circunferencia, daí a JVM intercepta essa chamada e consulta sua tabelinha "hmmmm, essa função é a que eu coloquei no endereço 9000 000, pula pra lá". Portanto os endereços não estão nas classes, elas são atribuídas na hora que a JVM carrega elas.\nVamos abrir o disassembly de novo, começa executando lá da linha 0 e vai indo. Uma hora esbarra nessa linha 6, que tem um invokestatic passando um índice 15. Ele olha lá na tabela interna dele e vê "ah, número 15 é o endereço 9000 0000" e aí dá o jump pro lugar certo. Eu simplifiquei mas justamente porque os endereços finais são definidos quando carrega o módulo e não quando compila, dá pra compilar as classes independentes uma da outra, como eu fiz aqui, compilando individualmente os dois arquivos, porque a JVM é quem vai gerenciar os endereços em tempo de execução.\nPorém, linguagens como C, C++, Swift, Go, Rust, Crystal, e outras não tem um interpretador ou máquina virtual pra controlar isso, portanto cada parte de cada módulo sendo compilado precisa já saber o endereço final das coisas, senão na hora de executar não ia achar nada. Como que faz?\nE aqui vem outro conceito de compilador que vou simplificar ao máximo. Pensa, se eu tivesse um projeto com mil arquivos, onde uma função num arquivo pode chamar funções em outros arquivos, seria uma zona pra compilar. Toda vez que eu mudo uma linha num arquivo, precisaria recompilar todos os mil arquivos pra garantir que os endereços de todo mundo estão corretos e eu não apaguei uma função ou deu conflito de endereços ou duplicou endereços sem querer. Então na realidade, tanto o GCC quanto um clang de LLVM quanto um rustc de Rust, vão quebrar a parte final da compilação em duas etapas.\nEsses ".o" são objetos, simplificando, eles são os binários compilados a partir de código fonte de C de cada arquivo. Vamos abrir o hello.c lá do começo. Tão vendo esse include <stdio> na primeira linha, isso indica pro compilador procurar por um arquivo de cabeçalho chamado stdio.h que tem que estar no Path do sistema. Nesse arquivo vai constar a interface da função printf que usamos lá embaixo. Se olharmos nesse arquivo tá dizendo que o printf é uma função que retorna inteiro e recebe como parâmetro um ponteiro constante de char, basicamente um array de chars, e tem outros argumentos opcionais.\nSem entrar muito em detalhes sobre o C, ter essa interface permite o compilador saber se quando estamos usando a função printf, se tá da forma correta. Porém, no momento da compilação do arquivo hello.c pro objeto binário hello ele ainda não sabe qual é o endereço onde encontrar a função, porque ela tá numa biblioteca externa, a libc, que é compartilhada com outros programas no mesmo sistema que dependem dela. Praticamente tudo numa distro Linux.\nNo ponto onde chama o printf o compilador vai tipo deixar um post-it dizendo "confirmar depois onde fica esse endereço". Se eu dependesse de outras bibliotecas externas, ia ficar deixando vários post-its pra confirmar depois. Pra ilustrar, vamos fazer o disassembly do objeto hello usando o objdump -d. Olhar assembly sempre é meio intimidante, mas não tem problema, só focar no pedaço que interessa que é a função main que começa aqui a partir do endereço 1139 em hexa. O printf é uma função então estamos procurando um call.\nE no endereço 1147 temos um suspeito, um call, mas pra um endereço aqui perto, em 1030. Vamos ver o que tem lá. E olha lá, tem um jump pra esse outro endereço e um comentário que é pra função puts da glibc. Se não estou enganado, quando se chama o printf com o parâmetro opcional nulo, ele muda pra puts. Mas nessa linha, na primeira fase do compilador, quando ele ainda não sabe os endereços, vai ter algo como um espaço em branco pro endereço, um post-it pra segunda fase confirmar o endereço.\nEssa segunda fase é o trabalho de um linker, no caso do GNU LD. Até agora eu não precisei chamar o linker manualmente porque o GCC faz isso sozinho pra gente. Mas se eu quiser manipular vários objetos já compilados e transformar numa biblioteca compartilhada, como um .so de Linux ou .dll de Windows, posso fazer isso com o comando ld.\nInclusive, o linker pode fazer otimizações em tempo de linking. Apesar do nome ser linker que é linkar ou grudar os pedaços, ele pode modificar mais do binário. É ele que sabe se é possível por exemplo fazer inlining. Lembra o exemplo besta de Java de circunferência? Se fosse em C, como ninguém mais chama aquela função, ele poderia simplesmente copiar o conteúdo da função e colar no lugar onde a função é chamada. Isso evita no mínimo uma instrução de jump e outra de return. Num programa maior tem muito mais ganhos.\nNo final, o compilador de C consegue analisar seu código e realizar um monte de otimizações e reescrever de uma forma otimizada, mas isso arquivo a arquivo independentemente, daí o linker reavalia os binários gerados, liga os endereços de cada um onde precisa e ainda otimiza mais, o que diminui mais ainda o tamanho do binário, economiza mais memória e processamento na hora de executar, e por isso programas em C e similares como Rust são tão rápidos.\nQuando você carrega um projeto em Java, ele inicia a máquina virtual JVM, daí o class loader começa carregando os arquivos binários .class do seu projeto e criando tipo uma tabelona interna que diz em quais endereços internos na memória estão quais classes e quais funções, de forma que quando uma classe pede pra executar uma função de outra classe, a JVM vai intermediar e arbitrar mandando executar a função correta, devolvendo o retorno e tudo mais.\nUm interpretador ou máquina virtual substitui a necessidade de um linker estático, porque ele cuida disso dinamicamente. Então você pode imaginar que o C, que não tem esse intermediário já precisa saber de antemão o endereço de tudo. Se de fato toda vez a JVM precisar ficar checando os endereços nessa tabela virtual pra cada chamada de função, seria tudo lento mesmo. Mas claro que no mínimo ela faz cache disso pra ir mais rápido. Mas ela pode fazer mais. Ela analisa os códigos mais executados, por exemplo baseado em quais caches são mais pedidos, os "pontos mais quentes" do programa, literalmente o HotSpot, que é o nome da máquina virtual de Java quando ele ganhou capacidades de just in time compiling, ou JIT.\nSe meu programa chamasse aquela função circunferencia diversas vezes sempre com o mesmo raio, em vez de toda vez executar o cálculo, o JIT vai ser esperto e cachear o valor final. Muitas das otimizações que eu falei que o linker faz no C em tempo de compilação, o JIT vai fazer durante a execução. Por isso que em Java você já tenha ouvido falar de "tempo de aquecimento", ou warm up. Logo que inicia um servidor Java, ele vai ter uma performance X que pode até parecer baixa, mas deixe rodando um tempo, e o mesmo código começa a executar mais rápido. O JIT é um otimizador em tempo real, aplicando mais e mais otimizações nos códigos mais acessados.\nEsse JIT, no final, tá traduzindo o bytecode do Java em instruções nativas de máquina de verdade mais otimizadas. É literalmente um compilador e mais ou menos um linkeditor que só trabalha em cima de código que realmente é necessário. Se seu programa for grande e tem partes que raramente são acessados ou ninguém nunca acessa, eles continuam lá sem serem otimizados. E o JIT vai fazendo cache do que vai otimizado, assim da próxima vez que alguém chamar essa parte, ele só executa o binário nativo de novo. E nesse ponto, esse trecho do código pode estar quase tão rápido como se tivesse sido escrito em C. Claro, não é só isso que determina a performance final, mas o JIT diminui bastante a distância entre traduzir bytecode Java de forma interpretada e um binário nativo compilado de C.\nUma ver convertido em bytecodes, o interpretador do V8, que se chama Igniter, começa a traduzir instrução a instrução. Não vai ser lento, mas também não vai ser a melhor performance. Assim como na JVM, ele vai ficar analisando a execução e perceber quais partes precisa otimizar. Digamos que sua aplicação web baixou trocentas bibliotecas, por exemplo o arquivo inteiro do jQuery. Mas na real você só precisa da função $() pra achar um elemento da página e a função fadeToggle pra criar uma transição animada de fade desse elemento. Todas as outras funções você não usa.\nA vantagem de C é que os compiladores amadureceram muito nos últimos 40 anos e o binário nativo final que geram tendem não só a serem os mais rápidos em geral, mas também a ocupar bem menos espaço em disco e a consumir menos memória quando carregam. Por isso que a kernel do Linux, drivers e coisas assim tendem a serem feitos com C, porque eu quero o mais otimizado possível e que escale bem, pra rodar tanto num servidor de datacenter com centenas de núcleos de processador e terabytes de RAM quanto num mero Raspberry Pi com quase nada de recursos.\nUma vez que o binário tá compilado estaticamente, é tudo fixo e imutável, você não tem como mudar o comportamento dele. Sim, se tiver muita paciência pra explorar coisas como injeção de código direto na memória do processo ou fazer patches de binários, explorar exploits de segurança, aí você consegue mudar alguma coisa. Mas isso é na gambiarra. É o que a comunidade de mods de games faz também. Eles descobrem em qual endereço da memória que fica o valor de vidas e eu injeto outro valor lá. Já mostrei isso no video do Super Mario.\nA grande vantagem de linguagens dinâmicas é permitir esse tipo de flexibilidade. Se isso é bom ou ruim, depende do seu uso. Tem gente que acha que isso não deveria ser permitido, que uma vez compilado, deveria ser tudo fechado. Tem gente que acha que precisa ser tudo aberto, independente se vai ficar mais lento ou consumir mais memória. Como eu sempre digo, em programação a gente troca uma coisa por outra, sempre. Não existe resposta definitiva, tudo depende de pra que vai usar. E no caso de um navegador web acho que todo mundo vai concordar que ser aberto e dinâmico é muito mais prático e é por isso que a Web em si fez tanto sucesso.\nPra não complicar vou pular os detalhes sobre metaprogramação e a diferença com pré-processamento estático, templates como em C++, ou macros como em Rust. Estudem se tiver interesse, mas a conclusão de tudo isso é dizer que linguagens estáticas costumam ter um compilador que gera binários estáticos, cujo bytecode não é mais modificado facilmente. Linguagens dinâmicas costumam ter um interpretados justamente pra ter essas propriedades de dinamicamente modificar o bytecode e alterar o comportamento do programa em tempo real de execução. O custo disso é serem mais lentos, porque não puderam contar com a otimização agressiva de um compilador e linkeditor.\nMas hoje em dia essa diferença diminuiu drasticamente, porque quase todo interpretador vem com um compilador embutido que roda em tempo real, um Just in time compiler, ou JIT. No fim do dia, ambos acabam gerando binário nativo otimizado, um gera tudo antes, o outro gera enquanto roda. Um usa menos recursos, porque fez toda a compilação e otimização antes, e o outro usa mais recursos, porque vai continuamento compilando à medida que o programa é executado.\nComo o video ficou super longo já, no próximo video vou dar uma pincelada em cada linguagem individualmente, mas antes vocês precisavam entender a diferença entre compiladores e interpretadores. Ser interpretado não implica ser sempre "lento", só às vezes. Um exemplo, quem já ouviu falar de Elixir e Erlang provavelmente reconhece sua reputação de ser altamente escalável, tanto que é com ele que é feito o motor de comunicação por trás do Whatsapp, que é gigantesco. Mas nem todo mundo entende que Erlang, assim como Java, é uma linguagem interpretada, que roda numa máquina virtual, que é um tipo de interpretador, e que tem um Just in Time Compiler, ou JIT, pra acelerar as coisas.


Nos dias 29 e 30 de maio, o Câmpus Feliz realiza a 1ª Semana Acadêmica das Licenciaturas. O objetivo do evento é compartilhar saberes relacionados às áreas de Letras e Química, proporcionando momentos de reflexão, discussão e vivências das práticas pedagógicas. Podem participar professores, alunos de magistério, de licenciatura em Letras ou Química e demais interessados.\nA abertura da 1ª Semana Acadêmica das Licenciaturas ocorrerá no Centro Cultural de Feliz, no dia 29 de maio, a partir das 18h15, conforme programação abaixo. Na ocasião, o doutor em Educação e professor da Universidade Federal da Fronteira Sul, Thiago Ingrassia Pereira, ministrará a palestra "Os desafios da escolha pela docência". Além disso, haverá apresentações culturais dos alunos da Escola Especial Um Sorriso a Mais (Feliz) e da Orquestra de Sopros de Feliz.\nAs atividades prosseguem no dia seguinte, nos turnos da manhã e tarde (das 8h às 17h), com palestras e oficinas.\nA 1ª Semana Acadêmica das Licenciaturas é gratuita e as inscrições devem ser realizadas até as 18h do dia 29 de maio, clicando aqui. As vagas são limitadas. Para obtenção de certificados é necessário o mínimo de 60% de presença.\n29 de maio - Centro Cultural de Feliz\n19h - Apresentação cultural de alunos da Escola Especial Um Sorrido a Mais, de Feliz\n19h45 - Apresentação da Orquestra de Sopros de Feliz\n20h15 - Palestra "Os desafios da escolha da docência", com Dr. Thiago Ingrassia Pereira\n21h45 - Espaço para intervenções\n30 de maio - IFRS - Câmpus Feliz\n- Oficina de criação literária - Marcelo Almeida, jovem escritor gaúcho.\n- Oficina "Ser professor" - Ana Paula François, Andréia Antich, Michele Mendonça, Rúbia Emmel (IFRS - Câmpus Feliz)\n- Oficina "Letramento literário: desafios e práticas", Gabriela Luft (IFRS - Câmpus Porto Alegre)\n- Palestra "Radiações: o que temos a ver com isso?", Tania Denise Miskinis Salgado (UFRGS)\n- Oficina "A gramática tradicional e o ensino de língua portuguesa", Marcelo Calixto (IFRS - Câmpus Feliz)\n- Oficina "Ser professor", Ana Paula François, Andréia Antich, Michele Mendonça e Rúbia Emmel (IFRS - Câmpus Feliz)\n- Oficina "Eletroquímica: atividades práticas", Vera Lúcia Peixoto Mallet.\n- Oficina "Interface entre a Literatura e a arte na contação de histórias", Izandra Alves (IFRS - Câmpus Feliz) e Lilian Cordeiro - (IFRS - Câmpus Ibirubá)


DIA SEM PAIS\nA minha perspectiva sobre o dia dos pais sempre foi, de certa forma, uma perspectiva de ausência. De falta, não; figuras masculinas não me faltavam, nem eventos para celebrar o “dia dos pais”, e é um tanto difícil alguém sentir falta de algo que nunca teve. Mas a ausência, essa estava ali – e o dia dos pais era só um lembrete a nível nacional de que ela existia.\nEssa realidade está longe de ser exclusiva minha. Em um país em que existem mais de 11 milhões de mães solo (IBGE), a paternidade é assunto que ainda carece de muita reflexão. Sob a égide da ideologia patriarcal e compulsoriamente heterossexual que permeia as nossas estruturas sociais atuais, ter (ou ter tido, em algum momento) um pai não é condição sine-qua-non de ser filha. Perceba: não estou dizendo aqui de ser órfão, não; estou dizendo de progenitores que optam por não viver a paternidade. Confesso que isso me faz questionar mesmo se justifica a existência de um DIA DOS PAIS, já que a data é um lembrete tão desconfortável pra tanta gente… ou talvez isso contribua para que o dia dos pais seja ainda mais justificado, uma vez que, já que tantos abrem mão da função, os bravos heróis que assumem seu posto precisam ser celebrados.\nPessoalmente, eu fico com a primeira opção, especialmente quando o contexto é composto por uma maioria de progenitores heterossexuais em cujos relacionamentos, na maioria das vezes, a ausência de um pai é o fardo de uma mãe. Mais do que os desafios que o processo de criar um novo ser impõe em si mesmo, o fardo social não demora a dar as caras. Os sintomas de uma sociedade machista chegam em forma de ataque a essas mães, através do cerceamento de seu corpo, de seu tempo, de sua atenção, de suas prioridades, de suas vontades. A mãe que tem um pai presente já não pode mais ser outra coisa que não mãe; a mãe que não o tem, menos ainda. Nesse aspecto, felizes mesmo são as mães sáficas.\nO fardo social do título de mãe não dá descanso nem quando o dia é dos pais. Me lembro bem de dias dos pais da minha infância, e que só posso imaginar o que minha mãe sentia ao me ouvir, aos cinco anos, dizer da ausência do meu pai com tanta naturalidade. Pois bem, era natural pra mim dizer “ah, o meu pai não vem, mas a minha mãe vem” quando me perguntavam quem vinha na celebração da data; mas sempre foi chato. E eventualmente, eu comecei a perceber o quanto esse e tantos outros aspectos decorrentes da ausência do meu pai eram socialmente chatos. Me tornei uma filha provida de amplo cansaço e profunda indiferença frente a qualquer questão paterna (ainda que me esforçasse contra isso).\nExiste um provérbio africano, acho, que diz que “é necessária uma vila inteira para se criar uma criança”. Na minha vila, como na de inúmera crianças, não tinha um pai. E por mais que me alegre ver a relação de pessoas cujos pais estiveram em suas vilas, sinto que esse lance de ‘dia dos pais’ é só mais um jeito de exaltar quem não faz mais que sua obrigação, de transformar o que seria o mínimo em algo extraordinário.\nHoje, pela primeira vez em anos, um dia dos pais foi leve pra mim; quando se é orfã, o peso da obrigação social de celebrar alguém que não fez questão de fazer parte da sua vila some. Sempre me entristeceu, em algum nível, que eu sentisse tão pouco pelo meu pai; mas faz todo sentido: orfã ou não, a minha família permanece a mesma. Desenvolver sentimentos como os que eu gostaria de sentir por ele, como os que eu sinto pela minha ‘pãe’, demandaria que ele tivesse se proposto a ser família para mim.\nNo mais, penso que celebrar as pessoas que nos dão apoio e suporte e carinho é essencial. Se o seu pai é uma dessas pessoas, celebrá-lo não demanda uma data; todo e qualquer dia é uma oportunidade.\nPostado em Ano 003, N 103, Carol CadinelliCom a tag Carol Cadinellipor ArtebodoqueDeixe um comentário\n← A SOCIEDADE DA VIGÍLIA E OS SUJEITOS DO PROCESSO\nNOTA SOBRE OS PASSADOS QUE NUNCA EXISTIRAM →


28/03/2008 - JF Nosso Bairro\nFanton era madeireiro\nO nome dado � escola do bairro Santo Antonio, Jos� Fanton, foi por sugest�o do filho Lidovino Fanton. Sua inten��o era prestar uma homenagem ao pai, "o grande batalhador", que com seu empenho, impulsionou o progresso e o crescimento de Farroupilha, ora como empreiteiro de corte, ora como fornecedor de combust�vel para os trens.\nJos� Fanton era filho dos imigrantes italianos Carlos Fanton e Paulina Chiele Fanton e nasceu em 1886, em Linha Vicentina. At� os 18 anos trabalhou com seus pais na agricultura. Com a morte deles e o casamento de suas irm�s, Elvira e Estela, mudou-se para a Linha S�o Luiz, onde comprou terras. Nesta �poca passou a trabalhar como empreiteiro de corte na constru��o de estradas de ferro, realizada pela Companhia B�lgica. Trecho este de Montenegro a Caxias do Sul, ramal de Carlos Barbosa, Garibaldi e Bento Gon�alves.\nConclu�das as obras (1910), a Companhia B�lgica abriu uma concorr�ncia p�blica para fornecimento do combust�vel para a Maria Fuma�a, como lenha, n� de pinho e os dormentes para a conserva��o da estrada. Jos� Fanton ganhou a concorr�ncia. A partir desta data, passou a se dedicar ao trabalho de fornecedor de combust�vel � base de lenha e n� de pinho � Via��o F�rrea. Tinha passe livre para viajar em qualquer trem, no trecho de Porto Alegre a Bento Gon�alves. Foi um grande incentivador e conscientizador do povo da regi�o, na planta��o de pinheiros.\nEm 1908 casou-se em Nova Milano com Vicenza Paraboni, com a qual teve seis filhos: Assunta, Carlos, �ngelo, Lidovino, Ger�nimo e Paulina. Descendente de italianos, possu�a um g�nio muito forte e era semi-analfabeto. Entretanto, com �tima vis�o para os neg�cios.\nViajava muito e em uma dessas in�meras viagens a Porto Alegre, dia 16 de setembro de 1932, morreu tragicamente na Via F�rrea, com apenas 46 anos de idade.\nDos filhos de Jos� Fanton, o que foi mais longe em termos de notoriedade e de realiza��o pol�tica, sem d�vida, foi Lidovino Antonio Fanton. Ele nasceu em 1920, em Farroupilha. Conclu�do o curso prim�rio e com apenas 16 anos, resolveu ir embora para Porto Alegre, onde conseguiu um emprego nos escrit�rios da Via��o F�rrea.\nEnquanto mantinha em Farroupilha seu escrit�rio de advocacia, militava na pol�tica estadual. Em 1962, foi eleito Deputado Estadual, sendo reeleito por mais duas legislaturas. Tamb�m foi eleito Deputado Federal por duas vezes seguidas. Lidovino Fanton faleceu em 12 de setembro de 1982.


A identidade da Catequese no Diretório Geral para a Catequese (parte 4) - Fundação Nazaré de Comunicação\nA identidade da Catequese no Diretório Geral para a Catequese (parte 4)\nO Concílio Ecumênico Vaticano II (de 1962-1965), muito sensível às questões derivadas da evangelização, pediu a elaboração de um Diretório para a orientação da catequese em todo o mundo com o objetivo de estar a serviço do Povo de Deus contribuindo para o fortalecimento da comunhão da Igreja.\nO Papa Paulo VI, atendendo a esse pedido, convocou uma comissão internacional de teólogos que ficou com a responsabilidade da elaboração desse documento, coordenada pela Congregação para o clero. O trabalho foi concluído e o primeiro Diretório foi promulgado em 1971 pelo referido pontífice.\nCom o passar dos anos, devido mudanças socioculturais, com novos documentos da Igreja como as Exortações Apostólicas Evangelii Nuntiandi (1975), Catechesi Tradendae (1979) e o Catecismo da Igreja Católica, sentiu-se a necessidade da atualização da primeira versão.\nO Diretório Geral para a Catequese (DGC) é um documento da Congregação para o clero, aprovado pelo Papa São João Paulo II no ano 1997. Essa já é a segunda versão.\n1 – A estrutura e importância do DGC\nO referido documento é de fundamental importância para toda a Igreja por muitos motivos. Antes de tudo, revela a grande preocupação da Igreja para com a catequese com sua exigência fundamental de unidade e comunhão na fé e na vida eclesial.\nPor outro lado, é necessário que haja clareza na exposição dos princípios fundamentais da evangelização e da catequese para que possam iluminar o processo de inculturação da fé e do encontro com Jesus Cristo, nos mais variados contextos socioculturais do mundo entre povos e culturas diferentes, mas conservando a fidelidade doutrinal e moral.\nCada Conferência Episcopal, a partir da sua própria realidade, foi convocada a traduzi-lo em Orientações específicas aplicando-o à própria realidade. Dessa forma, na 43ª Assembleia Geral da CNBB em 2005, foi aprovado o Diretório Nacional da Catequese (Documento 84).\nO atual DGC é composto por uma introdução, quatro partes e uma conclusão. Na exposição introdutória, apresenta-se os desafios do anúncio do evangelho no mundo contemporâneo, com seus múltiplos contextos e dimensões. Os evangelizadores e catequistas de toda a Igreja são chamados a identificar os clamores humanos onde se encontram, em todas as culturas e povos, bem como a perceber a sensibilidade religiosa do povo e a sua situação moral. A catequese autêntica e profunda estimula processos de conversão das pessoas.\nA segunda postura a ser cultivada pelos catequistas e evangelizadores é o cultivo de um olhar de fé, sereno, crítico, profético e cheio de esperança sobre a própria comunidade eclesial, avaliando a situação geral da catequese com suas conquistas, problemas, desafios, necessidades de mudanças e potencialidades.\n2 – Catequese, revelação e processos (I parte)\nA primeira parte do DGC, com três capítulos, retoma a convicção de que a catequese não nasce a partir da vontade da Igreja, mas é sinal de fidelidade a Jesus Cristo. É consequência da missão evangelizadora da Igreja que lhe foi confiada por nosso Senhor. O mandato missionário exige o aprofundamento dos dados da Revelação de Deus à humanidade, através do processo de assimilação das palavras, gestos, feitos e atitudes de Jesus.\nCristo é o mediador e, ao mesmo tempo, a plenitude da Revelação de Deus. A Transmissão de tudo aquilo que nos foi revelado através da pessoa de Jesus Cristo, constitui a missão da Igreja e é conduzida e animada pelo Espírito Santo. A Igreja nada nega e nem acrescenta. Por isso Jesus afirmou: ”o Espírito vai receber daquilo que é meu, e o interpretará para vocês” (Jo 16,15).\nAssim como Deus se revela processualmente ao longo da história até chegar à sua plenitude na pessoa de Jesus de Nazaré, da mesma forma, acontece também com a evangelização e a catequese. Não se pode pensar em evangelização e catequese que não respeitem processos. Começa com a qualidade do anúncio da Palavra com suas múltiplas funções e formas de ministérios em vista da promoção da fé e da conversão dos fiéis. Muitas vezes a assimilação dos conteúdos da evangelização depende também dos meios, atitudes e linguagem dos catequizadores que devem atuar em sintonia com as situações sociorreligiosas de cada contexto. Sem a assimilação da Palavra de Deus não há conversão. É necessário pensar a conversão como processo permanente de crescimento na santidade.\nA Catequese está a serviço da promoção da iniciação à vida cristã, que implica uma diversidade de processos, experiências de vida, compromissos, formação de convicções. Por isso, a catequese é serviço da educação permanente à fé, que gera atitudes novas promovendo conscientes discípulos de Jesus Cristo e favorecendo-lhes o engajamento na vida comunitária. Esse processo de múltiplas experiências pode ser estimulado pelo ensino religioso escolar, testemunho de fé da família, a piedade popular.\nA catequese, tendo como finalidade a comunhão com Jesus Cristo, exige a profissão de fé no único Deus trinitário, o Pai, Filho e Espírito Santo; a mesma sendo um processo permanente de educação à fé, abraça todas as fases da existência humana tendo como tarefa fundamental ajudar o fiel a conhecer, celebrar, viver e contemplar o mistério de Cristo.\n3 -A Catequese tem normas e critérios (II parte)\nA Catequese por ser a apresentação da mensagem evangélica que estimula a conversão em vista da salvação do fiel, é orientada por normas e critérios. Se, em algum contexto os critérios normativos não forem levados a sério, a catequese perde a sua consistência. São critérios já extensivamente apresentados em diversos documentos do Concílio Vaticano II e pós-conciliares. Recordemos alguns desses critérios normativos apresentados no DGC:\n– A Palavra de Deus é a fonte da catequese e é inseparável da Tradição da Igreja;\n– A apresentação da pessoa de Jesus Cristo deve constituir o centro da vida da catequese;\n– A catequese não se ocupa meramente com o estudo dos mistérios da fé, mas é a apresentação da mensagem da Salvação e, por isso, tem força capaz de gerar libertação, conversão, vida Nova;\n– A catequese deve estar sempre profundamente vinculada à vida da Igreja (eclesialidade), por isso deve estimular o sentido de pertença e o engajamento eclesial;\n– A catequese tem uma dimensão histórica, seja por sua origem como também por seu dinamismo transformador (ser Sal e Luz), por isso não pode estar desencarnada da realidade, eis porque é importante a inculturação;\n– A catequese autêntica deve zelar pela integridade do aprofundamento da mensagem evangélica, isso significa que nenhum aspecto do mistério de Cristo deve ficar alheio à catequese;\n– A catequese, orientada pelo critério da integridade, preserva a organicidade da exposição dos conteúdos da fé e respeita a hierarquia deles;\n– A catequese é chamada a ser fiel à pessoa, respeitando, sobretudo o processo de desenvolvimento humano, fazendo uso de métodos, linguagem e atividades mais adequadas;\n– A catequese deve se orientar por aquilo que propõe a Igreja já presente no Catecismo da Igreja Católica; o aprofundamento das verdades da fé, a partir de cada realidade, não pode contrariá-lo, apesar da possibilidade da liberdade e da criatividade; deve haver uma fidelidade dinâmica em sintonia com os mistérios da fé professados pela Igreja.\n1 – Qual e a importância do Diretório Geral da Catequese para os Catequistas?\n2 – Por que a Igreja define normas e orientações para a Catequese?\n3 – Por que os catequistas devem identificar os clamores humanos onde se encontram?


DPU-PR realiza processo seletivo para estágio em Direito\nquarta-feira, 28 de novembro de 2018, às 21:51\nA Defensoria Pública da União no Paraná (DPU-PR), através do CIEE, realiza processo seletivo para estágio na área de Direito. O aprovado e contratado terá remuneração de R$ 800,00, mais auxílio transporte no valor de R$ 8,00 por dia.\nO certame é destinado ao preenchimento inicial de 02 vagas e formação de cadastro reserva para a 2ª Categoria da DPU em Curitiba. Para ingressar no programa de estágio é necessário estar matriculado a partir do quarto semestre do curso de Direito quando convocado para firmar o Termo do Compromisso de Estágio.\nAs inscrições devem ser efetivadas através do www.cieepr.org.br, com prazo final marcado para 31 de janeiro de 2018. Não haverá cobrança de taxa.\nO concurso de caráter eliminatório e classificatório, será composto de uma prova contendo (20) vinte questões objetivas e (01) uma questão discursiva. A aplicação ocorrerá no dia 10 de fevereiro de 2019, às 10:00 horas, na UNICESUMAR - Rua Itajubá, 673 - Portão, Curitiba - PR.\nO gabarito será divulgado no dia 11 de fevereiro de 2019 e resultado final deve sair até o dia 21 de março de 2019. As publicações serão através do www.cieepr.org.br. É responsabilidade do candidato conferir a íntegra do edital e acompanhar possíveis mudanças em datas e demais itens.\nA validade do processo seletivo é de seis meses, a contar da data da homologação do resultado final, podendo ser prorrogado. edital do processo seletivo\nCIEE , DPU , Estágio , Estágio em Direito , Paraná


Enterprise Servicios Hospedagem Web Na Nuvem | LiquidNet Ltd Hosting\nAo guardar aplicações, correios eletrônicos e bases de dados em alguns servidores e não um autónomo, tratámos de assegurar uma infraestrutura de hospedagem na nuvem com muito maior estabilidade para seus websites e programas. Também, buscámos minimizar a vulnerabilidade dos servidores perante ataques de piratas/DDoS os quais tencionam derrubar o servidor das soluções tradicionais de hospedagem de recursos conjuntos.\nDado que você tem um banco de dados que precisa usar compartilhadamente entre vários sítios web hospedados em vários servidores e com diferentes provedores de hospedagem, valha-se da nossa funcionalidade MySQL remoto. Mediante este, será possível assentir conexões ao seu banco de dados para todo tipo de sítios eletrônicos de confiança. Este é um procedimento conveniente se você é dono de uma base de dados de usuários que precisa usar compartilhadamente entre várias lojas virtuais.\nPor meio do Gerenciador de Bancos de Dados incorporado no Painel De Controle, pode superintender todos os seus os bancos de dados com prontidão e eficácia. Você será capaz criar bancos de dados novinhos com apenas alguns cliques. Graças às estadísticas pormenorizadas da utilização dos recursos do MySQL, já poderá ver quais são aqueles bancos de dados que têm maior taxa de utilização.\nFizemos um agente que habilita você a criar backups dos seus bases de dados com um único clique. Dessa forma, você nem precisa iniciar sessão no menu de de phpMyAdmin.


Como o serviço ao consumidor ainda é ineficiente no Brasil – O mundo de Maria\nMaria Wang\tem 1\t 18/08/2008 862 palavras\nEnviei o seguinte e-mail ao Wal-Mart no dia 19/07/2007 (com cópia para abpinhe@wal-mart.com e\nNo dia 22 de julho recebi uma resposta de Isabel Veloso, em que me agradecia pelo contato e informava que minha reclamação havia sido encaminhada para o “diretor do WAL MART SUPER CENTER – INDIANOPOLIS, para as devidas providencias”. Até hoje não obtive resposta do tal diretor nem de outros dirigentes da empresa. Enquanto isso, não piso na loja. Nem eu nem meu marido. Já até expliquei para meu filho, que adorava ficar no Espaço da Criança, a razão de estarmos frequentando outros supermercados. Sei que isso possivelmente não faça a mínima diferença para o Wal-Mart de Indianópolis. Mas faz para mim. Se todos os consumidores que se sentirem lesados adotassem atitudes semelhantes, o descaso com o antendimento ao consumidor certamente seria menor. Duvido que o Wal-Mart faça algo semelhante com seus consumidores dos Estados Unidos, por exemplo.\nPrezado senhores Adriano Pinheiro e Vicente Trius, como vão?\nSomos consumidores freqüentes do Wal-Mart São Judas, em São Paulo-SP, desde a época em que a loja foi inaugurada no bairro. Durante esse período, já passamos por alguns aborrecimentos, mas nada comparado com um episódio ocorrido hoje, sábado, 19/07/2008, por volta das 19h.\nColoquei em meu carrinho de compras uma badeja de filé de abadejo, da marca Bom Peixe, que estava em uma gôndola em que havia um cartaz comparando o preço do produto no Wal-Mart com o preço do mesmo produto no Pão de Açúcar. O anúncio dizia que no Pão de Açúcar o quilo daquele produto custava R$40,00 e no Wal-Mart, em promoção, custava R$16,00 o quilo. Meu marido resolveu checar o preço pelo código de barras e constatou que o valor do produto por quilo era por volta de R$ 35, já que uma bandeja com 800g custava R$28,00.\nComo havia o anúncio na gôndola informando sobre a promoção do produto por R$ 16,00 o quilo, resolvi levar o peixe e no check-out explicaria a situação ao caixa e pediria para falar com o gerente ou encarregado do setor, para passar o produto pelo valor anunciado. Fui informada que teríamos de falar com o senhor Diogo.\nO gerente Diogo foi chamado pelo sistema de comunicação interno da loja e esperamos por mais de 30 minutos no caixa, em pé, e ele não apareceu. Depois de muita insistência para falar com alguém que autorizasse a compra do produto pelo valor anunciado, fomos avisados de que o gerente estava em uma reunião. Já estávamos dispostos a deixar a loja sem levar o restante das compras, no valor de R$ 257,00, quando o assistente que anda de patins pela loja passou uma espécie de “cartão de autorização” para que a caixa pudesse liberar a mercadoria pelo valor anunciado.\nAlém de nos sentirem totalmente desrespeitados como clientes e em nossos direitos de consumidor, o que mais nos impressionou negativamente foi o fato de esse “mal-entendido” parecer não ser acidental. Ou seja, a impressão que tivemos foi a de que alguém do Wal-Mart adota esse tipo de estratégia contando que os consumidores não notarão a diferença entre o preço anunciado e o preço cobrado no caixa. Tanto assim que, depois de mostrar para o peixeiro ele rapidamente disse que não era aquela marca de peixe e sim outra marca visivelmente inferior. Nos mostrou a gôndola da segunda marca do produto, que estava distante mais de 5 metros da gôndola em que estava disposta a placa com o anúncio sobre o filé da marca Bom Peixe.\nFicamos também muito desapontados pela indiferença com que o gerente aparentemente tratou o caso. Eu estava com meu filho de cinco anos se queixando de fome e querendo voltar para casa. Um casal atrás de nós na fila, com duas crianças, também foi afetado pela situação, e teve de retirar todas suas compras da esteira para passar em outro caixa. Ficamos mais de meia hora esperando pelo gerente que sequer apareceu.\nSenhores, sou jornalista há 15 anos e durante um período de minha carreira escrevi reportagens para revistas de varejo supermercadista. Minha impressão é que, naquela época o Wal-Mart era mais cuidadoso com o treinamento de seu pessoal.\nSe eu fosse gerente de uma loja como esta, proporia um procedimento padrão para que o caixa resolvesse imediatamente problemas semelhantes. Sei que é possível que alguns clientes se aproveitassem da situação para tirar vantagens. Mas tenho dúvidas se o Wal-Mart perderia mais do que o faz tratando seus clientes leais, como nós, que compramos quase toda semana em sua loja, da forma com que fomos tratados.\nCom este e-mail, registramos nosso descontentamento com a forma com que fomos tratados numa loja do Wal-Mart e esperamos que outros clientes não tenham de passar por situações semelhantes no futuro.\nWal-Mart se desculpa\nUm comentário sobre “Como o serviço ao consumidor ainda é ineficiente no Brasil”\n04/09/2008 às 14:30\nSerá que só desculpas são validas???? Veja o meu caso então:


TenisBrasil - Stosur vence apenas um game e desiste no 2º set fiogf49gjkf0d\nSamantha Stosur, Eugenie Bouchard, Jelena Jankovic, Julia Goerges, Stefanie VoegeleCopa Davis" /> fiogf49gjkf0d\nSamantha Stosur, Eugenie Bouchard, Jelena Jankovic, Julia Goerges, Stefanie VoegeleCopa Davis" lang="pt-BR" xml:lang="pt-BR" /> fiogf49gjkf0d\nSamantha Stosur, Eugenie Bouchard, Jelena Jankovic, Julia Goerges, Stefanie Voegeletênis" /> fiogf49gjkf0d\n2013/stosur/0404_charleston_olhabola_int.jpg" /> fiogf49gjkf0d\nStosur vence apenas um game e desiste no 2º set\n05/04/2013 às 09h57\n2013/stosur/0404_charleston_olhabola_int.jpg" title="Proteção na perna direita não manteve Stosur até o fim" />\nProteção na perna direita não manteve Stosur até o fim\nCharleston (EUA) - Terceira mais bem cotada para o título no Premier de Charleston, a australiana Samantha Stosur teve a sorte de conseguir jogar apesar da chuva, que adiou metade das oito partidas programadas para a quinta-feira. Contudo, a parte positiva parou por aí, uma vez que ela precisou abandonar o duelo com a canadense Eugenie Bouchard por conta de problemas na perna direita.\nCom apenas 19 anos, Bouchard se aproveitou do problema da australiana e abriu confortáveis 6/1 e 2/0 até que Stosur resolvesse desistir da partida. Esta foi a primeira vez que a jovem canadense, atual campeã juvenil de simples em Wimbledon, deixou pelo caminho uma rival do top 10. Sua próxima adversária no torneio é a também gabaritada Jelena Jankovic, da Sérvia.\nJankovic foi a primeira a entrar em quadra após a chuva e despachou a norte-americana Jessica Pegula em sets diretos, com parciais de 6/0 e 6/4. Esta será a primeira vez que a ex-número 1 do mundo irá enfrentar Bouchard, que atualmente ocupa a 114ª colocação no ranking, a melhor de sua carreira, mas que com a campanha em Charleston vai entarar no top 100, 19 posições acima da atual.\n"Acredito que possa bater essas jogadoras. É o momento de acontecer", comemorou Bouchard, que não foi a única zebra do dia. Quem também derrubou uma favorita foi a suíça Stefanie Voegele, responsável pela eliminação da cabeça de chave número 10, a alemã Julia Goerges, com placar final de 3/6, 6/1 e 6/3. Algoz também da pernambucana Teliana Pereira, a suíça mede forças nas quartas com a dinamarquesa Caroline Wozniacki.


Out of Control: Atendendo a pedidos...\nMulher mais linda que esta não há!\nAdorei a foto de cima!\nQuando começam as eleições :)?\nDaqui a duas semanas, mais ou menos...\n28 de novembro de 2009 às 13:15\nEla é um encanto de mulher !\nAinda vou a Lisboa de propósito lol\n28 de novembro de 2009 às 15:03\nE venha mais post's da Roberta ! :D\n28 de novembro de 2009 às 15:05\nEste blog está de dia para dia melhor frequentado!\nGrande Marina!!! Finalmente alguém com juízo! Que bom-senso!!! Quando fores a Lisboa, eu vou contigo!!! LOL\nEsta mulher é uma fofura...\n28 de novembro de 2009 às 16:08\nSó fofura? Ela é um encanto! Uma delicadeza de pessoa, tãao linda ^^\nOlha, se quiseres adicionar tás à vontade: marinapobraga@hotmail.com haja alguém com a mesma opinião do que eu :P\n28 de novembro de 2009 às 16:28\nVais passar a tarde toda a pensar como tirar a Roberta do campeonato LOL...A Bette já se reformou, mulher, converte-te à Roberta! Lol, vais-me matar!!! Pronto, a Bette também é girinha, não fiques triste!\nMarina, eu até diria mais: haja alguém com a mesma BRILHANTE e CERTA opinião que eu!\nCriei há umas semanas um e-mail para a Bruna mas é gmail, sei que dá para o msn mas não sei mt bem como. Mais vale adicionares-me tu. Fica também o contacto para quando se marcar o café (é melhor não acertarmos por aqui, não vá lá aparecer algum Orlando)\nOk, não se riam, este e-mail foi criado num severo e agudo ataque de parvoíce:\n28 de novembro de 2009 às 17:08\nBruna, já te adicionei !\nE vá, Patty, converte-te à Roberta. :D\nEsta gente anda tola!! Temos que fazer chegar este Blog a Roberta!!!!\nRoberta, cadê você? Eu vim aqui só pra te ver!!!!!\nAinda bem que só podem votar uma vez, já imaginaram se fosse diferente??\n28 de novembro de 2009 às 19:04\nAssim nao vale :S\n28 de novembro de 2009 às 19:54\nPatty, muito bem, já gritas a frase!!! Estás convertida!!! Lol\nComo queres fazer o blog chegar à Roberta? Será que lhe pode dar um piri pac (não sei como se diz esta coisa que vocês costumam dizer)?\n28 de novembro de 2009 às 20:39\nE depois ainda temos de admitir que aquele Laurent Filipe é cá uma brasa .. Ui!! :D\n28 de novembro de 2009 às 23:15\nBruna, de onde é que tu és?\nMarina, estavas a ir tão bem!!! Já vi que não és da Família!!!!\nLaurent Filipe???? Ó Bruna, temos que fazer uma lobotomia por aqui!!!\n29 de novembro de 2009 às 12:28\nMarina, sou do Porto.\nPatty, já me tinha apercebido que a Marina ainda não percebe muito disto, parece-me que ela é pequenina. Não é Marina, quantos anos tens? Mas acho que está num óptimo caminho, tem muito bom gosto (tirando o Laurent LOL)\n29 de novembro de 2009 às 13:16\nGente, ela é bonita mas vocês estão exagerando!!:-)\n29 de novembro de 2009 às 13:50\nNão estás a ver a coisa pelo prisma certo... a mulher é... uiiiii lindaaaaaaa demais! Bem, mas até é bom, cada uma gosta da sua e assim ninguém se zanga! A Roberta é só minha! (e um bocadinho da Marina também...)Lol\n29 de novembro de 2009 às 16:24\nEu acho o Laurent giro para a idade que já tem LOL\nE tenho 16 (quase 17) xD\n16 (quase 17)... gostei do parenteses, que giro! Estás numa fase maravilhosa da vida, Marina (aliás, todas as fases são maravilhosas) e ainda por cima tens tão bom gosto!\nPatty, acho que não é preciso lobotomia nenhuma, logo logo ela vai perceber que a Roberta é muito mais gira que o Laurent! (se ainda não percebeu... ãh Marininha?)\nMuitos bjinhos para todos e um especial para a minha companheira de campanha, Marina,\nUi, eu com meus 16 (quase 17) aninhos tinha paixonites por tenistas, tipo Steffi Graf e Gabriela Sabatini...\nBons tempos mas melhores agora, com Jennifers Beals e Anistons e Bombeiras, Mangueiradas e Vizinhas...\nMuito melhores agora!!\nAH, sim e Robertas!!\nÓ Marina, esquece lá o Laurent que ele é muito velho para ti!!\n29 de novembro de 2009 às 19:05\nEstava a ver que te esquecias da Roberta, Patty!\nEu com essa idade tive a minha primeira namorada, e tinha um fraquinho imagine-se por quem... pela Daniela Mercury! Ai ai, esta minha tendência para as aloiradas!\n30 de novembro de 2009 às 10:43\nMas olha, agora não sei mas a Daniela namorou com uma mulher há pouco tempo. É mais ou menos da família!!\n30 de novembro de 2009 às 12:45\nÉ óbvio que a Robertinha é muito mais linda do que o Laurent :D Nem é preciso ter olhos na cara para perceber isso xP\n30 de novembro de 2009 às 16:52\nMuito bem Marina, isso é que é falar!\nQuanto à Daniela, também ouvi esse boato e até há um video suspeito sobre isso numa entrevista dela na Maria Gabriela... ela deixa a dúvida no ar. E depois aquele beijão que ela pregou na outra cantora durante um show... hummm\n1 de dezembro de 2009 às 01:06\nisto é que é bom gosto que anda por aqui!\neu não tinha intenções nenhumas de ver o Ídolos até ter visto por acaso esta mulher ali sentada. não a conhecia mas captivou-me logo.\n2 de dezembro de 2009 às 18:17\nMais uma fã para a Roberta!\nBem-vinda Anónima! Se puderes, diz-nos o teu nome, ok?\n2 de dezembro de 2009 às 19:28\nдля сайта dvdvalente.blogspot.com\n11 de novembro de 2010 às 08:29\nComeça a Votação!\nQuer dizer, nem em minha própria casa??????\nA bela da semana - parte 3\nA bela da semana - parte 2\nA bela da semana - parte 1\nAusente de Espírito\nMas será que ela pensa mesmo...\nA bela da semana 2\nVá lá...vá lá!!!\nPérola do programa Everybody Loves Raymond\nGripe, espirros, garganta\nLucinda Williams é talvez...\nEu já gostei do Bon Jovi...\nChove e chove e venta e chove!!!!!\nApenas um reparo\nOutra vez esta música me persegue\nMais um comprimido para a gripe!\nQue bem que se está aqui...\nRoberta, Papai e Mamãe??\nHoje o dia começou bem!!\nO Paulo Bento devia ter deixado o Derlei\nEstou quase a enviar o CD\nÓ Carlitos...Mira esto\nToca o disco e volta ao mesmo\na Bela do Ano\nTem um bom-dia Bruna!!\nVamos ser sinceros...


Signo Caranguejo na 9ª Casa do Horóscopo - Aprendiz de Astrologia\nNeste artigo falamos dos efeitos da colocação do signo Caranguejo na 9ª casa do horóscopo.\nQuando o signo Caranguejo está colocado na 9ª casa- o que acontece para o Ascendente Escorpião – os nativos podem sentir-se «em casa» quando estão em viagem por algum país estrangeiro. Muitos podem mesmo decidir viver fora do país natal.\nPode haver um forte apego a algum país estrangeiro e à sua cultura ou língua. Para estas pessoas, o «lar» é uma imensa comunidade que se estende para o exterior das fronteiras onde nasceram e podem mesmo ter uma atitude do tipo «cidadão do mundo». Normalmente, estes nativos têm também grande facilidade para aprender línguas estrangeiras e podem ser muito versados sobre costumes e aspetos da cultura de outros países.\nCom o signo Caranguejo na 9ª casa os nativos valorizam em particular as ideias e filosofias que dão conforto ao ser humano e ás suas inseguranças. Preferem filosofias tradicionais às contemporâneas porque as mais antigas estão enraizadas nos costumes e na maneira de ser das pessoas numa dada cultura.\nGostam também bastante de estudar assuntos de pedagogia e educação. Uma razão que pode explicar o seu interesse por países e culturas estrangeiras pode ter a ver com o facto de a mãe poder ser estrangeira e oriunda de outra cultura ou professar alguma religião exótica.\nMais do que interessarem-se verdadeiramente pela filosofia, estas pessoas são mais inclinadas para aderir a ideologias ou religiões cujas ideias e valores lhes permitem fundar uma visão do mundo estável e tradicional. Gostam igualmente de estudar psicologia e pedagogia, cujo saber tem aplicação prática em áreas que apreciam. Assim, poderão escolher uma profissão em que lidam com crianças em termos pedagógicos ou terapêuticos.\nSão conservadoras e enraizadas na ideia de comunidade, Pátria, proteção e não aderem com facilidade a qualquer «ideia moderna» seja esta sobre o mundo, sobre o ser humano ou sobre as crenças e a relação destas com a «verdade». Pátria e Família são valores que consideram essenciais embora possam entendê-los não só como realidades físicas mas também como uma comunidade entre «espíritos» que partilham as mesmas formas de ser e de ver o mundo.\nCom Caranguejo na 9ª casa, muitos destes nativos podem apreciar viajar «com a casa», adquirindo uma roulotte e adotando um estilo de vida «móvel» em que podem mudar frequentemente o local onde «vivem» e o seu contexto.\nO signo Caranguejo na 9ª casa indica forte influência da mãe e das suas crenças no modo como o nativo projeta o seu próprio significado da realidade e a sua noção de verdade. Pode seguir a religião da mãe, os seus padrões de cultura, se esta for estrangeira ou dedicar o seu estudo superior à investigação da maternidade ou da relação «mãe/criança» numa dada cultura estrangeira ou em diversas culturas.\nA mulher no papel de mãe pode ser um tema muito estruturante nas suas vidas. Em alguns casos, estes nativos poderão dedicar-se ao mundo da «cozinha» e das suas referências culturais e estudar a relação entre a cultura e a alimentação. Ou, em alternativa, poderão desenvolver serviços de catering, de prestação de serviços de enfermagem ou de acompanhamento residencial de pessoas doentes ou idosas de origem estrangeira.\nPodem administrar uma escola de cuidados de saúde ou de enfermagem, de gestão hoteleira, etc..\nNo que se refere às ideias e crenças destas pessoas, tendem a ser conservadoras e tradicionais, recusando os «modernismos» e «os excessos» e não aderindo de forma entusiasta a novas formas de ver ou de compreender. Preferem as pedagogias tradicionais às que dão ao aprendente demasiada liberdade para aprender por si mesmo. Não gostam de desafiar a «sabedoria» tradicional.\nDeste modo, em relação aos estudos superiores , os nativos com o signo Caranguejo na 9ª casa gostam de Pedagogia e Psicologia, Antropologia Cultural (especialmente a que estuda sociedades matriarcais) Línguas, História e Arqueologia, Religião, Nutrição e Culinária, Enfermagem e Cuidados Primários de Saúde, Gestão Hoteleira, Arquitetura, etc..\nA visão do mundo dos nativos com Ascendente Escorpião é permeada pelas emoções e pela ligação aos valores tradicionais e ao papel da mulher e da mãe na sociedade e no progresso da Humanidade. Têm uma ligação forte com a comunidade e gostam de fazer atividades que unam vizinhos, membros da igreja, etc., em torno de causas comuns que defendem o seu estilo de vida e a sua segurança, respeitando os papeis tradicionais.\nQuando o signo Caranguejo está colocado na 9 ª casa a relação com o pai é, em geral,fácil e satisfatória o pai gosta da vida em família , é afetuoso embora possa ter um estilo mais discursivo do que aberto ao contacto físico.\nQuando o signo Caranguejo está colocado na 9ª casa as crenças tendem a manter-se ao longo da vida, sendo enraizadas na infância. Podem ter origem estrangeira, mais do que exprimir as tendências da comunidade local.\nOs signos nas Casas do Horóscopo, Signos na 9ª Casa do HoróscopoSigno Caranguejo na 9ª casa do horóscopo


Sobral de Prima: MOSES RODRIGUES AVANÇA E AVIAÇÃO CIVIL CONFIRMA AEROPORTO DE SOBRAL PARA 2016\nMOSES RODRIGUES AVANÇA E AVIAÇÃO CIVIL CONFIRMA AEROPORTO DE SOBRAL PARA 2016\nSob fortes aplausos, Moses Rodrigues foi recebido na Câmara de Vereadores de Sobral pela população sobralense, nesta quinta-feira 27. O plenário ficou lotado para receber a Audiência Pública, requerida pelo deputado federal cearense, para tratar dos aeroportos de Sobral e de Jericoacoara.\n“Requeri esta Audiência Pública, porque defendo que é preciso que aja clareza, comprometimento e, sobretudo transparência na condução da coisa pública, e em específico, o projeto do aeroporto de Sobral”, destacou Moses Rodrigues. O parlamentar sobralense ressaltou que mesmo sendo oposição aos governos Federal, Estadual e Municipal, a política deve ser feita para o povo e não em defesa de interesses particulares. “É essencial que os procedimentos tomados pelos entes executivos responsáveis em todo este processo tenham o máximo de celeridade e comprometimento. Precisamos lembrar que a disputa político-partidária jamais poderá sobrepor-se a um interesse maior, o do povo” finalizou Moses, autor do requerimento.\nA Audiência reuniu representantes da Secretaria de Aviação Civil, Governo do Estado do Ceará, Prefeitura dos municípios de Sobral e da Zona Norte. Durante o encontro, o secretário de aeroportos do Ministério, Leonardo Cruz, solicitou apoio do deputado Moses Rodrigues para que os recursos destinados não sejam contingenciados pela União.\nMoses Rodrigues foi elogiado por sua atuação no Congresso Nacional e pelo trabalho desenvolvido em prol do Estado do Ceará.