КМВ>Авторы: КМВ> VladD2 КМВ> Kupaev
КМВ>Аннотация: КМВ>Пример C++ показывает, что индустрии нужны системы метапрограммирования — даже достаточно причудливая система шаблонов широко используется для вычислений во время компиляции. Эта статья является исследованием возможного внедрения техники метапрограммирования в индустриальную среду в более чистой форме. Мы, таким образом, фокусируемся на том, чтобы сделать нашу систему легкой в использовании для программистов, как пишущих, так и использующих макросы.
Почему у Nemerle нет будущего
-------------------------------
Основные проблемы Nemerle, мешающие ему стать распространенным языком:
1) "Предательство" синтаксиса
2) Упор на повышение "мощности" языка
3) Метапрограммирование (для п.2)
4) Смешение парадигм (для п.2)
В основе проблем лежат:
1) Преувеличение мыслительных способностей программистов, а и людей вообще. В реальности они довольно ограничены.
2) Преувеличение роли логического, рационального мышления. Человек мысли иррационально, эмоционально (увы и ах).
3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.
Подробно о проблемах:
1) Синтаксис Nemerle взяв за основу синтаксис C, тем не менее существенно от него отступает, причем без всякого разумного обоснования. Если бы синтаксис отличался радикально (как у Python, Ruby и др.) это было бы пол беды — проосто изучение языка стало бы путешествием в совершенно новый мир, пусть непривычный и даже чуток враждебный. Враг бывает достоин уважения и даже восхижения, но предатель — никогда. Все удачные (читай: получившие расространение) синтаксические приемники Си шли по пути расширения его синтаксиса, но, в отличии от Nemerle, не извращения, таковы C++, Java, Java-script, PHP, C#, даже Perl. Аргумент разработчиков Nemerle: синтаксис отличается, но люди легко его выучат. Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).
2) Программистам не хватает не "мощности", которую вполне можно упаковать в библиотеки и API, а надежности, защищенности и удобства. Такие ставшие "примитивными" возможности среды разработки, как подсветка синтаксиса, контекстная справка, переход по перекрестным сслыкам, InteliSence и т.п. экономят гораздо больше времени и нервных клеток, чем многие синтаксические навороты. Причина в том, что программы пишут живые люди, которые быстро утомляются, часто ошибаются, что-то забывают и т.д. Простота и лаконичность — вот чего ждут разработчики.
3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается). И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу, не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java). А ведь мир видал препроцессоры куда круче Nemerle-вского, в PL/I язык препроцессора по мощи не многим уступал самому целевому языку. Похоже, использование generic-ов (причем без typedef!) и Reflection вполне достаточная доза метапрограммирования в современных языках.
4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная) видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста. В лучшем случае труднопонимаемые детали будут задвинуты, в худшем будут служить причиной тонких, неуловимых ошибок и огромных проблем с чтением чужого кода. Вы пробовали изучать, к примеру, Пролог? Пока читаете описание и разбираешь простые примеры — все отлично. Как дело доходит до решения оригинальных задач и чтения реального кода, вот тут и понимаете как трудно переключиться в принципиально иную парадигму.
Приходится сделать неутешительный вывод: Nemerle — лишь новый красивый узорчатый листок на пышном дереве мертвых исследовательских языков где-то рядом с НУТ-ом (Новым Утопистом) и другими попытками объять необъятное.
По моему макры в том виде, в котором они есть в лиспе, неважно ложатся на сишный синтаксис — приходится прибегать к всяческим ухищрениям. В лиспе они естесвенны — это не какая то подпорка к языку, и даже не его продолжение — это сам язык. В Немерле же (подчеркну, ИМХО) этого не наблюдается.
С другой стороны, то что он есть имеет следствием то, что на функциональное программирование могут обратить внимание массы. Не знаю преимущество это или недостаток ;-)
Здравствуйте, lastochkin, Вы писали:
L>1) Синтаксис Nemerle взяв за основу синтаксис C, тем не менее существенно от него отступает, причем без всякого разумного обоснования.
Существенно? Это ты про то что типы указывают по другому?
Или про то что все есть выражение?
L>Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).
Предательский синтаксис это сильно... мне ниразу такие мысли в голову не приходили.
L>2) Программистам не хватает не "мощности",
Отучаемся говорить за всех.
L>которую вполне можно упаковать в библиотеки и API,
Только если есть метапрограммирование. Ибо иногда попадаются такие задачки что
L>а надежности, защищенности и удобства.
Этого в немерле больше чем в C#.
L>Такие ставшие "примитивными" возможности среды разработки, как подсветка синтаксиса, контекстная справка, переход по перекрестным сслыкам, InteliSence и т.п. экономят гораздо больше времени и нервных клеток, чем многие синтаксические навороты.
Это сейчас пишут. Правда оно еще сыро но уверен со временем все будет.
L>Причина в том, что программы пишут живые люди, которые быстро утомляются, часто ошибаются, что-то забывают и т.д. Простота и лаконичность — вот чего ждут разработчики.
Так немерле это дает в лучшем виде.
L>3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается).
Да брось ты. Человек думает совершенно иначе чем машина.
И воспринимает метакод очень легко.
L>И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу, не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java).
Генерики это не метапрограммирование. Для того чтобы быть метапрограммированием нужно быть полным по Тьюрингу...
Кстати шаблоны в С++ теоритически полны по Тьюрингу. Хотя на практике компиляторы не дают делать глубокую рекурсию. Вот шаблоны можно назвать метарограммированием но это метапрограммирование через зад автогеном. Не смотря на это на них много его пишу. Посмотри на boost.org
L>А ведь мир видал препроцессоры куда круче Nemerle-вского, в PL/I язык препроцессора по мощи не многим уступал самому целевому языку.
Я не знаю что было в PL/I но в немерле макросы пишутся на немерле без каких либо ограничений.
L>Похоже, использование generic-ов (причем без typedef!) и Reflection вполне достаточная доза метапрограммирования в современных языках.
Для большинства задач. Но если нарываемся на задачу которая не попадает в это большинство то все. Приехали...
Я однажды при разработке на C# нарвался на такую... пришлось решать копипастом.
А былобы метапрограммирование воспользовался бы им.
L>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная) видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста.
У меня такое впечатление что ты программистов совсем за дебилов держишь.
Хотя учитывая то что большинство людей в данной отрасли только называют себя программистами... но с такими в любом случае связыватся себе дороже.
L>В лучшем случае труднопонимаемые детали будут задвинуты, в худшем будут служить причиной тонких, неуловимых ошибок и огромных проблем с чтением чужого кода.
Не будут.
L>Вы пробовали изучать, к примеру, Пролог? Пока читаете описание и разбираешь простые примеры — все отлично. Как дело доходит до решения оригинальных задач и чтения реального кода, вот тут и понимаете как трудно переключиться в принципиально иную парадигму.
Нмерле на порядки ближе к привычным языкам чем пролог.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Согласен с пунктами 2 и 3, они должны быть очевидны любому инженеру, работавшему на саппорте больших программных комплексов.
1 и 4 — спорны, здесь можно успешно аргументировать за обе стороны. Хотя безусловно, С-шний синтаксис не самый удачный вариант как для метапрограммирования, так и для ФЯ.
Вот это, безусловно, основное... l> 3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.
Программа пишется в первую очередь для человека. Одна беда — человеки это не понимают, предпочитают вместо разбирательства в чужом коде назвать его "говном" и переписать, накатав cryptic code, который другой программист предпочтет вместо разбирательства, назвать... и так далее.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, lastochkin, Вы писали:
L>По моему макры в том виде, в котором они есть в лиспе, неважно ложатся на сишный синтаксис — приходится прибегать к всяческим ухищрениям. В лиспе они естесвенны — это не какая то подпорка к языку, и даже не его продолжение — это сам язык. В Немерле же (подчеркну, ИМХО) этого не наблюдается.
L>С другой стороны, то что он есть имеет следствием то, что на функциональное программирование могут обратить внимание массы. Не знаю преимущество это или недостаток
Массы, увы, так и не заинтересовались Lisp-ом (и его потомками вроде Schema) с весьма простым синтаксисом. Если бы не AUTOCAD с EMACSом Lisp вообще бы давно загнулся. Так что дело не в синтаксисе. Дело в сложности (непривычности) парадигмы.
Еще пример: 80% утверждающих что знают SQL никогда не ходили дальше 'SELECT * FROM Details WHERE OrderID=?' и дальше цикл перебора записей, а вложенные подзапросы их просто приводят в ступор. Может это и к лучшему. Какое там к черту декларативное программирование...
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, lastochkin, Вы писали:
L>>3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается). WH>Да брось ты. Человек думает совершенно иначе чем машина. WH>И воспринимает метакод очень легко.
Машина вообще не думает. Зато она ничего не забывает. Обращение по ссылке (и макро-подстановка) для нее операция дешевая. В отличии от человека, который на вопрос "Сколько тебе лет?", начинает судорожно вспоминать какой сейчас год и что унего записано в паспорте.
L>>И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу, не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java). WH>Генерики это не метапрограммирование. Для того чтобы быть метапрограммированием нужно быть полным по Тьюрингу... WH>Кстати шаблоны в С++ теоритически полны по Тьюрингу. Хотя на практике компиляторы не дают делать глубокую рекурсию. Вот шаблоны можно назвать метарограммированием но это метапрограммирование через зад автогеном. Не смотря на это на них много его пишу. Посмотри на boost.org
Очень много. Потомучто потом выкидывают и пишут заново.
L>>Похоже, использование generic-ов (причем без typedef!) и Reflection вполне достаточная доза метапрограммирования в современных языках. WH>Для большинства задач. Но если нарываемся на задачу которая не попадает в это большинство то все. Приехали... WH>Я однажды при разработке на C# нарвался на такую... пришлось решать копипастом. WH>А былобы метапрограммирование воспользовался бы им.
Какой-то процент задач вполне можно отдать на растерзания c'n'p ради ясности остальных около 100%.
L>>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная) видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста. WH>У меня такое впечатление что ты программистов совсем за дебилов держишь. WH>Хотя учитывая то что большинство людей в данной отрасли только называют себя программистами... но с такими в любом случае связыватся себе дороже.
Хочешь ты или нет, но если ты занимаешься реальной разработкой, то тебе придется читать чужой код, а кому-то придется — твой.
Я стараюсь следовать великому принципу, родившемуся еще на заре программизма: KISS — Keep It Simple, Stupied — делай проще, глупец.
L>>В лучшем случае труднопонимаемые детали будут задвинуты, в худшем будут служить причиной тонких, неуловимых ошибок и огромных проблем с чтением чужого кода. WH>Не будут.
|-] — это улыбка Будды
WH>Нмерле на порядки ближе к привычным языкам чем пролог.
Внешне.
Здравствуйте, lastochkin, Вы писали:
L>Массы, увы, так и не заинтересовались Lisp-ом (и его потомками вроде Schema) с весьма простым синтаксисом.
Я, скорее, имел в виду привычность синтаксиса. Вот и WolfHound пишет, что "Нмерле на порядки ближе к привычным языкам чем пролог.", подразумевая, видимо, под теми, кому ближе "большинство людей в данной отрасли (которые) только называют себя программистами".
L> Так что дело не в синтаксисе. Дело в сложности (непривычности) парадигмы.
Непривычности. Ну, конечно, дело не в одном только синтаксисе. Еще причина — учить что то новое лень. Пример с sql это подтверждает. Вот примерно такие задачи Немерле и пытается решить. Как мне кажется.
Здравствуйте, lastochkin, Вы писали:
L>Машина вообще не думает. Зато она ничего не забывает. Обращение по ссылке (и макро-подстановка) для нее операция дешевая. В отличии от человека, который на вопрос "Сколько тебе лет?", начинает судорожно вспоминать какой сейчас год и что унего записано в паспорте.
if, for, foreach, &&, ||... и многое другое в немерле макросы. Что в них не понятно? А может не понятен код типа $"var1 = $var1"? Так лично я его понял даже не заглядывая в документацию по немерле.
И что касается памяти человека: После определенной тренировки человек может запоминять буквально все что воспринимает через все известные и не очень органы чувств.
К тому же память человека очень хорошо востанавливается по ассациациям те человек может полностью что-то забыть но если ему подсунуть какойто намек на это то он очень быстро все вспоминает. Те если человек один раз запомнил макрос то дальше даже если он этот макрос забудет он его вспомнит сразу же после того как снова увидит.
L>Очень много. Потомучто потом выкидывают и пишут заново.
А ты вобще с этой библиотеокой дело имел?
L>Какой-то процент задач вполне можно отдать на растерзания c'n'p ради ясности остальных около 100%.
Ты же не знаешь что за задача правда? И не знаешь как бы ее решение при помощи макросов повлияло на весь остальной код.
Так я тебе скажу: Никак.
Те если прямо сейчас взять и переписать эту сборку на немерле остальой код даже перекомпилировать не придеться.
L>Хочешь ты или нет, но если ты занимаешься реальной разработкой, то тебе придется читать чужой код, а кому-то придется — твой. L>Я стараюсь следовать великому принципу, родившемуся еще на заре программизма: KISS — Keep It Simple, Stupied — делай проще, глупец.
Я этот принцип прекрасно знаю. Но если проще означает в 10 раз больше кода... то это "проще" превращается в массу проблем при поддержке.
Это факт.
Многие почемуто постоянно забывают про выделеное.
Пусть это будет просто:
просто, как только можно, но не проще.
(C) А. Эйнштейн
WH>>Нмерле на порядки ближе к привычным языкам чем пролог. L>Внешне.
Не только.
У немерле вычислительная модель очень сильно отличается от пролога.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lastochkin, Вы писали:
L>Почему у Nemerle нет будущего L>-------------------------------
L>Основные проблемы Nemerle, мешающие ему стать распространенным языком: L>1) "Предательство" синтаксиса L>2) Упор на повышение "мощности" языка L>3) Метапрограммирование (для п.2) L>4) Смешение парадигм (для п.2)
L>В основе проблем лежат: L>1) Преувеличение мыслительных способностей программистов, а и людей вообще. В реальности они довольно ограничены.
К счастью не все тупые . Иногда встречаю умных на жизненном пути.
L>2) Преувеличение роли логического, рационального мышления. Человек мысли иррационально, эмоционально (увы и ах).
Ммм. К чему это?
L>3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.
При чем здесь Немерле?
L>Подробно о проблемах: L>1) Синтаксис Nemerle взяв за основу синтаксис C, тем не менее существенно от него отступает, причем без всякого разумного обоснования. Если бы синтаксис отличался радикально (как у Python, Ruby и др.) это было бы пол беды — проосто изучение языка стало бы путешествием в совершенно новый мир, пусть непривычный и даже чуток враждебный. Враг бывает достоин уважения и даже восхижения, но предатель — никогда. Все удачные (читай: получившие расространение) синтаксические приемники Си шли по пути расширения его синтаксиса, но, в отличии от Nemerle, не извращения, таковы C++, Java, Java-script, PHP, C#, даже Perl. Аргумент разработчиков Nemerle: синтаксис отличается, но люди легко его выучат. Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).
Я такого никогда не чувствовал.
Наоборот, я подумал "Наконец-то функциональный язык с нормальным синтаксисом!".
Единственное что напрягает "mutable" для переменных (но это видимо специально, чтобы не хотелось использовать ), я бы предпочел более короткое "val" как в Scala.
L>2) Программистам не хватает не "мощности", которую вполне можно упаковать в библиотеки и API, а надежности, защищенности и удобства.
Мне надо и то и другое.
А на чем эти самые библиотеки и API писать?
L> Такие ставшие "примитивными" возможности среды разработки, как подсветка синтаксиса, контекстная справка, переход по перекрестным сслыкам, InteliSence и т.п. экономят гораздо больше времени и нервных клеток, чем многие синтаксические навороты. Причина в том, что программы пишут живые люди, которые быстро утомляются, часто ошибаются, что-то забывают и т.д. Простота и лаконичность — вот чего ждут разработчики.
Именно. Лаконичность. Java без синтаксического сахара — это ужас.
Пусть сложность будет запрятана глубоко в метабиблиотеку.
L>3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается). И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу, не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java).
Правильно, чем проще язык, тем легче научить ему массу посредственных людей, которые будут писать посредственный код.
Но зато им можно мало платить, т.к. их легко заменить.
В C++ оно сведено к минимуму ? Посмотрите boost.
L> А ведь мир видал препроцессоры куда круче Nemerle-вского, в PL/I язык препроцессора по мощи не многим уступал самому целевому языку.
А он был типобезопасным?
На LINQ на нем можно было сделать?
А Late binding?
L>Похоже, использование generic-ов (причем без typedef!) и Reflection вполне достаточная доза метапрограммирования в современных языках.
Отсутствие typedef это ужас .
L>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная) видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста.
Смотря какого.
Мое мнение: Оставьте метапрограммирование разработчикам библиотек, я простые программисты пусть пользуются результатами их труда.
Писать обычный код на Nemerle ИМХО не сложнее чем на C#.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Единственное что напрягает "mutable" для переменных (но это видимо специально, чтобы не хотелось использовать ), я бы предпочел более короткое "val" как в Scala.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, lastochkin, Вы писали:
L>>Машина вообще не думает. Зато она ничего не забывает. Обращение по ссылке (и макро-подстановка) для нее операция дешевая. В отличии от человека, который на вопрос "Сколько тебе лет?", начинает судорожно вспоминать какой сейчас год и что унего записано в паспорте. WH>if, for, foreach, &&, ||... и многое другое в немерле макросы. Что в них не понятно? А может не понятен код типа $"var1 = $var1"? Так лично я его понял даже не заглядывая в документацию по немерле.
ПОКА эти макросы часть СТАНДАРТА — все хорошо, ПОКА...
WH>И что касается памяти человека: После определенной тренировки человек может запоминять буквально все что воспринимает через все известные и не очень органы чувств.
Древний миф. Память человека сжимает опыт с потерями (как при запоминании, так и при извлечении), их 3 вида: опущение, обобщение, искажение... впрочем это уже другая тема.
WH>К тому же память человека очень хорошо востанавливается по ассациациям те человек может полностью что-то забыть но если ему подсунуть какойто намек на это то он очень быстро все вспоминает. Те если человек один раз запомнил макрос то дальше даже если он этот макрос забудет он его вспомнит сразу же после того как снова увидит.
Ты оптимист и преувеличиваешь свои и чужие силы. Это пройдет.
L>>Очень много. Потомучто потом выкидывают и пишут заново. WH>А ты вобще с этой библиотеокой дело имел?
Это шутка, согласен — не очень удачная. Виноват, не имел, только просмотрел описание.
И что в ней есть такого чего нет в C# 2.0 (причем более гладко), не говоря уж про 3.0? Nemerle вроде как конкурент C#, а не C++.
Осмысливать опыть и включать новые элементы в СТАНДАРТНУЮ библиотеку — правильный путь. А вот давать обезьяне гранату — нет.
L>>Какой-то процент задач вполне можно отдать на растерзания c'n'p ради ясности остальных около 100%. WH>Ты же не знаешь что за задача правда? И не знаешь как бы ее решение при помощи макросов повлияло на весь остальной код. WH>Так я тебе скажу: Никак. WH>Те если прямо сейчас взять и переписать эту сборку на немерле остальой код даже перекомпилировать не придеться.
Я говорю не про влияние на другой код, а на понятность разработанного с помошь мета-. Хорошо, ты знаешь когда использовать эту мощь, а когда нет. Представь, что кто-то молодой-да-ранний начал юзать макросы к месту и не кместу, от чего стало казаться, что программа написана на branfuck-е и тебе поручили с этим разобраться, ы?
L>>Хочешь ты или нет, но если ты занимаешься реальной разработкой, то тебе придется читать чужой код, а кому-то придется — твой. L>>Я стараюсь следовать великому принципу, родившемуся еще на заре программизма: KISS — Keep It Simple, Stupied — делай проще, глупец. WH>Я этот принцип прекрасно знаю. Но если проще означает в 10 раз больше кода... то это "проще" превращается в массу проблем при поддержке. WH>Это факт. WH>Многие почемуто постоянно забывают про выделеное.
Иной раз лучше 1000 строк простого кода, чем 100 супер-навороченного.
Здравствуйте, lastochkin, Вы писали:
L>В основе проблем лежат: L>1) Преувеличение мыслительных способностей программистов, а и людей вообще. В реальности они довольно ограничены.
Так почему вообще кто-то должен рассчитывать на ограниченных? Только то, что ограниченные обезьянки стоят дёшево ещё не делает категорическим императивом требование угождать обезьянкам. Есть (и прекрасно себя зарекомендовали) бизнес-модели, построенные на привлечении самых лучших и самых дорогостоящих кадров. Да, в программировании это пока что редкость, но в других отраслях (например, у банкиров) это норма. Так почему, с какой такой радости IT-индустрия перед обезьянками обязана "ку" делать?!?
L>2) Преувеличение роли логического, рационального мышления. Человек мысли иррационально, эмоционально (увы и ах).
И метапрограммирование этому способу мышления очень даже способствует, между прочим.
L>3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.
Верно. И тут как раз и нужен язык с неограниченным сверху уровнем абстракций. Язык, который можно было бы сделать близким к естественному человеческому языку в каждой из предметных областей.
L>Подробно о проблемах: L> Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).
Тогда и синтаксис C# после Жабки — "предательство".
L>2) Программистам не хватает не "мощности", которую вполне можно упаковать в библиотеки и API,
НЕЛЬЗЯ. Невозможно СЕМАНТИЧЕСКУЮ сложность засунуть в API. Принципиально!!!
L> Простота и лаконичность — вот чего ждут разработчики.
И как её без метапрограммирования добиться?
L>3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается).
Чушь. Метапрограммирование, употреблённое к месту, позволяет очень легко разделить степени минимально допустимого понимания. Прикладник будет читать и понимать терминологию и семантику своей предметной области, и плевать ему на то, как оно внутри сделано. Разработчик DSL-ей будет читать код макросов и понимать всякие там оптимизации, не зная ни шиша о предметной области (ни его это дело). Программист системного уровня будет думать про файлики с сокетами, и плевать ему на DSL-ы и на предметную область и тем более на всякие там GUI.
L> И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу, не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java).
Только вот жабистый мир так по метапрограммированию истосковался, что порождает таких уродцев, как Hibernate. А многие носятся с аспектно-ориентированным программированием, с контрактами и прочими смешными частностями.
L> А ведь мир видал препроцессоры куда круче Nemerle-вского, в PL/I язык препроцессора по мощи не многим уступал самому целевому языку. Похоже, использование generic-ов (причем без typedef!) и Reflection вполне достаточная доза метапрограммирования в современных языках.
Недостаточная. Когда есть только это, в любом сложном проекте сразу появляется с десяток внешних препроцессоров.
L>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная) видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста.
Не программиста, а обезьянку. Обезьянок надо уволить и никогда больше на них не рассчитывать. Пусть улицы подметают. Бизнес-модель "шапками нах закидаем!" пора отправить на помойку истории.
Здравствуйте, lastochkin, Вы писали:
L>Еще пример: 80% утверждающих что знают SQL никогда не ходили дальше
Да кого блин интересуют проблемы 80% недочеловеков?!? То, что так исторически сложилось, что их принято употреблять в IT-индустрии — это просто глюк. В других индустриях это редкость. Пора забыть про обезьянок! Индустрия без них обойдётся!
Здравствуйте, lastochkin, Вы писали:
L>Машина вообще не думает. Зато она ничего не забывает. Обращение по ссылке (и макро-подстановка) для нее операция дешевая. В отличии от человека, который на вопрос "Сколько тебе лет?", начинает судорожно вспоминать какой сейчас год и что унего записано в паспорте.
Поздравляю! Восхитительный пример!
Вот как раз такой язык и нужен, где на вопрос тупой машины про "сколько тебе лет" можно смело отвечать — "родился я в один год с В. И. Лениным".
WH>>У меня такое впечатление что ты программистов совсем за дебилов держишь. WH>>Хотя учитывая то что большинство людей в данной отрасли только называют себя программистами... но с такими в любом случае связыватся себе дороже. L>Хочешь ты или нет, но если ты занимаешься реальной разработкой, то тебе придется читать чужой код, а кому-то придется — твой.
Дебилам — не придётся. И мне код дебилов редко приходится читать — стараюсь с ними не связываться.
L>Я стараюсь следовать великому принципу, родившемуся еще на заре программизма: KISS — Keep It Simple, Stupied — делай проще, глупец.
Так что может быть проще метапрограммирования? Это ведь и есть чистейшая реализация этого принципа — скрывать все детали, показывать только то, что нужно.
Здравствуйте, lastochkin, Вы писали:
WH>>Это факт. WH>>Многие почемуто постоянно забывают про выделеное. L>Иной раз лучше 1000 строк простого кода, чем 100 супер-навороченного.
А если это 1000 строк навороченного кода? Пусть там даже одни только примитивнейшие конструкции a la Python, и каждая строчка читается как песня, но логика за всем этим та-акая сложная, что лучше сразу вешаться.
В таких ситуациях и нужно метапрограммирование — сначала создаёшь язык, потом на нём как можно более просто и понятно описываешь сложную логику.
Вот скажи, тебе что приятнее и понятнее читать — EBNF, или написанный на Си конечный автомат, из этого самого EBNF сделанный? Тебе проще читать XML-описание виджетов на гуёвой формочке, или C++-ный код поверх кошмарного MFC?
Здравствуйте, CopyPaste, Вы писали:
CP>Бизнес-модель "шапками нах закидаем!" пора отправить на помойку истории.
Да, вместе с бизнес-моделью "предложим откат знакомому чиновнику" желательно бы.
Здравствуйте, lastochkin, Вы писали:
L>Основные проблемы Nemerle, мешающие ему стать распространенным языком: L>1) "Предательство" синтаксиса
Сильно сказано Главное — сочувствующие сразу начали кивать головой, типа "да, да, они нас предали, они все предатели, вот оно как"
Забавно, но примерно такое же коварство было совершено плюсами в отношении C. Тогда были попраны устои понимания производительности. Как же, ведь виртуальные метода значительно медленнее, а дополнительный и главное, О! Боже! скрытый параметр this нагружает стек и способен привести к его переполнению.
Но кто-то мудрый заметил: любите своих внуков, они отомстят вашим детям. И дедушка C был отомщён. Внучка Джава и её младший брат C# воздали папе по праву, предав родителя и осквернив единственно верную концепцию управления памятью с помощью new и delete.
Теперь на сцене появляется мутант N и кидает всех. Просто всех! Даже перл!
Осталось только выяснить не являются ли мутации в N исправлением ошибок, которые были совершны 30 лет назад дедушкой.
L>2) Упор на повышение "мощности" языка
"Мощность" в кавычках — синоним монструозности. Таким, кстати, был PL/I. Многословным и монстрообразным. Мощность N в действительно уникальном, правильно угаданном сочетании современных познаний о программировании.
L>3) Метапрограммирование (для п.2)
Метапрограммирование позволяет свести многие вещи к декларативности. В свою очередь, декларативность на сегодня единственный не исчерпавщий себя путь достижения краткости и лаконичности кода. В условиях моей прогрессирующей лени, простой и лаконичный прикладной код является тем идолом, которому я готов молиться и приносить всяческие жертвы. Получается, что исчерпав все существующие сегодня средства, метапрограммирование является чуть ли не единственным средством для продвижения вперёд. Даже такие вещи как AOP, которые где-то застряли на пол пути и всё никак не могут получить должного развития и применения, щёлкаются средствами метапрограммирования как семечки.
L>4) Смешение парадигм (для п.2)
Это как раз очень хорошо. Указатель на функцию существовал ещё в C и никто пока на это не жаловался. Функции высшего порядка, всякие лямбды и замыкания являются лишь синтаксическим сахаром для указателей на функции. Где здесь противоречие я в упор не вижу
L>Подробно о проблемах: L>Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).
Именно эмоции. Ничего больше. Мне самому кое-что не нравится, например, if/else, но я понимаю, что я пока просто ньюб. К тому же большинство "предательств" выправляется пространстовм имён Nemerle.Imperative. Но, зато, для того, чтобы оценить, например, list comprehension оказалось достаточно его одного осознанного применения.
L>2) Программистам не хватает не "мощности", которую вполне можно упаковать в библиотеки и API, а надежности, защищенности и удобства. Такие ставшие "примитивными" возможности среды разработки, как подсветка синтаксиса, контекстная справка, переход по перекрестным сслыкам, InteliSence и т.п. экономят гораздо больше времени и нервных клеток, чем многие синтаксические навороты. Причина в том, что программы пишут живые люди, которые быстро утомляются, часто ошибаются, что-то забывают и т.д. Простота и лаконичность — вот чего ждут разработчики.
Как известно, полезный выхлоп различных разработчиков может различаться в десять раз. Тем кто толпится в самом низу всё равно на чём программировать, лишь бы были, как ты правильно заметил, удобная среда с кнопкой Copy/Paste. Вчера они писали на VB, сегодня на C#, завтра будут с таким же успехом использовать copy/paste в Немерле. Они как не понимали как всё это работает, так и не будут понимать, потому что не дано. Поможет ли N тем, кто находится на верхней ступеньке? Скорее всего да. И не исключено, что разрыв увеличится с десяти, до, например, двадцати раз.
L>3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается).
VB 6 был насквозь пронизан COM'ом. COM для понимания и изучения ещё та дрянь. Тем не менее наиболее интенсивно COM компоненты использовали именно те, кто зачастую даже не догадывался о существовании COM. Я говорю о VB программистах. Тоже самое будет и с макросами.
L>И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу, не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java).
В Java уже присутствует, но это всё мелочи. Настоящая причина не просто в сложности, а в размерах этой сложности. Реализация таких вещей как квази-цитирование уменьшает сложность метапрограммирования на порядки, по сравнению, например, с комбинацией из рефлекшина и эмита. Порог вхождения всё ещё высок, но он уже достижим, а это принципиальная разница.
L>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная) видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста. В лучшем случае труднопонимаемые детали будут задвинуты, в худшем будут служить причиной тонких, неуловимых ошибок и огромных проблем с чтением чужого кода. Вы пробовали изучать, к примеру, Пролог? Пока читаете описание и разбираешь простые примеры — все отлично. Как дело доходит до решения оригинальных задач и чтения реального кода, вот тут и понимаете как трудно переключиться в принципиально иную парадигму.
Читабельность зависит от парадигмы в меньшей степени, если, конечно, парадигма сама по себе нечитабельна по определению. Больше всего читабельность зависит от объёма кода, его запутанности, от форматирования и следования соглашениям по именованию. Новая парадигма является припятствием для изучения языка и определённо увеличивает порог вхождения. Это правда. Но как раз здесь проявляется сильная сторона гибридов. Пока я не осознал и не проникся новыми парадигмами я могу продолжать кодировать в старом, привычном стиле. В своё время это был очень серьёзный плюс плюсов (простите, за каламбурчик). Понимание ООП приходило не сразу, но на плюсах можно было писать практически ничего об этом не зная.
L>Приходится сделать неутешительный вывод: Nemerle — лишь новый красивый узорчатый листок на пышном дереве мертвых исследовательских языков где-то рядом с НУТ-ом (Новым Утопистом) и другими попытками объять необъятное.
Вполне возможно. Могу лишь сказать, что ни я ни ты не являемся тем самым Предсказамусом, который может это настрадать. Сегодня судьбу языков определяют большие дяди вроде MS и Sun. Насколько в это может вмешаться комьюнити пока никто не знает. Может быть и может Одно ясно на 100% — Немерле, как язык программирования, однозначно можно назвать языком программирования будущего. Будет ли это сам N, его клоны или сворованные идеи и реализации уже не так важно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Осталось только выяснить не являются ли мутации в N исправлением ошибок, которые были совершны 30 лет назад дедушкой.
Мне так не кажется (что это исправление ошибок).
N — очередной этап развития, скрещивающий C# с функциональными возможностями.
C небезопасен by design.
Потому что предназначен для низкоуровнего системного программирования и есть по сути структурный ассемблер.
Да, в наше время писать на нем что-то мало-мальски большое — ужас.
Но тем не менее для кусков кода где надо выжать максимум он оправдан.
L>>2) Упор на повышение "мощности" языка
IT>"Мощность" в кавычках — синоним монструозности. Таким, кстати, был PL/I. Многословным и монстрообразным. Мощность N в действительно уникальном, правильно угаданном сочетании современных познаний о программировании.
+1
L>>3) Метапрограммирование (для п.2)
IT>Метапрограммирование позволяет свести многие вещи к декларативности. В свою очередь, декларативность на сегодня единственный не исчерпавщий себя путь достижения краткости и лаконичности кода. В условиях моей прогрессирующей лени, простой и лаконичный прикладной код является тем идолом, которому я готов молиться и приносить всяческие жертвы. Получается, что исчерпав все существующие сегодня средства, метапрограммирование является чуть ли не единственным средством для продвижения вперёд. Даже такие вещи как AOP, которые где-то застряли на пол пути и всё никак не могут получить должного развития и применения, щёлкаются средствами метапрограммирования как семечки.
+1
L>>4) Смешение парадигм (для п.2)
IT>Это как раз очень хорошо. Указатель на функцию существовал ещё в C и никто пока на это не жаловался. Функции высшего порядка, всякие лямбды и замыкания являются лишь синтаксическим сахаром для указателей на функции. Где здесь противоречие я в упор не вижу
Не совсем просто синтаксический сахар. Для того чтобы нормально сделать замыкания нужна сборка мусора.
L>>Подробно о проблемах: L>>Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).
IT>Именно эмоции. Ничего больше. Мне самому кое-что не нравится, например, if/else, но я понимаю, что я пока просто ньюб.
Это от того, что это выражение, которое должно всегда иметь значение, а не предложение. Как "(x > y) ? x : y" в C/C++.
Довольно типично для функц языков. А так есть "when".
IT> К тому же большинство "предательств" выправляется пространстовм имён Nemerle.Imperative. Но, зато, для того, чтобы оценить, например, list comprehension оказалось достаточно его одного осознанного применения.
Ну еще бы .
Программисты на Lisp,Python и прочих Haskell уже давно вовсю использовали.
"А мужики то не знали" (c) реклама
L>>2) Программистам не хватает не "мощности", которую вполне можно упаковать в библиотеки и API, а надежности, защищенности и удобства. Такие ставшие "примитивными" возможности среды разработки, как подсветка синтаксиса, контекстная справка, переход по перекрестным сслыкам, InteliSence и т.п. экономят гораздо больше времени и нервных клеток, чем многие синтаксические навороты. Причина в том, что программы пишут живые люди, которые быстро утомляются, часто ошибаются, что-то забывают и т.д. Простота и лаконичность — вот чего ждут разработчики.
IT>Как известно, полезный выхлоп различных разработчиков может различаться в десять раз. Тем кто толпится в самом низу всё равно на чём программировать, лишь бы были, как ты правильно заметил, удобная среда с кнопкой Copy/Paste. Вчера они писали на VB, сегодня на C#, завтра будут с таким же успехом использовать copy/paste в Немерле. Они как не понимали как всё это работает, так и не будут понимать, потому что не дано. Поможет ли N тем, кто находится на верхней ступеньке? Скорее всего да. И не исключено, что разрыв увеличится с десяти, до, например, двадцати раз.
+1
L>>Приходится сделать неутешительный вывод: Nemerle — лишь новый красивый узорчатый листок на пышном дереве мертвых исследовательских языков где-то рядом с НУТ-ом (Новым Утопистом) и другими попытками объять необъятное.
IT>Вполне возможно. Могу лишь сказать, что ни я ни ты не являемся тем самым Предсказамусом, который может это настрадать. Сегодня судьбу языков определяют большие дяди вроде MS и Sun. Насколько в это может вмешаться комьюнити пока никто не знает. Может быть и может
Не фига себе дяди определяют?
А Perl, Python, PHP, Ruby?
Здравствуйте, Андрей Хропов, Вы писали:
IT>>Это как раз очень хорошо. Указатель на функцию существовал ещё в C и никто пока на это не жаловался. Функции высшего порядка, всякие лямбды и замыкания являются лишь синтаксическим сахаром для указателей на функции. Где здесь противоречие я в упор не вижу
АХ>Не совсем просто синтаксический сахар. Для того чтобы нормально сделать замыкания нужна сборка мусора.
Как-то же в Паскале делали вложенные методы?
IT>>Именно эмоции. Ничего больше. Мне самому кое-что не нравится, например, if/else, но я понимаю, что я пока просто ньюб. АХ>Это от того, что это выражение, которое должно всегда иметь значение, а не предложение. Как "(x > y) ? x : y" в C/C++. АХ>Довольно типично для функц языков. А так есть "when".
Меня немного другое напрягает. В процессе набивки кода я постоянно жму компиляцию. Это у меня работает как сохранение изменений плюс проверка правильности набитого, чтобы потом не возвращаться назад. if/else требует возврата значений того же самого типа в обоих ветках, по-этому, пока работаешь над длинным if, приходится вбивать в else временную заглушку.
IT>> К тому же большинство "предательств" выправляется пространстовм имён Nemerle.Imperative. Но, зато, для того, чтобы оценить, например, list comprehension оказалось достаточно его одного осознанного применения.
АХ>Ну еще бы . АХ>Программисты на Lisp,Python и прочих Haskell уже давно вовсю использовали. АХ>"А мужики то не знали" (c) реклама
Дело не в не знали, а в том, что такое знание оказывается называется предательством.
IT>>Вполне возможно. Могу лишь сказать, что ни я ни ты не являемся тем самым Предсказамусом, который может это настрадать. Сегодня судьбу языков определяют большие дяди вроде MS и Sun. Насколько в это может вмешаться комьюнити пока никто не знает. Может быть и может
АХ>Не фига себе дяди определяют? АХ>А Perl, Python, PHP, Ruby?
Это всё больше относится к юниксовому хозяйству. Кстати, да, там всё довольно демократичнее. Но на Windows платформах всё не так весело.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
АХ>>Не совсем просто синтаксический сахар. Для того чтобы нормально сделать замыкания нужна сборка мусора.
IT>Как-то же в Паскале делали вложенные методы?
Это не замыкания. В замыкании важна не вложеность, а сохранение контекста, причем и вне метода. В паскале если отдать адрес вложенного метода наружу то в локальных переменных метода родителя получим мусор:
program tst;
type pfunc = function() : integer;
function fget(n : integer) : pfunc;
function lget() : integer;
begin
lget := n;
end;
begin
fget := @lget;
end;
var func : pfunc;
begin
func := fget(1);
writeln(func());
func := fget(1234);
writeln(func());
end.
такая программа выводит мусор, так как локальный n не запоминается, в языках же подерживающих замыкания n запомнится и результат будет правильный.
Здравствуйте, Андрей Хропов, Вы писали:
CP>>Бизнес-модель "шапками нах закидаем!" пора отправить на помойку истории. АХ>Да, вместе с бизнес-моделью "предложим откат знакомому чиновнику" желательно бы.
Будете смеяться, но эти модели зачастую порождаются одна другой. По крайней мере я это лично наблюдал раза два.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Меня упорно обвиняют не в тех греха, которые я совершил
Я вовсе ничего не иvею против возможностей Nemerle, я "клевещу" исключительно на род человеческий, утверждая:
1) Непоследовательность в синтексисе будет мешать распространению Nemerel из-за особенносте человеческой психики. Но польских аспирантов видно просто перло от креатиффа.
2) "Мощь" либо не бутет востребована, либо будет использоваться не к месту и не по назначению, опять-таки из-за ограниченности человеческих способностей. О том, что она может быть применена с большой с пользой, я не спорю.
3) При разработке реальтных проектов (крупных, с большим кол-вом участников), нужна не столько "мощь" инструментальных средств, сколько дисциплина, контроль и ограничения — опять из-за слабости человеческого восприятия и слабых коммуникационных способностей.
Не Nemerle первы, не он последний, его заявка на mainstream (учитывая CLR, C-like синтаксис) не вполне состоятельная, а маргинальных языков создано и так достаточно.
Здравствуйте, lastochkin, Вы писали:
L>Меня упорно обвиняют не в тех греха, которые я совершил
Никто тебя ни в чём не обвиняет. Просто есть не согласные с твоим мнением, вот и всё.
L>Я вовсе ничего не иvею против возможностей Nemerle, я "клевещу" исключительно на род человеческий, утверждая:
В чём то я с тобой согласен. Как контрактнику мне доводилось работать в разных командах, в больших и маленьких, сильных и слабых. То о чём ты говоришь относится в большей степени к большим и слабым командам, когда попытки достичь результата направлены исключительно на увеличение количества землекопов. Но, как известно, принцип брать не уменьем, а числом в программировании плохо работает.
L>Не Nemerle первы, не он последний, его заявка на mainstream (учитывая CLR, C-like синтаксис) не вполне состоятельная, а маргинальных языков создано и так достаточно.
Кстати, есть ещё одна область, точнее даже не область, а зияющая дыра. Это — DSL. Майкрософт сейчас занимается какими-то исследованиями, но боюсь, что на Немерле это делать будет всё равно проше.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, FR, Вы писали:
FR>такая программа выводит мусор, так как локальный n не запоминается, в языках же подерживающих замыкания n запомнится и результат будет правильный.
С мусором бороться вполне можно, но тогда это приведёт к проблеме типа циклических ссылок, когда не понятно кто кого первый должен удалять.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, CopyPaste, Вы писали:
L>>Хочешь ты или нет, но если ты занимаешься реальной разработкой, то тебе придется читать чужой код, а кому-то придется — твой.
CP> Дебилам — не придётся. И мне код дебилов редко приходится читать — стараюсь с ними не связываться.
Здравствуйте, IT, Вы писали:
FR>>такая программа выводит мусор, так как локальный n не запоминается, в языках же подерживающих замыкания n запомнится и результат будет правильный.
IT>С мусором бороться вполне можно, но тогда это приведёт к проблеме типа циклических ссылок, когда не понятно кто кого первый должен удалять.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>такая программа выводит мусор, так как локальный n не запоминается, в языках же подерживающих замыкания n запомнится и результат будет правильный.
IT>С мусором бороться вполне можно, но тогда это приведёт к проблеме типа циклических ссылок, когда не понятно кто кого первый должен удалять.
Циклические ссылки тоже можно разрулить но в результате получится тот же GC
Здравствуйте, Lloyd, Вы писали:
IT>>С мусором бороться вполне можно, но тогда это приведёт к проблеме типа циклических ссылок, когда не понятно кто кого первый должен удалять.
L>В паскале? Как?
В Паскале скорее всего никак.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Скажи, а кроме глословных заявлений ты в силах что-то сказать? Ну, там обосновать свои слова. Привести факты. А то ты очень громко вещаещь, но все твои слова пустой звук. Вот, к примеру, откуда ты взял "Непоследовательность в синтексисе"? Обоснуй, пожалуйста это утверждение. Приведи примеры. Глядишь если они окажутся обоснованными, то мы убедим авторов языка и исправим непоследовательност. Ну, а если это просто твои догадки, то ты так и скажи.
Еще интересно было бы послушать про "маргинальность". Ведь с тем же успехом можно утверждать, что это ты и твои слова маргинальны (и не безосновательно, надо сказать). И чем ты докажешь, что ты не верблюд?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>С сайта Немерле: L>[quote] L>All the people who consider Nemerle syntax odd, compared to C#, are referred to the Haskell and/or Lisp manuals. L>[/quote]
Не надо приводить не относящихся к делу. Примеры не последовательности в студию. Если примеров нет, то не стоит повтоять этот домысел вновь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CopyPaste, Вы писали:
WH>>>Это факт. WH>>>Многие почемуто постоянно забывают про выделеное. L>>Иной раз лучше 1000 строк простого кода, чем 100 супер-навороченного.
CP> А если это 1000 строк навороченного кода? Пусть там даже одни только примитивнейшие конструкции a la Python, и каждая строчка читается как песня, но логика за всем этим та-акая сложная, что лучше сразу вешаться.
CP> В таких ситуациях и нужно метапрограммирование — сначала создаёшь язык, потом на нём как можно более просто и понятно описываешь сложную логику.
CP> Вот скажи, тебе что приятнее и понятнее читать — EBNF, или написанный на Си конечный автомат, из этого самого EBNF сделанный?
Проще читать описание, сделанное на известном генераторе парсеров YACC, а не написанное самоделкиным угребище на макросах.
CP> Тебе проще читать XML-описание виджетов на гуёвой формочке, или C++-ный код поверх кошмарного MFC?
Проще читать С++ный код поверх кошмарного MFC (кстати, это совсем не сложно), чем столкнуться с хреново документированным описанием гуя на собственном языке, который считай что не документирован вообще.
Кстати, если это сообщение читают сотрудники компании CQG — загляните в директорию client/flo, и вы сможете увидеть такой самопальный "язык" воочию. Я еще не видел ни одного спеца, который сталкиваясь по работе со вставкой на FLO, не начинал материться (на нем описываются GOC-и, а они сами по себе штуки прикольные ). К счастью, его написал и пользовал всего один самоделкин, так что вероятность встретить FLO в исходниках клиента CQG невысока.
Ну короче, я хорошо представляю себе, что было бы, попадись Брайану Беллу, который эту дурь FLO написал, язычок типа Немерле (выглядит этот Брайан, кстати, один в один как сумасшедший ученый из фильма "назад в будущее") . Его имя и так было вместо ругательства в московском офисе — он очень творчески управлялся с темплейтами и COM-классами, а уж с таким пулеметом как немерле точно пропал бы дом, зуб даю .
Так что у нас в конторе Немерле не будет. Мы жить хотим. Вдруг в ком-нибудь неожиданно проснется талант Брайана Белла?
Здравствуйте, VladD2, Вы писали:
VD>Не надо приводить не относящихся к делу. Примеры не последовательности в студию. Если примеров нет, то не стоит повтоять этот домысел вновь.
Я не отвечал на вопрос "где примеры последовательности". Мои слова всего лишь повод задуматься: во-первых, есть люди, которым не нравится синтаксис Немерле именно своей нечеткостью, во-вторых, это люди определенного круга, в-третьих, на официальном сайте не дается ни опровержения, ни согласия с этим замечанием, подчеркивая, мол "есть мнение".
Т.е. примеры ничего не скажут — кому то они покажут, что синтаксис нечеткий (непоследовательность — немного не то слово), кому то нет.
Здравствуйте, Gaperton, Вы писали:
CP>> Вот скажи, тебе что приятнее и понятнее читать — EBNF, или написанный на Си конечный автомат, из этого самого EBNF сделанный? G>Проще читать описание, сделанное на известном генераторе парсеров YACC, а не написанное самоделкиным угребище на макросах.
Что делать, если для желаемого dsl-я нет известного инструмента?
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Gaperton, Вы писали:
CP>>> Вот скажи, тебе что приятнее и понятнее читать — EBNF, или написанный на Си конечный автомат, из этого самого EBNF сделанный? G>>Проще читать описание, сделанное на известном генераторе парсеров YACC, а не написанное самоделкиным угребище на макросах.
L>Что делать, если для желаемого dsl-я нет известного инструмента?
Отвечаю. Если нет известного инструмента для чего бы то ни было, не только DSL, то либо обходятся без инструмента — гражданскими средствами, либо пишут свой инструмент. Содержательно, да? Ну, так какой вопрос, такой и ответ.
Могу сказать про себя — я в таких случаях делал свой парсер и свою виртуальную машину. Благо что ФОРТ-машина, как и парсеры, делается элементарно, быстро и на автомате — не успеешь сказать "немерле". DSL-и были очень специфические, это были языки описания торговых систем и преобразований временных рядов, и для них не было ну совершенно никакого известного инструмента.
Это все было на С++. Менять язык только ради того, что прямо на нем можно сделать DSL, я не буду — это глупость. Должны быть более веские причины.
АХ>>Единственное что напрягает "mutable" для переменных (но это видимо специально, чтобы не хотелось использовать ), я бы предпочел более короткое "val" как в Scala.
АХ>Букву перепутал, var конечно же.
Я сомневаюсь в Вашей способности прогнозировать будущее Nemerle в основном потому, что Вы, по всей видимости, мало знакомы с его настоящим. Лично мне было гораздо интереснее почитать соображения о проблемах Nemerle здесь
ведь у меня сложилось впечатление, что Vermicious Knid разбирается в вопросе существенно лучше.
В то время как Ваше сочинение о будущем Nemerle изобилует преимущественно эмоциональными суждениями и мизантропией, которая как всегда единственная надежда и опора во дни сомнений, во дни тягостных раздумий о судьбах нашей родины.
L>Основные проблемы Nemerle, мешающие ему стать распространенным языком: L>1) "Предательство" синтаксиса L>2) Упор на повышение "мощности" языка L>3) Метапрограммирование (для п.2) L>4) Смешение парадигм (для п.2)
Мешают стать таковым почти всем существующим языкам. Кроме, естественно, тех, которые проектировались пуристами для пуристов.
Может Вы намекаете на то, что по сравнению с Java даже такие языки как C++ или C# являются маргинальными?
Весьма сомнительный тезис.
Рассмотрим подробнее тот же C#: Мало того что он содержит многочисленные "предательства С-like синтаксиса" вроде объявления массивов, так в нем есть вещи и покруче, которые Вы вполне могли бы назвать "предательством семантики" (например псевдодеструкторы ~foo, которые на самом деле никакие не деструкторы). Налицо существенные претензии на повышение выразительности (которую вы называете мощностью) в виде foreach или yield. Существует некоторая поддержка языком AOP в виде атрибутов.
И самое страшное — просто таки каинова печать — смешение парадигм. Думаю влияние ФП на C# трудно не заметить, нес па?
Так что из Вашей теории следует абсолютная невозможность какого бы то ни было настоящего у C#, и в этом теория противоречит фактам.
Тем более, похоже что пуристы сдают позиции. В Java решили досыпать фич и сахарку, а VB вообще стал более чем навороченным языком.
L>В основе проблем лежат: L>1) Преувеличение мыслительных способностей программистов, а и людей вообще. В реальности они довольно ограничены. L>2) Преувеличение роли логического, рационального мышления. Человек мысли иррационально, эмоционально (увы и ах).
Серьезная заявка на победу! Отталкиваясь от этих же аргументов Вы с таким же успехом докажете невозможность программирования, высшей математики и даже устного счета. Не останавливайтесь на достигнутом, порадуйте нас новыми шокирующимим откровениями.
L>3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.
В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.
L>Подробно о проблемах: L>1) Синтаксис Nemerle взяв за основу синтаксис C, тем не менее существенно от него отступает, причем без всякого разумного обоснования. Если бы синтаксис отличался радикально (как у Python, Ruby и др.) это было бы пол беды — проосто изучение языка стало бы путешествием в совершенно новый мир, пусть непривычный и даже чуток враждебный. Враг бывает достоин уважения и даже восхижения, но предатель — никогда.
Меня обескураживает такой романтический подход к языкам. Я склонен полагать, что называть своим врагом язык можно с таким же успехом как и десятичную систему счисления или электроперфоратор.
L>Все удачные (читай: получившие расространение) синтаксические приемники Си шли по пути расширения его синтаксиса, но, в отличии от Nemerle, не извращения, таковы C++, Java, Java-script, PHP, C#, даже Perl. Аргумент разработчиков Nemerle: синтаксис отличается, но люди легко его выучат. Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).
Это фактически не верно. Синтаксис претерпевал во многих примерах названных Вами положительными существенные изменения. Хотя, возможно, мне трудно уловить тонкость между "расширением" и "извращением". По моему же скромному разумению, те, кто стерпел Perl вынесут все что угодно с вот такими вот скобочками {}. Я даже подозреваю, что если бы в Lisp по умолчанию были правильные(тм) скобки, то его ждал бы ошеломительный успех.
Специально для тех, кто уже готовится отбивать мне почки, заявляю: про lisp я пошутил.
L>2) Программистам не хватает не "мощности", которую вполне можно упаковать в библиотеки и API, а надежности, защищенности и удобства. Такие ставшие "примитивными" возможности среды разработки, как подсветка синтаксиса, контекстная справка, переход по перекрестным сслыкам, InteliSence и т.п. экономят гораздо больше времени и нервных клеток, чем многие синтаксические навороты. Причина в том, что программы пишут живые люди, которые быстро утомляются, часто ошибаются, что-то забывают и т.д. Простота и лаконичность — вот чего ждут разработчики.
Этот довод работает в обе стороны. Просто взгляды на простоту очень сильно отличаются. Синтаксические сладкоешки уверяют, что оператор + все только упрощает, а синтаксические диабетики приходят в ужас от того, что за + может скрываться операция сложения матриц. В тех условиях, когда договориться о объеме стандартной порции сахара не представляется возможным, вполне может оказаться востребованным решение, позволяющее досыпать сахар по вкусу. Вы поняли, о чем я.
Мне кажется, что Nemerle (если не касаться макросов, да и макросы там к взрыву мозга не приводят) очень простой язык. Гораздо проще чем Scala или даже C# 3.0. Что же касается лаконичности, то про C# и тем более Java лучше вообще не вспоминать.
Про волшебный язык с двумя положительными свойствами я даже не заикнусь. А то придут мрачные люди вроде капитана Блэка из Catch 22 и сообщат, что к подписанию присяги о лояльности меня не допустят. Не очень то и хотелось.
L>3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается). И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу,
Есть мнение, что метапрограммирование как раз упрощает понимание. Оно как раз и придумывалось для того, чтобы пощадить наши мозги, а за одно и не позволить умереть от бессмысленного труда. Люди, которые ставят перед собой противоположные цели, занимаются не метапрограммированием, а разработкой пятимерных кубиков Рубика.
L>не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java). А ведь мир видал препроцессоры куда круче Nemerle-вского, в PL/I язык препроцессора по мощи не многим уступал самому целевому языку. Похоже, использование generic-ов (причем без typedef!) и Reflection вполне достаточная доза метапрограммирования в современных языках.
Для начала, обобщенное программирование к метапрограммированию никакого отношения не имеет. Причем обобщенное программирование в java теперь есть. Про препроцессоры вообще кошмар. Макросы Nemerle никакого отношения к препроцессору не имеют. Это расширение компилятора, а не средство осуществляющее текстовые подстановки.
При этом совершенно не понятно, почему, оставляя право на существование эмиссии кода в рантайм Вы отказываете в этом праве макросам? Это вещи по сложности почти несопоставимые, а уж по количеству граблей и подавно.
Непонятно также, почему, если отсутствие поддержки метапрограммирования — это только плюс, множество людей извращаются с кодогенераторами и шаблонами?
К слову, раз уж язык претендует на мэйнстрим, в нем есть некоторые средства дать по рукам тем самым "самоделкиным" которые примуться строчить свои макросы и которых тут так боятся.
L>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная)
Боже, храни Королеву! Вы бы хоть с терминологией разобрались, а? Это же элементарное уважение к собеседнику.
L>видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста.
Перегруженным мозгам остаются их естественные права использовать все что можно раздельно и экстенсивно.
Аргумент снова работает в обе стороны: мультипарадигменность позволяет плавно переходить от одной парадигмы к другой, допускает возможность комбинировать подходы в удобных пропорциях. С этой точки зрения, мультипарадигменность как раз претензия на мейнстрим.
L>В лучшем случае труднопонимаемые детали будут задвинуты, в худшем будут служить причиной тонких, неуловимых ошибок и огромных проблем с чтением чужого кода.
Все те же аргументы приводились и против ООП. Функциональные элементы все равно так или иначе приходят в мэйнстрим, пусть даже и под мозгодробительными названиями, придуманными microsoft-ом.
L>Вы пробовали изучать, к примеру, Пролог? Пока читаете описание и разбираешь простые примеры — все отлично. Как дело доходит до решения оригинальных задач и чтения реального кода, вот тут и понимаете как трудно переключиться в принципиально иную парадигму.
Тем не менее такое переключение уже происходило и не раз.
L>Приходится сделать неутешительный вывод: Nemerle — лишь новый красивый узорчатый листок на пышном дереве мертвых исследовательских языков где-то рядом с НУТ-ом (Новым Утопистом) и другими попытками объять необъятное.
Приходится сделать неутешительный вывод: тема будущего Nemerle в Вашем сообщении не раскрыта. У этого языка есть проблемы с Выходом в мэйнстрим. Я даже склоняюсь к мысли, что значительной популятности у Nemerle никогда не будет, и вовсе не потому, что он слишком хорош для этого мира. Качество языка с распространенностью вообще слабо коррелирует.
Вот только хорошая совместимость с .NET уже означает, что этот язык не является маргинальным.
Старина Аристотель, кажется говорил, что одна ласточка еще не делает весны, но вот только Nemerle такой ласточкой и не является. Тем более не является и попыткой объять необъятное.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Gaperton, Вы писали:
G>Отвечаю. :xz: Если нет известного инструмента для чего бы то ни было, не только DSL, то либо обходятся без инструмента — гражданскими средствами, либо пишут свой инструмент. :) Содержательно, да? Ну, так какой вопрос, такой и ответ.
;-)
G>Могу сказать про себя — я в таких случаях делал свой парсер и свою виртуальную машину. Благо что ФОРТ-машина, как и парсеры, делается элементарно, быстро и на автомате — не успеешь сказать "немерле". DSL-и были очень специфические, это были языки описания торговых систем и преобразований временных рядов, и для них не было ну совершенно никакого известного инструмента.
Ну! О чем и речь.
Если задаче нужен DSL, а известного нет, то его приходится писать. А макросы в этом деле неплохо помогают. Я, честно говоря, даже не представляю, зачем мне писать на лиспе, у которого нет макросов.
В общем то это моя вина. Из-за категоричности твоих постов я решил, что ты противник макросов.
G>Это все было на С++. Менять язык только ради того, что прямо на нем можно сделать DSL, я не буду — это глупость. Должны быть более веские причины.
Спасибо, это то, что я хотел услышать.
Разумеется, я не говорил ни о "менять", ни о "только для dsl"
Здравствуйте, Klapaucius, Вы писали:
K>В то время как Ваше сочинение о будущем Nemerle изобилует преимущественно эмоциональными суждениями и мизантропией, которая как всегда единственная надежда и опора во дни сомнений, во дни тягостных раздумий о судьбах нашей родины.
Вы так говорите, как будто с другой стороны посты у нас не изобилуют эмоциональными суждениями, и Немерлисты являют собой классический образ характера выдержанного, нордического .
L>>3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.
K>В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.
Э-э батенька, должно быть стыдно цепляться к словам и делать вид, что мы ничего не понимаем. Автор, очевидно, имеет в виду идеи, стоящие за literate programming, противопоставляя их пионерскому подходу "настоящих программистов", которые пишут "настоящий код не для всех". Знакомый типаж?
Да вот посмотрите, что тут один дядька пишет на эту тему...
I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."
Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.
Donald Knuth. "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99.
Так вот, автор выразил мнение, что массированое применение макросов и неконтроллируемые эксперименты над синтаксисом ухудшат свойства "литературности" программ, сделают их сложнее для понимания другим человеком, даже если он мега-гуру. Современные программные комплексы состоят из миллионов строк кода, такой объем один человек написать и осмыслить в одиночку не может принципиально. Так что чужой и незнакомый код — это реальность, с которой сталкивается каждый программист в компании, разрабатывающей промышленное ПО. Основной критерий, применяемый к коду таких систем — это maintainability (легкость сопровождения), потому как код такого объема выкинуть нельзя, это долговременная инвестиция компании. Плюс, надо отдавать себе отчет, что авторы системы из компании могут уйти, или будут заняты другой работой, и поддерживать код будут другие люди, не те, кто писали.
Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++. Ну и разумеется, макросы, как средство, наиболее опасное для maintainability, должно находится под строгим контролем, и применяться очень ограничено.
Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...
Здравствуйте, lomeo, Вы писали:
G>>Могу сказать про себя — я в таких случаях делал свой парсер и свою виртуальную машину. Благо что ФОРТ-машина, как и парсеры, делается элементарно, быстро и на автомате — не успеешь сказать "немерле". DSL-и были очень специфические, это были языки описания торговых систем и преобразований временных рядов, и для них не было ну совершенно никакого известного инструмента.
L>Ну! О чем и речь. L>Если задаче нужен DSL, а известного нет, то его приходится писать. А макросы в этом деле неплохо помогают. Я, честно говоря, даже не представляю, зачем мне писать на лиспе, у которого нет макросов.
L>В общем то это моя вина. Из-за категоричности твоих постов я решил, что ты противник макросов.
Чтобы расставить точки над "i" — я сторонник чрезвычайно осторожного обращения с макросами, т.е. я действительно противник их [широкого] применения. Подробности здесь http://rsdn.ru/Forum/Message.aspx?mid=2048270&only=1
Теперь, если говорить о DSL. Учитывая, что собственно сам интерпретатор DSL — обыкновенно небольшая и не далеко не самая сложная и рискованная часть всей задачи, мне представляется сомнительным выбирать язык исходя из удобства написания DSL.
В этом и состоит мое отличие от точки зрения большинства здесь — я совсем не в восторге от лекости метапрограммирования в Немерле, считая это в реальности очень небольшим плюсом. То, что он .NET-based, для меня еще более снижает его ценность как средства создания DSL — его не так просто встроить в другой процесс, как, например, LISP, Python, LUA, etc.
И это нормально. У меня свои задачи и своя точка зрения, у других может быть другая. Форум нужен, чтобы делиться точками зрения, не так ли?
Здравствуйте, Gaperton, Вы писали:
L>>В общем то это моя вина. Из-за категоричности твоих постов я решил, что ты противник макросов. G>Чтобы расставить точки над "i" — я сторонник чрезвычайно осторожного обращения с макросами, т.е. я действительно противник их [широкого] применения. Подробности здесь http://rsdn.ru/Forum/Message.aspx?mid=2048270&only=1
Ну, дураку хоть носовой платок дай, он и им порежется. В общем то, то, что можно сделать функциями, я думаю, никто не рисует на макрах. Макры должны делать код более удобным для сопровождения (краткость и ясность в описании задачи = DSL), а не наоборот. Когда мы не можем этого также легко добиться своими библиотеками функций или конструкциями языка — приходит их время.
В общем, я скатываюсь в банальщину.
G>Теперь, если говорить о DSL. Учитывая, что собственно сам интерпретатор DSL — обыкновенно небольшая и не далеко не самая сложная и рискованная часть всей задачи, мне представляется сомнительным выбирать язык исходя из удобства написания DSL.
Конечно. Только я считаю, что совсем не учитывать этот фактор тоже не очень правильно.
G>В этом и состоит мое отличие от точки зрения большинства здесь — я совсем не в восторге от лекости метапрограммирования в Немерле, считая это в реальности очень небольшим плюсом. То, что он .NET-based, для меня еще более снижает его ценность как средства создания DSL — его не так просто встроить в другой процесс, как, например, LISP, Python, LUA, etc.
Я тоже не в восторге от макросов в Немерле :-) Но причина у меня другая и очень субъективная — в Лиспе я создаю свой язык, а в Немерле надстраиваю имеющийся. Ну и еще в Лиспе не надо что то добавлять к синтаксису, чтобы добавить макры. В Немерле это как отдельный инструмент. Ну, т.е. я его так воспринимаю.
G>И это нормально. У меня свои задачи и своя точка зрения, у других может быть другая. Форум нужен, чтобы делиться точками зрения, не так ли?
Да. Создание своей шкалы ценностей — дело опыта. У тебя макры и DSL-и находятся пониже на этой шкале, у меня повыше.
Здравствуйте, Gaperton, Вы писали:
G>Да вот посмотрите, что тут один дядька пишет на эту тему...
G>
G>I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."
G>Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
G>The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.
G>Так вот, автор выразил мнение, что массированое применение макросов и неконтроллируемые эксперименты над синтаксисом ухудшат свойства "литературности" программ
Что-то я про макросы не разглядел, в какой именно строчке это выражено?
G>сделают их сложнее для понимания другим человеком, даже если он мега-гуру.
Макросы сами по себе и усложнение понимабельности кода никак между собой не связаны. Вообще! С тем же успехом можно запретить команду copy/paste в среде разработки. Вот уж действительно вещь, которая нанесла и ещё не раз нанесёт непоправимый урон простоте кода. А вот с макросами можно писать наоборот, очень простой, понятный и отжатый от всего лишнего бизнес код.
К тому же у макросов Немерле есть три проявления: в виде функций, в виде атрибутов и в виде изменения синтаксических конструкций. С функциями вроде всё понятно, это ни чем не хуже и не лучше обычных функций. Атрибуты? Ну так они и сейчас во всю используются, в том числе и для кодогенерации. Но вот только делается это совершенно варварскими методами с помощью эмита и рефлекшина. Изменение синтаксиса? Да, есть определённая угроза. Но кто сказал, что это будет обязательно ядерная бомба, а не мирный атом в условиях прогрессирующего энергетического кризиса?
G>Современные программные комплексы состоят из миллионов строк кода, такой объем один человек написать и осмыслить в одиночку не может принципиально. Так что чужой и незнакомый код — это реальность, с которой сталкивается каждый программист в компании, разрабатывающей промышленное ПО. Основной критерий, применяемый к коду таких систем — это maintainability (легкость сопровождения), потому как код такого объема выкинуть нельзя, это долговременная инвестиция компании. Плюс, надо отдавать себе отчет, что авторы системы из компании могут уйти, или будут заняты другой работой, и поддерживать код будут другие люди, не те, кто писали.
Legacy code всегда был проблемой. И эта проблема, в первую очередь, усугубляется объёмом этого самого кода. Во вторую — его запутанностью. Чаще всего объёмность и запутанность ходят вместе. Но вот кто и когда успел поставить знак равенства между макросами и объёмностью и запутанностью, мне не понятно Код с макросами, краткий, но непонятный на первый взгляд (хотя опять же почему непонятный?) в любом случае будет гораздо проще сопровождать чем накопипейсченный или того хуже изуродованный бредовым дизайном какого-нибудь Брайана Белла.
В общем, связь между макросами и ухудшением maintainability пока плохо улавливается.
G>Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++. Ну и разумеется, макросы, как средство, наиболее опасное для maintainability, должно находится под строгим контролем, и применяться очень ограничено.
А что насчёт неадекватного применения design patterns, кнопки копи/пейст, генераторов кода, которые потом теряются или меняются, а нагенерированные ими десятки тысяч строк остаются? Что делать с ленью девелоперов, тупостью архитекторов и близорукостью менеджеров? Это всё тоже очень сильно сказывается на обеспечении maintainability. Или запрет макросов одним махом решит все эти проблемы? Я сомневаюсь. Макросы — штука мощная, но однозначно разрушительной она может стать только у тех, у кого и без макросов проблем выше крыши.
G>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...
Но сначала они получили неслабое конкуретное преимущество, не так ли? А потом не смогли, не захотели, не договорились. И как это обычно водится в больших компаниях, нашёлся какой-нибудь ушлый манагер, который на затаптывании старого кода и его переписывании сделал себе карьеру.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
G>Так вот, автор выразил мнение, что массированое применение макросов и неконтроллируемые эксперименты над синтаксисом ухудшат свойства "литературности" программ, сделают их сложнее для понимания другим человеком, даже если он мега-гуру.
Как интересно. А что же он тогда позволил писать макросы в ТеХ?
>>Современные программные комплексы состоят из миллионов строк кода, такой объем один человек написать и осмыслить в одиночку не может принципиально. Так что чужой и незнакомый код — это реальность, с которой сталкивается каждый программист в компании, разрабатывающей промышленное ПО. Основной критерий, применяемый к коду таких систем — это maintainability (легкость сопровождения), потому как код такого объема выкинуть нельзя, это долговременная инвестиция компании. Плюс, надо отдавать себе отчет, что авторы системы из компании могут уйти, или будут заняты другой работой, и поддерживать код будут другие люди, не те, кто писали.
Не понимаю, какое отношение к этому имееют макросы. Такое ощущение, что уже есть огромное число кода на макросах и поддерживающие его программисты завалили жалобами все форумы. Не мог бы ты привести аргументы (а не домыслы) в пользу того, что код на макросах поддерживать труднее. Пока что я видел только ужасающий код без макросов.
G>Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++. Ну и разумеется, макросы, как средство, наиболее опасное для maintainability, должно находится под строгим контролем, и применяться очень ограничено.
Понятное дело, что использование макросов для DSL надо контролировать. Но макросы не виноваты, что ими пользовался кто-то криворукий. Более того, скажу, что в одной из крупнейших российских компаний своими глазами наблюдал ужасающий DSL на основе XML реализованный на C++ с использованием COM. Более гнусной вещи еще не встречал. И при этом руководство прекрасно знало о его недостатках, но не вмешалось и не заставила его переделать.
G>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...
Кто кого загнал в гроб? По-моему, наоборот Грехам неплохо нажился на продаже своей компании и, по его собственным словам, Lisp был основой успеха. То что у Яхо не нашлось компетентных людей для поддержки кода — проблемы Яхо.
Здравствуйте, ole!, Вы писали:
O>[большую часть удалил] G>>Так что у нас в конторе Немерле не будет. Мы жить хотим. Вдруг в ком-нибудь неожиданно проснется талант Брайана Белла?
O>перечитайте пож. ваш NDA.
И? Думаете я раскрыл нечто, что даст конкурентам CQG решающее преимущество? Теперь, после моего поста, и упоминания волшебных слов FLO и GOC вам стало ясно, как делать программные комплексы класса CQG, состоящие из десятка типов серверов, нескольких десятков клиентских подсистем, и содержащие миллионы строк кода? Флаг вам в руки.
Здравствуйте, Gaperton, Вы писали:
K>>В то время как Ваше сочинение о будущем Nemerle изобилует преимущественно эмоциональными суждениями и мизантропией, которая как всегда единственная надежда и опора во дни сомнений, во дни тягостных раздумий о судьбах нашей родины. G>Вы так говорите, как будто с другой стороны посты у нас не изобилуют эмоциональными суждениями, и Немерлисты являют собой классический образ характера выдержанного, нордического .
Моя вина в нечеткой формулировке. Беда, конечно же, не в изобилии эмоциональных суждений, а в отсутствии каких либо иных суждений кроме эмоциональных.
Что касается характера немерлистов — то мне нет до него никакого дела, как нет дела и до замечаний, которые делаются мне из-за действий, которые совершали какие-то другие люди. Я конечно заметил, что на rsdn существует, скажем так, институт коллективной ответственности, но мне такая практика категорически не нравится.
L>>>3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками. K>>В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль. G>Э-э батенька, должно быть стыдно цепляться к словам и делать вид, что мы ничего не понимаем.
Стыдно, по-моему, должно быть как раз автору, который не в состоянии внятно выразить свою мысль, особенно, если учесть, что сложность этой мысли весьма незначительна.
G>Автор, очевидно, имеет в виду идеи, стоящие за literate programming, противопоставляя их пионерскому подходу "настоящих программистов", которые пишут "настоящий код не для всех". Знакомый типаж?
Более чем. Я не собираюсь оспаривать идеи, стоящие за literate programming, а то, что программы пишутся для людей — считаю самоочевидным. Я просто не согласен с тем, что автор приписывает авторам Nemerle "пионерский подход". Лично я не заметил в дизайне Nemerle каких-то особенностей, принуждающих писать криптокод. Как раз наоборот — массу возможностей писать очень понятный и легко читаемый код. Что же касается возможностей писать криптокод, то их более чем достаточно в любом известном мне языке.
Проблема криптокода, по-моему, вообще не в том, что программистов так уж сложно убедить в необходимости писать понятный код, а скорее в том, что взгляды на понятность кода у программистов зачастую кардинально расходятся.
G>Так вот, автор выразил мнение, что массированое применение макросов и неконтроллируемые эксперименты над синтаксисом ухудшат свойства "литературности" программ, сделают их сложнее для понимания другим человеком, даже если он мега-гуру.
Ключевые слова выделены. Собственно, утверждение тривиально и сводится по сути к старым как мир утверждениям о том, что все хорошо в меру. Нетривиально, зато, само понятие меры, и, к сожалению, на этот вопрос Ваше утверждение свет не проливает.
С другой стороны контролируемые эксперименты над синтаксисом вполне могут улучшить свойства "литературности". При этом как мне показалось, при разработке Nemerle ставилась задача как раз сделать хорошо контролируемое средство для изменений синтаксиса.
Что касается макросов, то в большинстве случаев они вообще никак синтаксис не затрагивают.
G>Современные программные комплексы состоят из миллионов строк кода, такой объем один человек написать и осмыслить в одиночку не может принципиально. Так что чужой и незнакомый код — это реальность, с которой сталкивается каждый программист в компании, разрабатывающей промышленное ПО. Основной критерий, применяемый к коду таких систем — это maintainability (легкость сопровождения), потому как код такого объема выкинуть нельзя, это долговременная инвестиция компании. Плюс, надо отдавать себе отчет, что авторы системы из компании могут уйти, или будут заняты другой работой, и поддерживать код будут другие люди, не те, кто писали.
Все это также тривиально, как тривиален и тот факт, что проблема сопровождения существует и при отказе от использования макросов.
Вообще, если кому-то и нужно рассказывать про эту проблему, то не мне. И я не понимаю, каким образом из моего сообщения был сделан вывод, что мне про эту проблему рассказывать нужно.
G>Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++.
Да, это так.
G>Ну и разумеется, макросы, как средство, наиболее опасное для maintainability,
Это спорное утверждение. Однако опасность существует — это факт.
G>должно находится под строгим контролем,
+1
G>и применяться очень ограничено.
Вопрос также вполне дискуссионный.
Я бы лучше сказал разумно ограниченно.
G>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...
Это больше говорит о lisp и применении малораспространенных языков в мэйнстриме вообще, чем о злобной сущности макросов. Зло вообще в голове, а не в вещах. Просто смысл в программировании на lisp без использования макросов от меня ускользает.
С другой стороны видно, что макросы это оружие обоюдоострое. Но это о любом средстве можно сказать, за исключением тех средств от которых вообще ничего кроме вреда не бывает. Макросы дали Грэхемовскому стартапу конкурентное преимущество, а для yahoo и тех lisp-стартапов, которые планируют yahoo продаться (если такие вообще существуют) создали проблемы.
Я не спорю с тем, что то, что Грэхему хорошо — то yahoo смерть. Я не понимаю, как сама возможность писать макросы может погубить Nemerle при том, что макрописателей там всегда можно ограничить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Gaperton, Вы писали:
G>>>талант Брайана Белла?
O>>перечитайте пож. ваш NDA.
G>И? Думаете я раскрыл нечто, что даст конкурентам CQG решающее преимущество? Теперь, после моего поста, и упоминания волшебных слов FLO и GOC вам стало ясно, как делать программные комплексы класса CQG, состоящие из десятка типов серверов, нескольких десятков клиентских подсистем, и содержащие миллионы строк кода? Флаг вам в руки.
Раскрыл раскрыл. Теперь конкуренты наймут Браяна Белла, который поможет всё это написать и CQG разорится.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Gaperton, Вы писали:
G>>Так вот, автор выразил мнение, что массированое применение макросов и неконтроллируемые эксперименты над синтаксисом ухудшат свойства "литературности" программ, сделают их сложнее для понимания другим человеком, даже если он мега-гуру.
Q>Как интересно. А что же он тогда позволил писать макросы в ТеХ?
"Автор" — в данном случае не Кнут, а ласточкин. Он выразил это мнение, а не кнут.
>>>Современные программные комплексы состоят из миллионов строк кода, такой объем один человек написать и осмыслить в одиночку не может принципиально. Так что чужой и незнакомый код — это реальность, с которой сталкивается каждый программист в компании, разрабатывающей промышленное ПО. Основной критерий, применяемый к коду таких систем — это maintainability (легкость сопровождения), потому как код такого объема выкинуть нельзя, это долговременная инвестиция компании. Плюс, надо отдавать себе отчет, что авторы системы из компании могут уйти, или будут заняты другой работой, и поддерживать код будут другие люди, не те, кто писали.
Q>Не понимаю, какое отношение к этому имееют макросы.
А ты перечитай этот абзац еще раз — в нем я вообще о макросах не говорю — пока. Я излагаю мысль по порядку, как мне это удобно. Хочешь понять, какое он имеет отношение к макросам — читай дальше, до конца, там очень доступно все изложено. Ну, или просто напиши — длинно, мол, не осилил. Зачем шуметь-то?
Q>Такое ощущение, что уже есть огромное число кода на макросах и поддерживающие его программисты завалили жалобами все форумы.
Не знаю, откуда у тебя такое ощущение. Извини, ничем не могу помочь, тонны кода с макросами большой бандой писать не буду — это без меня.
Q>Не мог бы ты привести аргументы (а не домыслы) в пользу того, что код на макросах поддерживать труднее. Пока что я видел только ужасающий код без макросов.
Код макрос ужасающий быть может очень. Грамматика правило ввести новое я удобное мне, и хочешь понимай как. И еще человек сделают двадцать так. (определение измененной "грамматики" искать в файлах /megasystem/coolhacker_code. Файл правлен тремя людьми, с промежутком в год, а еще двое посмотрели на него, не вкурили и назвали отстоем, и написали пару своих "грамматик".).
Давай поставим вопрос так. Ты вообще на саппорте больших систем когда-нибудь работал? Систем, которым более 5 лет, которые писало человек 20, и в которых кода от миллиона строк? Если нет, то тебе сначала придется долго объяснять, в чем вообще суть понятия maintainability. А уже только потом перейти к макросам, и с переходом на яблоки, обяснить тебе разницу между определением нового термина (без макросов) и расширением синтаксиса и семантики языка (с макросами). Разница в том, что в первом случае ты, читая незнакомый код, знаешь правила его понимания, но не знаком со значением некоторых терминов, а во втором ты даже прочитать его толком не сможешь. Давай ты не будешь давать подстрочных комментариев, а дочитаешь до конца, и постараешься понять, о чем я — ты просил объяснить, я объсняю. Все таки, мы слишком давно знакомы по форуму, чтобы считать друг бруга идиотами, не так ли, Quintanar?
Вот тебе пример подобного кода на С++ — без макросов. Ситуация — ты читаешь функцию, ты в ней проездом по делу, тебе надо быстро в общих чертах понять, что здесь происходит, и идти дальше.
CDoSomething somethg( a, b, c );
somethg( d, e );
somethg( x, y );
somethg( w, r );
somethg( f, i );
Подсказка — этот код на самом деле оказался эквивалентен следующему:
something( a, b, c, d, e );
something( a, b, c, x, y );
something( a, b, c, w, r );
something( a, b, c, f, i );
Т.е. автор изобразил карринг на функторах. Проблема здесь в том, что ты вынужден посмотреть определение класса CDoSomething, не доверяя ее названию (!), потому что автору может прийти в голову сделать там что угодно. Такие вещи становится проблемой, когда тебе надо просмотреть много кода. И все ради какой-то совершенно не функциональной фигни.
Ок, здесь мы хотя бы знаем, что CDoSomething — это класс, что у него могут быть перекрыты скобки, и что там может быть что угодно. Однако, этот код уже вынуждает читателя знать о C++ много, например, что скобки можно перекрывать. А у новичка взорвет мозг. Лады, это была ерунда. Усугубляем проблему, приближаясь по силе воздействия к макросам. Вот такой код, :
a = b + c + d
где a, b, c, d — члены класса.
Что делает? А мы не знаем — то ли там перекрыт плюс, то ли присваивание имеет побочный эффект — черт его знает. Для того, чтобы понять что это, мы должны:
1) Посмотреть определение класса выяснить типы аргументов.
2) Посмотреть определение типов, проверить на предмет перекрытого =, оператора +, и (!!) операторов приведения типов, которые в свою очередь, могут указывать на другой "сложный" тип.
3) Вернуться обратно, и постараться восстановить ход мысли — ведь мы тут на самом деле проездом, и совсем по другому делу.
Общее в этих примерах — возрастающий уровень вложенности, такой, что до понимания смысла конструкции, которую ты видишь (не прикладного смысла, заметь), тебе надо порядочно полазить по чердакам и подвалам. Какое это имеет отношение к макросам? Ну право же, это была подготовка. Теперь ты, наверное, готов к настоящему С++?
Вопрос: сколько кода надо просмотреть, чтобы понять смысл этой конструкции на С++, и ход ее выполнения? При этом, не обольщяйся, вообрази, что вот такого описания http://www.intelib.org/intro.html у тебя нет, а это обычный умеренно документированный код в составе системы. Поэтому, тебы не должно смущать внешнее сходство с Лиспом — автор мог придатьэтой конструкции любой смысл. Как показывает практика — и придают любой, вплоть до противоположных по смыслу названий. Последнее, причем, обычно результат групповой работы.
G>>Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++. Ну и разумеется, макросы, как средство, наиболее опасное для maintainability, должно находится под строгим контролем, и применяться очень ограничено.
Q>Понятное дело, что использование макросов для DSL надо контролировать. Но макросы не виноваты, что ими пользовался кто-то криворукий.
Вопрос о вине или не вине макросов философский. То же самое, что вопрос вины адресной арифметики в крешах — она тут не причем, это все криворукие программисты.
Так вот, я макросы и не обвиняю — спорьте тут о крутизне макросов и немерле без меня. Они всего лишь инструмент. Виноваты во всем не макросы, а люди. А люди именно такие, какие есть — криворукие. Либо инструмент учитывает человеческую натуру, с которой ничего не поделаешь, либо нет, тут уж одно из двух. И вообще, ты забыл, что я всего лишь поясняю непонятливым клапауциям мысль ласточкина, по которой он так невежливо прошелся. Она, вопреки нашим шибко умным горячим головам, у ласточкина была. С мыслью можно быть не согласным, можно иметь свое мнение — страна свободная.
Q>Более того, скажу, что в одной из крупнейших российских компаний своими глазами наблюдал ужасающий DSL на основе XML реализованный на C++ с использованием COM. Более гнусной вещи еще не встречал. И при этом руководство прекрасно знало о его недостатках, но не вмешалось и не заставила его переделать.
Ну, всегда можно сделать еще хуже, ты же знаешь . А вот трамвай, например, людей на тротуарах не давит, даже если машинист пьян.
G>>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...
Q>Кто кого загнал в гроб? По-моему, наоборот Грехам неплохо нажился на продаже своей компании и, по его собственным словам, Lisp был основой успеха. То что у Яхо не нашлось компетентных людей для поддержки кода — проблемы Яхо.
Я и говорю о проблемах Яхо, а не Грэхема, если ты не заметил.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
G>>И? Думаете я раскрыл нечто, что даст конкурентам CQG решающее преимущество? Теперь, после моего поста, и упоминания волшебных слов FLO и GOC вам стало ясно, как делать программные комплексы класса CQG, состоящие из десятка типов серверов, нескольких десятков клиентских подсистем, и содержащие миллионы строк кода? Флаг вам в руки.
ANS>Раскрыл раскрыл. Теперь конкуренты наймут Браяна Белла, который поможет всё это написать и CQG разорится.
Не знал, что NDA обязывает скрывать фамилии отличников боевой и политической подготовки .
Кстати, насчет Брайана в Trading Station — это идея. А то чой-то они больно шустро новые продукты выпускают, надо им мощный гандикап подложить. Обучить Брайана Nemerle — и заслать на работу в Trading Station .
Здравствуйте, Klapaucius, Вы писали:
K>Что касается характера немерлистов — то мне нет до него никакого дела, как нет дела и до замечаний, которые делаются мне из-за действий, которые совершали какие-то другие люди. Я конечно заметил, что на rsdn существует, скажем так, институт коллективной ответственности, но мне такая практика категорически не нравится.
Респект . Характер выдержанный, нордический — без дураков.
хъ
Я тее так скажу — я не поддерживаю позицию ласточкина целиком, но меня удивило, как ты ответил на самый разумный его аргумент.
В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.
Ну, если по существу мысль ласточкина тебе понятна, и тривиальна, как выясняется, то что ж ты ему ответил-то так?
G>>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...
K>Это больше говорит о lisp и применении малораспространенных языков в мэйнстриме вообще, чем о злобной сущности макросов. Зло вообще в голове, а не в вещах. Просто смысл в программировании на lisp без использования макросов от меня ускользает.
Ты все правильно пишешь. Только один нюанс, смотри предложение сверху и снизу. K>Я не спорю с тем, что то, что Грэхему хорошо — то yahoo смерть. Я не понимаю, как сама возможность писать макросы может погубить Nemerle при том, что макрописателей там всегда можно ограничить.
Т.е. на лиспе писать без макросов смысла нет, он от тебя ускользает. Что характерно, я с тобой в этом согласен. Теперь объясни мне, согласному с тобой, какой смысл писать на Немерле, если макрописателей придется (от греха) ограничивать.
ЗЫ: Погубить эта возможность Немерле ИМХО не может. Он еще не дошел до того состояния, чтобы его что-то вообще могло "погубить".
Здравствуйте, Gaperton, Вы писали:
G>Код макрос ужасающий быть может очень. Грамматика правило ввести новое я удобное мне, и хочешь понимай как. И еще человек сделают двадцать так. (определение измененной "грамматики" искать в файлах /megasystem/coolhacker_code. Файл правлен тремя людьми, с промежутком в год, а еще двое посмотрели на него, не вкурили и назвали отстоем, и написали пару своих "грамматик".).
G>Давай поставим вопрос так. Ты вообще на саппорте больших систем когда-нибудь работал? Систем, которым более 5 лет, которые писало человек 20, и в которых кода от миллиона строк? Если нет, то тебе сначала придется долго объяснять, в чем вообще суть понятия maintainability. А уже только потом перейти к макросам, и с переходом на яблоки, обяснить тебе разницу между определением нового термина (без макросов) и расширением синтаксиса и семантики языка (с макросами). Разница в том, что в первом случае ты, читая незнакомый код, знаешь правила его понимания, но не знаком со значением некоторых терминов, а во втором ты даже прочитать его толком не сможешь. Давай ты не будешь давать подстрочных комментариев, а дочитаешь до конца, и постараешься понять, о чем я — ты просил объяснить, я объсняю. Все таки, мы слишком давно знакомы по форуму, чтобы считать друг бруга идиотами, не так ли, Quintanar?
G>Вопрос: сколько кода надо просмотреть, чтобы понять смысл этой конструкции на С++, и ход ее выполнения? При этом, не обольщяйся, вообрази, что вот такого описания http://www.intelib.org/intro.html у тебя нет, а это обычный умеренно документированный код в составе системы. Поэтому, тебы не должно смущать внешнее сходство с Лиспом — автор мог придатьэтой конструкции любой смысл. Как показывает практика — и придают любой, вплоть до противоположных по смыслу названий. Последнее, причем, обычно результат групповой работы.
Ну так в чем проблемы-то? Как видим, на С++ можно прекрасно писать крайне запутанные программы. Скажу больше, тоже самое можно делать на С без всяких макросов. Так же видим, что опыта поддержки кода с макросами еще ни у кого нет, поскольку они широко не использовались. Но ты уже сейчас клеймишь их изо всех сил. Это предрассудки и предубеждения.
Лично я не вижу большой разницы в чтении обычного кода и кода с макросами. В любом случае, быстро в большой кусок программы не вникнуть, все равно забудешь и функции, и что они значат, и, что важнее, какие у них побочные эффекты. Макросы может быть даже лучше, поскольку они часто не имеют к логике программы прямого отношения, а решают какие-то общие задачи упрощения кода.
G>Так вот, я макросы и не обвиняю — спорьте тут о крутизне макросов и немерле без меня. Они всего лишь инструмент. Виноваты во всем не макросы, а люди. А люди именно такие, какие есть — криворукие. Либо инструмент учитывает человеческую натуру, с которой ничего не поделаешь, либо нет, тут уж одно из двух. И вообще, ты забыл, что я всего лишь поясняю непонятливым клапауциям мысль ласточкина, по которой он так невежливо прошелся. Она, вопреки нашим шибко умным горячим головам, у ласточкина была. С мыслью можно быть не согласным, можно иметь свое мнение — страна свободная.
Меня Немерль не интересует. Мне обидно за макросы.
Здравствуйте, Gaperton, Вы писали:
G>Я тее так скажу — я не поддерживаю позицию ласточкина целиком, но меня удивило, как ты ответил на самый разумный его аргумент. G>
G>В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.
G>Ну, если по существу мысль ласточкина тебе понятна, и тривиальна, как выясняется, то что ж ты ему ответил-то так?
Все мои утверждения были совершенно тривиальны. Просто удивительно, что только тебе и еще "IT" удалось их понять (за что я глубоко признателен), пусть и не во всем согласиться (я и не настаиваю).
Дело в видимо в "фильтрах" большенства читателей:
1) желавших поспорить о возможностях языка (которых я вообще не касался);
2) требовавших конкретных доказательств (хотя посыл был именно в том, что человеческая природа иррациональна и слабо подвержена логике);
3) эмоционально восклицавших "не все программисты дебилы!" и "сам такой!" на банальнейшие слова об ограниченности человеческого разума.
Т.о. лишни раз подтверждается тезис: "Нельзя оценить систему, находясь в системе".
Здравствуйте, Quintanar, Вы писали:
Q>Меня Немерль не интересует. Мне обидно за макросы.
Ну и зачем они нужны в нормальном языке? Меня интересуют не домыслы (с), а реальные аргументы. DSL во-первых прекрасно делается и без макросов, а во-вторых — сам по себе случай достаточно редкий и специальный. Приведи примеры, когда макросы реально необходимы, и драматическим образом улучшают читабельность и сокращают код. А потом обоснуй, почему это просто нельзя сделать частью языка раз и навсегда, и забыть о макросах.
Если тебе обидно за camlp4 — то зря. Мы с мужиками обсудили и давно решили, что это для нас tool of choice для прототипирования компиляторов и создания своих DSL. Причина — возможность оформления кусков грамматики в виде синтаксических расширений, упрощающих эксперименты при создании своего собственного языка программирования (этого известные генераторы парсеров не дают), + ML позволит раза в 2 снизить затраты разработки на собственно компилятор, удобно на нем компиляторы писать. Заметь, о том, что camlp4 — макропроцессором называется, мы как-то не подумали.
Кстати, макросы — это старая новость. В 70-х годах были очень мощные и развитые макросистемы. Не прижились как-то. Применяли их и в промышленных масштабах — макроассемблер ЕС ЭВМ, например, можно назвать — очень популярное средство было тогда. Для PL/I была макросистема какая-то, которая могла все, или почти все. Так что опыт эксплуатации и написания программных систем с макросами у человечества был. И восторгов оно от этого особых не испытывало.
Здравствуйте, Gaperton, Вы писали:
G>Респект . Характер выдержанный, нордический — без дураков.
В юности я был черезвычайно вспыльчив, но после лоботомии все как рукой сняло.
G>Я тее так скажу — я не поддерживаю позицию ласточкина целиком, но меня удивило, как ты ответил на самый разумный его аргумент. G>
G>В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.
G>Ну, если по существу мысль ласточкина тебе понятна, и тривиальна, как выясняется, то что ж ты ему ответил-то так?
Я и не отрицал, что в сообщении ласточкина есть рациональное зерно, но полную ахинею написать вообще гораздо труднее, чем кажется.
Лично для меня утверждение о том, что "Literate Programming — это хорошо" — абсолютнейший трюизм. Я вообще не припоминаю чтобы кто-то утверждал что это плохо. Зато я и не припоминаю двух людей, чье представление о "Literate" хорошо согласовывалось.
Другое дело, что мне не интересно говорить об этом в терминах "общения с компьютером". Нормально, когда про "общение с компьютером" говорит тетя Клава, которая откуда-то (из фильма "Терминатор 2" или, может быть, из газеты "Вечерний желток") подчерпнула сведения о том, что компьютеры живые и собираются поработить человечество. Но для форума "декларативное программирование" это, мягко говоря, не то что нужно. Собственно, раз меня не устроила форма, то и возражение по этому пункту касается именно формы, а не содержания. В чем проблема-то?
Я не против критики. Но считаю, что критика должна быть качественной, осторой, захватывающей, содержательной, интересной.
Вместо этого предлагается очередное изложение изрядно надоевшей всем теории всеобщего идиотизма. Причем, как это обычно и бывает, сам продвигающий теорию ее последовательным сторонником не является, и сам себя идиотом не считает.
Что она мне дает, как ищущему интересных сведений читателю форума?
Что она дает мне, как ищущему развлечений читателю форума?
Что она дает разработчикам Nemerle?
Мой ответ на все три вопроса — "ничего".
Тезис о том, что выхолощенный язык позволяет писать понятнее мне кажется неверным. Возможностей любого выхолощенного языка для написания абсолютно нечитабельного кода более чем достаточно, в то время как средств для того чтобы писать читабельно — как правило не хватает.
Ваши претензии к макросам — понятны. Претензии ласточкина к макросам наводят только на мысль о том, что он вообще не понимает о чем говорит.
Поэтому я и утверждаю, что тема критики Nemerle ласточкиным абсолютно не раскрыта.
K>>Это больше говорит о lisp и применении малораспространенных языков в мэйнстриме вообще, чем о злобной сущности макросов. Зло вообще в голове, а не в вещах. Просто смысл в программировании на lisp без использования макросов от меня ускользает. G>Ты все правильно пишешь. Только один нюанс, смотри предложение сверху и снизу. K>>Я не спорю с тем, что то, что Грэхему хорошо — то yahoo смерть. Я не понимаю, как сама возможность писать макросы может погубить Nemerle при том, что макрописателей там всегда можно ограничить. G>Т.е. на лиспе писать без макросов смысла нет, он от тебя ускользает. Что характерно, я с тобой в этом согласен. Теперь объясни мне, согласному с тобой, какой смысл писать на Немерле, если макрописателей придется (от греха) ограничивать.
По моему скромному разумению, Nemerle приятный язык с достаточно серьезными возможностями. На нем можно программировать прибегая к написанию макросов только в тех случаях, где это действительно необходимо, т.е. в тех случаях, в которых сейчас применяются на мой взгляд более проблемные средства вроде генерации кода. К излишним злоупотреблениям макросами дизайн языка не принуждает. Высота порога вхождения для C# программиста не велика. Интеграция с .net, как я понял, полная и среди языков с такой степенью интеграции с .net я ничего лучше Nemerle не видел. Поэтому претензии на мейнстрим Nemerle как языка я считаю вполне адекватными. Те же проблемы, которые мешают ему стать мэйнстрим-языком с дизайном языка, на мой взгляд, связаны очень слабо.
Я могу, конечно, и дальше предаваться спекуляциям подобного рода, но не стану. В основном потому, что язык я знаю слабо, и врятли смогу сообщить о его достоинствах и недостатках что-то действительно ценное. Я бы с удовольствием почитал серьезный анализ, но — увы — ничего такого мне здесь видеть не приходилось.
G>ЗЫ: Погубить эта возможность Немерле ИМХО не может. Он еще не дошел до того состояния, чтобы его что-то вообще могло "погубить".
Ну почему же? Умереть вполне можно еще до рождения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, lastochkin, Вы писали:
L>Все мои утверждения были совершенно тривиальны.
Ласточкин, Вы меня просто поражаете. Если Вы сами считаете, что Ваши утверждения тривиальны — то зачем же вы их пишете. Не кажется ли Вам, что гораздо ценнее и интереснее нечто нетривиальное?
Я вот тоже могу сказать что Волга впадает в Каспийское море, а потом предаваться рассуждениям о будущем морей и рек, но будет ли от этого кому-нибудь счастье?
L>Просто удивительно, что только тебе и еще "IT" удалось их понять (за что я глубоко признателен), пусть и не во всем согласиться (я и не настаиваю).
Вы же вроде бы считаете, что человеческие возможности очень ограниченны? Рассматривается ли вариант, что просто Вам не удалось понять того, что Вас понял кто-то еще кроме этих двух господ?
L>Дело в видимо в "фильтрах" большенства читателей: L>1) желавших поспорить о возможностях языка (которых я вообще не касался); L>2) требовавших конкретных доказательств (хотя посыл был именно в том, что человеческая природа иррациональна и слабо подвержена логике);
Докажите это.
Ладно. Я пошутил.
Но вот только я никак не пойму (человек — увы — слаб), каким образом иррациональности человеческой природы лишает Nemerle будущего?
Т.е. если человек мыслит рационально, то он неминуемо полюбит Nemerle всем сердцем?
Допустим люди ограниченны и не оценят возможностей немерле -> Покойся с миром, немерле.
Или так: люди ограниченны, поэтому не распознают фатальных недостатков немерле -> да здравствует немерле!
А может так: люди ограниченны и вообще не заметят немерле -> немерле? а что это?
Какому варианту предпочтение-то отдавать? Начальная посылка вроде как одинаковая?
Понятно, что у меня, как и у всех людей, серьезные проблемы с ограниченностью, вот только отталкиваясь от своих неполных знаний и примитивных рассуждений, я вообще так и не смог понять, по какой же причине язык становится популярным.
Если Вы обладаете этим эзотерическим знанием — хотябы намекните. А то я выводить какие-то футурологические прогнозы из человеческой ограниченности не умею.
L>3) эмоционально восклицавших "не все программисты дебилы!" и "сам такой!" на банальнейшие слова об ограниченности человеческого разума.
L>Спасибо. Надеюсь, всем понравилось
Dum spiro, spero. Ну ну.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
G>>Ну, если по существу мысль ласточкина тебе понятна, и тривиальна, как выясняется, то что ж ты ему ответил-то так?
K>Я и не отрицал, что в сообщении ласточкина есть рациональное зерно, но полную ахинею написать вообще гораздо труднее, чем кажется.
На самом деле довольно просто, судя по ее распространенности в философии программирования. Ну да ладно, мы уклоняемся от темы.
K>Лично для меня утверждение о том, что "Literate Programming — это хорошо" — абсолютнейший трюизм. Я вообще не припоминаю чтобы кто-то утверждал что это плохо. Зато я и не припоминаю двух людей, чье представление о "Literate" хорошо согласовывалось.
Дело не в том, что люди утверждают, что это плохо (мало кому придет в голову спорить с Кнутом — для этого надо быть или очень умным, или напротив — полным дураком). Дело в том, что люди понимают, что такое LP, но не понимают, зачем это, и забывают об этом. Когда мне кажется, что вы, Клапауций, забыли о чем-то, то я беру на себя смелость вам об это напомнить. Даже если это, извините, тупо, тривиально, и просто. И не говорите мне, что вы ничего не забываете, никогда ничего не упускаете, и не ошибаетесь. Как вам напомнил Ласточкин (тупо и тривиально), человеческие возможности ограничены. Извините, но тот факт, что вы, как мне кажется, забыли или упустили какую-то тривиальную вещь, не является поводом вам о не не напомнить. Хуже вам от этого не станет, и более того — я всегда стараюсь говорить просто, доходчиво, и тривиально, а не впечатление производить.
K>Другое дело, что мне не интересно говорить об этом в терминах "общения с компьютером". Нормально, когда про "общение с компьютером" говорит тетя Клава, которая откуда-то (из фильма "Терминатор 2" или, может быть, из газеты "Вечерний желток") подчерпнула сведения о том, что компьютеры живые и собираются поработить человечество. Но для форума "декларативное программирование" это, мягко говоря, не то что нужно. Собственно, раз меня не устроила форма, то и возражение по этому пункту касается именно формы, а не содержания. В чем проблема-то?
Какой вы однако капризный . Пианист играет как умеет. Это его посты, он пишет так, как считает нужным. Вам в ваших постах никто не запрещает писатьтак как хотите вы — это ваше право, так проявите уважение и к другим. Придирки к форме и цепляния к словам, мне кажется, хороши для "священных войн" или там "философии", а для форума "декларативное программирование", мягко говоря, не то, что нужно. Тут не пионеры собрались, все все понимают. По существу вопроса у вас претензии есть, уважаемый Клапауций?
K>Я не против критики. Но считаю, что критика должна быть качественной, осторой, захватывающей, содержательной, интересной. K>Вместо этого предлагается очередное изложение изрядно надоевшей всем теории всеобщего идиотизма. Причем, как это обычно и бывает, сам продвигающий теорию ее последовательным сторонником не является, и сам себя идиотом не считает. K>Что она мне дает, как ищущему интересных сведений читателю форума? K>Что она дает мне, как ищущему развлечений читателю форума? K>Что она дает разработчикам Nemerle? K>Мой ответ на все три вопроса — "ничего".
Ай-ай. В форуме масса постов, которые мне, Gaperton-у, ничего не дают. Я их не читаю, и на них не отвечаю, потому, что никто не может заставить меня тратить время на то, что я делать не хочу. Уверен, так же поступаете и вы. У меня даже есть список авторов — ignore list.
С чего это вы, друг Клапауций, выбрали этот несчастный пост, и стали его клеймить по столь банальной, трюальной (извините, не знаю, что это слово значит, но красиво звучит, мне понравилось. "Трюизм", говорите?), и всем надоевшей причине?
Короче, по моему скромнейшему мнению, то, что вы перечислили — совсем не повод отвечать так, как это делаете как вы.
K>Тезис о том, что выхолощенный язык позволяет писать понятнее мне кажется неверным. Возможностей любого выхолощенного языка для написания абсолютно нечитабельного кода более чем достаточно, в то время как средств для того чтобы писать читабельно — как правило не хватает. K>Ваши претензии к макросам — понятны. Претензии ласточкина к макросам наводят только на мысль о том, что он вообще не понимает о чем говорит. K>Поэтому я и утверждаю, что тема критики Nemerle ласточкиным абсолютно не раскрыта.
Ну да. То что вы оценили письмо ласточкина в киллограм/амперах — я заметил
С остальным, т.е. по существу вопроса, я с вами по большей части согласен.
Здравствуйте, lomeo, Вы писали:
L>Я не отвечал на вопрос "где примеры последовательности". Мои слова всего лишь повод задуматься:
Думать о домыслах? Нет уж. Увольте.
L> во-первых, есть люди, которым не нравится синтаксис Немерле именно своей нечеткостью,
Термин "нечеткостью" недетерминирован. Обсуждать его слова нет.
Так что или вдохни в него хоть какой-то смысл, или преркрати "засорять эфир".
L> во-вторых, это люди определенного круга, в-третьих,
Люди определенного круга могут свербить по разному кругу проблем. Так что это не разговор.
L>на официальном сайте не дается ни опровержения, ни согласия с этим замечанием, подчеркивая, мол "есть мнение".
Совершенно естественно, что на официальном сайте не обсуждаются домыслы. Сформулируй вопрос, получишь ответ.
L>Т.е. примеры ничего не скажут — кому то они покажут, что синтаксис нечеткий (непоследовательность — немного не то слово), кому то нет.
Подытожим. Хоть каких-то критериев "нечеткости" ты сформулировать не всилах. Так как есть люди (о чем ты сам и говоришь) считающие синтаксис Nemerle продуманным и последователным, то высказанный тезис является на поверку всего лишь твоим подспудным мнением.
Так что мы обсуждаем? Частное мнение несколькоих человек толком не пробовавших программировать на языке?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
G>>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...
IT>Но сначала они получили неслабое конкуретное преимущество, не так ли? А потом не смогли, не захотели, не договорились. И как это обычно водится в больших компаниях, нашёлся какой-нибудь ушлый манагер, который на затаптывании старого кода и его переписывании сделал себе карьеру.
Кстати, популярность Яху была на пике именно в его времена, а как Грэхем ушел, так начала падать. Хотя все это домыслы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, популярность Яху была на пике именно в его времена, а как Грэхем ушел, так начала падать. Хотя все это домыслы.
А, может, и как только популярность начала падать, так Грэхем и ушел. Кто ж его знает...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VD>>Кстати, популярность Яху была на пике именно в его времена, а как Грэхем ушел, так начала падать. Хотя все это домыслы.
ПК>А, может, и как только популярность начала падать, так Грэхем и ушел. Кто ж его знает...
Думаю, ни то ни другое — Грэм с Моррисом ушли, чтобы создать свою компанию и получить независимость, которую они потеряли, слившись с Яху.
Продали свои акции и создали Y Combinator.
Предполагать, что обороты большой компании как-то зависят как-то от языка программирования в отдельном проекте — это нужно быть законченным романтиком, типа старого руководства DEC.
Они зависят, только когда компания маленькая и линейка продуктов тоже маленькая — так было с Грэмом и Моррисом до слияния с Яху и к этому они в результате вернулись. Сам Грэм неоднократно об этом писал.
прежде чем понять рекурсию, необходимо понять рекурсию.
Здравствуйте, Gaperton, Вы писали:
G>Т.е. на лиспе писать без макросов смысла нет, он от тебя ускользает. Что характерно, я с тобой в этом согласен. Теперь объясни мне, согласному с тобой, какой смысл писать на Немерле, если макрописателей придется (от греха) ограничивать.
Смысл очень простой. И он не один.
1. Немерле сам по себе неплохой язык. В дотнет он интегрирован просто изумительно. Вот МС сейчас готовит выпуск третьего фрэймворка которы на самом деле является навороченными библиотеками в области комуникации, GUI, воркфлоу и т.п. Немерле позволяет использовать все это из функционального языка без каких либо натяжек.
2. Мокросы могут создаваться опытными членами команды (которых обычо бывает очень не много, так как он редко уживаются с такими же как они ), документироваться, тестироваться и отдаваться менее опытным программистам для использования.
3. Можно использовать готовые макро-библиотеки, например, O/R Mappper.
G>ЗЫ: Погубить эта возможность Немерле ИМХО не может. Он еще не дошел до того состояния, чтобы его что-то вообще могло "погубить".
+1
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>if, for, foreach, &&, ||... и многое другое в немерле макросы. Что в них не понятно?
В них и не должно быть что-либо понятно. Макросы это особенность реализации и не более. 99% программистов не вникают в такие вещи.
WH>А может не понятен код типа $"var1 = $var1"? Так лично я его понял даже не заглядывая в документацию по немерле.
Вобще-то да, не понятен. Я сам такое видел только в PHP (кажется есть и в перле, но я его не знаю). Если бы не знал PHP, то вообще бы не понял что это такое.
WH>И что касается памяти человека: После определенной тренировки человек может запоминять буквально все что воспринимает через все известные и не очень органы чувств.
Я вот больше того что мне надо для работы не помню, в MSDN гляжу. Извечный вопрос — а оно того стоит, так напрягаться-то? И есть ли в необходимом количестве программисты способные и желающие так напрячься.
WH>К тому же память человека очень хорошо востанавливается по ассациациям те человек может полностью что-то забыть но если ему подсунуть какойто намек на это то он очень быстро все вспоминает. Те если человек один раз запомнил макрос то дальше даже если он этот макрос забудет он его вспомнит сразу же после того как снова увидит.
Есть разница между тем что-бы вспомнить сам макрос и вспомнить как им пользоваться. Я помню что вывод делатьеся через Console.Wrile[Line], но все перегрузки наизусть не помню. Если будет нормальный IntelliSence то это конечно не так страшно... будет ли? Не в смысле конкретной реализации, а в смысле возвожности такой подсказки к макросу, что бы из неё было понятно как им пользоваться.
WH>Я этот принцип прекрасно знаю. Но если проще означает в 10 раз больше кода... то это "проще" превращается в массу проблем при поддержке.
Разве в 10 раз? ИМХО такого отношения даже в Pure C vs С++ Metaprogramming не вознимает. Ну будет раза в два больше, зато понятного. И уход (болезнь, декрет) ведущего разработчика, великого магистра Nemerle и кавалера ордена метапрограммирования второй степени не оставит фирме неподдерживаемый код. ведь проблема Nemerle в том что множество его крутых фиг только из Nemerle и доступны. Нельзя на Nemerle написать макрос для VB.Net. С классами/функциями в этом смысле проще.
Здравствуйте, Андрей Хропов, Вы писали:
L>>1) Преувеличение мыслительных способностей программистов, а и людей вообще. В реальности они довольно ограничены. АХ>К счастью не все тупые . Иногда встречаю умных на жизненном пути.
Ключевое слово иногда. Язык которым могут, пусть и поверхностно, пользоваться (хотя бы читать) массы не жизнеспособен.
Здравствуйте, CopyPaste, Вы писали:
CP> Так почему вообще кто-то должен рассчитывать на ограниченных? Только то, что ограниченные обезьянки стоят дёшево ещё не делает категорическим императивом требование угождать обезьянкам. Есть (и прекрасно себя зарекомендовали) бизнес-модели, построенные на привлечении самых лучших и самых дорогостоящих кадров. Да, в программировании это пока что редкость, но в других отраслях (например, у банкиров) это норма. Так почему, с какой такой радости IT-индустрия перед обезьянками обязана "ку" делать?!?
Потому что зарплата программиста это одна из основных статей расхода и более дешёвый программист это для многих задач выгоднее, чем более дорогой, при условии, конечно, что более дешёвый справиться. Это, не всегда так.
CP> Верно. И тут как раз и нужен язык с неограниченным сверху уровнем абстракций. Язык, который можно было бы сделать близким к естественному человеческому языку в каждой из предметных областей.
Кому он нужен? Будут проблемы непонимания. как и с естественным языком.
L>>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная) видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста.
CP> Не программиста, а обезьянку. Обезьянок надо уволить и никогда больше на них не рассчитывать. Пусть улицы подметают. Бизнес-модель "шапками нах закидаем!" пора отправить на помойку истории.
Здравствуйте, CopyPaste, Вы писали:
CP> Да кого блин интересуют проблемы 80% недочеловеков?!? То, что так исторически сложилось, что их принято употреблять в IT-индустрии — это просто глюк. В других индустриях это редкость. Пора забыть про обезьянок! Индустрия без них обойдётся!
Ага. Ща пальцами щёлкнем и все дураки сразу исчезнут. Только вот гении от этого не появяться, а спрос на рабочие места надо удовлетворить.
Здравствуйте, CopyPaste, Вы писали:
CP> В таких ситуациях и нужно метапрограммирование — сначала создаёшь язык, потом на нём как можно более просто и понятно описываешь сложную логику.
Да, только вот обезьянки еле шарп выучили, а ты им новый язык для которого даже нормальной документации нет. Огорчаться, однако.
Здравствуйте, CopyPaste, Вы писали:
CP> Вот скажи, тебе что приятнее и понятнее читать — EBNF, или написанный на Си конечный автомат, из этого самого EBNF сделанный? Тебе проще читать XML-описание виджетов на гуёвой формочке, или C++-ный код поверх кошмарного MFC?
Плохой пример искажающий ситуацию. EBNF в отличие от твоих поделок во многих своих проявлениях стандартизирован и о нём можно много где почитать.
Здравствуйте, adontz, Вы писали:
A>Ага. Ща пальцами щёлкнем и все дураки сразу исчезнут. Только вот гении от этого не появяться, а спрос на рабочие места надо удовлетворить.
Дык с хорошим инструментом меньшее количество хороших пограммистов сможет решить большее количество задач. Это уже хоргшо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Да, только вот обезьянки еле шарп выучили, а ты им новый язык для которого даже нормальной документации нет. Огорчаться, однако.
Дык он же говорит о простом, специализированном языке. Такой язык любая обезьянка выучит на раз. Причем мы можем зажать обезьянок в жусткие условия контроля и они смогут сделать намного меньше ошибок чем если бы они писали тоже самое на универсальном языке.
В общем, тут рассчет очень прост. Чем выше уровень, тем проще всем. В том числе и обезьянкам. А если всем легче, то можно решать более сложные/объемные задачи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Плохой пример искажающий ситуацию. EBNF в отличие от твоих поделок во многих своих проявлениях стандартизирован и о нём можно много где почитать.
Как раз EBNF не стандартизирован. BNF был просто один. А EBNF это целый класс его расширения. Когда Бэкус и Науэр изобрели этот язык он был не более чем DSL-ем созданным на коленке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Есть разница между тем что-бы вспомнить сам макрос и вспомнить как им пользоваться. Я помню что вывод делатьеся через Console.Wrile[Line], но все перегрузки наизусть не помню. Если будет нормальный IntelliSence то это конечно не так страшно... будет ли? Не в смысле конкретной реализации, а в смысле возвожности такой подсказки к макросу, что бы из неё было понятно как им пользоваться.
Прочел твое сообщение и решил поделиться тем что уже реализовано из интелисенста.
Что касается подсказок к "мусору". Тут как с библиотеками. Хороший макрос должен быть интуитивен и документирован. Тогда и проблем с ним не будет. А в обратном случае проблемы будут и с простыми классами/функциями.
A>Разве в 10 раз? ИМХО такого отношения даже в Pure C vs С++ Metaprogramming не вознимает.
Сморя где. Думаю, если сравнить объем исходников компилятора одинаковой сложности написанного на Немерле и С, то разница будет и по более чем в 10 раз. Если конечно внешним генератором кода не воспользоваться.
A> Ну будет раза в два больше, зато понятного.
Вообще-то даже в два раза — это уже возможность решать в два раза более сложные задачи, или в два раза более объемные, или в два раза быстрее.
Но главное, по моему — это именно то что можно решать более сложные задачи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дык с хорошим инструментом меньшее количество хороших пограммистов сможет решить большее количество задач. Это уже хорошо.
Согласен, но не совсем. Работодатель устанавливает зарплату программисту за его потенциальную способность решить задачу. Те кто пишет, программы продают их благодаря функциональности, а не использовавшемуся языку программирования. Программы на VC++ и Delphi делающие одно и то же стоят приблизительно одинаково. С другой стороны работодателю выгоднее подсунуть разработчику такой инструмент чтобы за то же самое время было сделано больше работы. Ну и, соответсвенно, найти разработчика, который бы умел пользоваться таким инструментом. Тогда себестоимость продукта окажется ниже. Однако, прежде чем написать программу надо продумать что именно будет написано, а следовательно у нас есть какие-то постоянные расходы на написание не зависящие от языка программирования. Как результат нельзя повышать эффективность отдельно взятого разработчика бесконечно. Приходиться нанимать нескольких. Эти несколько разработчиков никогда не будут равноправны, хотя бы потому что не из инкубатора. Кто-то будет делать более сложную работу, а кто-то более простую. Причём сразу возникает две проблемы. Во-первых, тот кто делает сложную работу должен её делать не только хорошо, но и понятно, чтобы со сменой ведущего разработчика не пришлось переписывать пол-проекта. Во-вторых, простая работа должна выполняться просто. Если надо скачать из Интернета файл и записать на диск, то для этого не должно быть необходимо выучить новый язык и 3 библиотеки к нему. Как эти две проблемы решает Nemerle лично мне не совсем понятно, что конечно не означает что он их не решает. На последок всё же, хочу заметить, что в Nemerle можно добавить самопальные макросы и даже построить неплохой DSL удобно решающий конкретную задачу, но нельзя ничего убрать. Возникает опасение, не получим ли мы ситуацию как с распределением памяти в Си++, где Си был расширен кучей средств априори предотвращающх утечки, но, тем не менее, это не спасло, потому что можно расширить язык, но нельзя заставить использовать только его часть, причём далеко не самую старую и знакомую?
Здравствуйте, VladD2, Вы писали:
VD>Дык он же говорит о простом, специализированном языке. Такой язык любая обезьянка выучит на раз. Причем мы можем зажать обезьянок в жусткие условия контроля и они смогут сделать намного меньше ошибок чем если бы они писали тоже самое на универсальном языке.
Ты можешь добавить что-то в Nemerle, Например макросы которые позволят прямо в программе описывать интерфейс на HTML Но ты не можешь убрать то, что уже есть. Не можешь помешать использовать что-то за гранью своих макросов.
Здравствуйте, VladD2, Вы писали:
VD>Как раз EBNF не стандартизирован. BNF был просто один. А EBNF это целый класс его расширения. Когда Бэкус и Науэр изобрели этот язык он был не более чем DSL-ем созданным на коленке.
Я думаю сам факт, что аббревиатура EBNF не вызвает вопросов "а что это?" уже о многом говорит
Здравствуйте, VladD2, Вы писали:
VD>Прочел твое сообщение и решил поделиться тем что уже реализовано из интелисенста. VD>Вот глядите: Небольшой отчет о сделанной работе
Честно говоря именно подстказка к макросу и не впечатила. Нужно было что-то вроде
while (Continue_Condition)
{
Action;
}
а не тот кошмар со скриншота. Из подсказки выше понятно, например, что надо записать условие продолжения цикла, а не прерывания. Ну и вообще, while понятная конктрукция и уже проблемы, а что с непонятными-то будет? Писать XML DOC не предлагай. Функциям во многом хватает правильных имён у типизированных параметров. Имеем проблему. Может и не очень большую, но всё таки. На самом деле большую, потому что к while документация есть, а будет ли она с кустарным макросам? Чую, что придёться принудительно писать XML DOC потому что иначе никак.
VD>Вообще-то даже в два раза — это уже возможность решать в два раза более сложные задачи, или в два раза более объемные, или в два раза быстрее. VD>Но главное, по моему — это именно то что можно решать более сложные задачи.
Не, насчёт сложности это ты загнул. Если голова не варит, то никакой язык не поможет. Что касаеться скорости... тут как и везде в бизнесе надо считать риски. Вполне может быть, что лучше написать в два раза больше кода, который любой сможет подправить, чем в два раза меньше, гениального, но который некому поддерживать.
Здравствуйте, adontz, Вы писали:
A>Ты можешь добавить что-то в Nemerle, Например макросы которые позволят прямо в программе описывать интерфейс на HTML Но ты не можешь убрать то, что уже есть. Не можешь помешать использовать что-то за гранью своих макросов.
Могу. Я и только я определяю что будет использоваться в моем коде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Честно говоря именно подстказка к макросу и не впечатила.
Это от непонимания.
A> Нужно было что-то вроде A>
A>while (Continue_Condition)
A>{
A> Action;
A>}
А зачем показывать в хинте исходный код? Хинт открывает потаенную информацию. Он пказывает сгенерированный в реальности код.
A>а не тот кошмар со скриншота.
Это не кошмар. Просто код макроса должен быть универсален. Конечно можно навыпендриваться и для частных случаев (например, для циклов в которых нет return/continue/break) создать частный код. Но реально это не очень то и нужно.
Кстати, возможно послед завершения Интеграции народ будет менее беззаботно относиться к генерируему макросом коду. Ведь он сможет увидить его. А эти макросы писались теми кто их результат не видел. Оптимизатор же убирает все различия, так что авторам макросов было совершенно все равно.
A> Из подсказки выше понятно, например, что надо записать условие продолжения цикла, а не прерывания. Ну и вообще, while понятная конктрукция и уже проблемы, а что с непонятными-то будет?
Для использования макросов знать что они генерируют нет особого смысла. Если тебе не важно, то можешь не смотреть хинт на них или воспринимать код как черный ящик. А вот при отладке макросов очень важно видеть что за код получился при определенных условиях.
A> Писать XML DOC не предлагай. Функциям во многом хватает правильных имён у типизированных параметров.
Во многих хватет. Но если не хватет, то почему бы не написать коментарий? Информация редко бывает лишней.
A> Имеем проблему. Может и не очень большую, но всё таки. На самом деле большую, потому что к while документация есть, а будет ли она с кустарным макросам?
Дык зависит от автора. Тут никаких различий с функциями и классами. Я уже устал это повторять. Будет подсказка — мы ее выведем.
A>Не, насчёт сложности это ты загнул. Если голова не варит, то никакой язык не поможет.
А причем тут неварящая голова? Производительность повысится у всех кроме тех кто и так ничего не делал. Если ее было ноль, то она останется равной нулю. А если больше нуля, то выростет.
A> Что касаеться скорости... тут как и везде в бизнесе надо считать риски. Вполне может быть, что лучше написать в два раза больше кода, который любой сможет подправить, чем в два раза меньше, гениального, но который некому поддерживать.
Код на Немерле точно так же сможет подправить любой если проблема не очень сложна. А если сложна, то этот код для начала просто будет невозможно спроектирвоать и написать. Упрощение задачи в двое возможно позволит это сделать. Ну, и "скилы" людей которые смогут его подправить могут быть в два раза меньше (ведь код будет в два раза проще).
Еще надо не забывать, о том, что проектирование тоже изменяется. Кодирование становится ближе к проектированию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Честно говоря именно подстказка к макросу и не впечатила. Нужно было что-то вроде A>
A>while (Continue_Condition)
A>{
A> Action;
A>}
A>а не тот кошмар со скриншота.
Всё будет. Работы над хинтами ведутся от силы недели две и формат кода, отображаемый для макросов — это не самая большая проблема. Я бы даже сказал, что это вообще не проблема. Отформатируем как надо, где не надо отрежем, где надо нарастим. Всё будет как в кино. Главное сейчас то, что эти картинки не из фотошопа, а результат взаимодействия кода интеграции и компилятора, что в свою очередь доказывает, что всё это можно сделать.
ЗЫ. Влад ещё не очень удачный пример привёл, using смотрится гораздо более забавно. Там сразу виден сахарок try/finally. И, не исключено, что с такими подсказками макросы будут работать не во вред здоровью, а совсем даже на пользу, т.к. будут способствовать более чёткому пониманию того, как работает компилятор и как оно всё крутится внутри.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Как раз EBNF не стандартизирован. BNF был просто один. А EBNF это целый класс его расширения. Когда Бэкус и Науэр изобрели этот язык он был не более чем DSL-ем созданным на коленке.
A>Я думаю сам факт, что аббревиатура EBNF не вызвает вопросов "а что это?" уже о многом говорит
International Standard ISO/IEC 14977 specifies a standard version of the Extended Backus-Naur form of context-free grammars.
Здравствуйте, VladD2, Вы писали:
A>>Ты можешь добавить что-то в Nemerle, Например макросы которые позволят прямо в программе описывать интерфейс на HTML Но ты не можешь убрать то, что уже есть. Не можешь помешать использовать что-то за гранью своих макросов. VD>Могу. Я и только я определяю что будет использоваться в моем коде.
Здравствуйте, Gaperton, Вы писали:
K>>Я и не отрицал, что в сообщении ласточкина есть рациональное зерно, но полную ахинею написать вообще гораздо труднее, чем кажется. G>На самом деле довольно просто, судя по ее распространенности в философии программирования.
Вся магия тут в свободе трактовки.
K>>Лично для меня утверждение о том, что "Literate Programming — это хорошо" — абсолютнейший трюизм. Я вообще не припоминаю чтобы кто-то утверждал что это плохо. Зато я и не припоминаю двух людей, чье представление о "Literate" хорошо согласовывалось.
G>Дело не в том, что люди утверждают, что это плохо (мало кому придет в голову спорить с Кнутом — для этого надо быть или очень умным, или напротив — полным дураком). Дело в том, что люди понимают, что такое LP, но не понимают, зачем это, и забывают об этом.
Мне кажется, что проблема даже не в том, что кто-то что-то забывает. Проблема гораздо серьезнее. Она в том, что представления о читабельности кода черезвычайно субъективны и коренным образом разнятся у разных людей. С этим никакими напоминаниями не справится.
G>Когда мне кажется, что вы, Клапауций, забыли о чем-то, то я беру на себя смелость вам об это напомнить. Даже если это, извините, тупо, тривиально, и просто. И не говорите мне, что вы ничего не забываете, никогда ничего не упускаете, и не ошибаетесь. Как вам напомнил Ласточкин (тупо и тривиально), человеческие возможности ограничены. Извините, но тот факт, что вы, как мне кажется, забыли или упустили какую-то тривиальную вещь, не является поводом вам о не не напомнить. Хуже вам от этого не станет, и более того — я всегда стараюсь говорить просто, доходчиво, и тривиально, а не впечатление производить.
Ну так я всегда благодарен за напоминания. И то что говорить нужно доходчиво тоже считаю.
G>Какой вы однако капризный . Пианист играет как умеет. Это его посты, он пишет так, как считает нужным. Вам в ваших постах никто не запрещает писатьтак как хотите вы — это ваше право, так проявите уважение и к другим. Придирки к форме и цепляния к словам, мне кажется, хороши для "священных войн" или там "философии", а для форума "декларативное программирование", мягко говоря, не то, что нужно. Тут не пионеры собрались, все все понимают.
С моей стороны нелепо было бы кому-то что-то запрещать здесь. Я этого и не делаю. Но я имею полное право, оставаясь в рамках правил, высказать все что я думаю, о мнении другого, точно также как и Вы имеете полное право высказать свое мнение о моей оценке. Именно это и происходит. Все замечательно, зрители усталые но довольные расходятся по домам.
Но этой теме вообще место скорее в "философии" откуда она, по видимому, скатится таки в "священные войны"
G>По существу вопроса у вас претензии есть, уважаемый Клапауций?
А как же. Я эту претензию и высказывал. Убогость никак не является гарантией понятности и безопасности. Напротив она прищемляет возможности так, что зачастую не оставляет иного выбора, кроме как писать ужасную белиберду. Другими словами, упрощенный язык ограничивает понятность сверху, а не снизу. Снизу ее ограничить, по всей видимости, вообще невозможно.
G>С чего это вы, друг Клапауций, выбрали этот несчастный пост, и стали его клеймить по столь банальной, трюальной (извините, не знаю, что это слово значит, но красиво звучит, мне понравилось. "Трюизм", говорите?), и всем надоевшей причине?
Прошу меня простить за употребление такого сложного слова. Постараюсь в будущем этой ошибки не повторять.
G>Короче, по моему скромнейшему мнению, то, что вы перечислили — совсем не повод отвечать так, как это делаете как вы.
Это нормально. Как нормально и то, что мое скромное мнение об этом другое.
G>С остальным, т.е. по существу вопроса, я с вами по большей части согласен.
Аналогично.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: Почему у Nemerle нет будущего
От:
Аноним
Дата:
24.08.06 18:03
Оценка:
На 300% согласен со всеми утверждениями и уже работаю в этом направлении...
Извиняюсь за поздний ответ — был в отпуске.
L>>Я не отвечал на вопрос "где примеры последовательности". Мои слова всего лишь повод задуматься:
VD>Думать о домыслах? Нет уж. Увольте.
Я тебя не нанимал, не мне и увольнять :-)
Влад, я тоже могу давать подстрочник, придираясь к словам, но стараюсь этого не делать, так как в общении с собеседником в первую очередь ищу понимания. Моя же попытка объясниться не была услышана, потому что ты не хочешь подумать. А тут я ничего поделать уже не могу :-(
Здравствуйте, lomeo, Вы писали:
L>Я тебя не нанимал, не мне и увольнять L>Влад, я тоже могу давать подстрочник, придираясь к словам, но стараюсь этого не делать, так как в общении с собеседником в первую очередь ищу понимания. Моя же попытка объясниться не была услышана, потому что ты не хочешь подумать. А тут я ничего поделать уже не могу
Да, я и так думаю. Причем во всю. Просто мысли у меня другие. Вот и хочется услышать какие-то весомые аргумениты и факты от оппонента.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
Если нам не помогут, то мы тоже никого не пощадим.
