Наука информатики мертва? [закрыто]

Вопрос: наука и искусство КС мертвы? Под этим я подразумеваю, что реальные требования к мышлению, планированию и эффективному решению проблем, похоже, отстают от CS в наши дни. Похоже, что поле снижает барьер входа, чтобы больше людей могли «программировать», не изучая, как правильно программировать.

Фон: я недавно закончила бакалавриат в области компьютерных наук. Я работаю на стартовой позиции в приличной компании в отделе ИТ. Я в основном работаю с .NET и другими технологиями Microsoft на своей работе, но до этого я занимался вопросами Java через стажировки и тому подобное. Я лично программист на С ++ для своих собственных забавных проектов.

В глубине: благодаря работе, которую я выполняю, мне кажется, что интенсивные дисциплины настоящей науки больше не существуют в CS. В прошлом программистам приходилось эффективно решать проблемы, чтобы системы были надежными и быстрыми. Но теперь, когда преобладают такие технологии, как .NET, Java и языки сценариев, кажется, что эффективность и надежность были заменены на простоту разработки.

Большинство коллег, с которыми я работаю, даже не имеют степени в области компьютерных наук. Большинство из них получили степень по электротехнике, некоторые - по программной инженерии, даже те, кто поступил из технических школ без 4-летней программы. Тем не менее, они прекрасно справляются, не имея технического опыта в CS, не изучая теории и алгоритмы, не имея никакого отношения к принятию элегантного решения (они просто выбирают самое простое и дешевое решение).

Компания подталкивает нас к использованию технологий Microsoft, которые извлекают всю реальную мысль из этого вопроса и заменяют ее библиотеками и инструментами, которые могут автоматически создавать ваш проект в течение половины времени. Я не пытаюсь ненавидеть языки, я понимаю, что они служат цели и делают это хорошо, но когда ваши сотрудники не знают, как работает хэш-таблица, и используют неправильные методы сортировки или запускают команды SQL, которые ужасно неэффективны (но выполняют работу в приемлемое время), кажется, что больше усилий направляется на разработку технологий, которые балуют новых «программистов», а не на самом деле учат людей, как правильно делать вещи.

Я заинтересован в создании эффективных и, на мой взгляд, красивых программ. Если есть лучший способ сделать это, я бы предпочел вернуться и рефакторинг, чем позволить ему скользить. Но в корпоративном мире они подталкивают меня к быстрому, а не элегантному выполнению задач. И это действительно беспокоит меня.

Это то, что я собираюсь ждать до конца своей жизни? Есть ли еще места для людей, которые любят науку и искусство CS, а не просто зарплату?

И на той же ноте, вот хорошее прочтение, если вы не видели его до The Perils Of Java Schools

Да и нет

Хороший вопрос, но плохое предположение.

Научная часть образования, по-видимому, отсутствует, но предположение, что наука была там просто для того, чтобы программы были эффективными, ошибочно.

Наука была необходима, чтобы научить людей определять и решать проблемы.

К сожалению, эта часть некоторых "CS" учебных программ (учебных программ?), По-видимому, полностью опущена, заменена игрушечными задачами с тривиальными или известными решениями и предназначена просто для обучения знакомству с инструментами.

Неутешительный; многие выпускники Java-школы были обделены, никогда не учились разбивать проблемы, разрабатывать алгоритмы, определять тесты или даже эффективно отлаживать.

Наука информатики мертва? "..." Я недавно закончила бакалавриат по информатике. Я работаю на стартовой позиции в приличной компании в отделе ИТ .

Честно говоря, мои собственные два цента: вы не найдете «науку» в области компьютерных наук, работающую в ИТ-отделе приличной компании, потому что это отдел ИТ, а не отдел CS. Попробуйте вернуться в школу для получения степени доктора наук или работы в инженерных отделах компании, специализирующейся на компьютерных науках (например, обработка изображений, высокопроизводительные сети, системы компьютерной алгебры, аэрокосмическая промышленность и т. Д.). Здесь вы найдете сложные, интересные проблемы, когда небрежный дизайн [как правило] не будет допущен.

«Есть ли еще места для людей, которые любят науку и искусство CS, а не просто зарплату?»

