Executando verificação de segurança...
Em resposta a O que você considera mais produtivo em uma linguagem de programação?
0
maniero

Quase sempre essas coisas são subjetivas demais.

Existem alguns estudos sobre isso. Todos meio subjetivos também. O que significa ser pseudociência. A maioria dos estudos não provam nada e muitos estão errados. Mas tende ser melhor que um achismo total.

A linguagem não te dá tanta produtividade quanto pode pensar. E ferramentas podem ajudar até mais. Lembre-se que o grosso do tempo do desenvolvedor ele não está programando.

Eu nunca mais achei (dá vontade de falar que eu que inventei isso :D) um artigo interessante que fala que existem só 3 balas de prata na computação:

  • Linguagem de alto nível - não programar em Assembly e sim em Fortran, Lisp e depois as várias outras que apareceram como C ou TypeScript.
  • Modularização - Principalmente criar função em vez de ter um enorme linguição, então versões posteriores de Fortran, Lisp, COBOL e quase todas as outras (BASIC original e alguns simplificados não tinha, só um exemplo).
  • Gerenciamento automático de memória - começando com Lisp, mas hoje está presente em quase todas as linguagens, assim como os itens anteriores, até mesmo em algumas que preferem falar em semi automático, como em C++ por exemplo. C puro não tem isso.

Essas coisas dão ganhos de produtividade incríveis. O resto nem tanto. Algumas coisas dão ilusões de produtividade para escrever, mas depois cobra o preço de dar manutenção. tem estudo que mostra que linguagens dinâmicas só são mais produtivas para escrever, não no longo prazo. Mas as pessoas gostam da ilusão do curto prazo.

Para escolher uma linguagem pode adotar critérios técnicos e políticos. O segundo não pode ser subestimado. A Popularidade, por exemplo, é político. E isso conta. Até já saber usar também.

Quando se fala em limitação de recursos pode já excluir quase todas as linguagens. Mas às vezes isso não é tão importante quanto pensa. Por que, mesmo muita gente jogando pedra, ainda é preferida por muita gente? Porque olhando para todos os aspectos não tem linguagem que permita ao bom programador economizar mais recursos. Vai dar trabalho, mas isso é outra questão.

Não sei se de fato precisa disso, mas não vou dizer o contrário. Eu gosto desse critério.

Exclui C#? Então tá: https://www.techempower.com/benchmarks/#hw=ph&test=plaintext&section=data-r22.

Para fazer uma boa seleção precisa de informações corretas. Se pegar dados falsos, fofocas, fakes news, etc. sobre algo, a seleção será falha.

Curiosamente eu excluiria em alguns casos por outros motivos, mas não esse.

Macro é ilusão. Quem tem experiência sabe que isso gera muito problema no longo prazo e acaba destruindo a produtividade. Claro que tem casos bons. Tem casos que é menos necessário do que parece.

C# tem mecanismo mais simples e menos poderoso, mas que atende quando é muito necessário,que é a geração de código. Não é tão elegante e bonitinho, mas isso pode ser feature, mesmo que pareça um besourinho com terninho esfarrapado (não vou postar o meme).

Deploy simples anda ficando raro. Mas ok, quase todos os casos pelo menos disfarçam bem :)
Se depois de escolher uma linguagem adequada fizer código acidentalmente complexos, com arquiteturas desnecessariamente exageradas, pra que? A capacidade do programador conta mais que a linguagem.

Inferir tipo pode ser um fator de inelegibilidade em alguns, ou muitos, casos. E isso piora a manutenção, e pode até criar problemas de robustez em casos extremos.

Não consigo ver que o sistema de tempo de vida possa impedir abstrações, mas ele cria dificuldades. Algumas pessoas alegam que mesmo que seja improdutivo no primeiro momento, depois ganha muito. Claro que não tanto quanto o gerenciamento automático e simplificado de memória, mesmo a custo de consumo de recursos e pausas indeterminadas.

Se não precisa da performance de Rust, então C# deveria estar muito dentro. Java também. E outras.

Eu gosto e desgosto de Go, mas não sei se é massante. Ficou parecendo uma coisa bem de gosto mesmo, muito subjetivo, quase um motivo inventado.

É, pode ser uma pena Swift estar na mão da Apple.

Eu acho CLisp mosca branca demais, mais que Crystal. Eu até uso mosca branca, mas por motivos de legado ou pra algo pessoal.

OCaml é legal, mas cai quase no mesmo problema. Eu até adotaria F# que é Ocaml "melhorada" para .NET.

