Responsabilidade pelo tiro no pé dos outros

Programação Arquitetura
#1

De tempos em tempos eu fico imaginando como seria arquitetar uma nova linguagem de programação, o que eu gostaria de colocar nela, o que gostaria que ela não tivesse, etc.

Sempre chego num ponto: sobre a liberdade do programador em fazer o que quiser.

O meu primeiro contato com uma linguagem de programação de verdade foi com Pascal, e fiquei com um pouco de raiva dela por ser tão estrita, tão amarrada, tão chata de programar (e sim, eu reconheço e aprovo os motivos por ela ser assim).

O segunda linguagem foi C. Adorei por ser o oposto de todos os motivos acima. “O pé é meu e eu atiro nele se quiser”. E, é claro, que de lá pra cá já perdi vários, incontáveis pares de pés por causa disso.

Isso foi há vários anos, em tempos de faculdade, sem muito compromisso.

Hoje já vejo outras facetas do problema/desafio de se trabalhar com uma linguagem de programação, em criar e principalmente manutenir um código que milhares de pessoas dependem dele. Tanta liberdade pode se tornar um problema nas mãos erradas.

Erradas digo não daqueles que transformam liberdade em libertinagem, claro, eles também, mas erradas como nas mãos de inexperientes, daqueles que podem fazer besteira, ou mesmo tomar decisões não-ótimas.

Você se sentiria responsável pelas besteiras que os programadores podem fazer com a sua linguagem? Você tentaria proteger as crianças de características feitas para os adultos? Essa proteção faz parte da estratégia de público alvo?

Pelo que ouvi dizer, o Gosling falou que se pudesse voltar no tempo, ele tiraria o suporte de herança do Java, já que com composição dá pra ter o mesmo com menos riscos.

#2

Se é o caso de ir tirando as coisas da linguagem para evitar problemas, a próxima coisa que tem de ser tirada do Java é o suporte a threads dele; deveríamos ter apenas actors ou, no máximo, executors.

#3

[quote=Bruno Laturner]Você se sentiria responsável pelas besteiras que os programadores podem fazer com a sua linguagem? Você tentaria proteger as crianças de características feitas para os adultos? Essa proteção faz parte da estratégia de público alvo?
[/quote]

R: Não, Não e não sei.

Eu gostaria de ver uma envidencia disso…a questão é a formulação dos conceitos (acho que é assim que se fala rsrsrs) do que venha a ser uma linguagem orientada a objetos, Todos que constroem uma linguagem que intenciona a ser orientada a objetos tenta ao máximo contemplar o que está formulado acho que é por isso que cheguei a ler coisas do tipo “é uma linguagem fortemente orientada a objetos” etc… Já li coisas dizendo que Ruby é mais orientada a objetos que java por exemplo, se uma formulação for o parametro para determinar o quanto uma linguagem é orientada a objetos e o Mr. James Gosling é um PhD acho um pouco difícil de ele dizer isso.
Sendo um PhD o que faria mais sentido seria ele questionar a formulação assim como aconteceu no mundo da Física. Lembram do Einsein e Newton?

flws

#4

[quote=thingol]Se é o caso de ir tirando as coisas da linguagem para evitar problemas, a próxima coisa que tem de ser tirada do Java é o suporte a threads dele; deveríamos ter apenas actors ou, no máximo, executors.
[/quote]

Aí que está o problema, não tem volta. Ainda mais se tentássemos manter a compatibilidade retroativa, ou você quebra tudo ou começa uma linguagem nova. Pra todo o resto do mundo que adotou a tua tecnologia você diz bye, e eles te respondem com um “fuck you”. Pelo menos é melhor que ser juiz de futebol ou presidente do Brasil.

Quem faz os frameworks pelo menos pode lançar a versão major-version-number-plus-one e depreciar a antiga conforme os anos passarem.

Bem, a discussão não é tirar coisas depois de prontas, mas deixar ou não que elas entrem na linguagem durante a sua fase de concepção. A questão é, você não colocaria algo muito útil porém muito perigoso? Ponteiros, por exemplo?

Você não colocaria uma classe do teu framework pela possibilidade que as pessoas a usassem do jeito errado?

Retiraria a liberdade em favor de um maior controle? Qual pesa mais?

Parece até uma questão política :lol:

#5

Acho que nesse caso, onde escrever software não põe em risco a vida de ninguém (ta, existem casos onde pode colocar, mas em geral não) o máximo que podemos fazer enquanto escritores de API, Frameworks, etc é educar o usuário a não fazer bobagem.

