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


29

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.


7
"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?" - este não é um ou ou, ambos são verdadeiros (mas não pelas razões que você diz).
Jon Hopkins

15
Como alguém pode responder a isso sem refutar o título?

Comentaristas : os comentários destinam-se a buscar esclarecimentos, não a discussões prolongadas. Se você tiver uma solução, deixe uma resposta. Se sua solução já estiver publicada, faça um voto positivo. Se você quiser discutir esta questão com outras pessoas, use o bate-papo . Veja o FAQ para mais informações.

8
Por que isso não foi fechado como "subjetivo e argumentativo" ...?
BlueRaja - Danny Pflughoeft 01/07

Respostas:


103

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.


3
Há uma diferença entre ser desenvolvedor e programador.
Raynos

9
+1. Exatamente. Software de trabalho é o que você paga. Código é um meio de criar software, um artefato. A "programação" pura é a parte fácil e divertida da criação de software.
Joonas Pulakka

+1 para o todo. Não tenho certeza de que com "A única coisa que você deve desenvolver é um código exclusivo para os negócios para os quais está desenvolvendo". Mas vou admitir que é uma estratégia de negócios válida.
precisa saber é o seguinte

@ Chad - Leve o seu ponto. Às vezes eu falo com hipérbole. O senso comum sempre substitui a filosofia, quando se trata da crise, mas acho que é uma boa posição ser discutida caso a caso, em vez de assumir uma posição padrão de "sim, vamos escrever por nós mesmos". :)
pdr

Como empresa, a maior questão é: qual é o retorno do investimento no tempo gasto no desenvolvimento de uma solução. Meu chefe não se importa em que idioma eu desenvolvo, desde que eu possa ajudar a empresa a ganhar mais dinheiro do que está me pagando. Qualquer outra coisa e eles estão perdendo dinheiro comigo.
Dan Williams

38

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.


1
Eu não acho que a analogia funcione porque Brad e Pete ainda saberão como remover o pneu e tudo o que está envolvido (chaves, chaves e cerveja).
Kristofer Hoch

3
+1 ótima resposta. Eu acrescentaria que, independentemente da ferramenta usada, se você entender o que ela faz, fará seu trabalho corretamente. Por outro lado, se não o fizer, não importa quanto do trabalho está sendo feito pela ferramenta, em algum momento você vai estragar alguma coisa.
Jacek Prucia 01/07

1
@ Kristofer: Talvez seja melhor se Pete conheça alguns eletrônicos. Enquanto Brad sabe como usar o computador de diagnóstico e lê que o sensor de O2 está com defeito, Pete vê que o fio do sensor está um pouco queimado, sai do medidor para medi-lo e percebe que o regulador de tensão ficou instável e está queimando sensores de O2.
Zan Lynx

@Zan que não é a mesma coisa. @ Kristofer só porque eu uso o designer para arrastar os controles para um elemento do formulário rapidamente e concluir o código padrão não significa que não sei como alterar esse código para fazer o que quero depois.
Jcebrand # 01/07

Maneira perfeita de colocá-lo.
Rjalk #

37

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).


2
@ Raynos: muuuuito verdade. Especialmente deprimente quando essas pessoas são teamleaders e diretrizes fazer como 'quando os dados a enviar é menor que X bytes, use GET, quando mais, use POST'
keppla

8
@keppla - Seu problema não é que o líder da sua equipe não entendeu o HTTP, é que ele não estava disposto a mudar de opinião à luz de evidências de que ele estava errado (supondo que você tentou explicar as coisas). Você não pode saber mais do que todos que trabalham para você sobre tudo - o verdadeiro crime não é aceitar que alguém saiba mais sobre algo que você.
91111 Jon Hopkins

3
"Tea, Earl Grey, Hot" é uma programação declarativa. O trabalho do computador é encontrar um resultado contextualmente relevante com base em expectativas razoáveis. Produzir vapor a partir de "chá quente" nesse tipo de linguagem seria um erro de parte da equipe de design do computador, não do programador. Ele deve usar o caso contextualmente relevante, a menos que uma consulta específica seja inserida.
Diadem

1
@ Diadem: mesmo quando declarativo, você precisa saber o que declarar e, como programador, não esperaria que o computador pudesse adivinhar do passado o que você fará a seguir, porque fará coisas novas. A interface que interpreta seus desejos é para usuários finais.
keppla