Conheço pouco de Crystal, mas já investiguei um pouco. Não sei se ela é tudo isso que acha que é. Eu acho que tem um verniz que esconde os problemas. Por quase não ser usada, não sabemos direito dos problemas. Eu só tenho percebido os erros de Python agora, e eu já usei a linguagem há quase 20 anos. Popularidade ajuda a perceber melhor os problemas.

Se o meu caso fosse o seu eu iria de C#, até porque eu não precisaria aprender outra coisa e tem várias vantagens. Se eu quisesse mais economia de recursos, eu pensaria em Rust, daria um esbarrão em Go, e não descartaria C ou C++ em alguns casos. E se tivesse tempo, ainda tentaria Carbon.

Curiosamente uma linguagem que já usei muito e hoje em dia quase ninguém ouviu falar, é muito mais economia de recursos em vários critérios (mas não todos). Poder entregar aplicação com KBs em vez de MBs é ótimo né? (acabei de lembrar do cara que entrou praticamente 4 CRUDs em Laravel e a aplicação tinha 1GB). Liberar a memória assim que não precisa mais sem se preocupar também, né? Não ter uma VM maluca que demora de algumas dezenas ou centenas de vezes mais que o nativo, é a cereja no bolo, mesmo que ainda não tenha toda vantagem do nativo.

Uma coisa que eu acho engraçado quando a pessoa fala em economia de recursos e faz aplicação para web :D

Mas eu sempre gosto de ouvir mais sobre linguagens que eu não conheço bem. Obviamente não algo raso, ou óbvio (que está no site dela, na Wikipedia, doc, etc.)

Uma coisa que eu sempre vejo é as pessoas acreditarem que passaram todo o cenário, contexto, requisitos. Quase 100% das pessoas falham nisso. Eu mesmo já falhei inúmeras vezes. E muitas vezes ela não passa porque ela não tem (ou acham que já tem todos). Então a escolha será falha.

Parece que criou os critérios/requisitos para Crystal ganhar, ou seja, eles foram criados depois de saber o que Crytal tem. Parece licitação pública.

Faz sentido para você?

Espero ter ajudado. Em geral estou à disposição (sem abusos :D)

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Carregando publicação patrocinada...
2
MthRyan

Bom. Na verdade C# foi minha primeira opção eu a deixei de fora pois é minha linguagem principal, logo era injusto comparar com minhas pesquisas Durante a semana. E sim eu faria nela se pudesse pagar pelos recursos. Não pretendo criar um monólito e preciso de no mínimo 3 serviços para iniciar. O que em c# me custaria muita memória (cerca de 500mb em pico). Mais do que posso pagar, o que no momento é: 0.

Sobre os critérios, acho que essa impressão sobre crystal ficou muito mais pela falta do que excesso. Ahh e se a linguagem tem defeitos. Tive que fazer questão de deixar no fim um disclaimer sobre. De forma alguma quero que alguém a escolha por isso. Eu sei dos riscos e do que posso tolerar da linguagem. C# por exemplo, apesar de não possuir um sistema de inferência de tipos mais forte, é sempre minha primeira opção pela solidez.

Porém, o post no geral era realmente sobre o que as pessoas consideram: "produtivo". E respeito bastante o argumento de que abordagens mais conservadoras podem a longo prazo serem mais benéficas ao processo.

Contudo, tenho que discordar em parte sobre dois pontos: o sistema de macros, ressaltei é claro que esses devem ser ínfimos, e aplicados cirurgicamente. E sobre o sistema de lifetime. Esses sim tenho que reforçar, criar abstrações em certos aspectos em rust é doloroso. Leva muito tempo, esforço e aumenta a complexidade de forma absurda. Existem frameworks em rust em que um simples http response tem 4 argumentos genéricos com 2 sendo de lifetime.

E pra finalizar, diria que só tenho duas tristezas nessa vida: Swift estar na mão da Apple e Scala ter sido criada sob a JVM.

1
maniero
Autor
Autor

