Red vs Crystal

Vi hoje no Twitter um post do TaQ “An Introduction to Crystal: Fast as C, Slick as Ruby” sobre Crystal. Pelo título fui dar uma olhadinha e achei interessante e, pelos objetivos, achei semelhante a Red (o título pelo menos).

Como conheço mais Red do que Crystal, tentar comparar ambos está mais para presunção do que análise isenta. Então, desculpe qualquer erro nas comparações abaixo, mas resolvi fazer um apanhado de semelhanças e diferenças.

Semelhanças e diferenças (Crystal vs Red)

  • Estágio inicial: Ambas são consideradas beta ou alfa (apesar de ja ser possível fazer muita coisa em Red; acredito que em Crystal também). Red está na versão 0.6.1 e Crystal na versão 0.18.0. Pela abrangência e complexidade de Red, é bem provável que Crystal alcance a versão 1.0 antes de Red.
  • Plataformas: Pelo que vi, Crystal está disponível para Linux e Mac OSX. Atualmente, Red está disponível para Linux, Mac OS X e Windows. Em breve para Android.
  • Instalação: Red não precisa de instalação. É só baixar o executável para a plataforma desejada e executar um script/compilar/usar o REPL.
  • Compatíveis mas não iguais: Red possui a sintaxe parecida com Rebol e Crystal parecida com Ruby. Em algumas situações, Red executa programas feitos em Rebol e Crystal em Ruby. Quem deseja migrar deve estar ciente de que precisará efetuar alterações no código e nada garante que o código funcione sem algum hack.
  • Compilar para código nativo: Com Red, você pode baixar e rodar a versão para Windows e gerar executáveis para qualquer plataforma disponível sem se preocupar com mais nada a não ser a chave -t <plataforma>. É bom deixar claro que Red é composto por duas partes. Red que apresenta grande compatibilidade com Rebol e é de alto nível e Red/System que seria um substituto para o C, compartilhando a mesma sintaxe de Red mas com menos funções. O resultado é que compilando o exemplo da sequência de Fibonacci em Crystal (que está incorreto) o executável ficou com 294K ao passo que em Red/System ficou com 6,4K.  (Crystal foi 0,05s mais rápido que Red). Outro detalhe é que Red pode gerar bibliotecas (.dll, .so, .dylib) que podem ser utilizadas por outras linguagens.
  • Tipagem: Em Crystal, as vezes não é necessário informar o tipo do dado e em outras é (não sei se pode confundir ou não). Em Red não é necessário especificar o tipo de dado mas, se o usuário desejar, poderá especificar para os parâmetros de uma função (pode ser mais de um tipo como integer, string) e assim será gerado erro se um tipo de dado diferente for enviado em vez do erro aparecer apena em tempo de execução. Red/System possui tipagem estática (como pode haver uma interface entre Red e Red/System, existem algumas facilidade para trabalhar com tipos diversos de dados)
  • Interface com bibliotecas: Crystal oferece facilidades para o acesso a bibliotecas escritas em C (não sei se outras linguagens) sem a necessidade de sair da linguagem (escrever um programa em C, por exemplo). Red/System também (e Red por intermédio de Red/System). Como o objetivo de Red/System é ser um “substituto” de C para quem programa em Red, também permite o acesso a syscall (diretamente ao Kernel).
  • Fontes: Ambas linguagens disponibilizam os fontes. Para compilar Crystal você precisa ter Crystal (existem várias linguagens com esta recursividade). Para compilar Red, você precisa ter Rebol (versão comercial). Mas existe a possibilidade de você usar a versão grátis para criar executáveis com os fontes de Red. Ou você pode usar a versão compilada para Windows, Linux e Mac que os desenvolvedores utilizam. Futuramente Red será compilado com Red e a dependência deixará de existir.
  • Espaço armazenamento: Pelo repositório do Arch, diz que eu tenho que baixar 7,5M e, depois de instalado, irá ocupar 57,9M. Para Red eu tenho que baixar 1M do executável e … só. Na realidade, ele cria um arquivo de 500K que é o console (REPL) e uma biblioteca de 10k que são necessários para a execução (considere que em 1M ele já compila para três plataformas diferentes). Não é um item muito relevante mas considerando IoT, pode ser levado em conta (ou se as operadoras limitarem o consumo de dados).

