Como um aumento na complexidade dos sistemas afetou gerações sucessivas de programadores?

it just isn't necessary because of the increased amount of processing power and memory available.

Ter memória barata, discos enormes e processadores rápidos não é a única coisa que libertou as pessoas da necessidade de ficar obcecada em cada byte e ciclo. Compiladores agora são muito melhores do que os humanos em produzir código altamente otimizado quando isso é importante.

Além disso, não vamos esquecer o que estamos realmente tentando otimizar, que é o valor produzido para um determinado custo. Programadores são muito mais caros que máquinas. Tudo o que fazemos para que os programadores produzam programas de trabalho, corretos, robustos e com todos os recursos, mais rápidos e mais baratos, leva à criação de mais valor no mundo.

My question though is how do people feel about this "hiding" of lower-level elements. Do you older programmers see it as a godsend or an unnecessary layer to get through?

É absolutamente necessário realizar qualquer trabalho. Eu escrevo analisadores de código para viver; se eu tivesse que me preocupar com a alocação de registros ou o agendamento de processadores ou qualquer um desses milhões de outros detalhes, então eu não gastaria meu tempo corrigindo bugs, revisando relatórios de desempenho, adicionando recursos e assim por diante.

Toda a programação é sobre abstrair a camada abaixo de você, a fim de criar uma camada mais valiosa sobre ela. Se você fizer um "diagrama de camadas" mostrando todos os subsistemas e como eles são construídos uns sobre os outros, você verá que existem literalmente dúzias de camadas entre o hardware e a experiência do usuário. Eu acho que no diagrama do Windows Layer Cake há algo como 60 níveis de subsistemas necessários entre o hardware bruto e a capacidade de executar "hello world" em C #.

Do you think younger programmers would benefit more learning low-level programming BEFORE exploring the realms of expansive libraries?

Você coloca ênfase em ANTES, então devo responder sua pergunta de forma negativa. Estou ajudando um amigo de 12 anos a aprender a programar agora e é melhor você acreditar que estou começando com eles em Processando. js e não x86 assembler. Se você começar um programador jovem em algo como Processing.js , eles estarão escrevendo seus próprios jogos de shoot-em-up em cerca de oito horas. Se você os iniciar no montador, eles estarão multiplicando três números juntos em cerca de oito horas. Qual você acha que é mais provável engajar o interesse de um programador mais jovem?

Agora, se a pergunta for "os programadores que entendem que a camada n do bolo se beneficia da compreensão da camada n-1?" a resposta é sim, mas isso independe da idade ou da experiência; Sempre é possível melhorar sua programação de nível superior, entendendo melhor as abstrações subjacentes.

Eu tinha ideias sobre esse assunto e eu coloquei em um livro de 20 anos atrás . Está muito fora de catálogo, mas você pode continuar a usar cópias na Amazon . / p>

Uma resposta simples para sua pergunta é tão antiga quanto Aristóteles: Natureza detesta um vácuo . Por mais que as máquinas tenham ficado cada vez mais rápidas, o software ficou cada vez mais lento.

Para ser mais construtivo, o que propus foi que a teoria da informação e sua relevância direta para o software sejam parte da educação em ciência da computação. Só é ensinado agora, se é que é, de uma maneira muito tangencial.

Por exemplo, o comportamento big-O dos algoritmos pode ser compreendido de forma clara e intuitiva se você pensar em um programa como um canal de informação do tipo Shannon, com símbolos de entrada, símbolos de saída, ruído, redundância e largura de banda. p>