Ficou mais estranho ainda querer evitar monólito (o Stack Overflow não evitou, pode atender demanda de um dos 30 sites de mais acessados no mundo com um servidor, tudo em C#, porque eles não tinham rios de dinheiro, sem contar os inúmeros casos de serverless).

Não entendi de onde vem esses 500MB do C#, nem que Crystal atende o critério de poder pagar 0, muito menos como Crystal consegue ser segura (se não for temo opções melhores), não ter controle de tempo de vida (obrigatório para ser seguro sem GC), coletor de lixo (porque só assim vai gastar muito menos memória que C#), mas eu sempre gosto de aprender (GC baseado no Boehm é extremamente ineficiente, gastador de memória e causa vazamentos, foi ele que deu má fama aos GCs). Nem deveria ter uma linguagem com GC na conversa quando o requisito é estrito consumo de memória. Se falar que vai desligar o GC, C# também pode, mas em qualquer caso consome mais memória ainda, e se for gerenciar a memória na mão, não consigo imaginar porque não usar outras coisas inseguras. (avabei de descobrir que atualmente ela vaza memória em hello world).

Nem imagino que ganho terá em quebrar os executáveis, ou quanta economia fará (em geral isso é custo). E espero que não esteja falando de arquitetura de microsserviços, a não ser que esqueceu de falar que está trabalhando em um dos maiores projetos do mundo, e onde vai achar tanto programador e Crystal.

Acho que se apega a pontos pouco importantes e não está observando casos reais, misturando coisas, que me fez pensar desde o início que estava fazendo cherry picking. Pelo menos espero que já domine Crystal. Dominar e ter um ecossistema forte d~´ao mais produtividade que detalhes pequenos (eu diria minísculos pelo que foi indicado).

Eu acho que você tem uma visão equivocadas de algumas coisas e escolheu ter essa visão (não por falta de conhecimento técnico), eu poderia ficar argumentando, mas eu sei pouco do que realmente quer fazer (inicialmente falou de algo e depois mudou na (t)replíca) para argumentar melhor e parece que não será produtivo.

Mas estou sempre aberto a aprender, por isso bato muito na tecla que não consigo ver, imaginar, entender sobre certas decisões.

2
MthRyan

Não quero ser muito aguerrido nessa discussão pois tenho que dizer: sim, eu testei C#. Sim, eu testei outras linguagens. Lembre, você não sabe qual projeto estou trabalhando. E não, C# não consegue atender meus requisitos de memória uma vez que apenas para subir uma instância da clr com Aspnet é necessário 80mb de memória enquanto Crystal ou Go gastam 3. A escolha da arquitetura não é por moda e sim por praticidade. Não é um site apenas, logo não consigo manter tudo em um servidor. Então compreenda que fiz uma escolha apropriada pra mim. Não recomendei a ninguém que faça a mesma. Mas esses pontos se disponíveis em uma linguagem simplesmente me fazem escrever rapidamente um código extremamente limpo. E aposto que concorda com a maioria já que c# e f# apresentam quase todas as características que citei.

0
maniero
Autor
Autor

Por isso ficou improdutivo, parece que só queria desabafar, não dá detalhes e pede para opinarmos.

De qualquer forma agora veio mais algumas informações que confirmam vários aspectos do que eu disse, principalmente de fazer cherry picking sobre o que eu disse e do que responder. E mais uma, que é sobre a apostagem não ser sobre ser produtivo.

É claro que Crystal gasta menos memória inicial, porque gasta mais depois, afina usa um GC ingénuo, que é quase um mock, por isso dizem que vão mudar, e vai gastar mais memória e aí perde a vantagem pretendida por não ter controle sobre isso.

Eu fui ver mais sosbre Crystal e percebi que a comunidade dela é bastante ingênua, parecido com o que acontece com V, e acreditam em coisas que a computação não permite e acabam fazendo marketing para si mesmos de que fizeram a escolha certa. E acabam convencendo outras disso.

Não estou dizendo que Crystal seja uma linguagem ruim, eu já havia avaliado antes e sei que tem méritos e eu poderia usar em algum cenário, mas ela não é tão boa quanto alguns acham. Fazem parecer que ela é mágica, quando apenas não estão vendo o truque.

Faltou decidir se queria produtividade, baixo consumo real de memória ou outra coisa.

No fundo a maioria dos projetos nem precisam de muito cuidado, a pessoa faz de um jeito que não o ideal, mas funciona, e fica todo mundo feliz, não importa se é produtivo, se não atende requisitos que nem precisavam existir.

Por tudo isso não tenho mais o que dizer. Boa sorte no seu projeto.

2
MthRyan

Eu respeitei sua opinião de que o impacto do que apontei pode ser subestimado. Desde o primeiro comentário. Rebati alguns pontos. Mas essa insistência em falar sobre o projeto em si me cansa. O post nunca foi sobre isso. Ainda sim agradeço por tudo. Quem sabe um dia eu perceba que você está completo de razão, ou não. Isso só o futuro determina. Obrigado por comentar.