КМВ>Авторы: КМВ> 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 запомнится и результат будет правильный.
.
Если нам не помогут, то мы тоже никого не пощадим.
