Програмування на низькому рівні - що це для мене? [зачинено]

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

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

Моя позиція

Останні 4 роки я зосереджувався на "веб-технологіях", які можуть змінюватися, і я розробник додатків, який навряд чи зміниться.

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

Щоб досягти хорошої зручності використання, я вважаю, що такі речі є життєздатними

• Хороший дизайн : продумані функції, доступні через продуманий інтерфейс користувача.
• Правильність : Найкращий дизайн нічого не вартий, якщо він не виконаний правильно.
• Гнучкість : Додаток A повинен постійно розвиватися, щоб його користувачі не переходили на інший додаток B, який має нові функції, які A міг би реалізувати. Програми, що вирішують ту саму проблему, не повинні відрізнятися за особливостями, а за філософією.
• Продуктивність : Продуктивність сприяє гарному користуванню. Додаток завжди ідеально реагує і виконує свої завдання досить швидко (виходячи з їх частоти). Значення оптимізації продуктивності за межами моменту, коли це помітно користувачеві, сумнівне.

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

Моє запитання

Що може навчити мене програмування низького рівня, яких інших мов не навчив би мене? Чи щось мені не вистачає, чи це просто навик, який дуже мало корисний для розробки додатків? Будь ласка, розумійте, що я не ставлю під сумнів значення C і збірки. Просто в моєму повсякденному житті я дуже щасливий, що всі тонкощі цього світу відбираються та управляються для мене (в основному шарами, написаними на C / C ++ та самих зборах). Я просто не бачу жодних понять, які могли б бути для мене новими, лише деталі, які мені доведеться набити головою. То що в мені це?

Мій висновок

Дякую всім за відповіді. Треба сказати, мене ніхто не здивував, але принаймні зараз я впевнений, що відмовлюся від цієї сфери інтересів до тих пір, поки не виникне потреба в цьому.
Наскільки я розумію, написання цього монтажу для процесорів, оскільки вони використовуються в сучасних процесорах, не тільки непросто складне, але й ризикує призвести до більш низької продуктивності роботи, ніж аналог C. Оптимізація вручну майже неможлива через OOE, тоді як ви не отримуєте всі види оптимізацій, які компілятор може робити автоматично. Також код є або портативним, оскільки він використовує невеликий підмножина доступних команд, або оптимізований, але тоді він, ймовірно, працює лише в одній архітектурі.
Написання С вже майже не є таким необхідним, як це було раніше. Якби я писав заявку на C, я би так само використовував перевірені та встановлені бібліотеки та рамки, що дозволило б мені реалізувати підпрограми копіювання рядків, алгоритми сортування та інший матеріал, що служить вправ в університеті. Мій власний код виконуватиметься швидше ціною безпеки типу. Я ні прагну переосмислити колесо в ході нормальної розробки додатків, ні намагаюся налагодити, переглядаючи основні смітники: D
В даний час я експериментую з мовами та перекладачами, тому, якщо я хотів би щось опублікувати, я вважаю, що Поставимо робочу концепцію на C, хоча C ++ може так само добре зробити трюк.
Ще раз дякую всім за відповіді та вашу проникливість.

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

Подумайте про це як Хайкус або Лімерікс, де обмеження роблять його цікавим.

Щоб дати вам уявлення про те, що можливо в тому, що сьогодні здавалося б неможливим, ось один з найбільших хак-файлів коли-небудь. Шахи в 1 Кб оперативної пам’яті! http://users.ox.ac.uk/~uzdm0006/scans/1kchess/

Я недавно думав про це нещодавно. В даний час я вважаю себе розробником C # - що цілком чудово для моєї кар'єри.

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

Чим більше я програмую на абстрагованих мовах, тим більше мені не вистачає того, що спонукало мене до комп’ютерів, насамперед: тикати навколо комп’ютера і бачити, що смикається. Assembler і C дуже підходять для покупок :)

Використовуючи старі мови, я думаю, що ви змушені робити все дуже багато самостійно. У C # я можу зробити щось подібне myArray.SortBy(x=>x.Name). Ні в якому разі я не зміг би це зробити в C. Я приймаю, що мова буде робити найкраще сортування для мене. Якби я це робив на мові C, я міг би повернутися до часів своїх університетських модулів і переглянути свої різні алгоритми сортування та пошуку.

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

Моя пропозиція - грати зі С як інтелектуальне цікавість. Не робіть великих інвестицій у часи, тому що цього не варто.

Запропоновані цілі:

• Оновіть пам’ять про основні структури даних та алгоритми.
  • Це просто добре знати, як алгебра та геометрія.
  • Спробуйте виконати деякі вправи з підручника в коледжі або програмувати загадки на С.
