uso de byte, int e short em java

Como sempre absorvendo o ponto de vista ..

Essa da receita do bolo voce é bem critico mesmo , quase todo post que voce responde, voce cita o velho exemplo que nao existe a receita do bolo ou o caminho das pedras..
Outra parte que gosto em voce e a parte que voce cita a criatividade , se enquadra certo com a sua ideia de que nao tem uma receita pronta a ser seguida e sim uma logica pensada e aplicada ..

Voce e Ronaldo experientes na area, um dia eu chego a esse nivel rs

Virou meio que regra isso. Mas quero ver as respostas.

Geralmente o pessoal usa mais "int" porque isso virou meio que um padrão, os livros, apostilas e tal sempre usam o int como exemplo e ai o pessoal vicia nisso.

Existe também a questão de conversões e a facilidade das ferramentas, alguns frameworks e ferramentas (Spring, JAckson, GSON) quando trabalhamos com eles, acabam implementando funções de conversão de datas, grandezas, entre outras recebendo como valores tipos inteiros, ou seja, mesmo você sendo um programador novato que aprendeu agora que o certo é usar aqueles tipos primitivos, se for usar uma tecnologia como essas onde algumas de suas funções recebem inteiros, você teria que converter os valores toda vida, o que acabaria por lhe forçar a usar o tipo int por exemplo. Mesmo você tendo na cabeça que o correto é aquilo algumas coisas forçam você a realizar "absurdos" em determinadas situações. Mas que é bastante complicado é, lembro quando comecei que desenvolvi em clipper (aprendizagem com máquinas configuradas para limitação de memória), tudo influenciava na hora de decidir a próxima variável, por que toda a memória tinha quer ser racionada, nome de função, nome de campo no banco, as variáveis não tinham tanto tamanho como existem é linguagens como java e as máquinas eram totalmente limitadas, cara naquele o pessoal passava aperreio por conta disso

No os frameworks já deixam padronizados?

De certa forma sim, falando sobre pessoas que iniciaram agora, esses padrões de desenvolvimento na maioria das vezes surgem junto com os frameworks, não estou falando de MVC, MVW, entre outros, mas falando de implementação básica. Mas também pode-se pensar no comodismo do desenvolvedor, usar o que para ele não vai lhe oferecer dificuldade. Por que se é fácil e está correto nós usamos, as vezes com ressalvas, mas na maioria das vezes usamos normalmente e isso acaba que moldando o nosso modo de desenvolver.

Por isso é bom aprender a forma dificil e depois conhecer as facilidades.

Vejo em muito exemplos de software que a galera utilizam os tipos não primitivos sem precisão alguma, sendo que os mesmo consumem mais desepenho que os tipos primitivos..
Em aplicações grandes devemos ter em mente , qual tipo determinado atributo vai ser..

Isso mesmo Felipe Moreira e Edson Rodrigo, tudo também depende muito do projeto, quando você fala de um projeto simples a preocupação acaba sendo resumida, porém, quando desenvolvemos projetos mais complexos, maiores; é sempre bom se preocupar com questões de tipagem, linguagem, frameworks, entre outros fatores que influenciam no resultado.

Mas ainda assim acho que o programador deveria deixar a preguiça um pouco de lado e procurar aprender a respeito das coisas que ele usa, vejo muita gente usando framework para requisições http por exemplo e não faz a mínima ideia de como o framework trabalha a requisição. É sempre bom se aprofundar para quando acontecer algum problema com o código, você saber corrigir ou implementar você mesmo suas iterações fora dos frames.

Muito cuidado quando se quer dar um passo a frente. Ter facilidades é bom, mas sabendo o que está fazendo.

É bem assim mesmo, o complicado na hora de começar um projeto é justamente a seleção de tecnologias, e se for fazer um projeto onde você é o único desenvolvedor o bicho pega mais ainda, é bom sempre ter em mente que a ajuda de pessoas experientes no assunto é sempre bem vinda, humildade nunca é demais, perguntar, conversar com outras pessoas que você conheça sobre o que você desejar fazer é muito aconselhável. Seria muito bom se todo projeto fosse igual, mas sabemos que sempre nos deparamos com novos problemas, porém, se parar para pensar isso é muito bom, por que de certa forma estaremos sempre aprendendo coisas novas, fazendo novas amizades e iniciando novos contatos.

