Executando verificação de segurança...
1

js possui particularidades e/ou limitações em basicamente todos os pilares da poo, logo também acho que não é ideal pra aprender orientação a objetos quando se é iniciante. nem mesmo uma classe é uma classe. tiveram que introduzir uma caceteda de syntax sugar ao longo dos anos

meus professores viviam falando que poo foi chumbado na marra no python e no js, e eu achava muito preciosismo da parte deles e conforme fui estudando e trabalhando na área, tirando a passionalidade deles, típica do meio acadêmico, eu meio que concordo

Carregando publicação patrocinada...
1

nem mesmo uma classe é uma classe.

Tem um erro conceitual ai, OOP não é ter classes!
Uma maneira usada para facilitar OOP é ter class.

JS é OOP mas não precisa de classes para ser OOP.
O maior problema do que ensinam por ai é que OOP = classes.

Introduziram classes para que programadores acostumados com essa forma de OOP
pudessem entrar em JS sem ter que aprender sobre OOP prototipico
Que é uma maneira diferente de se pensar.

E programador não gosta de aprender algo muito diferente kkkkk

Um grande problema que sempre percebo é que features de java viram conceitos de OOP.
As features que Java ou C# possuem facilitam o OOP delas.
Mas não definem o que é OOP.

@manieiro aqui do Tabnews sempre diz que OOP de java é muito ruim e mal feito.

1

poo não é estritamente sobre classes porque também existe herança por prototipação, mas isso só existe no javascript e numa linguagem morta da xerox criada nos anos 80.

mas é interessante como introduziram a palavra "class" em javascript, não? por que o fizeram? não é um erro conceitual meu. em javascript existe class que por baixo dos panos não é class, literalmente com o nome class.

as linguagens mais tradicionais que suportam este paradigma não se aproximaram do javascript, mas javascript a cada atualização traz mais syntax sugars e conceitos pra se aproximar dessas linguagens. a última atualização recebeu itens relacionados a encapsulamento, o que já é muito maduro em java e c#, por exemplo, há décadas.

se é pra aprender poo, por que aprender primeiro em uma linguagem que tem muitas particularidades neste paradigma, ao invés de aprender em linguagens mais comumente utilizadas no mercado com este paradigma e cujos conceitos são comuns entre elas?

1

mas é interessante como introduziram a palavra "class" em javascript, não?

Eles fizeram como fazem com o C++. Agradar todo mundo.

itens relacionados a encapsulamento

JS sempre teve. Só não tinha a sintaxe que o alguns gostam kkkk
Closuses sempre estiveram no JS.

se é pra aprender poo, por que aprender primeiro em uma linguagem que tem muitas particularidades neste paradigma

Para aumentar a inteligencia e ter uma bagagem melhor para criar coisas novas e criativas! Para isso é preciso conhecer e aprender coisas como essa que são bem diferentes!

Além de que, JS continua sendo prototipico. Pegar algum lib super otimizada vai ver prototipos lá! E não conhecer isso vai ser um grande problema!

Outra questão!
JS já era comum no mercado de back com node desde 2009(ou rihno e outros).
Mesmo sendo es5, com o es6(2015) e posteriormente implementado(a pra se dizer que totalmente em 2017). O povo fazia grandes maravilhas do mesmo modo.

O que a TC39 quis foi melhorar o inicio do programador que já programava em linguagens comuns. Que não queria aprender JS! Um programador velho é um programador que não gosta de aprender.

cujos conceitos são comuns entre elas?

Os conceitos sempre estiveram lá!

  • encapsulamento
  • herança
  • herança multipla
  • polimorfismo

Mas não com a sintaxe que alguns estava acostumados!

OBS: Self(da qual JS deriva) foi criada na Sun e Lua(criada na puc) são prototipicas!
Lua foi criada sem class e o povo na época achou um tipo de desrepeito kkkk
Mas lua é super bem conceituada e usada no mundo todo.

