Bridging the gap

[Ronaldo Ferraz]

Salve!

Como leitor antigo de ficção científica, uma coisa que sempre me encafifou foi o seguinte: o que vai acontecer quando realmente precisarmos de programação de verdade. :)

Tirando um pouco da brincadeira, me parece que 99% do que fazemos--e nisso eu incluo todos os sistemas de grande porte que eu já escrevi e todos sobre os quais já ouvi falar, que vão muito além, é claro--são brincadeira de criança perto das necessidades futuras que temos.

Eu tenho cá comigo que grande parte do que não temos pode ser traçado na base nessa falta tecnológica. Por exemplo, micro-payments, secure environments, consensual environments, web semântica, sistemas de diagnóstico médico, e por aí vai. Arquiteturalmente, todos esses sistemas são passíveis de descrição. Programaticamente, nem tanto.

Pegando carona na citação do OMeta, pelo Thiago, me ocorre que há uma linha bem clara em que as features que vemos nas linguagens começam a quebrar para certos padrões de desenvolvimento. Quem escreve o código que escreve o código, em outras palavras.

Eu ainda não acredito em silver bullets, mas fico pensando em qual será o próximo passo; qual a próxima transformação.

Há algo nas linguagens atuais e que estão sendo desenvolvidas que já aponte algum caminho?

Especulações, especulações. :)

Abraços,

R.

[Thiago Silva]

2009/6/30 Ronaldo Ferraz <ronald...@gmail.com>:

> Salve!
> Como leitor antigo de ficção científica, uma coisa que sempre me encafifou
> foi o seguinte: o que vai acontecer quando realmente precisarmos de
> programação de verdade. :)

frequentemente me pergunto, também, o que será programação quando o
que fazemos (ou a forma com que fazemos) for considerado obsoleto.

> Tirando um pouco da brincadeira, me parece que 99% do que fazemos--e nisso
> eu incluo todos os sistemas de grande porte que eu já escrevi e todos sobre
> os quais já ouvi falar, que vão muito além, é claro--são brincadeira de
> criança perto das necessidades futuras que temos.
> Eu tenho cá comigo que grande parte do que não temos pode ser traçado na
> base nessa falta tecnológica. Por exemplo, micro-payments, secure
> environments, consensual environments, web semântica, sistemas de
> diagnóstico médico, e por aí vai. Arquiteturalmente, todos esses sistemas
> são passíveis de descrição. Programaticamente, nem tanto.

Talvez eu esteja pensando algo similar. Em geral, eu procuro imaginar
cenários que coloquem em perspectiva e me convençam de que o nosso
trabalho, atualmente, é primitivo e antiquado. Colocando nestes termos
e olhando ao redor, me parece que os softwares atuais (e a forma como
nós desenvolvemos) são exercícios rápidos e descartáveis. Creio que
estamos tateando, procurando entender aquilo que fazemos e aquilo que
criamos.

com isso, penso que os sistemas que escrevemos hoje são castelinhos de areia:
* não escalam - sua capacidade de crescer é altamente minada
* não toleram diversas abordagens de mudanças
* são extremamente frágeis
* daí, são efêmeros e descartáveis

Acho que a seguinte apresentação de Richard P. Gabriel é bastante
relevante aqui:

Architectures of extraordinarily large, self-sustaining systems
http://www.infoq.com/presentations/arch-extraordinarily-large-systems

> Pegando carona na citação do OMeta, pelo Thiago, me ocorre que há uma linha
> bem clara em que as features que vemos nas linguagens começam a quebrar para
> certos padrões de desenvolvimento. Quem escreve o código que escreve o
> código, em outras palavras.

Poderia comentar mais sobre isso?

> Eu ainda não acredito em silver bullets, mas fico pensando em qual será o
> próximo passo; qual a próxima transformação.
> Há algo nas linguagens atuais e que estão sendo desenvolvidas que já aponte
> algum caminho?

fazendo justiça ao meu bias, eu apontaria três trabalhos que me chamam
atenção (talvez eu tenha outras coisas interessantes entre os meus
diretórios, mas meu sono me impede de reunir mais material):

* implementação da pilha TCP/IP em uma DSL
http://blog.rafaelferreira.net/2008/04/couple-of-interesting-dsls.html

* A linguagem JOHN
http://www.vpri.org/pdf/rn2008003_john.pdf

* Programming as Planning
http://www.vpri.org/pdf/m2009001_prog_as.pdf

Ainda não estou certo de que estes trabalhos apontem um caminho. Mas,
diferente dos demais progressos em PL, estes são provocativos o
suficiente para estimular a investigação de outros (e novos) pontos de
vista.

[]'s
--
Thiago Silva
Computer Science
M.Sc. Candidate at Federal University of Pernambuco
jabber/gtalk: tsi...@jabber-br.org
http://blog.sourcecraft.info

[Ronaldo Ferraz]

Opa! 

Bom material para a leitura. Olhando um pouco mais sobre JOHN, lembrei do paper do Alan Kay et at, "Steps Toward the Reinvention of Programming" e achei mais informação na iniciativa dele: http://www.vpri.org/html/writings.htm. Na época que vi pela primeira vez me parecia interessante. Vou ter que ler novamente para ver se evoluiu alguma coisa desde então.

Sobre a questão que você pediu mais comentários, eu estava pensando em duas coisas:

1) Os trabalhos de Brooks, DeMarco, Connell, etc, indicam que há uma discrepância muito grande entre classes de programadores. Alguns estudos apontam que o top-tier é 10x mais produtivo/eficiente que o middle-tier que, por sua vez, é 2.5x mais eficiente que o bottom-tier. Obviamente, a maioria do que é de novo vem do top-tier mas é no middle/bottom-tier onde a implementação acontece. Será que existe até algum aspecto social limitante nisso? 

2) Será que vai chegar um ponto em que não vamos conseguir mais escrever determinadas classes de código e vamos precisar de ferramentas especiais que fazer isso. O passado parece indicar que sim: sempre foi mais fácil escrever parsers/lexers em ferramentas que geram isso embora o código final seja virtualmente incompreensível (a base, claro, é compreensível por servir como DSL). Mas será que vai chegar um ponto em que isso para de ser verdade e vamos precisar de sistemas semânticos mais fortes para resolver certos problemas?

Como eu disse, especulações, especulações. :)

Abraços,

R.

[Elomar França]

Fazendo uma aposta pro futuro, acredito que nos próximos anos teremos
muito mais dispositivos "programáveis" que o que temos hoje
(computação invisível?), e dispositivos bem diferentes - programar um
carro deve ser bem diferente de programar uma geladeira que deve ser
bem diferente de programar um relógio yada yada.

O que imagino nesse cenário é que programar as ferramentas vai ser a
parte mais importante e mais comum. Mais do que cadastros, serão
construídas DSLs e linguagens pra lidar com a vasta gama de sensores e
funções e aparelhos diferentes.

Nada novo, mas o que me preocupa é a mão-de-obra. A maioria das
"faculdades" de computação ensinam a utilizar ferramentas, e não a
criar. Acho que a tecnologia pra esse cenário de computação invisível
não está longe, mas será que teremos mão de obra pra lidar com isso?
Uma diferença ainda maior entre o top-tier e o bottom-tier?

(Ex. dessa cultura estranha nas faculdades: Prof. passou um projeto de
escrever um pequeno compilador. Maior preocupação de um grupo? Não
estavam conseguindo usar o clica e arrasta do Netbeans pra fazer a
interface).

Lendo essas referências que vocês passaram e vendo esses nomes
citados, sinto que eu estou alguns anos luz atrás de vocês e perdido
sem saber direito por onde começar, então perdoem (e corrijam)
qualquer baboseira imensa que eu falei. =)

Só pra não passar em branco :)

Elomar França
elo...@maisweb.org
twitter.com/elomar
+55 84 8855-0248

[guaracy]

Aproveitando e....

... oi para todos.

Eu não sou leitor de ficção e não sei até quanto as necessidades
futuras influenciarão na programação, pelo menos no modo que estamos
acostumados. Pessoalmente não vejo muita mudança. Teremos diversas
linguagens, diversas incompatibilidades, diversos bugs, diversos tipos
de programadores com diferentes gostos e por aí vai.

Quanto aos problemas citados pelo Thiago, acho que acontecem mas não
haveria necessidade para tal, pelo menos para alguns. Existem
problemas que não mudam significativamente com o tempo então, um
programa escrito em COBOL em 1970 poderia ser (e muitos são)
utilizados por um incerto número de anos ainda. Outros podem ser
provenientes de escolhas ou abordagens que poderiam ser diferentes.

Acho que está tudo disponível e é só juntar as peças. O problema deve
ser a aceitação x segurança (no sentido 'maria vai com as outras').


Modo propaganda:
Vou esperar o Squeakfest para me posicionar: :-)
http://squeakland.org/squeakfest/brasil/about/

Guaracy Monteiro

[Wladimir_apto_112]

Imagino como será programar em processadores quânticos (http://
www.sciencedaily.com/releases/2009/06/090628171949.htm), onde dois
qubits podem estar nos 4 estados possíveis simultaneamente.

Será que vamos ganhar dinheiro com a manutenção de "sistemas
legados" (os atuais) como o pessoal que programa Cobol ainda ganha?

--
Wladimir Boton
Blog: http://www.wboton.com
Twitter: http://twitter.com/wboton
Linkedin: http://www.linkedin.com/in/wboton

[Thiago Silva]

2009/6/30 Ronaldo Ferraz <ronald...@gmail.com>:

