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

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

> С точки зрения пользователя, "качество языка" -- это способность программиста выдавать быстро работающие решения.

имхо отсюда некуда копать

> С точки зрения манагера, решения не любые, а понятные другими программистами, поддерживаемые, зрелые, с минимум ненужных рисков.

вот это уже лучше. но не полностью.

1. понятные другими программистами = читабельность

2. поддерживаемые = дело наживное либо хорошие средства метапрограммирования, чтобы сеньор девелоперы могли поддерживать, не патча компилятор

3. зрелые = вредная фигня (т.к. нам надо поддерживать новые технологии, а не плестись в хвосте прогресса) либо опять хорошие средства метапрограммирования, чтобы сеньор девелоперы могли шейпить язык (запрещая опасное и добавляя полезное), не патча компилятор

4. с минимум ненужных рисков.

тут должны быть описания рисков

сразу приведу несколько:

4.1 сильное изменение требований и/или жестокий рефакторинг программы

цель: минимизировать текстуальные изменения языка

средство: так называемая "гибкость" языка

пример: исключения более гибкие, чем возврат Алг. Типа Данных Variant<UsualResult,CanNotDoBecase,ShitHappens>

4.2 изменения технологий, в т.ч. самого языки

4.х <заполнить>

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

== поддерживаемый

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

отсюда можно копать, моя любимая тема -- абстракции :-)

> С точки зрения компьютера :)) -- это язык, достаточно эффективно ложащийся на аппаратные ресурсы.

хе-хе, компьютер тут стоит на последнем месте, а в английской википедии одно время было что-то типа "ЯП -- это способ объяснить компьютеру, ..."

на самом деле, конечно это тоже важно.

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

s/минимизировать текстуальные изменения языка/минимизировать текстуальные изменения исходного кода программы на этом языке/

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

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

>1. понятные другими программистами = читабельность

>2. поддерживаемые = дело наживное либо хорошие средства метапрограммирования, чтобы сеньор девелоперы могли поддерживать, не патча компилятор


хорошо читаемый write only код на метабрейнфаке прокатит?

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

>3. зрелые = вредная фигня.. чтобы сеньор девелоперы могли шейпить язык (запрещая опасное и добавляя полезное), не патча компилятор


сидит молодой акын, играет Iron Maiden. Ищет. Сидит старый акын, адынпалкадваструна, дзынь раз в минуту. Нашёл.

а зачем им вообще что-то "шейпить", если средства зрелые? Если пубертатные, тогда ладно ещё.

вот сижу я сейчас под виндой, поставил mingw, llvm, собрал ldc, сижу tango патчу-собираю. Собранный под mingw-ом llvm D compiler упорно считает, что винда у меня posix. В SVN tango уже вроде пофиксили, так я старый стабильный релиз нашел. А Hans Boehm gc в libgc.a мингвом тоже с приключениями собирается -- или без нитей, или руками Makefile.direct править. А потом хочу ещё с исключениями потрахаться, SEH такой занятный под виндой.

Спрашивается, нафига бы мне чего-то там патчить, компилять, пробовать, если бы LDC официально держал "из коробки" позикс под виндовым gcc? Но получился жуткий зоопарк, на который надо пробовать, патчить, шейпить вот чего-то там.

>4. с минимум ненужных рисков.

>тут должны быть описания рисков


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

В модели Evidence Based Scheduling Джоэля риск -- это bad estimator, исполнитель, оценки которого с большой дисперсией, с большими разбросами.

>пример: исключения более гибкие, чем возврат Алг. Типа Данных


ну лисповые условия и рестарты тут рулят и педалят. Или смоллтоковый doesNotUnderstand.
Изменения требований вообще решаться по-другому должны -- надо долго думать и потом быстро грамотно задизайнить, а не заниматься monkey patching'ом используя "гибкость языка". Другое дело, если программа -- организация эксперимента или прототип того-ещё-не-знаю-чего. Тут гибкость важнее дизайна.

>4.2 изменения технологий, в т.ч. самого языки


это как? Мольеровский мещанин ВНЕЗАПНО обнаружил, что всю жизнь разговаривал прозой?

>== поддерживаемый


да, важно не "200 студентов написали много версий 0.01", а:
1. зрелый, поддерживаемый код
2. автоматизация везде, где возможно (FFI, генерация стабов и т.п.)

>отсюда можно копать, моя любимая тема -- абстракции :-)


тогда можно сделать вывод, что не все абстракции одинаково полезны. Например, можно сделать парсер на комбинаторах, на монадах или паттерн матчингом. Но у монад ВНЕЗАПНО большие накладные расходы по памяти и скорости.

Например, был тред про факториал на окамле, хаскелле, с++ и т.п. Так основной вывод с того треда: размещается объект в стеке, хипе или в пуле -- абстракция более важная, чем "написано на с++/яве/окамле".

