Чому OCaml не є більш популярним?

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

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

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

Це суб'єктивне питання, але чому OCaml та ML інші мови залишилися настільки незрозумілими, тоді як C та інші мови стали популярними?

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

З цією відмовою, ось декілька моментів, які є сугестивними, найважливішими насамперед:

• Перший зрілий компілятор С з'явився в 1974 році; перший зрілий компілятор OCaml з'явився наприкінці 1990-х. C має 25-річний головний старт.

• C постачається з Unix, який був найбільшим "вбивчим додатком" усіх часів. Довгий час у кожному відділі CS у світі мав працювати Unix, а це означає, що кожен викладач та кожен, хто пройшов курс CS, мали можливість потрапити на C. OCaml та ML ще чекають свого першого вбивчого додатка. (MLdonkey класно, але це не Unix.)

• C так добре заповнює свою нішу, що я сумніваюся, що ніколи не буде іншої мови низького рівня, присвяченої лише програмуванню систем. (Щоб побачити докази на користь, прочитайте статтю Денніса Річі про історію С від ХОПЛ II.) Навіть не зрозуміло, що таке ніша OCaml, а ніша Standard ML - лише трохи зрозуміліша. Таким чином, у Caml та ML є досить багато конкурентів, тоді як C знищив свого єдиного конкурента (BLISS).

• Одне з великих сильних сторін C полягає в тому, що його модель витрат є дуже передбачуваною: легко подивитися на будь-який невеликий фрагмент коду С можна миттєво отримати точне уявлення про те, які операції на машині доведеться виконувати для виконання цього коду. Модель витрат OCaml набагато менш зрозуміла, тим більше, що розподіл пам'ятінабагато менш явна, а загальна вартість розподілу пам’яті (дорівнює вартості розподілу плюс витрати, понесені під час вивезення сміття) залежить від нових властивостей, таких як тривалий час проживання та які об’єкти відносять до інших об’єктів. Чистий результат полягає в тому, що результативність важко передбачити і навіть важко проаналізувати після факту. (Інструменти профілювання пам'яті OCaml - це не те, якими вони повинні бути.) Як результат, OCaml не підходить для додатків, де продуктивність повинна бути дуже передбачуваною, як вбудовані системи.

• C - це мова зі стандартною та безліччю компіляторів. OCaml - це програмний артефакт: єдиний компілятор із єдиного джерела, а компілятор - стандартний. І цей стандарт змінюється з кожним випуском. Для людей, які цінують стабільність та зворотну сумісність, мова з одним джерелом може представляти неприйнятний ризик.

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

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

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

(Я знаю, що зараз ведуться роботи, щоб змінити це, з такими проектами, як "Батареї включені". Поверніться сюди через 5 років, і, можливо, OCaml стане більш популярним.)

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

Результатом стала популярність. Гроші можуть вирішити масу проблем.

На арені функціональної мови ми бачимо, що Haskell стає досить популярним. Я думаю, що більша частина популярності пов’язана з такими людьми, як дони, які пишуть корисні бібліотеки, і ніколи не припиняють маркетинг мовою. Щодня ви бачите кілька статей Haskell про програмування Reddit. Це тримає його у свідомості людей, поки вони нарешті вирішать: "Я спробую спробувати Haskell". Коли вони це роблять, вони бачать корисні речі, такі як веб-рамки, об’єктні бази даних, бібліотеки OpenGL та бібліотеки обробки XML. Це означає, що вони насправді можуть зробити щось корисне «прямо зараз». Так що між потенціалом бути продуктивним та чути про нього багато, Haskell здобув велику популярність.

У CL багато таких самих бібліотек, що і у Haskell, і це майже так само швидко, але ніхто про це не говорить, тому він "відчуває себе мертвим". Дійсно, #lisp набагато тихіше, ніж #haskell, але Lisp як і раніше дуже продуктивна мова з великою кількістю бібліотек. Жодна інша мова не має SLIME. Але маркетинг дуже важливий, і Haskell робить це краще, ніж Lisp або OCaml (і конкурує за ту ж базу користувачів).

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

Мені подобається OCaml багато як мову. АЛЕ ...

Підтримка інструментів просто не існує. Відладчик працює добре, але не працює на Windows (востаннє я перевірив), і просто не так багато інструментів розробки для нього.

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

Стандартна бібліотека іноді може мати непослідовне відчуття.

Об'єктна модель здається дещо зафіксованою, і стандартна бібліотека ледь використовує її, замість цього вибираючи бібліотеки на основі модулів.

Є багато інших речей, які, в основному, полягають у тому, що мова не відчуває себе «відполірованою», і що відганяє людей у ​​дуже критичний період, коли вони вибирають мову та намагаються вирішити, чи подобається вона їм.

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

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

