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

Alhos e Bugalhos

Há quem ache que que não há grandes programadores, outros acham que o código é que pode ser bom.
Acredito que há bons e maus programadores, e pessoalmente já conheci uns poucos bons e muitos dos maus, alguns são piores do que maus. O número de maus programadores não pára de aumentar, e de quem é a culpa não restam muitas dúvidas.
Também é verdade que o código, e até as próprias linguagens influenciam e muito a productividade dos programadores. Eu mesmo já passei por essa experiência, e o que retirei daí é que, não é só o próprio custo em termos do tempo perdido com mau código ou má arquitectura que retira a productividade ao programador. Aliás, este nem sequer me parece o factor mais importante. Na minha opinião o factor importante aqui é a moral, um bom programador perde motivação quando o trabalho que está a fazer é repetitivo e não tem inovação e por esse motivo dedica menos do seu tempo a fazer trabalho efectivo.

A shift in the Schwartz

Ultimamente este blog tem estado um pouco "ensonado", consequência de várias coisas. Uma delas, como não podia deixar de ser, não fosse a minha nacionalidade Portuguesa, é a falta de tempo (leia-se o mau aproveitamento deste).
A verdade é que analisando bem o motivo dessa inactividade no blog, ver-se-á que tem mais a ver com uma mudança de interesses em relação aos tempos em que o criei. O Repeat Until Keypressed surgiu numa altura em que influênciado pelo uso do Mac OS X, pela leitura de sites como o 43folders, o Life Hacker, etc..., estava bastante interessado em organização pessoal, workflows, tudo o que me pudesse levar a produzir mais fazendo menos.
Claro que estou e estarei sempre interessado nisso, mas a verdade é que actualmente tenho andado a ler mais sobre startups, sobre gestão de projectos e sobre alguns conceitos de programação mais invulgares.
Ao fazer o post anterior, onde publico um comentário meu a um artigo no blog do Mário Gamito, sobre um assunto que é bastante debatido por quem está envolvido na criação de startups, como encontrar a pessoa certa para uma determinada vaga e não um "falso programador" (programador no caso específico do post do Mário Gamito), percebi que se calhar a forma de não deixar morrer o blog será passar a falar mais sobre o que vou aprendendo sobre estes temas.
Olhando para os últimos posts publicados neste blog, vai-se de facto notando o afastamento do tema original, há meses que não há um link para o 43folders ou lifehackers, uma referência ao GTD, etc..., por esse motivo, espera-se nos próximos tempos, novos posts, falando sobre "algo completamente diferente".

1 shot de absinto

Deixei 1 shot de absinto no blog do Mário Gamito que me pareceu pertinente colocar aqui:

Este é um dos motivos porque é tão importante perceber o que um candidato a um determinado cargo realmente sabe, não basta olhar para os cursos que o candidato têm.
Este é um dos problemas que aflige e prejudica bastante algumas empresas, especialmente as grandes empresas onde os departamentos de RH regra geral não têm capacidade para confirmar se determinada entrada no curriculum corresponde a conhecimentos reais.

Hate is int the Air

Aparentemente um sinal da crescente popularidade da Apple, é o facto de esta cada vez ter mais haters, algo que até aqui era quase um exclusivo da Microsoft.
Um dos alvos preferidos desta nova espécie tem sido o Macbook Air que, a fazer lembrar a indignação dos utilizadores de PC quando a Apple deixou de colocar leitores de disquete nos computadores novos, aponta agora o desaparecimento da drive óptica mas desta vez com extra-raiva.

A questão que se coloca aqui é que o facto de o Air só suportar leitores ópticos externos não é grande novidade, já vários computadores portáteis fizeram o mesmo, alguns já há muitos anos como por exemplo a Toshiba com o portegé. Não podia, claro está, deixar passar esta oportunidade de dizer as esses novos Apple haters, vamos lá todos então odiar a Toshiba.

Em relação à possibilidade de desaparecimento das drives ópticas dos computadores num futuro próximo, só tenho a dizer que já é raro usar qualquer das minhas. No caso específico da Apple cada vez faz mais sentido poupar o espaço e o custo desse tipo de drives já que a própria Apple Store disponibiliza músicas, séries televisivas e filmes para venda e aluguer. Só sobra assim o software para ser transportado em meios ópticos. Nada que não se resolva! Eu próprio já comprei softwares que são descarregados da internet e que nunca chegam a passar por nenhum meio físico entretanto.
Para juntar à festa, as flash memory estão cada vez maiores, mais baratas e são mais fáceis de gravar e regravar do que os suportes ópticos.
E tendo em conta que até o SO eu já instalei a partir de um iPod (quem diz iPod pode dizer uma flash com uns quantos gigabytes) só tenho a dizer que não me parece que vá sentir muita falta das drives ópticas... especialmente quanto for pagar menos €500 para não ter blue ray.

Onde está o gil? [actualizado]

Afinal ainda não foi desta, foi só um downtime, aparentemente ainda há alguém a cuidar do gildot.


Hoje lembrei-me de verificar o estado do gildot e dei com ele em baixo.
Connection to 194.38.131.34 Failed
É sabido que o gildot estava mais para lá do que para cá, mas será que acabou de vez?

Repetição!?!? Qual repetição?

Segundo o mais futebol, Carlos paredes não apareceu, não apareceu, não apareceu, não apareceu, não apareceu, não apareceu, não apareceu...