O excesso de confiança nas ferramentas implica que você é preguiçoso? [fechadas]

Comecei a programar em C ++ na uni e adorei. No próximo período, mudamos para VB6 e eu odiava.

Eu não sabia o que estava acontecendo, você arrasta um botão para um formulário e o ide escreve o código para você.

Embora eu odiasse o modo como o VB funcionava, não posso argumentar que era mais rápido e fácil do que fazer a mesma coisa em C ++, para que eu possa entender por que é uma linguagem popular.

Agora, não estou dizendo que os desenvolvedores do VB são preguiçosos em apenas dizer que são mais fáceis que o C ++ e notei que muitas linguagens mais recentes estão seguindo essa tendência como um c #.

Isso me leva a pensar que, à medida que mais negócios desejam resultados rápidos, mais pessoas irão programar assim e, mais cedo ou mais tarde, não haverá o que chamamos de programação agora. Os futuros programadores dirão ao computador o que desejam e o compilador escreverá o programa para eles como em Star Trek.

Isso é apenas uma opinião sub informada de um programador júnior ou os programadores estão ficando mais preguiçosos e menos competentes em geral?

EDIT: Muitas respostas dizem por que reinventar a roda e eu concordo com isso, mas quando há rodas disponíveis, as pessoas não estão se preocupando em aprender a fabricar a roda. Eu posso pesquisar no google como fazer praticamente qualquer coisa em qualquer idioma e metade dos idiomas fazer muito por você quando se trata de depuração, eles não têm idéia do que o código faz de como corrigir o erro.

É assim que eu defendo a teoria de que os programadores estão se tornando mais preguiçosos e menos competentes, pois ninguém se importa com o modo como as coisas funcionam, exatamente como funcionam até que não funcionem.

Não, os desenvolvedores não têm mais preguiça ou menos competência. Sim, há uma necessidade cada vez menor de desenvolvimento real, no sentido de que você o conhece. E sim, isso ocorre porque as empresas desejam resultados rápidos, e por que não deveriam?

No entanto, existe um ponto final. Sempre haverá a necessidade de alguns desenvolvedores.

Muitos requisitos são os mesmos em diferentes projetos. Você está falando sobre o código da interface do usuário. A maioria das UIs é composta de um conjunto específico de campos - caixa de texto, caixa de seleção, rádio, seleção etc. - e não há realmente nenhum sentido em desenvolvê-los do zero, repetidamente. Então, as camadas de abstração são colocadas para remover todo esse código padrão.

Da mesma forma, a camada de dados, que normalmente não passa de Inserir, Excluir, Substituir e um grande número de visualizações diferentes dos mesmos dados. Por que continuar escrevendo isso repetidamente? Vamos inventar ORMs.

A única coisa que você deve desenvolver é um código exclusivo para os negócios para os quais está desenvolvendo.

Mas sempre haverá essa singularidade - onde não houver, haverá uma oportunidade de negócios - e sempre haverá a necessidade de as pessoas escreverem código.

Tudo isso dito, também tenha em mente que há muito mais em ser desenvolvedor do que escrever código. Esteja você codificando em montagem pura ou reunindo componentes do Drupal para criar um site direcionado a conteúdo, você está traduzindo a necessidade comercial em algo que o computador entende.

A parte mais importante de ser desenvolvedor de software é entender o requisito de negócios suficientemente bem para explicá-lo ao computador.

Realmente não importa qual idioma você está usando para explicar as coisas para o computador, apenas importa o que você pode. E isso é trabalho duro, nada de preguiçoso.

Um mecânico é preguiçoso e menos competente porque está usando uma chave hidráulica ?

Imagem dois caras, digamos Brad e Pete. Ambos trabalham em duas garagens trocando pneus diariamente. Brad é um cara inteligente, ele sabe que o uso de ferramentas melhores pode fazer seu trabalho melhor e mais rapidamente. O uso da chave hidráulica o ajuda a trocar mais pneus. Os clientes estão esperando em uma fila mais curta - todo mundo está feliz. Bard também sabe que essa chave é às vezes grande demais e não pode ajudá-lo com diferentes tipos de parafusos.

Por outro lado, Pete diz que a chave hidráulica é blasfêmia e Brad não é um "mecânico de verdade". Claro que Pete pode fazer apenas metade do que Brad faz, mas ele faz isso da "maneira certa".

Agora, o que você acha, quais clientes da garagem escolheriam? Um que leva 20 minutos ou outro com 40 minutos de espera.

