Bem, demorou. Um dos motivos foi que, a primeira vista, era tanta coisa que não compensava botar num post. Não é limitação do WordPress, mas é limitação do conceito de blogging como um todo.

Ok, parêntese: O intuito original deste post era fornecer mecanismos para balancear a relação quando da desarmonia. Técnicas de Análise e Resolução de Conflitos. Analisar, Documentar, e Compartilhar o conhecimento, entende?

Então, diante disso, resolvi criar um subprojeto-pessoal: Criei no wiki do leal.eng.br um Mini Guia. Este guia busca orientar soluções (ou melhor, “Padrão de Soluções” através de análise das forças/aspectos envolvidos e, principalmente, com um repositório de “Podrões de Projeto”).

Eis o endereço. Prometo informá-los quando do andamento e informá-los sobre atualizações importantes – Mas nada impede que assinem o feed do wiki.

Ergo, Divirtam-se!

A História da Web: Relembrar é Entender

Acompanhar a Web envolve um pouco da própria natureza da tecnologia: Novas demandas, novos desafios, e a constante necessidade de manter tudo alinhado com o que já existia, oferecendo recursos que originalmente sequer foram imaginados. Basicamente, as principais tecnologias que compõem a Web, entre 1990 a 2000, surgiram da necessidade de resolver os seguintes problemas:

Agora repare esta tabela com um olhar crítico: Dentro da visão original da Web, ela buscava apenas ser um repositório online de documentos, o que basicamente envolve HTTP e HTML. Ou seja, apenas o primeiro item da lista.

Todas estas necessidades transformaram a mesma em um ambiente dinâmico de troca de informações. Os documentos não eram mais arquivos em uma pasta: Tornaram-se registros complexos em grandes bancos de dados, constantemente acessados e modificados.

A solução Java, àquiela época, eram os Servlets, que buscavam apenas a geração de conteúdo dinâmico. Ela se situa no tempo um pouco depois do conteúdo rico na linha do tempo. Era uma solução adequada? Bem, não muito, mas o Java Server Pages, em 1998, ajudou a aliviar e torná-la mais agradável.

Mas acompanhando esta corrida, perceba que surgiram requisitos implícitos: Bancos de Dados, Logs, Gerência de Concorrência, Pooling de Recursos. Performance e Elegância.

Complexidade

Esta complexidade minou inicialmente o poder do Java. As soluções saiam, mas jamais dentro de padrões aceitáveis de performance. A Lei de Moore ajudou e hoje Java está entre as plataformas mais adequadas em termos de performance, e relação custo-benefício adequadas a maioria das corporações.

Perceba a ressalva acima: Corporações. Ela ainda estava – e ainda está – inacessível a maioria dos desenvolvedores. Desenvolver em casa e publicar na web uma aplicação Java envolve um pouco de esforço em achar soluções de hospedagem, devido a natureza do negócio de hospedagem.

Em paralelo, ambientes como Perl e PHP trouxeram uma outra visão: Ambientes Interpretados, leves, com valores diferentes do que o público-alvo do java buscava. Isto gerou uma impedância entre os ambientes que até hoje persiste: A maioria dos ambientes de hospedagem é capaz de rodar Perl e PHP, mas não Java. Isto criou uma cultura e uma divisão: Programadores PHP acham Java Complexo demais, e Programadores Java consideram PHP inadequado para fazer aplicações dentro das necessidades da sua empresa.

AOP, IOC, DI e ORM: Abordando os Problemas sob outro Ponto de Vista

Estamos em 2004. Nesta época, as soluções Java já estavam sendo questionadas quanto a sua capacidade de manterem-se adequadas aos requisitos modernos. O AOP criou um novo paradigma de programação, mas o conceito de Injeção de Dependências e Inversão de Controle, popularizados pelo Spring, e o de Mapeamento Objeto-Relational (Hibernate) mostraram que desenvolver em Java era possível – apenas não estavam sendo feito de uma forma efetiva.

