Confiabilidade

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Confiabilidade

myaccmail00

O fato da linguagem possuir checagem de tipos dinâmica e coletor de lixo, implica em uma diminuição de sua confiabilidade. Com coletor de lixo, o programador não tem controle sobre o que é deletado da memória, isso impossibilita a utilização dos programas em sistemas críticos, e graças a tipagem dinâmica o programador pode cometer erros simples que mais tarde serão difíceis de se identificar.


Como eu poderia exemplificar em código a falta de confiabilidade da linguagem?

--
Você recebeu essa mensagem porque está inscrito no grupo "Lua BR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para [hidden email].
Acesse esse grupo em https://groups.google.com/group/lua-br.
Para mais opções, acesse https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Confiabilidade

Denis Dos Santos Silva
o questionamento é elegante, mas, falho em todas as premissas.



Em domingo, 22 de abril de 2018 20:01:12 UTC-3, [hidden email] escreveu:

O fato da linguagem possuir checagem de tipos dinâmica e coletor de lixo, implica em uma diminuição de sua confiabilidade. Com coletor de lixo, o programador não tem controle sobre o que é deletado da memória, isso impossibilita a utilização dos programas em sistemas críticos, e graças a tipagem dinâmica o programador pode cometer erros simples que mais tarde serão difíceis de se identificar.


Como eu poderia exemplificar em código a falta de confiabilidade da linguagem?

--
Você recebeu essa mensagem porque está inscrito no grupo "Lua BR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para [hidden email].
Acesse esse grupo em https://groups.google.com/group/lua-br.
Para mais opções, acesse https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Confiabilidade

Tomás Guisasola
In reply to this post by myaccmail00
Oi!

O fato da linguagem possuir checagem de tipos dinâmica e coletor de lixo, implica em uma diminuição de sua confiabilidade. Com coletor de lixo, o programador não tem controle sobre o que é deletado da memória, isso impossibilita a utilização dos programas em sistemas críticos, e graças a tipagem dinâmica o programador pode cometer erros simples que mais tarde serão difíceis de se identificar.

Essas afirmativas são mitos.

O coletor de lixo não _impossibilita_ nada; ele só faz algumas coisas pelo programador, baseado em critérios, em geral, bem definidos.  Linguagens que não tem coletor de lixo deixam o trabalho de liberar a memória na mão do programador, o que não quer dizer que sejam mais confiáveis.

A checagem de tipos em geral não é tão forte quanto diz o nome: creio que a maioria das linguagens que checam tipos em tempo de compilação ainda assim permitem erros de execução como divisão por zero ou desalocação de ponteiros nulos e outras "barbeiragens" com ponteiros.

Cada linguagem tem suas características e, naturalmente, não há uma que seja boa para tudo.

No caso de Lua, apesar de ter coletor de lixo e checagem de tipos dinâmica, eu acho que é uma linguagem muito confiável.  Programas feitos em Lua não derrubam o SO, nem deixam memória perdida (alocada e não usada).  Podem dar erro de execução, mas são erros bem controlados do ponto de vista da linguagem.  Se o programador tiver um pouquinho de cuidado, pode tomar conta disso tudo.  Por exemplo, começando a executar com uma chamada pcall().  Assim o programa não "voa" :-)

Abraço,
Tomás

--
Você recebeu essa mensagem porque está inscrito no grupo "Lua BR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para [hidden email].
Acesse esse grupo em https://groups.google.com/group/lua-br.
Para mais opções, acesse https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Confiabilidade

Daniel Monteiro-2
Olá!
Aproveito para iniciar meu uso da lista para comentar meu caso de uso: desenvolvo jogos para computadores antigos - principalmente 486s e 386s. Tenho usado Lua no meu mais recente projeto (até por usar também no meu ambiente de trabalho, com isso, "fica tudo em casa") e tenho tido bons resultados num 486 SX33 com 8MB de RAM, sem HD para poder fazer Swap - se acabar a memória, o programa crasha.

Pontos que precisei tomar cuidado: compilei o Lua para ter Number como integer (uma vez que no meu código nativo também evito floats e uso apenas fixed point) e tenho o cuidado de sempre chamar o GC após toda interação com o state.

Em termos de impacto no desempenho, notei muito pouco em relação a quando tinha toda a lógica em C++ puro.

Um exemplo em um hardware um pouco mais poderoso (486DX50 com 20MB de RAM): https://youtu.be/Kl0nzEmZK0c

Espero ter adicionado algo para a discussão.

[]s

No dia 23 de abril de 2018 às 18:41, Tomás Guisasola <[hidden email]> escreveu:
Oi!

O fato da linguagem possuir checagem de tipos dinâmica e coletor de lixo, implica em uma diminuição de sua confiabilidade. Com coletor de lixo, o programador não tem controle sobre o que é deletado da memória, isso impossibilita a utilização dos programas em sistemas críticos, e graças a tipagem dinâmica o programador pode cometer erros simples que mais tarde serão difíceis de se identificar.