Por outro lado, a produtividade de um programador pode ser entendida em termos similares usando a teoria da informação de Kolmogorov. A entrada é uma estrutura conceitual simbólica em sua cabeça, e a saída é o texto do programa que sai pela ponta dos dedos. O processo de programação é o canal entre os dois. Quando o ruído entra no processo, cria programas inconsistentes (bugs). Se o texto do programa de saída tiver redundância suficiente, ele poderá permitir que os bugs sejam capturados e corrigidos (detecção e correção de erros). No entanto, se for demasiado redundante, é demasiado grande e o seu tamanho, combinado com a taxa de erro, causa a introdução de erros. Como resultado desse raciocínio, passei uma boa parte do livro mostrando como tratar a programação como um processo de design de linguagem , com o objetivo de poder definir as linguagens específicas do domínio apropriadas para uma necessidade. Nós fazemos o serviço de boca a boca para linguagens específicas de domínio na educação em CS, mas, novamente, é tangencial.

Construir idiomas é fácil. Toda vez que você define uma função, classe ou variável, você está adicionando vocabulário ao idioma com o qual começou, criando um novo idioma para trabalhar. O que geralmente não é apreciado é que o objetivo seja fazer com que a nova linguagem se aproxime mais da estrutura conceitual do problema. Se isso for feito, então ele tem o efeito de encurtar o código e torná-lo menos problemático, simplesmente porque, idealmente, existe um mapeamento 1-1 entre os conceitos e o código. Se o mapeamento for 1-1, você pode cometer um erro e codificar um conceito incorretamente como um conceito diferente, mas o programa nunca irá travar, o que acontece quando ele codifica nenhum requisito consistente .

Não estamos entendendo isso. Para toda a nossa conversa corajosa sobre o design do sistema de software, a proporção entre o código e os requisitos está ficando maior, muito maior.

É verdade que temos bibliotecas muito úteis. No entanto, acho que devemos ser muito circunspectos sobre a abstração. Não devemos presumir que B constrói em A e isso é bom, que se C se baseia em B é ainda melhor. Eu chamo isso de fenômeno de "princesa e ervilha". Empilhar camadas em cima de algo problemático não necessariamente conserta isso.

Para encerrar um longo post, desenvolvi um estilo de programação (que às vezes me deixa em apuros) onde

• A invenção não é uma coisa ruim. É uma coisa boa, como em outros ramos da engenharia. Claro que pode estar criando uma curva de aprendizado para os outros, mas se o resultado geral for uma produtividade melhor, vale a pena.
• Código minimalista estilo haiku. Isso especialmente serve para o design da estrutura de dados. Na minha experiência, o maior problema no software atualmente é a estrutura de dados inchada.

A abstração de alto nível é essencial para alcançar progresso contínuo na computação.

Por quê? Porque os humanos só podem ter muito conhecimento em suas cabeças a qualquer momento. Sistemas modernos e de grande porte só são possíveis hoje porque você pode aproveitar essas abstrações. Sem essas abstrações, os sistemas de software simplesmente entrariam em colapso sob seu próprio peso.

Toda vez que você escreve um método, você está criando uma abstração. Você está criando um pouco de funcionalidade que está oculto por trás de uma chamada de método. Por que você os escreve? Como você pode testar o método, prove que ele funciona e, em seguida, invoque essa funcionalidade sempre que quiser, apenas fazendo a chamada do método, e não precisa mais pensar sobre o código que está dentro desse método.

Nos primórdios da computação, usamos linguagem de máquina. Nós escrevemos programas muito pequenos, com um conhecimento íntimo do hardware para o qual estávamos escrevendo. Foi um processo meticuloso. Não houve depuradores; seu programa geralmente funcionava ou falhava. Não havia GUI; tudo era linha de comando ou processo em lote. O código que você escreveu funcionaria apenas nessa máquina específica; não funcionaria em uma máquina com um processador ou sistema operacional diferente.

Então escrevemos linguagens de alto nível para abstrair todos esses detalhes. Criamos máquinas virtuais para que nossos programas pudessem ser portáveis para outras máquinas. Criamos a coleta de lixo para que os programadores não precisassem ser tão diligentes no gerenciamento de memória, o que eliminou toda uma classe de bugs difíceis. Adicionamos a verificação de limites a nossos idiomas para que os hackers não pudessem explorá-los com saturações de buffer. Nós inventamos a Programação Funcional para que pudéssemos raciocinar sobre nossos programas de uma maneira diferente e redescobri-lo recentemente para aproveitar melhor a simultaneidade.

