C # Dev - я спробував Lisps, але я не розумію [закрито]

Після кількох місяців навчання та гри з Ліспом, як з CL, так і з Clojure, я все ще не бачу вагомих причин писати що-небудь замість C #.

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

Сильні сторони Lisp (за моїм дослідженням):

• Компактна, виразна нотація - Більше, ніж C #, так ... але, здається, я можу висловити ці ідеї і в C #.
• Неявна підтримка функціонального програмування - C # з методами розширення LINQ:
  • mapcar = .Вибір (лямбда)
  • mapcan = .Select (лямбда) .Aggregate ((a, b) => a.Union (b))
  • машина / перший =. Перший ()
  • cdr / rest = .Skip (1) .... і т.д.
• Підтримка функції лямбда та вищого порядку - у C # це є, а синтаксис, можливо, простіший:
  • "(лямбда (х) (тіло))" проти "х => (тіло)"
  • "# (" з "%", "% 1", "% 2" приємно в Clojure
• Відправлення методу відокремлено від об'єктів - C # має це за допомогою методів розширення
• Мультиметод-диспетчер - C # не має цього в основному, але я міг би реалізувати це як виклик функції за кілька годин
• Код - це дані (і макроси) - можливо, я не "дістав" макросів, але я не бачив жодного прикладу, де ідея макросу не могла бути реалізована як функція; це не змінює "мову", але я не впевнений, що це сила
• DSL - це можна зробити лише за допомогою функції функцій ... але це працює
• Нетипізоване "дослідницьке" програмування - для структур / класів, автоматичні властивості C # та "об'єкт" працюють досить добре, і ви можете легко перерости в сильніший текст, коли ви йдете разом
• Працює на апаратному забезпеченні, яке не є Windows - Так, так? Поза межами коледжу я знав лише одну людину, яка не працює вдома Windows або хоча б VM Windows на * nix / Mac. (Знову ж таки, можливо, це важливіше, ніж я думав, і мені щойно промили мозок ...)
• REPL для дизайну знизу вгору - Гаразд, я визнаю, це дійсно дуже добре, і мені це не вистачає в C #.