> Sobre a questão que você pediu mais comentários, eu estava pensando em duas
> coisas:
> 1) Os trabalhos de Brooks, DeMarco, Connell, etc, indicam que há uma
> discrepância muito grande entre classes de programadores. Alguns estudos
> apontam que o top-tier é 10x mais produtivo/eficiente que o middle-tier que,
> por sua vez, é 2.5x mais eficiente que o bottom-tier. Obviamente, a maioria
> do que é de novo vem do top-tier mas é no middle/bottom-tier onde a
> implementação acontece. Será que existe até algum aspecto social limitante
> nisso?

Talvez relacionado a isso, não sei, mas recentemente tive uma conversa
com silvio meira em que ele disse "2, 8, 90: duas pessoas escrevem,
oito comentam, noventa leem [de cada 100 pessoas]". Isso me chamou a
atenção pois, na conversa, eu estava insistindo na idéia de que
usuários são autores (e vice-versa). Mas não sei de onde vem o
conhecimento destes números, de que forma foi observado, nem o que
significa na dimensão social.

Voltando às classes de programadores, eu não sei se existe um aspecto
social limitante, mas acredito que existe um forte aspecto tecnologico
que influencia a percepção, capacidade e desenvoltura destas classes.

> 2) Será que vai chegar um ponto em que não vamos conseguir mais escrever determinadas classes de código e vamos precisar de ferramentas especiais que fazer isso. O passado parece indicar que sim: sempre foi mais fácil escrever parsers/lexers em ferramentas que geram isso embora o código final seja virtualmente incompreensível
> (a base, claro, é compreensível por servir como DSL). Mas será que vai
> chegar um ponto em que isso para de ser verdade e vamos precisar de sistemas
> semânticos mais fortes para resolver certos problemas?
>

Eu estava escrevendo um longo comentário sobre isso até notar que eu
não entendi o que vc está querendo dizer :)

Está supondo que podemos chegar num ponto em que seremos *incapazes*
de escrever determinados algoritmos?

[Thiago Silva]

2009/7/1 Elomar França <elo...@maisweb.org>:

> Nada novo, mas o que me preocupa é a mão-de-obra. A maioria das
> "faculdades" de computação ensinam a utilizar ferramentas, e não a
> criar. Acho que a tecnologia pra esse cenário de computação invisível
> não está longe, mas será que teremos mão de obra pra lidar com isso?
> Uma diferença ainda maior entre o top-tier e o bottom-tier?
>

Tem gente que acredita que os hackers vão dominar o mundo (os novos
sacerdotes, aqueles que sabem "ler e escrever" na nossa era). Eu
acredito que, de alguma forma, talvez as pessoas comuns possam
aprender a conversar com seus dispositivos (e não me refiro, aqui, a
meramente "usá-lo"). Mas não acredito que isso se realizará ensinando
Java no segundo grau.

[Ronaldo Ferraz]

Opa, Guaracy! Ótimo ver você por aqui. :)

O que eu gosto de comparar em ficção científica, especialmente no que tange a pessoas como Charles Stross e Kim Stanley Robison--para citar uns poucos--, que escrevem sobre futuro mais imediato, é o espalhamento. Um exemplo, é o caso do Halting State do Stross. O livro começa com um roubo em um banco dentro de um jogo. Dois meses depois, aconteceu algo muito similar no World of Warcraft. Probabilidades como essas vão só aumentando.

Esse é um exemplo simples e controlável dentro da nossa realidade atual. Mas, e quando coisas como realidade aumentada, realidades consensuais, processos decisórios ultra-escalonáveis, etc, coisas que já citei, começarem a acontecer. Temos ou teremos ferramentas para isso de forma direta?

Em resumo, o desenvolvimento que temos atualmente--mesmo em pesquisa--parece parco ainda. Vejo pouco se traduzir em realidade com os saltos que aconteceram algumas décadas atrás. Sim, concordo com o exemplo de Cobol mas penso de ele se traduz para o futuro quando a Lei de Moore continua a comer solta. :)

Abraços,

R.

[Ronaldo Ferraz]

Sim, exato. Não no sentido em que vamos parar, mas no sentido de que vamos precisar de extensibilidade por meio de outros sistemas para fazer isso. 

(Alias, geralmente se pensa em AI quando se fala nisso, mas aí já entra no mérito até da possível existência disso. Eu penso mais em sistemas secundários.)

R.

[Walter Cruz]

Excetuando talvez o Guaracy, que demonstra pensar diferente, alfinetando o Ronaldo e o Tits que morrerá em sua procura de exprimir-se em forma de código:

Vocês sentem que em algum ponto a figura do programador será obsoletada? (desculpem a palavra, estou com fome e não consigo pensar noutra melhor)
Vocês sentem que seus códigos nascem já fadados a sepultura? Se a resposta for sim, como vocês lidam com isso?

--
[]'
- Walter
waltercruz.com

[Ronaldo Ferraz]

Na verdade, não. :)

Eu estou pensando mais em quais são as ferramentas necessárias para realmente criar sistemas de porte universal. Eu sei que sou muito confuso mas deixa eu tentar dar um exemplo mais claro:

Suponha que em algum momento do futuro próxima, a Internet se torne completamente pervasiva. Você não tem mais desktop ou laptop: seu celular é tudo isso e mais um pouco. 

Chegando em casa, ele fala com as telas que estão nas paredes que se transformam em superfícies computacionais da forma que você precisar. Todos sistemas de sua casa são integrados: sua geladeira fala com o supermercado; seu sistema de música automaticamente dispara agentes para buscar músicas baseado no que você gostou de ouvir nos últimos dias sejam de gravadores famosas ou de artistas independentes, que, nesse momento, são a vasta maioria na verdade.

Você quase não trabalha mais presencialmente, exceto por uma ou outra reunião--o resto, acontece em um espaço de realidade aumentada que a extranet segura de sua empresa instanciou automaticamente para o projeto. Para todos os propósitos práticos, você está a alguns metros de distância de qualquer pessoa que você precisa mesmo que elas estejam do outro lado do mundo.

E naquele projeto em particular, quando um seu co-worker lhe manda algo tudo o que ele faz é escrever em um espaço compartilhado na realidade consensual que é o projeto, jogando ícones para lá e para cá, que todos vão acessando e modificando para fazer o trabalho. 

É claro que, por trás das cenas nesse ponto, há um intenso tráfego seguro com chaves públicas sendo trocadas a todo momento entre vários players para que isso aconteça. Protocolos de colaboração em larga escala falam entre si e instanciam automaticamente o ferramental necessário para que as coisas aconteçam. Agentes e sistemas inteligentes navegam pelo tráfego todo analisando contexto, fazendo sugestões, garimpando dados, corrigindo falhas.

Em suma, você está imerso nisso tudo se forma transparente e pervasiva.

A pergunta é: qual é o tipo de programação necessária para fazer isso acontecer, de hardware a software?

R.

2009/7/2 Walter Cruz <walte...@gmail.com>

[Thiago Silva]

2009/7/2 Ronaldo Ferraz <ronald...@gmail.com>:

> Sim, exato. Não no sentido em que vamos parar, mas no sentido de que vamos
> precisar de extensibilidade por meio de outros sistemas para fazer isso.
> (Alias, geralmente se pensa em AI quando se fala nisso, mas aí já entra no
> mérito até da possível existência disso. Eu penso mais em sistemas
> secundários.)
> R.
>

Acho que, para muitos, a programação sairia desse primitivismo e se
tornaria diálogo/negociação com máquinas (ou seja, IA).

Acho que outra vertente seria termos os ultra-large self-sustaning
systems onde teriamos estas coisas vivas e ubíquas, e
estudariamos/programariamos seus "órgãos" (a versão madura da criança
que chamamos hoje de "componentes"). Hoje, criamos as coisas
repetidamente ("reuso" ainda está na idade fetal, a começar pelo seu
próprio termo: "reuso" - IMHO). Talvez, amanhã, estaremos estudando e
"programando" "orgãos" que evoluem naturalmente....

De qualquer forma, eu acho que sistemas biológicos e tecnológicos
serão bastante parecidos em algum momento....não vejo outra tendência.
Por isso que estou convencido que o marco zero é fazer softwares que
não param e são modificados enquanto rodam. Sem isso, a gente vai
ficar aqui brincando de detonar prédios e construí-los novamente, sem
nunca chegar no céu (eis meus 2 centavos).

[Thiago Silva]

2009/7/2 Walter Cruz <walte...@gmail.com>:

> Vocês sentem que em algum ponto a figura do programador será obsoletada?
> (desculpem a palavra, estou com fome e não consigo pensar noutra melhor)
> Vocês sentem que seus códigos nascem já fadados a sepultura? Se a resposta
> for sim, como vocês lidam com isso?
>
> --

Acho que não (seremos obsoletos). Em certo sentido, somos todos
programadores, criando e configurando o mundo ao redor. Mas no nosso
caso (o codeiro), especificamente, acho que o ponto todo das máquinas
é ter alguém para configurá-las e dizer-lhes o que fazer. Esse é o
programador, seja codando, seja dizendo o que quer, e ver o que ele
pediu se manifestar automaticamente.

<caminhando-nas-nuvens>
Se IA amadurecer pra valer, as máquinas com IA deixarão de ser simples
máquinas e serão outros seres com quem teremos que lidar. Se elas
estarão à nosso serviço, então acho que a figura do programador some,
se tornando uno com a figura do usuário (aquele que vive pedindo, e
tendo alguém que faça o trabalho sujo) - a programação volta a ser
ensinar/ordenar. Se elas não estiverem a nosso serviço, iremos
construir máquinas sem IA, pra fazer o que as que tem IA não fazem por
nós.

