LINUX.ORG.RU

[haskell] есть ли что-то типа reflection? (недемократизм языка?)

 


0

0

Обычная фраза: deriving (Read, Show, Eq, Ord)

Компилятор умеет выводить инстансы этих typeclass-ов. А что делать, если хочется их выводить чуть-чуть по-другому или добавить еще один, который автоматически бы выводился? (Для этого, возможно, подошло что-то похожее на reflection, патчить компилятор не предлагайте)

__________________________________________________

Недемократизм языка в моем понимании -- это

1. Частичная реализация некой фичи и одновременно отстутствие инструмента для расширения реализации этой фичи. Например в яве оператор + для сложения целых, вещественных, строк и все: комплексные, кватернионы, вектора, матрицы... складывай уже через add.

2. Невозможность смены конкретной реализации фичи (зачастую связано с п.1). Например, невозможность создать в рамках с++ свой virtual dispatch (для того, что сделать множественный virtual dispatch, т.е. п.1). В принципе, п.2 до некоторой степени неизбежен, так как иногда намного проще сделать фичу, чем API для написания фич).

__________________________________________________

Более глобальный вопрос -- а насколько хаскель демократичен? (для обеспечения демократизма разрешается использовать ключи компилятора, template haskell, ...)

Ответ на: комментарий от anonymous

>ну есть такое понятие как readability - как его формализовать?

условная плотность вероятности понимания очередным программистом написанного, при симуляции модели по методу Монте-Карло N случайно взятых программистов. Условия = те критерии качества, про которые вы тут распинаетесь.

anonymous
()
Ответ на: комментарий от anonymous

>условная плотность вероятности понимания очередным программистом написанного, при симуляции модели по методу Монте-Карло N случайно взятых программистов. Условия = те критерии качества, про которые вы тут распинаетесь.

Это не есть формальным определением

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

ну да, просто изложил сам ход мыслей. Нечто вроде формулы Байеса для фильтрации спама, только тут у нас плотность вероятности функции "понимания фичи языка".

anonymous
()
Ответ на: комментарий от anonymous

> ну да, просто изложил сам ход мыслей. Нечто вроде формулы Байеса для фильтрации спама, только тут у нас плотность вероятности функции "понимания фичи языка".

эксперименты возможно и нужны, но шибко трудозатратны

мне достаточно того, что программисты скажут "да, этот язык более читаемый, вон прочите ту статью", а грамотные еще и перечислят чем он более читабельный (и если быть совсем циничным, эксперименты, показывающие обратное, не нужны :-)

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от anonymous

при симуляции модели по методу Монте-Карло N

вот есть статейка Джоэля про Evidence Based Scheduling http://www.joelonsoftware.com/items/2007/10/26.html — применение имитмоделирования по Монте-Карло для оценки вероятности успешного завершения проекта: контроля сроков, ресурсов, полноты фич (какие фичи надо выкинуть, чтобы вписаться в график).

Берём оценки исполнителей-программистов «сколько займёт реализация фичи». Делим план на факт, получаем «скорость исполнителя». Потом прогоняем на реальном проекте оценки времени, вычисляем возможные факт. времена (план/случайную «скорость» из выборки). Получаем имитмоделированием возможное время завершения проекта и % вероятности успешной реализации фич.

Можно немного придраться к модели: на мой взгляд, скорости-оценки не абсолютно равновероятные, скорее это условные вероятности из формулы вроде Байеса: вероятность точнее оценить трудоёмкость задачи больше, если до этого такие задачи уже решались. Скорее, это вопрос декомпозиции на подзадачи/исполнителей: зависимые/независимые, условно вероятные/равновероятные. Но предположим, что модель всё-таки достаточно точная.

Какое отношение это имеет к «критериям качества языка», метапрограммированию?