É bem parecido com a programação. C ++ é uma boa linguagem e tem seu objetivo (principalmente desempenho). O que eu gosto em linguagens como o C # é que posso me concentrar em um problema, pensar em algoritmo sem todo o ruído que o C ++ faz como avisos ambíguos do compilador, comportamentos indefinidos etc. O desenvolvimento está se tornando cada vez mais complicado que, nos velhos tempos dos mainframes e dos primeiros PCs, o cérebro humano permanece o mesmo - praticamente idiota. Um aplicativo pode ser executado na nuvem, móvel, desktop, existem muitas dependências, problemas de segurança e outros problemas. Eu quero ter uma ferramenta melhor para focar em problemas mais complicados e resolvê-los.

Use ferramentas melhores para realizar o trabalho - não há nada de errado nisso.

Então, o que estamos chamando de programação agora

Você diz:

Os futuros programadores dirão ao computador o que desejam e o compilador escreverá o programa para eles como em Star Trek.

faça um experimento: assista a Star Trek e tente interpretar as coisas que o computador deve fazer um pouco 'sem graça'.

• Chá cinzento, quente -> muito vapor.
• Chá, conde cinza, 60 graus Celsius -> uma poça e uma nuvem de vapor
• cinza-conde, 60 graus Celsius -> uma poça
• cinza-conde, 60 graus Celsius, em um copo -> um copo com uma gota nele
• cinza-conde, 60 graus Celsius, 0,2 litro, em um copo. -> finalmente (ok, você pode escolher mais)

Quando você chama Programação: 'Saber sobre o uso da memória, ponteiros, etc.', sim, acho que isso se tornará menos importante (como 'Saber sobre http, openid, unicode' se tornará mais importante).

Mas, na minha opinião, tudo é 'complexidade acidental', e o trabalho real como programador é 'Fazer máquinas de construção resolverem problemas, certificando-se de que você entenda o suficiente dos problemas acidentais para realizar a tarefa' e, por essa definição, alguém conversando com um computador star trek precisa ser um programador (ou seja, ter as mesmas virtudes que agora).

Os programadores não estão ficando mais preguiçosos. Os programadores sempre foram preguiçosos. Ser preguiçoso faz parte da natureza fundamental do trabalho. O problema é que as pessoas assumem que ser preguiçoso é negativo. Ser um programador "preguiçoso" é uma virtude.

Lembre-se do velho ditado, "Trabalhe de maneira mais inteligente, não mais". Esta é a unidade fundamental dos programadores.

Os caras que construíram e programaram os primeiros computadores não o fizeram porque gostavam de trabalhar duro, para evitar ainda mais o trabalho. (fazendo páginas de cálculos manualmente)

Ser 'preguiçoso' é uma das razões fundamentais pelas quais os programadores programam. É por isso que escrevemos linguagens de nível novo e cada vez mais alto, depuradores e IDEs cada vez melhores, scripts de shell e de construção, etc ...

Um programador analisa um problema, qualquer coisa que ele ou ela faça e pense;

"posso automatizar isso?" , "quanto tempo isso levaria?" , "quanto tempo isso me salvaria?"

Fazemos isso porque somos preguiçosos, não queremos fazer uma tarefa repetitiva e chata quando poderíamos fazer coisas que são muito mais divertidas.

Se os programadores não fossem preguiçosos, nenhum programador teria visto a necessidade de escrever uma única nova linguagem ou compilador.

No que diz respeito à noção de que um programador é "preguiçoso", porque ele tem que "procurar coisas", e daí, quem se importa. A suposição de que é mais trabalhoso aprender todas as nuances de um idioma específico (e nunca precisar procurar algo) é encontrar e usar o que você precisa quando precisa é uma falácia. Além disso, o processo de procurar coisas é o processo de aprendizado e o motivo pelo qual sites como esse existem.

Se alguém quiser um trabalho árduo de programação, eu diria a eles para codificar manualmente algum código de máquina bruto em hexadecimal. Fiz isso? Quer algo mais difícil? Agora vá depurar.

Antes de tudo, telefonar para pessoas que usam, por exemplo, idiomas preguiçosos com coletor de lixo, é como telefonar para pessoas que dirigem carros com transmissão automática preguiçosa. OMI é um pouco ridículo.

Quanto à competência, a programação é um trabalho muito mais popular e igualitário do que costumava ser. Então, sim, existem muitos recém-chegados, que não têm conhecimento. No entanto, não quero dizer que de repente haja programadores menos competentes. De fato, existem mais. Você está apenas olhando para o lado errado da curva da campainha.

Fico tentado a dizer: "sim, programadores juniores opinativos desinformados tornaram-se preguiçosos e menos competentes", mas vamos tentar uma resposta séria:

Muitas coisas se tornaram mais fáceis, mas mais é esperado de nós. No momento, estou criando um aplicativo Web que possui muitos recursos normalmente encontrados em aplicativos GUI bem elaborados (visualizações com guias, grades editáveis ​​e classificáveis, exportação para Excel etc.). As ferramentas que estou usando (ExtJS etc.) tornam razoavelmente barato criar esse aplicativo.