Sem IA amadurecida como inteligência real, acho que a figura do ser
humano configurando/programando o ambiente (a rede, o mundo virtual, o
computador) será sempre necessária. Pessoas são necessarias para
transmitir objetivos/regras/etc para que as máquinas realizem. E como
objetivos/regras/etc mudam nas pessoas, na sociedade, este papel é
sempre necessario. Ou pelo menos, será sempre necessario até que algum
ponto meta-estável seja atingido na sociedade.
</caminhando-nas-nuvens>

Sobre os códigos, eu acho que eles já nascem fadados à sepultura (os
meus, pelo menos), assim como gols feitos em partidas amistosas e
treinos não servem à pontuação alguma. São exercícios, creio....e eu
lido isso vendo justamente desta forma.

[Wladimir]

Ronaldo,

não vejo a necessidade novos tipos de programação para esse futuro que
você descreve. A maioria dos algoritmos para criar esse futuro já
existem. O que vai aumentar é poder de processamento e novas
tecnologias interativas como telas sensiveis ao toque maiores e mais
baratas, sistemas de projeção 3D ou holográficos, novos tipos de
sensores e cameras para "sentir" o ambiente e interagir com ele.

E quem vai programar os softwares necessários para tudo isso funcionar
serão os mesmos tipo de programadores que temos hoje, só que em maior
número. Empresas surgirão criando partes cada vez mais especializadas
desse mundo futuro. E quanto a interação de tudo isso entre si,
continuaremos a ter os mesmos problemas de incompatibilidades
existentes hoje se as decisões continuarem a serem tomadas com base no
market share e vantagens competitivas entre as empresas.

As ferramentas para os programadores continuarão a ser justamente
isso, ferramentas. Algumas com algumas firulas a mais que as outras.
Em alguns casos ainda haverá gente utilizando o velho vi ou emacs como
existe hoje mesmo tendo ferramentas sofisticadas com o Eclipse,
Netbeans, VS, e outras mais especializadas.

O pulo tecnologico acontecerá quando tivermos o poder de
processamento, capacidade de armazenamento e conhecimento suficiente
para simular algumas das funções do cérebro humano. Somente quando as
máquinas puderem ler um texto e "entendê-lo" de maneira semelhante a
nossa, ou ver como vemos, ou ouvir e entender o contexto do que está
ouvindo e suas implicações culturais é que teremos ganhos
significativos em nossa vida.

Quando passarmos por essa fase de simular nosso cérebro na área
sensorial e cognitiva, talves passemos para a fase da simulação da
criatividade onde o software passará a criar novos softwares. E ai não
precisaremos mais de programadores, ainda mais porque nenhum humano
entenderá como o software criado por outro funciona.

Antes disso ainda vejo alguns softwares criados (ou seria "evoluíndo")
por algoritmos genéticos, mais redes neurais resolvendo problemas
complexos, e mais algumas linguagens especializadas em alguns domínios
mais díficeis. Incluindo ainda a computação quântica em problemas
matemáticos que hoje não temos como solucionar.

--
Wladimir Boton
Blog: http://www.wboton.com
Twitter: http://twitter.com/wboton
Linkedin: http://www.linkedin.com/in/wboton

> 2009/7/2 Walter Cruz <walter....@gmail.com>

[Ronie Uliana]

Tenho para comigo que não estamos evoluindo o software, estamos
patinando o tempo todo, com pouco avanço.

Já repararam como estamos reinventando a mesma coisa desde
mil-novecentos-e-vovó-gostosa? Ruby é um Smalltalk "a la" script.
Closures, tão acaloradamente debatidos no Java, estão aí fazem
décadas, Máquinas vituais? Vixi. Garbage collector?... e por aí vai.

Alguém, acho que o Paul Graham (papa de LISP), disse que quanto mais
as linguagens evoluem, mais "features" do LISP elas implementam. :D
Acho que ele tem razão, qdo chegarmos no ponto que os caras estavam em
idos de 1960, aí quem sabe comecem a aparecer evoluções de verdade que
capacitem a gente a fazer essas traquitanas tecnológicas todas
funcionarem como os autores dos livros de ficção esperem que funcionem
:)

Mas, tirando as observações sacártiscas, eu apontaria que o futuro são
linguagens declarativas, como SQL e Prolog, onde você diz "o quê"
quer, não "como" vai fazer. E isso tem um potencial sem limite.

Na marcha em que redescobrimos LISP, ainda vai uns 10 ou 15 anos para
chegarmos em 1960, Prolog é de 72, são mais uns 15 anos, com sorte.
Para evoluir o Prolog para algo útil... noves fora, chuto que daqui
uns 40 anos vamos ter a resposta do Ronaldo :)

[]s
Ronie



2009/7/2 Thiago Silva <tsil...@gmail.com>:

[Ronaldo Ferraz]

Opa, Wlad!

Concordo com a parte de mercado e concordo em parte com a necessidade de aumento de processamento. Mas, como você mesmo descreve abaixo, um grande pulo acontece quando conseguirmos simular funções do cérebro humano. Especulando livremente mais uma vez, pergunto: e se isso não é possível com o ferramental que temos hoje?

Por exemplo, em 56 Chomsky formalizou boa parte da questão de gramáticas em sua hierarquia de gramática. Evoluímos bastante na parte de CFGs mas virtualmente nada nas gramáticas mais genéricas. Mais uma vez: e se o que temos hoje não é suficiente para fazer isso? Por que, se não for, boa parte do que eu menciono no exemplo não é possível de maneira (relativamente) trivial.

Óbvio, estou especulando longe aqui. Mas existem problemas mais simples: hoje não conseguimos nem fazer DSLs que possam ser programadas por usuários comuns com recuperação de erro trivial. É possível? Não sei. O Thiago talvez possa responder melhor. :)

Abraços,

R.

2009/7/2 Wladimir <wbo...@gmail.com>

[Ronaldo Ferraz]

Hehehehe. É a mesma sensação que eu tenho. Infelizmente, minha competência é tão limitada que eu só posso fazer perguntas. Quisera eu ter a capacidade de respondê-las concretamente. :)

Abraços,

Ronaldo "que no momento está apanhando de uma PEG" Ferraz

2009/7/2 Ronie Uliana <ronie....@gmail.com>

[Thiago Silva]

2009/7/2 Ronie Uliana <ronie....@gmail.com>:

>
> Tenho para comigo que não estamos evoluindo o software, estamos
> patinando o tempo todo, com pouco avanço.
>

Concordo.

> Já repararam como estamos reinventando a mesma coisa desde
> mil-novecentos-e-vovó-gostosa? Ruby é um Smalltalk "a la" script.
> Closures, tão acaloradamente debatidos no Java, estão aí fazem
> décadas, Máquinas vituais? Vixi. Garbage collector?... e por aí vai.
>

Eu levantei isso outro dia numa discussão com meu orientador. A
resposta recorrente foi: mercado. mercado. mercado.

No FISL, levantei de novo a questão numa mesa de restaurante. Me
pergunto até que ponto a força que o mercado aplica na escolha das
ferramentas e abordagens de desenvolvimento (que, como sabemos, não
equivalem ao estado da arte nem no cheiro) não enterram a si mesmo e a
sociedade? Alguns acham que a coisa se auto regula, cedo ou tarde.
Outros acham que isso é irrelevante. Mas, afinal, este fenômeno, estes
acidentes, retardam o progresso ou são apenas mecanismos que a
sociedade utiliza para ter tempo de absorver novas tecnologias?

Recentemente, numa entrevista com dan ingalls (engenheiro de diversas
máquinas virtuais Smalltalk), randal schwartz disse que conversou com
Woz e perguntou por que os produtos da apple na época (Lisa, etc) não
tinham o SO em smalltalk. Pelo que lembro, ele respondeu que teriam
que escrever o SO do zero, e o hardware não era rápido o suficiente. O
resultado, no podcast, foi uma surpresa enorme, e um monte de "what
if" nostálgicos.

what if?

> Alguém, acho que o Paul Graham (papa de LISP), disse que quanto mais
> as linguagens evoluem, mais "features" do LISP elas implementam. :D
> Acho que ele tem razão, qdo chegarmos no ponto que os caras estavam em
> idos de 1960, aí quem sabe comecem a aparecer evoluções de verdade que
> capacitem a gente a fazer essas traquitanas tecnológicas todas
> funcionarem como os autores dos livros de ficção esperem que funcionem
> :)
>
> Mas, tirando as observações sacártiscas, eu apontaria que o futuro são
> linguagens declarativas, como SQL e Prolog, onde você diz "o quê"
> quer, não "como" vai fazer. E isso tem um potencial sem limite.
>

O que me lembra. No paper de J.C.R Licklider "Man Computer Symbiosis"
(que, a propósito, acho que é extremamente relevante para esta
discussão), ele diz que as pessoas pensam melhor em termos de
objetivos do que em termos de instruções. Alan Kay sabia disso e, até
onde sei, a noção que ele tem de programação considera esta faceta.

> Na marcha em que redescobrimos LISP, ainda vai uns 10 ou 15 anos para
> chegarmos em 1960, Prolog é de 72, são mais uns 15 anos, com sorte.
> Para evoluir o Prolog para algo útil... noves fora, chuto que daqui
> uns 40 anos vamos ter a resposta do Ronaldo :)
>

Amém

[Thiago Silva]

2009/7/2 Ronaldo Ferraz <ronald...@gmail.com>:

> Em suma, você está imerso nisso tudo se forma transparente e pervasiva.
> A pergunta é: qual é o tipo de programação necessária para fazer isso
> acontecer, de hardware a software?
> R.
>