Em paralelo, o Struts tornava-se norma, enquanto buscava-se ao JSF a agilidade e leveza que o ASP.NET trazia.

Ruby on Rails – Uma Nova Abordagem (e Valores)

O Ruby on Rails é um divisor de águas: Com um novo jogo de valores (YAGNI, DRI), ele buscou a simplicidade e jogou outro requisito na roda: Interatividade. Muitos (bons) programadores Java, Perl, Python e PHP foram para o Ruby on Rails.

Web 2.0

Em paralelo, cunhou-se o termo “Web 2.0”. Redes, Ajax, Mashups. Novos requisitos na roda.

Recomeçando

Neste ponto, haviam 3 grandes problemas:

• Haviam basicamente 2 tribos de desenvolvedores Web: Os programadores de Scripting (PHP/Perl/Python), com ambientes interpretados, dinâmicos e leves, e os programadores Java, compilados e exigindo mais memória;
• As soluções interpretadas forneciam aplicações com grande demanda (CMS), enquanto as Java eram orientadas ao ambiente enterprise. Porém, isso não impedia que soluções de CMS open source fossem viáveis para corporações, mas o temor natural de integrar uma aplicação PHP com uma base de dados manipulada por uma aplicação Java inibia a sua adoção, resultando em vários CMS Java de uso interno – causando diariamente a reinvenção da roda nas empresas;
• Haviam outras maneiras de se fazer as coisas, e mais atrativas que em Java;

No ambiente Java, criou-se um claro conflito de valores: Como produzir mais e ao mesmo tempo, integrar com o que eu tenho?

Esta proposta foi a premissa para a IBM inaugurar o Project Zero.

O Conceito:

O Project Zero busca trazer leveza, reuso, simplicidade e agilidade para o desenvolvimento web. As seguintes premissas foram adotadas:

• O Java permite o uso de linguagens Interpretadas;
• O Ambiente Servlet/JSP é complexo, e isto causa problemas;
• O conceito dos Archives J2EE – EAR, WAR, RAR não provê a reusabilidade necessária para as aplicações, trazendo retrabalho;
• O ambiente deve ser flexível, permitindo que vários meios sejam usados para desenvolver um website;
• O Open Source é uma realidade, e não pode ser ignorado;

Desta forma, a proposta do Zero procura englobar estes fatores em uma solução onde:

• O open source seja uma realidade, e que a equipe interaja com a comunidade buscando uma solução não apenas com massa crítica, mas focada em um objetivo comum;
• Linguagens como Groovy e PHP possam integrar-se com o Java;
• O reuso de aplicações Web seja uma coisa possível
• O desenvolvimento pode ser feito a partir de um runtime pequeno (2MB), podendo ser feito pela linha de comando, IDE (Eclipse), ou até pelo Browser (AppBuilder);
• As abstrações de acesso a dados (arquivos locais e remotos, e-mail, e Web) sejam vistos como recursos REST, abstraindo a complexidade de uma forma homogênea

O Zero possui um website, com blog, forum, issue tracking, área de desenvolvimento, downloads e documentação. Tudo rodando no runtime do Zero, e mantido pela equipe do Zero.

Aplicações:

O meu tcc foi feito no Zero. Ambora me arrependa de ter tido uma abordagem mais monolítica (evitando o PHP e Groovy), comparar a sua performance (Spring + Hibernate) contra um servidor J2EE equivalente demonstrou uma performance superior. Lembra quando falei de um runtime leve? Pois então.

Outro ponto forte é integração: Vamos supor que você possui na intranet um portal MediaWiki, e gostaria de integrar a sua autenticação com algum sistema proprietário da empresa. Ou o seu blog (em WordPress) necessita de alguma integração com o seu CMS Java? Pois – mesmo sendo PHP, o Zero integra com eles de uma forma genial.

E o sMash?

Ah sim, o sMash é a versão comercial do Zero, e é disponível pela IBM. Mas a mesma é baseada no Zero e na sua comunidade.

