Mudança de Instalações

O Repeat Until Keypressed mudou de instalações. O novo endereço http://mlopes.online.co.pt substituiu a versão antiga que estava alojada no blogger.

Apesar de ter importado os posts, a versão antiga do Repeat Until Keypressed vai-se manter online exclusivamente por motivos de histórico, com os comentários desactivados.

Com a nova casa vem uma tentativa de mudar o estilo de escrita. Não, não me vou por a comentar as mamas novas da Floribela nem sequer falar do rabo da Jennifer Lopez. A ideia é tentar ter posts mais elaborados com algum conteúdo criado no próprio blog em vez do simples comentário a links interessantes encontrados noutros sítios. Alguns dos posts antigos eram de facto muito maus como por exemplo a versão antiga do post "Cada qual no seu lugar" que foi alterado entretanto ou como o "Aqui não há novidades" que apesar de linkar para um artigo que acho interessante, não diz nada sobre o artigo para o qual link aponta, e já agora, também não diz nada sobre mais coisa nenhuma.A nova plataforma permite-me um controlo mais apurado de todo o interface do blog bem como do seu próprio funcionamento, dando-me uma liberdade que o blogger não dava. Está portanto na altura de começar esta nova etapa.Boas leituras, desejem-me sorte!

Cada qual no seu lugar

Cada linguagem de programação tem a sua personalidade, e as práticas de programação devem ser adequadas a cada uma delas. Algumas linguagens terão personalidades mais semelhantes, outras mais distintas e quanto maior o distanciamento entre elas maior é a probabilidade da aproximação a um problema ser diferente.

Utilizar uma aproximação errada a um problema numa linguagem é em muito semelhante a atribuir a tarefa errada a um trabalhador. Não se coloca um programador de C a cortar HTML e não se coloca um web-designer a programar em C pois isso leva a insatisfação profissional, atrasos e erros na tarefa, enfim, um sem fim de consequências negativas.

Estruturado

A programação estruturada é aquela que mais "fora de moda" se encontra, apesar disso é a aquela que tem mais provas dadas. A grande maioria das aplicações que se vê por aí são feitas em C, praticamente tudo aquilo que utilizamos hoje em dia está assente em algo feito em C, como por exemplo muito do software que permite a existência da internet.

Dentro da programação estruturada há claro linguagens diferentes e as aproximações deverão também ser diferentes. Existem paradigmas distintos, tais como o imperativo e o funcional, existem as linguagens compiladas e interpretadas (conhecidas como linguagens de script).

Alguns do exemplos de linguagens estruturadas bastante populares são o C, o perl e o PHP. Logo aqui se nota a diferença entre as aproximações por linguagem. Não passa pela cabeça de ninguém resolver um problema da mesma maneira em PHP ou em C, a gestão de memória, o suporte para arrays dinâmicos, é tudo tão diferente que até sinto alguma dificuldade sequer em fazer uma comparação.

Objectos

Aqui entram algumas linguagens como por exemplo o python, o ruby , o Smalltalk e o IO language. Este é um paradigma mais geek e pouco utilizado, mesmo por alguns programadores de python e ruby que muitas vezes se desviam para a programação estruturada ou orientada a classes (muitas vezes chamada erradamente de orientada a objectos).

Aqui existem dois tipos de aproximação, o IO language, por exemplo, é prototipado, todos os objectos são criados clonando um objecto base e alterando depois o novo objecto. Nesta situação nem sequer existem classes.

Já em python por exemplo os objectos são criados a partir de classes, se bem que é possível criá-los copiando outros e depois alterando-os. Mas mesmo quando os objectos são criados a partir de classes na prática a diferença não é assim tão grande pois nas "new style classes" os objectos herdam todos implicitamente de um objecto base Object.

Neste tipo de linguagens a pureza de objectos da linguagem é um factor importante, pois é isso que permite a manipulação dos dados/código que caracterizam a aproximação ao problema utilizado normalmente neste tipo de linguagens. Closures e as funções e classes como first class citizens são também elementos importantes que condicionam a forma de utilizar a linguagem. É importante para quem não está familiarizado com o conceito de funções como first class citizens que isto não é um exemplo de passar funções como parâmetro ou devolver funções (as duas linhas são dois exemplos independentes):