Toda essa abstração isola você do hardware? Claro que sim. Morar numa casa em vez de montar uma tenda te isola da natureza? Absolutamente. Mas todo mundo sabe por que eles moram em uma casa em vez de em uma barraca, e construir uma casa é um jogo completamente diferente do que montar uma barraca.

No entanto, você ainda pode lançar uma tenda quando é necessário fazer isso, e na programação, você pode (se você estiver inclinado) ainda cair para um nível mais próximo do hardware para obter benefícios de desempenho ou memória você pode não conseguir em seu idioma de alto nível.

Você pode abstrair demais? "Ultrapassa o encanamento", como Scotty diria? Claro que você pode. Escrever boas APIs é difícil. Escrever boas APIs que incorporam de forma correta e abrangente o domínio do problema, de uma maneira intuitiva e detectável, é ainda mais difícil. Empilhar novas camadas de software nem sempre é a melhor solução. Padrões de Design de Software , em certa medida, pioraram essa situação, porque desenvolvedores inexperientes às vezes os alcançam quando são mais nítidos e mais enxutos. ferramenta é mais apropriada.

Realmente bom treinamento envolve ambos os extremos, bem como uma ponte entre.

No lado de baixo nível: como um computador executa o código a partir do zero *, incluindo o conhecimento da linguagem assembly e o que o compilador está fazendo.

No lado de alto nível: conceitos gerais, por exemplo usando matrizes associativas, fechamentos, etc. sem ter que perder tempo se preocupando sobre como funciona sob o capô.

No que diz respeito ao aspecto da complexidade: Eu acho que é muito fácil hoje em dia fazer sistemas complexos sem um compreensão clara do custo de fazê-lo . Como resultado, nós, como sociedade, construímos uma enorme quantidade de dívida técnica que nos ataca de tempos em tempos . É como terremotos (apenas o custo de viver perto de uma falha geológica, certo?), Só que está gradualmente piorando. E eu não sei o que fazer sobre isso. Idealmente, aprenderíamos e ficaria melhor administrando a complexidade, mas não acho que isso vá acontecer. Uma educação de engenharia responsável precisa incluir muito mais discussões sobre as conseqüências da complexidade do que a maioria de nossas universidades está fornecendo atualmente.

* e, de qualquer forma, onde está o "chão" em como um computador executa o código? É linguagem assembly? Ou arquitetura de computadores? Ou lógica digital? Ou transistores? Ou física de dispositivos?

Eu sinto que a programação de alto nível tem muitas vantagens e é uma parte essencial de uma linguagem de programação. Uma das razões pelas quais o Java se tornou bem-sucedido é que ele possui uma biblioteca abrangente. Você consegue mais com menos código - basta chamar uma função predefinida.

Agora podemos distinguir usuários de linguagens de programação de escritores de linguagem de programação (escritores de compiladores). Deixamos as otimizações para os escritores do compilador. Nós nos concentramos mais na manutenção, reutilização, etc.

O aumento na complexidade dos sistemas é implacável, opressivo e, em última instância, incapacitante. Para mim, como programador de geração mais antiga, também é amargamente decepcionante.

Eu tenho programado por mais de 40 anos, tendo escrito código em 50-100 idiomas diferentes ou dialetos, e me tornei especialista em 5-10. A razão pela qual eu posso reivindicar tantos é que na maioria eles são apenas a mesma língua, com ajustes. Os ajustes adicionam complexidade, fazendo com que cada idioma seja um pouco diferente.

