Histórico - a crise do software e a origem da linguagem Java

1. O início da computação: a crise do software

O início da computação: a crise do software

1. O objetivo desta seção é apresentar uma breve visão de como as coisas eram, lá no princípio da
computação. Vamos ver (muito rapidamente) o que funcionava, o que não funcionava, os problemas da
época e quais necessidades havia, para compreender como as coisas evoluíram.

2. No início da computação, criar um programa era complicado e difícil. Programar era considerado muito
mais uma arte do que uma técnica ou ciência. Apesar de toda a tecnologia envolvida (embora primitiva),
dificilmente os projetos chegavam ao fim, como esperado. Além disso, os projetos que finalizavam
muitas vezes estavam bem distantes de serem considerados “um sucesso”.

3. Porque isso ocorria? Por diversos motivos.

4. 1) Computadores, compiladores e ferramentas de desenvolvimento ainda estavam no início.

5. 2) As técnicas de programação, depuração e desenvolvimento ainda estavam começando.

6. 3) Programar é uma atividade complexa, que exige inumeras habilidades.

7. 4) Executar um projeto também é uma ação complicada

8. 5) Fatores humanos, falta de experiência e diversos outros motivos afetavam os projetos.

9. Dessa forma, inúmeros projetos falharam. Havia a necessidade de ferramentas melhores. Nesta época,
os equipamentos custavam muito. A memória (disco e RAM) eras muito caras e pequenas. Havia a
necessidade de usar até o último byte disponível. Ademais, era comum computadores serem operados
por técnicos altamente especializados, que conheciam profundamente os detalhes específicos de cada
máquina. Portanto, eram capazes de explorar cuidadosamente os detalhes da arquitetura, na busca
incessante pelo desempenho e espaço.

10. Linguagens como Pascal, C/C++ e Basic eram extremamente populares. Eram feitas com o objetivo de
atender a estas necessidades: desempenho e uso criterioso de memória. Algumas vezes, as
ferramentas eram criadas ou modificadas pelas mesmas pessoas que operavam (ou projetavam) as
máquinas, nas quais as ferramentas rodavam. Não era um cenário fácil.

11. Neste contexto, muitos projetos de desenvolvimento falhavam. Um grande volume de projetos com
orçamento estourado, prazos exageradamente dilatados e resultados insatisfatórios gerou uma grande
desconfiança na indústria e no mercado. Ficava cada vez mais evidente a necessidade de ferramentas
melhores e de técnicas melhores para produção de software.

12. Um outro problema muito comum que acontecia era a falta de padronização entre produtos. ou seja era
muito comum um dispositivo ou equipamento funcionar apenas em um certo computador e não funcionar
em outro. No princípio o problema era tão grave que muitas vezes um dispositivo não funcionava nem
mesmo na versão mais nova de um computador do mesmo fabricante. O mesmo problema de falta de
compatibilidade ocorria com programas. Ademais, este problema também afetava as linguagens de
programação e seus compiladores. Ou seja às vezes um programa gerado por um certo compilador X
funcionava, mas quando era compilado por outra versão ou outro compilador, disponível para a mesma
 linguagem, o programa deixava de funcionar. Fatores como atualização do sistema operacional,
atualização do equipamento, atualização do compilador outras mudanças poderiam facilmente
atrapalhar ou impedir a execução de um programa.

13. A visão original que você tinha do programador é um especialista que conhecia todos os detalhes da
máquina e sabem explorar cada particularidade do sistema. Com o tempo esta visão foi modificada.
Conforme as técnicas de programação eram desenvolvidas, ficava cada vez mais claro necessidade e
melhorias nas linguagens e a necessidade de padronização.

14. Uma das principais dificuldades na criação de programas é que o processo de desenvolvimento é
complexo por vários motivos. O tipo de linguagem que é falado e escrito por seres humanos não
funcionava para escrever programas de computador. O volume de detalhes necessários para montar um
sistema computacional crescia rapidamente com os anos, tornando o processo de desenvolvimento
cada vez mais complexo. Ou seja, em geral, o volume de funcionalidades e de código útil que era
possível adicionar nos sistemas começava a diminuir drasticamente, conforme o sistema ia aumentando.
Apareceu então necessidade de padronização de modo que o esforço e descrever sistemas
computacionais pudesse ser reduzido e a sua manutenção pudesse ser simplificada.

15. Havia diversos pontos nas linguagens de programação convencionais que tornavam o desenvolvimento
difícil. por exemplo, em relação à questão da gerência de memória, era necessário que os
programadores possuíssem uma compreensão muito profunda de como o programa pedia, usava e
liberava blocos de memória. a manipulação explícita da gerência de memória pelos programadores
através de funções como "malloc" e "free()" era uma das principais causas de problemas, retrabalho,
atrasos e perda de dinheiro nos projetos. isso não quer dizer que é possível desenvolver bons
programas manipulando explicitamente a memória. Mas quer dizer sim que é bem difícil fazer isso
corretamente, e é extremamente comum haver problemas na gerência explícita de memória, mesmo
com programadores muito experientes.

16. Pois bem, os detalhes ligados às técnicas de desenvolvimento de projetos serão abordados em outras
disciplinas, como engenharia de software. Eu gostaria de chamar a atenção para as características das
linguagens anteriores e começar a discutir como essas características foram importantes. Elas foram
usadas para definição dos principais requisitos que levaram à criação da linguagem Java e também do
paradigma de programação orientada a objetos.