func1(func2())
return func()

Este é o exemplo correcto:

func1(func2)
return func

No caso específico de python e ruby, quase tudo são objectos, mesmo as primitivas da linguagem, com excepção de uma mão cheia de keywords. No caso do ruby alguns operadores não são objectos (o == é mas o != não é, não sei bem porquê).

Classes

Neste tipo de linguagem inserem-se por exemplo o JAVA, o PHP e o C++, estes dois últimos só quando utilizados com classes em vez da forma estruturada. Este é actualmente o paradigma da moda. Regra geral as classes são utilizadas como contentores de funções que actuam sobre uma estrutura de dados comum. A diferença deste paradigma relativamente ao dos objectos é o facto de estas linguagens não serem puras de objectos, não terem closures nem funções e classes como first class citizens. A consequência disto é que a manipulação de código é muito reduzida e reflecte-se na aproximação ao problema.

Epilogo

Muitos dos programadores que experimentam uma linguagem com uma personalidade muito diferente daquilo a que estão habituados caem nos erros de fazer as coisas da forma errada para a linguagem que estão a usar. Por exemplo no How not to write Python code o autor enumera uma lista de coisas que ele considera que se deve ou não fazer em python.
Estranhamente o próprio autor cai num dos erros por ele referidos:

Python is Python, don’t try to emulate bad coding patterns from other languages

Ao fazer o seguinte:

A basic example: to check whether a function parameter is of a certain type, don’t use something like ‘arg.__class__ == MyClass’, use ‘isinstance(arg, MyClass)’.

Isto é claramente um erro pois o python é weak typed, não faz sentido o programador verificar tipos, pois isso é para linguagens strong typed e os compiladores/interpretadores serão com certeza mais eficientes a fazê-lo. No caso de haver de facto necessidade de verificar uma característica de um objecto, como por exemplo a existência de determinado método, vale mas verificar só mesmo essa característica. Ao fazer o que o autor diz no exemplo perdem-se as vantagens da pureza de objectos que permite fazer coisas como os file like objects. Este é o tipo de código típico de uma linguagem como o JAVA, mas... o próprio JAVA já faz isto pelo programador.

Outro exemplo que está bastante desviado da realidade do python é, ironicamente, o "Use Pythonesque coding pattern" que apresenta uma alternativa ao facto do python (tal como perl 5 por exemplo) não ter cases. Neste exemplo o erro é gritante porque o autor cria um código complicado para emular uma funcionalidade de outras linguagens, o facto de ele próprio falar nisto como uma alternativa ao case que não existe em python mostra o erro de estar a utilizar paradigmas de outras linguagens. A verdade é que nos últimos anos tenho programado muito em perl e python e nunca o meu código chegou a um ponto onde precisasse de um case.
O que me faz pensar que se estamos a tentar emular algo que não existe na linguagem... então estamos no caminho errado.

Um desvio à cultura vigente nas empresas

Este post fala de um estudo feio em 2001 sobre como a cultura de uma empresa pode influenciar a criatividade numa empresa como entidade.
O princípio é bom, mas as ideias acabam por seguir o habitual dentro da cultura empresarial actual onde na prática nada é diferente do que era. Na prática o que sinto ao ler as conclusões é que não estaria satisfeito a trabalhar no tipo de ambiente descrito.
Vale pelo estudo, as conclusões parecem-me muito fracas.

Não te esqueças de fazer o TPC

Alguns conselhos sobre formas de melhor conhecer o produto que está a desenvolver, de forma a poder planear prazos mais realistas. A validade destes conselhos está como sempre sujeita a discussão.

Aqui não há novidades

Só aquilo que já se sabia, uns são bons, outros são maus... e a experiência de facto não os ajuda.

Não, não sou o único...