Implementei os mesmos algoritmos inúmeras vezes: coleções, conversões, ordenação e pesquisa, codificação / decodificação, formatação / análise, buffers e strings, aritmética, memória, E / S. Cada nova implementação adiciona complexidade, porque cada um é um pouco diferente.

Aprendi meu ofício na era das linguagens de quarta geração, onde acreditávamos genuinamente que produziríamos uma sucessão de linguagens de nível mais alto e mais alto para capturar cada vez mais as partes repetitivas do software de escrita. Então como foi exatamente isso?

A Microsoft e a IBM eliminaram essa idéia, retornando ao C para escrever aplicativos para Windows e OS / 2, enquanto o dBase / Foxpro e até mesmo o Delphi se enfraqueciam. Em seguida, a Web fez isso novamente com seu trio final de linguagens assembly: HTML, CSS e JavaScript / DOM. Tem sido tudo a partir daí. Sempre mais idiomas e mais bibliotecas e mais estruturas e mais complexidade.

Sabemos que devemos fazer isso de forma diferente. Sabemos sobre CoffeeScript e Dart, sobre Less e Sass, sobre template para evitar escrever HTML. Nós sabemos e fazemos de qualquer maneira. Temos nossas estruturas, cheias de abstrações gotejantes, e vemos que maravilhas podem ser feitas por aqueles poucos escolhidos que aprendem os encantamentos arcanos, mas nós e nossos programas estamos presos às decisões tomadas no passado. É muito complicado mudar ou começar de novo.

Em resposta à sua pergunta final, eu aconselharia strongmente que os programadores mais jovens começassem o mais alto possível no bolo de camadas, e só mergulhassem nas camadas mais baixas à medida que a necessidade e o desejo fornecessem o ímpeto. Minha preferência é para idiomas sem loops, pouca ou nenhuma ramificação e estado explícito. Lisp e Haskell vêm à mente. Na prática, sempre termino com C # / Java, Ruby, Javascript, Python e SQL, porque é onde as comunidades estão.

Palavras finais: a complexidade é o inimigo final! Bata isso e a vida se torna simples.

My question though is how do people feel about this "hiding" of lower-level elements. Do you older programmers see it as a godsend or an unnecessary layer to get through?

Nenhum dos dois, realmente.

A estratificação é necessária porque, sem ela, você alcança um ponto em que seu sistema se torna um espaguete inatingível. É também um dos princípios da reutilização: se o desenvolvedor de uma biblioteca fez um bom trabalho, as pessoas que o usam não devem se preocupar com os detalhes da implementação. A quantidade de código enlatado que usamos em nossos sistemas cresceu em termos de mangitude do que era quando escrevi meu primeiro programa há 35 anos. Esse crescimento significa que somos capazes de fazer coisas mais poderosas com o passar do tempo. Isso é bom.

O lugar onde tem sido um problema para mim é totalmente cultural. Minha metade pragmática entende que não é mais possível pensar em todos os detalhes e poder terminar as coisas que quero fazer. (Envelhecer também não ajuda.) Minha rabugenta barba grisalha teve dificuldade em abrir mão de muitos anos de ter uma compreensão tão minuciosa de tudo em que trabalhei.

Do you think younger programmers would benefit more learning low-level programming BEFORE exploring the realms of expansive libraries?

Como foi apontado em outras respostas, há um equilíbrio a ser alcançado entre atrair e manter a atenção dos neófitos e dar-lhes uma educação ideal, de baixo para cima. Se você não pode fazer o primeiro, o último não pode acontecer.

Eu vejo as coisas em nossa indústria que são paralelas ao resto da sociedade. Costumava ser que quase todo mundo cultivava sua própria comida e passava muito tempo fazendo isso. Desde então, brotamos especialistas chamados agricultores que fazem esse trabalho, liberando outros para fazer outras coisas que contribuem para a sociedade. Eu compro minha comida em uma mercearia e seria completamente incapaz de produzir a maior parte sozinha se eu precisasse. Temos uma coisa semelhante acontecendo, embora em uma escala de tempo muito mais comprimida. Os programadores estão se especializando em algum conjunto de camadas e não em outros. O cara médio escrevendo GUIs pode saber que existe tal coisa como espaço de troca, mas provavelmente não sabe ou se importa muito sobre como o sistema operacional está gerenciando isso.

