JSON не в состоянии заменить HTML как язык разметки? К слову, можно ли считать hamlet (такая библиотека для генерации html из кода на haskell использующая TH) eDSL'ем? Он пожалуй строгое надмножество html.

> а какого хрена система должна позволять менять код на неправильный?

Ну да, не должна. Она должна кинуть ошибку типов. Именно по-этому «исследовать живой образ, отслеживать эволюцию данных, менять код» в языках со статической типизацией принципиально невозможно - при попытке этим заняться тебе компилятор даст по башке. Вообще, будущее за внешними расширяемыми и настраиваемыми тайпчекерами. то есть в самом языке типов нет - но есть внешний чекер, который можно настроить под любую систему типов, от ее отсутствия, до систем с зависимыми типами. Естественно, должна быть возможность настраивать чекер отдельно для каждого модуля и даже для отдельных функций. вшивать же систему типов в язык намертво - это устаревший подход. Хотя оно понятно - диссеры про зигохистоморфические препроморфизмы в хаскиле может писать любой идиот, а вот заниматься реальной научной работой - это сложно, по-этому системы типов и не развиваются уже лет 50, все на старых лиспонаработках держится.

JSON не в состоянии заменить HTML как язык разметки?

Подкузьмил. Способен.

> приведи сам пример «гуманитарщины» в которой «не нужно».

12.00.00 Юридические науки (все)
23.00.03 Политическая культура и идеологии
24.00.01 Теория и история культуры
09.00.14 Философия религии и религиоведение
09.00.03 История философии
09.00.04 Эстетика
09.00.05 Этика
10.01.10 Журналистика
10.01.09 Фольклористика

и так далее

> Два наиболее известных DSL-я - это HTML и SQL.

что характерно - оба замечательно выглядят в лиспоподобном синтаксисе.

Вообще, будущее за внешними расширяемыми и настраиваемыми тайпчекерами. то есть в самом языке типов нет - но есть внешний чекер, который можно настроить под любую систему типов

Не пойдёт.

Есть такая вещь, как программирование на типах. Если у нас есть только чекеры - с этим будет печально.

по-этому системы типов и не развиваются уже лет 50, все на старых лиспонаработках держится.

Дурик, почитай про type families, например.

> что характерно - оба замечательно выглядят в

лиспоподобном синтаксисе.

HTML хреново, SQL тоже не бог весь как, но для SQL хотя бы выполняются важные вещи (типа защиты от sql-инжекций).

оба замечательно выглядят в лиспоподобном синтаксисе.

В лиспоподобном синтаксисе хреново выглядит даже Лисп.

> А что в задачах изменилось за 50 лет, что их сейчас по-другому надо решать?

Предметные области.

Если 50 лет это было узкое подмножество математических задач, то теперь это задачи науки (не только математики), бизнеса, инженерии, промышленности, телекома. Предметные области стали на порядки более богатыми и комплексными. Следовательно, для эффективного решения нужны новые подходы, методики, абстракции. Современные языки предоставляют их, Лисп и Фортран — нет.

> Почему это - нельзя???

Потому что HTML это не язык программирования, вообще. На нем не программируют. А то так ведь можно и картинки в формате SVG в DSL занести. Ещё раз - HTML это не DSL, ни в одном месте.

Чем он хуже вполне тьюринг-полного PostScript

Вы много писали на PostScript? Я довольно много. И общего между PostScript и HTML не наблюдаю вообще ничего.

> Анафорический when на clj:

Ты вообще в курсе, что такое «анафора»? Может, тебе надо было сперва почитать OnLisp, прежде чем городить чепуху?

В любом случае, мне с вами больше не о чем говорить.

Слив засчитан.

> Современные языки предоставляют их, Лисп и Фортран — нет.

Если вы про тот самый Лисп, который придумал Маккарти, то его же не уже давно. Даже ЛИСП 1.5 уже давно умер. А Common Lisp, Racet или даже Clojure это очень даже современные языки.

> Common Lisp в освоении проще C++, который используется достаточно массово.