Vou tentar comentar esta pergunta em duas vertentes: uma sobre o ato
de programar, e outra sobre organização/design de sistemas.

Para começar, eis como vejo a nossa tragédia em 4 observações óbvias:

1) Estamos continuamente construindo software (ou seja, assumimos que
esta tarefa não tem fim) para atender um fluxo contínuo de demandas
desconhecidas;
2) Seja lá o que formos construir, temos que partir de um design inicial;
3) Cada peça que adicionamos ao software torna o design que escolhemos
mais denso;
4) Como estamos continuamente atendendo demandas desconhecidas, cedo
ou tarde, uma nova demanda muda a nossa percepção que, por
consequência, nos leva a considerar inapropriado o design escolhido.

Claro que estou considerando aqui a construção de softwares cujas
demandas satisfazem o item 1 (nem todos os softwares possuem demandas
desconhecidas).

Minha opnião sobre o ponto fundamental de atrito da atividade de
desenvolvimento é: como mudar de idéia aqui (na mente), mudando de
idéia ali (no software) sem passar pelo inferno que passamos há
decadas? A turma do Alan Kay defende late binding agressivo se
sustentando justamente no fato de que não sabemos desenvolver
softwares - daí precisarmos de mecanismos que nos permitem mudar de
idéia de forma mais sofisticada. Ainda, como o Ronie apontou,
trabalhar especificando objetivos nos dá uma margem mais interessante,
e talvez este tipo de problema diminua ou, quem sabe, desapareça
mudando apenas a abordagem.

E isso me leva à outras questões: até que ponto conseguiremos entender
os programas que estarão rodando? Até que ponto seremos capazes de
traçar e verificar se sua execução é correta? Até que ponto isso é
desejável?

Agora, com computadores quânticos ou não, eu acho que estes problemas
permanecem. Claro, teremos maior poder de processamento. Mas já temos
hoje um certo tanto e, no entanto, não utilizamos. Se teremos muito,
muito mais amanhã, ok, talvez determinados algoritmos saiam do campo
impraticável. Mas eu não sei até que ponto o poder de processamento
(ou o tipo de algoritmos que poderemos utilizar) iluminará soluções
para os problemas mencionados acima. O problema, ao meu ver, não é
hardware, mas sim, nosso entendimento sobre a criação e evolução de
*sistemas*.

Daí a segunda vertente: escrever código que vai pro saco daqui há uns
anos todos nós escrevemos. Como criar e organizar sistemas pervasivos
que evoluem e escalam? Eu imagino que, ou a coisa toda se tornará uma
caixa preta auto-sustentável que configuramos apenas dizendo o que
queremos (e não, como fazer), ou temos que levantar as mangas para
entrar no sistema, e isso, acredito eu, necessariamente exige que ele
seja entendível em diversos "níveis", que possua várias dimensões de
interação, navegação e programação; que possa ser experimentado e
investigado de forma segura, sem quebrar....enfim, só sei que arquivos
fontes e diretórios não dão conta do recado =P

[guaracy]

> Opa, Guaracy! Ótimo ver você por aqui. :)

Obrigado. E é bom ver todo mundo por aqui (quem eu conheço e quem não
conheço). Desejo sucesso para nós. :-)

...

> Em resumo, o desenvolvimento que temos atualmente--mesmo em pesquisa--parece
> parco ainda. Vejo pouco se traduzir em realidade com os saltos que
> aconteceram algumas décadas atrás. Sim, concordo com o exemplo de Cobol mas
> penso de ele se traduz para o futuro quando a Lei de Moore continua a comer
> solta. :)

Vai ver que o processo é assim mesmo. Já passamos da *Revolução da
Informática* e agora estamos apenas evoluindo lentamente em algumas
áreas (tipo uma revolução industrial que começa com um motor a vapor,
causa grandes modificações e depois se equilibra; o barco a vapor cede
lugar ao barco movido a diesel e mais luxuoso e só)

Guaracy Monteiro

[guaracy]

> Excetuando talvez o Guaracy, que demonstra pensar diferente, alfinetando o
> Ronaldo e o Tits que morrerá em sua procura de exprimir-se em forma de
> código:

Bem, não foi minha intenção alfinetar ninguém. Apenas expressei o meu
pensamento.

> Vocês sentem que em algum ponto a figura do programador será obsoletada?
> (desculpem a palavra, estou com fome e não consigo pensar noutra melhor)
> Vocês sentem que seus códigos nascem já fadados a sepultura? Se a resposta
> for sim, como vocês lidam com isso?

Eu acho que o programador não se tornará obsoleto. Pelo menos em um
futuro não tão distante. Não gosto de pensar que meus códigos sejam
fadados a sepultura. Pelo menos não os faço assim. Eles são destinados
a resolver problemas e, enquanto estiverem resolvendo, tudo bem. O que
pode alterar o ciclo de vida deles são as frescuras que os fabricantes
inventam (seja a incompatibilidade com SOs futuros seja por não ter o
fundo rosa com as letras verdes que pode ser adotado pela maioria em
um futuro qualquer).

[guaracy]

...

> As ferramentas para os programadores continuarão a ser justamente
> isso, ferramentas. Algumas com algumas firulas a mais que as outras.
> Em alguns casos ainda haverá gente utilizando o velho vi ou emacs como
> existe hoje mesmo tendo ferramentas sofisticadas com o Eclipse,
> Netbeans, VS, e outras mais especializadas.

Concordo já que foi um texto parecido com o meu mas mais explicativo.
Eu não deveria fazer esse comentário, mas .....

s/ferramentas sofisticadas/outras ferramentas/

[guaracy]

> Concordo com a parte de mercado e concordo em parte com a necessidade de
> aumento de processamento. Mas, como você mesmo descreve abaixo, um grande
> pulo acontece quando conseguirmos simular funções do cérebro humano.
> Especulando livremente mais uma vez, pergunto: e se isso não é possível com
> o ferramental que temos hoje?

Talvez sim. Só falta saber como exatamente. Outro fato é a integração
da programação com os elementos externos. Acho fácil conectar um
refrigerador com um supermercado. O difícil é o controle do que entra
e do que sai do refrigerador.

> Por exemplo, em 56 Chomsky formalizou boa parte da questão de gramáticas em
> sua hierarquia de gramática. Evoluímos bastante na parte de CFGs mas
> virtualmente nada nas gramáticas mais genéricas. Mais uma vez: e se o que
> temos hoje não é suficiente para fazer isso? Por que, se não for, boa parte
> do que eu menciono no exemplo não é possível de maneira (relativamente)
> trivial.

Talvez a gramática seja algo muito extenso e a simplificação dele seja
algo muito complexo. Se pegar uma linguagem com J, temos verbos,
advérbios e, um é uma coisa (ou pode ser diferente dependendo do que
vem antes e depois mas juntando os dois temos outra coisa. O resultado
é que fica algo difícil de ler e entender facilmente.

> Óbvio, estou especulando longe aqui. Mas existem problemas mais simples:
> hoje não conseguimos nem fazer DSLs que possam ser programadas por usuários
> comuns com recuperação de erro trivial. É possível? Não sei. O Thiago talvez
> possa responder melhor. :)

Será que a DSL não foi feita apenas para o programador resolver a
tarefa? Acho que se for para o usuário, ele deveria criar a DSL e o
programador implementar.

[guaracy]

...

> Agora, com computadores quânticos ou não, eu acho que estes problemas
> permanecem. Claro, teremos maior poder de processamento. Mas já temos
> hoje um certo tanto e, no entanto, não utilizamos. Se teremos muito,
> muito mais amanhã, ok, talvez determinados algoritmos saiam do campo
> impraticável. Mas eu não sei até que ponto o poder de processamento
> (ou o tipo de algoritmos que poderemos utilizar) iluminará soluções
> para os problemas mencionados acima. O problema, ao meu ver, não é
> hardware, mas sim, nosso entendimento sobre a criação e evolução de
> *sistemas*.
>
> Daí a segunda vertente: escrever código que vai pro saco daqui há uns
> anos todos nós escrevemos. Como criar e organizar sistemas pervasivos
> que evoluem e escalam? Eu imagino que, ou a coisa toda se tornará uma
> caixa preta auto-sustentável que configuramos apenas dizendo o que
> queremos (e não, como fazer), ou temos que levantar as mangas para
> entrar no sistema, e isso, acredito eu, necessariamente exige que ele
> seja entendível em diversos "níveis", que possua várias dimensões de
> interação, navegação e programação; que possa ser experimentado e
> investigado de forma segura, sem quebrar....enfim, só sei que arquivos
> fontes e diretórios não dão conta do recado =P

Agora lembrei de um livro. ( http://thinking-forth.sourceforge.net/ ).
Acho que vale baixar nem que seja só para ver as ilustrações (algumas
hilárias).

O livro é de 1984 (pode ser mais velho do que muitos aqui). Um trecho
que eu acho interessante

"...
Programming computers can be crazy-making. Other professions give you
the
luxury of seeing tangible proof of your efforts. A watchmaker can
watch the
cogs and wheels; a seamstress can watch the seams come together with
each
stitch. But programmers design, build, and repair the stuff of
imagination,
ghostly mechanisms that escape the senses. Our work takes place not in
RAM,
not in an editor, but within our own minds.
..."

Será que isso mudou de 1984 para cá? Ou de quando fizeram o primeiro
programa? Pessoalmente acho que não. O fato da resolução do problema
estar na nossa cabeça é o principal motivo da dificuldade de
manutenção até por nós mesmos. Quando eu vejo alguém dizendo que o
código deve ser legível, para mim não significa muita coisa. Se o
problema for somar dois números, não tem problema. Mas se for algo
grande, pode dificultar mesmo se a demanda for conhecida.

Acho que o entendimento dos programas é o principal entrave para
outras coisas. Cada um aborda o problema de uma forma e, para
entender, é necessário pensar como o outro o que pode ser uma tarefa
difícil. As vezes pode ser mais fácil refazer um programa do que
apenas efetuar algumas alterações.

[guaracy]

> Hehehehe. É a mesma sensação que eu tenho. Infelizmente, minha competência é
> tão limitada que eu só posso fazer perguntas. Quisera eu ter a capacidade de
> respondê-las concretamente. :)

