Нужно ли инженерам-программистам знать вещи низкого уровня? [закрыто]

По мере развития языков программирования высокого уровня, таких как C #, Java и т. Д., Многие люди утверждают, что они станут альтернативой таким языкам, как ассемблер и C / C ++, которые предоставляют вам доступ и контроль над компьютерным оборудованием, поскольку программисты должны сосредоточиться на создание программы и решение проблемы, не теряя времени на работу с компьютером, чтобы он заработал. Поскольку аппаратное обеспечение продолжает улучшаться, разница в производительности между C / C ++ и Java не будет значительной, и большие игры могут программироваться на языке, таком как Java.

Это общая идея, которую я кратко изложу после просмотра этой темы в Интернете. Как вы думаете, это станет реальностью в ближайшем будущем? Означает ли это, что все, что мы узнаем о вещах низкого уровня, больше не практично для индустрии программного обеспечения? Означает ли это, что язык ассемблера и C / C ++ станут релевантными только для инженеров-электриков, поскольку они будут единственными, кому нужно программировать свои электрические компоненты?

---

Сколько обучения достаточно? Если мы изучим слишком много вещей низкого уровня, мы в конечном итоге станем более ориентированными на электротехнику или если мы изучим слишком много математики, мы могли бы стать математиками, а не программистами. Я просто хочу знать, действительно ли полезные материалы по математике, которые я изучал (я прошел курс по математике, который охватывает материал, аналогичный этой книге (они использовали другой учебник): дискретная математика и ее применение), на самом деле так же полезны, как и наши навыки программирования. Многие математические упражнения могут занять у большинства из нас часы, и если вы серьезно относитесь к этому, у вас будет меньше времени для изучения программирования. На нашем форуме разработчиков игр даже по математике и физике есть только один раздел, который можно сравнить с программированием.

Прямо сейчас я только начал читать "Искусство компьютерного программирования". Математика описана только в четверти книги, но это упражнение трудно для нас, нематематиков. Даже такую ​​«элементарную» математику, мы использовали ее так много в нашей карьере? Некоторые люди, вероятно, скажут мне, что чтение книги TACOP - пустая трата времени, и, вероятно, стоит потратить время на что-то более практичное, хотя книга посвящена программированию (немного больше академического сравнения с книгами, объясняющими подобные вещи). Но я думаю, что автор приложил немало времени и усилий для его создания. Он может даже написать полный набор из 5 книг, а у нас - у аудитории - есть только задача прочитать его. Почему бы нет?

Интересный вопрос. Я долгое время программист на C ++, который сейчас работает на C # (с небольшим количеством неуправляемого C ++ для работы, критически важной для производительности), и исторически мне приходилось добавлять случайный фрагмент кода на ассемблере, обычно по соображениям производительности.

Несколько моментов при подготовке ответа на вопрос:

• Для вашего сравнения я предлагаю, чтобы основное различие между языками, которые вы упоминаете, C # и Java, от другого набора, Assembly, C / C ++, заключалось в том, что первые используют управляемую среду выполнения для обеспечения сборки мусора. Существуют и другие различия (например, переносимость двоичных файлов, размер структуры и переносимость), но, поскольку вы смотрите на сравнение различий в производительности, это (?) Основной вклад.

• Assembly, C и C ++ далеко не одинаково «низкоуровневые». Я думаю, что вы правы в том, что связываете языки ассемблера и C с разработчиками аппаратного обеспечения / прошивки / драйвера, но C ++ обычно используется на более высоком уровне и все еще интенсивно используется - хотя, очевидно, C # / Java делают это в соответствии с TIOBE показатель.

• На уровне C ++ я бы добавил Objective-C, так как он больше похож на C ++, чем на C # / Java. Наконец, я хотел бы отметить, что с добавлением shared_ptr <> и других функций автоматического управления ресурсами, эти языки поддерживают нечто похожее на сборку мусора.

Хорошо, перейдем к вашему основному вопросу: действительно ли разработчикам программного обеспечения нужно больше знать вещи низкого уровня?

Мой ответ: да

Причины:

• Даже при использовании C # / Java вы, вероятно, столкнетесь с объектами инфраструктуры, которые требуют явного управления ресурсами, и / или столкнетесь с проблемами «закрепленных» графиков памяти в любых нетривиальных приложениях. Вы должны понимать, как эти системы работают, чтобы эффективно избегать и устранять эти проблемы.
• Мобильные платформы имеют более ограниченные ресурсы, и, хотя в некоторых из них есть поддержка ограниченных версий Java и .NET, нынешнее доминирование iOS и Objective-C предполагает долгое обновление.
• Производительность: каждый раз, когда вы сталкиваетесь с производительностью, вам, скорее всего, придется заглянуть в изначально скомпилированный кусок кода, чтобы обойти его.
• Устаревшая поддержка: в любое время, когда вам нужно взаимодействовать, чтобы получить доступ к функции, еще не раскрытой (пока) в управляемом коде, вам нужно будет сделать то же самое.

Хороший вопрос - но я не вижу, чтобы неуправляемые языки исчезали в ближайшем будущем.

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

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

При этом нам нужно больше разработчиков на C # / Java / Ruby, чем на ассемблере / C. Для нас, разработчиков «более высокого уровня», более глубокое понимание того, что происходит «под капотом», полезно и сделает нас лучшими разработчиками. Но так же много других вещей . Как разработчик .NET, например, я могу выучить так много всего , что сделает меня более продуктивным, что изучение нашего промежуточного языка (гораздо менее C ++ / C / Assmebly), хотя и очень полезного, часто отходит на второй план.

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

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

