Обсуждение:Язык модулей ML

Стиль изложения

Не согласен со стилевыми правками.

Во-первых, терминологическая ошибка. «прозрачное» и «тёмное» — это формы сопоставления, а не виды: «There are two forms of signature ascription, transparent and opaque». Это принятый термин — например, здесь, в самом низу страницы. По крайней мере, я встречал только так. Если где встретили «виды» — покажите.

Во-вторых, «взаимное использование компонентов программ» — это императивный стиль изложения. ФПшный стиль будет «совместное использование». Разница тонкая и казалось бы несущественная, но педагогически она важна, так как сводится к идеологической сущности парадигмы.

Есть высказывание, не шибко авторитетное (автора не помню, процитировал его Джон Кармак) и уж точно не от первопроходцев-теоретиков, но чисто педагогически от себя рекомендую относится к ней как к Мантре Тайного Знания, рассматривая все прочие практические свойства ФП как её следствие. Примерно по памяти смысл такой: «ООП поддерживает крупномасштабное программирование за счёт того, что инкапсулирует „moving parts“, ФП — за счёт того, что исключает „moving parts“.» Под «moving parts» понимается изменяемое состояние, как-нибудь подберу красочный перевод.

Более наглядно скажу так. В ФП компоненты не используют друг друга; они являются независимыми и вместе используются для построения более сложных компонентов. В ИП же мелкие компоненты организуются в более крупные постепенно и плавно. Когда ИП-программист изучает сторонний компонент, он обычно говорит, что знакомится «с тем, как компонент работает». ФПшник говорит, что знакомится «с интерфейсом компонента». Разница в том, что в ИП иерархия компонентов неразрывна, старшие тянут младших, и для понимания требуется смотреть на зависимости; а в ФП иерархия скачкообразная, систему режут на слои барьеры абстракции. То есть ФП по своей сути задаёт тенденцию к ЯОП в простейшей его форме (без радикальной смены грамматики и семантики), даже если не знать что это или не заморачиваться. В контексте ML последнее предложение особенно существенно - MetaLanguage.

Для совсем наглядного примера: InfixingOperators. Строятся элементарные кирпичики — чистые каррированные функции с инфиксным использованием и назначенными приоритетами. А потом из них формируются такие длинные предложения, что их читать можно только лингвистически, как «пиво = Вася сгонял в магазин». Едва стоит попытаться мысленно трассировать последовательность вызовов — мозг стопорится. (Собственно, потому ФП и называют «декларативным (что-) программированием», несмотря на изобилие действий, которые представляют собой «как», а не «что». На самом деле «декларатив» это HTML и SQL.) Компоненты в ФП не используют друг друга, они служат такими же элементами для написания программ, как «for» в Паскале. Но фишка ФП в том, что эти написанные программы сами становятся элементами для написания программ следующего уровня — как если бы программист сменил Паскаль на Перл или Питон для «склейки». Собственно, статья как раз об одной из реализаций этой идеи. Так что я настаиваю на «совместном использовании», а не «взаимном».

Третья правка абсолютно не существенная, сугубо стилевая, но подниму вопрос между делом, пригодится на будущее. Я предпочитаю последовательный стиль изложения даже в рамках одного предложения. Последовательный — значит, сперва мотивация, причинно-следственные связи, потом о том, что там на том конце мотивации, а лишь потом что мы делаем для достижения этого конца. Поэтому предложение «В качестве примера использования [этой структуры] можно рассмотреть реализацию более сложного поведения» мне больше нравится, чем «Следующий пример этой структуры реализует более сложное поведение». Кстати, мне ещё не нравится «пример реализует». Пример сам ничего не реализует, его человек написал, и в нём (в примере) он (человек) что-то реализовал. На фоне этого я ещё даже подумал, что слово «использование» у вас пропущено специально, но с таким стилем я тем более не согласен. В качестве компромисса могу предложить такой вариант: «В следующем примере реализуется более сложное поведение с использованием этой структуры».Arachnelis 09:17, 5 января 2015 (UTC)