Pelo que vejo, a competência de todos é limitada para as respostas.
Não digo de todos deste grupo, pois as perguntas não são novas. As
respostas são como o Ronie escreveu mas não acho que a resposta seja
tão simples assim. Acho que enquanto existirem programadores "umanos",
os problemas continuarão. :-)

[Tony Fabeen]

Minha simples opinião.

Como sempre :

  - Surgirão novas linguagens.
  - Reinventarão a roda.
  - Surgirão novos frameworks, e seus criadores irão ser tratados como "Pop Stars" caso estes venham a se tornar "mainstream"
  - Existirá o mundo corporativo. E um conjunto de  empresas responsáveis por criar uma nova sopa de letrinhas e ditar soluções da moda.
  - Haverá o marketing.
  - Haverá emprego para os profissionais capacitados.

[]s

Tony.

--
Tony Fabeen.
http://www.infoq.com/br
http://www.keeponrightway.com
"All the average think Gauss although all the innovators think Pareto".
(Unknown)

[Rodrigo Kumpera]

On Jul 3, 1:28 am, Thiago Silva <tsilva...@gmail.com> wrote:
> 2009/7/2 Ronaldo Ferraz <ronaldofer...@gmail.com>:

Apesar de achar oque o pessoal do VRPI está fazendo muito
interessante,
eu acredito não acho que qualquer coisa de realmente revolucionário
irá sair
de lá. Meus ovos estão na cesta do Simon Peyton-Jones e seus
comparsas.

Ou melhor, nem na deles, pois quase não tem grupos tentando resolver
aquilo
que eu considero o real grande problema dos sistemas atuais, que é:
Quantas linhas de código precisa um hello world?

Em python: print "hello world"

E a resposta? Uma? Não, aqui são: [1]

python: 685mil C 688mil python
glibc: 873mil C 173mil assembly
kernel: 7.200mil C 229mil assembly

Total:
8758mil linhas de código C
402mil linhas de código assembly!
688mil + 1 linhas de código python

Poderíamos estar falando de um software enorme, 1 milhão de linhas de
código, e ainda assim
a maior parte dele continuaria sendo escrita em C. Então do que
adiantaria aqui trocar Java por
python, por smalltalk, ou seja lá oque for que sair do View Points, se
a principal parte continuará
escrita em C e em assembly.

As métricas que foram mencionadas aqui compartilham uma coisa em
comum, todas estão limitadas
pelo componente mais fraco. Então enquanto forem necessárias muitos
milhões de linhas de código para
o hello world da tua linhagem e o ambiente for tão frágil quanto
aquilo que temos hoje, nada irá mudar muito.

Se isso é um rant contra C? Sim, é. Não pela linguagem ser um
desastre, mas pelas alternativas serem piores. [2]

Não adianta querem discutir como se construir um maravilhoso ambiente
de programação se ele tiver de ser criado
usando algo tão tosco quanto C.

Todos os sinais do anacronismo do C existem, dos que usam aos que
consomem, dos que tentam escrever um programa
multi-threaded aos que tentam extrair mais informação dos fontes para
melhorar um compilador.

Dito isso, eu vejo que o maior problema hoje não está nas linguagens
de programação em si, mas no ambiente no qual
elas executam. São frágeis, simplórios e desprovido de qualquer forma
de inovação. Basta ver que em 20 anos se produziu
somente uma VM não convencional, a do Erlang, o resto todo é sempre
uma variação sobre o mesmo tema.

Porém como podemos esperar que alguém inove no universo dos ambientes
de execução quando custa muitos anos homem
para se produzir um sofisticado o suficiente para uso em produção.
Ninguém ainda conseguiu produzir, do zero, uma VM inteira
com escala industrial com menos de 100 anos/homem.

Ou seja, enquanto produtizar o trabalho de um doutorado nessa área
continuar custando coisa de 10milhões de dólares e vários
anos, nada vai mudar.

Essa é minha opinião, em vez de criarem mil LISPs e 500 smalltalks,
matem somente um C que o resto vem sozinho.

[1] Número tirado do ohloh.net, excluindo todas libs em C que o python
depende.
[2] C++ é, fundamentalmente, C com tempo extra de compilação.

[Ronaldo Ferraz]

2009/7/3 guaracy <guara...@gmail.com>:

> Pelo que vejo, a competência de todos é limitada para as respostas.
> Não digo de todos deste grupo, pois as perguntas não são novas. As
> respostas são como o Ronie escreveu mas não acho que a resposta seja
> tão simples assim. Acho que enquanto existirem programadores "umanos",
> os problemas continuarão. :-)

Ah, com certeza. Para mim, o legal nessa discussão é especular
justamente sobre as variações--ver os pontos de vistas individuais,
modos como cada um programa, e ver o que pode sair. Pelo que vejo, de
todos nós, o único fazendo algo realmente fora da curva usual de
desenvolvimento é o Thiago.

Eu tenho que confessar que essa discussão é um bálsamo off-work para
mim. Ultimamente meu mundo tem consistindo mais em liderar três
gerências distintas de arquitetura, engenharia e pesquisa de software
deixando--infelizmente--muito pouco tempo para código. :(

Abraços,

R.

[Ronaldo Ferraz]

2009/7/3 guaracy <guara...@gmail.com>:

> Talvez sim. Só falta saber como exatamente. Outro fato é a integração
> da programação com os elementos externos. Acho fácil conectar um
> refrigerador com um supermercado. O difícil é o controle do que entra
> e do que sai do refrigerador.

Ou não. Talvez isso seja o mais fácil e o difícil realmente seja
controlar as preferências distintas das cinco pessoas que vivem
naquela cada e manter um mapa heurístico de disponibilidade.
Provavelmente possível com o que temos hoje, claro. Mas do lado do
supermercado pode não ser tão trivial. :)

> Talvez a gramática seja algo muito extenso e a simplificação dele seja
> algo muito complexo. Se pegar uma linguagem com J, temos verbos,
> advérbios e, um é uma coisa (ou pode ser diferente dependendo do que
> vem antes e depois mas juntando os dois temos outra coisa. O resultado
> é que fica algo difícil de ler e entender facilmente.

Com certeza. Se pensarmos no que já foi falado na thread sobre
permitir que os próprios usuários programem (viva o LCARS), alguma
coisa mais interessante e complexa pode ser necessária com uma
interface gramatical transparente.

> Será que a DSL não foi feita apenas para o programador resolver a
> tarefa? Acho que se for para o usuário, ele deveria criar a DSL e o
> programador implementar.

Geralmente sim, é feita para programadores. O converso é sempre um
pouco mais complicado e suscetível a erros esdrúxulos.

R.

[Ronaldo Ferraz]

Ah, certamente. Eu duvido que isso mude muito também já que esse é o
framework social em que operamos. Haverão os Hiro Protagonists da
vida, mas nada muito diferente do que hoje. Eu estou mais interessado
nas novas rodas que terão que ser reinventadas. :)

R.

2009/7/3 Tony Fabeen <tony....@gmail.com>:

> Minha simples opinião.
>
> Como sempre :
>
>   - Surgirão novas linguagens.
>   - Reinventarão a roda.
>   - Surgirão novos frameworks, e seus criadores irão ser tratados como "Pop
> Stars" caso estes venham a se tornar "mainstream"
>   - Existirá o mundo corporativo. E um conjunto de  empresas responsáveis
> por criar uma nova sopa de letrinhas e ditar soluções da moda.
>   - Haverá o marketing.
>   - Haverá emprego para os profissionais capacitados.
>
> []s
>
> Tony.
>

> 2009/7/3 guaracy <guara...@gmail.com>

[Ronaldo Ferraz]

Ponto muito bom, Kumpera.

Acho que você tocou mais a fundo na questão que eu estava querendo
explorar e quantificou melhor o problema para mim: linguagens de
programação refletem intrinsecamente o seu ambiente de execução e
existe pouco esforço além dos que você mencionou abaixo para lidar (ou
mesmo quantificar) com isso.

Obviamente, isso leva à questão de que uma nova plataforma baixa ainda
significaria a criação de dois layers distintos de programação para
usos diferentes (core/meta dev e user dev). Obviamente, core/meta é o
que precisa evoluir aqui.

Abraços,

R.

2009/7/3 Rodrigo Kumpera <kum...@gmail.com>:

[Rodrigo Kumpera]

O Rob Pike já falava disso à quase uma década, de que a pesquisa em software de
base basicamente morreu. http://doc.cat-v.org/bell_labs/utah2000/

2009/7/4 Ronaldo Ferraz <ronald...@gmail.com>

[Thiago Silva]

que legal ver o kumpera aqui :)

2009/7/3 Rodrigo Kumpera <kum...@gmail.com>:

> Apesar de achar oque o pessoal do VRPI está fazendo muito
> interessante,
> eu acredito não acho que qualquer coisa de realmente revolucionário
> irá sair
> de lá. Meus ovos estão na cesta do Simon Peyton-Jones e seus
> comparsas.

Por que seus ovos estão (estariam) nesta turma?