2
@Zan Lynx: Talvez um exemplo melhor: faça o computador avisar você toda vez que alguém for seqüestrado (o computador não parece se importar com isso no TNG). 'Computador: informe-me quando alguém for sequestrado' 'Por favor, defina abduzido' 'Quando ele for levado contra sua vontade' 'Por favor, defina vontade', etc. Para encontrar uma solução como 'Informar o oficial encarregado quando a localização de alguém mudar do conhecido ao desconhecido, e não há registro de que um oficial de transporte o tenha transportado ou que ele tenha entrado em um ônibus, e o navio não esteja no cais. você ainda precisa de um programador de Mindset.
keppla

23

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.


19

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.


11
As pessoas que dirigem automóveis são preguiçosas, não há nada de ridículo nisso. Manual com calcanhar-e-dedo do pé oferece muito mais controle e desempenho fora do carro, mas requer muita habilidade e trabalho extra.
Cody #

11
@ Codificador: "requer trabalho extra" - na rodovia, não, no engarrafamento, mas depois não oferece nenhuma vantagem.
vartec

2
As transmissões manuais também proporcionam melhor economia de combustível na estrada, embora isso seja menos verdadeiro nos conversores de torque de travamento.
Dave Markle

4
@Dave, na verdade, os eletrônicos modernos tornaram o automático realmente mais eficiente, em média. Meu Ford Fusion com as mesmas opções foi avaliado quase uma milha por galão a menos. Estou certo de que há momentos em que o manual ainda é melhor no micro, mas acima de tudo automático tem a liderança.
precisa saber é o seguinte

3
@ Codificador - Se você acha que dirigir um manual requer "muita habilidade", você precisa olhar para os milhares de motoristas incompetentes na estrada com transmissões manuais. ;)
techie007 01/07

15

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.


+1 sim, programadores júnior opinativo desinformados tornaram-se preguiçosos e menos competente
SoylentGray

12

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.


portanto, quando ninguém sabe o que é um algoritmo ou como implementar uma estrutura de dados, porque todos "programam" em IDE de arrastar e soltar, estão apenas usando a ferramenta certa para o trabalho?
Skeith

@Skeith - Depende do trabalho, mas se produz um software que resolve o problema, então sim.
Jon Hopkins

1
@ Jon-Hopkins, eu diria que o grande aumento na programação dependente do Google tem a ver com o grande número de APIs necessárias hoje em dia. É muito difícil acompanhar tudo isso. (Mas, em essência, você está correto)
Jarrod Nettles

1
@Skeith - A criação de uma interface do usuário ocupa cerca de 5% do tempo médio dos desenvolvedores de aplicativos. O que você acha que eles fazem nos outros 95%? O designer não ajuda muito com o código de back-end. Você está claramente atacando um homem de palha. A maioria das pessoas conhece as ferramentas necessárias para o trabalho, caso contrário não seriam empregadas.
Morgan Herlocker

@Skeith: Um usuário de banco de dados precisa se preocupar com a implementação de um banco de dados? Claro que não; o usuário do banco de dados usa . Eles podem precisar conhecer alguns detalhes, para otimizar seus bancos de dados, mas não precisam implementá-los para serem dignos de usá-los. Além disso, um programador pode não saber o que a palavra "algoritmo" significa, mas isso não significa que eles não os escrevam . Eu estava desenvolvendo e implementando algoritmos muito antes de ouvir o termo.
Nicol Bolas

11

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".


1
+1 indicando que é uma questão de perspectiva. Eu estava por perto quando o UNIX saiu do Bell Labs e havia uma quantidade considerável de 'tsk tsk' em que linguagens de alto nível como 'C' estavam diminuindo a arte antiga e esotérica de escrever sistemas operacionais, e isso certamente levaria a nada de bom. À medida que nossas ferramentas melhoram e cuidamos de mais contabilidade irracional para nós, podemos usar o tempo economizado para lidar com problemas mais difíceis e sutis.
Charles E. Grant

6

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.


4

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!)


4

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.


4

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.


+1: "Esses garotos preguiçosos hoje com seus carros, arcos e flechas. Quando eu era garoto, travávamos nossas batalhas com espadas curtas e andávamos de e para o campo de batalha. E isso era difícil para os dois lados". - Xerxes I, imperador da Pérsia, 473 aC
Bob Murphy

