LINUX.ORG.RU

[ЖЖ] *морфизм, Haskell & Lisp

 


3

1

Вот все праздники разбирался с Template Haskell, квазицитированием, SYB и ghc7, не забывая такие важные вещи как распитие спиртных напитков и игру в FreeCiv :)

И вот какая идея мне пришла в голову... Катаморфизм ведь — штука всеобъемлющая, и если лисперы могут называть свои S-выражения алгебраическими типами данных, то почему же мы не можем называть алгебраические типы данных S-выражениями?

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

Единственное, «но» в подходе лисп-систем к компиляции, там компилятор «внутри», а не «с боку» как в более традиционных подходах. А так, работы ведутся, та же Java, та же Scala позволяет вмешиваться в работу компилятора. А в GHC есть Template Haskell, который идеологически близок к лисповским макросам, с той только разницей, что они стоят по разные стороны относительно катаморфизма: лисп как списки, хаскель как алгебраические типы с соответствующей типизацией.

В ООП языках все еще интереснее, там для реализации лисповского подхода нужно две вещи: а) классы должны быть объектами первого класса; б) должен быть способ узнавать конкретный тип объекта в рантайме. В Яве есть и первое (на худой конец в рамках JVM), и второе. В С++ есть RTTI, а вот с первым дела обстоят вроде бы не очень, хотя Александреску в своей книге показывал, вроде бы, как можно генерить иерархию классов с помощью шаблонов. Про Scala, вообще молчу, там алгебраические типы «из коробки» имеются.

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

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

> Кстати, а вообще можно работать полностью без преобразования типов?

А какие с этим проблемы? Зачем вообще может понадобиться преобразование типов?

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

> А кто говорил про _любые_ ошибки? Но, например, агда.

Логические она точно не отловит. Или когда ошибка в самой спецификации.

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

> других языков со статической типизацией нет?

Тут прозрачно намекают на Haskell, но вот в чём беда, когда я пытался изучать Haskell, то не смог с ним приступить ни к одной из реально стоявших передо мной задач. Поскольку я не могу заниматься изучением языка путем написания различных факториалов, то пришлось на него плюнуть и взяться за Common Lisp. Отличный язык Haskell, в котором нельзя сделать ошибок просто по той причине, что на нём почти нельзя писать ничего практического. Нет код - нет ошибок. Мечта.

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

> А какие с этим проблемы? Зачем вообще может понадобиться преобразование типов?

Ну там например при сложении int и float, int должен неявно преобразоваться во float, чтобы сложиться. Или ты предалагаешь явные преобразования float(5) + 1.5 или переписывать функции для всех возможных сигнатур?

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

Зачем вообще может понадобиться преобразование типов?

Ну, такой дубовый пример из плюсов, когда

std::string string_ = "This is string";

То есть объект типа «строка» мы инициализируем (в данном случае с неявным преобразованием) объектом типа «массив символов». Как более Ъ проводить подобные действия при идеальной статической типизации?

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

>Какие проблемы?

Ты же сам о них твердишь.

В примере про JavaScript я показал, что неочевидные преобразования типов проводятся аж бегом.

И пусть проводятся. Кому надо - пользуется. Кто не умеет, но все равно пользуется - индеец. Может быть тебе они неочевидны, мне и многим другим очевидны.

где же это так конпелятор «помог», подумал за меня?

Он сложил числа или сконкатенировал строки, как ты и просил его. Ты не написал тонну кода для этого, он тебе в этом помог.

«а какого хрена ты творишь-то?»

Этот вопрос в первую очередь нужно задавать самому себе при написании «1»+2.

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

> Отличный язык Haskell, в котором нельзя сделать ошибок просто по той причине, что на нём почти нельзя писать ничего практического

Ну, так Haskell и не лезет (пока) в production и прочий ынтырпрайз. Он, как я помню, с самого начала позиционировался, как академический язык, полигон для испытания теорий. А под его влиянием, может, более другие языки и претерпят какие-нить изменения в лучшую сторону.

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

> Смотрю я на отсутствие типизации, и говорю, что без неё проблем будет больше, чем с ней. Сколько раз ещё это повторить надо?

Ошибки, от которых защищает статическая типизация не стоят самой типизации.

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

> Или ты предалагаешь явные преобразования float(5) + 1.5

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

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


Шаблоны (templates)?

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

>Шаблоны (templates)?

И при использовании встанешь на те же грабли.

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

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

а какие абстракции над АСТ нужны? не то чтобы минимально достаточные, а реально удобные?

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

> Или когда ошибка в самой спецификации.

Ну то, что программа соответствует спецификации, доказать можно. А больше ничего доказывать смысла нет.

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

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

Очевидно так: std::string string = new string(«This is string»);

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

> а какие абстракции над АСТ нужны? не то чтобы минимально достаточные, а реально удобные?

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

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

> Ну то, что программа соответствует спецификации, доказать можно.

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


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

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

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

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

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

> Нам надо доказать отсутствие ошибок перед тем, как программа

заказчику уйдет


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

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

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

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

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

> Так и делается обычно.

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

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

> «Конец разработки» - это когда программа соответствует спецификации,

удовлетворяющей заказчика.


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

archimag ★★★
()

Вещества в треде!

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

> Ну то, что программа соответствует спецификации, доказать можно. А больше ничего доказывать смысла нет.

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

Этого сделать на данный момент нельзя, да и никому не надо.

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

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

>ЯП создается математиками для математиков в итоге

Хм, а сообщество хаскелистов за последнее время создало вполне-себе уютную инфраструктурку. И веб-приложения, и ГУЙ и биндинги к всяким-разным вкусным библиотечкам, дрова для разных БД и прочее. За последние пару лет прогресс очень заметен.

