Я переживаю кризу впевненості у своїх можливостях як комп'ютерного програміста.

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

Це така річ, яку хороший програміст повинен мати можливість «винаходити» за пару годин, чи я нереальний?

Ну добре, принаймні мені вдалося винайти сортування міхурів: D

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

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

Це така річ, яку хороший програміст повинен мати можливість «винаходити» за пару годин, чи я нереальний?

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

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

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

(Caveat: ну, ви повинні мати можливість вирішити проблему за кілька годин, але це не призведе до роботи алгоритму навіть на досить малих графіках.)

Це така річ, яку хороший програміст повинен мати можливість «винаходити» за пару годин, чи я нереальний?

Однозначно нереально. Люди не просто "придумують" алгоритми за кілька годин. Це вимагає багато зусиль і роботи. Щоб процитувати цей блог:

У програмуванні Pearls Бентлі, цитуючи Дональда Кнута, зазначає: "Поки перший бінарний пошук був опублікований у 1946 році, перший бінарний пошук, який працює правильно для всіх значень n, з'явився до 1962 року".

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

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

Навряд чи ви зможете знайти краще рішення, ніж ті, з яких ви можете вибрати.

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

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

(s) Він також повинен мати можливість знати, чи справді це найкращий шлях для вирішення конкретної проблеми.

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

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

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

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

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

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

Я знаю деяких дуже розумних та компетентних програмістів, яким доводилося навчати закону DeMorgan у школі, перш ніж вони могли це робити послідовно. Мені довелося самостійно розібратися з Алгоритмом Дейкстри (і я повинен визнати, що я трохи пишаюся цим), але це пройшло у мене дуже багато часу, поки я навіть не міг зрозуміти сортування бульбашок.

Більше відомо, що Ейнштейн, який, на вашу думку, може бути знавцем теорії вузлів, не міг пов'язати власні шнурки, поки йому не виповнилося десять років.

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

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

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

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

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

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

(BTW мій дозвіл вважається таким же порядком важливості, що і купон на безкоштовну автомийку.)

Так, він / вона повинен.

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

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

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

Не хвилюйся

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

Тому я говорю це:

1. Я не рекомендую винаходити колесо, але коли ви це зробите ...
2. Намагайтеся не повністю винаходити це і ...
3. Не хвилюйтесь, якщо ви не можете цього зробити. Ось чому у нас є спільнота програмування :-).

Теорія графіків та алгоритми, що застосовуються до нього, виглядають просто на поверхні, але, як правило, далеко від нього. Ви можете подумати, що, на перший погляд, формування непересічних (планарних) графіків є простим. Минулого року я детально розглядав цю проблему (планарність через усунення підграфів Куратовського). З цього досвіду я можу сказати, що люди, які пишуть ці алгоритми, зазвичай проводять тривалість докторантури, роблячи це, а іноді дослідження проводяться в командах. І як дослідники , це єдина їх робоча спрямованість протягом цього періоду часу. Нерозумно думати, що ми на місцях інженери можемо очікувати того самого. Як справедливо сказав хтось тут, його сліпо очевидно, коли рішення стоїть перед вами. Це завжди здається так!

Це така річ, яку хороший програміст повинен мати можливість «винаходити» за пару годин, чи я нереальний?

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

Це означатиме, що ви ігноруєте досить історію проблеми найкоротшого шляху , переходячи від алгоритму O (| V | ^ 4), опублікованого в 1955 році, до алгоритму O (E + V log V), опублікованого в 1984 році (що є Dijkstra алгоритм з деревами Фібоначчі). Ви майже гарантовано зробите гірше, ніж вже розроблені алгоритми. Що ще гірше, є великий шанс, що ваш алгоритм має прогалини або помилки, роблячи його неправильним. Крім того, ви майже напевно витратите набагато більше часу на продумування свого алгоритму, його реалізацію та тестування, ніж час, який знадобиться для повторного використання існуючого алгоритму.

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

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