Обсуждение

>несмотря на все навороты с типами данных в том же Haskell, его и ему подобные языки почему-то не используются рутинно для представления данных и схем данных -- и это не случайно Это у вас перекос. Кому надо, те используют.

Например, недавно написал пост на тему использования нововведений в систему типов для описания структур БД.

Экзотика всегда есть. Я с базами данных познакомился ещё с деревянными, а потом CODASYL, и только потом реляционными, и затем уже объектными (мимо которых серьёзный софт всегда лезет в нижележащие слои "напрямки"), а сейчас и NoSQL с любопытством наблюдаю. И насмотрелся поэтому на самые разные способы и языки описания моделей данных -- вплоть до макроассемблера, Forth и прочих фортранов с его common blocks. Конечно, и на Haskell можно исхитриться, и даже кто-то этим занимается.

Ну, пост на тему использования нововведений -- это не массовая практика программирования. Я только вчера смотрел индексы популярности языков программирования. О Хаскеле очень много говорят, но мало почему-то программируют. Как я понимаю, justy_tylor получил большой опыт работы с инженерными данными, и теперь понимает настоящие тамошние проблемы (они меньше всего лежат в области описания структур БД, а больше лежат в описании структур реального производственного мира в терминах удобных для этого структур данных). И хочет предложить решение, менее экзотическое и тем самым более практическое, чем Haskell. Хотя я вполне понимаю, что сами вы считаете Haskell очень практическим языком. Но я не отказываю justy_tylor в возможности успеха при создании нового языка, с успехом не меньше чем у Haskell. Все эти Python и Lua появились в общем-то из похожих проектов (хотя любую программу, которую на них можно написать, можно написать и на Haskell -- вопрос в том, нужно ли, а не можно ли).

h-t-t-p-s://github.com/languages/Haskell - 17 по счёту. Совсем не мало программируют. h-t-t-p://sogrady-media.redmonk.com/sogrady/files/2012/09/language-ranking-0912.png - ровно на оси вопросов и количества проектов. Про Matlab и R больше говорят. То, что делает justy_tylor, я бы сделал EDSL на Хаскеле. Зачем ещё один язык? И типы хорошие, и производительность неплохая (уж параллельная так вообще великолепна), и код генерировать удобно. Нововведения обязательно попадут в руки творцов и будут использованы. Сейчас используются фантомные типы, что не так удобно. В заключение укажу на ваш промах в ваших рассуждениях - вы рассуждаете о массовой практике программирования вообще, когда я указываю на практику программирования на Хаскеле. Так же, как приёмы программирования на C# не будут массовой практикой программирования на Хаскеле.

Когда в моде был конфликт имён между языком go от google и другим с очень похожим названием, мне захотелось посмотреть, что же это за другой язык (на гуглёвский я уже посмотрел). В общем, слова "онтологически-ориентированное программирование" они любят. И, кстати, книжка этих же авторов про микро-пролог выходила на русском ещё, кажется, в конце 80-х, когда пролог был моден. Есть ли в этом всём смысл -- честно не знаю. :-)

... Легенды - ложь, легенды врут, легенды для глупцов ...

Да, это именно онтологически-ориентированное программирование в GO!, но justy_tylor не любит semantic web онтологии (и я его в этом поддерживаю). Кстати, половина разработчиков ISO 15926 утверждают, что OWL -- это отход на 20 лет назад с точки зрения конструирования нормального онтологического представления данных. Насколько я понимаю, фишка justy_tylor в том, что он хочет брать за основу выражения онтологии прототипную теорию понятий, хотя и в довольно раннем изводе (Lakoff). В этой теории понятий осуществляется контроль для привязки к базовому уровню восприятия (манипулирование соразмерными человеку объектами в пространстве "внутри головы") человека, а не просто порождаются эффективные математически произвольные конструкты языка. Ну, и он хочет поработать с проблемой класса-экземпляра (во всех языках класс и экземпляр класса отличаются в поведении с точки зрения онтологического статуса, в прототипной теории поняний всё с этим по-другому), а это сводится к работе с "временами" (компиляции, макроподстановки, оценивания, исполнения и т.д.). Ну, и все эти "прологи" после этого становятся просто библиотеками каких-то методов вычисления, макроподстановки, оценивания, исполнения, легко подшиваемыми сбоку.