Пока что в модели Джоэля язык программирования мог быть любой. Но проведём эксперимент: пусть часть программистов-исполнителей делает проект на языке L, а другая часть берёт более богатый язык, «платформу Х». «Платформа Х» — это метаязык, метасистема — язык, описывающий сам себя, среда-система, написанная на себе самой. Если статистически можно доказать по результатам эксперимента, что система Х позволяет выдавать более точные оценки времени выполнения, видно, что применение такой платформы-метасистемы имеет смысл. Осталось только найти Х.

Поищем его конструктивно, индуктивно по такому же принципу. Система Х — метаязык сверхвысокого уровня, на уровне N которого описывается сам метаязык; уровень N описан с помощью более низкоуровнего языка уровня (N-1); ур. (N-1) описан с помощью уровня (N-2) и т.д. На уровне 1 сидит базовый Си, ассемблер, или байткод LLVM/.NET/Java.

Вопросы:

0. А есть ли смысл вообще в метаязыке Х по сравнению с каким-то одним обычным языком Х.

1. Какой именно метаязык лучше для уровня N?

2. Какие подуровни лучше для конкретного Х, как лучше провести декомпозицию.

3. ???? Как провести вычислительный эксперимент, пытаясь ответить на вопросы 0-1-2 статистически, эмпирически? Сколько и каких опытов надо провести, чтобы измерения 0-2 стали статистически значимыми? Что оценивает эксперимент -- умение наугад выбранных программистов решать задачу на конкретном языке, умение строить метасистему на конкретных базовых языках, конкретный компилятор или некие мифические «качества языка»? Допустим, мы можем доказать-найти корреляцию между сначала метасистемой Х и языкам L1,L2..Lk, затем между Lx и какими-то «качествами языка»-- или между «качествами» и удачно построенной метасистемой Х. Каковы границы применимости такой метасистемы на других проектах и задачах? Можно ли статистически/эвристически найти *самое* оптимальное, глобально, а не только локально решение или хотя бы определить направление его поиска?

4. PROFIT! Нашли волшебную платформу Х, языки, на которых её можно построить, «качества языка», используя которые можно всё это построить.

Ну то есть, предлагается провести эксперимент вроде shootout benchmark game по ссылке выше и кластеризировать/проанализировать результаты. И доказать эмпирически, статистически: «такой-то язык лучше в таких-то задачах благодаря такой-то семантике, таким-то базовым *качествам языка*»

anonymous
()
Ответ на: комментарий от www_linux_org_ru

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

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

>шибко трудозатратны

да ну. Берём какой-то маааленький проектик из 2-3 подзадач, просим оценить время на реализацию, вычисляем факт затраты на реализацию. Запускаем легион анонимусов ^W^W army of programmers чтобы порешали, и с 1000-ной попытки собираем более-менее убедительную репрезентативную выборку. Ищем корреляции. Профит! :)

anonymous
()
Ответ на: комментарий от anonymous

> Система Х -- метаязык сверхвысокого уровня, на уровне N которого описывается сам метаязык; уровень N описан с помощью более низкоуровнего языка уровня (N-1); ур. (N-1) описан с помощью уровня (N-2) и т.д. На уровне 1 сидит базовый Си, ассемблер, или байткод LLVM/.NET/Java.

не понял... уровень 2 описан с помощью ассемблера или даже си?

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от anonymous

> Запускаем легион анонимусов ^W^W army of programmers чтобы порешали, и с 1000-ной попытки собираем более-менее убедительную репрезентативную выборку. Ищем корреляции. Профит! :)

знаешь ли, не все имеют карманную армию в 3000 программистов

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

ага. Например, берём COLA/COKE или Church/State. Функциональный язык описан с помощью императивного ядра. Императивное ядро -- базовые примитивы языка недолисп, который транслируется в Си, и в который транслируется "лисп".
Похожие идеи есть и в MBase, на лиспе ядро 1 уровня, 1 уровень компилируется в .NET VM (0 уровень, через рефлексию реализуется ядро языка), второй уровень компилируется в первый, третий во второй и т.п.
Или, язык HN с C++ в качестве HN0, язык вроде Хаскелля HN (на самом деле, комбинаторная логика).