Но почему тогда Lisp настолько не распространён и непопулярен? Общепринятое объяснение у лисперов такое: «потому что 99% населения — быдло, не могущее в Lisp». Но, если следовать тебе, то Lisp проще С++? Противоречие.

> Общепринятое объяснение у лисперов такое: «потому что 99% населения

— быдло, не могущее в Lisp».

Это ложь. Лисперы это так не объясняют.

Потому что HTML это не язык программирования, вообще. На нем не программируют.

Тю. Если формально подходить, то в аббревиатуре DSL вообще нет буквы «P». Есть специальный язык, заточенный под одну конкретную предметную область, специально сделанный для того, чтобы задачи из этой предметной области решать быстро и просто.

А то так ведь можно и картинки в формате SVG в DSL занести.

Ну да, естественно.

И общего между PostScript и HTML не наблюдаю вообще ничего.

Ну как, и тот, и другой используются, в основном, для вывода информации в структурированном, человеко-читабельном виде.

> Ну как, и тот, и другой используются, в основном, для вывода

информации в структурированном, человеко-читабельном виде.

Не, html задуман для семантической разметки данных (если забыть про это, то сейчас это больше дизайнерский инструмент), а PostScript для управления стэковой машиной.

> Есть такая вещь, как программирование на типах. Если у нас есть только чекеры - с этим будет печально.

Ничего печального, нету никаких задачах, в которых программирование на типах нельзя было бы заменить другими более удобными средствами.

Не пойдёт.

А других вариантов нет. Должно же быть хоть какое-то развитие? Попытки пришивать типы к языку намертво себя уже давным-давно изжили, так что soft typing - единственный выход.

почитай про type families, например.

Ну я и говорю - обсасывать в диссерах тривиальные идеи 50-летней давности может любой дурак.

Ничего печального, нету никаких задачах, в которых программирование на типах нельзя было бы заменить другими более удобными средствами.

Которые будут тем же программированием на типах, только в маске.

Должно же быть хоть какое-то развитие?

Угу. Оно есть.

Ну я и говорю - обсасывать в диссерах тривиальные идеи 50-летней давности может любой дурак.

Можно ссылочку на диссер 50-летней давности, где изложена подобная идея?

Не, html задуман для семантической разметки данных (если забыть про это, то сейчас это больше дизайнерский инструмент), а PostScript для управления стэковой машиной.

Ну да. То есть, ты доказал, что различия между ними есть. Это никак не отменяет того факта, что предназначения их сходны.

> Это никак не отменяет того факта, что предназначения их сходны.

Нет, у них принципиально разные назначения. Это вообще очень разные вещи.

> В лиспоподобном синтаксисе хреново выглядит даже Лисп.

В лиспоподобном синтаксисе все выглядит прекрасно. Для хаскеля верно обратное.

> Которые будут тем же программированием на типах, только в маске.

но для них не придется прибивать типа к языку.

Угу. Оно есть.

Пруфы?

Можно ссылочку на диссер 50-летней давности, где изложена подобная идея?

А там есть какая-то идея? 50 лет назад занимались делом, а не высасыванием тривиальных вещей из пальца. Это тот же параметрический полиморфизм, только в профиль (полиморфный тип, по определению, это просто функция из типа в тип, так что под формальное определение полиморфного типа равно попадают как «классические» полиморфные типы, так и «type families»), так что выразительности это не прибавляет ни на грош. Вот гораздо интереснее рассматривать определенные классы функций из значений в типы - но это слишком сложно для среднестатистического хаскиеба.

> Ты вообще в курсе, что такое «анафора»?

А ты вообще в курсе, что полноценные анафорические макросы в CL не возможны? Даже aif бедный, и тот в общелиспе работать не будет.

Есть такая вещь, как программирование на типах. Если у нас есть только чекеры - с этим будет печально.

Ничего печального, нету никаких задачах, в которых программирование на типах нельзя было бы заменить другими более удобными средствами.

пока давай возьмем еще не программирование на типах, а пример попроще