Мне кажется, что дрейф разговора в сторону обсуждения текущей популярности и массовой практики программирования в данной дискуссии неверен. Из этого сущего никак не воспоследует должное. Правильно обсуждать суть дела: 1. поможет ли предлагаемое justy_tylor использование в языке программирования выражение семантики данных и вычислений прежде всего в базовом уровне восприятия человека (тут есть теория Lakoff -- базовый уровень определяется большим числом экспериментов) сделать язык более легко понимаемым простыми людьми. Если грубо, то в голове человека предполагается наличие хардвера (неважно, "микропрограммированного" в ходе его детства, или настоящего мозго-эволюционного), и предлагается сделать язык, удобный для работы на этом хардвере. Это обеспечит ту самую популярность, и хитрость только в том, чтобы не потерять теоретической мощности выражения мира на этом языке. 2. Потом этот язык можно компилировать в какой-то другой язык, удобный для исполнения на компьютере. Это может быть и Хаскель, нет вопросов. Но у justy_tylor гипотеза, что сделать (1) нельзя, используя EDSL на Haskell (даже если учесть нововведения). Поэтому он пытается думать о разных других механизмах разгребания уровня онтологического-на-прототипах программирования до уровня императивного программирования современных микропроцессоров. И предлагает свои таинственные макросы-которые-не-макросы. От себя замечу, что ход мыслей justy_tylor мне симпатичен. Ибо все эти Haskell и OWL мне кажутся одинаково далёкими от удобства вычисления на человеческом хардвере, и одинаково неудобными способами выражения окружающего мира. Если justy_tylor удастся придумать что-то, что теоретически бы согласовывалось с разными теориями понятий, подтверждаемыми экспериментами, то был бы шанс резко продвинуться в области онтологических языков. А Haskell и OWL можно было бы отнести к математическим языкам, ни разу онтологическими не являющимися. Всякие языки нужны, всякие языки важны: одни нужны людям, другие машинам...

Согласен с thesz Haskell, для представления данных и схем-данных используют, но сие не мейнстримовско просто. По понятным причинам, которые даже лень вспоминать. Вообще говоря, любой (многие) язык ориентированный на EDSL'и и/или мета-программирование можно использовать для представления данных/схем-данных и программирования с оными. Собсно для этого (но только в более широком контексте) они и создавались. Они может не шибко практичные будут по разным причинам, но годные вполне. Понятно, однако, что для этого нужен определенный уровень развития, причем даже скорее не как программиста, а как ученого. Т.е. в кругозор кроме программирования должна и даталогическая проблематика в том или ином виде входить. А ежели программер типа кодер, то чего тут ожидать-то.

Это был как раз мой тезис: любой тьюринг-полный язык можно использовать для представления данных/схем данных и программирования с оными. Даже машинные коды, даже бейсик. Не шибко практично, но годно. Но насчёт уровня развития -- тут развилка в рассуждении. Даталогическая проблематика может быть сформулирована в терминах математических (и тогда только тяжёлый-тяжёлый тренинг соответствующего раздела математики поможет), или в терминах какой-то подтверждённой экспериментами на обычных людях (это важно: не математиках, а обычных людях) теории понятий, а в математические теории только оттранслирована (отмэппирована). Как я понимаю, justy_tylor хочет пройти по второй "человеческо-понятийно" тропинке в развилке и затем оттранслироваться в математику (что труднее, это две разных задачи -- тут трудности первопроходца), а thesz готов идти по первой математической половинке (которую уже прошли хаскеловерные), но у него будут неминуемые трудности вести за собой толпы людей (тут нет трудности первопроходства, но есть огромные дидактические трудности со всеми остальными). Ежели взять общие трудозатраты людского времени, то путь thesz менее оптимальный: даже если justy_tylor потратит на свои исследования десять человеко-лет, эти затраты легко окупятся на снижении образовательного ценза на год для первых же десяти пользователей его языка.

Дрейф начали вы и большое спасибо за предложение его прекратить. >Ибо все эти Haskell и OWL мне кажутся одинаково далёкими от удобства вычисления на человеческом хардвере, и одинаково неудобными способами выражения окружающего мира. В любом случае это будет конструктивная логика. Никуда от неё не деться. Является ли OWL реализацией конструктивной логики, мне неизвестно. Я даже не знаю, что это такое. Haskell является реализацией конструктивной логики. Agda2 ещё ближе (это реализация теории типов Пера Мартина-Лёфа). Поэтому практически любая попытка выразить что-то, компилируемое в железо, будет содержать в себе три четверти реализации Haskell и половину реализации Agda2.

>Это был как раз мой тезис: любой тьюринг-полный язык можно использовать для представления данных/схем данных и программирования с оными. Вы не удосужились прочитать мой пост, и зря. Пост был о том, что представление схем данных и программирование с оными производится на метауровне. На типах задаются аксиомы и теоремы о структурах данных, которые используются при доказательстве других теорем (сиречь при программировании). Вот это уже не возможно выразить в любом Тьюринг-полном ЯП, даже на ассемблере. И, кстати, отвечая на ваш другой комментарий: Пролог (программирование в ограничениях) давно уже существует в виде библиотеки на Хаскеле. Вообще, многое из языковых конструктов обычных ЯП в Хаскеле выражается в виде библиотек.