O resultado de tudo isso é que não se trata apenas de desenvolvimento. A especialização contínua significa que os desenvolvedores precisarão continuar melhorando suas habilidades de comunicação e integração.

Como com tudo, um pouco faz bem, mas muito dói. O problema é que muitos sistemas não sabem quando parar - apenas mais 1 abstração, para ajudá-lo a programar mais rápido ... mas depois você acaba codificando no mundo real, onde as coisas nunca são tão simples quanto você quer, e você gaste mais tempo trabalhando nas bordas do que você gastaria com uma abstração com menos recursos.

É habilmente descrito aqui

ou aqui - "com uma única linha de código você pode adicionar 500 usuários ao domínio". .

Suas abstrações tentam esconder a complexidade de você, mas na verdade tudo o que elas fazem é esconder essa complexidade. A complexidade ainda está lá, é só que você tem muito menos controle sobre isso - e é por isso que você acaba com esse tipo de situação.

Do younger programmers benefit more learning low-level programming BEFORE exploring the realms of expansive libraries? If so then why?

Eu não penso assim. Ainda há muitas situações em que é benéfico estar ciente de que a camada abaixo da "funciona abaixo", por exemplo,

• Ao depurar um problema na camada n , isso pode ser explicado considerando o que acontece na camada n-1 (ou seja, a camada abaixo). Eu acho que a camada 0 seria "transistores", mas se você quiser explicar um problema com transistores você provavelmente fala sobre física (por exemplo, calor), então talvez a física seja realmente nível 0.

• Ao otimizar o código, (infelizmente) ajuda a diminuir o nível de abstração, isto é, implementar um algoritmo em termos de uma camada de nível inferior. No entanto, os compiladores tornaram-se realmente bons em fazer isso para você se eles realmente verem todo o código envolvido. Esse motivo tornou-se mais popular recentemente com o boom de dispositivos móveis e incorporados, que tendem a ter processadores mais fracos e onde o "desempenho por Watt" é muito mais relevante do que, digamos, em sistemas desktop.

Uma grande motivação na linguagem de programação e no design da biblioteca (ou seja, API) é facilitar as coisas no cérebro humano. Até hoje, tudo ainda é compilado em código de máquina. No entanto, isso não é apenas propenso a erros, também é notoriamente difícil de entender. Então é muito desejável para

• Peça ao computador que o ajude a encontrar erros lógicos nos programas que você escreve. Coisas como sistemas de tipo estático ou analisadores de código fonte (eu ouço Eric Lippert funciona em um bastante popular nos dias de hoje) ajuda com isso.

• Tenha uma linguagem que possa ser processada eficientemente por um compilador e que comunique a intenção do programador a outros programadores para facilitar o trabalho no programa. Como um extremo absurdo, imagine que escrever programas em inglês simples é possível. Outros programadores podem ter um tempo mais fácil para imaginar o que está acontecendo, mas ainda assim, a descrição seria muito difícil de compilar em instrutores de máquina, e é notoriamente ambígua. Então você precisa de uma linguagem que um compilador possa entender, mas que seja também compreensível.

Dado que muitos (mais?) compiladores ainda são de propósito geral, eles possuem um conjunto de instruções muito genérico. Não há instrução "desenhar um botão" ou "reproduzir este filme". Portanto, mover para baixo a hierarquia de abstração faz com que você acabe com programas que são muito difíceis de compreender e manter (embora sejam triviais para compilar). A única alternativa é mover para cima a hierarquia, levando a mais e mais linguagens e bibliotecas abstratas.