• Хорошо, с формами/видами ошибся. Насчёт взаимного использования — меня несколько смущает термин «соиспользование», поэтому для пробы заменил в одном месте, как видно, неудачно. Есть ли где определение/перевод этого самого соиспользования? Что касается третьего пункта, личное мнение вкратце: это было слишком длинно (больше половины предложения — вода), а кроме того вряд ли на уровне предложения нужно городить огород с обоснование в ущерб краткости изложения. Разве читатель прекратит читать если обоснование ему вдруг не понравилось? Может быть, «В следующем примере этой структуры реализовано более сложное поведение». Хотя и пример может реализовать: [1] а также поиском по фразе в гугле. Заметьте несколько книжных примеров. РоманСузи 10:18, 5 января 2015 (UTC)

• Глянул один источник (ссылка 1 в статье) - там идут "зависимости между модулями" (dependencies). Ещё бывает "interopera...", т.е. перекрёсное взаимодействие - но здесь прошу не цепляться за "взаимо-" в русском, т.к. "inter-" в английском более размыто. Поищу что поконкретнее, но за сроки не обещаю, щас со временем беда. Arachnelis 15:12, 8 января 2015 (UTC)

• Данная статья ­— результат большой и качественной работы, но раз уж поднялся вопрос о стиле изложения, то должен отметить, что есть куда стремиться. В том виде как есть статья хороша для журнала, а чтобы она смотрелась как энциклопедическая следовало бы, на мой взгляд, учесть следующие вещи. Во-первых, стоило бы постараться минимизировать примеры, и постараться не делать их сквозными (чтобы не было отсылок «в примере рассмотренном выше…» или «далее для этого примера будет показано, что…»): секции изложения должны быть максимально самостоятельными (в процессе дальнейших правок они могут поменяться местами или даже разъехаться по разным статьям). Кроме того, сами примеры для энциклопедической статьи не должны быть мотивирующими, то есть, в идеале сначала должны быть даны подобающие и точные абстрактные определения, а конкретные примеры — лишь как их последующая небольшая иллюстрация. Иными словами, хорошая статья не должна основываться на примерах, а должна читаться целостно и в том случае, если бы они были исключены (или, например, скрыты спойлером). Во-вторых, стоило бы аккуратнее пользоваться навигацией внутри статьи и выделением (жирным и курсивом). В целом — навигация дело хорошее, но она имеет смысл на самостоятельные секции и определения, «самостоятельные сущности», которые потенциально могут стать статьями. То же касается и выделения жирным: если какое-то понятие выделено жирным, то рядом ожидается его определение, и ожидается также перенаправление на эту статью (и на это место), возможно, с потенциалом для самостоятельной статьи. В иных случаях лучше жирным не выделять. В-третьих, речевые обороты в энциклопедическом стиле несколько отличаются от используемых в статьях, такие обороты, как «рассмотрим x», «как уже было отмечено» лучше избегать. Хочу чтобы мой комментарий был воспринят в позитивном ключе — не как критика (так как статья в по большому счёту хорошая и целостная), а как направляющее к совершенству (которому, как известно нет пределов), bezik° 11:24, 6 января 2015 (UTC)

• Я согласен, и знаю это всё. В данном случае иначе (пока) не получилось - 100% просмотренных источников излагают именно так, просто в силу необычности предмета. Единственное исключение - The Deifinition Of Standard ML. Но это матан, изучение которого даже разработчики компиляторов признают нелёгким делом. Так что переваривать в энциклопедический стиль придётся самим "на коленке", я пока собрал сырое. Постараюсь по мере сил, буду рад любым конкретным предложениям. Arachnelis 15:12, 8 января 2015 (UTC)
• Некоторые источники (например, Paulson) делят не на три главы, а на две: "Структуры и сигнатуры" и "Функторы". Такой подход облегчит переход к энциклопедическому стилю. Arachnelis 17:00, 13 января 2015 (UTC)

• Такой вариант оцените. Arachnelis 17:34, 15 января 2015 (UTC)

