Здравствуйте, bigger longer and uncut, Вы писали:
Ну, что же еще одно мнение законченного апологета ФЯ.
В общем-то особого смысла отвечать на него нет. Все равно столь сформировавшюся позицию не изменить.
Однако, я все же отвечу.
Ответ мой рассчитан на сомневающихся.
VD>>И более того, он позволяет писать в функциональном стиле не хуже чем ML или Хаскель.
BLA>Ого, неслабое заявление.
BLA>Только необоснованное.
Я выражаю мое мнение. Что касается обоснованности, то в твоем ответе обоснований нет вовсе. Если уж ты требуешь обоснования от других, то хотя бы потрудился бы обосновывать свое несогласие.
BLA> Если взять Nemerle как _язык_, то он уступает и ML (особенно MetaML/Ocaml) и уж тем более хаскелю.
Это ничем не обоснованные заявления. Мое мнение — все что ужно длоя удобного программирования в функциональном стиле в нем есть. Но с удовольствием послушаю аргументированное доказательство обратного. Все же Ocaml и Хаскель я знаю очень поверхностно.
BLA> ни такой развитой системы типов,
Заявление громкое, необоснованное и крайне сомнительное.
BLA> ни контроля за редукционной стратегией (если я не упустил ничего)
Возможно, упустил. Если ты аргументируешь свои нападки, то можно будет попробовать понять насколько ты прав, и насколько то о чем ты говоришь актуально.
BLA> ни такого уровня формализма.
Очень убедительно. С такими аргументами в лес.
BLA> Да первая же попытка написать какой-нибудь хитроумный комбинатор даст понять кто где.
Ну, дык зачем дело встало?
К тому же ты кое-чего недопонимаешь. У 99% народа нет, нужды писать комбинаторы (хотя это на Nemerle делать можно). Людям нужно удобно и просто писать нужные им код, решать их задачи.
И тут кроется главный вопрос. Люди уже в массе своей не хотят использовать чисто функциональные языки типа Хаскель. Более того гибридные языки типа Окамла им тоже мало интересны. Это факт, который очень легко доказать. Надо доказывать?
BLA>А если взять компилятор Nemerle с этими на каждом шагу в кассу и не в кассу понапиханными макросами, так все еще хуже, как ни удивительно. Если кто-то не согласен, я с радостью услышу опровержение и рассказ как удобно на самом деле делать композицию из макроса и функции.
С радостью опровергну любое сделанное тобой утверждение, после того как ты потрудишься хоть немного его обосновать.
Апеллировать к возгласам вроде "в кассу понапиханными макросами, так все еще хуже, как ни удивительно..." бессмысленно и не интересно.
BLA>Кстати у common lisp'a та же проблема и даже после Scheme он часто вызывает лишь глухое раздражение, несмотря на более мощные макросы.
Какая такая же? Может быть сначала нужно доказать, что проблема вообще есть?
И вообще, может быть прежде чем выступать с критикой чего-то лучше сначала хоть немного узнать об этом чем-то? Или это такой способ познакомиться с незнакомым языком, наехать на него без малейшей аргументации заставив людей объяснять тебе базовые вещи?
Что касается макросов Nemerle-а, то как раз они намного ближе к макросам Схемы нежели Лиспа (хотя, по сути, Схема — это клон Лиспа, но как раз подсистема макросов в нем сильно отличается).
Надо понимать, что авторы Нэмерла знают как минимум не меньше тебя в этом вопросе. В конце вот этого
http://nemerle.org/metaprogramming.pdf документа есть раздел "Related work". В нем кратко описывается, откуда растут ноги макросов Немерла, и почему были выбраны те или иные решения.
Вот что там сказано по поводу макросов Сехемы:
У нашей системы много общего с современными макрорасширениями Scheme[1]:
• Альфа-переименование и связывание переменных выполняется после развертывания макроса, с использованием контекста, хранимого в макросе.
• Макросы могут контролируемо использовать внешние имена, не боясь пересечься с посторонними именами.
• Сторона, на которой вызывается макрос, не использует какого-либо особого синтаксиса для вызова макросов, единственное место, где используется особый синтаксис – определение макроса, что обуславливает легкость использования макросов программистами, несведущими в метапрограммировании.
Поддерживая перечисленное выше, мы встроили систему макросов в статически типизированный язык. Типы в сгенерированном коде проверяется после раскрытия. Мы также обеспечиваем четкое разделение этапов – метафункции до использования должны быть скомпилированы и сохранены в библиотеке.
Работа над Scheme длилась довольно долго, и предлагалось много интересных вещей. Например, макросы первого класса в [9], кажется, можно реализовать в Nemerle с помощью простой передачи функций, оперирующих кодом объектов.
Другими словами, как раз со Схемы и были взяты многие идеи макросов немерла.
BLA>Да и сама по себе система макросов — сомнительная мегафича.
Для меня по-прежнему больше сомнений вызывает обоснованность твоего мнения. Так что не забывай аргументировать.
BLA> Кроме того, что их выразительная мощь на самом деле сильно ограничена (самим фактом работы их на уровне AST и относительной их локальности и непредсказуемости — да,
Хм. Снова сотрясение воздуха. Хотелось бы развернутого объяснения того, чем не угадила работа на уровне AST (в том числе типизированного)? Ну, и по поводу непредсказуемости тоже хотелось бы услышать нечто большее, чем пустые заявления.
BLA>если они полны по-тьюрингу на них можно сделать все
Они полны по Тьюрингу.
BLA> — но в какой-то момент сложность все равно сделает это бессмысленным),
На каком-то безусловно. На каком-то уровне сложности все современные средства созданные человечеством бессильны. Ну и что?
Если не заниматься пустым философствованием, а поглядеть на то, что способны дать макросы, то мне кажется очевидным то, что они способны сильно упростить решение многих актуальных задач. А стало быть, они точно полезны.
BLA>... еще и сам по себе этот подход используется десятки лет
Да, используется. Не спорю. Но используется в языках, которые по тем или иным причинам не стали и вряд ли когда-нибудь станут действительно популярными. Nemerle же имеет все предпосылки стать популярным. Он не напичкан догмами. Как и С++ он предоставляет выбор парадигмы. Причем делает это куда эффективнее и чише чем С++. Функциональное программирование на Немерле — это функциональное программирование. Без компромиссов, моря обвязочного кода и ужимок свойственных С++. Императивное программирование хотя и практически целиком встроено на макросах, но все же выглядит очень естественно. Даже известные апологеты
C#/С++ находят императивную составляющую в Немерле очень достойно реализованной.
BLA> и приделать макросистему к любому языку дело моментальное.
Ага. Языком. Я вот пытался сделать это для C# и могу сказать, что это не самая простая задача. Она конечно реально, но есть две проблемы. Первое — нужно иметь четкое видение того как это сделать с учетом особенностей языка. Второе — это просто большой объем работы. Даже банальные вещи вроде совместимости с языком в который встраиваются макросы и интуитивность использования являются очень немалыми проблемами. На сегодня языки обладающие действительно мольными, удобными, гибкими и совместимыми с разными парадигмами подсистемами макросов можно перечислить по пальцам одной руки. И, по-моему, Немерле лидер среди них. По крайней мере, аналогичной реализации у императивных языков я вообще не видел.
BLA> Тем более что почти для любого языка уже готовых макродвижков как минимум дюжина.
Громкие слова не имеющие ничего общего с действительностью. К примеру, перечисли эти дюжины для C# и С++.
BLA> В Окамле даже встроенный есть.
Это не правда. Для Окамла есть только препроцессор CamlP4. Вот слова о нем из привденного выше документа:
CamlP4 [12] – это препроцессор для OCaml. Его LL(1)-парсер — полностью динамический, что позволяет выразить весьма сложные расширения грамматики. Макросы (именуемые расширениями синтаксиса) должны быть скомпилированы и загружены в парсер до использования. При работе они могут конструировать новые выражения (используя систему цитирования), но только на уровне нетипизированного дерева разбора. Более углубленное взаимодействие с компилятором невозможно.
Немерле превосходит CamlP4 в том, что макросы в нем встроены в компилятор и мгут взаимодействовать с ним получая информацию о типах. В этом форуме было приведенио уже множество примеров того, как эта ценная возможность может сделать макросы предсказуемее и интеллектуальнее.
BLA>В хаскеле встроенных сразу три штуки на выбор.
Опять не правда. Есть экспериментальные расширения Хаскеля предоставляющие такие возможности. Лучший из них — Template Haskell и послужил одним из прототипом для макросов Немерла:
Между макросами Template Haskell [2] и Nemerle есть интересные различия:
• Разрешение связываний при трансляции цитирования дает возможность сделать вывод о корректности типов объектного кода до его использования. Это позволяет значительно раньше обнаруживать ошибки. Но наличие splicing-конструкции $ делает типизацию отложенной до следующего этапа компиляции, и в этом случае новые связывания должны быть динамическими.
• Макросы Template Haskell, как и любая другая функция Haskell, являются функциями высшего порядка: их можно передавать как аргументы, применять частично и т.д. Это, однако, требует вручную помечать, какой код должен исполняться при компиляции. Мы решили позволить вызывать макросы просто по имени (как в Scheme), так что их использование выглядит как вызов обычной функции. Вы по-прежнему можете использовать функции высшего порядка (функции, оперирующие объектным кодом, могут быть произвольными), но только верхние метафункции (предваряемые macro) запускают вычисления во время компиляции.
• Мы не ограничиваем splicing объявлений с кодом верхнего уровня и не вводим особого синтаксиса для вводящих их макросов. Это кажется хорошим способом использования преимуществ связывания имен после раскрытия макроса и императивного стиля, присущего Nemerle. Для императивного программиста естественно думать о вводимых определениях как о побочных эффектах вызова макросов, даже если эти вызовы находятся в цитируемом коде.
• Мы вводим макросы, оперирующие с типами, объявляемыми в программе, и способные императивно изменять их. Более того, они выглядят как атрибуты, применяемые к определениям типов, так что опять же программисту не обязательно знать что-нибудь о метапрограммировании, чтобы использовать их.
Есть еще много сходств с Template Haskell. Мы напрямую позаимствовали оттуда идею квази-цитирования и splicing-а. Идеи исполнения функций при компиляции и отложенной проверки типов также навеяна Template Haskell.
BLA>Правда нужны они тому же хаскелю как собаке пятая нога — чем им заниматься в ленивом языке с каррингом — это нужно очень сильно думать, чтобы придумать.
Само их наличие говорит, что нужны. Зачем собственно делать то, что и так есть?
BLA> А когда придумаешь — тут-то они и бесполезны, т.к большинство таких задач сводятся к нетривиальной манипуляции с типами.
Которые с успехом могут быть организованы в Немерле, так как компилятор предоставляет средства анализа имеющихся типов, средства их модификации, и средства порождения новых типов.
BLA>Потому если всерьез кому нужно реально что-то реально сложное, то используют term rewriting трансформацию. А вот здесь уже макросы ничем похвастаться не могут. MSP типа MetaOcaml еще как-то, но не макросы.
Хм. Сдается мне, то эти слова просто демонстрируют то, что ты не понимаешь, что такое макросы Немерла.
Вот что сказано о MetaOCaml на титульной странице его сайта:
http://www.metaocaml.org/
MetaOCaml is a compiled dialect of MetaML.
А вот, что сказано о MetaML в упомянутом мной выше документе:
MetaML [7] вдохновил и Template Haskell и MacroML, введя квази-цитирование и идею типизация объектного кода. Он был разработан в основном для операций с кодом и его исполнения в рантайме, так что это несколько отличающаяся от нашей область деятельности.
И о MacroML, так как без слов о нем картина не будет ясна:
В MacroML [6] было предложено использовать макросы времени компиляции для языка ML. Это имеет много общего с Template Haskell в смысле связывания имен в цитировании до раскрытия макросов. MacroML, кроме того, позволяет захватывать символы в месте применения макроса (это похоже на нашу функцию UseSiteSymbol()). И все это производится без необходимости отказываться от типизации цитат.
Макросы в MacroML ограничены конструированием кода из имеющихся частей, поиск декомпозиция и кода невозможны.
BLA>В общем конечно по сравнению с C# оно огого, но не боле.
Если убрать снобизм и предвзятость "в корман", и как следует разобраться в Немерле, то даже апологетам чистых ФЯ станет понятно, что Немерле как минимум достойный конкуретн.
Ну, а лично я полностью уверен, что Неперле превосходит Окамл и Хаскель. Как минимум Немерле значительно удобнее если рассматривать его как статически-типизированный, типобезопасный, объектно-ориентированный язык. Ведь ОО-возможности в нем позаимствованы из лидеров в этой области среди мэйнстрим языков (C#, Ява, С++).
VD>>В общем, Nemerle — это отличная работа! И будет очень жаль если она пройдет мимо мэйнстрима. При должной раскрутке и "техническом оснащении" (поддержке IDE, наличии полноценной помощи, книг и т.п.) он может прочно и на долго занять место лидера среди мэйнстрим
BLA>Кстати если под IDE понимаются все эти рефакторинги и интеллисенсы — то в чем вообще смысл?
Это отдельный вопрос. Мне вобщем-то окровенено мало интересно обсуждение этого вопроса с теми кто не видит нужны в IDE, интелисенсе и рефакторинге, так как лично я испытываю потребность в этих возможностях просто таки на чисто животном, интуитивном уровне. Такой спор для меня аналогичен спору на тему "нужен ли лифт в 16-ти этажном доме". Это просто очень удобно!
BLA>IDE как design-time metaprogramming явно и не имеет смысла и конфликтует с compile-time.
От IDE в первую очередь мне нужны средства ускоряющие написание, отладку и рефакторинг кода. Метапрограммирование тут как бы вовсе не причем. Хотя кое что из метапрограммирования мне в IDE тоже не помешала бы. Например, к оным можно отнести всякого рода дизайнеры. Так мне очень нравится изучать иерархию классов в дизайнере классов (если кто не видел оный в SV2005, то ближайшим аналогом будут UML-дизайнеры, хотя они несколько отличаются), а так же нравится пользоваться GUI-дизайренами.
BLA>Причем где-где, а на этом уровне (вбитие километров повторяющегося кода и тп) макросы по возможностям кроют с лихвой.
Макросы действительно способны устранить дублирование кода не понижая при этом других качеств кода. Но они не в силах заменить то же автодополнение при вводе, а я знайте ли, не люблю убивать массу времени на то, чтобы вспомнить или уточнить то как пишется тот или иной метод/класс/функция/т.п.
К тому же у интелисенса есть еще ряд премуществ. Одно из важнейших — это отсуствие необходимости сокращать названия идентификаторов. Плохая читабельность кода на Хаскеле и других ФЯ зачастую связанна с банальным пренебрежением к качеству и осмысленности идентификаторов. Это же повышает и сложность обучения. Ведь запоминать традиции вроде x::xs или даже h::t — это отдельный и не малый труд. И мне жаль тех апологетов ФЯ которые не понимают этого просто потому, что сами уже прошли через это.
BLA>Ну в самом деле — идеальный код не требует дублирования и необходимости сложной навигации просто в силу малой своей избыточности.
Хм. Эти слова сомнительны сразу по двум причинам.
1. Идиальный код — это то к чему
стремятся хорошие программисты. Тут сразу два ключевых слова.
Стремятся и
хорошие. Между тем не всегда удается написать идеальный код. Причем "не всегда" — это слова про хороших программистов. Начинающие же и плохие программисты создают идеальный код вообще очень редко. Так что возможности по навигации и рефакторингу нужных хотя бы для того, чтобы превращать не идеальный код в тот, что ближе к идеалу. Забавно, что этот процесс рекурсивен по своей природе. Один рефакторинг может привести к осознанию того, что нужен еще один. Да и со временем отношение к коду может измениться.
2. Код может быть большим не только из-за того, что он не идеален. Код банально может быть слишком объемным вследствие сложности решаемой задачи. Несомненно, грамотная декомпозиция способна сделать отдельные его участки простыми и понятными, но, черт побери, декомпозиция только увеличивает объем кода! Рано или поздно мы приходим к тому, объем проекта столь велик, что в нем становится сложно разораться не только без достойных средств навигаций, но и без средств визуализации вроде дизайнеров классов.
Я замечал, что апологеты ФЯ часто с пренебрежением относятся к данным вопросам, но мне кажется, что это их заблуждение. И сформировано оно возможно оттого, что они реально не решали с помощью своих любимых инструментов действительно объемных задач. ФЯ часто появляется где-то рядом с математикой или синтаксическим анализом. В этих областях функциональная декомпозиция, поднятая на высоких уровень в ФЯ действительно дает хороший эффект, но эти задачи не являются действительно объемными и легко делятся на относительно небольшие подзадачи. Связанность таких задач не очень высока. Между тем банальные примитивные финансовые программы приводят к огромным массивам тесно связанного кода. И в этих областях не использовать средства предоставляемые современными IDE — просто не размуно. Это все равно что добровольно вешать на себя гандикап.
BLA>Макросы в общем для этого в основном и сделаны (ну еще, конечно, чтобы откладывать вычисления, например, но это мелочи по сравнению).
BLA>Формально это кстати очень просто обосновывается — во время compile-time в любом случае больше информации, чтобы оставлять работу кодогрузчику на уровне пользователя ну и следовательно таких же возможностей как раньше уже в IDE не получишь. В рантайме еще больше, потому и IDE для динамических языков — это обычно одно название.
BLA>Ну я вообще к тому, что аутлайн, фолдинг, подсветка и replace c регекспами есть везде, а большего на метауровне и ненужно. А то лишь когнитивный диссонанс получается.
Однако "когнитивный диссонанс" звучит красиво. Хотя и совершенно не ясно о чем речь.
Отступы подсветка и replace — это минимум. Причем совершенно не достаточный для большинства людей привыкших полноценным IDE. Я не хочу спорить с тобой. Тебе может это и не надо. Но ты в меньшинстве. Заведи голосование на этом сайте и убедишься в этом.
VD>>языков общего назначения. При этом Васик мог бы занять нишу языка для прикладников и "домохазяек", С/С++ нишу битодробилок, а Nemerle займет нишу котрую сейчас занимают C# и С++, т.е. языка общего назначения для решения нетривиальных задач.
BLA>Как-то сомневаюсь. Скорее к тому моменту, когда бренд Nemerle раскрутится, на дотнете можно станет пускать нормально окамл и хаскель и немерлю придется туговато.
Ты видимо очень долго спал. И Окамл, и Хаскель давно прекрасно работают на дотнете. Вот тебе список ссылочек:
Haskell
Hugs98 for .NET
Haskell for .NET (using Mondrain for .NET) (Nigel Perry)
Haskell.net Project
Caml
F# (ML and Caml)
OCAMIL (Emmanuel Chailloux & Raphael.Montelatici)
А вот более полный список языков:
http://www.dotnetpowered.com/languages.aspx
Вот только, по-моему, во многом эти языки не дотягивают даже до C#. Например, ООП в них выглядит весьма странно и не удобно.
BLA>учитывая, что сейчас, например, большинство случаев отказа от них связано с отсутствием важных библиотек типа развивающегося и поддерживаемого гуя, а user- & codebase гораздо больше.
Ну, так какие там проблемы с библиотеками для вышеперечисленных языков?
Надо уметь смотреть правде в глаза. Языки вроде Окамла и Хаскеля просто не принимаются большинством программистов. Их любят только те, кто окончательно и бесповоротно проникся идеями ФЯ. Хаскель отпугивает своими манадами, полной ленивостью, отсутствием императивных конструкций и шифровальным стилем записи. Окамл кривой поддержкой ООП, отсутствием компонентности, непривычным синтаксисом. Схема и Лисп пугают тем, что нужно писать программы в АСТ.
Мне лично все равно будут ли апологеты ФЯ считать это фобиями, но это факт. Мэйнстрим не принял и врде ли примет большинство ФЯ.
Немерле же по сути являясь ФЯ умудряется достойно поддерживать и другие парадигмы. Даже в стиле старого доброго С на нем пишется без проблем.
BLA> Ну и еще один момент — дотнет — это вообще очень маленький сегмент всего IT и использовать языки, которые есть только на нем сильно менее целесообразно, чем те, что есть везде.
Кому как. Есть мнение, что управляемые среды вроде дотнета и Явы — это будущее программирования. Но это опять же отдельная тема, поднимавшаяся здесь не раз.
BLA>Ну и там для некоторых(большинства) нетривиальных задач как использовали пролог, лисп, APL и фортран, так и будут продолжать.
Для решения большинства задач, в том числе и не тривиальных, сегодня используются С++, Ява и C#. Это факт. Как раз Пролог и даже Лисп являются скорее исключением. Это языки используемые в узких нишах. Обычно в научных кругах. Я же говорю о Немерле как о претенденте на лидерство в области промышленного программирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