Concluindo

Então fica o convite: Veja os links acima e julgue se a Web não precisa de um curto-circuito. :)

“-Quando Tralha é Coisa Séria!”

Nesta virada do ano, arrumobservando o meu quarto, percebi que o espaço classificava-se da seguinte maneira (classificado por importância):

• Livros e Revistas;
• CDs e DVDs;
• Cabos Antigos e Aparelhos Eletrônicos Sem Uso;
• Computadores;
• O mega-traste que vos fala;

Como destes, o último item, embora pouco importante, era apenas a razão do quarto existir, e dada a velocidade com que o espaço começava a ser tomado, decidi fazer uma organização. CDs e DVDs estão sendo ripados, e pro 2o semestre fecho um Home Server/Media Center e alguns livros serão doados (caso você tenha algum leve interesse, confira isso e aquilo).

Moral da História: O traste fica, apesar dos protestos da vizinhança.

Mas a questão das revistas bateu em alguns aspectos sentimentais:

• Quadrinhos de Valor Sentimental: Vertigo Brasileira e os Episódios da Morte e Ressureição do Super-Homem;
• Coleções
• Periódicos (que irão pro saco! Eu juro);
• Outras, aonde um artigo ou outro se salva, serão scaneadas e mantidas – prometo escrever sobre isso quando fechar a solução, mas já dei início a este processo;
• Outras revistas tem mais de 30 anos… err…

Abre Parêntese – Eu ainda não cheguei aos 30, mas ver revistas de 1978 ensinando a fazer tele-jogo me colocaram em um dilema imenso: Eu não sabia eletrônica, mas durante anos, sempre assinei e comprei revistas e livros sobre eletrônica. Como lidar com isso? Fecha Parêntese.

Em paralelo, outras constatações: Estava me formando, queria dar menos atenção a programação – Calma, é apenas uma licença sabática! – , e queria ter novas perspectivas sobre a vida. Novos passatempos, mas ainda mantendo a natureza doméstica que rege a minha vida.

A partir daí, surgiu o plano.

O Plano

O Plano era simples: Montar um Laboratório de Eletrônica e efetivamente aprender Eletrônica Básica, Digital e Microcontroladores. Estabelecer um hobby, ganhar o domínio e a prática para ler os artigos, compreender, e enfim, dar cabo na minha coleção das Revistas da Editora Saber. Um processo para tomar os próximos 2 anos, divertir-me e ganhar o conhecimento.

Existe uma infinidade de fatores que impediram isso de iniciar-se antes. Fatorei tudo e resolvi utilizar uma abordagem semi-autodidata para conduzir o meu próprio aprendizado. Motivar-me, de acordo com as minhas próprias premissas. E, principalmente, montar uma caixa de ferramentas de deixar os outros com inveja. :)

Power!!!!

E como você costuma ler neste blog, ter um projeto bem definido e exemplar :)

Semi-Autodidata?

É. Deixa eu explicar: Ser autodidata é muito valorizado pelas pessoas. Porém tem um grandissíssimo problema: Diante de fatos incompreendidos, você define que uma maneira é a única que funciona, muitas vezes sem sequer de fato compreender os aspectos que envolvem a sua percepção.

Falta. Método.

Isto te torna hábil, mas também te torna burro. Muito burro. E foi por este motivo – não prender-me a miopia do auto-aprendizado –, que me graduei em computação mesmo já possuindo experiência no mercado de trabalho. Resolvi aplicar esta visão a um hobby.

Logo, é necessário método: Experimentar sim, porém diante do obstáculo, discutir e compreender a questão, de forma iterativa.

Parte do Plano envolveu eleger “Tutores” – Pessoas com Experiência Vasta nos Assuntos, para orientar-me e ouvir meus relatos. Até agora, tem rendido muito bem.