допустим, у нас есть типы

struct Vector { const float x; const float y; const float z; };
struct NormalizedVector: public Vector { /* у него всегда x*x+y*y+z*z=1.0 */ };

double norm(Vector v) { return sqrt(x*x+y*y+z*z); }
double norm(NormalizedVector v) { return 1 }

template<type V1, type V2> 
double angle(V1 a, V2 b) { return arccos(a*b/norm(a)/norm(b)); } 

как это делать с динамической типизацией? по-моему, только таская с собой флаг «а вектор-то нормализован», что займет лишние байты и такты (и еще возможно потребует перефасовки при закидывании на видеокарту)

так что применение типов не ограничивается чеком — исходя из знаний типа, можно че-то делать по-другому или вообще не делать; те keystrokes, которые мы потратили на декларацию типа, в случае допустим С потеряны почти безвозратно, а в случае С++ начинают немного уже работать на прогера :-)

но для них не придется прибивать типа к языку.

Пиши диссер.

Пруфы?

Type families. GADTs.

А там есть какая-то идея?

С тобой всё понятно.

под формальное определение полиморфного типа равно попадают как «классические» полиморфные типы, так и «type families»

А под формальное определение еды попадает искусственная баранина из водорослей. Но почему-то еда существует гораздо больше, чем 50 лет, а вот баранину до сих пор не научились производить иначе как убийством баранов.

Вот гораздо интереснее рассматривать определенные классы функций из значений в типы - но это слишком сложно для среднестатистического хаскиеба.

Не понял последнее слово, но dependent types, о которых ты говоришь, тоже относительно новое изобретение.

> как это делать с динамической типизацией?

Мне обычно сложно объяснить это другим лисперам, но мне действительно часто не хватает плюсовых шаблонов, местами они очень удобны. Только дело в том, что динамическая типизация здесь не очень-то и при чём. Надо генерировать соответствующие типы (как и в плюсах), а дальше всё разводится довольно тривиально с помощью CLOS. Но вот генерировать типы несколько муторно и лисповые макросы для этого плохо предназначены, ибо возникает проблема с именами. Хотя, может стоит подумать на эту тему чуть дольше.

> как это делать с динамической типизацией?

никаких проблем: [code] (cond [(vector? v) ...] [(normalized-vector? v) ...]) [/code]

что займет лишние байты и такты

occurence typing же! чекер выведет типы на основе кода и элиминирует лишние проверки.

а в случае С++ начинают немного уже работать на прогера :-)

Это когда, например?

Type families. GADTs.

Ну а новые идеи где?

С тобой всё понятно.

То есть ты не можешь подтвердить наличие хорть какой-то самой завалящей идеи? Оно и ясно.

Не понял последнее слово, но dependent types, о которых ты говоришь, тоже относительно новое изобретение.

Ну вот именно, dependent types новое изобретение, но вместо того, чтобы развивать dependent types, занимаются высасыванием из пальца и обжовыванием всякой тривиальщины. Нет, безусловно, перспективными направлениями тоже кто-то занимается, но это капля в море - 99% занято во всякой покрытой пылью времен бестолковщине типа GADT.

Так ведь ad-hoc полиморфизм полностью перекрывается CLOS. Или ты хочешь, чтобы полиморфные аргументы разрешались в компайлтайме? Тогда придется рассматривать подмножество CL, т.к. аргументы надо выводить, и значит в общем типизировать код. А в оригинальном CL типизировать не получится.

> А потом предметному специалисту понадобится какая-нибудь мелочь, в этот DSL не входящая...

кстати да, вот написали «свой лисп» при реализации R и таки loop (ввиду безнадежно засахаренного синтаксиса итерате даже не рассматриваем :) никто не портировал. И что бы это было удобно сказать не могу, одними *apply тоже скучно бывает писать.

> Или ты хочешь, чтобы полиморфные аргументы разрешались

в компайлтайме?