Если на картинку с кластерами с shootout benchmark посмотреть внимательно, там языки-абстракции-результаты гнездятся тоже не абы как, прослеживается закономерность по абстракциям, концепциям, "качествам".

>на самом деле, конечно это тоже важно.


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

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

а зачем им вообще что-то «шейпить», если средства зрелые? Если пубертатные, тогда ладно ещё.

а я ведь один раз четко сказал свое мнение, ладно еще раз:

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

В качестве примера рассмотрим яву, в которой до 2005(!!!!) года не было дженериков, а использовалось зрелое выведение всего из Object-a (в том числе при создании коллекций, бу-га-га!)

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

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

> хорошо читаемый write only код на метабрейнфаке прокатит?

"читаемый write only"? это что такое?

> хорошо читаемый ... код на метабрейнфаке прокатит?

да, т.к. брейнфак в общем-то не препятствует эффективной реализации поверх него языка высокого уровня

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

= понятность языка

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

>В качестве примера рассмотрим яву, в которой до 2005(!!!!) года не было дженериков,

Когда ява создавалась (конец 90-х) были очень сильные реакционные настроения против шаблонов С++ которые вызывали внезапные internal compiler error-ы без разъяснения контекста ошибки, просаживали время компиляции в несколько раз и вообще интродуцировали кучу внезапных граблей которые могли вылезти и на финальной стадии проекта. В первой ревизии С# шаблонов тоже не было. По результатам голосования на сайте Борланда генерики выпилили и из Дельфи.

>а использовалось зрелое выведение всего из Object-a (в том числе при создании коллекций, бу-га-га!)

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

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

> Когда ява создавалась (конец 90-х) были очень сильные реакционные настроения против шаблонов С++ которые вызывали внезапные internal compiler error-ы без разъяснения контекста ошибки, просаживали время компиляции в несколько раз и вообще интродуцировали кучу внезапных граблей которые могли вылезти и на финальной стадии проекта. В первой ревизии С# шаблонов тоже не было. По результатам голосования на сайте Борланда генерики выпилили и из Дельфи.

(побежал в википедию проверять насчет С# и Дельфи)

если так, то все это подтверждает тезис: в языке должны быть "незрелые" фичи, иначе лет через 5-10 мы будем ужасаться идиотизму его создателей

>> а использовалось зрелое выведение всего из Object-a (в том числе при создании коллекций, бу-га-га!)

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

не понял... ты защищаешь подход старой явы? ну так это

1. небезопасно -- то, что сейчас ловится статически, вызывало http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ArrayStoreException.html

2. тормозно -- нужны рантаймовые проверки

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

>не понял... ты защищаешь подход старой явы?

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

>небезопасно -- то, что сейчас ловится статически, вызывало

Это чисто теоретическая проблема т.к коллекции всегда private и поэтому то что в них кладется ограничено интерфейсом класса в котором они содержатся.

>тормозно -- нужны рантаймовые проверки

А их никак не избежать без того чтобы отказаться от того что код всех библиотек в момент работы над проектом полностью собран. В том же COM гоняли туда-сюда коллекции IUnknown-ов и делали им QueryInterface перед использованием.

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

> Я бы сказал что это отличный подход который я люблю - перемещает проблемы из практической сферы в теоретическую в которой они некого не волнуют кроме чистоплюев. Таким образом он диаметрально противоположен подходу С++ который решая теоретические проблемы порождает гораздо более серьезные практические проблемы.

бред

плюсы никогда не отличались стремлением решать теоретические проблемы (и потому не популярны в академической среде :-)

> Это чисто теоретическая проблема т.к коллекции всегда private и поэтому то что в них кладется ограничено интерфейсом класса в котором они содержатся.

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

> А их никак не избежать без того чтобы отказаться от того что код всех библиотек в момент работы над проектом полностью собран. В том же COM гоняли туда-сюда коллекции IUnknown-ов и делали им QueryInterface перед использованием.

СОМ головного мозга?

в современной яве избежали

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

>плюсы никогда не отличались стремлением решать теоретические проблемы (и потому не популярны в академической среде

Наверно я слишком громко назвал проблемы которые любит решать С++ "теоретическими". Это скорее FUD-проблемы.

>> Это чисто теоретическая проблема т.к коллекции всегда private и поэтому то что в них кладется ограничено интерфейсом класса в котором они содержатся.

>как быть с коллекциями, которые подаются аргументом или выдаются результатом функции?

Можно сделать аргументом массив и при получении конвертировать. А при отдаче вовне конвертировать обратно из коллекции в массив. Впрочем, в плюсах при получении аргумента вида const std::vector< std::tr1::shared_ptr<Widget> >& чтобы сохранить содержимое себе его тоже надо копировать, и тоже неявно копировать при отдаче коллекции вовне, полагаясь на оптимизацию возвращаемого значения.

>в современной яве избежали

Там сделали именно то что я ожидаю от конструкций призванных обеспечивать безопасность типов: там это нечто типа аннотации.

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