Público alvo

 Bem, qualquer linguagem serve para qualquer um. Vou apenas escrever um pouco para deixar o artigo maior

Crystal

  • Como o ideal não é a compatibilidade com Ruby que tem Rails como carro chefe, certamente não irá abocanhar uma grande parcela de desenvolvedores do Ruby se não for compatível (no artigo diz que não roda Rails).
  • Para outros usuários de Ruby, será necessário analisar com calma o custo/benefício da mudança.
  • Para quem está testando novas(?) linguagens, é uma nova opção para incluir na lista (Go, Rust, Elixir, Red, Crystal, Eve, etc.)

Red Red/System

  • Como Carl Sassenrath encerrou o desenvolvimento de Rebol 2 e disponibilizou os fontes (fora as partes que possuíam copyright) mas largou de mão, muitos ficaram órfãos. O desenvolvimento da versão 3 pela Atronix também data de 2/3 anos atrás. Red pode ser adotado por quem está sem alternativas (e por outros também).
  • Para quem possui um grande leque de aplicações que vão de drives para o SO até aplicativos para rodar no Windows+Mac+Linux+Android (outras opções no futuro como iOS) pode ser uma boa opção.
  • Para quem está de olho na IoT e não quer muita complicação também poderá ser uma opção interessante.
  • Para quem está testando novas linguagens, blá, blá, blá.
Cuidado. O texto abaixo é altamente tendencioso.
O meu interesse por Red é pela descomplicação que ele parece ter (facilidade de passear por diversos SOs sem precisar nem instalar e com 1M), escrevo um programa e gero executável para diversos ambientes, pelo que pode fazer de baixo nível (falar com o Kernel que não é o meu caso) até alto nível (criar DSL ou dialetos como são chamadas em Red), usar GUI nativa dos diversos SOs (atualmente só Windows mas para as próximas versões Android, Mac e Linux/GTK3) e previsões futuras como módulos acopláveis (usar a GPU, por exemplo), meta-DSL (facilidade para a criação de DSLs). Resumindo, parece que os desenvolvedores miraram nas estrelas para alcançar a lua.

Um exemplo que acho legal em Red é o mostrado abaixo. Em poucas linhas é possível criar uma janela, editar um código e ver em tempo real o resultado. Se você tiver curiosidade, basta baixar Red para Windows (é a versão 0.6.2 que está em desenvolvimento e possui o nome de red-latest.exe), baixar o código fonte do relógio que possui 51 linhas contendo o código para criar o ambiente, para criar o relógio e mais 16 linhas que falam sobre o programa. Funciona no wine, bastando tiraro comando transparent da primeira linha. Interessante ler outras informações no site.

blue-clock2

Clock livecoding demo

Vai demorar um bom tempo para Red chegar na versão 1.0. Alguns acham que a versão 0.7 já poderia ser considerada a 1.0 pois possui suporte a parte de I/O. Como não venho de Rebol, olho para o que está considerado para I/O e penso: “Não precisa de tudo aquilo para I/O. Já é possível ler e escrever arquivos, diretórios, posso ler até páginas pelo protocolo http[s]”. Mas se eles dizem …

Anúncios

por que aprender cobol?

TL;DR

Porque é uma linguagem de programação mais legal que muitas atuais, permite desenvolver facilmente programas mais sérios que muitas linguagens modernas e ainda está sendo utilizada e possui vagas para programadores. Ah, mas …..

Verbosidade?

Se você reclama que precisa escrever muito em COBOL, então você escolheu trabalhar em J certo? Não? Então você só pode estar esperando um futuro onde você pensa no sistema, pressiona enter e os programas se materializam no computador. Não existe outra alternativa. Ah, entendi. Você só está repetindo pois ouviu alguém dizer e acha legal. Sem problema. Mas vejamos o sem graça “Hello World” em Java e em COBOL. A versão Java poderia ser assim:

e em COBOL assim:

Em execução;

Basicamente, 5 linhas em cada linguagem para um programa legível. Ah, mas em Java eu posso escrever tudo na mesma linha. E daí? Vai ficar um programa menos legível e, se você não está em coma desde 1960, em COBOL também é possível escrever tudo na mesma linha. Ah, mas na minha linguagem eu escrevo só: print "Hello World". Grande coisa, poderia apenas digitar um ponto e sair um “hello World” (e pior que tem). Se você reparar, em COBOL é só display "Hello World". O resto serve para facilitar a legibilidade do programa como veremos depois.

É uma linguagem morta!

Realmente. Tanto que existe  vagas no mercado igual a Python ou Ruby e mais do que Pascal, não se escreveriam alguns bilhões de linhas por anos e não haveriam tantos fabricantes oferecendo suas implementações com Micro Focus, IBM, entre outros. Se está morta, não dá dinheiro e as empresas teriam falido. Os artigos irão se basear no GnuCOBOL. Finalmente, alguém de um banco me disse que estavam arrependidos de terem feito um sistema em Java. Deveriam ter feito em COBOL. Isso em 2016.

Por que GnuCOBOL?

Bem, é código aberto, possui uma boa compatibilidade com as versões atuais e existem diversos casos de utilização real e até substituição de ambientes comerciais. A versão estável é a 1.1 mas a 2.0 está em desenvolvimento. Pessoalmente eu acho que na versão estável falta algum polimento na entrada de dados  e a implementação de alguns detalhes. O número de desenvolvedores é pequeno então não espere novidades a cada semana.

Para instalar no Linux, sua distribuição já deve ter em algum repositório ou é só baixar os fontes de site GnuCOBOL, verificar as necessidades, compilar e instalar. Tem um executável para Windows que é só baixar  que a instalação é automática (até poderia ser melhorado para automatizar alguma coisa como a definição dos caminhos).