Dez anos atrás, seria quase impossível, pelo menos, muito caro, criar um aplicativo assim. Mas há dez anos, um formulário HTML simples com uma tabela HTML seria suficiente para os clientes. Hoje, com o mesmo esforço, melhores resultados (pelo menos mais bonitos) são possíveis e os clientes esperam obtê-los!

Em geral, hoje, um desenvolvedor de software precisa conhecer mais idiomas do que um desenvolvedor de software há 20 anos. Naquela época, algo como C e SQL era suficiente. Hoje, estou usando JavaScript, HTML, Groovy, Java, SQL no mesmo projeto.

Os programadores estão se tornando menos competentes e preguiçosos em alguns aspectos, mas mais competentes em outros, embora a divisão C ++ / VB não seja a razão ou um sintoma em minha mente.

O uso de um construtor de GUI não é preguiçoso, é apenas diferente, trata-se de ferramentas para o trabalho em questão. Se um programador de assembler chamasse um programador de C ++ preguiçoso, você chamaria besteira sobre isso (corretamente) e o mesmo vale para C ++ e VB. O VB permite que você faça algumas coisas rapidamente, à custa de algum controle. As barreiras para iniciar a codificação são certamente menores, mas isso é uma coisa muito diferente da preguiça - você apenas aprende coisas diferentes e as aplica de maneiras diferentes. Os programadores de VB não são mais preguiçosos do que os programadores de C ++ são improdutivos, eles apenas trabalham e produzem de maneiras diferentes.

No ponto mais amplo, geralmente a educação dos programadores é melhor agora do que nunca. A idéia de não usar o controle de origem, por exemplo, é bastante repugnante para quase todo mundo agora, há 10 ou 20 anos atrás, que não teria sido tão verdadeiro. Da mesma forma, é mais provável que eles entendam e desejem usar testes de unidade automatizados, integração contínua e assim por diante; portanto, nesse sentido, eles são mais competentes do que eram.

Mas o que eu acho que mudou é que as pessoas não sabem mais como resolver problemas do jeito que costumavam, e isso é verdade para praticamente qualquer linguagem convencional. A resposta instantânea a qualquer problema agora é o Google e, embora seja ótimo e funcione 95% do tempo, vejo muitos programadores que não têm idéia do que fazer quando isso não acontece.

Não é que eles não entendam os fundamentos (eles não entendem, mas isso não é realmente grande coisa), é que eles não podem resolver os problemas de tal maneira que podem até descobrir quais são os fundamentos que precisam estar enfrentando.

Antes do Google, você não tinha escolha. Seus recursos eram sua equipe, algumas dezenas de livros físicos aos quais você pode ter acesso e seu cérebro. Essa configuração significa que, se você encontrar um problema, é provável que esteja resolvendo você mesmo a partir de algo próximo aos primeiros diretores, para que você seja muito bom nisso ou desempregado rapidamente.

E isso era verdade, independentemente do idioma que você usava. O VB é de alto nível e oculta muito, mas isso significa que, quando se trata de solução de problemas, isso realmente significava que havia mais que você precisava trabalhar. Se algo não funcionasse, você teria que ser mais criativo e trabalhar mais, pois tinha menos controle. Como programador de VB (e eu falo por experiência própria), você não sabia menos do que os caras do C ++, sabia apenas coisas diferentes, mas ambos sabiam como resolver problemas.

Mas provavelmente é difícil vê-lo como uma crítica significativa aos programadores hoje em dia, eles não desenvolvem as habilidades porque não precisam delas, mas é uma fraqueza em comparação com aqueles que adquiriram as habilidades quando eram necessários.

Percebo no seu perfil que você tem 23 anos. Deixe-me colocar os dentes e dar uma perspectiva de alguém com cerca de duas vezes a sua idade que faz isso há muito tempo:

Costumava haver muito menos de tudo, começando com poder de computação, armazenamento e largura de banda da rede, se você tivesse uma rede. Essas escassez impõem limites ao que você poderia razoavelmente fazer, tornando muito mais fácil entender tudo. O software que executamos hoje é muito mais capaz do que as coisas com as quais trabalhei 25 ou 30 anos atrás, e esses recursos significam que há muito mais. Isso torna muito mais difícil reunir uma compreensão refinada de tudo para uma pessoa. Parte disso tem a ver com o fato de que as coisas continuarão a aumentar em complexidade e parte disso tem a ver com os efeitos colaterais da idade.

O ecossistema de computação está se tornando muito parecido com os sistemas biológicos: os seres humanos são mais complexos que os organismos unicelulares, e algumas partes de nós precisam se especializar para se tornarem boas em fazer alguma coisa. Minhas células cerebrais são muito boas em coisas inteligentes, mas seriam perdidas se enfiadas no meu rim e se espera que façam coisas renais. Da mesma forma, o cara que é bom em escrever processadores de sinais digitais pode não ter idéia de como a indexação de texto completo funciona, porque essa não é sua especialidade. Mas ambos podem evoluir um pouco e aprender a entendê-lo, se necessário, mas há limites para o quanto você pode se espalhar e ainda ser eficaz no que faz.