Hoje, pegar um erro, compilar projetos e testar é muito barato. Há anos atrás, na época que tecnologia começou a aparecer, isso seria válido, pois uma bobagem na utilização de alguma tecnologia custava milhares de dólares. Hoje isso não é mais verdade.

Portanto, conscientizar é mais importante do que proibir. Estou estudando Ruby e tem uma convenção que achei muito interessante que é o uso de ! (exclamação) na nomenclatura de métodos que devem ser usados com cuidado. Se tivessemos isso em Java ou .NET pra sinalizar coisas perigosas acho que seria um grande avanço.

#6

[quote=TucaZ]
Portanto, conscientizar é mais importante do que proibir. Estou estudando Ruby e tem uma convenção que achei muito interessante que é o uso de ! (exclamação) na nomenclatura de métodos que devem ser usados com cuidado. Se tivessemos isso em Java ou .NET pra sinalizar coisas perigosas acho que seria um grande avanço.[/quote]

Mas vc tem: crie uma anotação @Dangerous ou um tag do java doc



/**
* @Dangerous use this method with caution. 
*/
@Dangerous
public void doSomethingTrullyDangerous(){

}

As linguagens não podem ter sintaxe para tudo o que venha a ser nessário no futuro.
Elas devem ter uma sintaxe limpa e clara e construtos que possam aumentar as capacidades da linguagem como API e não como
coisas internas da linguagem.

#7

Não acho que faça sentido isso, pois quase todas as coisas que existem no mundo podem ser usadas se forma boa ou ruim.

Ex: Uma faca bem amolada é ótima para o açougueiro cortar a carne que te serve, mas ao mesmo tempo o risco dele cortar um de seus dedos aumenta consideravelmente. O mesmo serve para as linguagens de programação. Algumas características ajudam de uma forma, mas podem ser usadas de uma forma que causem problemas.

#8

isto não tem sentido… quem não sabe usar não mete a mão quem meteu a mão sem saber usar foi por risco e responsabilidade do proprio… retirar coisas para não deixar os que não sabem façam merda e limitar os uem sabem é um extremo absurdo… se não sabe não usa ate saber de verdade… muito simples… as vezes é necessario dar muitos tiros no pe para aprender a atirar… acho que deveriam expandir e não limitar…

#9

Bobagem, ninguém cria mecanismos em uma linguagem com o desejo explícito de dar “tiro no pé”. Certas coisas existem em uma determinada linguagem porque, na sua criação, não se sabia dos problemas que elas criariam.

O próprio conceito de herança é um exemplo, as pessoas só se tocaram que o uso excessivo dela é nocivo porque ela existe na linguagem Java. Aliás, herança só é nociva em linguagens que não possuem o conceito de classes abertas ou duck typing, como Java e C#. Não há problema nenhum em usar herança em Ruby, pois é possível modificar as classes facilmente em tempo de execução.

#10

Eu acho que você tem que limitar o dano que o programador pode fazer sim.

Pra ser mais correto, você tem que limitar o efeito da ação do programador. Se o efeito ficar limitado, tudo bem. Neste sentido, o Java foi um grande avanço em relação ao C/C++. Lembrem-se que o C/C++ não tinha proteção de memória, então você tinha aqueles famigerados bugs de invasão de memória, onde alguém ultrapassava a extensão de um array e escrevia sobre o dado seguinte, que podia pertencer a outro módulo completamente diferente do sistema. O erro normalmente se manifestava muito depois.

Nesse sentido, acho essas linguagens dinâmicas um ENORME passo para trás. Com o pretexto de dar mais poder ao programador, elas também aumentam o efeito que as construções da linguagem podem ter.

Acho que a linguagem de programação perfeita teria que dar poder ao desenvolvedor, mas ao mesmo tempo garantindo que o efeito de qualquer ação fosse localizado ao máximo.

Acho que o argumento que ‘o programador tem que ter o poder e é problema dele programar direito para não fazer merda’ não é válido, porque você nunca trabalha sozinho. Mesmo que todos na sua equipe cuidem de limitar o efeito que o código que escrevem pode ter, isso não é suficiente, porque você está utilizando bibliotecas, frameworks, etc, que foram escritos por outros programadores. Se a linguagem fornece efeitos globais, fica muito difícil controlar o que acontece quando várias bibliotecas são utilizadas em conjunto.

Novamente, não estou dizendo que os programas em Java não têm efeitos globais. Mas o objetivo de qualquer linguagem no futuro deveria ser limitar estes efeitos, e não aumentar.

#11

Se herança é o root of all evil, então porque ninguém se deu ao trabalho de fazer uma linguagem OO sem herança, baseada apenas em composição?