Це трохи порівняння від яблук до апельсинів. OCaml є досить молодою мовою [1], і ніколи не було серйозних, наполегливих зусиль, щоб ввести її в основний потік (за винятком поточної роботи Microsoft з F #). На відміну від C, це не lingua franca найбільш широко підтримуваної та імітованої операційної системи підприємства (тобто UNIX). На відміну від Java, у неї не було великої корпорації, яка висунула її як обчислювальну платформу нового покоління. На відміну від Perl, Python та Ruby, він не зайняв важливу впливову нішу (тобто його ніша - це мова програмування та автоматизовані дослідження міркувань - не дуже гучна порівняно з веб-розробкою). Отже, вона не надто популярна.

[1] Справедливо кажучи, оригінальна мова ML є приблизно з 70-х років. Але OCaml з'явився до 1996 року і він не успадкував бібліотеки Standard ML. Це, на практиці, молодша мова, ніж C, C ++, Java, Python, Haskell або навіть Ruby.

Спільнота OCaml не змогла розробити велику і надійну стандартну бібліотеку (крім того, що поставляється з OCaml сьогодні), що спрощує розробку додатків. Існує кілька спроб вирішити проблему, але просто подивіться на Python або Ruby, щоб побачити, чого немає. OCaml - це чудова мова, якщо ви хочете вирішити алгоритмічну проблему, яка не дуже залежить від необхідності взаємодії з передовими стандартними модулями, такими як XML, мережа, обчислення даних і так далі, які ви б краще не реалізували самостійно.

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

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

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

Мені показали ML та Smalltalk приблизно в один і той же час. Smalltalk просто виглядав проклятим класно, і відразу було зрозуміло, що таке OO і як можна зробити гарні, інтерактивні речі в цьому середовищі. ML стосувався абстрактних математичних речей, які не здавались важливими для того, що я хотів зробити. І на відміну від C, не обіцяв дозволити мені писати швидкі ігри на 16-бітних мікросередовищах.

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

У наші дні я думаю, що питання виникне: тепер я відчуваю, що мені потрібно знати цей дивний і заплутаний теоретичний матеріал про типи, чому я б обрав ML через Haskell або Erlang?

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

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

Крім того, люди, які знають такі мови, як OCaml, дуже неоднорідні. Серед веб-програмістів, можливо, один з 1000 почув про OCaml. Серед людей, які займаються науковими обчисленнями в Кембриджському університеті, близько 90% людей, яких я знав, вільно володіли OCaml. Дійсно, я був одним із останніх серед своїх друзів, які вивчали OCaml. Ми навіть запустили OCaml на нашому суперкомп'ютері 256 процесорів ...

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

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

Коли я вступив до університету, я вже знав розумну кількість BASIC, C ++ та Java та трохи мови мовлення Pascal та x86. Я був далеко не експерт, але дійшов висновку (трохи наївний), що всі мови програмування в основному однакові з дещо різним синтаксисом. У нашому вступі до курсу програмування було використано ML, яке швидко відключило мене від цього поняття. На цьому етапі моєї кар’єри в програмі мені було важко зайнятися головою навколо ML, і я не бачив сенсу функціонального програмування. Я думаю, що потрібно трохи більше досвіду з деякими проблемами процедурного програмування, щоб дійсно оцінити переваги функціонального підходу.

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

Існує також ефект зворотного зв’язку щодо популярності мови. Коли я почав програмувати, я хотів знати, як програмувати графічні ефекти та ігри. Вивчивши трохи BBC BASIC та пізніше QBASIC, я, природно, дослідив, які найпоширеніші мови використовували програмісти демо-сцени та ігор, і почав вивчати складання C ++ та x86. Сьогодні деякі нові програмісти можуть захотіти знати, як створювати веб-додатки, і тому вони будуть тяжіти до вивчення PHP, Ruby або C #. Існує дуже мало областей застосування для самомотивованих програмістів-початківців, де відповідь на тему "яка найкраща мова навчитися програмувати щось на зразок X" буде "Ocaml".

Багато практичних причин, що пояснюються обмеженою популярністю Ocaml (відсутність зрілих бібліотек, налагоджувачів, IDE тощо), розглядаються офіційною підтримкою Microsoft для F # як мови .NET першого класу. Буде цікаво дізнатися, чи F # допомагає досягти більшого рівня популярності для функціонального програмування.

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

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

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

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

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

Мені подобається кодування в ML та C для самих різних проектів. Що мені заважає використовувати ML у вбудованих проектах (більшість з яких мають обмеження в режимі реального часу та потребують перевірки) - це збирання сміття.

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

ІМХО, я думаю, що велика проблема OCaml полягає не в мові (це чудово), а в людях, які її розвивають, і, як наслідок, його ліцензії:

http://caml.inria.fr/ocaml/license.en.html

Вони використовують ліцензію Q Public для компілятора! Так, ліцензія ex-Trolltech використовується для бібліотек Qt! Забудьте отримати будь-який внесок з такою ліцензією.

Якщо ви перевіряли мовну перестрілку ( http://shootout.alioth.debian.org/ ) близько 7-8 років тому, OCaml трохи відставав від C та C ++ за швидкістю виконання. У той час, інші мови (як Haskell) отримали кращий компілятор (я думаю, через інший підхід спільноти), і тепер швидкість виконання OCaml не така велика, як у минулому.

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

Добре, якщо мова йде про гроші, як говорить @jrockway, ми побачимо, чи F # набуде популярності, як java або C #.

Як я вважаю, розробники не відчувають комфорту з функціональним способом виконання справ (це було з F # сесії в дні 2009 року, де близько 10 людей сказали, що знають функціональне програмування серед майже 100 осіб).

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

Ну, можливо, F # стає популярним.

Це не допомагає, що c-> ocaml є більшим розумовим переходом, ніж c-> lisp. Я кілька разів розглядав ocaml і завжди виявляв, що вартості / вигоди для мене просто не було, тому відклав його ще раз. Це не виглядало важко, а насправді виглядали дуже акуратно. Він намагався дізнатися зовсім інше значення для "!". Принаймні, Лісп виглядає настільки різним, що легко уникнути неправильного трактування його дрібних фрагментів як c.

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

Я думаю, що головна причина полягає в тому, що OCaml знає занадто мало розробників.

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

Мені дуже подобається O'caml ... Я реалізував купу речей, використовуючи його, компілятор, перекладачі, систему для спілкування з C ...

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