Керовані кодери проти рідних кодерів

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

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

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

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

Чисто з технічної точки зору немає чіткого переможця.

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

Ще в мої дні, що кодували рідні, я здебільшого писав математичні симуляції, які працювали на суперкомп'ютерах. Вони мали некрасиві CLI та були здебільшого орієнтовані на алгоритми. Сьогодні я пишу на C # і створюю прекрасні програми GUI, але втратив би, якби мені довелося зробити щось подібного калібру на рідній мові. Навіть із такою основою, як QT, все-таки знадобиться вдвічі більше часу, щоб створити щось у C ++ / QT, ніж у C #.

Щоразу, коли я бачу когось, хто написав широкомасштабну повнофункціональну програму GUI на C / C ++, я не можу не відчути почуття побоювання та натяку на ревнощі.

Мені цікаво, як інші досвідчені кодери бачать керовані та некеровані мови. Ви бачите керований код як любитель-іш ? Ви бачите рідні кодери як більш хардкор ?

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

• Багато передбачуваної неефективності інших мов часто повторюються програмістами C ++ як найкраща практика. Ми додаємо достатню кількість нульових перевірок, перевірку меж масиву, перевірку типів, перевірку введення даних тощо, щоб значною мірою заперечувати будь-яку перевагу швидкості виконання, отриману мовою, яка не робить це автоматично, принаймні для коду, який не інтенсивно обробляє дані.
• Ця додаткова котлованна плитка стає вродженою звичкою через деякий час, так що вона насправді не відчуває себе зайвою роботою, і стирчить як біль у великому пальці, коли її немає.
• Коли я програмую на "керованій" мові, я все ще думаю про розподіл пам'яті, щоб переконатися, що я не створюю витоку пам'яті. Я, можливо, не ставлю явного delete, але я все ще знаю про свою точку, коли сміттєзбірник вважає його придатним до видалення. Мені було складніше вирішити проблеми з низькою пам’яттю, починаючи з Java, ніж я коли-небудь робив на C ++, можливо, тому що в C ++ їх набагато важче ігнорувати дуже довго.
• Те саме стосується і динамічного набору тексту. Мені все одно доводиться відслідковувати, чи є параметром функції масив, чи int, або рядок. Насправді це вимагає більше розумових зусиль, оскільки тип не є чітко переліченим там для мене.
• Сучасний стиль C ++ сильно відрізняється від епохи до C #. Замість того, щоб змінювати мову, люди "відкрили", як використовувати існуючі функції C ++ унікальними способами, щоб уникнути значної частини керованої пам'яті минулого. Моделі дизайну, які безкоштовно звільняють пам'ять, зараз дуже поширені.
• Наскільки я знаю, незважаючи на те, що графічні дизайнери, такі як QT-дизайнер, можна зробити лише графічним кодом, є переважним методом, з кодом в основному використовується лише для обробників подій або для налаштування часу виконання.
• Мови, якими ви часто не користувалися широко, завжди відчувають себе трохи незграбно, навіть якщо ви здебільшого пам'ятаєте синтаксис. Якщо я не пишу python протягом року, є багато ідіосинкразій, які я забув, і він відчуває себе більш незручним, ніж C ++ на деякий час, хоча об'єктивно більшість людей вважають python "легшою" мовою.

При поєднанні всіх цих факторів моя ментальна модель залишається досить узгодженою між програмою на C ++ та інших мовах, і відмінності відчуваються здебільшого синтаксичними. Зрозуміло, багато цього є результатом навчання, звичок, стандартів кодування та сучасних моделей дизайну, а не особливостей, властивих самій мові C ++, але порівняння все ще залишається.

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

Ви бачите керований код як любитель-іш? Чи вважаєте ви кодери ріднішими?

Ні.

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

Завдяки потужності процесора в наші дні частота фактичного необхідності витягти з машини якомога більше, використовуючи рідні мови нижчого рівня, стає все менше і менше. Зазвичай це просто не є діловою справою. Продуктивність завжди перевищує кілька мілісекунд різниці у часі виконання.

На жаль, Microsoft призвела до того, щоб ми пов'язували "керований код" з бібліотеками нетто класу C # /.