"se programadores mais antigos enxergarem inovações como essas como uma dádiva de Deus ou uma camada adicional para abstrair, e por que eles poderiam pensar assim?"

Eu tenho programado desde que eu estava no ensino médio, cerca de 34 anos, começando com Basic e Z80 Assembler, passando para C, várias linguagens 4GL, Scheme, SQL e agora várias linguagens da Web. O alcance, a escala e a profundidade dos problemas enfrentados pela profissão experimentaram um período inflacionário durante esse período, particularmente nos anos 90. Construções como bibliotecas, estruturas e serviços de sistema operacional são todos os recursos destinados a abordar a complexidade que acompanha o espaço expandido de problemas. Eles não são uma dádiva de Deus nem um fardo em si - apenas uma exploração contínua de um vasto espaço de solução.

Mas, IMHO, "inovação" é melhor compreendida em termos de novas formas, e não confundida com movimento lateral - reintroduzindo formas que já vimos introduzidas. De certa forma, a fecundidade de um ecossistema sofre quando as formas primitivas não compõem, quando fixam decisões tomadas no início da evolução, ou não conseguem reprocessar seus próprios detritos. Alguns, se não a maioria, dos construtos nos quais continuamos focados não priorizam o sustento a longo prazo do valor como uma preocupação. Isso começou a mudar - abordagens como Service Orientation e Domain Driven Design, para não falar de modelos baseados em hipertexto e gráficos, por exemplo, estão alterando o cenário. Como qualquer ecossistema, eventualmente as formas dominantes darão lugar a novas formas; somos mais bem servidos, permitindo a diversidade, de forma ampla e em pequenos incrementos, em vez da padronização de cima para baixo em grande escala, seguida pelo colapso de uma vez por todas.

"E os programadores mais jovens se beneficiam mais com a programação de baixo nível antes de explorar os domínios das bibliotecas expansivas? Se sim, então por quê?"

OTOH, mesmo que seu objetivo seja trabalhar como nível técnico / mecânico, algum nível de exposição de programação de baixo nível ainda será útil para desenvolver suas habilidades de resolução de problemas.

Meu primeiro programa (como um adolescente de 15 anos) foi em 1974 em PL / 1 em cartões perfurados para um mainframe IBM 370/168. Meu pai trabalhava na IBM e tive a sorte de poder ir ao datacenter aos domingos.

Naquela época, um programa de vários milhares de declarações (ou seja, cartões empunhados) era um grande programa (e também pesado, já que muitos milhares de cartões perfurados pesavam muitos quilos). Interfaces visuais não existiam (um programa típico lido a partir de sua "entrada padrão" usando um comando de cartão perfurado começando com //GO.SYSIN DD * IIRC, mas eu não dominava JCL ). Algoritmia era importante, e a biblioteca padrão do IIRC era bem pequena para o padrão atual.

Hoje, programas de milhares de linhas são geralmente considerados pequenos. Por exemplo, o compilador GCC tem mais de dez milhões de linhas de código-fonte, e ninguém está compreendendo-as totalmente .

Meu sentimento é que a programação hoje é bem diferente dos anos 70, porque você precisa usar muito mais recursos (em particular, bibliotecas existentes e frameworks de software). No entanto, acho que as pessoas que desenvolvem software de datacenter (por exemplo, os mecanismos de pesquisa do Google) ou algum software incorporado se preocupam tanto com algoritmos e eficiência quanto com o programador médio da década de 1970.

Eu ainda acho que entender a programação de baixo nível é importante até hoje (mesmo que a maioria dos programadores não codifique algoritmos básicos de contêiner como árvores balanceadas, matrizes ordenadas acessadas dicotomicamente, etc ...) porque entender todo o quadro ainda é importante.

Uma grande diferença entre a década de 1970 e hoje é a relação de custo entre os esforços (humanos) do desenvolvedor e o poder do computador.