... ninguém se importa com como as coisas funcionam, exatamente como funcionam até que não funcionem.

Quando você tem um trabalho a fazer, geralmente precisa dar o salto de fé que uma ferramenta que você está usando (biblioteca, RDBMS, subsistema inteiro etc.) funciona como deveria. Uma das coisas que a experiência traz é a capacidade de escolher quais buracos de coelho você vai encontrar para descobrir falhas em suas ferramentas, corrigir o problema e depois voltar ao que estava fazendo.

Agora, não estou dizendo que os desenvolvedores do VB são preguiçosos em apenas dizer que são mais fáceis que o C ++ e notei que muitas linguagens mais recentes estão seguindo essa tendência como um c #.

Isso é tudo uma questão de perspectiva. Eu estava por perto para ver o C ++ surgir, e segue essa tendência também. C ++ torna as coisas muito mais fáceis do que C, C torna as coisas muito mais fáceis do que a montagem e a montagem torna as coisas muito mais fáceis do que escrever manualmente os códigos de operação. Como alguém que escreveu muita montagem e montou algumas coisas manualmente do zero, isso colocaria você, como programador de C ++, três passos no caminho "é mais fácil".

Algo que mantenho há muito tempo é:

Um dos maiores pontos fortes da linguagem Visual Basic é que um iniciante pode aprender a fazer muitas coisas úteis rapidamente.

Uma das maiores fraquezas dos programadores do Visual Basic é que eles aprenderão a fazer muitas coisas úteis rapidamente, e pararão de aprender qualquer coisa.

Quando eu ensinava a programar o primeiro exercício, o primeiro dia de aula era como criar um aplicativo no NOTEPAD e compilá-lo usando VCC ou VBC. Sim, são coisas que nós (como programadores) não fazemos diariamente, mas devemos entender o que está acontecendo quando pressionamos "F6".

Os programadores não estão (geralmente) ficando 'preguiçosos' tanto quanto esperamos obter mais de nossas ferramentas. Não preciso digitar "get / set" 10.000 vezes por dia. GOSTO que o Visual Studio e outras ferramentas, como Code Smith e Resharper, trabalhem para que eu faça o que já sei como fazer, para que eu possa aplicar meu esforço em descobrir como fazer coisas "novas". Isso não me deixa mais preguiçoso, me deixa "inovador".

Como desenvolvedor profissional, não devemos perder tempo reinventando a roda, mas devemos entender claramente o que é necessário para fabricar a roda que vamos usar. São coisas que 'deveríamos' aprender como desenvolvedores de estudantes (mas, infelizmente, muitas vezes não são). Se um desenvolvedor não entende alguma tecnologia de "caixa preta", isso realmente os torna menos "competentes". A maioria dos desenvolvedores apenas 'basicamente entende' como um driver ODBC funciona, eles apenas entendem 'o que' faz. Preciso saber como funciona uma transmissão para ser um motorista competente? Eu diria que não. Isso me torna um proprietário de carro mais competente para saber disso, sim.