Porque mencionei o Aprendizado de Programação? Bem, o Aprendizado de Programação, sem método, cria um rendimento baixo – é necessário você ter persistência e, principalmente, compreender abstração. Mas de qualquer forma, não obter o resultado desejado envolve um pouco da preguiça mental de não compreender o obstáculo diante de você. É o clássico “Maldito compilador! Agora este erro!” – Muitas vezes sem ler e buscar compreendê-la.

E o que você fez?

Estabelecendo Premissas:

• Safety First – Comecei comprando equipamentos e lendo orientações de segurança. Isto rendeu-me uma ida ao IT Center;
• Ferramentas são para o que o homem não domina com as mãos: Sempre que encontrava alguma dificuldade, recorria ao google para descobrir como os outros resolviam. Isto gerou algumas descobertas sobre ferramentas úteis, como as “Terceira Mão”, muito úteis para soldagem de placa, ou descascadores de fio (tentei aqueles da Western – São bons, mas tendem a quebrar fácil. A coisa terminou no da Sparkfun – É Campeão!). E pinças e alicates;
• Dicas, Dicas, Dicas: Utilizei o Instructables como uma referência. Ótimas idéias, e uma comunidade ativa na área de eletrônica. Fazer não basta. É preciso saber fazer uma forma melhor de fazer;

A partir daí, a coisa centrou-se ao redor de coletar, informar, e registrar:

• Plataformas: Na verdade, há cinco anos eu já possuia uma uma placa de desenvolvimento PIC. Decidi mantê-los, mas com menos enfoque, e direcionar-me para Arduino, dada a comunidade;
• Componentes: Tem a Tip, no Reduto. É boa, mas me deslocar pro comercio em horário comercial é uma tormenta. Fico em casa: Tentei algumas lojas online. A minha favorita absoluta chama-se Soldafria. O atendimento é ótimo, a navegabilidade é boa, e a variedade e preços são excelentes. Para outros casos extremos, recorri a Sparkfun e ao MercadoLivre;
• Circuitos: Ainda não achei projetos que me inspirassem. Por hora, estou rascunhando alguns e aprendendo sobre as partes envolvidas;
• Sites: Sim, algum. Ainda não tomei coragem para postar em algum fódum – Prometo repensar sobre isso. De qualquer forma, meu caderno de notas continua a mil;

Aonde ficamos?

Basicamente já montei alguns circuitos básicos com Arduino. O foco agora é em montar circuitos, e não em programá-los. Logo, minha experiência com o Eagle, Arduino IDE, WinAVR, Processing e MPLAB fica para outro momento. Por hora, é soldagem e construção de placas parece ser o próximo estágio. Porém, compreenda que o enfoque – macro – é aprender todas as áreas e buscar-me nelas.

Preciso fazer um curso intensivo de solda. Ainda não decidi, mas o curso do Francisco, do Kit8051, me parece bom. E tem o CuriousInventor.com tem um site útil sobre o assunto.

Lembra dos aparelhos eletrônicos acima? Estou desmontando e me livrando do que não me interessa de componentes. O resto vai pra caixa de componentes, serelepemente. :)

Agora eu consigo olhar para um esquema envolvendo microcontroladores e compreender o significado – Reconhecer o padrão. Aplicá-lo ainda está um pouco tortuoso, mas eu provavelmente irei trabalhar isso em breve.

Bem, o futuro parece claro: Montar mais circuitos, ganhar esta confiança, entender os principais circuitos envolvidos, e começar a envolver-me em outros projetos. Ah, sim: Desmontar mais circuitos, hehe.

Caso você esteja curioso, confira a minha galeria de fotos do lab no Gallery2. Caso deseje discutir e até oferecer-se como tutor em alguns projetos, fale com o nosso Serviço de Atendimento ao Cu-rioso.

Grato.

Mas entrar é só o começo da equação, sendo necessário sair para que a graduação seja efetiva. Agora que existem testemunhas suficientes para comprovar que eu fui dispensado da minha, posso começar a falar algumas coisinhas que aprendi, e que julgo importante compartilhar, com o mínimo conhecimento de causa.