> Dito isso, eu vejo que o maior problema hoje não está nas linguagens
> de programação em si, mas no ambiente no qual
> elas executam. São frágeis, simplórios e desprovido de qualquer forma
> de inovação. Basta ver que em 20 anos se produziu
> somente uma VM não convencional, a do Erlang, o resto todo é sempre
> uma variação sobre o mesmo tema.
>
> Porém como podemos esperar que alguém inove no universo dos ambientes
> de execução quando custa muitos anos homem
> para se produzir um sofisticado o suficiente para uso em produção.
> Ninguém ainda conseguiu produzir, do zero, uma VM inteira
> com escala industrial com menos de 100 anos/homem.
>

Me pergunto qual o papel, neste custo, do "ambiente frágil" subjacente
utilizado no desenvolvimento das VMs....

> Ou seja, enquanto produtizar o trabalho de um doutorado nessa área
> continuar custando coisa de 10milhões de dólares e vários
> anos, nada vai mudar.
>
> Essa é minha opinião, em vez de criarem mil LISPs e 500 smalltalks,
> matem somente um C que o resto vem sozinho.
>

E como ocupar o espaço de C? BitC [1] ? COLA [2]?

A propósito, acho que é a terceira vez que vejo vc levantar estes
pontos....o que falta para vc cansar e procurar matar o C com as
próprias mãos? ;)

[1] - http://www.bitc-lang.org/
[2] - http://piumarta.com/software/cola/

[Thiago Silva]

2009/7/4 Ronaldo Ferraz <ronald...@gmail.com>:

>
> 2009/7/3 guaracy <guara...@gmail.com>:
>> Pelo que vejo, a competência de todos é limitada para as respostas.
>> Não digo de todos deste grupo, pois as perguntas não são novas. As
>> respostas são como o Ronie escreveu mas não acho que a resposta seja
>> tão simples assim. Acho que enquanto existirem programadores "umanos",
>> os problemas continuarão. :-)
>
> Ah, com certeza. Para mim, o legal nessa discussão é especular
> justamente sobre as variações--ver os pontos de vistas individuais,
> modos como cada um programa, e ver o que pode sair. Pelo que vejo, de
> todos nós, o único fazendo algo realmente fora da curva usual de
> desenvolvimento é o Thiago.
>

Também concordo que esse é o ouro na discussão. Mas, a titulo de
esclarecimento, eu não estou fazendo nada fora da curva usual. Melhor
dizendo, eu não estou fazendo nada, além de estudar. Eu tenho uma
ótima oportunidade de fazer coisas insanas por estar no mestrado mas
minha capacidade e habilidade impõem um certo limite naquilo que sou
capaz de fazer no momento.

> Eu tenho que confessar que essa discussão é um bálsamo off-work para
> mim. Ultimamente meu mundo tem consistindo mais em liderar três
> gerências distintas de arquitetura, engenharia e pesquisa de software
> deixando--infelizmente--muito pouco tempo para código. :(
>
> Abraços,
>
> R.

Devemos esse espaço a você, cara :)

[Thiago Silva]

Eu me apoio na idéia que nossa área está na infância. A idéia de
continuar na infância me frustra de forma intensa. Se estamos na
infância, deduzo que o amadurecimento mostrará coisas bem diferentes
de fazer as coisas.

No mínimo, tem muito atrito ocorrendo, muito atrito que passa
despercebido (somos treinados a nos anestesiar) e que já sabemos
resolver e não resolvemos. E, no mínimo, procuro torná-los explícitos,
mostrando a ferida e como dói.

Por uma nova era! (hehe)


2009/7/4 Ronaldo Ferraz <ronald...@gmail.com>:

[Thiago Silva]

2009/7/4 Thiago Silva <tsil...@gmail.com>:

> Eu me apoio na idéia que nossa área está na infância. A idéia de
> continuar na infância me frustra de forma intensa. Se estamos na
> infância, deduzo que o amadurecimento mostrará coisas bem diferentes
> de fazer as coisas.
>
> No mínimo, tem muito atrito ocorrendo, muito atrito que passa
> despercebido (somos treinados a nos anestesiar) e que já sabemos
> resolver e não resolvemos. E, no mínimo, procuro torná-los explícitos,
> mostrando a ferida e como dói.
>
> Por uma nova era! (hehe)
>

Tarde, mas em tempo:

It's a curious thing about our industry: not only do we not learn from
our mistakes, we also don't learn from our successes.
-- Keith Braithwaite

[Rodrigo Kumpera]

2009/7/4 Thiago Silva <tsilva.br@gmail.com>

que legal ver o kumpera aqui :)

2009/7/3 Rodrigo Kumpera <kum...@gmail.com>:

> Apesar de achar oque o pessoal do VRPI está fazendo muito
> interessante,
> eu acredito não acho que qualquer coisa de realmente revolucionário
> irá sair
> de lá. Meus ovos estão na cesta do Simon Peyton-Jones e seus
> comparsas.

Por que seus ovos estão (estariam) nesta turma?

Porque não acho que OO ou linguagens com tipagem latente tenham futuro.
Haskell com um sistema de tipos baseados em teoria de categorias me parece
muito mais concreto e promissor.

Subtipagem e polimorfismo são coisas muito diferentes para serem misturados
da forma como são nas maioria das linguagens OO.
 
Além disso, tipagem latente é uma desastre quando falamos de qualquer forma
de análise do sistema. Todos sistemas até hoje construídos são baseados em
algorítmos otimistas, oque sempre gera resultados probabilísticos.

Eu acredito em verificação formal e programação declarativa que em OO
e escrever código imperativo.

> Dito isso, eu vejo que o maior problema hoje não está nas linguagens
> de programação em si, mas no ambiente no qual
> elas executam. São frágeis, simplórios e desprovido de qualquer forma
> de inovação. Basta ver que em 20 anos se produziu
> somente uma VM não convencional, a do Erlang, o resto todo é sempre
> uma variação sobre o mesmo tema.
>
> Porém como podemos esperar que alguém inove no universo dos ambientes
> de execução quando custa muitos anos homem
> para se produzir um sofisticado o suficiente para uso em produção.
> Ninguém ainda conseguiu produzir, do zero, uma VM inteira
> com escala industrial com menos de 100 anos/homem.
>

Me pergunto qual o papel, neste custo, do "ambiente frágil" subjacente
utilizado no desenvolvimento das VMs....

Provavelmente enorme. O ferramental vai de ruim a patético (iPhone), o SO é hostil
e a linguagens disponíveis são um desastre.

Não existe pesquisa aplicada p/ se avançar nesse problema e a principais iniciativas
infelizmente girando em torno de sistemas meta-circulares, que ficam lindos em papers
mas são uma enorme piada no mundo real.

> Ou seja, enquanto produtizar o trabalho de um doutorado nessa área
> continuar custando coisa de 10milhões de dólares e vários
> anos, nada vai mudar.
>
> Essa é minha opinião, em vez de criarem mil LISPs e 500 smalltalks,
> matem somente um C que o resto vem sozinho.
>

E como ocupar o espaço de C? BitC [1] ? COLA [2]?

A propósito, acho que é a terceira vez que vejo vc levantar estes
pontos....o que falta para vc cansar e procurar matar o C com as
próprias mãos? ;)

COLA é de alto nível, memória vai continuar precisando ser gerenciada manualmente [1]
e ainda continua sendo necessário ter uma relação muito clara de código fonte e de máquina [2].

BitC tinha tudo para ser uma boa tentativa, porém o Shapiro ficou de saco cheio da academia e foi p/ MS,
logo o projeto perdeu seu mentor.

Quanto a gastar tempo com isso, eu adoraria, porém não tenho hoje o luxo de trabalhar p/ uma empresa
brasileira e ficar aquém á crise. Quem sabe em 2010.


[1] Nem que seja usando algo como regions do cyclone.
[2] Não tanto como no C, mas todas operações contra a memória de um treco de código tem que ser visíveis ao programador.

[Thiago Silva]

2009/7/4 Rodrigo Kumpera <kum...@gmail.com>:

> Porque não acho que OO ou linguagens com tipagem latente tenham futuro.
> Haskell com um sistema de tipos baseados em teoria de categorias me parece
> muito mais concreto e promissor.
>
> Subtipagem e polimorfismo são coisas muito diferentes para serem misturados
> da forma como são nas maioria das linguagens OO.
>
> Além disso, tipagem latente é uma desastre quando falamos de qualquer forma
> de análise do sistema. Todos sistemas até hoje construídos são baseados em
> algorítmos otimistas, oque sempre gera resultados probabilísticos.
>

Eu ainda não tive a oportunidade de conhecer sistemas de tipos mais
sofisticados. Reconheço os benefícios de inferêcia de tipos, mas sem
experiência, eu não saberia dizer como tudo isso se conjuga durante a
evolução de um sistema - ou seja, se a minha habilidade de
experimentar interações não previstas acaba sendo minada, de alguma
forma, pelos tipos definidos, e como isso se dá.

>> Me pergunto qual o papel, neste custo, do "ambiente frágil" subjacente
>> utilizado no desenvolvimento das VMs....
>
> Provavelmente enorme. O ferramental vai de ruim a patético (iPhone), o SO é
> hostil
> e a linguagens disponíveis são um desastre.
>
> Não existe pesquisa aplicada p/ se avançar nesse problema e a principais
> iniciativas
> infelizmente girando em torno de sistemas meta-circulares, que ficam lindos
> em papers
> mas são uma enorme piada no mundo real.
>
>

O "infelizmente" é porque são uma piada no mundo real? Ou porque vc
não atribui mérito a meta-circularidade?

