A ciência da Ciência da Computação está morta? [fechadas]

Pergunta: A ciência e a arte de CS estão mortas? Com isso, quero dizer que os requisitos reais para pensar, planejar e resolver problemas com eficiência parecem estar se afastando do CS atualmente. O campo parece estar diminuindo a barreira de entrada para que mais pessoas possam 'programar' sem ter que aprender a programar de verdade.

Formação: Sou recém-formado com bacharelado em Ciência da Computação. Estou trabalhando em uma posição inicial em uma empresa de tamanho decente no departamento de TI. Eu principalmente faço .NET e outras tecnologias da Microsoft no meu trabalho, mas antes disso eu fiz coisas de Java por meio de estágios e similares. Pessoalmente, sou um programador de C ++ para meus próprios projetos divertidos.

Em Profundidade: Através do trabalho que tenho realizado, parece-me que as disciplinas intensas de uma ciência real não existem mais no CS. No passado, os programadores tinham que resolver problemas com eficiência para que os sistemas fossem robustos e rápidos. Mas agora, com as tecnologias predominantes como .NET, Java e linguagens de script, parece que eficiência e robustez foram trocadas por facilidade de desenvolvimento.

A maioria dos colegas com quem trabalho nem se formou em Ciência da Computação. A maioria se formou em engenharia elétrica, alguns com engenharia de software, mesmo alguns que vieram de escolas de tecnologia sem um programa de quatro anos. No entanto, eles se dão muito bem sem ter o conhecimento técnico do CS, sem ter estudado teorias e algoritmos, sem ter nenhuma consideração em criar uma solução elegante (eles apenas buscam a solução mais fácil e barata).

A empresa nos incentiva a usar as tecnologias da Microsoft, que retiram todo o pensamento real do problema e o substituem por bibliotecas e ferramentas que podem criar seu projeto automaticamente para você na metade do tempo. Não estou tentando odiar as linguagens, entendo que elas servem a um propósito e o fazem bem, mas quando seus funcionários não sabem como uma tabela de hash funciona, usam métodos de classificação incorretos ou executam comandos SQL que são terrivelmente ineficientes (mas fazem o trabalho em um tempo aceitável), parece que mais esforço está sendo feito no desenvolvimento de tecnologias que ofereçam novos 'programadores' em vez de realmente ensinar às pessoas como fazer as coisas corretamente.

Estou interessado em tornar programas eficientes e, na minha opinião, bonitos. Se houver uma maneira melhor de fazê-lo, prefiro voltar e refatorá-lo do que deixá-lo deslizar. Mas no mundo corporativo, eles me pressionam a concluir as tarefas rapidamente e não com elegância. E isso realmente me incomoda.

É isso que eu vou esperar pelo resto da minha vida? Ainda existem posições por aí para pessoas que amam a ciência e a arte do CS em vez de apenas o salário?

E na mesma nota, aqui está uma boa leitura, se você ainda não a viu antes de The Perils Of Java Schools

Sim e não

Boa pergunta, mas suposição ruim.

A parte de Ciência da educação parece estar faltando, mas a suposição de que a ciência estava lá apenas para tornar os programas eficientes é equivocada.

A ciência era necessária para ensinar as pessoas a definir e resolver problemas.

Infelizmente, essa parte de alguns currículos de "CS" (currículos?) Parece ser completamente omitida, substituída por problemas de brinquedo por soluções triviais ou conhecidas e destinada apenas a ensinar familiaridade com ferramentas

Decepcionante; muitos graduados em Java foram enganados, nunca ensinaram como decompor um problema, projetar um algoritmo, especificar um teste ou até mesmo depurar efetivamente.

A ciência da Ciência da Computação está morta? "..." Sou recém-formado com um BS em Ciência da Computação. Estou trabalhando em uma posição inicial em uma empresa de tamanho decente no departamento de TI .

Honestamente, meus dois centavos: você não encontrará a "ciência" da ciência da computação trabalhando em um departamento de TI de uma empresa de tamanho decente, porque é o departamento de TI, não o departamento de CS. Tente voltar à escola para fazer um doutorado ou trabalhar nos departamentos de engenharia de uma empresa cujo foco é ciência da computação (por exemplo, processamento de imagem, redes de alto desempenho, sistemas de álgebra computacional, aeroespacial, etc ...). É aqui que você encontrará os problemas difíceis e interessantes em que o design desleixado [geralmente] não será tolerado.