A necessidade de desenvolvimento rápido de aplicativos (link obrigatório do wiki: http://en.wikipedia.org/wiki/Rapid_application_development ) fez com que os desenvolvedores escrevessem menos código e os desenvolvedores mais novos entendessem menos, porque não precisam entender como implementar um lista vinculada, pois eles têm algo mais alto nível para focar.

Eu não consigo pegar, matar, tirar a pele, açougueiro e curar carne, e duvido que o cara no café lá embaixo possa, mas ainda recebo meu sanduíche de bacon dele, assim como os executivos recebem seus aplicativos de desenvolvedores que não sabem sobre ponteiros (como eu!)

Já foi dito que as grandes disciplinas científicas são exemplos de gigantes apoiados nos ombros de outros gigantes. Também foi dito que a indústria de software é um exemplo de anões que estão na ponta dos outros anões.
- Alan Cooper

Um bom desenvolvedor de software não é quem reinventa a roda. Ele é capaz de usar as ferramentas que foram construídas antes dele. Ele não perde tempo reescrevendo as mesmas coisas chatas e antigas, que foram escritas centenas de vezes, se tornam cansativas rapidamente e provavelmente já existem em uma versão de qualidade superior.
Se você fornecer a eles um idioma que já inclua discos de pedra redonda, é provável que eles não gastem muito tempo reinventando as rodas. Se eu recebesse um centavo por cada rotina de cópia de string já escrita em C, provavelmente poderia comprar toda a indústria de software.

A preguiça é de fato uma das três grandes virtudes de um programador. As ferramentas de que você fala foram criadas por bons programadores para bons programadores, para reduzir a redundância e o tédio e, assim, aumentar a produtividade e a motivação. De fato, essas ferramentas podem ter efeitos negativos para iniciantes, pois inibem uma compreensão mais profunda do aspecto de programação que simplificam.

Não. Você está ficando velho.

Não é brincadeira, o que você está experimentando é uma espécie de direito de passagem para os desenvolvedores. Desde que os primeiros idiomas de nível superior substituíram o assembly. Naquela época, você já ouvira todos os programadores do ASM reclamando da mesma coisa. Daqui a cinco anos, todos os desenvolvedores do Ruby on Rails estarão reclamando da preguiça de mais uma nova safra de novas ferramentas que estão tornando as pessoas.

Esse refrão será repetido até que as máquinas destruam todos nós: "Parece que a tecnologia X está tornando os desenvolvedores mais preguiçosos e piores que a tecnologia Z que eu sempre usei?"

A boa notícia é que, apesar de os compiladores terem percorrido um longo caminho, as pessoas ainda precisam de montagem, C e todos os outros velhos defensores de muitas coisas ... mas não a maioria das inovações tecnológicas de ponta. Se você quer estar na vanguarda, sugiro que você atualize seu conjunto de habilidades.

Pela minha experiência, sim e não, mas não é culpa das línguas; é culpa dos próprios desenvolvedores. Eu trabalhei com muitos desenvolvedores que não se importavam em fazer as coisas direito, melhorar a si mesmos ou realmente fazer outra coisa senão produzir a mesma porcaria que eles fazem há anos. Tentar fazer essas pessoas melhorarem é como conversar com uma parede de tijolos - na metade do tempo, eles ignoram qualquer coisa que não usaram no passado ou não estão totalmente dispostos a "se arriscar" com algo que possa melhorar sua produtividade. .

Linguagens mais avançadas não são o problema, são os programadores que não tratam essa profissão como um ofício em constante evolução. Você não precisa estar intimamente ciente de tudo o que há de novo ou pular em cada novo movimento, mas deve pelo menos tentar melhorar o que faz.

Para um exemplo concreto: sou desenvolvedor .NET por profissão. Eu esperaria que um desenvolvedor .NET competente estivesse ciente de coisas como LINQ, Entity Framework, WPF, MVC e similares; eles não precisam usá-lo ou empurrá-lo no local de trabalho, mas pelo menos uma compreensão passageira de "Isso existe" é melhor do que a ignorância absoluta que eu vejo com muita frequência.

Eu só tenho codificado há cerca de 4 anos no trabalho e isso tem sido quase inteiramente c #. Eu aprendi C ++ quando estava na faculdade e na Uni, mas não seria capaz de fazer muito com isso agora.

Portanto, para o desenvolvimento da GUI, isso pode ser visto como preguiçoso, mas, novamente, não é possível ver que você pode se concentrar menos na codificação dessa parte e mais no desenvolvimento da lógica do próprio aplicativo.

então, talvez, em vez de se tornarem menos competentes, eles estejam mudando o foco, provavelmente muito para sistemas de comunicação e distribuição, como computação em nuvem e SOA. Embora isso possa ser o mesmo pensamento de um programador intermediário.

Provavelmente, é verdade que a barreira à entrada nos trabalhos de programação vem diminuindo a cada ano. Por exemplo, agora é possível para engenheiros cuja especialidade não é principalmente software e artistas escrever código usando linguagens de script.

Isso implica que o nível de competência realmente aumentou, se você considerar a amplitude. O fato de os artistas poderem programar também significa que agora há mais programadores com habilidades artísticas.

Há uma diferença entre "programador" e "programador real". Por favor, não chame o HTML de linguagem de programação, mas existem muitos "programadores de HTML". Cada um de vocês (programadores / desenvolvedores) pode fazer uma experiência com colegas - apenas "desligue a Internet (na verdade, não permita que eles usem mecanismos de busca)", e você verá que uma enorme variedade de "programadores" ficará Sem trabalho. O que eles podem fazer, eles sabem que, se precisarem, por exemplo, pesquisar em texto, eles devem "pesquisar 'a pesquisa de texto em% language_name%'"? Eles não podem responder a isso - quais são as diferenças nos algoritmos de Boyer-Moore e Knuth-Morris-Pratt.

Então, na IMO, programar significa resolver problemas, conhecendo uma linguagem de programação muito boa, no mínimo, com seu 'STL' e outras coisas importantes. Programar é uma arte, é um tipo de vida, não é algo que possa ser feito por todos.

Desculpe por mais sarcasmo do que o necessário, mas acho que este artigo diz melhor do que eu.

Estou errado?

UPD: O principal e importante é o conhecimento dos fundamentos, como algoritmos, estruturas de dados, etc. Quantos de vocês podem implementar as bibliotecas / funções padrão / etc, caso os de hoje sejam removidos acidentalmente? Na IMO, o programador deve usar código 'alienígena' desenvolvido / bem depurado (bibliotecas / estruturas / etc), mas deve ser capaz de reinventar a roda, sempre!

Quanto ao VB ser fácil de usar e aos programadores preguiçosos que escolhem o VB por causa disso:

Eu acho que o VB está cercado por um grande mito de ser fácil de usar. Esse mito era originalmente um tanto verdadeiro: nos dias por volta de 1991-1994, quando os dinossauros percorreram a Terra, havia apenas duas ferramentas reais da RAD, VB e Delphi. Eles eram bem parecidos, mas NOTA: Delphi e VB eram igualmente fáceis de usar! A única diferença notável entre eles foi que o VB tinha uma sintaxe completamente ilógica e produziu programas incrivelmente lentos.

As GUIs do C / C ++ foram gravadas no MFC ou na API do Windows não processada. Portanto, o VB era certamente mais fácil de usar do que a alternativa da Microsoft. Então o boato foi assim:

• O VB é mais fácil de usar que a API Microsoft C / C ++ / Win. ->
• VB é mais fácil de usar. ->
• VB é fácil de usar. ->
• VB é o mais fácil.

Esse boato continuou, mesmo que Delphi sempre fosse igualmente fácil, se não mais fácil, já que Pascal é uma linguagem sã e lógica.

Então, no final dos anos 90, a Borland lançou um equivalente em C ++ ao Delphi: C ++ Builder. Agora havia três ferramentas igualmente fáceis. Nessa época, os poucos argumentos racionais restantes para usar o VB morreram. No entanto, o mito ainda vivia. "VB é o mais fácil".

Então o Java apareceu e havia várias ferramentas RAD para ele também (e para sua versão do fiasco da Microsoft chamada J ++). No entanto, o mito VB continuou.

A Microsoft também fez o suporte ao RAD para C ++ e também criou o C #, reunindo tudo em uma grande gosma chamada .NET. Como o mito do VB ainda existia, eles conseguiram enganar os desenvolvedores antigos do VB a usar o VB.NET em vez de C ++ ou C #. Embora o VB.NET não fosse compatível com as versões anteriores do VB.

Hoje, o VB é uma linguagem completamente redundante. A ferramenta RAD não é mais fácil do que qualquer outra ferramenta RAD. A sintaxe da linguagem é absolutamente horrível, tão ruim que na verdade incentiva o design do programa e as práticas de programação.

Há uma enorme variedade de atividades agrupadas sob a bandeira da "programação" e um número cada vez maior de trabalhadores envolvidos no final "técnico" da escala. Você não precisa ser capaz de escrever compiladores, ou mesmo selecionar entre um conjunto de algoritmos para resolver um problema específico e montar um site em PHP. A indústria / sociedade precisa de muitas pessoas produzindo esses sites (aparentemente), e também de um certo número de programadores trabalhando em problemas mais difíceis. Esse segundo grupo não é preguiçoso ou incompetente como um todo, ou nossos aviões ficariam em chamas, caixas eletrônicos entregando quantidades aleatórias de dinheiro, máquinas de raio X fornecendo doses fatais de radiação, mercados financeiros ficando estragados, etc. sobre esse último :-)

