Чи справді інженерам програмного забезпечення вже потрібно знати речі низького рівня? [зачинено]

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

Це загальна ідея, яку я коротко підсумую, переглянувши цю тему в Інтернеті. Як ви думаєте, це стане реальним найближчим часом? Чи означає це, що все, що ми дізнаємось про речі низького рівня, вже не практичне для програмної галузі? Це означає, що мова монтажу та C / C ++ стануть актуальними лише для інженерів-електриків, оскільки вони будуть єдиними, кому потрібно програмувати свої електричні компоненти?

---

Скільки навчання достатньо? Якщо ми вивчимо занадто багато предметів із низьким рівнем, ми з часом станемо більш орієнтованими в електротехніці або якщо ми навчимося занадто багато математики, ми могли б навчитися стати математиками, а не програмістами. Мені просто хочеться дізнатись, чи вивчала математика, яку я вивчила (я взяла курс з математики, який охоплює матеріал, подібний до цієї книги (вони використовували різні текстові книги): дискретна математика та її застосування) насправді настільки ж корисний, як і наш набір навичок програмування. Багато вправ з математики можуть зайняти більшість з нас годин, і якщо ви серйозно ставитесь до цього, у вас буде менше часу на вивчення програмування. На нашому форумі gamedev навіть математика та фізика мають лише один розділ для порівняння з програмуванням.

Зараз я тільки почав читати "Мистецтво комп'ютерного програмування". Математика висвітлюється лише приблизно в чверті книги, але вправи важкі для нас, не математиків. Навіть таку "елементарну" математику, ми її так багато використовували у своїй кар'єрі? Деякі люди, напевно, скажуть мені, що читати книгу TACOP - це марна трата часу, і, мабуть, варто витратити час на щось інше, більш практичне, навіть якщо книга стосується програмування (трохи більше академічного порівняння з книгою пояснюють подібні речі). Але я думаю, що автор вклав багато часу та зусиль, щоб його виготовити. Він навіть може написати повний набір із 5 книг, тоді як ми - аудиторія - лише місія його читати. Чому ні?

Цікаве запитання. Я тривалий час програміст C ++, який зараз працює в C # (маючи трохи некерованого C ++ для критичної роботи), і мені історично доводилося додавати час від часу трохи збірки коду, як правило, з міркувань продуктивності.

Кілька пунктів у підготовці відповіді на питання:

• Для вашого порівняння я пропоную, що основне відмінність між мовами, які ви згадуєте, C # та Java, від іншого набору, Assembly, C / 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, ніж ми розробники Assemby / C. Для нас, розробників вищого рівня, корисніше розуміння того, що відбувається "під кришкою", і зробить нас кращими розробниками. Але так само багато інших речей . Як розробник .NET, для прикладу, є стільки, що я можу дізнатися, що зробить мене більш продуктивними, що вивчення нашого проміжного мови (набагато менше C ++ / C / Assambly), хоч і дуже корисно, часто доводиться займати місце.

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

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

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

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

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

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

"Коли апаратне забезпечення постійно покращується, продуктивність між C / C ++ та Java не буде суттєвою, і велика гра може бути запрограмована на такій мові, як Java."

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

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

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

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

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

Аналогічно, середньому програмісту не потрібно знати або регулярно програмувати мовою складання. Це настільки ж умова товарних навичок, як і привітання про те, як далеко ми зайшли в світі технологій. Для автоматизації завдань бізнесу потрібні комп'ютери. Тому програмісти, які можуть програмувати в .NET / Java, користуються великим попитом.

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

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

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

Можливо, не дуже корисно (я не зможу виправити машину, знаючи все це), звичайно не професійно практично, але, ну, весело. L'art pour l'art: la connaissance pour la connaissance.

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

Таким чином, ваш графічний інтенсивний шутер від першої особи або ваша алгоритмічна система FX торгівлі, вони все ще досить низького рівня (C ++ тощо), оскільки швидкість є ключовою. Але веб-додаток, який вчасно виписує звіт про продаж? Чорт, ти можеш написати це в Sinclair BASIC, і це все одно прийнятно.

Не всі завдання з інженерії програмного забезпечення однакові . Людям, які працюють на операційних системах, компіляторах, фреймворках, драйверах пристроїв, вбудованих системах та високоефективних наукових обчисленнях, давно, потрібно знати "речі низького рівня". Люди, які пишуть форми доступу до CRUD, або PHP-кошики для магазинів мами та поп, можливо, не так багато. Якою інженерією програмного забезпечення ви хочете займатися, і чи хочете ви це робити все життя?

На мою думку, вам потрібно навчитися хоча б одного рівня абстрагування нижче рівня, на якому зазвичай працюєте. Якщо ви працюєте на C / C ++, то вам слід підібрати деяку архітектуру машини та складання. Якщо ви працюєте в PHP, ви повинні розуміти HTTP і трохи C / C ++ або Perl. Якщо Access - це ваш хліб і масло, то вам краще знати теорію RDB, а можливо, трохи про COM або .Net. Колись у вашій кар’єрі ви зрештою зупиняться мертвими у своїх слідах через проблему на нижчому рівні абстракції, і вам потрібно буде мати змогу хоча б трохи поспілкуватися з тим, хто є фахівцем у цій галузі. Чи можете ви "дістатися" без цього матеріалу? Зрозуміло, але планувати просто "дістатися" на конкурентному ринку праці небезпечно.

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

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

Я дуже ненавиджу саме поняття "практичного" знання . Все, що ви коли-небудь дізнаєтесь, однаково практично. Не має значення, якщо ви не будете працювати на рівні абстракції, близькому до апаратного, просто знання понять із цього домену завжди вигідно для побудови нових знань на іншому рівні абстракції. Чим більше пов'язаних вам понять, тим краще.

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

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

На мою думку, коли ви вживаєте слово "Інженер", ви маєте на увазі, що чоловік / жінка - це той, хто проектує та будує речі з самого нуля. Справжня проблема інженерів програмного забезпечення - це вирішити проблему, але яка проблема? Це велике питання.

Розробник відрізняється від Інженера багато в чому. "Розробник" - це людина, яка зазвичай будує речі на вже існуючих платформах. Він розробляє існуючі платформи або будує нову спадщину платформи від старих, звичайно використовуючи компонент батьківської системи.

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

Інженер розумний. Він Вчений, він вирішує дуже щире питання. Більшість питань, які сам комп'ютер має як особливість. Ми користувач ніколи не наближаємось до цієї проблеми, вона інкапсульована. Інженери - це той, хто залишає свої дослідження після того, як багато вивчає існуючу систему і придумує щось нове для вирішення проблеми, якщо рішення вимагає, якщо їхній системі потрібна нова мова, вони винайдуть нову мову, оскільки існуюча система не здатна вирішення цього питання. Інженери закінчили розробляти систему, на якій розробники будують свою систему.

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

Якщо розробник, це повністю залежить від його інтересу. :)