Хаскель, описание ленивых вычислений в функциональной парадигме, это очень мелкие подмножества передаваемых данных. Никто не будет заниматься неестественной трансляцией Хаскеля, когда надо между системами (созданными с использованием разных языков программирования) передать данные про трубы, насосы и жизненный цикл нефтяной платформы. Проще говоря, аналоги ADT требуются сразу и для всего, а тайпклассы и (любые) вычисления уже тянут на EDSL.

Как раз у justy_tylor, как мне показалось, есть претензия к разнице способов манипулирования типами и данными этих типов -- устранить эту разницу у него в дизайн-целях. Отмоделировать (эмулировать) представление этого в ЧЯП (человечьем ЯП) у него в задачах. А вот какая там архитектура (тьюринговская, конструктивной логики, теории категорий, аналоговых вычислений, квантовых вычислений) МЯП (математического или машинного языка -- я их сознательно называю одинаково) это уже будет обсуждаться. И чем можно/нельзя пожертвовать в дефиниции ЧЯП для того, чтобы это село на какую-то разумную вычислимость. То, что Пролог и прочие логические выводы с оптимизацией должны быть библиотеками, у justy_tylor в дизайн-целях есть. Кстати, один из моих постов с отсылками к теориям понятий (я очень надеюсь, что этот ЧЯП будет у justy_tylor на основе плюралистической теории понятий, а не только прототипной) -- http://ailev.livejournal.com/1019876.html, там четыре нумерованных пункта (из которых переход к логической парадигме как раз первый, и в этом же первом источнике как раз проясняется, отчего у justy_tylor такое внимание к насосам и выражению процедур из замены при поломке, а не внимание к абстрактным выразимостям максимального математического разнообразия объектов, как это принято в работах не онтологов, а математиков). Математики-алгебраисты изобретают свои формальные структуры безотносительно окружающей нас реальности, а онтологи пользуются разными представлениями (в том числе и математическими) для попыток выразить именно окружающую реальность. Программисты со своими компиляторами по факту разделились: язычники программирования (computer science) поддерживают математический взгляд на мир, а язычники информационных систем (совсем другая вузовская специальность) поддерживают онтологический взгляд. Как только язычники программирования задумаются о классе языков для поддержки DDD непосредственно, а не через предварительный перевод в математическую абстрацию (т.е. поддержку представления насоса каким-нибудь программным типом, подходящим для представления функционального объекта из жизни, а не программным типом для монады или чего-то аналогичного из учебника математики), то будет прорыв. justy_tylor хочет этого прорыва сейчас, я его поддерживаю в этом начинании.

Гы, эта линия рассуждений (про "Любая достаточно сложная платформа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины функционального языка") вот тут: http://ailev.livejournal.com/1023299.html

Это был как раз мой тезис: любой тьюринг-полный язык можно использовать для представления данных/схем данных и программирования с оными. Даже машинные коды, даже бейсик. Не шибко практично, но годно. Я под годно имел в виду, что это экономит трудо затраты. Т.е. в Хаскелле можно относительно легко запрограммировать кодогенерацию, управляюмую этими схемами. Что даст выигрыш в сравнении с ручным написанием и переписыванием кода под изменившиеся схемы. Не каждый программер сможет, но есть такие которые могут. На бейсике тоже конечно можно так сделать, но трудозатраты не окупаются. По сути мы тут должны сделать внешний DSL с помощью бейсика, для чего он кагбэ не очень приспособлен. А Хаскел - язык который позволяет делать как интернал так и экстернал ДСЛи достаточно гибко и удобно.

Ежели взять общие трудозатраты людского времени, то путь thesz менее оптимальный: даже если justy_tylor потратит на свои исследования десять человеко-лет, эти затраты легко окупятся на снижении образовательного ценза на год для первых же десяти пользователей его языка. Просто есть уже реальные проекты - т.е. языки типа Хаскела, Скала, Меркури, Лисп (например Racket), Руби, F-Logic + возможно еще какие-то по вкусу, которые кагбэ не для всех, но задачу реализуют. Можно пытаться упростить порог для них, и задача достаточно очевидная - после попыток заюзать вышеупомнятое в обычном проекте. Но совершенно неочевидно насколько и как она решаема в плане снижения входного барьера на уровне математичности мышления.

Я не понимаю, почему надо заниматься неестественной трансляцией Хаскеля при передаче данных про трубы. Что такое ADT в данном контексте? Надеюсь, что вы понимаете, что вы собираетесь сшивать языки с разными семантиками и что вам потребуется трансляция (желательно, доказуемо корректная) между семантиками.

Я очень надеюсь, что и вы, и justy_tylor понимаете, что уже сейчас можно пользоваться тем, что вы оба только проектируете. Эта штука называется зависимые типы данных и доступна в Agda2, например. Ибо то, что вы описываете, свободно выражается в этой парадигме (при этом логическое программирование встроено в инструменты поддержки Agda2).