Те, чого мені не вистачає в Lisp (завдяки суміші C #, .NET, Visual Studio, Resharper):

• Простори імен. Навіть зі статичними методами я люблю прив'язувати їх до "класу", щоб класифікувати їх контекст (Clojure, здається, має це, CL не здається.)
• Прекрасна підтримка компіляції та дизайну
  • система типів дозволяє мені визначати "правильність" структур даних, які я передаю
  • в режимі реального часу підкреслюється що-небудь неправильно написане; Мені не потрібно чекати часу виконання, щоб знати
  • удосконалення коду (наприклад, використання підходу FP замість імперативного) автоматично запропоновано
• Інструменти розробки графічного інтерфейсу: WinForms та WPF (я знаю, що Clojure має доступ до бібліотек Java GUI Java, але вони мені повністю чужі.)
• Інструменти для налагодження графічного інтерфейсу: точки прориву, вхід, перехід, інспектори значень (текст, xml, користувальницький), годинник, налагодження за допомогою потоку, умовні точки перерви, вікно стека виклику з можливістю переходити до коду на будь-якому рівні в стопку
  • (Справедливо кажучи, моє враження щодо Emacs + Slime, здавалося, щось із цього забезпечує, але я частково ставлюся до підходу VS GUI)

Мені дуже подобається ажіотаж навколо Lisp, і я дав йому шанс.

Але чи можу я зробити в Ліспі щось, що я не можу зробити так добре в C #? Це може бути трохи докладніше в C #, але у мене також є автозаповнення.

Що я пропускаю? Чому я повинен використовувати Clojure / CL?

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

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

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

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

Отже, підсумовуючи те, що люди, як правило, роблять w / мови, як, наприклад, C #, - це побудувати DSIL (інтерпретовані мови, визначені для домену). Lisp надає вам можливість створити щось набагато більш радикальне, DSP (Paradigms Specific Paradigms). Ракетка (раніше PLT-схема) особливо надихає в цьому плані - вони мають ледачу мову (Lazy Racket), набрану (Typed Racket), Prolog та Datalog, вбудовану ідіоматично через макроси. Усі ці парадигми забезпечують потужне вирішення великих класів проблем - проблем, не найкращим чином вирішених імперативним програмуванням або навіть парадигмами ПП.

Практично все, що спочатку було доступне лише в Ліпсі, вдячно перейшло на безліч інших сучасних мов. Найбільшим винятком є ​​філософія "код - дані" та макроси.

Код - це Дані (і макроси) - Можливо, я не "дістав" макросів, але я не бачив жодного прикладу, де ідея макросу не могла бути реалізована як функція

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

Приклад "привіт світу" макросу - писати "якщо" з точки зору cond. Якщо вам дійсно цікаво дізнатись про силу макросів, спробуйте визначити "мій-якщо" в clojure, використовуючи функції та спостерігайте, як він ламається. Я не хочу бути таємничим, я просто ніколи не бачив, щоб хто-небудь починав розуміти макроси за допомогою пояснення поодинці, але це слайд-шоу є досить хорошим введенням: http://www.slideshare.net/pcalcado/lisp-macros-in -20-хвилин-показ-кложур-презентація

У мене були невеликі проекти, де я зберігав буквально сотні / тисячі рядків коду за допомогою макросів (порівняно з тим, що було б у Java). Значна частина Clojure реалізована в Clojure, що можливо лише завдяки макросистемі.

Я не є експертом у Common Lisp, але знаю і C #, і Clojure досить добре, тому, сподіваюся, це корисна перспектива.

• Простий синтаксис => потужність - Lisps - це про найпростіший синтаксис, який міг би працювати. S-вирази - все, що вам потрібно. Після того, як ви "grokked" (function-call arg1 arg2 arg3) ", ви в основному це отримали. Решта - це лише вибір правильних викликів та аргументів функції. Здається, це майже тривіально просто, але факт полягає в тому, що ця простота - це те, що надає Ліпсу стільки сил і гнучкості, і, зокрема, дає можливість метапрограмування, якими славиться Лісп. наприклад, якщо я хочу, щоб макрос викликав кілька різних функцій на одних і тих же аргументах, я просто роблю щось на кшталт наступного (не це не лише програма виконання програми - це макрос, який генерує скомпільований код, як ніби ви виписали всі окремі виклики функції вручну):

(defmacro print-many [functions args]  
  `(do   
     ~@(map   
        (fn [function] `(println (~function ~@args)))   
        functions)))

(print-many [+ - * /] [10 7 2])  
19  
1  
140  
5/7

• В результаті неймовірно простого синтаксису філософія Ліспа "Код - це дані" набагато потужніша за все, що ви можете зробити зі складом функцій / шаблонами / дженериками тощо. Це більше, ніж просто DSL, це генерування коду та маніпулювання під час компіляції , як фундаментальна особливість мови. Якщо ви спробуєте отримати такі можливості на мові, яка не гомонічна, на зразок C # або Java, врешті-решт, викрийте Lisp, погано. Звідси знамените десяте правило Грінспунса: "Будь-яка достатньо складна програма C або Fortran містить спеціальну, неофіційну інформацію, помилку, повільну реалізацію половини звичайного Lisp". Якщо ви коли-небудь опинялися, що винайшли загальнозміцнюючу мову шаблону / управління потоком у вашій програмі, ви, напевно, знаєте, що я маю на увазі .....

• Паралельність - це унікальна сила Clojure (навіть відносно інших Lisps), але якщо ви вважаєте, що майбутнє програмування означатиме необхідність писати програми, які масштабуються на високоядерних машинах, то вам справді слід справді розібратися в цьому - це досить новаторський. Clojure STM (Software Transactional Memory) працює тому, що Clojure охоплює незмінні та безконтурні конструкції одночасності, засновані на новому розділенні ідентичності та стану (див. Чудове відео Річ Хікі про особистість та стан ). Було б дуже боляче переносити подібні можливості сумісності на середовище мови / часу виконання, де значна частина API працює над об'єктами, що змінюються.