Нет. Но я хочу по разному обрабатывать список целых и список строк, только у меня нет такого типа (значимого для CLOS) - список строк. При чём, мне даже не нужны гарантии (что в этом списке могут быть только целые), мне нужно просто логически отличать список строк от списка целых (ну если очень упростить).

вместо того, чтобы развивать dependent types, занимаются высасыванием из пальца и обжовыванием всякой тривиальщины.

И правильно делают. Иначе вместо того, чтобы выводить типы, тайпчекер сам начнёт требовать доказательств. В данном случае worse is better.

> 12.00.00 Юридические науки (все)

экспертные системы

23.00.03 Политическая культура и идеологии

онтологии знаний и куча статистики из психологии, экономики и т.п. для познания электората

24.00.01 Теория и история культуры

как минимум анализ авторства текстов (к разностным методам отношение имеет спорное)

09.00.14 Философия религии и религиоведение

онтологии... да библию и ту в специально разработанной программе читают :)

09.00.03 История философии

онтологии

09.00.04 Эстетика

никуда без квалиметрии

09.00.05 Этика

опять же квалиметрия

10.01.10 Журналистика

ну тут и антиплагиат и куча анализаторов-классификаторов новостных лент, нечеткий поиск в архивах статей... да просто генерация текстов на заданную тему (явно возрастает качество новостей)

10.01.09 Фольклористика

угу вручную значит корпус текстов лопатить? можно, но не нужно

Откуда наивное представление что данные области продвигаются исключительно силой мысли и не нуждаются в ИТ?

> Современные языки

приведите список, если не трудно? :)

А разностные сетки, как же разностные сетки?

я - den73

> SQL: хозяин, внезапно field1 оказалось блобом; че делать будем? Такое бывает и без всяких типов, когда делаешь конкатенацию двух текстовых полей. Через миллион записей может встретиться переполнение размера строки и привет.

Но в целом, я согласен (и уже пару раз писал о том), что SQL - это пример статически типизированного языка с динамической реализацией. SQL как раз служит контрпримером для тех, кто видит статическую типизацию и динамическую реализацию как взаимно противоречивые требования.

В отличие от лиспа, SQL не стал изгоем, очень активно развивается, на нём пишут много полезных программ, и, думаю, входит в пятёрку наиболее популярных в мире языков.

я - den73

> Интерпретатор C-подобного языка пишется максимум за неделю.

И где сейчас этот интерпретатор?

> Иначе вместо того, чтобы выводить типы

Полный вывод типов вообще исключительно вреден. Это не говоря о том, что системы типов, позволяющие вывод, очень примитивны, невыразительны и толку от их использования никакого нет.

тайпчекер сам начнёт требовать доказательств.

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

>>используй скобочки, Люк.
Да как же можно, это же уебищные скобочки!! Или фигурные скобочки менее уебищны и они не в счет?

И где сейчас этот интерпретатор?

Там где и полагается ему быть — в помойке её сдал какой-то отрицательный студент как свою работу. Для себя я C-подобных языков не пишу.

Да как же можно, это же уебищные скобочки!! Или фигурные скобочки менее уебищны и они не в счет?

Конечно. Они гораздо краше, разве не очевидно? А если серьёзно, то когда говорят про уёбищные скобочки лиспа, имеют в виду пару круглых скобок на каждую апликацию (коих в функциональном языке чуть более чем). В haskell вместо скобочек используют уёбищный оператор апликации ($). А те скобочки о которых вы говорите, это уёбищные скобочки C. Чем они не нравятся людям, я не знаю. Спросите у питонистов.

я den73

> Type families. GADTs. Я не знаю, что это, но это наверняка не нужно.

Примеры полезных вещей из МП:

дан исходный текст проекта на С (CL, Java, Haskell).