Да, конечно, но, вероятно, не в ИТ-отделах средних компаний.

Если вы программист, не считайте себя «ученым-программистом»; Ученые-компьютерщики - это те, кто создает компьютеры следующего поколения, некоторые из которых по-прежнему являются научной фантастикой, пока не будет получено правильное сочетание материалов, миниатюризации и вычислительной теории. Они являются только началом трубопровода. Люди, которые разрабатывают программное обеспечение здесь и сейчас, являются «инженерами программного обеспечения»; они используют теории и инструменты, иногда наслоив практическую теорию и инструменты реального мира, чтобы использовать всю мощь этого сложного куска электроинического волшебства и заставить его делать то, что мы хотим. Это, в свою очередь, одна из специализаций в области «компьютерной инженерии», которая берет теории компьютерных ученых и применяет их, аппаратное и программное обеспечение, к реальным электронным решениям для конечных пользователей.

Это ИМО, где бизнес встречается с теорией. В таких случаях старую поговорку «враг лучшего достаточно хорош» можно легко развернуть, чтобы прочитать «враг хорошего - лучше». Считая себя «инженером», а не «ученым», и помещая то, что вы делаете параллельно с другими инженерными дисциплинами, вы облегчаете различия.

Допустим, к вам приходит клиент, инженер-строитель и просит вас построить мост. Мост должен простираться на 20 футов, выдерживать саму нагрузку и перевозить одну тонну груза, он должен прослужить 10 лет с обычным обслуживанием, и они хотят его в месяц за 20 000 долларов. Это ваши ограничения; Соблюдайте минимумы, не превышая максимумы. Делать это "достаточно хорошо" и получать зарплату. Было бы плохо для вас построить мост Золотые Ворота, который на несколько порядков превзошел бы как проектные характеристики, так и бюджет. Вы обычно в конечном итоге съедаете перерасход средств и платите штрафы за перерасход времени. Кроме того, было бы плохо спроектировать для вас веревочный мост, рассчитанный на вес 5 взрослых мужчин, даже если он стоил всего 1000 долларов во времени и материалах; Вы не получаете хорошие отзывы и отзывы клиентов,

Возвращаясь к программному обеспечению, скажем, у вас есть клиент, которому нужна система обработки файлов, созданная для того, чтобы переваривать входящие файлы и помещать информацию в систему. Они хотят, чтобы это было сделано за неделю, и он должен обрабатывать пять файлов в день, объемом около 10 МБ данных, потому что это весь трафик, который они получают в настоящее время. Ваши драгоценные теории в основном выходят в окно; Ваша задача состоит в том, чтобы создать продукт, который соответствует этим спецификациям в течение недели, потому что таким образом вы также соблюдаете бюджет расходов клиента (поскольку материалы, как правило, не годятся для контракта на программное обеспечение такого размера). Тратить две недели, даже в десять раз больше, это не вариант, но, скорее всего, это не программа, созданная за день, которая может обрабатывать только половину пропускной способности, с инструкцией для запуска двух копий.

Если вы думаете, что это крайний случай, вы ошибаетесь; это повседневная среда большинства домашних работников. Причина в рентабельности инвестиций; эта первоначальная программа не стоит много и, следовательно, очень быстро окупится. КОГДА конечным пользователям нужно больше или быстрее, код можно реорганизовать и масштабировать.

Это основная причина текущего состояния программирования; Предположение, подтвержденное всей историей вычислений, состоит в том, что программа НИКОГДА не является статичной. Он всегда должен быть обновлен, и в конечном итоге он будет заменен. Параллельно постоянное совершенствование компьютеров, на которых работают программы, позволяет снизить внимание к теоретической эффективности и повысить внимание к масштабируемости и распараллеливанию (алгоритм, который выполняется за N-квадрат времени, но который можно распараллелить для работы на N ядрах, будет кажутся линейными, и часто стоимость большего количества оборудования дешевле, чем стоимость разработки более эффективного решения).