• Краща оцінка ієрархії пам’яті (пропускної здатності) , починаючи від кешу процесора до затримки транскокеанічної мережі. Це допоможе вашим навичкам розробки додатків на всіх рівнях.
  • Найголовніше, це добре , щоб дізнатися про сценарії , в яких невелика непомітною перегрупування коди високого рівня може призвести до драматичних поліпшення швидкості .
    • Іноді причину можна зрозуміти лише в низькому рівні реалізації в контексті ієрархії пам'яті.
    • Нерозуміння природної причини такої можливості призводить до необізнаності , страху та врешті-решт до заперечення , думаючи, що неправильно розробникам високого рівня користуватися таким оптимізацією. Насправді в цьому немає нічого поганого.
• Вдячні за естетику програмних систем на базі компонентів , що дозволяє використовувати компоненти високого рівня, розроблені в C / C ++ / Assembly.
  • Естетика точно така ж, як і зручність використання програмного забезпечення:
    • Хороший дизайн (потужний, простий у користуванні, продуманий)
    • Правильність
    • Гнучкість (розширення та нова поведінка за допомогою композиції існуючих частин, кожна з чітко визначеною метою)
    • Продуктивність (не ускладнюючи зручність використання)
  • Хоча ви, можливо, не розробляєте власні компоненти низького рівня, ваше розуміння допоможе вам оцінити та вибрати хороші компоненти, які використовуватимуться у ваших проектах високого рівня.
• Нарешті, оцініть, що компоненти низького рівня майже завжди складніші у своїх реалізаціях , далеко не зрозумілі, лише дивлячись на інтерфейс.
  • Низький рівень завжди складний. Хороша бібліотека приховує складність, не зменшуючи її потужність.
  • Навчіться читати "технічні нотатки", написані розробниками компонентів, які пропонують користувачам компонентів вищого рівня про те, як найкраще використовувати компоненти.

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

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

це покращить вашу основу, але, ймовірно, не покращить ваші веб-програми

Кожна мова програмування дещо змінюється, як ви думаєте про програмування взагалі. Конкретний приклад, який я можу вам навести, - це коли я почав вивчати haskell, і раптом функціональні біти javascript, ruby ​​та python просто мали набагато більше сенсу. Я ніколи раніше не використовував foldl в жодному зі свого коду, але після haskell я його майже бачу скрізь, де я бачу масиви. Тож великі шанси, що якщо ви вивчите якийсь C, ви набагато більше усвідомлите відносні характеристики продуктивності різних конструкцій улюбленою мовою. Кілька хвилин тому я слухав розмову про написання швидкого та оптимізованого javascript, і доповідач сказав: "Якщо це важко зробити на C, це буде дуже повільно в JavaScript". Його наміром є те, що javascript - це інтерпретована мова, а перекладач написаний на C або C ++.

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

Ура за цікавість!

Дуже добре мати уявлення про те, що відбувається насправді на найнижчих рівнях складної системи, навіть якщо немає логічної необхідності знати свої обов'язки. На сьогоднішній день найкращим способом вирішувати речі на рівні біт - це створити власний процесор. Ви повинні подумати над машинними опкодами на рівні мови, зрозуміти, чому ортогональні набори інструкцій настільки хороші, ускладнення керування перериваннями, компроміси між складними схемами та мікрокодом (наприклад, в одиницях множення), і так багато іншого задоволення!

Але це, очевидно, вимагає електроніки і займає багато часу, тому наступне найкраще - це іграшка з антикварним 8-бітовим процесором. Мікроконтролери, як 8051, як і раніше знаходять широке використання і доступні для любителів. Це все ще потребує певного ноу-хау в галузі електроніки для пастухів та створення світлодіодів, які світяться без паління, і коштує $ $, якщо ви ще не обладнані для електроніки.

Наступне найкраще після цього: іграшка в симуляторі процесора (емулятор? Я змішую ці терміни) - вони існують для Z80, 6502, 8086 ... всі старі 8-бітні. Це може бути найосвітнішим і цікавим для програміста програм, який не знає, який кінець паяльника тримати (хоча хтось навчається це досить швидко :) Як текст записується у відеопам'ять, як трюкові монтажні коди допомагають у роботі. .. Є багато цікавих речей для вивчення цього рівня.

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

Словом, весело. Коли я звик грати з асемблером (працюючи з VB на C ++, C тощо), було просто приголомшливо переміщувати дані з однієї частини процесора в іншу. Це було чудове відчуття точно знати що відбувається всередині процесора, не турбуючись про те, що відбувається під ним, про який ти не знав. Плюс чудове відчуття свободи - ви можете робити практично все, тому що в мовах вищого рівня немає вбудованих обмежень.

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

Чи є якісь вагомі підстави вчитися / практикувати програмування низького рівня. У мене є різні відповіді залежно від контексту.