Um lado disso, acho que todas as outras respostas estão apenas olhando, é que essa é apenas a tendência generalizada que vai das linguagens de baixo nível para as de alto nível.

Sim, o setor de software está mudando de idiomas de baixo nível para idiomas de alto nível, sempre mudou e provavelmente continuará a fazê-lo enquanto criarmos ferramentas melhores. Sim, isso pode ser considerado preguiçoso, pois você teve que trabalhar muito para fazer coisas básicas para os padrões atuais. Mas eu não diria menos competente. A competência está simplesmente passando da implementação para o design.

Nível baixo É um pouco subjetivo, mas em um nível baixo, você está trabalhando mais perto do hardware. Há menos manipulação e suposições de intenção. As ferramentas básicas são apresentadas e as tarefas são deixadas para o programador. Os idiomas de baixo nível vieram primeiro, é claro, e geralmente são as ferramentas da velha guarda, pois os idiomas de nível superior não existiam quando começaram. Sempre haverá algum desenvolvimento de baixo nível. Mas eu não faria um site em montagem.

Alto nível O objetivo em altos níveis é automatizar a funcionalidade básica e simplificar a programação. Reduz a barra de entrada para novos programadores, realiza as tarefas com mais rapidez e padroniza como representamos e processamos dados, geralmente com uma sobrecarga. Considere uma string. Nos primeiros dias, alguém provavelmente usava de 1 a 26 para az, e usava apenas 5 bits e só precisava saber qual o tamanho de suas palavras. Em seguida, o padrão ascii foi desenvolvido e tivemos strings C com um caractere terminador. Agora, temos objetos que lidam com coisas para evitar estouros de buffer e subtipos especiais que não permitem caracteres de escape. Ou um laço. Um loop "for" é um nível um pouco mais alto que o loop "while". E um loop "while" é realmente apenas uma representação de uma maneira estruturada de chamar GOTO.