Concordo com o Ronaldo Filho e passei pelo mesmo cenário que ele quando comecei a trabalhar na área. Comecei com DBase II com um micro com 702 kb de memória e um HD externo de 10 Mega. Hoje qualquer dispositivo de merda é muito superior a isto. E naquela época tínhamos de nos preocupar com alocação de recursos. Algumas máquina nem tinham HD e era tudo na base dos disquetes. Em alguns casos o executável ficava grande demais para ser carregado e era necessário utilizar uma técnica chamada Overlay e dividir o executável e dois discos.

Hoje temos muita memória e espaço em disco então na maioria dos casos não faz diferença. Claro que conhecer e seguir as melhores práticas é aconselhável, mas dependendo do projeto e cenário não afeta em nada. Prefiro o uso errado de um tipo do que um algorítimo ou modelagem porca. Claro que ser você estiver desenvolvendo para um dispositivo com poucos recursos deve-se levar este tipo de cuidado em consideração.

Acho que se você gosta de usar os tipos certos ótimo, mas sem preciosismo e não se preocupar se outras pessoas não são tão preocupadas assim. E muitas vezes você vai trabalhar em manutenção de sistemas legados e trocar os tipos não é algo trivial.

Eu gosto de jogar Minecraft onde devemos usar a ferramenta certa para a tarefa certa, então tenho obsessão por usar tipos e nomenclatura correta, mas se não der, desde que não atrapalhe uso a menos recomendada também.

Justamente isso Jothaz, bem argumentado, gosto muito de pensar que teoria e prática na área de desenvolvimento andam juntas até certo ponto, como dizia o velho poeta "existem situações e situações", umas ocorrem de um jeito com algumas variáveis, já a outra tem 99% das mesmas variáveis da outra mas por um detalhe tudo acaba sendo diferente na construção. Como desenvolvedores precisamos ter a mente aberta e arriscar até aceitar sugestões que, para nós, naquele momento pareceriam totalmente inviáveis.

Uma das coisas que coloquei na cabeça quando desenvolvi um certo conhecimento na área foi, padrões existem não para dificultar o desenvolvimento, mas para melhorar o futuro do projeto, pensando em manutenção e compreensão do código, e outra foi que humildade é tudo, a arrogância nesse ramo só leva a gente para o buraco.

Nas minhas respostas é quase que recorrente o alerta de que não existem receitas nem roteiros, afinal é desenvolvimento e neste caso é fundamental ser criativo. E é difícil definir algo com certo ou errado.

Aqui no fórum a maioria esmagadora dos posts é buscando receitas de bolo. Ao que parece são muitas pessoas que não estudam, não pesquisam, não se esforçam e querem trabalhar com desenvolvimento.

Claro padronização, metologias, melhores praticas e processos, principalmente para grandes projetos é fundamental, mas é tudo um meio e não um fim.

TI não pode ser dogmática.

Outro coisa recorrente nas minhas repostas é nada de deslumbramento, pretensão e prepotência. Seja ambicioso, mas com humildade.

É isso mesmo, o que você falou Jothaz agora realmente é isso mesmo e a maioria das pessoas que fazem essas consultas atrás de "receitas de bolo" são iniciantes na programação, não coloco toda a culpa neles, coloco também em alguns professores de faculdade que acostumam os alunos ao nosso famoso CTRL + V e CTRL + C, é triste, eu mesmo quando ia para as aulas, ficava louco quando professor passava um desafio, e o pessoal acostumado ao copiar e colar, ficava perdido sem saber para onde ir, sem entender, muitas vezes, nem o que o professor pediu, mas mesmo assim eles achavam que não precisavam estudar, por que provavelmente pensavam que na carreira de programador, eles iriam encontrar tudo como acontecia nas aulas.

Já faz uns 3 ou 4 anos, desde quando assistia às aulas, mas converso com muita gente, e percebo que ainda hoje acontece.

Faço das suas palavra a minha Edson.