Felizmente isso não é um problema no modelo relacional ou funcional, por isso as pessoas criam esses paradigmas, pra rodar sistemas criticos, e OO para criar apps pra iPhone e Android.
Você não sabe nem escrever Ericsson. 
O “grande nome” do paradigma funcional que você citou usa programação funcional em domínios extremamente específicos. Então, de acordo com esse critério, podemos citar como “grandes nomes da OO”: IBM, Oracle, Xerox, Microsoft, Siemens, Apple, Google e dezenas de outras empresas que usam ou usaram Java, C++, Python, Objective-C, …
Sua pergunta sequer faz sentido, porque grandes empresas não se desenvolvem em torno de paradigmas de programação.
Você espalha desinformação nesse fórum com muita convicção.
Eu não disse que era usada pra tudo, apenas em sistemas críticos. Pelo visto você esta com dificuldade de assimilar isso por algum motivo?
IBM e Oracle não usa OO no seu banco de dados relacional.
Para programadores criarem app front-end, como já falei, não tem coisa melhor do que OO. Nesse sentido, Microsoft Apple e Google usarem OO é uma coisa boa. Interessante Go não é OO…
Siemens, Xerox não sei nada sobre envolvimento com OO, poderia ser mais específico?
Não, cara. A Ericsson usa Erlang onde ela precisa de “soft” real time. Erlang não é adequada para sistemas hard real time e safety-critical.
Para uma operadora de telecom, o sistema de Billing é crítico, porque se faturar errado, você é processado ou não entra grana. Existem vários sistemas de billing feitos em C++ com Java. A Ericsson vende um desses.
Go não é OO, nem é funcional, nem força a imutabilidade. Go é um C modernizado, projetado por um cara que trabalhou com os criadores de C.
A Siemens usa OO em sistemas de automação industrial. A Xerox patrocinou o grupo que inventou o conceito de OO.
Eu não tenho idéia onde vc quer chegar. A Ericsson usa Erlang pra chutar o traseiro da concorrência no mercado de soft real time, e é isso que importa.
Não é crítico para a Ericsson, por isso é em OO.
Poderia simplesmente ter dito que não tem sistemas criticos em OO, só relacional, funcional e estruturado.
Links?
A Xerox patrocinou o grupo que inventou o conceito de OO.
Você quer dizer o conceito de GUI (Graphical User Interfaces)?
O sentimento é recíproco. Você já respondeu a pergunta do tópico: Dados imutáveis são realmente necessários? Não. É possível construir software de qualidade em qualquer domínio (inclusive sistemas críticos) sem forçar a imutabilidade. Já foi feito e continua sendo feito. Não creio que haja nada mais interessante pra sair desse papo.
BOMBA! Alan Kay afirma que mutabilidade viola o espírito da POO…
doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.
Generally, we don’t want the programmer to be messing around with state, whether simulated or not.
But most people who use setters simply use them to simulate direct assignments to interior variables, and this violates the spirit and intent of real OOP.
Pelo visto muita gente vai ter que re-aprender OO, né @esmiralha.
It is unfortunate that much of what is called “object-oriented programming” today is simply old style programming with fancier constructs. Many programs are loaded with “assignment-style” operations now done by more expensive attached procedures.
Acho que já pode trancar o tópico né, quem vai querer discutir com o cara que inventou o negócio?
Esse tópico tem que ser trancado porque você é incapaz de sustentar uma discussão em busca de esclarecimento. Você só quer convencer alguém de que você está certo.
Reduzir a mutabilidade é um princípio importante. Ninguém negou isso. O que eu neguei e nego é que a imutabilidade seja um pré requisito obrigatório para construir software de qualidade para qualquer domínio, inclusive em sistemas críticos. A única teoria que não pode ser refutada é a realidade.
1 curtida
ok, é apenas sua opinião, e podia ter dito 16 posts atras. agora que o inventor da OO respondeu a pergunta do tópico, não é muito relevante.
…ou vc tb quer argumentar com o inventor da oo???
Ainda essa discussão? risos
Você pode mostrar um exemplo claro onde a mutabilidade num sistema crítico poderia ser um problema? Deixe-me reformular: pode explicar claramente por quê apenas imutabilidade funciona em sistemas críticos? Acha que nunca vai ser preciso mutabilidade em tais sistemas?
Óbvio que em termos de concorrência aplicar-se-ia imutabilidade, mas ainda dentro de um sistema crítico, podem existir cenários onde você precisa representar teus objetos com certa mutabilidade, pois fazer cópia excessiva de tudo poderia trazer problemas de performance.
Tem que ponderar. Em OO é possível programar com imutabilidade quando necessário. E em FP é possível programar com mutabilidade quando necessário.
Não, claro que não. Deixo ele mesmo te responder!
The basic idea (influenced by Sketchpad) is that most variables/values are in dynamic -relationships- with each other (maintained by the interior of the object), so being able to directly reset a value from the outside is dangerous. Because (in Smalltalk anyway) there is at least a setter method required, this allows the possibility of an outside setting action to be mediated by the internal method to maintain the desired interrelationships. But most people who use setters simply use them to simulate direct assignments to interior variables, and this violates the spirit and intent of real OOP.
Ele está falando de manipular diretamente o estado interno de um objeto.
Molecagem não ler a resposta dele. Garoteou…
Se tiver não pertence a parte critica, o core, do sistema.
hum??? strings em Java são rápidas porque são imutáveis. rs
Que cópia excessiva esta falando. Poderia dar um exemplo?
Nao. Escolher não mudar uma estrutura mutável não oferece os mesmos benefícios de se trabalhar com estruturas imutáveis. Não da pra fazer cópia barata, não da pra confiar que não será acidentalmente modificado, compilador não consegue tirar proveito da imutabilidade, etc.
Você pode com certeza exigir que seus programadores ponderem. Mas como falei, e volto a repetir, isso raramente funciona na prática porque depende de disciplina e é ainda mais problemático no contexto de uma equipe, já que todos tem que estar ciente do problema o tempo todo. Nunca ouviu falar que a civizilização avança na medida que as pessoas podem fazer mais coisas, sem precisar pensar?
Você acabou de descobrir que tem feito errado todo esse tempo (se é que vc programa, ainda não estou convencido) e eu garotei?
O segundo paragrafo você esqueceu? Onde ele diz que só a história do objeto muda?
an object is only visible when it is stable and no longer computing
Você sabe o que stable significa né? 
Significa que o objeto não pode estar acessível enquanto está em um estado inconsistente. Se uma operação exige a alteração do estado do objeto e essa alteração não é atômica, o objeto não pode estar visível até que essa operação seja concluída. Isso pode ser implementado através de locks (2PL que ele mesmo menciona). Ou através da criação de uma sequência de versões que representa o timeline desse objeto. Os dois mecanismos tem suas vantagens e desvantagens. Não é preto ou branco como você quer pintar.
Você cospe bobagens como “se tem mutabilidade não pertence ao core do sistema”. Isso é uma baboseira, é um bullshit do caramba.
Se for algo não crítico ou que não precisar escalar, eu uso locks.
Para todas as outras, a solucao imutavel é a melhor.
Estava me referindo a FP. Um programa funcional é modelado como uma cebola, com o centro imutável.