Além disso,

Os futuros programadores dirão ao computador o que desejam e o compilador escreverá o programa para eles como em Star Trek.

Bem vindo ao futuro! É exatamente o que os compiladores fazem. Antigamente, as pessoas tinham que escrever o código da máquina manualmente. Agora nós automatizamos isso e simplesmente informamos ao computador como escrever o código da máquina para nós.

Eu acho que em algum lugar ao longo do caminho você perdeu de vista o que os programadores são pagos para fazer.

Nossa entrega não é código, é software de trabalho.

Não estamos construindo móveis nos quais os encaixes cortados à mão, de alguma forma, conferem valor extra por causa de todo o "artesanato" manual que foi utilizado.

Somos pagos para resolver problemas de negócios em computadores). Se você pode entregar o mesmo produto em menos tempo e por menos dinheiro, acho que é nossa obrigação deixar de lado a pretensão de que os programas C ++ são superiores simplesmente porque são mais complexos de construir.

A proporção de (desenvolvedores de programas principais / número de desenvolvedores) está diminuindo porque:

• As ferramentas estão ficando mais fáceis, isso significa que talentos menores são necessários para o mesmo problema

• As pessoas estão se acostumando às tecnologias de TI, e isso tem mais disposição de gastar dinheiro com ferramentas personalizadas

• A literatura de Ciência da Computação está crescendo exponencialmente, a especialização e a divisão do trabalho estão aumentando, de modo que não há mais pessoas "Aristotélicas" que falam sobre tudo (na verdade elas não precisam saber tudo por causa das camadas de abstração)

• Mais trabalhos oferecidos, o filtro é afrouxado

• É necessária mais automação a cada ciclo de vida, a demanda está aumentando e a oferta não é suficiente

• A proporção de desenvolvedores em relação à população está aumentando.

  Portanto, as pessoas não estão ficando mais preguiçosas e menos competentes, a média cai porque a computação é uma área mais aberta agora.

Muitas respostas dizem por que reinventar a roda e eu concordo com isso, mas quando há rodas disponíveis, as pessoas não estão se preocupando em aprender a fabricar a roda.

Você está minando todo o seu argumento pelo fato de que, de alguma forma, as rodas ainda são fabricadas. Entendo o seu ponto de vista, mas notei que, em qualquer disciplina, há pessoas suficientes interessadas nas coisas de baixo nível para continuar. Por exemplo, eu uso o Qt para criar GUIs. Essa ferramenta não chegou por mágica, as pessoas desenvolveram o vínculo entre as coisas de baixo nível e as que eu faço. Sim, menos pessoas entendem as coisas de baixo nível. Menos pessoas também podem matar sua própria comida ou consertar seu próprio carro, mas a sociedade consegue sobreviver.

Antes dos anos 40, os computadores eram circuitos com fio. Então Von Neuman teve a idéia de localizações de memória armazenada. Estou certo de que os programadores do MIT pensaram que ele iria degradar o comércio deles em algo muito fácil. Depois veio a montagem, depois FORTRAN, depois ada, depois C, depois c ++, depois java e assim por diante. O ponto é que o objetivo de uma linguagem é permitir cada vez mais abstrações. Esse sempre foi o objetivo e é a razão pela qual o c ++ pegou e depois o java depois dele. Meu maior problema é que as universidades não estão mais ensinando aos alunos nada sobre computadores. Eu não contratei programadores de c # se eles não conhecem c ++ como as costas de suas próprias mãos. Por quê? Como é muito fácil ser um programador ruim, cada vez mais abstrata a linguagem se torna. Eles precisam entender ponteiros, gerenciamento de memória, ligação dinâmica etc. . por dentro e por fora antes que eles pudessem entender C # no nível em que confio que contribuam para nossa base de código. Também os faço lutar por criar arquivos antes de permitir que eles usem o Visual Studio. Dito isto, eu amo C # e um bom IDE, mas eles são bons como ferramentas quando são entendidos corretamente. Na minha opinião, uma abstração é mais útil quando você entende os detalhes que estão sendo abstraídos - é uma ideia muito antiga, veja Thomas Aquinas sobre a relação da Abstração com os particulares.

Acho que outro bom exercício para desenvolvedores iniciantes é fazê-los escrever alguns aplicativos usando a API do Windows. Depois que eles terminarem, faça com que eles o tornem orientado a objetos, onde todos os formulários herdam da sua classe de janela genérica. Faça com que eles encapsulem o loop de eventos e coloquem alguns ponteiros de função voltando para sua classe de formulário. Então diga bom trabalho, a Microsoft já fez isso por você, chamado System.Windows.Forms. Diverta-se.