"Ainda existem posições por aí para pessoas que amam a ciência e a arte do CS, em vez de apenas o salário?"

Sim, absolutamente, mas provavelmente não nos departamentos de TI de empresas de médio porte.

Se você é um programador, não se considere um "cientista da computação"; são os cientistas da computação que estão criando a próxima geração de computadores, alguns dos quais ainda são ficção científica até que a mistura correta de materiais, miniatuização e teoria computacional seja obtida. Eles são apenas o começo do pipeline. As pessoas que desenvolvem software aqui e agora são "engenheiros de software"; eles levam as teorias e ferramentas, às vezes colocando a teoria prática e as ferramentas do mundo real no topo, para aproveitar o poder em potentia dessa complexa peça de magia eletroínica e fazê-la fazer o que queremos. Essa é, por sua vez, uma especialização do campo da "engenharia da computação", que utiliza as teorias dos cientistas da computação e as aplica, hardware e software, a soluções eletrônicas do usuário final do mundo real.

É na IMO que os negócios encontram a teoria. Nesses tipos de casos, o velho ditado "o inimigo de melhor é bom o suficiente" pode ser facilmente mudado para ler "o inimigo de melhor é bom". Considerar-se um "engenheiro" em vez de um "cientista" e colocar o que você faz em paralelo com outras disciplinas de engenharia lança as diferenças em relevo.

Digamos que um cliente chegue até você, um engenheiro civil / estrutural, e peça para você construir uma ponte. A ponte precisa se estender por 20 pés, sustentar-se e transportar uma tonelada de carga, deve durar 10 anos com manutenção de rotina e eles a querem em um mês por US $ 20.000. Essas são suas restrições; atender aos mínimos, sem exceder os máximos. Fazer isso é "bom o suficiente" e recebe o salário. Seria uma engenharia ruim para você construir a Ponte Golden Gate, excedendo em muito as especificações de projeto e o orçamento em várias ordens de magnitude. Você geralmente acaba comendo os custos excedentes e pagando multas por excesso de tempo. Também seria uma má engenharia para você construir uma ponte de corda com o peso de cinco homens adultos, mesmo que custe apenas US $ 1000 em tempo e materiais; você não recebe boas críticas e depoimentos de clientes,

De volta ao software, digamos que você tenha um cliente que precisa de um sistema de processamento de arquivos criado para digerir os arquivos que entram e colocar as informações no sistema. Eles querem isso em uma semana e precisam lidar com cinco arquivos por dia, com cerca de 10 MB de dados, porque esse é todo o tráfego que eles recebem atualmente. Suas preciosas teorias vão amplamente pela janela; sua tarefa é criar um produto que atenda a essas especificações em uma semana, pois, ao fazer isso, você também atende ao orçamento de custos do cliente (como os materiais geralmente são uma gota no balde para um contrato de software desse tamanho). Passar duas semanas, mesmo com dez vezes o ganho, não é uma opção, mas o mais provável é que não seja um programa criado em um dia que possa lidar apenas com metade da taxa de transferência, com instruções para ter duas cópias em execução.

Se você acha que esse é um caso marginal, está errado; esse é o ambiente diário da maioria dos alojamentos internos. O motivo é o ROI; esse programa inicial não custa muito e, portanto, se paga muito rapidamente. Quando os usuários finais precisam fazer mais ou ir mais rápido, o código pode ser refatorado e redimensionado.

Essa é a principal razão por trás do estado atual da programação; a suposição, confirmada por toda a história da computação, é que um programa nunca é estático. Ele sempre precisará ser atualizado e, eventualmente, será substituído. Paralelamente, o aprimoramento constante dos computadores nos quais os programas são executados permite diminuir a atenção à eficiência teórica e aumentar a atenção à escalabilidade e paralelização (um algoritmo que é executado no tempo do quadrado N, mas que pode ser paralelo para rodar nos N núcleos). parecem lineares e, geralmente, o custo de mais hardware é mais barato que o dos desenvolvedores para criar uma solução mais eficiente).