• Давно хотел спросить: может быть Реализацию / OCaml лучше в статью про OCaml утащить (желательно ещё источниками снабдив)? То есть, здесь общая теория, а там конкретика. РоманСузи 18:21, 13 января 2015 (UTC)

• Теоретически вроде ничего возразить нельзя, но меня беспокоит размер статьи. Думается, изолированное изучение языка модулей после ядра языка читателю будет удобнее. ИМХО. Arachnelis 20:21, 13 января 2015 (UTC)

• Ну это я пока сильно заранее спрашиваю. У меня пока статья OCaml медленно движется (почему-то Erlang больше вдохновлял). И о размере какой статьи идёт речь? На избранную можно хоть 250 Кб выставлять. РоманСузи 20:39, 13 января 2015 (UTC)

• Ну вы же меня знаете, я ориентируюсь на читателя, на логику, на что угодно, но только не на местные правила :). Так что это к администрации. Я говорил о размере статьи об ОКамле. Если здесь будет 100 Кб, и там ещё плюс 50 из общих 250, то определённо рано или поздно кто-то поднимет вопрос о переносе/слиянии, хотя бы для равновесия. А если про каждый диалект по 250 напишем - то тем более, проще одна статья про модули на 150, чем в трёх одно и то же разными словами по 50 в каждой. Проще уж сразу. Кстати, тоже на будущее, я тут напоролся на чудесную сводку, уверен, что пригодится: ML Dialects and Haskell: SML, OCaml, F#, Haskell . Давно была мысль сделать сравнение языков семейства ML (более узкое и более удобное для интересующихся Х-М, чем сравнение всех и вся), а тут четыре уже готовы. Менее готовое, но более обширное собрание: haskellwiki/Blog_articles/Comparisons Arachnelis 20:46, 13 января 2015 (UTC)
• Сообразил, как мы должны всё организовать. Здесь — ОБЩАЯ часть, то, что не является сугубо присущим какому-либо одному диалекту, и в разделе «Расширения» вскользь о различиях и отсылка к разделу в статье о диалекте. В статьях о диалектах, наоборот, про общую часть максимум абзац с отсылкой сюда, а потом предельно подробно про индивидуальные особенности. Это всё очевидно. Так вот, ФВП и первоклассные модули, соответственно, остаются. Но классы, исходя из такой схемы, надо перенести в ОКамл, так как в successorML, скорее всего, ООП будет реализовано совершенно непохожим образом. Я так понимаю, они введут теоретически проработанные подтипы в базовую систему типов, и тогда можно на коленке строить объектные модели без особого сходства с традиционным ООП (как на Лиспе CLOS). Если я не прав, и сходство будет существенное — тогда вернём раздел сюда и перепишем. В SML# полиморфизм записей наверняка позволяет изображать что-то погибчее, чем пример «почти-ООП» здесь, так что это третий индивидуальный вариант. Возможно, удастся сочинить обобщающий раздел про ООП, но позже. За один момент всё же надо сейчас договориться — абзац про различия в семантике функторов. Я думаю, этот акцент лучше всего продублировать и здесь, и в обоих статьях (изложив по-разному). Там всего-то один абзац, так что торговаться за размер статьи даже я не буду, зато это определённо лучше, чем «здесь SMLный вариант, в SML опустить по умолчанию, а в ОКамл написать». При дублировании ни один читатель не упустит эту маленькую деталь. Если вы согласны со всей схемой, то организацию я беру на себя, вроде время пока всё ещё немного есть. Раздел «модульность» в вашем черновике про ОКамл, соответственно, буду править, пока вдохновение на эту тематику настроено, вы тогда потом по стилю если что подправите, источники повесите — и в чистовик. Нормально так? Arachnelis 09:35, 14 января 2015 (UTC)

• Вроде бы, так хорошо. Кстати, я из черновика уже кое-что перетащил в статью. Одна просьба — ставьте пожалуйста на все абзацы источники, во всяком случае в статье OCaml. Иначе потом на хорошую или избранную не подать. У меня же пока наоборот нет вдохновения. РоманСузи 18:59, 15 января 2015 (UTC)