Se eles devem ser desenvolvedores da web, peça a eles que escrevam alguns programas de CGI para entender o POST, GET etc ... e depois escrevam scripts na página. Faz ASP.NET e PHP fazer muito mais sentido.

Se eles estiverem trabalhando em algo de nível inferior em uma rede, faça-os escrever alguns aplicativos usando soquetes antes de apresentá-los às bibliotecas que já o fizeram.

Descobri que isso melhora a produtividade a longo prazo, porque fornece as ferramentas e as intuições corretas para resolver seus próprios problemas.

As universidades deveriam estar fazendo isso, mas não são o que precisamos.

Dito isto, concordo que está se tornando cada vez mais difícil encontrar programadores que valem a pena sair da faculdade, principalmente porque não foram eliminados por serem forçados a escrever algoritmos recursivos e listas vinculadas. Além disso, eles geralmente só têm cursos em Java ou .NET e, portanto, não entendem nada sobre o modo como eles funcionam. Ainda assim, a abstração é bastante útil quando usada corretamente.

(..) mais cedo ou mais tarde, não haverá o que chamamos de programação agora

Eu discordo deste ponto.
Sem saber o que é consciência, o trabalho do programador é seguro.

É assim que as "máquinas pensantes" se parecem no momento:

-Pare de mudar de assunto!
-Eu pensei que nosso amor era especial.
-Pare de mudar de assunto!
-Não estou mudando de assunto.
-Tu es! Estou tentando falar sobre a sua incapacidade de entender do que estamos falando.
-Não, não é nem perto. minha música favorita dos beatles é do outro lado do universo. qual é a sua?

Acredito que apenas aqueles programadores que não entendem esse ponto estão condenados.

Por exemplo, resposta do desumanizador :

Eles não podem responder a isso - quais são as diferenças nos algoritmos de Boyer-Moore e Knuth-Morris-Pratt.

E com "esse ponto", quero dizer - é errado tentar superar os computadores no que eles são melhores - algoritmos. Em vez disso, o programador deve auxiliar o computador no contexto, informando sobre os problemas que estamos tentando resolver.

As ferramentas em si não corrigem problemas, elas apenas (às vezes) tornam os programadores mais eficientes.

É como: "armas não matam, seres humanos matam".

Absolutamente não. Na minha experiência, o uso das ferramentas de desenvolvimento corretas permite o desenvolvimento rápido de aplicativos sem sacrificar a qualidade. De fato, eu argumentaria que, na maioria das vezes, a qualidade aumentou devido à nossa "confiança excessiva nas ferramentas". Além disso, as ferramentas de desenvolvimento podem diminuir a curva de aprendizado e introduzir mais pessoas na programação. Isso, é claro, tem uma desvantagem, pois há muito mais programadores iniciantes, mas, em suma, ajuda no processo criativo e impulsiona a tecnologia.

O excesso de confiança nas ferramentas implica que você é preguiçoso?

De um modo geral, 'Não'; mas há uma grande ressalva.

Comecei a programar em C ++ na uni e adorei. No próximo período, mudamos para VB6 e eu odiava.

Eu não sabia o que estava acontecendo, você arrasta um botão para um formulário e o ide escreve o código para você.

Sim, de fato. Sua experiência na uni fala da mesma ressalva que mencionei.

Se você não sabe qual é o problema da sua ferramenta ou está incapaz de solucionar problemas quando a ferramenta tem problemas próprios, isso é uma enorme bandeira vermelha. Essa circunstância não implica necessariamente preguiça, mas provavelmente implica inexperiência.

Eu acho que existem 2 tipos de programadores. Existem programadores que apenas programam para fazer o trabalho por causa de talvez um prazo ou talvez apenas para serem mais produtivos. Eu diria que eles eram preguiçosos. Simplesmente acredito que eles não têm interesse em "como" um computador faz o que faz ou em "como" um programa faz o que faz.

Depois, há programadores apaixonados, como eu. Programadores apaixonados, como eu, gostam de saber exatamente o que está acontecendo na CPU. Assim como um bom psicólogo tenta descobrir o que está acontecendo na cabeça humana, os progologistas, como eu, querem saber o que está acontecendo dentro da CPU. Assim, aprendemos, dissecamos e analisamos um programa e usamos ferramentas, como Refletor e desmontadores, para tentar descobrir como um programa funciona.

Tenho uma silenciosa esperança de que as coisas mudem. As CPUs não estão escalando verticalmente tanto, apenas horizontalmente, e o ARM etc. serão limitados por recursos em um futuro próximo.

É bem possível que a demanda por programação sem arrastar e soltar diminua e veremos alguns trabalhos mais interessantes.