[]'s

[Rodrigo Kumpera]

2009/7/4 Thiago Silva <tsilva.br@gmail.com>

2009/7/4 Rodrigo Kumpera <kum...@gmail.com>:

> Porque não acho que OO ou linguagens com tipagem latente tenham futuro.
> Haskell com um sistema de tipos baseados em teoria de categorias me parece
> muito mais concreto e promissor.
>
> Subtipagem e polimorfismo são coisas muito diferentes para serem misturados
> da forma como são nas maioria das linguagens OO.
>
> Além disso, tipagem latente é uma desastre quando falamos de qualquer forma
> de análise do sistema. Todos sistemas até hoje construídos são baseados em
> algorítmos otimistas, oque sempre gera resultados probabilísticos.
>

Eu ainda não tive a oportunidade de conhecer sistemas de tipos mais
sofisticados. Reconheço os benefícios de inferêcia de tipos, mas sem
experiência, eu não saberia dizer como tudo isso se conjuga durante a
evolução de um sistema - ou seja, se a minha habilidade de
experimentar interações não previstas acaba sendo minada, de alguma
forma, pelos tipos definidos, e como isso se dá.

Polimorfismo paramétrico e type classes já te leva muito longe.
 

>> Me pergunto qual o papel, neste custo, do "ambiente frágil" subjacente
>> utilizado no desenvolvimento das VMs....
>
> Provavelmente enorme. O ferramental vai de ruim a patético (iPhone), o SO é
> hostil
> e a linguagens disponíveis são um desastre.
>
> Não existe pesquisa aplicada p/ se avançar nesse problema e a principais
> iniciativas
> infelizmente girando em torno de sistemas meta-circulares, que ficam lindos
> em papers
> mas são uma enorme piada no mundo real.
>
>

O "infelizmente" é porque são uma piada no mundo real? Ou porque vc
não atribui mérito a meta-circularidade?

Infelizmente por perderem tempo com isso. Sistemas meta-circulares são
muito ruins de se trabalhar com. Eles são um desastre de engenharia.


 

[Guaracy Monteiro]

Ronaldo Ferraz <ronald...@gmail.com> writes:

> Ah, com certeza. Para mim, o legal nessa discussão é especular
> justamente sobre as variações--ver os pontos de vistas individuais,
> modos como cada um programa, e ver o que pode sair. Pelo que vejo, de
> todos nós, o único fazendo algo realmente fora da curva usual de
> desenvolvimento é o Thiago.
>
> Eu tenho que confessar que essa discussão é um bálsamo off-work para
> mim. Ultimamente meu mundo tem consistindo mais em liderar três
> gerências distintas de arquitetura, engenharia e pesquisa de software
> deixando--infelizmente--muito pouco tempo para código. :(

Agora pensei na tua atividade atual como um programador do
futuro. Especifica o que deseja e o programa inteligente faz o serviço
para ti. A diferença é que ainda necessitas de pessoas para a
programação. Em um futuro distante, poderias colocar um capacete e uma
máquina faria todo o serviço.

Eu tenho minhas recaídas futuro <-> passado. Hoje configurei o gnus
para conversar com o gmail e vou acompanhar a lista por ele. Ainda tem
alguns ajustes para fazer, mas espero que o meu próximo C-c C-c :-)

--
Guaracy Monteiro

- O -

A photograph is memory in the raw. ~Carrie Latet

[Thiago Silva]

2009/7/6 Guaracy Monteiro <guara...@gmail.com>:

> Agora pensei na tua atividade atual como um programador do
> futuro. Especifica o que deseja e o programa inteligente faz o serviço
> para ti. A diferença é que ainda necessitas de pessoas para a
> programação. Em um futuro distante, poderias colocar um capacete e uma
> máquina faria todo o serviço.
>

Talvez num futuro não tão distante. Já existe uma área chamada
brain-computer interface:

http://en.wikipedia.org/wiki/Brain-computer_interface

Eis uma noticia recente:

http://www.readwriteweb.com/archives/twitter_thoughts.php

[Philipe Farias]

Chegando com alguns dias de atraso na discussão numa tentativa de
prolonga-la ainda mais (muitas idéias e referências interessantes!)
farei algumas perguntas (para as quais não possuo as respostas).

C é encarada como uma linguagem antiga e ultrapassada que serve como
base para boa parte das linguagens ditas atuais e modernas, sendo essa
uma grande falha ou desvantagem para o avanço computacional (o
verdadeiro bug do milênio? hehe). Mas como saber que uma linguagem é
antiga, o quê a torna antiga e ultrapassada? Quais são os problemas
que C e seus descendentes não estão conseguindo resolver? Ou não
conseguirão resolver? Caso resolver problemas seja a questão.

Olhando para a história do desenvolvimento tecnológico (desde a pedra
lascada, longe assim ;)) e abstraindo um monte de coisa alguém pode
inferir que não há tanto atraso quanto reclamam. E que talvez o tempo
de 100 anos/homem para produzir a primeira VM inteira em escala
industrial seja um processo normal e, quem sabe, até acelerado. Quem
sabe...me parece muito tempo também.

Quanto a grande influência das ferrementas, acredito que escrever, ou
anotar, as idéias e compartilha-las, é mais importante do que procurar
qual o melhor papel e a melhor caneta. Não retirando a importância e
capacidade de influência da segunda parte.

Também acho que a forma atual da Academia sofre sérios problemas (como
foi citado o alto custo financeiro e demora em um doutorado) mas
deduzo disso que a morte de C (por uma bala de prata, talvez?) não
seja a tal solução ideal. E será que títulos e pesquisas acadêmicas
mais ágeis bastem para "todos" largarem o C?

[Guaracy Monteiro]

Philipe Farias escreveu:

> C é encarada como uma linguagem antiga e ultrapassada que serve como
> base para boa parte das linguagens ditas atuais e modernas, sendo essa
> uma grande falha ou desvantagem para o avanço computacional (o
> verdadeiro bug do milênio? hehe). Mas como saber que uma linguagem é
> antiga, o quê a torna antiga e ultrapassada? Quais são os problemas
> que C e seus descendentes não estão conseguindo resolver? Ou não
> conseguirão resolver? Caso resolver problemas seja a questão.
>

Para mim, antigo não significa, necessariamente, ultrapassado. Para muitos,
se a cor da moda é verde, tudo que foi feito em vermelho não presta mais
e deve
ser trocado. Acho que a base de tudo é o processador e seu set de
instruções. C
até pode ser a base de muitas coisas, mas só continua se quiserem. O
FreePascal
é feito em Pascal. Se alguém baixar os fontes do GHC, vai precisar de um GHC
para compilar. Eles até podem ter começado com C, mas não são mais. Quem
resolve alguma coisa é o processador e seus companheiros. Se C não premite
resolver alguma coisa, usa-se algo que resolva.

> Olhando para a história do desenvolvimento tecnológico (desde a pedra
> lascada, longe assim ;)) e abstraindo um monte de coisa alguém pode
> inferir que não há tanto atraso quanto reclamam. E que talvez o tempo
> de 100 anos/homem para produzir a primeira VM inteira em escala
> industrial seja um processo normal e, quem sabe, até acelerado. Quem
> sabe...me parece muito tempo também.
>

Aí eu pergunto como seria essa VM? Quais os benefícios? Seria interessante
para todos ou apenas uma parcela que necessita de recursos específicos?

> Quanto a grande influência das ferrementas, acredito que escrever, ou
> anotar, as idéias e compartilha-las, é mais importante do que procurar
> qual o melhor papel e a melhor caneta. Não retirando a importância e
> capacidade de influência da segunda parte.
>

Até porque ninguém escolhe o melhor. Seja por preço, por conhecimento ou
talvez, porque simplesmente não existe o melhor. Talvez exista o melhor
para determinada pessoa ou determinada tarefa. Qual o melhor SGBD? Editor
de textos? Sistema operacional? Linguagem de programação? Paradigma?

> Também acho que a forma atual da Academia sofre sérios problemas (como
> foi citado o alto custo financeiro e demora em um doutorado) mas
> deduzo disso que a morte de C (por uma bala de prata, talvez?) não
> seja a tal solução ideal. E será que títulos e pesquisas acadêmicas
> mais ágeis bastem para "todos" largarem o C?
>

Acredito que apenas pesquisas não sejam suficientes. É necessário que
toda a estrutura existente seja mudada e deve ser feito de forma gradual.
Se quando acordastes pela manhã tivesse uma manchete: "De hoje em
diante, todos os computadores usarão apenas DisritimixOS, que já vem
com o SGBD BananANSI e a linguagem HypeBasicTalk".

--
Guaracy Monteiro
http://fotomix.wordpress.com/

[Rodrigo Kumpera]

2009/7/16 Guaracy Monteiro <guaracy.bm@gmail.com>

Philipe Farias escreveu:

> C é encarada como uma linguagem antiga e ultrapassada que serve como
> base para boa parte das linguagens ditas atuais e modernas, sendo essa
> uma grande falha ou desvantagem para o avanço computacional (o
> verdadeiro bug do milênio? hehe). Mas como saber que uma linguagem é
> antiga, o quê a torna antiga e ultrapassada? Quais são os problemas
> que C e seus descendentes não estão conseguindo resolver? Ou não
> conseguirão resolver? Caso resolver problemas seja a questão.
>

