Управляемые кодеры против родных кодеров

Я кодер и имею опыт работы как с нативным, так и с управляемым кодом. Я начал с Pascal и C, затем перешел на C ++ и в конце концов на C #.

За последний год или около того я программировал почти исключительно на C # и потерял многое из того, что было естественно, когда я был программистом на C ++.

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

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

Чисто с технической точки зрения нет явного победителя.

Нет никаких сомнений в том, что управляемый код на порядок проще в коде и понимании. Просто посмотрите на разницу в количестве строк, необходимых для создания простого графического интерфейса в Win32 C ++ и C #.

В те дни, когда я работал в нативном коде, я в основном писал математические симуляции, которые работали на суперкомпьютерах. У них были ужасные CLI и они были в основном сфокусированы на алгоритмах. В настоящее время я пишу на C # и создаю красивые приложения с графическим интерфейсом, но был бы потерян, если бы мне пришлось сделать что-то похожего калибра на родном языке. Даже с такой средой, как QT, на C ++ / QT все равно потребуется вдвое больше времени, чем на C #.

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

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

Моя дневная работа в настоящее время на C ++, но я программирую на нескольких языках достаточно долго, чтобы я едва заметил разницу. Вот мои наблюдения:

• Многие предполагаемые недостатки других языков часто реализуются программистами на C ++ как лучшие практики. Мы добавляем достаточное количество нулевых проверок, проверок границ массивов, проверок типов, проверки ввода и т. Д., Чтобы в значительной степени свести на нет любое преимущество в скорости выполнения, получаемое языком, который не выполняет этих действий автоматически, по крайней мере для кода, который не требует интенсивной обработки данных.
• Этот дополнительный шаблон становится укоренившейся привычкой через некоторое время, так что на самом деле он не ощущается как дополнительная работа, и выпирает как больной большой палец, когда его не хватает.
• Когда я программирую на «управляемом» языке, я все еще думаю о распределении памяти, чтобы не допустить утечки памяти. Возможно, я не помещаю явное delete, но я все еще осознаю, в какой момент сборщик мусора считает его пригодным для удаления. Мне было труднее решать проблемы с нехваткой памяти, начиная с Java, чем когда-либо в C ++, возможно, потому, что в C ++ их гораздо сложнее игнорировать очень долго.
• То же самое касается динамического набора текста. Мне все еще нужно следить за тем, является ли параметр функции массивом, или целым числом, или строкой. На самом деле, это требует больше умственных усилий, потому что тип не указан прямо для меня.
• Современный стиль C ++ сильно отличается от эпохи до C #. Вместо того, чтобы менять язык, люди «обнаружили», как использовать существующие функции C ++ уникальными способами, чтобы избежать значительной части управления памятью в прошлом. Шаблоны проектирования, которые автоматически освобождают память, сейчас очень распространены.
• Насколько я знаю, даже несмотря на то, что можно создавать приложения с графическим интерфейсом только написанием кода, графические дизайнеры, такие как QT designer, являются наиболее предпочтительным методом, так как код в основном используется только для обработчиков событий или настройки времени выполнения.
• Языки, которыми вы давно не пользовались, всегда немного неуклюжи, даже если вы в основном помните синтаксис. Если я не пишу python в течение года, я забыл о многих специфических особенностях, и какое-то время он чувствует себя более неловко, чем C ++, хотя объективно большинство людей считают python «более простым» языком.

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

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

Считаете ли вы управляемый код любительским? Вы видите нативных кодеров как более хардкорных?

Нет.

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

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

К сожалению, Microsoft привела нас к объединению «Управляемого кода» с библиотеками класса C # / .Net.

Здесь есть две отдельные и почти не связанные вещи.

1. Классные .Net библиотеки.

2. Управляемый код.

C # предлагает оба в опрятном, поддерживаемом, простом в использовании пакете за одну цену.

C ++ имеет множество классных библиотек, которые делают почти все, что делает .Net. Вместо того, чтобы обвинять «нативный код C ++» в том, что он имеет больше «сложностей, причуд и особенностей», чем в коде C # /. Net, вы могли бы искать лучшие библиотеки C ++.

Лучшие библиотеки также позволяют писать хороший код на C ++.

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

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

Все дело в инструментах. Без инструментов мы просто животные в штанах.

«Родной C ++» не означает, что вы должны выбросить все свои инструменты. Это означает, что вы должны найти хорошие инструменты. Microsoft больше не помогает вам, поэтому вам нужно тратить время на поиск нужного набора инструментов.

