Sabemos que nesse ramo de trabalho as coisas mudam muito rápido , e de uma forma bem drásticas.Paradigmas caem a todo instante , com a mesma velocidade que são criados.Semana passada um professor da faculdade abordou o assunto , e houve uma grande discussão , uns acham que o futuro e obscuro , pois hoje já tem muita coisa pronta , frameworks exigem cada vez menos programação , e consequente menos conhecimento tecnico.Em contra partida , tiveram outras que argumentaram que o que pode acontecer e a profissão mudar drasticamente , mais que nunca deixara de existir , pois a programação envolve mais coisas do que simplesmente codigo. Confesso que fiquei completamente em cima do muro , vi argumentos bem consistentes em ambas situações , mais pendo mais para o lado da mudança. Recentemente li o livro codigo limpo , que tinha um pequeno trecho que abordava sobre o assunto , e falava justamente sobre o essa mudança.Agora a opinião de vocês , a programação vai morrer?!Ou vai simplesmente mudar?!
Futuro do desenvolvimento ,sera que ainda vai existir nos próximos anos?!
53 Respostas
Possivelmente mude, mas não acabará. Há anos o Delphi já tinha um ORM. Anos depois tivemos o “clica e arrasta” do ASP.Net Web Forms que foi substituído pelos Html Helper do ASP.Net MVC (quem conhece Web Forms e MVC sabe que hoje está escrevendo mais código que antigamente).
A maioria dos grandes problemas computacionais (semáforos, ordenação, acesso ao disco, entre outros) já foram resolvidos antes mesmo dos anos 90, mas ainda assim precisamos escrever código-fonte para implementar as diferentes regras de negócio que existem (afinal, é o software que deve se adequar ao negócio do cliente, e não o contrário). Ao meu ver, soa como uma piada a criação de um componente capaz de implementar regras de negócio com a mera configuração de propriedades.
Pense comigo: novas formas de fazer negócio surgem e desaparecem todos os dias. Hoje há um cálculo para tal imposto, amanhã podem aparecer 10 novos cálculos para impostos diferentes, e o contrário também pode facilmente ocorrer. A empresa A segue uma lista de 10 passos para armazenar seu estoque, já a empresa B segue uma lista de 50 passos para manter seu estoque. E onde nós entramos nessa história? Não podemos esquecer que nós, como desenvolvedores, estamos na retaguarda disso tudo. Nós devemos desenvolver soluções customizadas e adaptadas para cada forma de negócio. Enquanto o mercado for diverso, nós estaremos lá para implementar as suas particularidades. Portanto acho que não, o programador nunca deixará de existir.
Vocês conhecem Cobol ou já ouviram falar? Alguns que profetizaram o seu fim já nos deixaram, mas um desenvolvedor Cobol continua tendo trabalho e é muito valorizado.
É claro que a área vai continuar evoluindo e se modificando, mas, pode ficar tranquilo, desenvolvimento vai continuar existindo.
Vai continuar com certeza, vai evoluir muito e vai continuar, só tende a crescer muito, empresas, eletrônicos, a tecnologia precisa de programação. Precisamos dizer pra máquina o que ela deve fazer, e mesmo que a inteligência artificial evolua muito, ainda teremos que programar a inteligência artificial.
Possivelmente mude, mas não acabará. Há anos o Delphi já tinha um ORM. Anos depois tivemos o “clica e arrasta” do ASP.Net Web Forms que foi substituído pelos Html Helper do ASP.Net MVC (quem conhece Web Forms e MVC sabe que hoje está escrevendo mais código que antigamente).A maioria dos grandes problemas computacionais (semáforos, ordenação, acesso ao disco, entre outros) já foram resolvidos antes mesmo dos anos 90, mas ainda assim precisamos escrever código-fonte para implementar as diferentes regras de negócio que existem (afinal, é o software que deve se adequar ao negócio do cliente, e não o contrário). Ao meu ver, soa como uma piada a criação de um componente capaz de implementar regras de negócio com a mera configuração de propriedades.
Pense comigo: novas formas de fazer negócio surgem e desaparecem todos os dias. Hoje há um cálculo para tal imposto, amanhã podem aparecer 10 novos cálculos para impostos diferentes, e o contrário também pode facilmente ocorrer. A empresa A segue uma lista de 10 passos para armazenar seu estoque, já a empresa B segue uma lista de 50 passos para manter seu estoque. E onde nós entramos nessa história? Não podemos esquecer que nós, como desenvolvedores, estamos na retaguarda disso tudo. Nós devemos desenvolver soluções customizadas e adaptadas para cada forma de negócio. Enquanto o mercado for diverso, nós estaremos lá para implementar as suas particularidades. Portanto acho que não, o programador nunca deixará de existir.
Perfeito.
Hoje escrevo muito mais código do que no tempo que programava desktop em Delphi.
Infelizmente, não vejo grandes mudanças num futuro próximo.
E digo infelizmente, pois realmente gostaria de ver ferramentas mais poderosas surgindo.
Um bom vídeo para refletir sobre isso:
Infelizmente, não vejo grandes mudanças num futuro próximo.E digo infelizmente, pois realmente gostaria de ver ferramentas mais poderosas surgindo.
Isso não ocorre devido a natureza da web, seja internet ou intranet, onde a maioria dos sistemas são voltados hoje. No tempo que desktop estava em alta era natural trabalhar de forma RAD, mas para web RAD atrapalha. Como foi o caso do que o Júlio Murta falou do Web Forms. Outros exemplos são ADF e JSF com “Java Studio Creator”/NetBeans 6 ou similares. Sem falar nas soluções polêmicas completamente amarradas, com prática dependente de terceiro para criar aplicações sem codificação, que nem vale citar nomes para não atrair pessoas contratadas em defender interesses comerciais.
Eu concordo com quase tudo o que disse. Hoje, para desenvolver para web é bem mais comum escrever código na mão do que usar algum tipo de ferramenta RAD.
Mas já parou pra pensar, o motivo disso? Por que pra Desktop funcionava e pra Web não?
Acho essa situação similar ao do pessoal que preferia binário a assembly e assembly a fortran, mostrada no vídeo.
Claro que, hoje não há nenhuma boa ferramenta para fazer isso (que eu conheça)… mas por que estamos descartando o conceito inteiramente?
Eu concordo com quase tudo o que disse. Hoje, para desenvolver para web é bem mais comum escrever código na mão do que usar algum tipo de ferramenta RAD.
Mas já parou pra pensar, o motivo disso? Por que pra Desktop funcionava e pra Web não?
Acho essa situação similar ao do pessoal que preferia binário a assembly e assembly a fortran, mostrada no vídeo.
Claro que, hoje não há nenhuma boa ferramenta para fazer isso (que eu conheça)… mas por que estamos descartando o conceito inteiramente?
Boa pergunta, por que nao ?
E falando sobre essas mudanças , conversando com um amigo que ja tem seus 20 anos nesse ramo , me falou que aconteceu algo parecido quando o delphi surgiu , todos achavam que era o fim , tamanha a facilidade da ferramenta,mais como constatamos nao foi isso que aconteceu , apesar da tentativa, parece que o delphi nao se adequou a realidade dessa decada, e toda sua mobilidade.
E que voces acham de frameworks como , rails , cakephp , ou o grovy?Talvez esse seja o futuro , menos codigo e mais negocio?
obs:Como eu to começando agora sempre me surgem essas duvidas , ainda to na busca do estagio.obd
Eu concordo com quase tudo o que disse. Hoje, para desenvolver para web é bem mais comum escrever código na mão do que usar algum tipo de ferramenta RAD.
Mas já parou pra pensar, o motivo disso? Por que pra Desktop funcionava e pra Web não?
Acho essa situação similar ao do pessoal que preferia binário a assembly e assembly a fortran, mostrada no vídeo.
Claro que, hoje não há nenhuma boa ferramenta para fazer isso (que eu conheça)… mas por que estamos descartando o conceito inteiramente?
Eu concordo com quase tudo o que disse. Hoje, para desenvolver para web é bem mais comum escrever código na mão do que usar algum tipo de ferramenta RAD.
Mas já parou pra pensar, o motivo disso? Por que pra Desktop funcionava e pra Web não?
Acho essa situação similar ao do pessoal que preferia binário a assembly e assembly a fortran, mostrada no vídeo.
Claro que, hoje não há nenhuma boa ferramenta para fazer isso (que eu conheça)… mas por que estamos descartando o conceito inteiramente?
Certamente eu gostaria de escrever menos código, eu nasci na era RAD e entregava mais soluções para o negócio em menos tempo. Mas tenho consciência que nos tempos de hoje voltado para web e suas firulas infinitas, como você falou “não existe ainda uma boa ferramenta”, que seja flexível em todos os momentos do projeto e que não dê maus motivos para dividir opiniões, ou seja, com plena aceitação não só na comunidade Java (por exemplo), senão acontece de ver webdesigners xingando projetos em JSF ou WebForms como já vi.
O grande lance hoje é que a parte de frontend está ficando cada vez mais complexa e mais longe do backend, e como ter uma ferramenta CASE que acompanhe e lide bem com isso? Então o que tem surgido, além do designer que já era comum, é ter mais pessoas focadas em codificação client, o tal “desenvolvedor frontend”, e nós “macacos velhos” ficarmos mais com o backend, claro que trabalhando sempre juntos, ambos sabendo mexer nas pontas de cada lado e entendendo de todo o negócio, para atingir o objetivo que é comum.
Fica sem emprego quem aprende SOMENTE[u] as ferramentas, porque estas nascem e morrem todo dia. Há um tempo atrás, ferramentas como Clipper, Delphi e VB eram ensinadas como “informática avançada”, e não como ferramentas de desenvolvimento. O resultado é que quem sabia somente a ferramenta ficou para trás. Quem realmente entendia de programação, estruturas de dados, banco de dados relacionais, redes, etc. adaptou-se. Conheço vários profissionais que começaram com Clipper, Delphi e outras ferramentas mais antigas e que hoje em dia mandam muito bem com Java.
Enfim, acho que seja completamente natural que surjam ferramentas para que usuários comuns criem seus próprios aplicativos Web, Mobile e até games. Atualmente eu utilizo uma plataforma que me permite criar CRUDs na Web sem digitar uma linha de código. E aí fica a pergunta, você seria capaz de criar uma ferramentas dessas ? Saberia pelo menos por onde começar ?
Fica sem emprego quem aprende SOMENTE[u] as ferramentas, porque estas nascem e morrem todo dia. Há um tempo atrás, ferramentas como Clipper, Delphi e VB eram ensinadas como “informática avançada”, e não como ferramentas de desenvolvimento. O resultado é que quem sabia somente a ferramenta ficou para trás. Quem realmente entendia de programação, estruturas de dados, banco de dados relacionais, redes, etc. adaptou-se. Conheço vários profissionais que começaram com Clipper, Delphi e outras ferramentas mais antigas e que hoje em dia mandam muito bem com Java.Enfim, acho que seja completamente natural que surjam ferramentas para que usuários comuns criem seus próprios aplicativos Web, Mobile e até games. Atualmente eu utilizo uma plataforma que me permite criar CRUDs na Web sem digitar uma linha de código. E aí fica a pergunta, você seria capaz de criar uma ferramentas dessas ? Saberia pelo menos por onde começar ?
Com certeza eu jamais me atreveria a criar soluções mágicas para a web hoje. A criatividade dos webdesigners e pitacos dos clientes olhando grandes sites/sistemas estão fora do comum… Mas se está se referindo a CRUDs genericos seguindo um padrão, isso é o menor dos problemas, mas templates já resolvem, pelo menos no caso do Visual Studio. Problema mesmo são telas não triviais relativas ao dia a dia do fluxo do negócio.
Faz só 18 anos que escuto esse papo de que o programador vai se extinguir. Ironicamente, hoje vejo as tecnologias indo no sentido inverso.
O que o clica e arrasta do Delphi, do VB e do WebForms ensinaram é que não se pode limitar tanto o desenvolvimento para aplicações de grande porte. O programador precisa de poder, e precisa que isso esteja ao seu lado.
Veja um framework MVC hoje, e as tendências modernas de desenvolvimento: Frameworks como AngularJS não vem mais com a proposta de tudo pronto, e dão aos programadores mais facilidade para escrever seus próprios componentes com JavaScript, seu próprio CSS e ter liberdade para criarem o que quiserem. O próprio padrão MVC exige um profissional muito mais especializado do que o antigo modelo clica-e-arrasta, quando tentavam emular a orientação a eventos do desktop no PC - na verdade, o MVC dá estrutura para você ter é um conjunto de desenvolvedores, especializados em áreas diferentes (interface gráfica, middleware, banco de dados) - por isso parece até um tanto excessivo quando fazemos trabalhos sobre ele sozinhos na faculdade.
E não estou nem entrando no mérito das novas especialidades requeridas pelo desenvolvimento assíncrono.
Frameworks para desktop novos, como JavaFX, estão exigindo programadores com mais conhecimento gráfico, pois aumentou-se a demanda por interfaces mais responsivas e bonitas.
E, claro, sempre haverá mercado para quem gosta de desenvolver o framework em si, trabalhar com tempo real e atuar em softwares que exploram os limites do hardware.
O que está ficando cada vez menos valorizado é o “CRUDeiro”. O cara que faz o feijão com arroz. Esse profissional já perdeu valor desde a época do Delphi, e não seria diferente na web. Informática é uma área que exige especialização, e que exige que os profissionais sejam competentes. Se quiser ser crudeiro, prepare-se para enfrentar a concorrência de gente pouco qualificada que vai conseguir fazer software entendendo pouco e usando ferramentas.
Nessa questão de ser generalista ou especialista, eu penso que ninguém deve ser generalista demais, ou seja, que não tenha um conhecimento mais profundo em algumas áreas, e que um especialista não acompanhe as tecnologias emergentes.
Agora, ficar entre esses limites, significa escolher que faixa de funções vai poder ocupar e com quem ou quantos vai concorrer. O que não pode é depois ficar reclamando da faixa salarial que o mercado estiver pagando para o cargo.
Server side nem é a grande questão, todos esses frameworks que você citou são tranquilos portanto que a equipe em média seja madura na utilização da tecnologia. Além desses, ASP.NET MVC é produtivo e flexível também, tenho usado pra valer tem uns 4 anos e é muito objetivo. No Java o que me agrada mais é Spring MVC. Muitos também partem para a solucao totalmente desacoplada com REST, mas para mim nos projetos atuais que trabalho é totalmente fora de necessidade, REST somente quando necessário criar um serviço para outro sistema usar.
O lado client que é a “parada”, onde as necessidades ficaram mais complexas. Existe muita coisa para facilitar dependendo da situação, como frameworks JavaScritpt que simplificam a parte dinâmica do HTML, a qual uso Knockoutjs, e soluções como o Bootstrap que ajudam na parte de CSS relacionada a layout de formulários. Como ViniGodoy falou, nada disso vai na direção da proposta de “tudo pronto”, mas conforme a demanda você vai enriquecendo sua “biblioteca” com soluções a serem reaproveitadas no projeto.
Boa noite galera , a gente falou tanto do delphi que fiquei curioso de como esta hoje , sei que para desktop ainda tem muito softwares rodando , agora como esta para os dipositivos mais atuais , comentando com um amigo ele me citou o Delphi XE5 , do que se trata?
Eu tenho dois amigos desenvolvedores Delphi e ambos estão querendo atuar com outras tecnologia. Até conheci um desenvolvedor Delphi Sênior durante um treinamento de .Net dizendo que não vale a pena desenvolver mais nada em Delphi. Acho melhor você buscar por outras tecnologias.
O Delphi está sendo descontinuado desde que a Borland abriu mão da IDE. É um mercado decrescendo.
Vocês conhecem Cobol ou já ouviram falar? Alguns que profetizaram o seu fim já nos deixaram, mas um desenvolvedor Cobol continua tendo trabalho e é muito valorizado.
É claro que a área vai continuar evoluindo e se modificando, mas, pode ficar tranquilo, desenvolvimento vai continuar existindo.
Tu realmente conhece alguém ou empresa que ainda desenvolve sistemas em COBOL? rs
Eu concordo com quase tudo o que disse. Hoje, para desenvolver para web é bem mais comum escrever código na mão do que usar algum tipo de ferramenta RAD.
Mas já parou pra pensar, o motivo disso? Por que pra Desktop funcionava e pra Web não?
Acho essa situação similar ao do pessoal que preferia binário a assembly e assembly a fortran, mostrada no vídeo.
Claro que, hoje não há nenhuma boa ferramenta para fazer isso (que eu conheça)… mas por que estamos descartando o conceito inteiramente?
Por que o conceito em si é furado. A web não é ambiente de desenvolvimento.
Tu realmente conhece alguém ou empresa que ainda desenvolve sistemas em COBOL? rs
Todos os grandes bancos do Brasil usam Cobol, e por conta disso, demandam muita mão de obra para manutenção de legado e desenvolvimento de novos sistemas. Onde eu trabalho, por exemplo, há mais desenvolvedores Cobol do que Java (e há mais desenvolvedores C do que ambos juntos :))
Certamente eu gostaria de escrever menos código, eu nasci na era RAD e entregava mais soluções para o negócio em menos tempo. Mas tenho consciência que nos tempos de hoje voltado para web e suas firulas infinitas, como você falou “não existe ainda uma boa ferramenta”, que seja flexível em todos os momentos do projeto e que não dê maus motivos para dividir opiniões, ou seja, com plena aceitação não só na comunidade Java (por exemplo), senão acontece de ver webdesigners xingando projetos em JSF ou WebForms como já vi.
O grande lance hoje é que a parte de frontend está ficando cada vez mais complexa e mais longe do backend, e como ter uma ferramenta CASE que acompanhe e lide bem com isso? Então o que tem surgido, além do designer que já era comum, é ter mais pessoas focadas em codificação client, o tal “desenvolvedor frontend”, e nós “macacos velhos” ficarmos mais com o backend, claro que trabalhando sempre juntos, ambos sabendo mexer nas pontas de cada lado e entendendo de todo o negócio, para atingir o objetivo que é comum.
As empresas que preferem especializar por que é mais atraente pra elas, desenvolvimento frontend e backend estão cada vez mais simples, e não complexo.
Vocês conhecem Cobol ou já ouviram falar? Alguns que profetizaram o seu fim já nos deixaram, mas um desenvolvedor Cobol continua tendo trabalho e é muito valorizado.
É claro que a área vai continuar evoluindo e se modificando, mas, pode ficar tranquilo, desenvolvimento vai continuar existindo.Tu realmente conhece alguém ou empresa que ainda desenvolve sistemas em COBOL? rs
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.
Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
O kicolobo escreveu um post interessante hoje, vai de encontro ao tema:
Tu realmente conhece alguém ou empresa que ainda desenvolve sistemas em COBOL? rs
Todos os grandes bancos do Brasil usam Cobol, e por conta disso, demandam muita mão de obra para manutenção de legado e desenvolvimento de novos sistemas. Onde eu trabalho, por exemplo, há mais desenvolvedores Cobol do que Java (e há mais desenvolvedores C do que ambos juntos :))
Dinossauros. kkk
Isso explica porque bancos estão com o sistema sempre fora do ar.
Tu realmente conhece alguém ou empresa que ainda desenvolve sistemas em COBOL? rs
Todos os grandes bancos do Brasil usam Cobol, e por conta disso, demandam muita mão de obra para manutenção de legado e desenvolvimento de novos sistemas. Onde eu trabalho, por exemplo, há mais desenvolvedores Cobol do que Java (e há mais desenvolvedores C do que ambos juntos :))Dinossauros. kkk
Isso explica porque bancos estão com o sistema sempre fora do ar.
Cara, não fala bobagem, o que pode cair são sistemas periféricos como sites e caixas eletrônicos. Os sistemas de transações bancárias dificilmente falham.
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
ah, sim. Concordo que desenvolvimento não vai deixar de existir. Mas desenvolvimento COBOL acho que já não existe mais, portanto pra desenvolvedores não é exagero COBOL ser considerada morta.
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
ah, sim. Concordo que desenvolvimento não vai deixar de existir. Mas desenvolvimento COBOL acho que já não existe mais, portanto pra desenvolvedores não é exagero COBOL ser considerada morta.
Morta é quando não se usa mais. Cobol continua muito vivo, com milhões de linhas de código, rodando diuturnamente em máquinas gigantes.
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
ah, sim. Concordo que desenvolvimento não vai deixar de existir. Mas desenvolvimento COBOL acho que já não existe mais, portanto pra desenvolvedores não é exagero COBOL ser considerada morta.
Queria que o Java ou qualquer outra linguagem contemporânea estivesse tão “morto” como COBOL. Vi que citaram um texto meu aqui (http://www.itexto.net/devkico/?p=1799). É exatamente o que digo: não se deixe levar pela imagem que feiras, revistas e sites nos expõe do REAL mercado de desenvolvimento. A coisa é muito mais ampla, e por mais estranho que pode parecer, Javeiro, dotneteiro, nodeiro e cia são minoria (e ainda bem).
COBOL tem apenas 55 anos de otimizações de história. É uma das linguagens mais fáceis de entender (foi o objetivo CORE da linguagem) e é responsável por boa parte do que você faz hoje e não se da conta. Foi ao banco? COBOL. Comprou passagens? COBOL. Tá indo para um hospital ou pagar seus impostos? COBOL. Alugou um carro? COBOL. E por aí vai.
A diferença é que são o que chamo de “programadores invisíveis”. São estes os caras que realmente geram valor com desenvolvimento. A diferença é que não querem ou precisam aparecer em blogs, revistas, palestras, etc. Eles vão trabalhar, ENTREGAM, geram valor (foco nisto sempre) e vão para casa tranquilos viverem suas vidas rindo de gente que diz ter sua tecnologia morrido simplesmente por ser ignorante o suficiente para não saber do que realmente rola.
E vou dizer mais: não é só COBOL. Outro gigante que todo mundo faz desdém se chama VBA. Sim, você tem ele no seu Word ou Excel, basta pressionar Alt + F11 que ele aparece. Dica: sei de primeira mão (participei disto) que mineiração no Brasil rod em cima disto. E detalhe: roda BEM e forte. Outro aliás: por que será que o Office vende tanto? Será que é só pelo Word e Excel? Quem realmente compra Office são empresas. O que elas realmente querem com ele? VBA
Link interessante: COBOL no Brasil domina - http://www.zdnet.com/cobol-is-alive-and-kicking-in-brazil-[telefone removido]/
Outro ponto: a Gartner fez um estudo recente que mostra que 70% do código transacional do mundo é escrito em… COBOL.
Citando nosso amigo Cumpadre Washington: “sabe nada… inocente. Tu tu tu pá!” 
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
ah, sim. Concordo que desenvolvimento não vai deixar de existir. Mas desenvolvimento COBOL acho que já não existe mais, portanto pra desenvolvedores não é exagero COBOL ser considerada morta.
Morta é quando não se usa mais. Cobol continua muito vivo, com milhões de linhas de código, rodando diuturnamente em máquinas gigantes.
Desenvolvedor não usa mais se novos projetos não são iniciados.
O que não quer dizer que esteja morto para os dinossauros, nesse ponto concordo com vc.
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
ah, sim. Concordo que desenvolvimento não vai deixar de existir. Mas desenvolvimento COBOL acho que já não existe mais, portanto pra desenvolvedores não é exagero COBOL ser considerada morta.
Morta é quando não se usa mais. Cobol continua muito vivo, com milhões de linhas de código, rodando diuturnamente em máquinas gigantes.
Desenvolvedor não usa mais se novos projetos não são iniciados.
O que não quer dizer que esteja morto para os dinossauros, nesse ponto concordo com vc.
Novos projetos que você, com sua visão limitada do mundo vê, certo?
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
ah, sim. Concordo que desenvolvimento não vai deixar de existir. Mas desenvolvimento COBOL acho que já não existe mais, portanto pra desenvolvedores não é exagero COBOL ser considerada morta.
Queria que o Java ou qualquer outra linguagem contemporânea estivesse tão “morto” como COBOL. Vi que citaram um texto meu aqui (http://www.itexto.net/devkico/?p=1799). É exatamente o que digo: não se deixe levar pela imagem que feiras, revistas e sites nos expõe do REAL mercado de desenvolvimento. A coisa é muito mais ampla, e por mais estranho que pode parecer, Javeiro, dotneteiro, nodeiro e cia são minoria (e ainda bem).
COBOL tem apenas 55 anos de otimizações de história. É uma das linguagens mais fáceis de entender (foi o objetivo CORE da linguagem) e é responsável por boa parte do que você faz hoje e não se da conta. Foi ao banco? COBOL. Comprou passagens? COBOL. Tá indo para um hospital ou pagar seus impostos? COBOL. Alugou um carro? COBOL. E por aí vai.
A diferença é que são o que chamo de “programadores invisíveis”. São estes os caras que realmente geram valor com desenvolvimento. A diferença é que não querem ou precisam aparecer em blogs, revistas, palestras, etc. Eles vão trabalhar, ENTREGAM, geram valor (foco nisto sempre) e vão para casa tranquilos viverem suas vidas rindo de gente que diz ter sua tecnologia morrido simplesmente por ser ignorante o suficiente para não saber do que realmente rola.
E vou dizer mais: não é só COBOL. Outro gigante que todo mundo faz desdém se chama VBA. Sim, você tem ele no seu Word ou Excel, basta pressionar Alt + F11 que ele aparece. Dica: sei de primeira mão (participei disto) que mineiração no Brasil rod em cima disto. E detalhe: roda BEM e forte. Outro aliás: por que será que o Office vende tanto? Será que é só pelo Word e Excel? Quem realmente compra Office são empresas. O que elas realmente querem com ele? VBA
Link interessante: COBOL no Brasil domina - http://www.zdnet.com/cobol-is-alive-and-kicking-in-brazil-[telefone removido]/
Outro ponto: a Gartner fez um estudo recente que mostra que 70% do código transacional do mundo é escrito em… COBOL.Citando nosso amigo Cumpadre Washington: “sabe nada… inocente. Tu tu tu pá!” :)
Não. COBOL é ainda usado por dinossauros porque é a única coisa capaz de rodar no hardware que essas empresas investiram décadas atrás. Elas foram vítimas de algo chamado de vendor lockin, bastante comum no mercado de mainframes.
Desculpa, a idéia que COBOL é usado por causa de um exercito de programadores “invisíveis” que geram mais valor do que programadores “normais” é interessante, mas não passa de uma visão romântica da realidade. 
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
ah, sim. Concordo que desenvolvimento não vai deixar de existir. Mas desenvolvimento COBOL acho que já não existe mais, portanto pra desenvolvedores não é exagero COBOL ser considerada morta.
Morta é quando não se usa mais. Cobol continua muito vivo, com milhões de linhas de código, rodando diuturnamente em máquinas gigantes.
Desenvolvedor não usa mais se novos projetos não são iniciados.
O que não quer dizer que esteja morto para os dinossauros, nesse ponto concordo com vc.
Novos projetos que você, com sua visão limitada do mundo vê, certo?
Cobol sempre foi uma ferramenta corporativa de grande porte, devido ao ambiente operacional a que se destina.
Então um desenvolvedor típico, nem tem ideia do que isso significa.
Exato. Um desenvolvedor moderno não tem mainframe em casa pra rodar programas em COBOL.
Exato. Um desenvolvedor moderno não tem mainframe em casa pra rodar programas em COBOL.
Este argumento é excelente: “nunca vi então não existe”
Não. COBOL é ainda usado por dinossauros porque é a única coisa capaz de rodar no hardware que essas empresas investiram décadas atrás. Elas foram vítimas de algo chamado de vendor lockin, bastante comum no mercado de mainframes.Desculpa, a idéia que COBOL é usado por causa de um exercito de programadores “invisíveis” que geram mais valor do que programadores “normais” é interessante, mas não passa de uma visão romântica da realidade. :D
O problema nunca foi hardware (tirando a época da reserva de mercado) e sim software. Reescrever todo o software legado de décadas de desenvolvimento ainda esbarra no tripé custo/benefício/viabilidade.
Embora eu ache (aqui é “achismo” mesmo, não tenho números) que essa situação esteja chegando ao limite, logo logo não teremos mais tantos coboleiros para continuar dando continuidade nisso…
As pessoas esquecem que existem simuladores.
Não disse isso, citei o Cobol como exemplo de uma tecnologia considerada morta, mas que os profissionais que trabalham com ela ainda são procurados e são bem pagos.
Projetos legados e complementos continuam sendo mantidos sem problemas.Quanto ao trecho que você destacou, foi em relação à pergunta do tópico.
ah, sim. Concordo que desenvolvimento não vai deixar de existir. Mas desenvolvimento COBOL acho que já não existe mais, portanto pra desenvolvedores não é exagero COBOL ser considerada morta.
Queria que o Java ou qualquer outra linguagem contemporânea estivesse tão “morto” como COBOL. Vi que citaram um texto meu aqui (http://www.itexto.net/devkico/?p=1799). É exatamente o que digo: não se deixe levar pela imagem que feiras, revistas e sites nos expõe do REAL mercado de desenvolvimento. A coisa é muito mais ampla, e por mais estranho que pode parecer, Javeiro, dotneteiro, nodeiro e cia são minoria (e ainda bem).
COBOL tem apenas 55 anos de otimizações de história. É uma das linguagens mais fáceis de entender (foi o objetivo CORE da linguagem) e é responsável por boa parte do que você faz hoje e não se da conta. Foi ao banco? COBOL. Comprou passagens? COBOL. Tá indo para um hospital ou pagar seus impostos? COBOL. Alugou um carro? COBOL. E por aí vai.
A diferença é que são o que chamo de “programadores invisíveis”. São estes os caras que realmente geram valor com desenvolvimento. A diferença é que não querem ou precisam aparecer em blogs, revistas, palestras, etc. Eles vão trabalhar, ENTREGAM, geram valor (foco nisto sempre) e vão para casa tranquilos viverem suas vidas rindo de gente que diz ter sua tecnologia morrido simplesmente por ser ignorante o suficiente para não saber do que realmente rola.
E vou dizer mais: não é só COBOL. Outro gigante que todo mundo faz desdém se chama VBA. Sim, você tem ele no seu Word ou Excel, basta pressionar Alt + F11 que ele aparece. Dica: sei de primeira mão (participei disto) que mineiração no Brasil rod em cima disto. E detalhe: roda BEM e forte. Outro aliás: por que será que o Office vende tanto? Será que é só pelo Word e Excel? Quem realmente compra Office são empresas. O que elas realmente querem com ele? VBA
Link interessante: COBOL no Brasil domina - http://www.zdnet.com/cobol-is-alive-and-kicking-in-brazil-[telefone removido]/
Outro ponto: a Gartner fez um estudo recente que mostra que 70% do código transacional do mundo é escrito em… COBOL.Citando nosso amigo Cumpadre Washington: “sabe nada… inocente. Tu tu tu pá!” :)
Não. COBOL é ainda usado por dinossauros porque é a única coisa capaz de rodar no hardware que essas empresas investiram décadas atrás. Elas foram vítimas de algo chamado de vendor lockin, bastante comum no mercado de mainframes.
Desculpa, a idéia que COBOL é usado por causa de um exercito de programadores “invisíveis” que geram mais valor do que programadores “normais” é interessante, mas não passa de uma visão romântica da realidade. :D
Não leve como ofensa, mas a sua visão é totalmente discordante da realidade…
Acredito que você nunca tenha trabalhado em uma empresa que tem programadores COBOL, e se trabalhou, deve ter pego clientes muito azarados.
Aqui onde trabalho atendemos diversas instituições bancárias que continuam utilizando COBOL há décadas. E não por causa do tal vendor lockin, mas sim pelo simples fato de que a solução quase sexagenária continua atendendo, mesmo com toda a escalada de usuários e disponibilidade, as suluções COBOL continuam atendendo na disponibilidade e confiabilidade que eles precisam.
É simples! Ou você acredita mesmo que empresas multinacionais que continuam rodando software em COBOL realmente estão travados no tal vendor lockin?
A questão principal é que até não sairia tão caro modernizar tais aplicativos. Mas o custo mesmo que baixo não compensa, se ainda existem programadores dispostos a codificar em COBOL.
Eu concordo com quase tudo o que disse. Hoje, para desenvolver para web é bem mais comum escrever código na mão do que usar algum tipo de ferramenta RAD.
Mas já parou pra pensar, o motivo disso? Por que pra Desktop funcionava e pra Web não?
Acho essa situação similar ao do pessoal que preferia binário a assembly e assembly a fortran, mostrada no vídeo.
Claro que, hoje não há nenhuma boa ferramenta para fazer isso (que eu conheça)… mas por que estamos descartando o conceito inteiramente?
Por que o conceito em si é furado. A web não é ambiente de desenvolvimento.
Concordo que HTML não foi feito para sistemas. As evoluções em torno do HTML5 foram muito bem vindas para melhorar isso, só que naturalmente não nasceu mesmo para isso. Mas como o mundo se voltou para a mobilidade e facilidade de acesso aos sistemas via browser, temos que atender este cenário da melhor forma possível, razões técnicas isoladas nem sempre vencem.
Certamente eu gostaria de escrever menos código, eu nasci na era RAD e entregava mais soluções para o negócio em menos tempo. Mas tenho consciência que nos tempos de hoje voltado para web e suas firulas infinitas, como você falou “não existe ainda uma boa ferramenta”, que seja flexível em todos os momentos do projeto e que não dê maus motivos para dividir opiniões, ou seja, com plena aceitação não só na comunidade Java (por exemplo), senão acontece de ver webdesigners xingando projetos em JSF ou WebForms como já vi.
O grande lance hoje é que a parte de frontend está ficando cada vez mais complexa e mais longe do backend, e como ter uma ferramenta CASE que acompanhe e lide bem com isso? Então o que tem surgido, além do designer que já era comum, é ter mais pessoas focadas em codificação client, o tal “desenvolvedor frontend”, e nós “macacos velhos” ficarmos mais com o backend, claro que trabalhando sempre juntos, ambos sabendo mexer nas pontas de cada lado e entendendo de todo o negócio, para atingir o objetivo que é comum.
As empresas que preferem especializar por que é mais atraente pra elas, desenvolvimento frontend e backend estão cada vez mais simples, e não complexo.
Quanto a backend com certeza ficou mais simples. Só não consegui entender essa colocação quanto a frontend, ainda mais pela sua resposta acima, pois quando algo não é projetado para tal coisa, traz dificuldades técnicas para que o resultado final seja bom. Você não acha que as interfaces gráficas web hoje exigem conhecimento de mais conceitos e recursos técnicos? Lembre-se como era a 10 anos atrás e como hoje aumentou o nível de riqueza e interação, buscando melhor experiência do usuário, etc.
Não leve como ofensa, mas a sua visão é totalmente discordante da realidade…Acredito que você nunca tenha trabalhado em uma empresa que tem programadores COBOL, e se trabalhou, deve ter pego clientes muito azarados.
Aqui onde trabalho atendemos diversas instituições bancárias que continuam utilizando COBOL há décadas. E não por causa do tal vendor lockin, mas sim pelo simples fato de que a solução quase sexagenária continua atendendo, mesmo com toda a escalada de usuários e disponibilidade, as suluções COBOL continuam atendendo na disponibilidade e confiabilidade que eles precisam.
É simples! Ou você acredita mesmo que empresas multinacionais que continuam rodando software em COBOL realmente estão travados no tal vendor lockin?
Vendor lockin pode ser ruim ou uma ótima fonte de receita. Depende se você é quem está travado ou com a posse da chave. 
A questão principal é que até não sairia tão caro modernizar tais aplicativos. Mas o custo mesmo que baixo não compensa, se ainda existem programadores dispostos a codificar em COBOL.
Dinossauros não mudam, eles são extintos.
Ainda que existam, eu não apostaria minha carreira em uma linguagem onde praticamente não há novos desenvolvimentos. Basta pegar o jornal e ver o número de vagas ofertadas para COBOL, Delphi e afins…
Quanto a backend com certeza ficou mais simples. Só não consegui entender essa colocação quanto a frontend, ainda mais pela sua resposta acima, pois quando algo não é projetado para tal coisa, traz dificuldades técnicas para que o resultado final seja bom. Você não acha que as interfaces gráficas web hoje exigem conhecimento de mais conceitos e recursos técnicos?
Por que apps moveis são mais simples. frontend tende a ser mais focado em uma determinada tarefa, por isso possuem uma interface mais enxuta.
Obviamente estou falando de nativo. Sistemas web são mais complexos e tendem a cair no desuso.
Acho que é uma questão de opinião. Mas eu prefiro as interfaces web de 10 anos atras.
Quando entro em um site, eu quero acessar uma informação, não quero riqueza de gráficos ou de interações. Pra isso existem apps.
Mas se você pegar um jornal nem vagas em java e c# encontrará.
Mas se você pegar um jornal nem vagas em java e c# encontrará.
Acho que o Vini disse jornal no sentido figurado …
Bom, eu comparei alguns termos no CEVIU, e de fato, as vagas para Java disparam para mais 1000, enquanto vagas para COBOL eu encontrei no máximo umas 10.
Sobre assunto, o 1o capítulo do livro Passionate Programmer traz um exercício bastante interessante.
Quanto a backend com certeza ficou mais simples. Só não consegui entender essa colocação quanto a frontend, ainda mais pela sua resposta acima, pois quando algo não é projetado para tal coisa, traz dificuldades técnicas para que o resultado final seja bom. Você não acha que as interfaces gráficas web hoje exigem conhecimento de mais conceitos e recursos técnicos?Por que apps moveis são mais simples. frontend tende a ser mais focado em uma determinada tarefa, por isso possuem uma interface mais enxuta.
Obviamente estou falando de nativo.
Se você estava falando de aplicação nativa poderia ter especificado, realmente não tem o que discutir que interface nativa é mais simples de programar. Mas esse tipo de aplicação não atende a maioria dos casos atuais.
Sistemas web cair em desuso? Eu só vejo o inverso na prática.
Lembre-se de quem vai investir na aquisição do sistema não é você. Se para o cliente vai ser importante seus usuários acessando o sistema de qualquer lugar (incluindo PC), com interações importantes para a experiência de uso, então ir contra a necessidade seria engessar o processo.
Mas se você pegar um jornal nem vagas em java e c# encontrará.
Acho que o Vini disse jornal no sentido figurado …
Bom, eu comparei alguns termos no CEVIU, e de fato, as vagas para Java disparam para mais 1000, enquanto vagas para COBOL eu encontrei no máximo umas 10.
Sobre assunto, o 1o capítulo do livro Passionate Programmer traz um exercício bastante interessante.
eu sei, só quis bancar o bobo kk
Concordo.
Só citei o caso do Cobol para acalmar os alarmistas do fim do mundo, a “resiliência” do Cobol é impressionante.
Se você estava falando de aplicação nativa poderia ter especificado, realmente não tem o que discutir que interface nativa é mais simples de programar. Mas esse tipo de aplicação não atende a maioria dos casos atuais.
Mas vai atender com o tempo. Quando a idéia do frontend ficar longe do backend se consolidar. Aí o próximo passo será reduzir a complexidade. Quando nativo vai se consolidar ainda mais.
Faz parte da tendência que você apontou. Nem vou entrar no mérito se isso é bom ou ruim, é apenas um fato conhecido pelo fato de tudo em TI funcionar em ciclos, e o ciclo atual é nativo.
Sistemas web cair em desuso? Eu só vejo o inverso na prática.
Estou falando disso.
http://blog.flurry.com/bid/109749/Apps-Solidify-Leadership-Six-Years-into-the-Mobile-Revolution
Qualquer lugar roda aplicativos. Acho que só aquele chromebook do google que não roda, mas o mercado é tão pequeno que acho não faz diferença.
Mas se você pegar um jornal nem vagas em java e c# encontrará.
Acho que o Vini disse jornal no sentido figurado …
Bom, eu comparei alguns termos no CEVIU, e de fato, as vagas para Java disparam para mais 1000, enquanto vagas para COBOL eu encontrei no máximo umas 10.
Conte ainda com o fato que COBOL apenas não serve pra muita coisa. O programador precisa ter familiaridade com o SO que seu programa COBOL vai rodar.
Exato. Um desenvolvedor moderno não tem mainframe em casa pra rodar programas em COBOL.
Este argumento é excelente: “nunca vi então não existe” :D
Posta uma foto então.
Se você estava falando de aplicação nativa poderia ter especificado, realmente não tem o que discutir que interface nativa é mais simples de programar. Mas esse tipo de aplicação não atende a maioria dos casos atuais.Mas vai atender com o tempo. Quando a idéia do frontend ficar longe do backend se consolidar. Aí o próximo passo será reduzir a complexidade. Quando nativo vai se consolidar ainda mais.
Faz parte da tendência que você apontou. Nem vou entrar no mérito se isso é bom ou ruim, é apenas um fato conhecido pelo fato de tudo em TI funcionar em ciclos, e o ciclo atual é nativo.
Sistemas web cair em desuso? Eu só vejo o inverso na prática.
Estou falando disso.
http://blog.flurry.com/bid/109749/Apps-Solidify-Leadership-Six-Years-into-the-Mobile-Revolution
Qualquer lugar roda aplicativos. Acho que só aquele chromebook do google que não roda, mas o mercado é tão pequeno que acho não faz diferença.
Isso que você defende é só em relação a aplicações mobile. Tenho me referido a sistemas web rodando no browser, atendendo qualquer plataforma, seja PC clássico ou mobile.
Veja, não é defendendo, apenas apontando para onde a área de desenvolvimento está caminhando.
As empresas estão adotando tablets e smartphones em massa. A web vai ficar restrito apenas a interações simples, coisa que pode ser feito por um designer e um programador HTML.
não estou defendendo, apenas dizendo pra onde a área de desenvolvimento esta caminhando.
A tendência é as empresas adotarem tablets e smartphones em massa. A web vai ficar restrito apenas a interações simples, coisa que pode ser feito por um designer e um programador HTML/JS. Se você quer continuar apostando em javascript tudo bem, mas entenda que os trabalhos mais complexos (e com melhores salários) migrarão para desenvolvimento de aplicações usando SDK nativo.
Mas provavelmente teremos toda uma gama de serviços apoiando essas aplicações nativas não ?
ainda é MUITO mais produtivo utilizar computador comum que um smartphone, a onda mobile afetou muito pouco sistemas corporativos por esta razão, a maioria das pessoas trabalha de frente com o computador colocar um celular na mão somente atrasaria o desempenho.
Claro que em alguns casos há ganho, ter sistemas para pessoas que estão sempre se movimentando, que visitam bastante cliente, ai concordo que a versão mobile se destaca, mas em geral é nicho em ambiente corporativo