Кроме того, существует очень простой принцип, что каждая строка кода разработчика - это что-то еще, что может пойти не так. Чем меньше пишет разработчик, тем менее вероятно, что то, что он пишет, имеет проблему. Это не критика чьего-либо "уровня ошибок"; это простая констатация факта. Возможно, вы знаете, как писать MergeSort вперед и назад на 5 языках, но если вы нажмете только один идентификатор в одной строке кода, вся сортировка не будет работать, и если компилятор не поймал ее, это может привести к часов, чтобы отладить его. Сравните это с List.Sort (); это там, это эффективно в общем случае, и, что самое лучшее, это уже работает.

Итак, многие особенности современных платформ и принципы современных методологий проектирования были созданы с учетом этого:

• ООП - встраивать связанные данные и логику в объект, и где концепция этого объекта является действительной, то есть это объект или более специализированный вывод.
• Готовые шаблоны - хорошие 60% или более кода являются синтаксической несоответствием и основами того, чтобы программа показывала что-то на экране. Стандартизируя и автоматически генерируя этот код, вы вдвое сокращаете рабочую нагрузку разработчика, что позволяет повысить производительность.
• Библиотеки алгоритмов и структур данных. Как и в предыдущем примере, вы можете знать, как писать стек, очередь, быструю сортировку и т. Д., Но зачем это нужно, когда есть библиотека кода, в которой все это встроено? Вы не будете переписывать IIS или Apache, потому что вам нужен веб-сайт, поэтому зачем реализовывать алгоритм QuickSort или объект красно-черного дерева, когда доступно несколько отличных реализаций?
• Свободные интерфейсы. В том же духе у вас может быть алгоритм, который фильтрует и сортирует записи. Это быстро, но, вероятно, не очень читабельно; Вашему младшему разработчику понадобится день, чтобы понять это, не говоря уже о том, чтобы внести хирургические изменения, необходимые для сортировки дополнительного поля в объекте записи. Вместо этого библиотеки, такие как Linq, заменяют множество очень уродливого, часто хрупкого кода одной или двумя строками настраиваемых вызовов методов, чтобы превратить список объектов в отфильтрованные, отсортированные, проецируемые объекты.

Мне кажется, что вы делаете ИТ, а не CS, и это не должно означать, что CS мертва. CS не умер, просто большинство рабочих мест в разработке программного обеспечения. Поскольку большинство студентов CS учатся программировать, они обычно нанимают программистов, а не компьютерных специалистов. Работа в области компьютерных наук ничтожна по сравнению с программированием. Вы могли бы даже сделать сложное приложение, используя методы информатики, но по моему мнению (и мне не нравятся ответы на вопросы, потому что они субъективны), это падает в инженерном лагере, чем в ученом лагере.

Кроме того, красивый и элегантный код находится в поле зрения обозревателя , но для большинства компаний / менеджеров наличие достаточно хорошего дизайна в срок гораздо важнее красивого кода, но никогда не заканчивается вовремя.

Наконец, существует реальный мир и земля лала. К сожалению, мы получаем зарплату от первого, и именно здесь возникает «наука / искусство» разработки программного обеспечения о том, как производить высокое качество программного обеспечения с временными / бюджетными ограничениями. Я чувствовал те же чувства, что и у тебя в начале моей карьеры. Я всегда хотел создать «лучший», но вскоре понял, что «лучший» - это не самый эффективный или элегантный, а самый экономичный дизайн.

Прежде всего, вы ошиблись. «думать, планировать и эффективно решать проблемы» - это не наука, а техника. Наука намного больше об исследовании новых областей. И на самом деле в академическом мире люди гораздо меньше заботятся об эффективности кода, чем в промышленности. В научных кругах это больше о проверке концепций и т. Д.

Нет, то, что вы описываете, это то, что для разработки программного обеспечения требуются менее глубокие знания. Что может быть правдой, если требования будут одинаковыми. Но в настоящее время ожидается, что инженер-программист знает, как справляться с многопоточностью, распределенными вычислениями, масштабированием и т. Д. Предполагается, что он должен уметь эффективно руководить проектом. Большая часть этого не была вообще в учебных планах несколько десятилетий назад.

Я не думаю , что вы сказали , совершенно верно, но у вас есть что - то от точки в любом случае. В частности, я думаю, что со временем компьютерная наука и разработка программного обеспечения разошлись.