Проблема здесь не в жестком программировании или чем-то подобном, а в контроле. Дело в том, что C # предлагает производительность за счет контроля. Если вы пишете программу, которая требует большого количества контроля (эта память освобождается именно сейчас), то у вас нет выбора, кроме как использовать C ++. Если вам нужно сделать это быстро, то вам, возможно, придется использовать C #. Проблема заключается в том, что поддерживающие библиотеки для C # намного лучше и новее, чем предоставляемые для C ++. Например, MFC очень, очень старый, и его практика, как известно, ужасна, в основном она была написана задолго до стандартизации. Если Microsoft приложит некоторые усилия для предоставления новых библиотек C ++, например, ознакомится с новым PPL в Visual Studio 2010, то, как ни странно, эта задача станет легкой в ​​C ++. И я думаю, что они мигрируют таким образом,

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

Я слышал, что многие сторонники управляемого языка говорят это, но я почти никогда не видел, чтобы это было правдой. Дело в том, что новые инструкции ЦП, доступные в более новых ЦП, просто не дают такого большого преимущества, если вы не занимаетесь очень жесткой математикой, и в этом случае вы не можете позволить себе накладные расходы, связанные с компиляцией или интерпретацией при запуске -время, и вы можете просто использовать компилятор Intel C ++, чтобы использовать новейшие и лучшие в SSE в любом случае. Возможности оптимизации компилятора C ++ огромны по сравнению с тем, что может сделать JIT, потому что JIT должен выполняться в течение доли времени во время работы программы, в то время как компиляторы C ++ довольно легендарны, поскольку тратят свое время на компиляцию.

Сборка мусора - это не какая-то волшебная вещь или что-то в этом роде - это выбор алгоритма. Это подходит для всех ситуаций? Не на дальнем взгляд на IDisposable беспорядка в C # и как Java даже не потрудился , чтобы попытаться с этим вопросом, в то время как ++ деструкторы C 's закроют ваши файлы и освободить память и близко ваши розетки, и т.д. и т.п. GC отлично подходит для некоторых программ и не для некоторых других.

На мой взгляд, родной C / C ++, по сравнению с C #, выглядит как ассемблер для самого C / C ++. Другой сложный уровень абстракции (не совсем верно, но, скажем так), как всегда, упрощает разработку, но снижает скорость и излишнее использование памяти. Так что, на мой взгляд, он просто разделяется на разные категории, создавая тем самым новые подтипы программистов.

Между прочим, уровень абстракции C # невероятно быстр, Microsoft отлично поработала.

Есть любительские программисты, а не любительские языки. Языки у них есть все (ну, по крайней мере, большинство из них) их цель.

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

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

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

В прошлом году фирма, в которой я работаю, занималась реверс-инжинирингом кода CRC для коммуникаций грубой силой (мы его получили в конце концов) У каждого из 3 разработчиков была своя версия, Borland C, C # .Net 2008, VB6. VB6 был, очевидно, медленным, Borland C был быстрым, но C # .net просто порвал его в 12 раз быстрее. Не совсем то, что мы ожидали.

Это зависит от сочетания вещей, но в основном, при прочих равных условиях, да, нативный код более «хардкорный», чем управляемый код.

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

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

Родные разработчики обычно получают репутацию более хардкорных, потому что они чувствуют себя более хардкорными и ведут себя таким образом. Нативные разработчики обучены работе с системой, не терпящей никаких ошибок, поскольку они неизбежно приводят к серьезным сбоям или неограниченным утечкам памяти. В частности, .NET допускает ленивые взломы, такие как попытка поймать все вокруг, избавляя разработчика от мысли, что он должен понять основную проблему (« иногда это просто вызывает InvalidOperationException. Я не могу это объяснить, давайте просто поймать все. код критичен! "). Это совсем не чёрно-белое, но мои наблюдения выросли в неуправляемом мире и теперь работают в управляемом коде полный рабочий день.

Кроме того, разработчики, которым управляют, также имеют тенденцию иметь доступ к намного более чистым и более организованным BCL. Это часто побуждает их исследовать то, что на самом деле происходит под одеялом. Правда, то же самое можно сказать, скажем, о STL или Boost, но библиотека классов .NET часто достаточно хороша, чтобы иногда делать нас интеллектуально ленивыми.

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

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

Считаете ли вы управляемый код любительским? Вы видите нативных кодеров как более хардкорных?

Между двумя мирами существует разрыв , и я не могу понять, почему: управляемые системы где-то написаны на нативном коде (в конечном итоге все работает "в сборке"). То, что я хочу увидеть (пока в моей жизни), - это система конструирования приложений, где все подзадачи приложения будут написаны на правильном языке.

Родной код стал легче, так как Go был выпущен. Мне легче читать и писать, чем Java и C #. Хотя на данный момент программирование GUI с помощью Go не очень приятно (я быстро взглянул на параметры).
Постарайтесь не судить об этом из-за отсутствия большого сообщества и разнообразия библиотек по сравнению с C # (например), потому что он все еще считается новым.