Para mim, antigo não significa, necessariamente, ultrapassado. Para muitos,
se a cor da moda é verde, tudo que foi feito em vermelho não presta mais
e deve
ser trocado. Acho que a base de tudo é o processador e seu set de
instruções. C
até pode ser a base de muitas coisas, mas só continua se quiserem. O
FreePascal
é feito em Pascal. Se alguém baixar os fontes do GHC, vai precisar de um GHC
para compilar. Eles até podem ter começado com C, mas não são mais. Quem
resolve alguma coisa é o processador e seus companheiros. Se C não premite
resolver alguma coisa, usa-se algo que resolva.

 
O GHC só precisa de um compilador de Haskell p/ compilar as bibliotecas dele,
a VM ainda é escrita em C/C++.

[Rodrigo Kumpera]

2009/7/16 Philipe Farias <philip...@gmail.com>

Chegando com alguns dias de atraso na discussão numa tentativa de
prolonga-la ainda mais (muitas idéias e referências interessantes!)
farei algumas perguntas (para as quais não possuo as respostas).

C é encarada como uma linguagem antiga e ultrapassada que serve como
base para boa parte das linguagens ditas atuais e modernas, sendo essa
uma grande falha ou desvantagem para o avanço computacional (o
verdadeiro bug do milênio? hehe). Mas como saber que uma linguagem é
antiga, o quê a torna antiga e ultrapassada? Quais são os problemas
que C e seus descendentes não estão conseguindo resolver? Ou não
conseguirão resolver? Caso resolver problemas seja a questão.

Olhando para a história do desenvolvimento tecnológico (desde a pedra
lascada, longe assim ;)) e abstraindo um monte de coisa alguém pode
inferir que não há tanto atraso quanto reclamam. E que talvez o tempo
de 100 anos/homem para produzir a primeira VM inteira em escala
industrial seja um processo normal e, quem sabe, até acelerado. Quem
sabe...me parece muito tempo também.

Pelo contrário, basta analisar dois casos recentes para se ter uma idéia
de que esse número é facilmente pequeno. Sun com JVM e Microsoft com .NET.

O Java começou como um projeto de pesquisa em 91 e o time teve em média
7 pessoas até 95. Porém a JVM continuou uma porcaria até o lançamento da versão
1.4 em 2002, ou seja, levaram 7 anos com produtização e hardening. A JavaSoft no auge
da bolha tinha coisa de 100 engenheiros trabalhando com JSE.

O .NET tem uma história parecida, o primeiro release foi em 2001 porém as implementações
da CLR anteriores a versão 2.0 são uma droga, esta foi lançada no começo de 2006. Porém sua
existencia como projeto de pesquisa na MS remete a meandros de 1995/96. Quanto tempo foi
gasto? Tranquilamente na ordem de uma ou duas centenas de anos homem, pois o time da CLR
sempre foi gigantesco (que eu saiba eles eram em quase 300 em 2007).

O mesmo pode ser observado com outras linguagens. C++ por exemplo, o GCC levou 13 anos para
ter um compilador razoavel da linguagem - primeiro g++ em 1990 e primeiro usavel foi o  3.3 em 2003.
Para C, foram só 14 anos com o lançamento do 3.0 depois de todo o trama do EGCS.

E o GHC? Bom, o projeto é bem antigo também, data do começo da década passada e até alguém
anos ninguém respeitava ele para funcionar no mundo real, ou seja, uma década de trabalho, no mínimo.

[Thiago Silva]

2009/7/16 Philipe Farias <philip...@gmail.com>:

>
> Chegando com alguns dias de atraso na discussão numa tentativa de
> prolonga-la ainda mais (muitas idéias e referências interessantes!)
> farei algumas perguntas (para as quais não possuo as respostas).
>

Oi Philipe! jóia! Vamos buscar respostas :)

> C é encarada como uma linguagem antiga e ultrapassada que serve como
> base para boa parte das linguagens ditas atuais e modernas, sendo essa
> uma grande falha ou desvantagem para o avanço computacional (o
> verdadeiro bug do milênio? hehe). Mas como saber que uma linguagem é
> antiga, o quê a torna antiga e ultrapassada?
>

C pode ser até encarada como uma linguagem antiga. Mas não acho que a
idade seja relevante. Uma linguagem (e qualquer coisa, provavelmente)
se torna ultrapassada quando suas características se tornam inferiores
em relação ao que se conhece em um dado momento.

> Quais são os problemas
> que C e seus descendentes não estão conseguindo resolver? Ou não
> conseguirão resolver? Caso resolver problemas seja a questão.

Nessa thread, acho que a problemática mais discutida tem sido a
criação de softwares corretos que são enormes/complexos e escalam.

> Olhando para a história do desenvolvimento tecnológico (desde a pedra
> lascada, longe assim ;)) e abstraindo um monte de coisa alguém pode
> inferir que não há tanto atraso quanto reclamam. E que talvez o tempo
> de 100 anos/homem para produzir a primeira VM inteira em escala
> industrial seja um processo normal e, quem sabe, até acelerado. Quem
> sabe...me parece muito tempo também.

Acho que o atraso é percebido por alguns ao se observar (correta ou
incorretamente) um _gap_ entre o que se conhece em estado da arte e a
tecnologia que se tem a disposição (e no que se trabalha sobre),
considerando-se que não há razões técnicas (não há trade-off) para a
escolha de uma abordagem considerada inferior. Mas se fosse só isso,
acho que não teriamos que nos preocupar. Eventualmente, talvez, a
abordagem considerada superior se sobresairia, enterrando as
inferiores. Mas isso não parece acontecer naturalmente.

Mesmo considerando o potencial maleável do software ("soft"), ainda
assim, certas escolhas acabam por definir compromissos fortes que
podem dificultar ou restringir avanços - veja o caso do browser/HTML.
Há quem considere também a influência da tecnologia na nossa percepção
(definindo mind-sets, status-quo, ...), o que talvez torne a questão
um pouco mais delicada.

> Também acho que a forma atual da Academia sofre sérios problemas (como
> foi citado o alto custo financeiro e demora em um doutorado) mas
> deduzo disso que a morte de C (por uma bala de prata, talvez?) não
> seja a tal solução ideal. E será que títulos e pesquisas acadêmicas
> mais ágeis bastem para "todos" largarem o C?
>

Não sei se a questão é se títulos e pesquisas são "ágeis" ou não
(talvez eu não tenha compreendido o que quis dizer). Mas, tirando do
topo da cabeça sem pensar muito, podemos obsevar que o que sai da
academia não é aditivamente aplicada à indústria. Talvez isso seja um
grande problema.

[]'s

[Rodrigo Kumpera]

2009/7/17 Thiago Silva <tsilva.br@gmail.com>

Não sei se a questão é se títulos e pesquisas são "ágeis" ou não
(talvez eu não tenha compreendido o que quis dizer). Mas, tirando do
topo da cabeça sem pensar muito, podemos obsevar que o que sai da
academia não é aditivamente aplicada à indústria. Talvez isso seja um
grande problema.

Pesquisa aplicação em computação não acontece no Brasil, mas acontece o tempo inteiro.
Não precisa ir muito longe para ver isso acontecendo, alguns de vocês devem ler este meu
email usando o fruto direto do doutorado do Andreas Gal.

[Philipe Farias]

Thiago,

Quanto ao último parágrafo recentemente vi uma paresentação
interessante (não das mais empolgantes btw) no InfoQ por Tony Hoare
(Sir "Quicksort"). Ele fala sobre as áreas de ciência da computação e
engenharia de software. Basicamente descreve o escopo e propósitos de
ambas e como se relacionam (ou deveriam se relacionar).
Pelo que entendi (ou lembro) a engenharia de software deve focar na
aplicação prática/indústria/mercado e possui uma visão a curto prazo
(os problemas de hoje). Enquanto a ciência da computação deve ter como
foco a pesquisa científica e possui uma visão a longo prazo (vários
anos, décadas talvez).
Há mais ponderações e argumentos na palestra dele que minha ultra
simplificação não faz jus...

Hoje, após concluir CC, percebo que pesquisa científica apesar de
muito interessante não é o que pretendo fazer...

[Adorilson Bezerra de Araujo]

2009/7/17 Philipe Farias <philip...@gmail.com>

Thiago,

Quanto ao último parágrafo recentemente vi uma paresentação
interessante (não das mais empolgantes btw) no InfoQ por Tony Hoare
(Sir "Quicksort"). Ele fala sobre as áreas de ciência da computação e
engenharia de software. Basicamente descreve o escopo e propósitos de
ambas e como se relacionam (ou deveriam se relacionar).
Pelo que entendi (ou lembro) a engenharia de software deve focar na
aplicação prática/indústria/mercado e possui uma visão a curto prazo
(os problemas de hoje). Enquanto a ciência da computação deve ter como
foco a pesquisa científica e possui uma visão a longo prazo (vários
anos, décadas talvez).

Seria algo parecido com isso:

http://www.ddj.com/architect/217701907

--
Adorilson Bezerra

[CMilfont]

"Porém a JVM continuou uma porcaria até o lançamento da versão 1.4 em 2002"

Louds, o Hotspot teve um impacto profundo na VM, lembro que o 1.2 era horrivel mas o 1.3 já deu uma avançada boa. [que acho que foi com o Hotspot ou deve ter sido no 1.4 mesmo estou com preguiça de pesquisar].

2009/7/17 Rodrigo Kumpera <kum...@gmail.com>

--
http://www.milfont.org

[Philipe Farias]

Adorilson,

Tipo esse artigo.

Aqui o link da apresentação: http://www.infoq.com/presentations/tony-hoare-computing-engineering
Havia esquecido.

[Rodrigo Kumpera]

Sim, a primeira versão usando a HotSpot foi a 1.3, mas você tentou usar ela em produção?
Não era nada difícil crashar ela.

2009/7/18 CMilfont <cmil...@gmail.com>