Программная инженерия (как и другая инженерия) - это применение науки для создания продуктов, решения проблем и т. Д. Информатика - это прежде всего исследование алгоритмов и (хотя эта часть часто несколько забывается) способов реализации этих алгоритмов (по крайней мере, в некотором теоретическом смысле - например, возможно, рассматривая все машины PRAM как эквивалентные).

Имея это в виду, я думаю, что причина раздвоения становится очевидной: большинство алгоритмических проблем, связанных с чем-то вроде типичного веб-сайта, уже решены - большинство из них уже давно . Возможно, что еще более важно, большинство из них были решены достаточно хорошо, что для обычного веб-разработчика проблема исчезла почти полностью. Например, выполнение атомарных обновлений распределенных баз данных, безусловно, является нетривиальной задачей, но типичный веб-разработчик просто пишет некоторый SQL и не знает (или не заботится) о том, сколько исследований потребовалось, чтобы выяснить, как сделать работу надежно.

Одно время было практически невозможно отделить информатику от разработки программного обеспечения. Было решено так мало проблем, что написание даже относительно тривиальной программы требовало изучения основ. Если вы хотели сделать что-то столь же простое, как сортировку группы данных в конце 50-х или начале 60-х, у вас были довольно хорошие шансы, что вам просто нужно будет провести некоторый анализ ваших данных и попытаться спроектировать алгоритм, который наилучшим образом соответствует тому, что требуется для сортировки этих конкретных данных - нигде не было так много известных алгоритмов сортировки, как сегодня, и даже известные алгоритмы были известны не так хорошо, как сегодня ,

Тем не менее, 50 лет исследований и разработок окупились - наиболее типичные разработки могут использовать не только известные алгоритмы, но и заранее написанные реализации. Наиболее типичные проблемы могут быть решены вполне разумно на основе существующих знаний (и даже существующих реализаций) алгоритмов.

Это не означает, что информатика мертва - все еще есть много алгоритмов для исследования, и люди проводят исследования в них. Это, однако, означает, что большая часть исследований является более специализированной и может применяться только в довольно специализированных областях. Вероятно, существует также больший «разрыв» между приобретением и применением знаний. Когда-то вы нашли лучший способ сортировки в процессе написания программы сортировки, и она была практически сразу записана в реальном коде. Сейчас много компьютерных наук посвящено таким вещам, как, как использовать по существу бесконечное количество процессоров - что, вероятно, когда-нибудь будет полезно, но даже примитивные племена не посчитали бы двухъядерные процессоры в моем компьютере «многими» ... :-)

Разработка программного обеспечения и информатика - это не одно и то же, и я обнаружил, что большинство моих одноклассников на бакалавриате Программа Comp Sci была разочарована этим.

Я думаю о программном обеспечении как о продукте компьютерной науки ... как картины - продукт изобразительного искусства.

Я думаю, что большинство людей со степенями CS нанимаются на работу для разработки программного обеспечения, особенно на ранних этапах их карьеры. Я думаю, что многие люди в этой роли остаются там и не идут дальше.

Я думаю, что разница начинает появляться, когда появляются новые проблемы или парадигмы, или когда «объединение» недостаточно. Кто строит новые фреймворки или языки? Кто садится и разрабатывает детали нового физического движка? Кто использует теорию графов / графические преобразования, чтобы выжать из алгоритма несколько циклов за итерацию производительности?

Я закончу с того, с чего начал, соглашаясь с тем, что многие программисты занимаются разработкой программного обеспечения / проектированием, возможно, не полностью реализуя свой потенциал.

Вы, кажется, путаете информатику с программированием и разработкой программного обеспечения в целом. Два не то же самое, даже не близко. Независимо от того, что говорят наши ученые степени, подавляющее большинство из нас - программисты, а не ученые-компьютерщики. Если вы не принимаете активное участие в научных кругах на высоком уровне, я бы поспорил, что вы на самом деле не имеете ни малейшего представления о том, что происходит в информатике.

Я могу сказать вам, что информатика жива и здорова. Я должен ежедневно решать новые проблемы и придумывать эффективное и элегантное решение этих проблем. Я должен ежедневно использовать свои навыки инженера и использовать знания себя и своих коллег, чтобы решить эти проблемы для нашего клиента.