Além disso, existe o princípio muito simples de que toda linha de código de desenvolvedor é outra coisa que pode dar errado. Quanto menos um desenvolvedor escreve, menos provável é que o que ele escreve tenha um problema. Isso não é uma crítica à "taxa de erros" de ninguém; é uma simples afirmação de fato. Você pode saber como escrever um MergeSort para frente e para trás em 5 idiomas, mas se você digitar apenas um identificador em uma linha de código, a Classificação inteira não funcionará, e se o compilador não o capturar, poderá levar você horas para depurá-lo. Compare isso com List.Sort (); está lá, é eficiente no caso geral e, aqui está a melhor coisa, já funciona.

Portanto, muitos dos recursos das plataformas modernas e princípios das metodologias de design modernas foram criados com isso em mente:

• OOP - construa dados e lógica relacionados em um objeto, e sempre que o conceito desse objeto for válido, ele será o objeto ou uma derivação mais especializada.
• Modelos pré-criados - um bom código de 60% ou mais é uma crença sintática e o básico para fazer o programa mostrar algo na tela. Ao padronizar e gerar automaticamente esse código, você reduz a carga de trabalho do desenvolvedor pela metade, permitindo um aumento na produtividade.
• Bibliotecas de algoritmos e estruturas de dados - Como descrito acima, você pode saber como escrever uma pilha, fila, QuickSort etc., mas por que precisa, quando há uma biblioteca de códigos com tudo isso incorporado? Você não reescreveria o IIS ou o Apache porque precisava de um site; então, por que implementar um algoritmo QuickSort ou um objeto em árvore vermelho-preto quando várias excelentes implementações estão disponíveis?
• Interfaces fluentes - Na mesma linha, você pode ter um algoritmo que filtra e classifica os registros. É rápido, mas provavelmente não é muito legível; o desenvolvedor júnior levaria um dia apenas para entendê-lo e muito menos fazer as alterações cirúrgicas necessárias para classificar em um campo adicional no objeto de registro. Em vez disso, bibliotecas como o Linq substituem muitos códigos muito feios e quebradiços por uma ou duas linhas de chamadas de método configuráveis ​​para transformar uma lista de objetos em objetos projetados filtrados, classificados e projetados.

Parece-me que você está fazendo TI, e não CS, e isso não implica que CS esteja morto. O CS não está morto, apenas a maioria dos trabalhos está no desenvolvimento de software. Como a maioria dos estudantes de CS aprende a programar, eles geralmente acabam contratando como programadores e não como cientistas da computação. Os trabalhos de Ciência da computação são minúsculos em comparação aos trabalhos de programação. Você pode até criar um aplicativo complexo usando técnicas de ciência da computação, mas na minha opinião (e eu não gosto de respostas de opinião porque são subjetivas), isso cai no campo da engenharia do que no campo dos cientistas.

Além disso, um código bonito e elegante está nos olhos de quem vê , mas para a maioria das empresas / gerentes, ter um design suficientemente bom no prazo é muito mais importante que o código bonito, mas nunca termina no prazo.

Por fim, existe o mundo real e a terra do lala. Infelizmente, recebemos o salário do primeiro e é aí que entra a "ciência / arte" do desenvolvimento de software sobre como produzir alta qualidade de software com restrições de tempo / orçamento. Senti o mesmo tipo de sentimento que você tem no início da minha carreira. Eu sempre quis criar "o melhor", mas logo percebi que "o melhor" não é o mais eficiente ou elegante, mas o design mais econômico.

Primeiro de tudo, você entendeu errado. "pensar, planejar e resolver problemas com eficiência" não é ciência, é engenharia. A ciência tem muito mais a ver com explorar novos campos. E, na verdade, no mundo acadêmico, as pessoas se preocupam muito menos com a eficiência do código do que na indústria. Na academia, é mais uma prova de conceitos, etc.

Não, o que você está descrevendo é que é necessário menos conhecimento aprofundado para o desenvolvimento de software. O que pode ser verdade, se os requisitos forem os mesmos. Atualmente, porém, espera-se que o engenheiro de software saiba como lidar com multi-threading, computação distribuída, dimensionamento etc. Eles devem saber como liderar o projeto com eficiência. A maior parte disso não estava nos currículos poucas décadas atrás.

Eu não acho que o que você disse esteja exatamente certo, mas você tem alguma razão . Penso que, com o tempo, a ciência da computação e a engenharia de software se separaram.