Uma universidade, como toda instituição, é sistêmica, possuindo inúmeros participantes interagindo entre si. Em termos imediatos, porém, a relação aluno e professor é, sem dúvida, a mais importante, pois é a partir dela que se justifica o prédio, o cafezinho, e até o alívio quando passa aquela baby deliciosa pelos corredores. Sua vida funciona em função disso e, mesmo que você não ache importante, é preciso garantir a sobrevivência no meio.

Metade desta responsabilidade encontra-se na mão do estudante. Ou mais da metade, se considerarmos que a relação entre aluno e professor é desproporcional (apesar que ela tenda a igualar-se durante o curso, devido a evasão – escolar e de aulas individuais): Portanto, é imprescindível começar pela massa crítica. Os próximos posts irão focar-se nos outros aspectos desta relação.

O que faz um bom aluno?

Alvin Lucier, um amigo meu, formou-se e permitiu citar algumas características que o mesmo julga fundamental para definir um bom aluno. O mesmo dedicou-se algum tempo para, junto comigo, enumerá-las. Uma boa fonte da nossa discussão foi este link. Agradeçam a ele por este post.

Um bom aluno (como ele – eu estou no extremo do mau exemplo) mantém uma boa relação com os professores, colegas, e funcionários. Com os professores, o aluno deve demonstrar-se motivado. Professores gostam – e alguns precisam perceber – a motivação e o empenho de um aluno. E a melhor maneira de transmitir é através de atitudes.

O que transmitir e quais atitudes?

Alunos que agradam:

• Comparecem: Isto denota atenção, respeito ao trabalho do professor. Chegam na hora, explicam suas eventuais faltas (com motivos plausíveis, por favor), e mantém-se atualizados com o andamento da disciplina (matéria, tarefas e exames). E, acima de tudo, assumem responsabilidade pelos os seus atos;
• Aproveitam Oportunidades: Cursos de Extensão, Eventos (como Seminários, Palestras), Estágios, Monitoria são coisas que permitem aos outros enxergá-los sobre um olhar mais simpático. Mas se você só buscar fazer os exercícios e buscar resolver desafios já está de bom tamanho, acredite;
• Demonstram Atenção: Fazem perguntas, ouvem, não se perdem durante a aula conversando ou saindo. Respondem perguntas do professor. Isto ajuda a quebrar o gelo e tornar a aula mais interativa;
• Estão Informados: Informação é Responsabilidade. Logo, se o aluno busca estar esclarecido com as suas notas, com a sua frequência, com o calendário de provas, e, principalmente, com a ementa do curso, isto se torna um claro sinal de que o mesmo está envolvido com a disciplina. Mas sempre é bom conversar com o professor, pelo menos alguma vez, como forma de estabelecer uma relação casual;
• Dedicam-se: Os trabalhos buscam ser bem feitos. E efetivamente alocam tempo para a sua execução.

Concluindo

Se a faculdade é um fato, e mesmo que você não goste, é importante demonstrar-se comprometido. Alunos motivados permitem ao professor conduzir melhor a disciplina, sendo o benefício um jogo de ganha-a-ganha. Se você ainda está na graduação, não abra mão desta oportunidade de fazer acontecer.

É claro! Não sendo livros técnicos (que ainda me permitirei curtir), e estando na minha wishlist, porque não?

Julho passado, comprei uma câmera. Minha relação com elas é meio tortuosa, mas… enfim, decidi dar uma chance. Lorenda, minha fiel assistente em assuntos digitais, me ajudou a encontrar uma câmera… e…

… E eis que temos a PowerShot A720IS. Ainda estou lendo o manual, mas, o que dizer? Ela é ótima.

(Semi Profissional, cheia de features (e hacks!). Ainda estou lendo os manuais e tentando entender como é difícil fazer um dispositivo digital tratar imagens da mesma forma que o olho humano (ou superando-o), mas estamos sem dúvida, fazendo progressos. :)