Я не пытаюсь ненавидеть языки, я понимаю, что они служат цели и делают это хорошо, но когда ваши сотрудники не знают, как работает хэш-таблица, и используют неправильные методы сортировки или запускают команды SQL, которые ужасно неэффективны (но выполняют работу в приемлемое время), кажется, что больше усилий направляется на разработку технологий, которые балуют новых «программистов», а не на самом деле учат людей, как правильно делать вещи.

Это звучит как проблема с сотрудником и, конечно, не для всех программистов.

То, что инструменты, облегчающие нашу работу, существуют, вовсе не означает, что мы не должны понимать технологию подчеркивания; если мы этого не делаем, мы никому не помогаем и, конечно же, не выполняем свою работу по правильному решению проблем.

Вы просто не поняли проблему под рукой. Проблема не в том, чтобы получить максимальную производительность, а в том, чтобы приложение было достаточно быстрым и отзывчивым. Обучение программированию - это решение проблемы за наименьшее количество денег.

Ненавижу формулировать это таким образом, но любое впечатление, которое вы испытываете по поводу смерти CS, - это всего лишь ваши собственные предварительные представления о том, что должен делать «настоящий» программист.

Ну, мертвый или не спорно!

Дело в том, что в современную технологическую эпоху большинство компаний нанимают людей для решения реальных задач типа рабочих процессов посредством автоматизации программного обеспечения. Они не заинтересованы в том, насколько изящной или быстрой может быть программа, которую вы можете написать, если она позволяет бизнесу работать быстрее и с большей производительностью.

Напряжение на большей производительности за меньшее время. (Подумайте о коммерциализации сельскохозяйственных культур / продуктов питания; более быстрый и быстрый рост при меньших затратах). То же самое происходит в мире технологий (следующая новая идея).

Помните, что в наше время все движется быстрее, чем когда-либо прежде, благодаря количеству и доступу к знаниям, чем в те времена. В те старые времена объем производства был небольшим и лучше, прибыль была выше. Теперь игра полностью изменилась. Достаточно взглянуть на такие вещи, как качество обслуживания клиентов, и, в общем, вещи не длятся дольше.

Элегантность и эффективность важны для технологических компаний, таких как Google и т. Д., Хотя даже эти места не идеальны, но вы можете приблизиться к этому, работая в одной из этих компаний в ближайшие годы.

В жизни всегда есть компромисс. Вы можете найти работу, которая платит меньше, где у вас есть все время и внимание. Или вы предпочитаете плавать с остальными из нас для лучшей оплаты и игнорировать вещи, которые не идеальны. Чем быстрее это осознание погрузит вас в вас, вы сможете подготовиться к реальному миру. Я не говорю, что вы должны игнорировать качество и элегантность, но знать динамику. Вы будете счастливее :)

На мой взгляд, некоторые из самых интересных вещей, которые могут возникнуть в будущем, безусловно, будут основаны на научной части информатики, в частности на улучшенном компьютерном зрении / машинном обучении и других алгоритмах разделения. Они, вероятно, будут продвигаться вперед в промышленности (например, Microsoft Kinect), но являются такими чрезвычайно сложными проблемами, что они, безусловно, будут основаны на большом объеме исследований и прогресса, достигнутого в академических кругах (опять же, Microsoft Kinect).

Я думаю, что стандартное ежедневное программирование - это примерно столько же искусство, сколько наука, но, безусловно, существуют области, которые глубоко заинтересованы в научных аспектах информатики. Например, исследователи для компаний и университетов. Если вы действительно хотите заниматься наукой профессионально, тогда вам следует искать доктора философии. Тем не менее, я обнаружил, что научные аспекты моего образования всегда были ценными, несмотря на то, что мне нужно полагаться на мою более творческую сторону в реальности!

Люди, которые не знают, что они делают, могут взломать вещи с некоторыми из инструментов, которые вы упомянули, но они обычно нанимают настоящих людей из CS, чтобы создавать инструменты, вам просто нужно стать более абстрактным, чтобы действительно подтолкнуть себя.