Simplesmente use Java
(teamten.com)- Minha linguagem favorita é Python. Mesmo assim, eu uso Java em todo lugar — até para scripts simples.
- Algumas experiências:
- Em uma empresa baseada em Java, escrevi cenários de teste em JavaScript. Mas era difícil rastrear stack traces e acabei fazendo esforço desnecessário escrevendo código de ponte entre Java e JavaScript.
- Estávamos salvando logs em formato JSON, e um colega desenvolvedor criou um programa chamado
logcatpara lidar com esses logs. Eu estava satisfeito com o programa, mas depois, quando fizemos um programa parecido em Java, ele mostrou mais de 10 vezes o desempenho. - Graças à vasta experiência e à abundância de materiais sobre Java, Java foi mais rápido que Python na tarefa de criar um serviço web. Estritamente falando, isso é uma vantagem de usar uma única linguagem.
- A discussão mais acalorada sobre Java é o verbose (verbosidade). Mas isso não é desvantagem nenhuma. Veja os dois códigos abaixo.
// java
Map<String,User> userIdMap = new HashMap<String,User>();
// python
userIdMap = {}
- Mas, na prática, é bem mais provável que o código Python esteja escrito assim. (Se não estiver, será realmente muito difícil de manter)
# Map from user ID to User object.
userIdMap = {}
- Ou seja, usar uma linguagem de tipagem dinâmica é como sacrificar a produtividade depois de 14 dias para construir algo legal em 30 minutos.
- O Stack Overflow, usando ASP.NET, sustentou 60.000.000 de pageviews com 5 servidores (em 2010).
- Vamos ver o exemplo de testes unitários. Escrever e manter testes unitários consome tempo. Em especial, casos excepcionais que podem ser verificados facilmente por tipos nem sequer são bem capturados por testes unitários em linguagens de tipagem dinâmica (ex.: parser).
- (Para acrescentar mais um motivo para não usar Python) uma solução improvisada (quick hack) vai crescendo e se torna uma ferramenta muito importante, mas não há folga para reescrevê-la, e no fim você passa a sofrer com desempenho e manutenção toda vez que a usa.
- Por fim, os motivos pelos quais prefiro Java em vez de outras linguagens de tipagem estática
- É difícil aplicar C/C++ ao meu trabalho
- C# tem pouco suporte multiplataforma
- Scala é complexa demais
- Outras linguagens, como D e Go, ainda são novas demais para eu colocá-las no meu trabalho
- Há alguns motivos pelos quais trouxe este texto para o GeekNews:
- Fiquei surpreso porque foi a primeira vez que vi um texto do tipo “Eu realmente gosto de Java!”. (Só pelo título, achei que viria uma reviravolta...)
- Achei interessante o fato de o autor ter sua própria caixa de ferramentas (feita em Java). Isso me fez imaginar a figura de um velho tirando antigas armas de bolso, uma por uma.
- Eu, pessoalmente, gosto muito de JavaScript e Python. Mas, olhando por alto, também parece que nessas linguagens a tendência é “introduzir tipos de alguma forma” (TypeScript para JavaScript, typing/mypy para Python). Diante disso, ao ler este texto, pensei que usar uma linguagem de tipagem estática sem impor tipos de forma alguma talvez seja, em certa medida, algo próximo de uma autoindulgência da minha parte.
- O autor compara diretamente Java e Python porque tem experiência com as duas linguagens, mas não acho que seja necessário limitar a discussão a isso. Em uma perspectiva mais ampla, o que vocês pensam sobre linguagens de tipagem estática e dinâmica?
PS. Vamos evitar depreciar uma linguagem sem sentido :D
58 comentários
Pode ser uma experiência muito pessoal, mas acho que, no Java, o maior problema é a JVM mais do que a linguagem.
Já passei muitas vezes pela situação de o gerenciamento de memória não funcionar direito em várias versões da JVM.
Então faça e use
pandasenumpyem Java também. Quem faz esse tipo de afirmação não deve ser mantido por perto.Java é usado para backend web e Python para IA. Se for para discutir desempenho, aí teria que usar Rust; não é algo que todo mundo já sabe? Mas, como a tendência é que a participação da IA aumente daqui para frente, penso que talvez já esteja na hora de abandonar Java. Aqui no nosso país muita gente tem essa mentalidade de que não podemos ficar para trás, rs.
Se a demanda por IA aumentar e APIs REST comuns ou tarefas simples de CRUD forem substituídas, a ponto de esses sistemas deixarem de ser construídos, aí talvez dê até para abandonar o Java.
Além disso, nem sempre um projeto é composto por uma única linguagem, então também não acho que dê para fazer uma correspondência de um para um entre linguagem e objetivo do projeto. Como a interface de programação costuma ser em Python e as partes em que desempenho é importante geralmente usam código nativo. Embora esse tipo de configuração de projeto não seja muito comum por aqui.
A introdução deixa um pouco a desejar. Se tivessem informado primeiro a data em que o texto original foi escrito, acho que metade do pessoal aqui teria entendido até certo ponto...
Eu também percebi isso ao ver os comentários de outras pessoas.
Mas eu presumi por conta própria que tinha sido escrito recentemente e não senti nenhum estranhamento ao ler o conteúdo. Pelo menos para mim, ainda é um texto convincente.
Separadamente disso, vou prestar mais atenção nas datas de vez em quando kkk
A discussão está ficando acalorada.
Se houver uma contestação, por favor escreva apenas o seu conteúdo.
Comentários que violam as regras de uso do site foram removidos.
Além disso, informamos que bloqueamos contas com atividades repetidas que não estão de acordo com as regras de uso.
Pedimos uma discussão saudável.
Eu confio mais no Google (V8) do que na Oracle (JVM).
Quando eu programava em Python e vi Java pela primeira vez, achei realmente verboso, mas hoje em dia, quando vejo o código necessário para adicionar type hints completos em Python, já não me parece tão diferente assim rs. O ponto fraco do Java, na verdade, talvez seja mais a convenção de nomenclatura de tentar dar nomes absurdamente longos aos métodos.
1 de junho de 2014
Eu também prefiro linguagens com tipagem estática.
Embora linguagens de tipagem dinâmica tenham suas vantagens em termos de praticidade, em ambiente de produção elas às vezes acabam ficando difíceis de manter.
Além disso, linguagens de tipagem dinâmica geralmente têm como filosofia de projeto algo como "escrever código simples", então há muitas coisas que a própria linguagem gerencia de forma implícita; por causa disso, muitas vezes sobra menos espaço para otimização.
No fim, parece melhor pensar e escolher de acordo com o ambiente de desenvolvimento, equilibrando esses dois lados: facilidade de implementação vs. maior margem para otimização.
Texto de 10 anos atrás, caramba
Pois é kkk
Apenas use Java
Minha vida ficou mais tranquila depois que abandonei Java.
Há bons motivos para a posição de popularidade do Java continuar caindo na pesquisa do Stack Overflow.
Na Coreia, por causa daquela mania de amarrar frameworks governamentais ao Spring, ele ainda serve na hora de conseguir emprego,
mas no Ocidente, fora sistemas legados, parece que quase desapareceu a escolha de Java ao começar novos projetos.
É verdade que existe um motivo para isso, mas me parece que você está interpretando esse motivo de outra forma.
No próprio site da TIOBE também é mencionado que o ranking de linguagens deve ser visto apenas como referência e que não tem relação direta com participação de mercado ou popularidade.
A conclusão é: Python está em 1º com uma participação esmagadora, mas existem ferramentas assim no mercado?
O que encontramos com mais frequência é C/C++, .NET, Java (Kotlin) e Swift.
Ter muitas perguntas e buscas não significa que seja uma linguagem muito usada.
Python é uma linguagem que qualquer pessoa pode usar mesmo sem formação na área.
Não dá para negar que ela é muito popular, mas no mercado de desenvolvimento a conversa é outra.
O Instagram usa Python no backend.
Não está muito claro o que significa exatamente 'ferramentas no mercado'... mas Django, FastAPI, PyTorch, NumPy, Pandas e por aí vai já não são ferramentas suficientes...?
Vim pelo título já esperando os comentários primeiro kkk. Hoje em dia a dependência de linguagens ficou bem mais ampla, né.
Se a gente limitar a questão só ao custo, Java acaba saindo mais caro na nuvem por causa do uso de memória. Programas em linguagens estáticas que precisam de 100 MB ou 200 MB de memória, quando são escritos em Java, muitas vezes acabam precisando de 1 GB ou 2 GB, e threads leves frequentemente não funcionam por causa da compatibilidade com bibliotecas.
Java também é uma linguagem estática, mas... a questão de memória tem mais a ver com o coletor de lixo ou a JVM, e esse “programa que precisa de 100 MB, 200 MB de memória por ser uma linguagem estática” provavelmente se aplica a linguagens nativas como C e C++.
Desculpem pela alucinação. T_T Java também é, sim, uma linguagem estática. Somando esses e aqueles custos na nuvem, acaba sendo preciso considerar algo em torno de 30 mil won por 1 GB de memória, então serviços desenvolvidos em Java acabam gerando custos bem altos.
Se existem exceções, é uma linguagem de tipagem dinâmica. Separadamente, concordo com o ponto de que sistema de tipos e uso de memória são questões distintas.
A definição dessa exceção que você mencionou me parece ampla demais; poderia explicar com um pouco mais de detalhe?
Pela definição que eu conheço de linguagens com tipagem estática/dinâmica, se o tipo de uma variável é determinado em tempo de compilação e, para mudá-lo, isso precisa ser feito explicitamente, então é uma linguagem de tipagem estática. Já em uma linguagem de tipagem dinâmica, o tipo da variável pode ser definido em tempo de execução e também pode ser alterado implicitamente.
Quando você se depara com uma situação como fazer downcasting em tempo de execução, o Java precisa verificar tipos em runtime. Por esse motivo, o Java é dinamicamente tipado nesse momento, e o que surge aí são as exceções.
Fundamentalmente, se essa lacuna não existisse, não haveria necessidade de chamar exceções de exceções.
throwseria apenas açúcar sintático para o padrão de guardar o objeto lançado em uma variável global e fazer umgotoAssim como você mencionou, uma linguagem que realiza verificação de tipos em tempo de execução é chamada de tipagem dinâmica. Porém, isso se aplica a todos os valores tratados pelo programa. Como o texto é sobre Java, usando Java como exemplo, o código Java tem verificação de tipos em tempo de compilação, mas isso também implica algo importante: os valores atribuídos a uma variável precisam corresponder ao tipo dessa variável.
Se a checagem de tipos em tempo de execução torna uma linguagem dinamicamente tipada, então C também seria uma linguagem dinamicamente tipada por causa disso? Pelo que sei, existe o conceito de
void*; qual é exatamente a diferença entre os dois?Qual compilador C insere verificação de tipos no código e gera um erro explícito quando os tipos estão errados? Se existir uma implementação assim, por favor dê apenas um exemplo.
Em C, não existe verificação de tipos nesse processo. Ler um dado de ponto flutuante como inteiro não causa problema nenhum, certo? Não é que seja tipagem dinâmica, é só perigoso mesmo.
Sim, se C fizesse verificação de tipos em tempo de execução, então seria uma linguagem de tipagem dinâmica.
Como não faz, é de tipagem estática.
void*é apenas um ponteiro bruto cujo tipo original não pode ser conhecido. Não dá para saber que tipo existe no endereço para o qual esse ponteiro aponta.Minha opinião é que a melhor linguagem é aquela com a qual você já está familiarizado.
Concordo. Também parece que não é fácil sair da linguagem usada pela equipe ou pela organização.
Entre os vários motivos pelos quais o conteúdo do trabalho ou as alocações ficam separados, quando uma linguagem é adicionada isso acaba gerando sobrecarga para determinadas pessoas e, quando há mudança de pessoal, o trabalho deixa de avançar. Como isso também é um fator que afeta a contratação, acho que é preciso ter cuidado na escolha da stack tecnológica.
Por outro lado, se insistirmos em uma linguagem só por já estarmos acostumados com ela, mesmo que o pool de contratação seja pequeno ou que ela exija aprendizado adicional após a contratação, isso também é um problema.
Por que o C# seria insuficiente em multiplataforma? Hoje em dia, a maioria dos apps de servidor em .NET é implantada em servidores Linux.
Python nem é um comparativo válido para começar, e acho que é verdade que Kotlin, comparado ao C#, é mais verboso e não tem muitos dos recursos necessários.
Ah, esse texto é de 10 anos atrás. Hoje a situação mudou bastante.
C# também é uma linguagem que usa máquina virtual, então o suporte multiplataforma já deveria ter aparecido há muito tempo, mas, pelo que eu sei, isso surgiu só muito recentemente, e por isso acho que, por um bom tempo, vai continuar existindo a percepção de que dá para rodar em outros sistemas operacionais além do Windows, mas só isso.
Além disso, em ambientes Linux focados em servidores que operam 365 dias por ano, também é verdade que se evita o .NET por ele ainda não ser tão suficientemente comprovado quanto outras linguagens cuja estabilidade já foi verificada por mais de 10 anos naquele sistema.
Nesse sentido, não seria por isso que dizem que falta suporte multiplataforma?
Mas, afinal, qual é exatamente o critério para considerar que a estabilidade foi comprovada? Eu não entendo se você está falando simplesmente do tempo de uso.
Como é um texto de 10 anos atrás, ele foi escrito daquele jeito porque não fazia muito tempo desde o surgimento do .NET Core.
Hoje, os aplicativos .NET já funcionam de forma estável e confiável no Linux e no Mac.
Enquanto eu procurava por algo como uma linguagem com a sintaxe concisa ao estilo de Python e tipagem estática, acabei descobrindo o GDScript por acaso, mas a desvantagem grande demais é que ele é difícil de usar de forma ampla.
Se tiver a oportunidade, recomendo fazer um projetinho com o Godot e experimentar um pouco do GDScript.
Eu tive uma aversão a Java depois de conhecer Kotlin...
Tenho a impressão de que, sempre que você precisa de algum recurso em Java, existe uma resposta comprovada.
Apenas use Kotlin.
Mesmo assim, eu também perguntei por e-mail a opinião dele sobre Kotlin (como usuário de Kotlin), e ele respondeu dizendo que nunca usou, então é difícil falar com base em experiência.
Eu gosto de linguagens com tipagem estática. Porque elas reduzem a necessidade de ficar pensando nisso, e aí posso usar esse tempo para pensar em outras coisas.
Java é uma linguagem que ocupa uma posição realmente única. A última vez que usei Java no trabalho foi há uns 10 anos, mas mesmo hoje, se eu tivesse que desenvolver algum programa para trabalho e não como hobby, ela entraria na lista das linguagens a considerar em primeiro lugar.
Hoje, as principais linguagens que uso no trabalho são Ada e C, mas as ferramentas que faço para uso pessoal ou dentro da equipe geralmente escrevo em PowerShell. Só que, quando estou escrevendo e passa só um pouquinho de tempo (tipo 5 minutos...), já me pego pensando: "qual era mesmo o tipo dessa variável?". Por isso, ultimamente tenho feito questão de sempre explicitar os tipos. (No PowerShell, dá para especificar o tipo na definição da variável, ou omitir e usar de forma dinâmica.)
Também não gosto muito de C. Erros relacionados a tipos que o compilador filtraria em Ada, C simplesmente não consegue detectar. Às vezes penso que seria bom existir uma linguagem com sintaxe parecida com a de C, mas com o sistema de tipos de Ada.
Não consigo gostar de Javascript nem de Python. Perl ou Shell Script... prefiro nem pensar nisso.
Acho que é inevitável por causa da filosofia básica da linguagem C, "confie no programador"..
Ah, e eu gosto de Java, mas odeio o Maven.
Na boa e velha época, dava para fazer tudo com o Ant!
Ainda bem que o Java está aos poucos acompanhando as linguagens mais modernas, com a adição de
recorde pattern matching, entre outros recursos.O Java é bom por ter muitas referências, mas se for só por isso, fico pensando por que não seria melhor usar C++.
Eu teria gostado que houvesse um pouco mais sobre as vantagens do Java.
Eu só usei C++ como exemplo porque é a linguagem que eu mais uso. Eu também acho que Java é uma boa linguagem, mas o que eu queria apontar era que faltava falar sobre as vantagens do Java naquele post original.
Se foi escrito algo como "Java é bom demais", então o foco principal deveria ser falar das vantagens do Java, mas me parece que o principal são as críticas a outras linguagens.
Como você comentou, também acho que a JVM do Java é extremamente boa.
Concordo totalmente. O aviso de que não era para limitar a discussão especificamente ao Java tinha essa intenção. Mas parece que isso não foi muito bem transmitido...
O fato de os comparativos serem Java e C++ já faz a credibilidade cair bastante, kkk
É só usar Java.
Como Java roda sobre a JVM, dá para configurar o ambiente local e o da máquina de forma idêntica. Com C++, levaria bastante tempo para deixar o ambiente de todos os desenvolvedores e das máquinas igual. Também é difícil de manter...
Parece que o autor original está usando Java simplesmente porque é um tipo de trabalho em que é difícil aplicar C++. Talvez, se tivesse que escolher entre Python e C++, ele não escolheria C++?
correção: "por último, motivos pelos quais não [usar] outras linguagens estaticamente tipadas" -> "por último, motivos pelos quais preferir Java em vez de outras linguagens estaticamente tipadas"
Isca boa pra pegar fogo mesmo.. recomendo demais
Não é o tipo de fogo que eu queria T_T
Quentinho... né...