То есть, вопрос про оптимальные языки можно ставить как
1. оптимальность метаязыка "сверхвысокого уровня"
2. оптимальность разбиения на подуровни, что лучше, 2 таких уровня или 3 таких.
3. оптимальность выбора языка для конкретного подуровня.

Например, возьмём Сhurch/State. То, что Church (функциональный) описан на State(императивном) -- обеспечивает интероперабельность функ/императивной части. То, что State транслируется и линкуется с Си, обеспечивает прозрачность интеграции с Си.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

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

мне кажется, «читабельность» — это подвид более общей фичи «понятность» языка. Если каждую фичу можно понять или применить неправильно, её поймут неправильно, вопрос только в вероятности такого события. Поэтому разумнее устранить неоднозначности заранее, чтобы можно было понять однозначно. Можно считать, что фича «более понятна», если вероятность истолковать её неправильно меньше.

Например, возьмём С++. Константность, константные ссылки, транзитивность константности. Есть вероятность, что т.к. транзитивность константности не отслеживается, не обеспечивается, «реализация константности в С++ непонятна».

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

Почему не сделать методы по умолчанию виртуальными, а в особых случаях final sealed — невиртуальными? Почему _аннотация_ virtual, которую разумный компилятор с разумной системой типов должен сам вычислить и применить, чисто оптимизация для компилятора по-сути, у нас принимает такой важный *нечитаемый* смысл, что её везде надо писать руками, следить, не ошибиться бы? Вывод «виртуальные методы в С++ не понятны»

Почему в C/C++ нет средств отследить aliasing указателей автоматически? Требуется, в лучшем случае, расставлять компиляторно-зависимые костыли руками. Почему такие аннотации компилятор не может расставить сам. Вывод «семантика указателей в части aliasing problem в C/C++ непонятна».

Я не говорю, что фича непонятна абсолютно. Не, с некоторой вероятностью понимания этих костылей её можно считать условно-вероятностно понятной, по нечёткой логике. Но если фича не однозначно понятна со 100% вероятностью, это хорошо закопанные грабли.

Возьми, например, текст с терминами — он условно-понятен. Или на лунном с иероглифами — он сразу понятен, наглядно — если ты знаешь иероглиф или основные штрихи, идиомы.

Вот фантастически наглядно описана разница между императивным и функциональным стилем мышления — Хаскель это такой «ГЕПТАПОД А» http://dustyattic.ru/literature/ted_chan/story_of_your_life

Так что — ПОНИМАЙ http://dustyattic.ru/literature/ted_chan/grip

anonymous
()
Ответ на: комментарий от anonymous

> мне кажется, "читабельность" -- это подвид более общей фичи "понятность" языка.

я бы (вопреки одному своему посту в этом треде) почти до конца бы их разделил:

читабельность синтаксиса,

понятность семантики.

> Если каждую фичу можно понять или применить неправильно, её поймут неправильно, вопрос только в вероятности такого события. Поэтому разумнее устранить неоднозначности заранее, чтобы можно было понять однозначно. Можно считать, что фича "более понятна", если вероятность истолковать её неправильно меньше.

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

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

но должна быть возможность, дописав атрибут, сказать: "а вот здесь компилятор обязан развиртуализовать функцию", и если он это не может, должна быть ошибка компиляции.

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от anonymous

> Какой физический смысл у невиртуального деструктора?

очевидный для знающего идеологию с++

однако я бы предпочел иметь ключевое слово non_virtual, которое нужно ставить перед невиртуальной функцией и деструктором, и запретить слово virtual

> Почему не сделать методы по умолчанию виртуальными, а в особых случаях final sealed -- невиртуальными? Почему _аннотация_ virtual, которую разумный компилятор с разумной системой типов должен сам вычислить и применить, чисто оптимизация для компилятора по-сути, у нас принимает такой важный *нечитаемый* смысл, что её везде надо писать руками, следить, не ошибиться бы? Вывод "виртуальные методы в С++ не понятны"

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

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

______________________________________

я потом видимо еще отвечу

www_linux_org_ru ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.