pureP(function) - истина, если названная ф-я является чистой ф-ей от своих аргументов и возвращает рез-т на стеке. nonDetermenisticCalls(function) - список точек вызова нечистых ф-й, вызываемых из данной. noMallocP(f) - истина, если ф-я не выделяет памяти finiteMallocP(f) ф-я выделяет конечное кол-во памяти (возвращет оценку сверху, возможно, в виде формулы) terminatesP(f) - ф-я заведомо не зацикливается callsWho(f) - кого вызывает whoCalls(f) - кто вызывает globalVariablesUsed(f) - список используемых глобальных переменных moveToFile(f,destination) - переместить в другой файл проекта с сохранением смысла проекта splitAt(function,point) - разбить ф-ю на две в указанной точке исходного текста с генерацией кода для передачи контекста catchParameters(function,destination) - определить тип, содержащий все входные и выходные параметры ф-ии, завести переменную destination этого типа и вставить код, к-рый копирует параметры при каждом вызове в эту переменную. traceIf(function,condition) трассировка на входе и выходе при выполнении условия isOnStack(function) - вставить код, который возвращает истину, если данная функция находится где-то на стеке. generalizeFunctions(f1,f2,dest) - объединить функции f1 и f2 и, если, они ранее были получены с помощью copy-paste, слить общие части. simplifyFunction(f1,targets) - улучшить f1 в смысле критерия targets (например, число строк кода, отсутствие циклов и т.п.) с сохранением смысла optimizeQuery(f,point). В проект встроен in-process реляционный сервер. Имеется запрос к нему. Вызвать оптимизатор, который сгенерирует оптимальный код выполнения запроса в этом сервере.

Вот если бы появился язык, в котором МП хорошо поддерживается и в котором _уже_ реализована хотя бы половина данных примитивов, я бы подумал о том, что бы на него перейти. Я догадываюсь, что ближе всего к этой точке находится Java, но пока не готов ей заниматься ввиду её известных недостатков.

В идеале, этот язык должен иметь динамическую реализацию, т.е., модификации должны производиться во время исполнения программы, без её остановки.

Является ли Хаскель движением в эту сторону? Насколько я понимаю, нет. А раз нет, то я не вижу, зачем мне нужен Хаскель. Я ожидаю от компьютера решения тех задач, которые сейчас решаю я. Что может Хаскель? Он может выводить типы. Но мне не нужны эти типы, я обхожусь простыми средствами: палкой и верёвкой. Полезное дело делает SQL - он оптимизирует запросы. Я не вижу, как Хаскель мог бы повысить производительность моего труда, по сравнению с лиспом. Отказ от истинно динамической архитектуры, каковой является лисп, должен иметь серьёзные причины. В случае Хаскеля я таких причин не вижу.

и чем же это тебе $ не угодило? Да это, может быть, лучшее, что есть в хаскеле.

>> Иначе вместо того, чтобы выводить типы

Полный вывод типов вообще исключительно вреден.

Yeah, well, that's just, like, your opinion, man.

тайпчекер сам начнёт требовать доказательств.

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

Прогрессируйте в других языках. А мой самый практичный из академических (и наоборот) попрошу не трогать.

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

Agda и Coq — на вершине лямбда-куба, куда двигаться дальше — пока не придумали.

Всё не так просто. Что считать синтаксисом Хаскеля? Нечто определённое в стандарте как haskell2010? Так им никто же не пользуется! Многочисленные расширения расширяют и синтаксис. Причём так расширяют что при использование квазицитирования ломается list comprehensive, а внутри квазицитирования не работают списки (последнее впрочем может относиться только к hamlet'у). Добавим ко всему прочему синтаксические сахара… С другой стороны возможность легко и непренуждённо определять свои операторы в плане создания языков-подмножеств хороша. Это если не брать во внимание, что любая монада по сути и есть маленький eDSL.

Уфф… Какая разница 100500 скобочек или 50250 $ (или .)? Проблема же не в скобочках, а в их количестве. Но $ не надо закрывать, это да…

Разница в том, что большинство применений в Хаскеле является пробельными символами.

> при использование квазицитирования ломается list comprehensive

Интересно, УМВР. Ссылку на пример поломки можно?

а внутри квазицитирования

Работает свой парсер, никакого отношения к Хаскелю не имеющий.