Під час поточного (2013) конкурсу Google Code Jam виникла проблема, яка взяла C ++ та Java людей 200+ рядків коду порівняно з людьми Python, які вирішили ту саму проблему лише за допомогою 40 рядків коду.

Python не є безпосередньо порівнянним з C ++ та Java, але різниця у багатослівності, як я вважав, може вплинути на ефективність алгоритму.

Наскільки важливим є знання правильного алгоритму порівняно з вибором мови? Чи могла б чудово реалізована програма Python реалізована в C ++ або Java краще (використовуючи той самий алгоритм) і чи це має якесь відношення до природного багатомовності певних мов програмування?

Очевидно, якщо ви розглядаєте це питання в контексті чогось на кшталт Google Code Jam, алгоритмічне мислення явно важливіше, коли потрібно вирішувати алгоритмічні проблеми.

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

Просто зустрічний приклад: якщо вам потрібно ще 200 рядків на Java, але всі у вашій компанії знають Java, це не є великою справою. Якби ви могли написати це в 5 рядках Python або будь-якою іншою мовою, але ви б єдиним в компанії знали цю мову - це велика справа. Насправді така велика справа, що вам навіть цього не дозволять, а натомість доведеться писати це на Java.

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

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

Щодо алгоритмічних змагань, однак мій особистий досвід змагання в них протягом декількох років чітко підказує мені, що слід дотримуватися однієї мови. Швидкість - головний фактор, і ви просто не можете дозволити собі витрачати час на свої інструменти, коли вам слід присвятити його вирішенню проблем у визначений термін. Також врахуйте, що написання 200 рядків коду Java без роздумів все-таки набагато швидше, ніж обробка 50 рядків складного пітонного коду, що вимагає багато роздумів, але обидва вирішують більш-менш ту саму проблему.

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

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

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

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

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

Мова має значення.

DARPA і ВМС США провели експеримент з перестрілки майже 20 років тому. Переможцем темного коня став Хаскелл. Ада та C ++ були представлені; Яви не було.

Приблизно в той же час Pratt & Whitney провели дослідження даних щодо проектів контролерів реактивних двигунів, переглянувши дані таймкарту та помилки трекера. Вони виявили, що Ада давала подвоєну продуктивність програміста і 1/4 щільність дефектів будь-якої іншої мови, якою вони користуються.

Atari використовував FORTH для розробки відеоігор, і той факт, що вони використовували FORTH, вважався надзвичайно захищеним.

Зауваження Пола Грехема щодо використання LISP добре відомі. Erann GAT в коментарі на LISP в JPL однаково переконливі, хоча і не так добре відомі.

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

Мова має значення.

Деякі моменти:

• Верхні позиції мають тенденцію до C ++ / C / Java, незалежно від кількості рядків коду різниця між цією та іншою мовою. Це може бути більше про те, що топ-кодери мають тенденцію вибирати ці мови над деякими іншими, можливо, через швидкість їх використання.
  На жаль, ви не можете легко побачити мову програмування в Google Code Jam, але я завантажив декілька найкращих і, наскільки я пам’ятаю, це переважно C / C ++. TopCoder (популярний веб-сайт хостингу конкурсів програмувань) здебільшого має подібні результати.

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

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

• Пряма кількість ліній не така вже й велика справа. Як тільки ви отримаєте достатній досвід програмування, ви дізнаєтесь, що можете витратити 10 хвилин на програмування 10 рядків або 200 рядків, все залежить від того, наскільки складні лінії. Крім того, якщо ви закодували подібний код сотні разів, ви зможете зробити це досить швидко. Не надто згадуйте про всі макроси, які найпопулярніші C / C ++ кодери часто використовують для оптимізації свого часу кодування.

• Френк зазначає хорошу думку - (поза межами змагань з програмування) ви не можете займатися кодуванням в Python для вашої компанії, якщо вся їхня кодова база знаходиться на C або будь-якому іншому, вам потрібно відповідати їх мові.

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

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

Звичайно, у випадку таких змагань, як Code Jam чи TopCoder, це не велика вага, оскільки це всього 40 рядків проти 200 рядків. З іншого боку, для цього виду конкуренції найбільше значення має часова / просторова складність алгоритму. У той час як у реальному застосуванні YMMV, у цих типах змагань алгоритм O (n) , написаний на найповільніших мовах, завжди буде бити O (n²), записаний на найшвидших мовах. Тим більше, що буде кілька тестів, які є найгіршим сценарієм.

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

C ++ проти Python?