3

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.


2

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.


2

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.


1
por competência, eu quis dizer programação, todas as outras habilidades são irrelevantes, exceto matemática.
Skeith

3
@Skeith - "por competência eu quis dizer programação, todas as outras habilidades são irrelevantes, exceto matemática" - isso é tão errado. Uma das maiores melhorias do setor nos últimos 30 anos é que agora as habilidades de comunicação são absolutamente essenciais. Dê-me um programador basicamente competente, com grandes habilidades em matemática ou um com grandes habilidades de comunicação, e é o cara com habilidades de comunicação todas as vezes.
Jon Hopkins

+1 @ Jon - Concordo totalmente. Programadores que não falam com os clientes em nada além de cálculo lambda e sopa de alfabeto não têm valor na maioria dos objetos.
Morgan Herlocker

1
@Skeith: Então você só precisa saber de programação e matemática para ser um bom programador? Em que mundo você está? Você precisa saber como usar um computador, como se comunicar com clientes e outros programadores, como escrever documentos, etc. O que você não precisa saber é matemática. Claro, há alguma sobreposição entre matemática e programação, mas apenas conhecer a parte da programação é suficiente.
Martin Vilcans

Quando eu estava na faculdade, participei de uma aula de cálculo de negócios. Na final, terminei em primeiro e ganhei 100 (o professor me classificou ali mesmo - ele ficou impressionado por eu ter completado tão rapidamente). No entanto, como desenvolvedor de software, não uso matemática. O que eu uso é lógica para entender o domínio comercial e uso o carisma para interagir com as pessoas. As linguagens de programação evoluíram o suficiente para que, se você sabe escrever bem em inglês, também pode codificar. Ressalva: escrever bem Inglês é mais difícil do que a programação, porque você está wetware programação baseada em DNA ..
Christopher Mahan

2

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!


6
Meu único problema com isso é que eu trabalho como programador (um programador adequado, não web / HTML / script) há 20 anos e não tenho idéia dos algoritmos de Knuth-Morris-Pratt. Para a maioria dos programadores, esse tipo de teoria não afeta o dia-a-dia, pois esse material é agrupado em bibliotecas.
9117 Jon Hopkins

2
As bibliotecas padrão com as quais trabalho têm milhares de classes e centenas de milhares de linhas de código. Você está dizendo que eu deveria poder reimplementar tudo isso sem documentação? Caso contrário, você precisa esclarecer o tamanho de algo que pode obter antes de deixar de ser uma roda.
Peter Peter

6
Os humanos não têm a vida útil necessária para aprender a reinventar todas as rodas inventadas até agora, nem aprender a reinventar as rodas que estão sendo inventadas agora .
Macke

3
@ Deshumanizer: Espero ser treinado e ter mais de um compilador C em minhas mãos para salvar o mundo, caso contrário, vou me ferrar de qualquer maneira. (BTW Porque mesmo um compilador C Por que não apenas um USB-stick, um osciloscópio e uma bateria de 9V Sério ....?)
Macke

1
Basta desligar os compiladores e você verá a maioria das pessoas apenas sentadas enquanto os programadores REAL digitam o código da máquina diretamente em um arquivo!
Philip

1

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.


graças agora eu posso soar mais justificado em meu ódio de VB, adicionando uma razão
Skeith

1

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 :-)


1

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.


1

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.


* é software inchado, (às vezes)
kagali-san

0

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.


0

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.


0

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.


0

(..) 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".


1
Se não me engano, o Cleverbot não repete o que as pessoas já disseram?
Andrew Arnold

0

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.


0

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.


-2

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.


Discordo. Pessoas diferentes estão interessadas em coisas diferentes. Algumas pessoas estão mais interessadas na programação de nível inferior e gostam de saber o que está acontecendo no hardware. Outras pessoas são de alto nível e se preocupam principalmente com aplicativos. Você acha que alguém escrevendo código para, digamos, o Facebook, tem alguma preocupação com o que está acontecendo com a CPU ou com o funcionamento dos drivers? Dizer que, coincidentemente, as pessoas interessadas nas mesmas partes da programação que você é, as apaixonadas, não têm fundamento lógico.
Chance

-3

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.