Я так не думаю, разработчикам ядра всегда будут нужны вещи низкого уровня. Также не помешает понять, как все работает, если вы в основном поймете, что на самом деле делает код, который вы пишете, вы научитесь писать лучший код. Я думаю, что удаление вещей низкого уровня - ужасная идея, поскольку это абстрактное мышление иногда полезно, но на самом деле может быть помехой, если вы хотите, чтобы проблема была решена наилучшим образом. Например, важно понимать, что когда вы объединяете строки, вы на самом деле создаете новые строки, но если вы не понимаете, как были реализованы строки, вы можете просто объединить их и подождать 5 минут, которые требуются для запуска вашей программы. Это отличная статья о таких вещах, как это: http://www.joelonsoftware.com/articles/fog0000000319.html

Это зависит от того, над чем фактически работает разработчик программного обеспечения. Можно сделать продуктивную, счастливую и прибыльную карьеру, даже не затрагивая ничего низкого уровня, но это еще не все задачи программирования. Чтобы существовали операционные системы и компиляторы, должны быть инженеры, работающие над операционными системами и компиляторами, и они должны будут знать C, C ++ и язык ассемблера их машины.

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

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

«С улучшением аппаратного обеспечения производительность между C / C ++ и Java не будет значительной, и большая игра может быть запрограммирована на языке, таком как Java».

Я не верю, что это утверждение будет правильным в ближайшее время. В управляемом коде всегда есть попадание из-за проверок, сделанных за сценой. Это также не вопрос аппаратного обеспечения лучше, поскольку аппаратное обеспечение становится лучше, также как и приложения, которые должны работать на них. Система, написанная на нативном коде, должна иметь интерфейс для управляемого кода. Theres производительность производительности, которая происходит при переключении между ними.

Однако только небольшой процент приложений действительно нуждается в этом оптимизированном коде. Большинство бизнес-приложений прекрасно работают с любым управляемым кодом, .net, java и т. Д. Это не означает, что приложения, которым это необходимо, переключатся в ближайшее время. Однако рукописная сборка теперь используется гораздо реже, так как оптимизирующие компиляторы C / C ++ настолько хороши. Недавно была ОС, написанная полностью на ассемблере, но некоторые до сих пор ее используют. Это также очень важно в области безопасности.

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

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

Когда компьютеры были впервые изобретены, лишь немногие знали, как ими пользоваться. В настоящее время в большинстве домов в богатой стране имеется 1 или более компьютеров, которые могут использоваться обычным человеком. Многие простые люди ежедневно работают на компьютерах. Средний человек имеет возможность пользоваться компьютером, но нам все еще нужны программисты.

Точно так же обычному программисту не нужно знать или регулярно программировать на ассемблере. Это не только условие рыночных навыков, но и приветствие того, как далеко мы продвинулись в мире технологий. Бизнесу нужны компьютеры для автоматизации задач. Поэтому программисты, которые могут программировать на .NET / Java, пользуются большим спросом.

Задачи, которые можно автоматизировать, будут автоматизированы. Не все задачи могут быть автоматизированы. Не вся автоматизация идеальна. Итак, важна ли сборка? Конечно. Нужно ли быть «программистом». Конечно нет.

Хм, на самом деле, мне нравится изучать вещи низкого уровня.

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

Может быть, не очень полезно (я не смогу починить машину, зная все это), конечно, не профессионально, но весело. L'art для l'art: от возрождения до возрождения.

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

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

Не все работы по разработке программного обеспечения одинаковы . Люди, работающие над операционными системами, компиляторами, платформами, драйверами устройств, встроенными системами и высокопроизводительными научными вычислениями, чертовски хорошо знают «низкоуровневые вещи». Люди, пишущие формы Access CRUD, или магазинные тележки PHP для магазинов Mom и Pop, возможно, не так много. Какой вид разработки программного обеспечения вы хотите сделать, и хотите ли вы заниматься этим всю оставшуюся жизнь?

Мое мнение таково, что вам нужно выучить хотя бы один уровень абстракции ниже того уровня, на котором вы обычно работаете. Если вы работаете в C / C ++, то вам следует подобрать архитектуру и сборку машины. Если вы работаете в PHP, вы должны понимать HTTP и немного C / C ++ или Perl. Если Access - это ваш хлеб с маслом, то вам лучше знать некоторые теории RDB, и, возможно, немного о COM или .Net. В какой-то момент вашей карьеры вы в конечном итоге останетесь в тупике из-за проблемы на более низком уровне абстракции, и вам нужно будет хотя бы немного пообщаться с кем-то, кто является экспертом в этой области. Можете ли вы «обойтись» без этого материала? Конечно, но планирование «обойтись» на конкурентном рынке труда опасно.

Я сам много работаю в C # .NET и всегда держался подальше от C, C ++. Недавно начал искать работу и был удивлен, увидев, сколько вакансий доступно и требует опыта работы на C, C ++. Сначала я думал, что C, C ++ устарели, но, глядя на доступные рабочие места, похоже, что это не так.

Все перечисленные вами управляемые языки имеют интерпретаторы или виртуальные машины, написанные на C / C ++. Без этих двух наиболее управляемых или интерпретируемых языков даже не было бы. Я бы сказал, что вы недооцениваете их ценность.

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

Что я обычно делаю, C # - это язык очень низкого уровня, и я считаю его чем-то очень близким к аппаратному. Но все же я верю, что даже мои элементарные, ржавые знания цифровой электроники, дизайна процессора и т. Д. Очень полезны для всего, что я когда-либо делал.

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

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

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

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

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

Действительно, программист должен учиться и хорошо разбираться в материалах низкого уровня ... :)

В то время как разработчик, это полностью зависит от его интересов. :)