Engenharia de software (como outra engenharia) tem a ver com a aplicação da ciência para criar produtos, resolver problemas, etc. A ciência da computação é principalmente sobre pesquisa de algoritmos e (embora essa parte seja muitas vezes esquecida) como implementar esses algoritmos (pelo menos em algum sentido teórico) por exemplo, talvez tratando todas as máquinas PRAM como equivalentes).

Tendo isso em mente, acho que a razão por trás da bifurcação se torna aparente: a maioria dos problemas algorítmicos envolvidos em algo como um site típico já foi resolvida - a maioria deles há muito tempo. Talvez o mais importante seja que a maioria deles tenha sido resolvida o suficiente para que, para um desenvolvedor web comum, o problema tenha desaparecido quase completamente. Por exemplo, fazer atualizações atômicas em bancos de dados distribuídos é definitivamente uma tarefa não trivial - mas um desenvolvedor web típico apenas escreve um pouco de SQL e não tem idéia (ou se importa) com quanta pesquisa foi necessária para descobrir como fazer o trabalho de forma confiável.

Ao mesmo tempo, era essencialmente impossível separar a ciência da computação da engenharia de software. Tão poucos problemas foram resolvidos que escrever um programa relativamente trivial exigia pesquisas sobre os fundamentos. Se você quisesse fazer algo tão simples quanto classificar um monte de dados no final dos anos 50 ou início dos anos 60, as chances eram muito boas de que você precisaria fazer uma análise dos seus dados e tentar projetar um algoritmo que se encaixa da melhor forma possível com o que seria necessário para classificar esses dados em particular - nem perto do número de algoritmos de classificação conhecidos hoje, e mesmo os algoritmos conhecidos não eram tão conhecidos quanto hoje. .

Porém, 50 anos de pesquisa e desenvolvimento valeram a pena - o desenvolvimento mais típico pode usar não apenas algoritmos conhecidos, mas implementações pré-escritas. A maioria dos problemas típicos pode ser resolvida razoavelmente com base no conhecimento existente (e até mesmo nas implementações existentes) de algoritmos.

Isso não significa que a ciência da computação esteja morta - ainda existem mais algoritmos para pesquisar e pessoas fazendo pesquisas neles. Isso significa, no entanto, que a maioria das pesquisas é mais especializada e provavelmente se aplica a áreas bastante especializadas. Provavelmente também há uma "lacuna" maior entre adquirir e aplicar o conhecimento. Ao mesmo tempo, você descobriu uma maneira melhor de classificar no processo de escrever um programa de classificação, e ele foi gravado em código real quase imediatamente. Agora, muita ciência da computação é dedicada a coisas como usar um número essencialmente infinito de processadores - o que provavelmente será útil um dia, mas mesmo as tribos primitivas não considerariam os dois núcleos do meu computador como "muitos" ... :-)

Desenvolvimento de software e ciência da computação não são a mesma coisa, e eu descobri que a maioria dos meus colegas de classe em um B.Sc. O programa Comp Sci ficou frustrado com isso.

Penso no software como um produto da ciência da computação ... como pinturas são um produto da arte visual.

Eu acho que a maioria das pessoas com formação em CS é contratada para trabalhar no desenvolvimento de software, especialmente nos estágios iniciais de suas carreiras. Eu acho que muitas pessoas nessa função ficam lá e não vão mais longe.

Eu acho que a diferença começa a aparecer quando novos problemas ou paradigmas aparecem ou quando "bater juntos" não é bom o suficiente. Quem constrói os novos frameworks ou idiomas? Quem se senta e medita os detalhes de um novo mecanismo de física? Quem usa a teoria de grafos / transformações de grafos para extrair alguns ciclos por iteração de desempenho de um algoritmo?

Terminarei por onde comecei, concordando que existem muitos cientistas da computação em funções de desenvolvimento / engenharia de software, talvez não cumprindo seu potencial.

Você parece confundir ciência da computação com programação e desenvolvimento de software em geral. Os dois não são os mesmos, nem chegam perto. Independentemente do que nossos diplomas possam dizer, a grande maioria de nós somos programadores, não cientistas da computação. A menos que você esteja ativamente envolvido na academia em um nível alto, eu apostaria que você realmente não tem idéia do que está acontecendo na ciência da computação.