Essas afirmativas são mitos.

O coletor de lixo não _impossibilita_ nada; ele só faz algumas coisas pelo programador, baseado em critérios, em geral, bem definidos.  Linguagens que não tem coletor de lixo deixam o trabalho de liberar a memória na mão do programador, o que não quer dizer que sejam mais confiáveis.

A checagem de tipos em geral não é tão forte quanto diz o nome: creio que a maioria das linguagens que checam tipos em tempo de compilação ainda assim permitem erros de execução como divisão por zero ou desalocação de ponteiros nulos e outras "barbeiragens" com ponteiros.

Cada linguagem tem suas características e, naturalmente, não há uma que seja boa para tudo.

No caso de Lua, apesar de ter coletor de lixo e checagem de tipos dinâmica, eu acho que é uma linguagem muito confiável.  Programas feitos em Lua não derrubam o SO, nem deixam memória perdida (alocada e não usada).  Podem dar erro de execução, mas são erros bem controlados do ponto de vista da linguagem.  Se o programador tiver um pouquinho de cuidado, pode tomar conta disso tudo.  Por exemplo, começando a executar com uma chamada pcall().  Assim o programa não "voa" :-)

Abraço,
Tomás

--
Você recebeu essa mensagem porque está inscrito no grupo "Lua BR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para [hidden email].
Acesse esse grupo em https://groups.google.com/group/lua-br.
Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "Lua BR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para [hidden email].
Acesse esse grupo em https://groups.google.com/group/lua-br.
Para mais opções, acesse https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Confiabilidade

Stephen Eilert
In reply to this post by myaccmail00

O fato da linguagem possuir checagem de tipos dinâmica e coletor de lixo, implica em uma diminuição de sua confiabilidade. Com coletor de lixo, o programador não tem controle sobre o que é deletado da memória, isso impossibilita a utilização dos programas em sistemas críticos, e graças a tipagem dinâmica o programador pode cometer erros simples que mais tarde serão difíceis de se identificar.


Como eu poderia exemplificar em código a falta de confiabilidade da linguagem?


Você está partindo de uma premissa e tentando construir o argumento de trás pra frente para justificar a sua premissa. Não considero isso um exercício válido.

Antes de mais nada: Garbage Collector é um detalhe de implementação da linguagem. Eu posso usar Garbage Collector em C se eu quiser. Assim como você pode desligar garbage collector em Java.

Com coletor de lixo, o programador não tem controle sobre o que é deletado da memória, isso impossibilita a utilização dos programas em sistemas críticos

Isto é incorreto.

Primeiro, você possui todo o controle quando algo vai ser ou não apagado da memória. Garbage collector não fica aleatoriamente apagando coisas. Ele só vai liberar memória quando não houverem mais referências. E não vai cometer erros, o que torna software mais confiável, não menos.

Você não têm controle sobre códigos de terceiros, então é verdade que nesse caso não há controle sobre o uso de memória. O interessante é: se você estiver escrevendo a mesma coisa em C ou C++, você *também não têm controle*. E pior, nesse caso, a biblioteca pode estar liberando memória e tentando utilizar de novo (double free), pode não estar liberando memória nunca (memory leak), pode estar tentando acessar memória que não à percence (out of bonds access), etc. Pelo menos em Lua (e outras linguagens com GC), você garante que esses problemas não vão acontecer – fora memory leak, justamente por você ter controle de quando "deleta" coisas da memória, então o código pode escolher nunca deletar.

Note que existem diversos sistemas críticos escritos em Java (satélites, sondas em Marte, aviação, dispositivos médicos) e todas as implementaçõs de Java possuem Garbage Collector.

O fato de existir ou não Garbage Collector não exime o programador de ter cuidado com alocação de memória. E o controle continua com ele. Se eu estou desenvolvendo um sistema embarcado com pouca memória, tenho que tomar cuidado na hora de alocar memória/construir objetos. Em alguns casos faz sentido alocar toda a memória no começo do programa e usar como "pool".

Sobre checagem de tipos dinâmica: algumas classes de erros podem sim ser evitadas com com linguagens fortemente tipadas e checadas em tempo de compilação. Mas, a não ser que estejamos falando de linguagens tipo Haskell, é uma checagem muito simplória. Simplória no sentido de: na primeira vez que o trecho de código rodar, o problema vai ser encontrado. Se você colocou código em produção com trechos que nunca foram executados, então existem problemas bem mais sérios com o seu processo. E provavelmente testes não estão sendo escritos.

Não existe compilador nenhum que consiga lhe salvar de práticas de desenvolvimento ruins.


— Stephen



--
Você recebeu essa mensagem porque está inscrito no grupo "Lua BR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para [hidden email].
Acesse esse grupo em https://groups.google.com/group/lua-br.
Para mais opções, acesse https://groups.google.com/d/optout.