Neste interim, este semestre representa a chance de fechar as contas em vários aspectos da minha vida. O mais óbvio é a faculdade: TCC, Poscomp, Monitoria, e Maratona. O que não está neste escopo, e não sirva pra dar suporte a nada dos mesmos, vai para a prateleira. E isto inclui MGS4 e uma Stolichnaya (Sigh…):

Ah sim, atualizei o Gallery 2 e até coloquei algumas fotos lá. :)

E afinal, vencemos, e agora é Belo Horizonte. Antes que perguntem, eu também preciso explicar porque da minha posição gestual.  Ou melhor, o Diálogo:

Lourenço: “-Aldrin, acho que o seu balão não vai aparecer tanto, por ser branco…”
Eu: “-Não se preocupe. Não é o balão que faz a fama, mas ‘-as bolas do aldrin’ já são facilmente associadas a pessoa. Sem sequer terem visto!… -Olha o tam…”
(click)

Enfim, está explicado. :)

[ A reconstrução aproximada das perguntas é um exercício destinado ao leitor. ]

• Geringonças não são necessariamente uma melhoria, vide a sucessão:
  Quadro Negro -> Retroprojetor -> Power Point
• E eu não preciso gastar o meu tempo com um computador apenas porque eu sou um cientista da computação.
  [ Não são exigidos a pesquisadores médicos sofrer das doenças que eles investigam ]
• Não é o negócio da ciência da computação promover a “automação”, por exemplo, criando aplicações que exijam mais hardware para criar um mercado para a próxima geração de hardware.
  [ Pesquisadores médicos não precisam criar novas doenças para criar um mercado para novos produtos farmacêuticos ]
• Não é tarefa da Universidade oferecer o que a sociedade quer mas dar o que a sociedade precisa.
  [ As coisas que a sociedade pede são geralmente entendidas, e você não precisa uma Universidade para isto; a universidade tem que oferecer o que nenhum outro pode fornecer. ]
• Somos todos modelados pelas ferramentas que usamos, em particular: os formalismos que usamos formam os nossos hábitos de pensamento, por bem ou por mal, e isto significa que você deve ser bastante cuidadoso ao escolher o que aprender e ensinar, visto que desaprender não é realmente possível.
  [ Há muitos anos atrás, caso eu precisasse de um assistente, um prequisito seria "Sem exposição prévia a FORTRAN", e em ensino de segundo grau da Sibéria, o ensino de BASIC não seria permitido. ]
• Um programador deve ser capaz de demonstrar que o seu programa possui as propriedades exigidas. Se isto é consequência, é improvável que ele seja capaz de atender aos requisitos: Somente se ele permite a sua obrigação influenciar o seu design, há esperança de que ele possa atender a expectativa. Uma verificação pura a posteriori lhe inibe um pouco desta influência holística e é portanto colocar a carroça na frente dos bois, mas isto é exatamente o que acontece nas fábricas de software aonde “programação” e “controle de qualidade” são feitos por equipes distintas. [ E sem dizer que estas fábricas entregam sem garantia. ]
• As técnicas exigidas de racionalização efetiva são bastante formais, mas enquanto a programação é feita por pessoas que não as dominam, a crise de software irá continuar conosco e será considerada uma doença sem cura. E você sabe o que doenças sem curas fazem: elas convidam macumbeiros e charlatões aonde, neste caso em particular, tomam a forma de gurus de Engenharia de Software.
• Alguns duvidam que a supracitada “técnicas de racionalização efetiva”, meigas como elas são para programas pequenos, irão escalonar, como dizem, “dada o assombroso tamanho e imensa complexidade da maioria dos programas”. Bem, eles podem ser inadequados se você tentar usá-las para desemaranhar a tremenda confusão produzida por um grupo de incompetentes, desorganizados programadores. O seu poder manifesta somente na fase de construção quando (i) eles tendem a conduzir para textos muito menores que seriam produzidos e (ii) comprimento de variações de programas tendem a crescer não muito mais que a linearidade dos comprimentos dos programas derivados. Finalmente os programas produzidos são infinitamente menores que o lixo usual.
• Não devemos jamais esquecer que programadores vivem em um mundo de artefatos, um fato que o distiguem de outros cientistas. Um programador não deve perguntar o quanto aplicáveis as técnicas de boa programação são aplicáveis, ele deve criar um mundo aonde elas são aplicáveis, e é a sua única maneira de entregar um design de alta qualidade. Sobre isso eu devo citar EWD898 (1984):
  

  “As capacidades das máquinas nos dão bastante recursos para fazê-la uma completa confusão. Oportunidades ilimitadas para estragar as coisas. Desenvolver a disciplina austera de manter as coisas suficientemente simples neste ambiente é um desafio formidável, tanto tecnicamente quando educacionalmente.”