MacBook Air Haters Suck My Dick, apesar do título agressivo, o conteúdo não o é tanto. Mas aparentemente não sou o único a ficar farto de passar a vida a tropeçar em comentários idiotas sobre o MacBook Air.
Já vi gente a queixar-se das coisas mais parvas, a reclamar que no MacBook Air não conseguem fazer <inserir coisa parva que nunca precisou de fazer>, a compará-lo com tijolos maiores que o meu desktop, etc...
A minha sugestão: já chega, se não gostam não comam mas poupem-nos ao ruído de vos ouvir choramingar.

O perfil do "entrepeneur"

Um estudo chegou a algumas conclusões interessantes, mas não inesperadas, sobre o que leva alguém a ter um perfil de "entrepeneur" (e eu que não me lembro da palavra em português).

O GIT é mesmo bom!

Há quem fique excessivamente fascinado com o git, mas de facto aquilo é bom. Eu só tenho pena de ainda não o dominar mais , mas já vou mexendo nuns repositórios e até tem corrido bem.
Deixo aqui um link para quem se quiser iniciar (eu comecei pelos tutoriais que estão na página oficial).

SDL para games.online

Quem leu o post que aqui coloquei ontem e seguiu o link para o blog do games.online possivelmente reparou que está iminente o arranque do desenvolvimento de um jogo que ao contrário dos outros que lá estão não será online, mas sim para descarregar e instalar.
Aproveitando as possibilidades que isso nos dá, optámos por fazer o desenvolvimento em C utilizando SDL.

Assim chegamos ao objectivo deste post que é partilhar o link para o excelente tutorial que me tem ajudado a relembrar o C e a aprender a usar SDL. Sim, porque como diz no tutorial, eu ainda sou do tempo (e não fiz nada em C desde esses tempos) em que se fazia isto:

_asm {
    mov ax, 13h
    int 10h
}

First time

Aí está a minha primeira experiência com o Wordpress.

Cuidado com as linguagens

Sim, as linguagens são importantes

A propósito deste evento running a startup on Scheme, lembrei-me de algo que li há uns tempos (e que não deixo link porque já não sei dele) sobre os perigos de utilizar tecnologias que não sejam mainstream numa empresa.
Uma empresa que tenha a sua existência baseada em software e que desenvolva esse software em Lisp vai ter sempre um enorme problema quando precisar de aumentar o seu staff de programadores. Posso dizer por experiência própria que, num mercado pequeno como o português, e ajudado pelo sistema de ensino, até para arranjar programadores de python é difícil, imagine-se então Lisp.

Python

Apesar disso, a minha escolha continua a recair sobre o python porque sendo uma linguagem que segue os paradigmas a que a grande maioria dos programadores estão habituados permite "apanhar" bons programadores mesmo que estes não estejam familiarizados com a linguagem. Um bom programador consegue num período de uma ou duas semanas estar a produzir em python. O mesmo não acontece com Lisp onde um bom programador não habituado ao paradigma pode demorar meses a conseguir tornar-se produtivo.

Ruby

Uma linguagem que está com uma grande popularidade actualmente, embora já tenha tido mais popularidade (a verdade é que no último ano até perdeu utilizadores) é o ruby.
Ao ruby aplica-se tudo o que foi dito sobre o python com duas desvantagens, a primeira o facto de não ser tão fácil de aprender como o python, e introduzir alguns conceitos "estranhos" para quem vem da programação estruturada (OO incluído). No caso do python, são raros os exemplos em que um programador, mesmo não familiarizado com a linguagem não consiga perceber. No ruby isto não acontece e mesmo já tendo algum conhecimento básico de ruby não é raro tropeçar em sintaxe que não faço ideia do que faça.
A outra desvantagem é a maturidade da linguagem, não tive oportunidade (nem vontade) de ver como está a versão 1.9, mas até à versão 1.8 o interpretador era bastante ineficiente.
Poderia ainda apontar a legibilidade como mais um ponto contra o ruby, mas o JAVA e o PHP são o que são e continuam a ser as linguagens mais usadas