Sua opinião é muito pertinente. Quando um motorista se acostuma com uma direção hidráulica, dificilmente quer voltar para o modelo anterior e como você falou pode acontecer o mesmo com o programador iniciante.

Nesse contexto do aprendizado eu particularmente prefiro começar com a visão top-down do que a bottom-up. Coisas gerais e mais simples primeiro, depois ir detalhando mais o problema. Mas isso é também muito relativo.

Mas eu acho que encontrei um parâmetro interessante para diminuir um pouco a relatividade:

Dividir o aprendizado em 2 momentos:

1 – lazer e experimentação
2 – desenvolvimento de produtos reais (softwares para pessoas usarem)

Nesse momento 1 de lazer e experimentação, o princípio é que se aprenda brincando. Atualmente com o Scratch já é possível aprender um pouco de lógica estruturada, programação orientada a objetos, passagem de mensagem a objetos sem precisar detalhar esses conceitos formalmente. Além de poder compartilhar o programa e olhar o código feitos por centenas de pessoas ao redor do mundo. Um objeto no Scratch é simplesmente uma figura, que vai executar ações(métodos) como “mova 2 passos”. Cada figura também tem suas características (propriedades). Nesse momento não é necessário conceituar, só é necessário arrastar o mouse e modificar os valores, variáveis, mudar posições dos comandos, enfim experimentar e aprender a lógica literalmente brincando. Nada de falar sobre a programação, simplesmente programar. “Deixe eu puxar esse comando aqui pra ver o que acontece! Legal!” A lógica vai sendo assimilada indiretamente.

No momento 2 é preciso partir de problemas reais: criar softwares que serão utilizados por pessoas. Criar software que funcione é a prioridade, é o mais importante. Não confudir com criar relatórios, artigos, ou outro documento descritivo que tem sua importância para a área científica, mas para o aprendizado de resolução de problemas reais de software isso pode prejudicar bastante. São realidades diferentes, velocidades diferentes ao ponto de ser quase impossível uma só pessoa ser incrivelmente bom desenvolvedor, gerente de produtos reais e ao mesmo tempo um renome na pesquisa científica. Nesse momento é preciso esclarecer isso para o aluno decidir que carreira seguir ou pelo menos compreender a complexidade de cada uma.

Voltando a focar somente no desenvolvedor. Os problemas reais tem diversos níveis de complexidade e portanto é importante que os problemas cheguem do mais simples e a complexidade vá aumentando aos poucos. Ao invés de se preocupar com um sistema inteiro o aluno pode se preocupar somente com uma tela, ou ainda começar com um sistema menor.

Na sequência dos problemas as serem resolvidos, o aluno vai lidando com ambientes e realidades diferentes. Quando tiver que lidar com situações de rede, aí sim poderá receber informações mais detalhadas sobre protocolos de comunicação e outras variáveis envolvidas, segurança, etc. Ele vai sentir necessidade de automatizar algumas tarefas, é aí onde entra os arquivos batch do windows e o shell script do linux. Vai lidar também com algumas telas para desktop e outras para Web. Com essa vivência o desenvolvedor iniciante vai captando o ponto chave da sua área: Existem vários contextos e o essencial é utilizar a linguagem adequada ao contexto que se está trabalhando. Se isso for bem assimilado ele vai compreender a importância de aprender várias linguagens e de ler códigos de qualidade. Eu já passei por Pascal, C e Java(não domino para projetos reais) na graduação. PHP, ASP, Javascript, Visual Fox Pro, além da linguagem de formatação CSS e agora estou experimentando Scratch, Ruby, o framework para web Ruby on Rails e a biblioteca javascript Jquery nas horas vagas.

Mas vocês podem perguntar e onde fica os problemas de IA, otimização, mineração. É como eu falei a medida que o problema for colocado, cria-se um universo propício para detalhar mais sobre ele, seja por livros, artigos, aulas com expecialistas, etc. Permitindo dessa forma que ele seja solucionado. Mas isso requer que o aluno já tenha a base anterior de resolver os problemas menos complexos. O princípio é partir sempre de um problema e a medida que for aparecendo as dificuldades, é sinal que é preciso fazer uma pausa para pesquisar fontes externas.

Isso são só princípios, gostaria de saber a opinião de vocês. E continuar essa discussão interessante.

2) Acho interessante que uma pessoa que trabalhe com linguagens de programação conheça diversas linguagens. É como um lingüísta.
Linguagens diferentes, abordagens diferentes para um mesmo problema.

3) Os mais tradicionais por algum motivo deixaram de acompanhar a evolução do objeto de estudo. É humano resistir as mudanças [e desumano programar em VB]… vejam as pessoas casadas! =)

Acho que Platão seria um ótimo desenvolvedor…