А зависит только от восприятия, на самом деле... Это уже сложившимся программистам нужно кардинально перестраивать свое мышление. Новичкам в этом плане намного проще.

Я тут вон разбирал свой код двухлетней давности. Очень познавательно. Тут и неумение пользоваться штатными комбинаторами; засилие лишних скобок; сваливание в одну кучу концепций, которые сваливать не нужно, а нужно комбинировать; совершенно лищние функции с типом IO a -> IO a и т.д.

Но есть одно «но». Код был понят практически сразу, не смотря на большой перерыв в программировании на хаскеле. Практически сразу и сходу были внесены изменения, которые заработали СРАЗУ. Код хорошо модифицировался по частям, в рантайме это НИКАК не проявлялось, хотя проверка типов ругалась.

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

> И веб-приложения

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

дрова для разных БД

В большинстве очень все сыро.

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

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

Практически сразу и сходу были внесены изменения, которые заработали СРАЗУ. Код хорошо модифицировался по частям, в рантайме это НИКАК не проявлялось, хотя проверка типов ругалась.

см. пункт выше.

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

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

И отчего всякие Haskell-и да OCaml-и считаются лучшими языками для прототипирования?..

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

> И отчего всякие Haskell-и да OCaml-и считаются лучшими языками для прототипирования?..

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

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

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

Хе-хе-хе. Не всегда и не везде. В Scala, есть прикольнейшая штука, implicit называется ;) Вся довольно сложная eDSL-машинерия скалы именно на этом и строится. Но проверка типов — статическая, просто добавится неявное преобразование типов.

Вообще всякие 2+3 в качестве примеров приводить не интересно. Лучше (.) :: (b -> c) -> (a -> b) -> a -> c и пусть рассказывают как такое реализовать в «динамических» языках, чтобы оно в рантайме постоянно не валилось. А потом еще можно и >>= привести. Можно, конечно, и скаловское что-нибудь, чтобы не орали «Хаскель! Хаскель!», но там синтаксис более запутанный, и ориентация на ООП.

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

> Ошибки, от которых защищает статическая типизация не стоят самой типизации.

Ошибки, которые допускает динамическая типизация, не стоят выгод от нее.

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

>Смотрю я на свой опыт разработчик как со статической типизацией

Это ты так C++ ушибся, что разницы не видишь? Ну, дык!

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

>то пришлось на него плюнуть и взяться за Common Lisp

А может стоило за ум взяться? Книжки почитать по дискретной и не очень математике, теории типов, мат. логике, абстрактной алгебре?

Кстати, посмотри на Скалу, там все то же самое, только с ориентацией на ООП, и огромным количеством ява-библиотек на все случаи жизни, невозбранная работа в режиме индусо^W «улучшенной явы», и нет необходимости чтить монаду IO. Или на F#, те же яйца, только под .Net.

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

> А может стоило за ум взяться?

archimag вызывает большое уважение и сделал больше чем вы, делайте выводы

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

>Зачем?

Ответ очевиден: закостенеешь мозгом, будешь не спобен принимать, и воспринимать новое. Если для тебя программирование - ремесло, исключительно способ заработка на кусок хлеба, то конечно можно, спокойно уйдешь лет через 10 на свалку истории.

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

>Они очень убоги, нет ни одной нормальной системы шаблонов.

Ты давно смотрел? Hamlet уже не катит?

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

>А что, кроме плюсов, других языков со статической типизацией нет?

Я конкретно про С++ писал =).

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

>>В случае С++ ты уже начинаешь в яме

Что за бред?

горькая правда жизни.

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

> Ты давно смотрел? Hamlet уже не катит?

Там шаблоны - это чистый Haskell code, и это ужасно. Ни один нормальный верстальщик или дизайнер не станет учить сильно ограниченный eDSL на haskell, чтобы сделать страничку.

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

> Ответ очевиден: закостенеешь мозгом, будешь не спобен принимать, и воспринимать новое.

Для этого обязательно учить именно дискретную математику, мат логику? Почему не функан, например?

Если для тебя программирование - ремесло, исключительно способ заработка на кусок хлеба, то конечно можно, спокойно уйдешь лет через 10 на свалку истории.

Программирование - это и есть ремесло.

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

>функан
У нас его сокращали до ФАН :) Хотя фана как такового там не так уж и много ;)

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

> А может стоило за ум взяться?

Ответ очевиден: закостенеешь мозгом, будешь не спобен принимать,

и воспринимать новое.



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

Если для тебя программирование - ремесло


Извините, а что программирования для вас? Я занимаюсь программированием потому что мне нравится создавать программы, а почему занимаетесь вы?

спокойно уйдешь лет через 10 на свалку истории


Обоснуете? Или только слюной брызгать способны?

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

> А это как такое делается??? Я нихрена не понял.

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

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

> Шозабред?

Дай человеку больную тему про математиков развить :)

anonymous
()

пора уже отходить от языков, созданных с помощью инженерного похода и приходить к подходу математическому

вперёд

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

>у нас на физфаке многие преподы именно за это их и ругали

Причем тут конкретно математика? Это общий закон: как только ты перестаешь развиваться, искать что-то новое — все. Наступает печальный конец. И как раз твои преподы этому доказательство.

Я кстати, говорю совершенно серьезно, без подначек и прочего. Всегда нужно искать что-то новое.

Я знаю одного математика который ведет себя крайне безобразно. Правда вот, когда в вузах стали вводить бально-рейтинговую систему, направо и налево раздавать «бананы» стало проблематично. Так что успокоился малость. Хотя из любого приличного вуза его бы поперли, но провинция-с.

Или только слюной брызгать способны?


Разве? По-моему, я совершенно спокойно разговариваю, нет?

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

>Она легко делается в любом динамическом языке

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

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