• Функціональне програмування - Ліпс підкреслює програмування з функціями вищого порядку. Ви маєте рацію в тому, що його можна імітувати в OO-об'єктах із закритими / функціональними об'єктами тощо, але різниця полягає в тому, що вся мова та стандартна бібліотека розроблені, щоб допомогти вам писати код таким чином. Наприклад, послідовності Clojure ліниві , тому можуть бути нескінченно довгими на відміну від ваших ArrayLists або HashMaps в C # / Java. Це робить деякі алгоритми набагато простішими у висловленні, наприклад, наступний реалізує нескінченний список номерів полів:

  (def fibs (lazy-cat '(0 1) (map + fibs (drop 1 fibs))))

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

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

Кілька швидких коментарів до речей, які ви вважаєте "відсутніми":

• Як ви кажете, у Clojure є простори імен. Насправді це динамічні простори імен: ви можете оновити їх під час виконання - це дає деякі дивовижні переваги для інтерактивної розробки. Мені було весело переосмислювати функції під носом запущеної нитки або зламати живу структуру даних ....
• Підтримка часу компіляції / проектування - не дуже актуальна, якщо ви кодуєте в системі REPL - ви просто зробите це і побачите результат безпосередньо. Сказавши це, Clojure починає отримувати покращену підтримку IDE, наприклад, плагін CounterClockwise для Eclipse .
• Розробка графічного інтерфейсу - Так, вам доведеться вивчити новий API, але це завжди буде так, коли потрібно перемикати мови .... хороша новина полягає в тому, що Java API не такі вже й важкі, і зараз є цікаві Clojure- конкретні обгортки / приклади, які виглядають досить просто у використанні. Дивіться це питання щодо розробки графічного інтерфейсу Clojure, щоб побачити кілька прикладних прикладів
• Налагодження GUI: це працює з налагодженням графічного інтерфейсу в Eclipse, якщо ви використовуєте CounterClockwise або Enclojure, якщо ви використовуєте Netbeans. Сказавши це, я не використовую цю можливість - я вважаю інтерактивне налагодження в REPL більш продуктивним.

Я особисто вважаю переваги Clojure / Lisp досить переконливими, і не збираюся повертатися до C # / Java (крім того, що мені потрібно позичити всім корисним бібліотекам!).

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

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

У звичайного Lisp є така суміш:

• s-вирази як синтаксис даних
• код як дані призводить до макросів та інших прийомів символічного обчислення
• динамічна мова дозволяє змінювати час виконання (пізнє прив'язування, MOP, ...)
• сильно набраний, динамічно набраний
• інтерактивне використання з інкрементальним компілятором чи перекладачем
• Оцінювач як двигун основних процесів
• керована пам'ять за допомогою збирання сміття
• Гібридна мова з важким використанням імперативного, функціонального та об’єктно-орієнтованого програмування. Можна додати й інші парадигми (правила, логіка, обмеження, ...).

Тепер інші мови, як-от C #, також мають це. Але часто не з однаковим акцентом.

C # має

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

Це не допомагає, що C # має, наприклад, функції маніпулювання кодом, якщо вони широко не використовуються, як у Lisp. В Lisp ви не знайдете багато програмного забезпечення, яке не використовує макросів у всіх видах простих і складних способів. Використання маніпуляції кодом - це справді велика особливість у Lisp. Емуляція деяких застосувань можлива у багатьох мовах, але це не робить її центральною особливістю, як у Lisp. Перегляньте приклади книг на кшталт "On Lisp" або "Practical Common Lisp".

Те саме для інтерактивного розвитку. Якщо ви розробляєте велику систему САПР, більша частина розробки буде інтерактивною з редактора, а REPL - безпосередньо в запущеному додатку CAD. Більшу частину цього можна імітувати на C # або інших мовах - часто застосовуючи мову розширення. Для Lisp було б нерозумно перезавантажувати додаток CAD, що розробляється, для додавання змін. Система CAD також міститиме розширений Lisp, який би додав мовні функції (у вигляді макросів та символічних описів) для опису об'єктів CAD та їх взаємозв'язків (частково, що містяться, ...). Можна робити подібні речі в C #, але в Lisp це стиль розробки за замовчуванням.

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

Якщо ви працюєте в середовищі Windows (я цього не роблю), C # має перевагу, оскільки це основна мова розробки Microsoft. Microsoft не підтримує жодної форми Lisp.

Ви пишете:

• Простори імен. Навіть зі статичними методами я люблю прив'язувати їх до "класу", щоб класифікувати їх контекст (Clojure, здається, має це, CL не здається.)

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

• Велика підтримка компіляції та проектування-часу система типів дозволяє мені визначити "правильність" структур даних, які я передаю навколо чогось неправильно написаного, підкресленого в реальному часі; Мені не потрібно чекати, поки час виконання, щоб знати покращення коду (наприклад, використання FP-підходу замість імперативного), автоматично запропоновано

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

• Інструменти розробки графічного інтерфейсу: WinForms та WPF (я знаю, що Clojure має доступ до бібліотек Java GUI Java, але вони мені повністю чужі.)

Комерційні Lisps, такі як LispWorks та Allegro CL, пропонують подібні речі під Windows.

• Інструменти для налагодження графічного інтерфейсу: точки прориву, вхід, перехід, інспектори значень (текст, xml, користувальницькі), годинник, налагодження за допомогою потоку, умовні точки перерви, вікно стека виклику з можливістю переходити до коду на будь-якому рівні у групі (Чесно кажучи, моє враження про Emacs + Slime, здавалося, забезпечує щось із цього, але я часткова до підходу, орієнтованого на VS GUI)

Комерційні Lisps, такі як LispWorks та Allegro CL, пропонують усе це під Windows.

Реньє Джосвіг сказав це найкраще.

Для мене силу Ліса неможливо зрозуміти, просто переглянувши список функцій Lisp. Для Ліспа, і зокрема для Ліса, ціле більше, ніж сума частин. Це не лише REPL плюс s-вирази плюс макроси плюс багатопроменева відправка плюс закриття плюс пакунки плюс CLOS плюс перезавантаження плюс X, Y і Z. Це весь шебанг, все геніально інтегрований. Це щоденний досвід, який дуже сильно відрізняється, ніж щоденний досвід інших мов програмування.

Лісп виглядає інакше, він використовується по-різному, підходити до програмування по-іншому, коли його використовувати. Це елегантний, повний, великий та безшовний. Не обійшлося і без власних вад та пекадило. Звичайно, існують порівняння з іншими мовами, які можуть бути зроблені там, де він може не вийти попереду. Але жодним чином не є Lisp просто мовою X плюс REPL та макросами, а також мовою Y плюс мульти-методом відправки та перезапуску.

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

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

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

Хоча можливо виразити, що в якості функції (рядок порівняння, список випадків та закриттів для виконання) він, мабуть, не виглядає як "нормальний код", і саме там макроси lisp мають певну виграш. Ви , ймовірно , використовували досить багато макросів або спеціальні форми TAHT є макро-як, як defun, defmacro, setf, cond, loopі багато іншого.

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

http://www.defmacro.org/ramblings/lisp.html

Я пам'ятаю, як читав в іншому місці таку ідею, як така: Інші мови перейняли різні риси Ліспа; збирання сміття, динамічне введення тексту, анонімні функції, закриття для отримання кращого C ++ / C / Algol. Однак, щоб отримати повну потужність Ліспа, вам потрібні всі його основні риси, і тоді ви маєте ще один діалект Ліспа, чітке сімейство мов, яке існує в тій чи іншій формі вже більше 50 років.