Тут грають дві окремі і майже не пов'язані між собою речі.

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

2. Керований код.

C # пропонує як в охайний, підтримуваний, простий у використанні пакет за одну ціну.

У C ++ є безліч класних бібліотек, які роблять майже все. Net робить. Замість того, щоб звинувачувати "нативний C ++" код у тому, що він має більше "складностей, вигадок та ідіосинкрасій", ніж чистий код C # /. Ви можете шукати кращі бібліотеки C ++.

Кращі бібліотеки дозволяють також писати хороший код C ++.

Кожного разу, коли я бачу когось, хто написав широкомасштабну повнофункціональну програму GUI на C / C ++, я не можу не відчути почуття побоювання та натяку на ревнощі

Погана політика. Натомість слід з’ясувати, які бібліотеки визначень класів вони використовували. Ви також могли використовувати ці бібліотеки.

Вся справа в інструментах. Без інструментів ми просто тварини в штанах.

"Рідний C ++" не означає, що ви повинні викинути всі свої інструменти. Це означає, що ви повинні знайти хороші інструменти. Microsoft вже не допомагає вам, тому вам потрібно витратити час на пошук правильної суміші інструментів.

Тут не йдеться про хардкорне програмування чи щось подібне, а про контроль. Справа в тому, що C # пропонує продуктивність за ціною контролю. Якщо ви пишете програму, яка потребує високого рівня контролю (ця пам'ять розміщена саме зараз), то вам не залишається іншого вибору, як використовувати C ++. Якщо вам потрібно швидко зробити це, можливо, вам доведеться скористатися C #. Проблема полягає в тому, що підтримуючі бібліотеки для C # набагато кращі та новіші, ніж передбачено для C ++. Наприклад, MFC дуже, дуже старий, і його практики, як відомо, були жахливими, вони в основному писалися задовго до стандартизації. Якщо Microsoft докладе певних зусиль для надання нових бібліотек C ++, наприклад, перегляньте новий PPL у Visual Studio 2010, то, як не дивно, це завдання стає легким у C ++. І я думаю, що вони мігрують таким чином,

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

Я чув, що багато прихильників керованої мови говорять про це, але я майже ніколи насправді не бачив, щоб це було правдою. Справа в тому, що нові інструкції з процесора, доступні в новіших процесорах, просто не пропонують такої переваги, якщо ви не займаєтеся дуже жорсткою математикою, і в цьому випадку ви не можете дозволити собі накладні витрати на необхідність компілювати або інтерпретувати її під час запуску. -час, і ви можете просто використовувати компілятор C ++ від Intel для використання найновішого і найкращого в 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 ++. Однак зазвичай вам потрібне це програмування низького рівня в невеликій частині вашого коду, і коли це не потрібно, керована мова є більш продуктивною.

Рідні розробники, як правило, отримують репутацію того, що вони більш хардкор, тому що вони відчувають себе більш жорсткими і діють таким чином. Рідні розробники навчаються в системі, не терпимої до будь-яких помилок, оскільки вони неминуче призводять до жорстких збоїв або безмежного витоку пам'яті. Зокрема . код критичний! "). Це зовсім не чорно-біле, але мої спостереження виросли в некерованому світі і зараз працюю над керованим кодом повний робочий день.

Крім того, керовані розробники також, як правило, мають доступ до більш чистих та організованих BCL. Це часто спонукає їх вивчити те, що насправді відбувається під прикриттями. Щоправда, те саме можна сказати, наприклад, для STL або Boost, але бібліотека класів .NET часто досить хороша, щоб часом нас інтелектуально ледавати.

Однак, написання хорошої керованої програми, що керується транспортом, потребує багато роботи. Це означає, що проводити профілювання пам'яті та процесора, тестування одиниць та аналіз коду аналогічним чином, як це роблять некеровані розробники. Некеровані розробники, як правило, розуміють це, а керовані розробники, як правило, включають більше тих, хто цього не робить.

Знову ж таки, не чорно-біле. Є багато інтелектуально ледачих некерованих розробників та хардкор-керованих розробників. Ні за визначенням не елітніше за інших.

Ви бачите керований код як любитель-іш? Чи вважаєте ви кодери ріднішими?

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

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