Posso dizer que a Ciência da Computação está viva e bem. Eu tenho que resolver novos problemas diariamente e encontrar uma solução eficaz e elegante para esses problemas. Eu tenho que usar minhas habilidades como engenheiro diariamente e usar o conhecimento de mim e de meus colegas para resolver esses problemas para o nosso cliente.

Não estou tentando odiar as linguagens, entendo que elas servem a um propósito e o fazem bem, mas quando seus funcionários não sabem como uma tabela de hash funciona, usam métodos de classificação incorretos ou executam comandos SQL que são terrivelmente ineficientes (mas fazem o trabalho em um tempo aceitável), parece que mais esforço está sendo feito no desenvolvimento de tecnologias que ofereçam novos 'programadores' em vez de realmente ensinar às pessoas como fazer as coisas corretamente.

Isso parece um problema com o funcionário e certamente não é verdadeiro para todos os programadores.

Só porque existem ferramentas que facilitam nosso trabalho não significa que não devemos entender a tecnologia de sublinhado; caso contrário, não estamos ajudando ninguém e, certamente, não estamos fazendo nosso trabalho na solução de problemas da maneira correta.

Você simplesmente não entendeu o problema em questão. O problema não é obter o desempenho máximo - está obtendo desempenho suficiente para que seu aplicativo seja responsivo e rápido o suficiente. Aprender a programar é resolver o problema, pela menor quantia de dinheiro.

Eu odeio dizer dessa maneira, mas qualquer impressão que você tenha sobre a morte do CS é apenas suas próprias pré-concepções sobre o que um programador "real" deve ter que fazer.

Bem, morto ou não, é discutível!

O fato é que, na era tecnológica atual, a maioria das empresas contrata pessoas para resolver tarefas do tipo fluxo de trabalho no mundo real por meio da automação de software. Eles não estão interessados ​​em quão elegante ou mais rápido um programa você pode escrever, desde que permita que a empresa execute mais rapidamente com maior produtividade.

O estresse está em mais produção em menos tempo. (Pense na comercialização de culturas / alimentos; crescimento mais rápido e mais com menos custo). O mesmo está acontecendo no mundo da tecnologia (a próxima nova idéia).

Lembre-se, hoje em dia, as coisas estão se movendo mais rápido do que nunca, devido à quantidade e acesso ao conhecimento do que antigamente. Naquela época, a produção era pequena e melhor, os lucros eram maiores. Agora, o jogo mudou completamente. Basta olhar para coisas como a qualidade do serviço ao cliente e, em geral, as coisas não duram mais.

Elegância e eficiência são importantes para empresas de tecnologia como o Google etc., mesmo que esses lugares não sejam perfeitos, mas você pode se aproximar trabalhando com uma dessas empresas nos próximos anos.

Sempre há uma troca na vida. Você pode encontrar um emprego que paga menos, onde você tem todo o tempo e atenção. Ou você escolhe nadar conosco para pagar melhor e ignorar coisas que não são perfeitas. Quanto mais rápido essa percepção afundar em você, você poderá se preparar para o mundo real. Não estou dizendo que você deva ignorar qualidade e elegância, mas conhecer a dinâmica. Você será mais feliz :)

Na minha opinião, algumas das coisas mais interessantes que o futuro possa ter certamente se basearão na parte científica da ciência da computação, especificamente na visão computacional / aprendizado de máquina e em outros algoritmos de sematisização. Provavelmente, eles serão promovidos na indústria (por exemplo, o Microsoft Kinect), mas são problemas tão difíceis que certamente se basearão no grande corpo de pesquisas e nos progressos realizados pelos acadêmicos (novamente, no Microsoft Kinect).

Eu acho que a programação cotidiana padrão é tanto uma arte quanto uma ciência, mas certamente existem áreas que estão profundamente interessadas nos aspectos científicos da ciência da computação. Por exemplo, pesquisadores de empresas e universidades. Se você realmente quer se envolver profissionalmente nas ciências, deve procurar um doutorado. No entanto, descobri que as partes científicas da minha educação são continuamente valiosas, apesar de também precisar contar com o meu lado mais criativo na realidade!

As pessoas que não sabem o que estão fazendo podem invadir as coisas com algumas das ferramentas mencionadas, mas geralmente contratam pessoas reais de CS para fazer as ferramentas, você só precisa ser mais abstrato para se esforçar.