"Парадокс" і "+" +

Я читав статтю тут: http://www.paulgraham.com/avg.html і частина про "парадокс" була особливо цікава. Як хтось, котрий головним чином кодує c ++, але має інший мову (в основному Haskell), я знаю кілька корисних речей на цих мовах, які важко повторити на c ++. Питання в основному стосується людей, які володіють як мовою c ++, так і якоюсь іншою мовою, чи є якась потужна мовна особливість чи ідіома, якою ви користуєтесь мовою, яку було б важко концептуалізувати чи реалізувати, якби ви писали лише на c ++?

Зокрема, ця цитата привернула мою увагу:

За індукцією, єдиними програмістами, які в змозі побачити всі відмінності у силі між різними мовами, є ті, хто розуміє найпотужнішу. (Це, мабуть, мав на увазі Ерік Реймонд про те, що Лісп зробить вас кращим програмістом.) Ви не можете довіряти думкам інших, через парадокс Блуба: вони задоволені якою мовою вони користуються, бо це диктує як вони думають про програми.

Якщо виявиться, що я еквівалент програміста "Blub" завдяки використанню c ++, то виникає таке питання: Чи є корисні поняття чи методи, з якими ви стикалися на інших мовах, які вам було б важко осмислити, якби у вас писав чи «думав» у c ++?

Наприклад, парадигма логічного програмування, що спостерігається на таких мовах, як Prolog і Mercury, може бути реалізована в c ++ за допомогою бібліотеки castor, але в кінцевому підсумку я вважаю, що концептуально я замислююсь з точки зору коду Prolog і перекладаю на еквівалент c ++ при використанні цього. Як спосіб розширити свої знання з програмування, я намагаюся з’ясувати, чи є інші подібні приклади корисних / потужних ідіом, які ефективніше виражаються іншими мовами, про які я, можливо, не знаю як розробник c ++. Інший приклад, який спадає на думку, - це макросистема в lisp, генерування програмного коду всередині програми, здається, має багато переваг для деяких проблем. Здається, це важко здійснити і продумати зсередини c ++.

Це питання не може бути дискусією "c ++ vs lisp" або будь-якою дискусією типу мовних воєн. Задаючи таке питання, це єдиний спосіб, коли я бачу можливість дізнатися про речі, про які я не знаю, я не знаю.

Ну, оскільки ви згадали про Haskell:

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

   map :: (a -> b) -> [a] -> [b]
   map f [] = []
   map f (x:xs) = f x : map f xs

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

3. Функціональне програмування загалом. Використання карт і складок замість ітерації. Рекурсія. Йдеться про мислення на вищому рівні.

4. Ледача оцінка. Знову мова йде про роздуми на більш високому рівні та дозволити системі обробляти оцінку.

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

Пам'ятайте!

Спробуйте написати це на C ++. Не з C ++ 0x.

Занадто громіздкий? Гаразд, спробуйте це з C ++ 0x.

Подивіться, чи можете ви перемогти цю 4-лінійну (або 5-рядкову, будь-яку: P) компіляційну версію в D:

auto memoize(alias Fn, T...)(T args) {
    auto key = tuple(args);                               //Key is all the args
    static typeof(Fn(args))[typeof(key)] cache;           //Hashtable!
    return key in cache ? cache[key] : (cache[key] = Fn(args));
}

Все, що вам потрібно зробити, щоб зателефонувати йому, це щось на кшталт:

int fib(int n) { return n > 1 ? memoize!(fib)(n - 1) + memoize!(fib)(n - 2) : 1;}
fib(60);

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

(define (memoize f)
    (let ((table (list)))
        (lambda args
            (cdr
                (or (assoc args table)
                    (let ((entry (cons args (apply f args))))
                        (set! table (cons entry table))
                        entry))))))
(define (fib n)
        (if (<= n 1)
            1
            (+ (fib (1- n))
                (fib (- n 2)))))))
(set! fib (memoize fib))

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

Однак, я не можу придумати верхню частину головної мови рідної мови C ++, яка робить те, що робиться yieldв Python або JavaScript.

Інший приклад - паралельне програмування . C ++ 0x буде говорити про це, але нинішній стандарт не робить, і паралельність - це зовсім новий спосіб мислення.

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

Супроводи - це надзвичайно корисна мовна функція, яка лежить в основі більшої кількості відчутних переваг інших мов у порівнянні з C ++. Вони в основному забезпечують додаткові стеки, тому функції можна переривати і продовжувати, надаючи схожі на конвеєр мови засоби, які легко подають результати операцій через фільтри до інших операцій. Це чудово, і в Ruby я знайшов це дуже інтуїтивно та елегантно. Лінива оцінка також пов'язана з цим.

Інтроспекція та компіляція / виконання коду під час виконання / оцінювання / що завгодно - це потужно потужні функції, яких не вистачає на C ++.

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

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

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

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

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

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

¹ Можливо , не зовсім доречний, але carі cdrвзяти їх імена з апаратних засобів: перший Лисп побіг на машині , яка мала фактичний декремент регістр і фактична адреса Регістр. Як це?

Асоціативні масиви

Типовим способом обробки даних є:

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

Правильний інструмент для цього є асоціативний масив .

• Найкраща мовна підтримка асоціативних масивів, які я бачив, - це MUMPS , де асоціативні масиви: 1. завжди сортуються 2. їх можна створити на диску (так звана база даних) з таким самим синтаксисом. (Побічний ефект: він надзвичайно потужний як база даних, програміст має доступ до нативного btree. Найкраща система NoSQL коли-небудь.)
• Мій другий приз припадає на PHP , мені подобається синтаксис foreach та easy, як $ a [] = x або $ a [x] [y] [z] ++ .