Você pode usar qualquer editor para criar os programas (agora que existe a possibilidade de um formato mais livre sem a necessidade de iniciar e terminar em colunas específicas. O Emacs e o Vim são duas opções. Tem o OpenCobolIDE que é mais específico para trabalhar com o GnuCOBOL (inicialmente era chamado de OpenCOBOL), o Geany também salienta sintaxe, o Visual Studio 2015 entre outros.

Mas o Dijkstra disse ….

que “O uso de COBOL mutila a mente, o seu ensino deve, portanto, ser considerado como uma infração penal”. Parece que ele não gostava de COBOL, BASIC, APL, etc.. Se ele estivesse vivo, provavelmente falaria mal de Python, Ruby, Java, Go, etc.. O fato é que não existe e, provavelmente nunca existirá, uma linguagem que seja difícil de escrever programas ruins.

A linguagem.

Como o próprio nome diz, COBOL (COmmon Business Oriented Language) é uma linguagem orientada ao uso em negócios. E as atividades de uma empresa pouco mudaram desde o surgimento. São tarefas repetitivas como faturamento, folha de pagamento, contabilidade e outras que podem ser passadas para o computador sem muitas alterações do que é feito manualmente. Se você tem um programa de contabilidade escrito em 1960, o processo provavelmente não sofreu alterações até hoje. Uma empresa que fabrica calçados, poderia usar o mesmo programa ainda hoje (com algumas melhorias é claro e como muitas fazem). Gastar dinheiro comprando programas mais novos está mais para  custo do que investimento.

Outro aspecto importante é que a linguagem já vem (e vinha) com tudo que é necessário para desenvolver um programa para uso comercial. Aproximadamente 99% + 1% da aplicações comerciais necessitam trabalhar com arquivos de dados (clientes, fornecedores, mercadorias, contas a pagar/receber, funcionários, etc. Se fosse utilizada uma linguagem como Pascal, C, etc., seria necessário a escolha de um SGBD (que nem sempre era fácil na época). COBOL pode trabalhar como PostgreSQ, MySQL, etc. mas geralmente é uma preocupação desnecessária em muitos casos (é claro que se o volume de dados for grande e crítico, um bom SGBD é um ótimo complemento).

Como a linguagem foi desenvolvida para que um “leigo pudesse ler e entender”, ela utiliza expressões que podem ser mais facilmente entendidas. Por exemplo, display "Endereço..:" at line 10 column 05 é perfeitamente identificável. Antigamente era mais trabalhoso digitar tudo isso mas os editores modernos podem completar as palavras enquanto se digita, o que facilita bastante e, no caso, é possível digitar display "Endereço..:" at 1005 o que seria praticamente normal para qualquer linguagem.

A linguagem possui divisões, seções e parágrafos e tem um formato parecido com uma receita culinária. Temos:

  • IDENTIFICATION DIVISION que seria a identificação da receita/programa como nome e outras informações.
  • ENVIRONMENT DIVISION que informa o ambiente que será utilizado cozinha, panelas, colheres, forno, etc.
  • DATA DIVISION que possui os dados ou os ingredientes que serão utilizados para o preparo/programa.
  • PROCEDURE DIVISION que diz exatamente como devemos proceder para fazer o bolo ou resolver o problema.

Apesar da estrutura ser mais rígida, os dados são facilmente localizáveis.

Considerações finais.

Eu pretendia falar mais sobre a programação em COBOL mas como ficaria muito longo, fica para o próximo artigo.

GIMP 2.8

Bem, a versão 2.8 do GIMP ainda não saiu mas já é possível testar diversas características na versão 2.7 que é a versão em desenvolvimento e dará origem a versão 2.8. É interessante constar que testei a versão 2.7.1 no Linux (e foi compilada aqui mesmo, baixando os programa pelo git). Tempos? Nao sei exatamente. A versão 2.8 estava prevista para sair este ano. Se você não puder esperar, possui nas mãos a grande vantagem do software livre. Procure a versão de desenvolvimento (2.7), instale e vá testando no seu computador. No meu caso, Linux, é possível eu ter as versões 2.6 (estável) e 2.7 (desenvolvimento) instaladas simultaneamente e sem que uma interfira na outra. Depois eu testo no Windows para ver a possibilidade de ter as duas rodando simultaneamente.

Provavelmente, a característica mais interessantes para muitos será a utilização de uma única janela, estilo photoshop, e não a interface de múltiplas janelas como é utilizada atualmente. Será possível alternar entre os dois modos facilmente. Ainda não está totalmente pronta mas jé é possível ter uma noção de como ficará.

Uma visão do resultado (clique nas imagens para ver em tamanho grande em outra janela):

Uma outra facilidade é a inclusão de quais ícones serão mostrados na caixa de ferramentas bem como a sua ordem. Basta acessar a janela de preferências, selecionar os ícones que deverão ou não aparever e/ou alterar a ordem de visualização deles. É mais fácil que acessar com diversos cliques através dos menus (é claro que muitos possuem atalhos através de combinações pelo teclado).

Ao abrirmos diversas imagens, elas aparecerão na aba da janela, facilitando a mudança entre uma e outra. Também é possível escolher a imagem de outras formas, mas ficamos assim, por enquanto.

Escrever um texto sobre a imagem também ficou melhor. Escreve-se diretamente sobre a imagem e não em uma caixa de dialogo separada (apesar de ser possível escolher a opção anterior).

Depois é possível selecionar a camada com o texto e efetuar alterações no mesmo. O menu para a seleção do modo de uma determinada camada também sofreu uma reestruturação. As opções semelhantes foram agrupadas. Por exemplo, Darken only, Multiply e Burn, que ‘escurecem’ a imagem estão agrupadas.

Agora é possível agrupar as camadas e especificar rótulos para os pinceis. Quando selecionamos um pincél, o programa nos mostra os rótulos atribuídos a ele.

Sempre que ocorrem mudanças, a gente estranha um pouco no início. Com um pouco de uso elas se tornam normais. Muitas vezes, o meu fluxo consiste em abrir uma imagem no formato raw da câmera (.PEF), faço as alterações que julgo necessárias, pressiono combinação Ctrl+Shift+S para ‘Salvar como’ e salvo com a extensão .xcf.bz2, achato a imagem e salvo como .jpg, redimensiono e coloco uma borda com a assinatura para colocar na web (Ctrl+Shift+W) e uso novamente Ctrl+Shift+S para salvar a imagem pequena com borda. Agora terei que me acostumar já que Ctrl+Shift+S apenas grava a imagem no formato nativo para o GIMP, isto é, .xcf e seus companheiros como .xcf.gz, etc.

Agora, para ‘salvar como’ em outro formato, é necessário Ctrl+Shift+E, para exportar a imagem.

Bem, existem outras coisinhas como rotacionar os pincéis, informações de cálculos ou outras unidade para o redimensionamento da imagem (25%, 2cm + 3in, etc). Você pode ter uma idéia na página das novidades. Depois de sair a versão 2.8, a próxima etapa deverá ser a integração completa com a GEGL e a possibilidade de trabalhar com 16bits por cor. Quem estava esperando por isso, terá que aguardar pela versão 2.10 (ou a versão 2.9 que é a desenvolvimento).

Atualização O GIMP que achei no SF é uma versão antiga da 2.7.0 de 23/08/2009 (dois meses é bastante tempo quando o programa tem uma atividade maior no desenvolvimento) e ainda não possui a opção de janela única entre outras. Então, para quem usa o Windows, é melhor continuar na versão 2.6 por enquanto (a menos que exista uma versão mais nova em outro local).

Leitura na rede

Hoje fiquei sabendo que o Grupo Câmara Obscura está preparando um livro de ensaios que deverá ser lançadp no início de agôsto.

Infelizmente, pelo menos para mim, a idéia é de um lançamento único. Pessoalmente eu gostaria que fosse algo semanal. Tá, concordo que seria muito trabalho. Então algo mensal. Não? Bi? Trimestral? O melhor é aguardar agôsto e ver o que o Rodrigo e os envolvidos decidem. Realmente é algo que exige um bom tempo dos envolvidos. Quando a gente vê a coisa pronta, nem se da conta do trabalho que dá. É possível ver pelo número de revistas online que iniciaram e encerraram as atividades após alguns exemplares.

Como eu acho interessante o assunto, isto é, revistas e livros no formato pdf, vou me alongar um pouco sobre o assunto. Já faz algum tempo que utilizo tal tipo de ferramenta. Inicialmente foi na área de linguagens de programação (Lisp e Smalltalk possuem diversos livros no formato pdf para baixar gratuitamente) e, depois, com o Dave Thomas que começou com a venda de livros no formato pdf (inicialmente algo sobre Ruby e extendeu-se para diversas outras linguagens).

Na área da fotografia, tem a PBase Magazine que é trimestral (mas o pessoal resolveu tirar umas férias depois da edição de janeiro/2008). Possui entrevistas, artigos, dicas, etc. Vale a pena conferir o trabalho do pessoal.

Outro local muito bacana para conseguir literatura em pdf-mags.com. Não é específico sobre fotografia mas possui bastante livros sobre o assunto, geralmente acompanhados de ensaios, ilustrações, crônicas, entrevistas, etc. Basta acessar o site e selecionar a categoria desejada. Música, fotografia, moda, artes, vídeo, computação, etc. Ideal para quem gosta.

Como usuário do software livre, não posso deixar de citar a GIMPZine que é uma publicação trimestral com dicas e trabalhos feitos no GIMP. Uma excelente trabalho do Anderson, Guilherme e Mozart. Só para salientar, o Mozart Couto é ilustrador e autor (desenhista e argumentista/roteirista) de histórias em quadrinhos, tendo trabalhos e premiações no Brasil e exterior e, sempre que possível, utiliza o GIMP para suas tarefas. É mais ou menos como fotografia. Quem sabe faz, quem não sabe sai sempre em busca de melhor equipamento (talvez colocando na assinatura as fotos fiquem mais bonitas 🙂 )

Mas não vou fazer uma salada. Outra hora eu falo sobre as alternativas em software livre para deixar o trabalho de alguns legal (não no sentido de bonito, mas todos sabem que pirataria é crime 😉 ).