Сначала он говорит о лексемах, но не знает что они называются термином "лексема", а придумывает свой термин — "элемент". Потом он упоминает, что не понимает что такое регулярный язык. Странно все это...
А вообще, если судить именно по краткости, то самыми краткими языками являются декларативные языки, например, Пролог — по краткости (по количеству лексем) он "сделает" любой императивный язык программирования.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Пол Грэм. Краткость — сила.
В статье ни разу не употреблено важное слово: библиотека (например, си++ с boost-ом и без — две большие разницы). Без его учета все рассуждения о краткости идут лесом.
Да и про IDE тоже ничего не говорится
Здравствуйте, eugals, Вы писали:
E>В статье ни разу не употреблено важное слово: библиотека (например, си++ с boost-ом и без — две большие разницы). Без его учета все рассуждения о краткости идут лесом.
1. Библиотеки ведь тоже кто-то пишет.
2. Лисп с библиотеками и Лисп без библиотек — тоже "две большие разницы". Но можно сравнить Лисп с библиотеками
си++ с библиотеками или их же, но без. E>Да и про IDE тоже ничего не говорится
А как IDE влияет на краткость
Здравствуйте, Трурль, Вы писали:
Т>1. Библиотеки ведь тоже кто-то пишет.
Кто бы их ни писал, факт в том, что само их наличие существенно влияет на краткость получаемых решений.
При всей лаконичности языка, если под него существует мало библиотек, он однозначно хуже более многословного, но хорошо расширяемого соперника. По критериям самого же Грема:
Думаю, лучшей мерой величины программы может быть количество элементов, где элементом является что-либо, могущее стать отдельной вершиной в дереве исходного кода. Имя переменной или функции есть элемент; целое или вещественное число есть элемент; сегмент текстового литерала есть элемент; элемент паттерна или форматной директивы есть элемент.
Использование библиотек (стандартных или сторонних) во многих случаях помогает сокращать указанное "количество элементов кода". Тем более в рамках предложенного способа сравнения:
Такие исследования, как сравнение языков программирования Лутца Прекельта, хоть и приводят к ожидаемым результатам, но склонны использовать задачи, которые слишком малы для осмысленного теста. Лучший тест для языка — это то, что происходит в программах, написанных за месяц.
Во всей статье речь идет не о гипотетических преимуществах какого-либо из языков программирования. Сравнение предполагается именно с позиции промышленного программирования, а в нем наличие библиотек является существенным (даже главным) криерием выбора средства разработки. Странно, что приходится это объяснять.
Т>2. Лисп с библиотеками и Лисп без библиотек — тоже "две большие разницы".
Я по поводу Лиспа ничего плохого и не говорил.
Т>А как IDE влияет на краткость
Она напрямую влияет на скорость разработки, ради достижения которой всё это сравнение и затевается.
Здравствуйте, eugals, Вы писали: E>Здравствуйте, Трурль, Вы писали:
Т>>1. Библиотеки ведь тоже кто-то пишет. E>Кто бы их ни писал, факт в том, что само их наличие существенно влияет на краткость получаемых решений.
Я просто предлагал посмотреть с точки зрения разработчика библиотеки. Вопрос краткости встает в первозданной чистоте.
E>При всей лаконичности языка, если под него существует мало библиотек, он однозначно хуже более многословного, но хорошо расширяемого соперника.
Наличие большого количества уже написанных библиотек не означает автоматически хорошей расширяемости.
Насчет "однозначно хуже": если среди всей кучи библиотек нет того, что нужно для решения данной задачи, то она абсолютно бесполезна.
E>Во всей статье речь идет не о гипотетических преимуществах какого-либо из языков программирования. Сравнение предполагается именно с позиции промышленного программирования, а в нем наличие библиотек является существенным (даже главным) криерием выбора средства разработки. Странно, что приходится это объяснять.
Для самого Грэма наличие библиотек не являлось ни главным, ни даже существенным критерием выбора.
Т>>А как IDE влияет на краткость E>Она напрямую влияет на скорость разработки, ради достижения которой всё это сравнение и затевается.
Во-первых, влияние IDE на скорость разработки не столь уж существенно.
Во-вторых, скорость разработки не рассматривается как единственный критерий.
программы, написанные на более сильных языках, имеют тенденцию содержать меньше ошибок. Этого уже вполне достаточно, и вероятно в таких задачах, как сетевые коммутаторы, это важнее, чем производительность программиста.
Здравствуйте, Трурль, Вы писали:
Т>>>1. Библиотеки ведь тоже кто-то пишет. E>>Кто бы их ни писал, факт в том, что само их наличие существенно влияет на краткость получаемых решений. Т>Я просто предлагал посмотреть с точки зрения разработчика библиотеки. Вопрос краткости встает в первозданной чистоте.
Ты — да. У него я такого не увидел (особенно, в контексте упоминаемой в начале статью "Мести зануд").
Что же касается проблем разработчика библиотек (первозданной чистоты), то тут тоже не всё ясно. Считать ли STL или boost или, скажем, builtin-функции python-а частью языка или же независимыми "элементами кода"...
спорный вопрос, а про него не сказано ни слова.
Т>Наличие большого количества уже написанных библиотек не означает автоматически хорошей расширяемости.
+1 Т>Насчет "однозначно хуже": если среди всей кучи библиотек нет того, что нужно для решения данной задачи, то она абсолютно бесполезна.
Да конечно, но это ведь не значит, что про существование библиотек нужно забывать вообще, рассматривать язык в отрыве от наработанных под него паттернов, сред разработки и т.п.
Т>Для самого Грэма наличие библиотек не являлось ни главным, ни даже существенным критерием выбора.
Вот я про это и говорю
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Сначала он говорит о лексемах, но не знает что они называются термином "лексема", а придумывает свой термин — "элемент". Потом он упоминает, что не понимает что такое регулярный язык. Странно все это...
Насчет лексем (tokens) — действительно странно для человека, создающего языки и компиляторы. Но это всего лишь вопрос терминов.
Регулярность языка программирования: вот этого и я тоже не понимаю. В математическом смысле "регулярность" — это прибл. правильность. Правильный язык программирования? Вы знаете такой язык?
Проще говорить, например, о естественности языков программирования, да и языков вообще. Надо полагать эсперанто и подбные ему создавались как "регулярные" языки, однако не прижились именно ввиду своей неестественности. Это не означает, что "придуманный" язык не может стать естественным для человека, но такой язык еще не создан.
Пол Грэм по сути хочет подвести нас к мысли, что естественность есть краткость. По крайней мере так я его понимаю. Но это спорное утверждение, чего и сам автор не отрицает. Это всего лишь гипотеза стоящая того, чтобы задуматься над ней.
Но такая сверхчувствительность обернется тем, что неуклюжие языки станут для вас невыносимыми. Я нахожу программирование на языках, которые не имеют макросов, невыносимо ограничивающим, так же как если бы кто-то привыкший к динамической типизации посчитал бы невыносимо ограничивающим возврат в языки, где следует описывать типы для каждой объявляемой переменной и невозможно объявить список, состоящий из элементов разных типов.
Здесь надо вспомнить, что Грэм — поклонник языка Lisp, и под словом "макросы" он подразумевает Lisp-макросы, а не макросы C.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cron Tab, Вы писали:
CT>Регулярность языка программирования: вот этого и я тоже не понимаю. В математическом смысле "регулярность" — это прибл. правильность. Правильный язык программирования? Вы знаете такой язык?
Регулярный язык — это язык порождаемый регулярной грамматикой.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Регулярный язык — это язык порождаемый регулярной грамматикой.
Здесь проблема перевода. "Regular language" — необязательно "регулярный язык".
Здравствуйте, Трурль, Вы писали:
Т>Одна такая вакуумная лошадка принесла авторам $40M.
Особенно вот это:
Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
Здравствуйте, Дарней, Вы писали:
Д> Д>Особенно вот это: Д>
Д> Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
Да. Цитата в точку. Я бы дополнил бы эти слова еще тем, что большинство людей противятся новооведениям.
Видимо поэтому на рэнок вылезает только то, что хорошо пропихивается.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Дарней, Вы писали:
Д>>А кто-нибудь в курсе, что такое "лексическое замыкание"? (lexical closure) Т>То же самое, что "лямбда-выражение".
А почему "лексикал"?
ЗЫ
Замыкание — чертовски не подходящий перевод для closure.
Мне кажется, что именно некудышные названия затрудняют понимание этой простой идеи. Безымянные функции было бы куда более понятно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Замыкание — чертовски не подходящий перевод для closure.
VD>Мне кажется, что именно некудышные названия затрудняют понимание этой простой идеи. Безымянные функции было бы куда более понятно.
Тогда понятно! И правда — название не самое удачное.
Здравствуйте, VladD2, Вы писали:
VD>А почему "лексикал"?
Так уж сложилось исторически. Сначала в Лиспе использовалось динамическое связывание имен. В Scheme было введено статическое (лексическое) связывание. Вот и возникли "lexical closure" и "dynamic closure".
VD>Замыкание — чертовски не подходящий перевод для closure.
Перевод подходящий, сам термин неудачный. VD>Мне кажется, что именно некудышные названия затрудняют понимание этой простой идеи. Безымянные функции было бы куда более понятно.
Вменяемые люди употребляют термин "замыкание" только для обозначения структуры данных, представляющей безымянные функции.
Здравствуйте, Трурль, Вы писали:
Т>Так уж сложилось исторически. Сначала в Лиспе использовалось динамическое связывание имен. В Scheme было введено статическое (лексическое) связывание. Вот и возникли "lexical closure" и "dynamic closure".
Не совсем понял, чем отличаются эти два сабжа
А где можно про это почитать?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Трурль, Вы писали:
Т>>Так уж сложилось исторически. Сначала в Лиспе использовалось динамическое связывание имен. В Scheme было введено статическое (лексическое) связывание. Вот и возникли "lexical closure" и "dynamic closure".
Д>Не совсем понял, чем отличаются эти два сабжа
На клиппере/фоксе не доводилось программировать?
proc a
x = 1
do c
proc b
x = 2
do c
proc c
x = x + 1
При вызове из a и из b переменная x в c связывается с разными переменными. Вот это называется динамическим связыванием.
Здравствуйте, Трурль, Вы писали:
Т>На клиппере/фоксе не доводилось программировать?
Нет, не приходилось. Но идею кажется понял.
А статическое связывание — это то, которое реализовано в .NET 2.0? Хотя там это не совсем связывание... но эффект аналогичный.
Здравствуйте, Дарней, Вы писали:
Д>А статическое связывание — это то, которое реализовано в .NET 2.0?
Статическое связывание — то, что используется в большинстве языков.
Здравствуйте, VladD2, Вы писали:
Д>> Д>>Особенно вот это: Д>>
Д>> Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
VD>Да. Цитата в точку. Я бы дополнил бы эти слова еще тем, что большинство людей противятся новооведениям.
Только вот Грэхем намекает на то, что нововведение — это Lisp, а не подкрашенный C.
VD>Видимо поэтому на рэнок вылезает только то, что хорошо пропихивается.
То, что пропихивается — всегда вылезает.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Только вот Грэхем намекает на то, что нововведение — это Lisp, а не подкрашенный C.
Для тех кто не в силах уловить смысл сказанного, поясню его слова. О Лиспе как о новооведении он конечно не говорит. У него с мозгами еще все впорядке, чтобы называть язык 60-го года нововедением. Он говорит, о том, что считает Лисп более мощьным (или высокоуровневым языком). Причем делает он это на основании того, что в лиспе имеется мощьнейшая система метапрограммирования. Тут с ним тяжело не согласиться. Метапрограммирование действительно мощьнейший механизм. Вот только он есть не только в Лиспе. На сегодня есть так же OpenC++ и R#
. Однако он совершенно прав, в том, что костность мышления очень сильна. И большинство людей не в силах разглядеть действительно мощьное решение потому как мыслить понятиями "Блабла".
VD>>Видимо поэтому на рэнок вылезает только то, что хорошо пропихивается. ГВ>То, что пропихивается — всегда вылезает.
Чушь. Вылезают только то что может вылезти и во что вкладываются деньги. Например, МС вбухала море денег в ДиджиталДашборд. Результат нулевой.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Трурль, Вы писали:
Т>Вменяемые люди употребляют термин "замыкание" только для обозначения структуры данных, представляющей безымянные функции.
Именитые называют это делегатами.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> Он говорит, о том, что считает Лисп более мощьным (или высокоуровневым языком). Причем делает он это на основании того, что в лиспе имеется мощьнейшая система метапрограммирования. Тут с ним тяжело не согласиться. Метапрограммирование действительно мощьнейший механизм. Вот только он есть не только в Лиспе. На сегодня есть так же OpenC++ и R#
Ну, я бы все-таки не стал ставить OpenC++ и R# в один ряд с макросами Лиспа... Там метапрограммирование в полном объеме может легко продолжаться и во время исполнения программы.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Он говорит, о том, что считает Лисп более мощьным (или высокоуровневым языком). Причем делает он это на основании того, что в лиспе имеется мощьнейшая система метапрограммирования. Тут с ним тяжело не согласиться. Метапрограммирование действительно мощьнейший механизм. Вот только он есть не только в Лиспе. На сегодня есть так же OpenC++ и R#
.
ПК>Ну, я бы все-таки не стал ставить OpenC++ и R# в один ряд с макросами Лиспа...
А я стану. Разницы по сути нет. Просто Лиспу проще так ка он сам и его однные по сути АСТ и к тому же по сути интерпретируемый.
ПК> Там метапрограммирование в полном объеме может легко продолжаться и во время исполнения программы.
1. Если код нескомпилирован.
2. Ничего не мешает загрузать R# в рантайме. Только код будет намного шутрее. Сам код R#-а генерируется с его же помощью и тут же на ходу компилируется. Про OpenC++ ничего сказать не могу, так как лично с ним серьезно не возился.
Если говорить о динамической компиляции, то с R# пока что только одна проблема. Код приходится компилировать C#-повским компилятором. Который поднимается в виде отдельного процесса. Это приводит к тому, что компиляция занимает около 0.1 секунды. Если будет время доведу R# до стадии полноценного комилятора и будет не хуже лиспа, только писать можно бедет на скобокоорганизванном АСТ, а на C#.
PS
Кстати, похоже, что многоуровневые трансформации встречаются вообще не часто. Обычная задача для метапрограммирования — это преобразование некой простой модели в сложную (код на некотором языке). Тот же компилятор Лиспа, насколько я знаю так себя компилировал. Компилятор был преобразованием Лиспа в ассемблер (и то и другой были в виде S-выражений).
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Ну, я бы все-таки не стал ставить OpenC++ и R# в один ряд с макросами Лиспа...
> А я стану. Разницы по сути нет. Просто Лиспу проще так ка он сам и его однные по сути АСТ и к тому же по сути интерпретируемый.
Дык, об этом и речь идет До таких возможностей OpenC++ и R# — как до Луны. В остальном согласен.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Дык, об этом и речь идет До таких возможностей OpenC++ и R# — как до Луны.
До луны не так далего. Еще раз повторяю. Ты малость недооценивашь три фактора.
1. Необходимость многопроходного метапрограммирования. Оно не так и нужно, так как основная его задача преобразование простой модели в сложную.
2. Если надо, оно достаточно элементарно реализуется.
3. Наличие в менеджед-языках средств динамической работы. Это для С++ возможно есть проблемы с этим. А для дотнета нет. Там проблема в том, что слишко много в рантайме делается.
В любом случае, адептом Лиспа я точно не стану, так как меня блевать тянет от программирования в АСТ напичканом скобками. Так что прийдется развивать идею на базе наиболее близкого и пригодного, по моему мнению, продукта из досупных на сегодня.
В любом случае на сегодня народ Лисп не очень то принял. А метапрграммирование развивается на шаблонх С++. Это уж точно через одно место и убого до ужаса. R# точно будет более гибок.
С R# скорее будет проблемой
1. Найти оптимальный синтаксис трансформации (над этом я как раз и думаю сейчас).
2. Заставить народ поверить в R# и принять его. Вот тут действительно будут проблемы которые очень хорошо описал тов. Грэм тут http://www.nestor.minsk.by/sr/2003/07/30710.html
ПК> В остальном согласен.
Ну, может в этом мре что-то и изменится к лучшему.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ГВ>>Только вот Грэхем намекает на то, что нововведение — это Lisp, а не подкрашенный C. VD>Для тех кто не в силах уловить смысл сказанного, поясню его слова. О Лиспе как о новооведении он конечно не говорит.
Он говорит о нововведении, появляющемся по отношению привычному Блаб-континууму конкретного Блаб-программиста. C#, а равно и Java, никаких серьёзных нововведений по отношению к C++ не предлагают (во всяком случае, ничего такого, что нельзя было бы с относительной лёгкостью эмулировать на C++, притом с выигрышем в производительности и гибкости). Переносимость, это, по большому счёту — маркетинговый миф.
VD>У него с мозгами еще все впорядке, чтобы называть язык 60-го года нововедением.
Да нет, Lisp ещё старше, просто на нём умеет программировать ещё меньшее количество программистов, чем на C++. И здесь, кстати, есть любопытная вещь:
Макросы, появившиеся в Lisp'е в середине шестидесятых, до сих пор — терра инкогнита.
Да, Влад, согласен, у него с мозгами, похоже, всё в порядке (я не иронизирую)...
Что же в Lisp'е такого прекрасного? Если он такой замечательный, почему его не используют все? Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы. Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих. (Выделено мной — ГВ.)
И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии, но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.
и вот ещё интересно:
Используя метод индукции, приходишь к выводу, что только те программисты, которые понимают самый мощный язык(Выделено мной — ГВ.), в состоянии осознать полную картину разницы в мощности между различными языками (видимо, именно это имел ввиду Эрик Реймонд, когда говорил о том, что Lisp сделает вас лучше как программиста). Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
Если на С++ можно программировать "как на C", то на Lisp этого не получится по определению. Т.е., "порог вхождения" для этого языка можно охарактеризовать как "понимание Lisp", а не как "вчерашний Basic". Если некто воспитан на C или Basic, то для того, чтобы начать программировать на Lisp, нужно поменять свою модель мышления... иначе он будет на него ругаться как на недоделанный C. Или, как вариант, нужно иметь врождённую склонность к такому сдвигу модели. Я это называю гиперконструктивной ленью или — конструктивной гиперленью.
Обычно технология меняется быстро. Однако с языками программирования все по-другому — они не просто технология, они воплощают собой способ мышления(Выделено мной — ГВ.) программистов. Это наполовину технология, наполовину религия.
Ну а поскольку структурность мышления у отдельно взятого индивидуума эволюционирует очень медленно (в масштабах его жизни), то отсюда имеем "противление нововведениям". Одни привыкли мыслить в терминах "шаг-за-шагом, делай раз, делай два", другие — в терминах методов манипуляции структурами. Понятно, что первые создадут простое "пошаговое" усовершенствование типа добавления очередной законченной конструкции (добавят делегаты, или "модули", или ещё что-то в этом роде), а другие сделают новый механизм управления структурами (придумают Lisp или шаблоны для C++).
Однако я не думаю, что смогу убедить кого-нибудь (старше 25) выучить Lisp.
Понятно, также, что первые будут долго и нудно противиться новым для них подходам, опирающимся на манипулирование структурами (Зачем так сложно! Это же непонятно нормалному человеку!), а вторые будут падать в депрессию, если им навяжут плоды деятельности первых (Чего? Да это же можно было сделать так, так и так! Можно же сделать одну простенькую структурную модификацию! Да, кстати, а почему я не могу теперь вывернуть это наизнанку?). Такое деление ни плохо, ни хорошо — так есть. Плюсы и минусы есть и у первой и у второй группы — зависит от контекста.
Также мы были спокойны, если требовались разработчики на C++ или Java.
Напомню, что в 95 шаблоны только-только появлялись и представляли собой не меньшую, если не большую terra incognita, чем макросы Lisp. Они и сейчас не слишком-то э... популярны. Достаточно вспомнить, как упорно ты и другие (не будем показывать пальцем) пару лет назад уверяли, что шаблоны — это suxx и нагромождение треугольных скобок. Пока Microsoft не объяснила доходчиво, что таки нет, шаблоны — это не suxx, это даже почти рулез, но, тссс.. дети, таки ничего опасного — спички мы уже убрали!
VD>Он говорит, о том, что считает Лисп более мощьным (или высокоуровневым языком). Причем делает он это на основании того, что в лиспе имеется мощьнейшая система метапрограммирования. Тут с ним тяжело не согласиться. Метапрограммирование действительно мощьнейший механизм. Вот только он есть не только в Лиспе. На сегодня есть так же OpenC++ и R#
Влад, ты действительно сравнивал макросы Lisp и шаблоны С++? Напоминаю на всякий случай — с точки зрения Lisp-машины программа является и программой и данными одновременно. Поверь на слово: макросы Lisp не менее опасная вещь, чем шаблоны C++. Если не более.
VD>Однако он совершенно прав, в том, что костность мышления очень сильна. И большинство людей не в силах разглядеть действительно мощьное решение потому как мыслить понятиями "Блабла".
В точку.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Поверь на слово: макросы Lisp не менее опасная вещь, чем шаблоны C++. Если не более.
Опасности тоже разные бывают. Ассемблер очень опасен, и Лисп тоже опасен. Но опасны по разному
У одного опасность происходит от слишком близкого приближения к "железу", у другого — от слишком большого удаления.
Истина должна быть где-то между ними
Чтобы избежать "опасностей метапрограммирования", нужно иметь возможность удобного просмотра результирующего кода, в идеале — в любой момент времени исполнения программы.
Также очень желательно иметь информацию, откуда взялась каждая ветка кода — в результате применения некоего правила преобразования кода (с идентификатором этого правила), или из исходного кода проги.
По крайней мере, в режиме отладки.
ИМХО
Здравствуйте, Дарней, Вы писали:
ГВ>>Поверь на слово: макросы Lisp не менее опасная вещь, чем шаблоны C++. Если не более.
Д>Опасности тоже разные бывают. Ассемблер очень опасен, и Лисп тоже опасен. Но опасны по разному Д>У одного опасность происходит от слишком близкого приближения к "железу", у другого — от слишком большого удаления.
Не, не в этом дело. Вопрос в понятности кода. А завернуть непонятную программу можно на чём угодно — хоть на макросах, хоть на бейсике. А что такое "понятность"... э... это уже индивидуально.
Д>Истина должна быть где-то между ними
Я думаю, что истина где-то вне этих определений.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не, не в этом дело. Вопрос в понятности кода. А завернуть непонятную программу можно на чём угодно — хоть на макросах, хоть на бейсике. А что такое "понятность"... э... это уже индивидуально.
Макросы — это конечно очень мощный инструмент. Для обфускации исходников
Но некоторые и без них прекрасно справляются...
В любом случае — по сравнению с С-макросами, метапрограммирование ничего не сможет добавить в этом отношении
Здравствуйте, Дарней, Вы писали:
Д>В любом случае — по сравнению с С-макросами, метапрограммирование ничего не сможет добавить в этом отношении
Вы думаете?
Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе.
Где-то не так чтобы очень давно, но и не совсем уж вчера, я уже нечто подобное слышал (см. выделенные фрагменты)...
Что-то подобное: VD>1. Необходимость многопроходного метапрограммирования. Оно не так и нужно, так как основная его задача преобразование простой модели в сложную.
И вот такое: VD>2. Если надо, оно достаточно элементарно реализуется.
Нечто похожее: VD>В любом случае, адептом Лиспа я точно не стану, так как меня блевать тянет от программирования в АСТ напичканом скобками. Так что прийдется развивать идею на базе наиболее близкого и пригодного, по моему мнению, продукта из досупных на сегодня.
Очень похожее: VD>В любом случае на сегодня народ Лисп не очень то принял.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
Д>Макросы — это конечно очень мощный инструмент. Для обфускации исходников Д>Но некоторые и без них прекрасно справляются... Д>В любом случае — по сравнению с С-макросами, метапрограммирование ничего не сможет добавить в этом отношении
Это не касается макросов, синтаксис которых идентичен/близок синтаксису обычных конструкций в языке. Вы можете усложнять макросы в Си++ и даже довести до каких-то абсурдных высот вроде OpenC++, но все это будет походить на огромный древесный гриб, т.е. на чужеродный нарост. Именно такие макросы и наводят тумана в исходниках.
В идеале мета-язык должен быть очень близок или даже идентичен основному языку. Есть ли такие языки?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Он говорит о нововведении, появляющемся по отношению привычному Блаб-континууму конкретного Блаб-программиста. C#, а равно и Java, никаких серьёзных нововведений по отношению к C++ не предлагают
Ага для Блаб-программиста, так тот думает на Блабе.
ГВ>Если на С++ можно программировать "как на C", то на Lisp этого не получится по определению.
Ну, это мягко гворя преувеличение. Лисп довольно разнообразен. На нем мнжно и импиритившинку забацать. Хот к делу это не относится.
ГВ>
ГВ>Также мы были спокойны, если требовались разработчики на C++ или Java.
ГВ>Напомню, что в 95 шаблоны только-только появлялись и представляли собой не меньшую, если не большую terra incognita, чем макросы Lisp.
Вот только и сегодня шаблоном плюсов до макросов Лиспа как до Пекина раком.
ГВ> Они и сейчас не слишком-то э... популярны.
Гы-гы.
ГВ> Достаточно вспомнить, как упорно ты и другие (не будем показывать пальцем) пару лет назад уверяли, что шаблоны — это suxx и нагромождение треугольных скобок.
Я никогда никого не уверял что шаблоны это что-там ницензурное. Не ври уж так открыто. Я говорил, что у них есть проблемы, и что их используют мягко говоря не всегда по назначению. А отсюда появляется излишняя сложность.
VD>>Он говорит, о том, что считает Лисп более мощьным (или высокоуровневым языком). Причем делает он это на основании того, что в лиспе имеется мощьнейшая система метапрограммирования. Тут с ним тяжело не согласиться. Метапрограммирование действительно мощьнейший механизм. Вот только он есть не только в Лиспе. На сегодня есть так же OpenC++ и R#
.
ГВ>Влад, ты действительно сравнивал макросы Lisp и шаблоны С++? Напоминаю на всякий случай — с точки зрения Lisp-машины программа является и программой и данными одновременно. Поверь на слово: макросы Lisp не менее опасная вещь, чем шаблоны C++. Если не более.
Опасность тут не причем. Я вообще не считаю Лисп идеалом. Но отрицать очевидное не стоит. С точки зрения метапрограммирования Лисп очень интересен. Ты просто как всегда прочел мои слова и выделил в них свой потоенный смысл, который я в них не вкладывал.
VD>>Однако он совершенно прав, в том, что костность мышления очень сильна. И большинство людей не в силах разглядеть действительно мощьное решение потому как мыслить понятиями "Блабла". ГВ>В точку.
Но это конечно не про тебя.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Не, не в этом дело. Вопрос в понятности кода. А завернуть непонятную программу можно на чём угодно — хоть на макросах, хоть на бейсике. А что такое "понятность"... э... это уже индивидуально.
Д>Макросы — это конечно очень мощный инструмент.
Макросы Лиспа названы макросами по недоразумению. На самом деле это метапрограммы, т.е. код который модифицирует другой код или сам себя.
Д> Для обфускации исходников
Будешь смеяться, но в Лиспе "макросы" используются для компиляции лисп-кода в машинный.
Д>В любом случае — по сравнению с С-макросами, метапрограммирование ничего не сможет добавить в этом отношении
Чушь. С-макросы — это просто одна большая задница. Они очень не многое могут и при этом приносят очень много вреда.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cron Tab, Вы писали:
CT>Это не касается макросов, синтаксис которых идентичен/близок синтаксису обычных конструкций в языке. Вы можете усложнять макросы в Си++ и даже довести до каких-то абсурдных высот вроде OpenC++, но все это будет походить на огромный древесный гриб, т.е. на чужеродный нарост. Именно такие макросы и наводят тумана в исходниках.
Ты бы разобрался сначала что такое ОпенС++, а потом про грибы рассуждал бы.
CT>В идеале мета-язык должен быть очень близок или даже идентичен основному языку. Есть ли такие языки?
Никому он ничего не должен. Решения могут быть самыми разными. И лучшее будет то кторое окажется удобнее и безопаснее других.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Чушь. С-макросы — это просто одна большая задница. Они очень не многое могут и при этом приносят очень много вреда.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Кажись, это мы еще не обсуждали: Пол Грэм. Краткость — сила.
Все-таки ключевое слово для Лиспа не "краткость", а "расширяемость".
А вот K — язык, где краткость положена в основу всего.
Здравствуйте, Трурль, Вы писали:
Т>А вот K — язык, где краткость положена в основу всего.
Попробую развить эту мысль. Философия K проста: поскольку большие программы очень сложно писать и отлаживать, не надо их писать вообще. Программы должны быть маленькими. Как говорит Артур Уитни, "если это нельзя сделать на одном экране, то это нельзя сделать вообще".
В жертву принесено буквально все (удобочитаемость, инкапсуляция,...). Зато достигается поразительная краткость. Например, СУБД kdb — 50k "байт-кода" и по слухам 20-30 экранов кода на K. А может она немало, например восьмерки вокруг Oracle и MSSQL описывать, пока они соревнуются по скорости.
I think there are five reasons people like object-oriented programming, and three and a half of them are bad:
...
3. Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Зверёк Харьковский, Вы писали:
Т>Еще один сабж.
Т>
I think there are five reasons people like object-oriented programming, and three and a half of them are bad:
Т>...
Т>3. Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.
Совершенно верно. Действительно, ООП позволяет в некотором смысле вносить комментарии в исходники. Но то же самое можно сказать и о процедурном программировании! Там, где асм-программер обошелся бы call [eax], а то и джампом, C-программер пишет какие-то десятки строк хидеров (которые вообще никакого кода не производят!).
Все современные высокоуровневые языки можно трактовать ровно как возможность писать комментарии в исходниках. Я надеюсь, что в будущем вместо натужных описаний типа "Это класс XFactory. Реализует паттерн factory для класса X." мы сможем записывать этот факт в исходнике. И это будет намного круче, потому что этот комментарий будет читать компилятор, и он проверит его как минимум на полноту и непротиворечивость.
Фрагмент звучит так, как будто Грэм считает комментирование "лишней" работой. Если это так, то он врёт. Лисп-хакер, который одной строкой может положить символ на стек и поставить в тупик еще пятерых лисп-хакеров, потому что он не удосужился написать двадцать строк тщательно отформатированного комментария, может идти далеко.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
И без правой части можно мозг сломать, выясняя по коду, что же мы такое инкрементируем.
В С уже можно таких комментов не писать, ибо они выражены в коде. В С++ можно писать меньше комментов, чем в С. Потому что кое-что выражается в виде кода.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В С уже можно таких комментов не писать, ибо они выражены в коде.
Думаю, Грэм подразумевал именно такие комменты.
Ваши же возражения скорее относятся к пункту 2.
Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway.
употребляют термин "замыкание" только для обозначения структуры данных, представляющей безымянные функции.
Разницы по сути нет. Просто Лиспу проще так ка он сам и его однные по сути АСТ и к тому же по сути интерпретируемый. 