Мені не дуже подобається синтаксис асоціативного масиву JavaScript, тому що я не можу створити, скажімо, [x] [y] [z] = 8 , спочатку я повинен створити [x] і a [x] [y] .

Гаразд, в C ++ (і на Java) є хороший портфоліо класів контейнерів Map , Multimap , що б там не було, але якщо я хочу сканувати, я повинен зробити ітератор, і коли я хочу вставити новий елемент глибокого рівня, я повинні створити всі верхні рівні тощо. Некомфортно.

Я не кажу, що в C ++ (і Java) немає корисних асоціативних масивів, але безмовні (або не строгі набрані) мови скриптів перемагають складені, оскільки вони є безтиповими мовами скриптів.

Відмова: Я не знайомий з C # та іншими .NET мовами, AFAIK вони мають гарну асоціативну обробку масиву.

Я не навчаюсь Java, C \ C ++, складанню та Java Script. Я використовую C ++, щоб заробляти на життя.

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

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

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

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

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

чи є якась потужна мовна особливість чи ідіома, якою ви користуєтесь мовою, яку було б важко концептуалізувати чи реалізувати, якби ви писали лише на c ++?

Чи є якісь корисні поняття чи прийоми, з якими ви стикалися в інших мовах, які вам було б складно осмислити, якби ви писали чи «думали» на c ++?

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

Реєструйте конвенції про розподіл та виклики

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

Щоб дізнатись про такі поняття, я рекомендую ознайомитись з програмуванням мови монтажу та ознайомтесь із цією статтею про якість генерації коду ARM .

Генерація коду часу виконання

Якщо ви знаєте лише C ++, то, напевно, ви думаєте, що шаблони - це всебічне і кінцеве метапрограмування. Вони ні. Насправді вони є об'єктивно поганим інструментом метапрограмування. Будь-яка програма, яка маніпулює іншою програмою, є метапрограмою, включаючи інтерпретатори, компілятори, системи комп’ютерної алгебри та докази теореми. Генерація коду під час виконання - корисна функція для цього.

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

Маніпуляція деревами

Дерева є скрізь у програмуванні. При розборі у вас є абстрактні синтаксичні дерева. У компіляторах є ІР, які є деревами. У графіці та графічному програмуванні у вас є дерева сцен.

Цей "надзвичайно простий парсер JSON для C ++" важить всього 484 LOC, що дуже мало для C ++. Тепер порівняйте його з моїм простим аналізатором JSON, який важить лише 60 LOC F #. Різниця полягає насамперед у тому, що алгебраїчні типи даних ML та відповідність шаблонів (включаючи активні візерунки) значно полегшують маніпулювання деревами.

Ознайомтесь і з червоно-чорними деревами в OCaml .

Суто функціональні структури даних

Нестача GC в C ++ робить практично неможливим прийняття деяких корисних підходів. Суто функціональні структури даних є одним із таких інструментів.

Наприклад, ознайомтеся з цим збірником регулярних виразів 47 рядків в OCaml. Стислість зумовлена ​​значною мірою широким використанням суто функціональних структур даних. Зокрема, використання словників із наборами ключів. Це дійсно важко зробити в C ++, оскільки словники та набори stdlib всі змінні, але ви не можете мутувати ключі словника або ви порушуєте колекцію.

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

Хвост дзвінки

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

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

Паралельність

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

Це давнє запитання, але оскільки ніхто про це не згадував, я додам перелік (і тепер дік) розуміння. Написати однолінійку в Haskell або Python легко, що вирішує проблему Fizz-Buzz. Спробуйте це зробити на C ++.

У той час як C ++ робив величезні кроки до сучасності за допомогою C ++ 11, це трохи розтягує назву "сучасної" мови. C ++ 17 (який ще не був випущений) робить ще більше кроків, щоб досягти сучасних стандартів, якщо "сучасний" означає "не з попереднього тисячоліття".

Навіть найпростіші розуміння, які можна записати в один рядок на Python (і підкоряючись обмеженню довжини рядка 79 символів Гуйдо), стають безліччю і безліччю рядків кодів при перекладі на C ++, а деякі з цих рядків коду С ++ є досить складними.

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

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

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

Саме ця особливість Objective-C навчила мене оцінювати здатність мови передавати будь-який тип об'єктів / функцій / що б не було важливо-поняття-мова - навколо них, а також сили їх збереження змінні. Будь-яка точка мови, яка визначає будь-який тип поняття, але не забезпечує засоби для його зберігання (або посилання на нього) у всіх доступних видах змінних, є важливим каменем спотикання і, ймовірно, джерелом дуже негарного, дубльований код. На жаль, барокові мови програмування мають тенденцію проявляти ряд таких моментів:

• У C ++ ви не можете записувати тип VLA, а також зберігати вказівник на нього. Це фактично забороняє справжні багатовимірні масиви динамічного розміру (які доступні в C з C99).

• У C ++ ви не можете записати тип лямбда. Ви навіть не можете ввести це. Таким чином, немає можливості обійти лямбда або зберегти посилання на неї в об'єкті. Функції лямбда можна передавати лише шаблонам.

• У Fortran ви не можете записати тип назви. Просто не існує способу передати назовнику будь-яку рутину. Отже, якщо у вас є складний алгоритм, який повинен вміти обробляти два різних назви, вам не пощастить. Ви не можете просто написати алгоритм один раз і передати йому відповідні назви.

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