• Em resposta a questões sobre porque ensinamos coisas sem valor que a indústria ignora, eu o indico EWD920 (1985). Permita-me citar mais um parágrafo:
  

  “Retomando a questão original: pode a ciência da computação salvar a indústria de computação? A minha resposta é “Se a indústria de computação pode ser salva, somente a ciência da computação pode fazê-la.”. Mas irá demorar muito até que a indústria de computadores – em particular, as empresas bem estabelecidas – compartilhem esta visão. Certamente irá demorar mais que o período limitado pela a qual eles planejam os seus futuros. No intervalo, o mundo acadêmico – que tradicionalmente planeja muito mais além – não tem escolha. Tem que refinar e ensinar usando o melhor das suas habilidades como a computação deve ser feita; no caso dela ceder a pressão de propagar a má-prática de hoje, é melhor que ela suma.”.

• Mas para reforçar sobre quanta paciência precisamos, permita-me mencionar outra velha citação (de 1988):
  

  “Poucas pessoas reconhecem que a alta tecnologia tão celebrada hoje é essencialmente uma tecnologia matemática.”

  (do segundo relatório David, batizado em referência ao seu presidente, Dr. E. E. David Jr.)

• Não, eu não tenho medo que a ciência da computação tenha sofrido com a popularidade da Internet. Ela atraiu uma crescente – para não dizer: inundante ! – massa de estudantes com bastante pouca inclinação acadêmica e na pesquisa ela apenas fortaleceu a prevalescente (e de certa forma vulgar) obcessão com velocidade e capacidade.
• Sim, eu concordo com a sua preocupação: Como programar bem – quando um assunto ensinável é dificilmente ensinado. A situação é similar aquela em matemática, aonde o currículo explícito é confinado a resultados matemáticos; como a matemática é algo que o estudante deve absorver por osmose, assim dizendo. Uma razão para preferir manipulação de símbolos, calcular argumentos é que o seu design é muito melhor ensinável que o design via um argumento verbal/pictorial. A introdução em larga escala de cursos em metodologia calculacional, entretando, iria encontrar problemas políticos intransponíveis.
• No negócio de software existem muitas empresas aonde não é claro que a ciência pode ajudá-la; se a ciência deve tentar ajudá-la também não é muito claro.

Edsger Wybe Dijskstra (11/05/1930 – 06/08/2002) foi um cientista da computação holandês. Ele recebeu em 1972 o prémio Alan M. Turing para contribuições fundamentais na área de linguagens de programação, e foi processor na Universidade de Texas em Austin de 1984 até a sua morte em 2002. O prémio anual da ACM foi renomeado como Prêmio ACM Edsger W. Dijkstra logo após a sua morte.

Dijkstra também era notado por ter tido apenas um único computador (já no final da vida), e raramente usá-lo, mantendo a sua convicção que a ciência da computação não deve ser mais abstrata que mera programação, explicada em um número de famosos dizeres como “A Ciência da Computação não é tanto sobre computadores do que a Astronomia é sobre Telescópios”.

Espero escrever sobre ele.

(Escrever sobre o que eu escrevi? Ok, aqui é metalinguagem por definição)