По-перше, я викладаю програмування на С (але також OCaml та Java), мотивуючи студента до вивчення програмування з жорсткої сторони, мабуть, найважча частина завдання. Найкращий аргумент, який я знайшов до цього часу, - це "розуміння": мови вищого рівня приховують безліч основних механізмів, а іноді і не для добра; вони також підштовхують вас залишатися на вищому рівні, навіть коли деякі хитрощі низького рівня справді можуть бути корисними ( для продуктивності, більшу частину часу.) Розуміння того, що ви використовуєте, дійсно може допомогти використовувати його краще. Мій досвід викладання підтверджує, що студенти, які навчаються програмуванню нижчого рівня (та інші, не орієнтовані на користувача, такі компілятори), є більш пристосованими та швидше навчаються новим концепціям чи інструментам вищого рівня.

По-друге, як ви заявляєте, продуктивність є частиною досвіду користувача. Більшу частину часу продуктивність сприймається як написання складного та поруч із машинним кодом. Це не завжди так, продуктивність - це набагато більше питання алгоритмів та структур даних, а також взаємодії між algo та даними. Я використовую спеціальний проект з цього питання, в основному це просте пошуку шляху, але справжньою проблемою є розмір даних: графік нескінченний. Єдиний спосіб досягти показників походження та вписатись у пам'ять - це написати виділений розподільник пам’яті (насправді два, розподільник пулу та розподільник переробки.) Це те, що ви не можете зробити на більшості мов вищого рівня. Насправді, більшість мов, зібраних сміттям, матимуть проблеми з продуктивністю та пам'яттю.

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

Я сам вловлююся в обох світі (зовсім по-різному), я кілька років працюю над концепцією теоретичного програмування, дизайном і підтвердженням системних типів, і роблячи це, я використовую і вивчаю мови дуже високого рівня (переважно функціональні, але й чисті) Орієнтований на об'єкт.) Останнім часом я повернувся до іншої сторони (в основному системного та ядерного програмування) і виявив себе досить легко в цій області, мені дуже весело! Наступним кроком для мене є пошук спільної точки: особливості мови вищого рівня для програмування нижчого рівня! Отже, поки що немає мови для цього (можливо, іти Google для системного програмування userland), і я розглядаю ідею побудувати свою власну мову, але це вже інша історія.

Я б сказав, що у вашому домені не так багато причин, однак, якби ви робили високоефективні обчислення (наприклад, ігри, науки тощо), це було б виправдано.

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

Тільки з цікавості ви могли дізнатися, як все працює на нижчому рівні. Наприклад, коли я був в університеті, мені подобалося використовувати gcc для генерації асемблерного коду з C ++. Було корисно зрозуміти, як реалізуються поліморфізм та виняток. Але крім цього, єдині речі, чому ви могли навчитися сьогодні на C, це:

1) брудні хитрощі пам’яті. C - найкращий спосіб зрозуміти, що в безумстві програмістів немає дна :)

2) GOTOs фактично використовуються (і корисні) для помилок відкату

3) краще вивчіть, як працює розподіл пам'яті (різниця між купою та будь-яким стеком?).

Тому в основному моя теза така: якщо ви вже закінчили університет і вам все ще не потрібен C, ніж не вивчайте його :)

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

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

Покажчики:

List<object> listOne = new List<object>();
List<object> listTwo = listOne;

listTwo.Add(new object());

Debug.WriteLine(listOne.Count); //do you know what this will be?

Струни:

string initial = "initial";
string another = initial;

another = "changed!";
Debug.WriteLine(initial); //what about this?

Списки:

Коли ви використовуєте список проти пов’язаного списку? (Майже неможливо це знати, не розуміючи на досить низькому рівні того, як працює список)

-

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

Що може навчити мене програмування низького рівня, яких інших мов не навчив би мене?

Найголовніше - це навчить вас, як комп’ютери насправді працюють. Немає іншого способу навчитися цьому, крім програмування низького рівня. Незалежно від того, які програми ви програмуєте, це завжди допоможе. Ви насправді зрозумієте, що відбувається глибоко внизу під усіма веб-речами. А якщо ви працюєте з Windows, весь API написаний на C, тому знаючи, що ця мова дозволить вам безпосередньо спілкуватися з ОС, коли вам потрібно використовувати функцію, якої не вистачає вашим поточним мовам та їх бібліотекам.

Звичайно, програмування низького рівня дозволять вам працювати з абсолютно різними речами, як-от вбудоване програмування та програмування в режимі реального часу, де asm / C / C ++ є обов'язковим. Якщо у вас немає інтересу до подібного роду додатків, насправді не дуже потрібно вивчати asm / C / C ++.

Також ви дізнаєтеся біти та байти. Бітові маніпуляції, шістнадцятковий тощо. Ці речі, з якими ви можете стикатися час від часу, навіть під час програмування в Інтернеті / настільних програмах. Алгоритми шифрування - один із таких прикладів, де він використовується.