OBS2: O modo prototipico do JS não é bonito! Não da pra negar não!
Mas eu acho que deveriam melhorar isso, no lugar de inserir outra forma!
:)

1

interfaces, sobrecarga de métodos e construtores, enums, necessidade de implementar coisas simples como "classes" abstratas na unha...

ter que implementar na mão, fazer workarounds, usar libs... claros indicativos de que "os conceitos sempre estiveram lá" é uma meia verdade.

1

Agora entendi seu ponto. Elucidou as minhas dúvidas!

Tudo isso que você esta dizendo não é nada relacionado aos conceitos OOP diretamente.

Principalmente de Simula e Smalltalk que são a origem de OOP.

Ter que implementar na mão é algo estranho, pq nesse caso o programador não quis mudar sua forma de pensar. Ele esta querendo trazer o que sabe de outra linguagem e socar em JS. Esse é um erro comum. Mas que não deveria acontecer.

É isso que eu digo sobre programador velho! Ele não quer aprender.
Ele quer socar o que sabe de outra linguagem na nova! E isso gera grandes frustrações!

Por isso uma linguagem que implementa OOP de uma forma diferente não é bem aceita.
Pois não querer aprender e querer usar as mesmas coisas que usava em outra linguagens gera problemas!

os conceitos sempre estiveram lá

Quais são os conceitos de OOP pra você?
você segue a definição de Peter Wegner no artigo dele?

Estou bem curioso!
esta discussão esta muito boa!

Abraços

1

você parte da premissa que todo "programador velho" é preguiçoso, e além de essa ser uma afirmação desrespeitosa, é inválida nessa discussão porque não apenas não sou um programador "velho", muito menos preguiçoso, como trabalho também diariamente com javascript, entre outras tecnologias.

existem motivos sólidos para o mercado não adotar o javascript em projetos críticos, dentre eles está o suporte anêmico a poo. é mais provável uma empresa iniciar o desenvolvimento de um ERP hoje em pleno 2023 utilizando object pascal do que javascript. por que a minha equipe deve adotar uma linguagem em que "os conceitos de poo estão lá", mas que dificultam o desenvolvimento e consequentemente testes e manutenção? todas as demais linguagens orientadas a poo seguem determinado padrão de desenvolvimento, mas minha equipe "tem que aprender (tempo e dinheiro) coisas novas" (que não são novas) porque (apenas) em javascript é implementado diferente e para não ser taxado de programador velho e preguiçoso pelo uriel.

"não é porque posso, que devo". tem que ser bom para o projeto, e não para o programador. os outros são velhos e preguiçosos ou você gosta de bater em prego com chave de fenda e acha que todos deveriam fazer o mesmo?

2

também convenhamos, é muito mais vantajoso usar JS funcional do que orientado a objetos. Mas acredito também que colocando o ts na balança isso mude um pouco, já que torna a orientação a objetos do javascript muito melhor. Como toda ferramenta a linguagem tem casos de uso e funciona melhor em determinados ambientes. Assim como toda linguagem permissiva, o javascript sofre muito do mau uso de pessoas que querem programar da mesma forma com que em outras linguagens, o que é um erro absurdo. Se você quer programar estilo Java, passe longe de javascript, é uma questão de gosto e de organização do projeto. Nem sempre POO vai ser o melhor e nem o mais indicado, parece ser óbvio, mas nem todo mundo tem esse conhecimento.

1

exato. é o que venho tentando dizer.

sobre o typescript: sim, é mais seguro, tira bastante a permissividade do js e implementa coisas como interface, por exemplo, mas não da melhor forma (basta ler os códigos transpilados). tenho um webservice na nossa empresa que desenvolvi em node.js e typescript, e atende muito bem a sua proposta. ficou leve, é rápido, é escalável, está fácil de testar, mas tendo participado de outros projetos mais críticos com outras tecnologias na mesma empresa (com C# e ASP .NET Core), ficou evidente pra mim o limite. e tá tudo bem... linguagem é ferramenta, a gente usa o que serve para o projeto, não existe bala de prata em nenhum caso.