Composição só substitui herança de forma eficiente com um belo esquema de delegação, coisa que Java está longe de ter. Então antes do Gosling falar isso ele deveria ter falado algo assim:

“Bem que poderíamos pensar num method_missing para o Java hoje em dia!”

Uma linguagem pode até ser poderosa, sem entrar na frente do programador em termos de agilidade e produtividade. Um belo exemplo disso é Ruby…

Java não é poderosa, mas essa falta de poder não faz falta para a maioria dos projetos. Mas haverá sempre exceções, e para esses casos podemos usar JRuby agora…

#12

Qual o grande avanco que essa convencao proporcionaria?

Tb isso existe em varias outras linguagens, nao é especifico do Ruby. Metodos que terminam com interrogacao para predicados e metodos que terminam com exclamacao indicam metodos que alteram estado do sistema.

#13

Isso de usar caracteres especiais em nomes de métodos me lembra o Lisp - por exemplo, em Scheme, o equivalente ao Java de:

Character.isLowerCase ('σ')

é

(char-lower-case? #\σ)

(por convenção, “?” indica que o método retorna um booleano, e que é um teste).

#14

[quote=cmoscoso]
Qual o grande avanco que essa convencao proporcionaria?

Tb isso existe em varias outras linguagens, nao é especifico do Ruby. Metodos que terminam com interrogacao para predicados e metodos que terminam com exclamacao indicam metodos que alteram estado do sistema.[/quote]

Me expressei mal. Não acho que o simples fato de ter a exclamação em si seria um avanço. Mas sim a reviravolta cultural que isso traria para os desenvolvedores das linguagens que não tem.

Sou desenvolvedor Microsoft (.NET) e a comunidade de desenvolvedores MS em geral é pouco preocupada com a qualidade do código. Trabalho com Microsoft já a uns 4 anos e nunca peguei um projeto que eu não tivesse começado e que tivesse sido desenvolvido com esmero, com cuidado. A MS acostumou muito mal seus desenvolvedores a partir do momento em que disse que eles não precisavam mais se preocupar com super utilização de recursos ou em liberar memória porque o framework iria cuidar disso tudo pra você.

Acredito que o avanço estaria em admitir que mesmo em uma linguagem gerenciada e que facilita muito as coisas pra você é possível fazer grandes bobagens. Eu encaro que se tivessemos mecanismos explicitos para isso seria um dos primeiros passos pra iniciar a conscientização dos desenvolvedores (Imagina um método que dissesse explicitamente: “CUIDADO AO ME UTILIZAR!”). Mas ao mesmo tempo seria ir contra o próprio Marketing.

#15

[quote=Emerson Macedo]Não acho que faça sentido isso, pois quase todas as coisas que existem no mundo podem ser usadas se forma boa ou ruim.

Ex: Uma faca bem amolada é ótima para o açougueiro cortar a carne que te serve, mas ao mesmo tempo o risco dele cortar um de seus dedos aumenta consideravelmente. O mesmo serve para as linguagens de programação. Algumas características ajudam de uma forma, mas podem ser usadas de uma forma que causem problemas.[/quote]

A linguagem de máquina pode fazer uma máquina que auxilie o homem a fazer muitas coisas, mas também pode fazer computadores ou máquinas que lancem foguetes em outros países…

#16

A maior besteira que um programador pode cometer e nao atender aos requisitos especificados portanto a melhor ajuda que alinguagem pode oferecer é ficar fora do seu caminho. Neste sentido acho que linguagens dinamicas e funcionais sao uma vantagem; o primeiro exige menos ciclos de build e agiliza o desenvolvimento e o segundo e mais importante basicamente permite construir programas com menos codigo.

#17

Limitar TODAS as linguagens é uma coisa complicada. Nem todos os problemas se resumem ao mundinho CRUD das empresas. Nas empresas, aliás, isso já virou “mais do mesmo” há muito tempo. O mundo de hoje exige novas abordagens, novas ferramentas, novas linguagens.

Java não é mais o futuro. Java é o presente e começa a se tornar o passado! Java e .Net serão o Cobole o Clipper, o VB e o Delphi em breve.

então, porque limitar os programadores? Devemos nos preocupar com segurança, sim. É bom ter linguagens com gerenciamento aotomático de memória. Mas mesmo nesse mundo de linguagens dinâmicas e gerenciadas, ainda existe espaço para o bom e velho C e até mesmo para o Assembly…

Ao invés de taxarmos linguagens como bos e ruins, pq não pensar em cada uma delas como uma ferramenta apropriada para determinado problema?

Ponteiro é perigoso??? Tanto quando uma faca… Depende de quem usa!

#18