17. Na programação procedural, o foco principal do sistema era a criação de um modelo baseado em uma
grande coleção de funções, ou procedimentos. tudo em um programa era modelado como uma coleção
de funções que realizava as operações do sistema. Esse foco em funções funcionava bem para
sistemas pequenos, mas falhavam conforme os sistemas começaram a aumentar. Quanto maiores os
sistemas, mais difícil era compreender e fazer manutenção. Ou seja, era muito trabalhoso fazer
correções e adicionar melhorias, em grande parte porque esse tipo de atividade exige que o
programador possua um modelo mental muito preciso de como o sistema foi pensado e como ele
funciona por dentro. Em outras palavras, a complexidade era grande demais e muitas vezes resultava
em um enorme volume de retrabalho. era bastante comum acontecer do cliente fazer um pedido de
melhoria e este pedido não poder ser aceito, sob pena de afetar uma parte grande demais do sistema.

18. As necessidades então poderiam ser listadas da seguinte forma. Era necessário padronizar as coisas
para facilitar a interoperabilidade. Padronizar características da linguagem de programação e do
compilador. Era necessário ter técnicas para lidar com a crescente complexidade dos sistemas a serem
desenvolvidos. era preciso uma maneira mais simples de manipular a memória e gerenciá-la sem
precisar fazer isso explicitamente. uso de memória dinâmica em geral exige usar alguma forma de
ponteiros. Mas trabalhar com ponteiros não é simples é uma das fontes mais comuns de erro em
programação na linguagem C. Operações envolvendo aritmética de ponteiros também estavam longe de
serem suaves: muitas vezes eram traumáticas, tanto para o programador como para o sistema.

19. Uma das primeiras abordagens para reduzir o volume de trabalho necessário à programação foi a
criação de bibliotecas. Desde que o computador foi criado existem bibliotecas de componentes que
permitem facilitar e reduzir o trabalho de desenvolvimento. No caso de linguagens como C, as
bibliotecas funcionavam muito bem, mas apenas nas situações onde todos os seus componentes eram
 completamente adequados a realização da tarefa e não exigiam modificações ou customização.
Entretanto, conforme sistemas evoluíram a necessidade de modificações das bibliotecas crescia a cada
vez mais. abordagem cognitiva para adaptação de bibliotecas consistia em obter o código-fonte, estudá-
lo e depois realizar modificações em seus componentes. Esse processo era demorado, trabalhoso,
altamente suscetível a problemas e exigia o reteste de todos os componentes afetados. Na prática, esta
operação em geral era inviável. Simplesmente não valia a pena. muitas vezes era mais simples
reescrever do zero que eu modificar o código de outras pessoas. Portanto, havia a necessidade de criar
código que fosse mais fácil de se adaptar e que funcionasse em mais situações: ou seja, código que
fosse mais flexível e mais geral, respectivamente.

20. Da mesma forma, no paradigma procedural era extremamente comum a necessidade de adaptações
que se revelavam difíceis, quando um sistema precisava executar em um contexto diferente. Outro
contexto era por exemplo rodar em uma nova máquina, ou em uma rede com um padrão de
comunicação diferente, ou usando um banco de dados distinto.

21. Havia portanto uma forte necessidade de padronização, tanto da linguagem, quanto das bibliotecas,
quanto das ferramentas de desenvolvimento. No princípio muitas empresas não viam valor nenhum na
padronização, pois cada uma queria expandir o seu produto ou o seu software conforme a sua própria
necessidade. a grande vantagem de realizar um desenvolvimento que não respeita nenhum padrão é
que você possui liberdade total de fazer o que quiser. Entretanto, quando você tem uma solução
proprietária que não adere a padrão nenhum, normalmente você está isolado do resto no mercado. Em
outras palavras, a adoção de padrões permite interoperabilidade. Pense por exemplo em um teclado
USB. O que permite que um teclado USB funcione em qualquer computador (que entenda o mesmo
padrão) é exatamente a definição rígida de regras sobre como o padrão deverá funcionar. Quando
existem padrões que são amplamente aceitos e bem feitos, há a tendência de que todos na mesma
indústria se beneficiem.

22. O mesmo raciocínio ocorre com o software e o seu desenvolvimento. Quando há uma padronização no
ambiente de desenvolvimento, na linguagem ou no local onde o software rodará, é muito mais fácil
garantir suas propriedades e garantir que ele vai funcionar conforme previsto. Da mesma forma, existem
outras características que são relevantes para o software, como por exemplo segurança. Há uma frase
clássica no mundo da segurança que diz assim: "segurança, desempenho e custo: escolha duas". Isto
significa que em geral se você tiver muito desempenho e muita segurança, precisará pagar um alto
custo. O mesmo raciocínio se aplica para as outras combinações possíveis.

23. Em particular, é muito difícil garantir a segurança quando você trabalha com uma linguagem como C,
que permite uma imensa liberdade na manipulação de memória e no uso de ponteiros.

24. Todas estas necessidades em conjunto, e as grandes dificuldades no desenvolvimento de software

empregando linguagens procedurais inspiraram a criação da linguagem Java. O paradigma de
orientação a objetos já existia e foi adotado como filosofia principal na estruturação da linguagem Java.