Чистий Пітон повільний. Ось чому стандартний інтерпретатор Python (CPython) написаний на C. Практично всі з вбудованими функціями написані як оптимізовані C. Python також може бути легко використаний у поєднанні з бібліотеками C (через ctypes або як рідні модулі cpython ) та з бібліотеками C ++ через Boost :: Python . Таким чином ви можете записати свою логіку високого рівня на Python, гнучку мову, що дозволяє швидко прототипувати та адаптувати (це означає, що ви можете витратити більше часу на налаштування та вдосконалення свого алгоритму). OTOH, ви можете записати свої функції бібліотеки нижчого рівня в модуль C або C ++. Чудовим прикладом такого підходу є SciPy, що є бібліотекою Python, але під кришкою він використовує високооптимізовані числові бібліотеки, такі як ATLAS, LAPACK, Intels MKL або AMML AMML.

На мою думку, те, що люди розмовно розглядають "мови програмування", - це фактично три окремі речі:

1. Тип мови та синтаксис
2. Мова IDE
3. Наявні бібліотеки для мови

Наприклад, коли хтось виводить C # в дискусію, ви можете подумати, що він / вона говорить про синтаксис мови (1), але на 95% впевнено, що дискусія буде включати .Net Framework (3). Якщо ви не розробляєте нову мову, важко і зазвичай безглуздо виділяти (1) і ігнорувати (2) і (3). Це тому, що IDE та стандартна бібліотека - це "фактори комфорту", які безпосередньо впливають на досвід використання певного інструменту.

Останні кілька років я теж брав участь у програмі Google Code Jam. Перший раз я вибрав C ++, оскільки він має гарну підтримку для читання вводу. Наприклад, зчитування трьох цілих чисел зі стандартного вводу в C ++ виглядає так:

int n, h, w;
cin >> n >> h >> w;

Хоча в C # те саме буде виглядати так:

int n, h, w;
string[] tokens = Console.ReadLine().Split(' ');
n = int.Parse(tokens[0]);
h = int.Parse(tokens[1]);
w = int.Parse(tokens[2]);

Це набагато більше розумових витрат на просту функціональність. У C # речі з багаторядковим введенням ускладнюються. Можливо, я просто тоді не придумав кращого шляху. У всякому разі, я не зміг пройти перший раунд, тому що у мене виникла помилка, яку я не зміг виправити до кінця раунду. За іронією долі метод введення читання пригнічував помилку. Проблема була проста: введення містило число, яке було занадто великим для 32-бітного цілого числа. У C # int.Parse(string)буде викинуто виняток, але в C ++ потік введення файлу встановив би певний прапор помилки і не вдасться мовчки зробити так, щоб підозрюючий розробник не знав про проблему.

Обидва приклади демонструють, як бібліотека використовувалася, а не синтаксис мови. Перший демонструє багатослівність, а другий демонструє надійність. Багато бібліотек переносяться на кілька мов, а деякі мови можуть використовувати бібліотеки, які спеціально не створені для них (див. Відповідь @ vartec про Python з бібліотеками C).

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

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

Integer prev = b.get(k)
if (prev == null) prev = 0
Integer v = a.get(k);
if (v == null) v = 0;
b.put(prev + v);

замість

b[k] += a[k]

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

NB

Різниця між 200 рядками коду та 40 рядками коду величезна, і вона ще більша, коли це різниця між лінією програми 200 000 та лінією програми 40000. Тоді це різниця між командою з п'яти плюс менеджер та командою з одного чи двох.

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

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

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

На мою думку, оптимізація для найменшого LoC майже ніколи не є доброю ідеєю. Так, кожен написаний LoC - це потенціал для помилок, і вам ніколи не доведеться налагоджувати те, що ви ніколи не писали тощо. Справа в тому, що оптимізувати для читабельності та нерозбірливості. Не має значення, чи вирішуєте ви проблему за допомогою великого регексу в 20 рядків, на відміну від написання модуля 1k LoC. Регекс буде непрозорою стіною, надзвичайно схильною до помилок, важко зрозуміти, кошмарам змінювати, не змінюючи свою поведінку ненаголошеними способами тощо.

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

Дуже показове порівняння: я б скоріше мав 100-мільйонний лок-код тестово нерозчленованого коду C #, наповнений такими предметами, як «надмірне вбивство», як стратегічний зразок, фабрики тощо, а не програма з 20-пітним пітоном, яка просто «спрацьовує». У 5 разів більше коду чи ні, архітектура виграє щодня.

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