Я тут недавно завел разговор о пределах высокоуровневости языков программирования и получил много интересных ответов, которые дали мне пищу для размышлений.
Результаты этих размышлений я решил изложить в письменном виде и предложить форуму. На сенсацию не претендую, но, может быть, кому-то будет интересно.
Поскольку я писал текст используюя Google Docs, и переносить его сюда со всем форматированием мне лень, я опубликовал текст средствами гуглдокс
Особую благодарность хочу выразить участникам alpha21264, VladD2, Кодёнок, Mystic и Kerbadun, поскольку их реплики направили ход моей мысли в нужное русло.
В целом не плохо, хотя есть что по править. Особенно раздражает не по делу (и не верно) использование термина "энтропия".
0>Поскольку я писал текст используюя Google Docs, и переносить его сюда со всем форматированием мне лень, я опубликовал текст средствами гуглдокс
А вот это зря по той простой причине, что эту статью (а это уже тянет на статью) нельзя будет найти поиском.
По сему предлагаю прислать нам этот материал на сабмит, подкорректировать и выложить в виде полноценной статьи.
ЗЫ
Что касается вопроса "Так почему же мы не пишем все на Lisp?"...
Тут есть две составляющих. Социально-психологическая (субъективная) и объективна.
Субъектная часть хорошо описывается совсем уж выдающимся примером — оплатой ЖКХ. Чтобы заплатить за жилье можно:
1. Пойти в сбербанк, встать в очередь и оплатить через окошко. При этом убивается море времени, платится больший банковский процент и тратится много нервов.
2. Заплатить через банкомант или спец.терминал.
3. Заплатить через интернет.
Самый сложный и неудобный — это первый вариант. Но как не парадоксально, но это самый популярный вариант.
Нечто похожее происходит и с языками программирования (а так же другими компьютерными технологиями). Люди морально и психологически не готовый к более абстрактным языкам.
Объективные причины так же парадоксальны. Лисп предлагая мощнейшие абстракции (ФП, ООП, МП) при этом умудряется не предоставлять простейшие абстракции вроде привычных всем математических выражений (инфиксные операторы и т.п.). Так же в Лиспе имеются проблемы с типизацией (она динамическая, а при попытках ввести статическую появляются явные описания типов, а это уже повышает объем кода без увеличения объема информации). Кроме того до недавнего времени банально не было эффективных реализаций Лиспа для ПК. Да и те что есть сейчас имеют проблемы под Windows.
Кроме того Лисп хотя и обладает мощной макро-системой, но все же она не позволяет расширять синтаксис, а только меняет семантику. Это приводит к тому, что программы должны быть записаны в виде S-выражений которые с трудом читаются простыми смертными. Справедливости ради надо отметить, что есть эксперименты по прикручиванию к лиспу качественных синтаксических расширений, но он почему-то тоже не выстрелили.
Однако Лисп — это действительно незаслуженно забытое (а многими и не узнанное) достижение человечества.
Среди языков программирования я бы назвал Лисп и Пролог языками которые не смогло оценить интеллектуальное большинство. А жаль. Работы над немерлом — это попытка исправить ситуацию. В немерле исправлены многие недостатки лиспа. Думаю что Nemerle 2 будет идеальным по расширяемости языком. Но, боюсь, что социально-психологический аспект может препятствовать популяризации и Nemerle. Но я уверен, что если не за Nemerle, то за его потомками (последователями) будет будущее. Видимо через несколько десятков лет никого не будет пугать мысль о том, что язык может настраиваться под задачу. Но сегодня это не так. Люди боятся расширяемости даже спустя 50 лет с момента появления первого расширяемого языка — Лиспа.
Кроме того есть еще одна, на мой взгляд намного более серьезная, проблема — гиганты-монополисты просто таки подминают под себя рынок ПО и начинают им управлять. Это приводит к тому, что они просто таки навязывают свою волю большиству и тем самым сами формируют рынок. Создание языков и производство компиляторов перестало быть прибыльным делом. Сегодня уже нельзя выпустить Turbo Lisp и захватить рынок. Массы же ориентируются на отсталые и экстенсивно развивающиеся технологии предлагаемые монополистами просто на том основании, что за ними стоит бабло, а бабло, как известно, на сегодня всегда побеждает бабро.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да все плохо. Высокоуровневость ЯП зависит от коррелированности обрабатываемых данных предметной области. Чем "хаотичнее" предметная область, тем сложнее его отобразить в виде программы (упорядоченного набора команд-сообщений) на любом ЯП, где словарь (тезаурус) тоже упорядоченный набор информации. Есть некоторые проблески в виде замены отношения порядка на отношение эквивалентности в лице хеш-функций, но коллизии заставляют упорядочивать. И чем больше набор разнообразной информации тем больше коллизий. Вот когда найдем "серебряную пулю" — словарь с поиском O(1) для любого N, тогда можно поговорить о "самом" высокоуровневом ЯП. А пока все ЯП практически равнозначны, просто они заточены под разные предметные области.
T>>Конечно, это вырожденные случаи, просто из любопытства интересно, ловит ли компилятор подобные извороты?
H>А ловит ли компилятор, скажем, Си, извороты вида: H>
for(;;);
H>
Проверил. Не ловит. Очень удивительно, я ожидал варнинг.
Здравствуйте, VladD2, Вы писали:
VD>Он о том, что компилятор C написан на С же, но это не приводит к тому, что компилятор зацикливается встретив конструкцию for... если я его правильно понял.
Я о том, что задача выявления зацикливания сродни проблеме останова. Если мы, в принципе, можем отловить примитивные случаи, которые на практике почти не встречаются, то со сложными уже сложно что-то поделать, но они наиболее вероятны на практике.
Очень интересно. В двух словах: высокоуровневость — характеристика языка, описывающая множество паттернов, которые язык позволяет устранять. Чем больше разных паттернов можно устранить — тем более высокоуровневый язык.
Спасибо вам за труд. Вряд ли я бы нашёл время прочитать оригинальное обсуждение целиком.
Замечания по оформлению:
— в конце заголовков точка не ставится
— у параграфов отступы разной ширины
— почти все параграфы состоят из 1-2 предложений
— "Как верно было подмечено в обсуждении, для задачи сложения двух чисел язык, позволяющий записать выражение “a + b” будет предельно высокоуровневым" здесь было бы очень уместно поставить ссылку на соответствующую ветку в обсуждении.
Ачепятки:
— Изучая этот я искал модель
— а получателем — компьютер, исполнительное устройства
— Так же мы будем рассматривать
— “Уровень” языка существует только в контексте конкретной задачи его верхняя граница находится там
— по этой шкале шкале высокоуровневости
— шкале высокоуровневости так же есть теоретический предел
— Возможно, что существует
Здравствуйте, Temoto, Вы писали:
T>Очень интересно. В двух словах: высокоуровневость — характеристика языка, описывающая множество паттернов, которые язык позволяет устранять. Чем больше разных паттернов можно устранить — тем более высокоуровневый язык.
Это один из аспектов высокоуровневости.
Второй — близость к предметной области.
Они ортогональны друг другу.
T>Замечания по оформлению: T> ... T>Ачепятки:
Спасибо за замечания, приму меры
Здравствуйте, Temoto, Вы писали:
T>Очень интересно. В двух словах: высокоуровневость — характеристика языка, описывающая множество паттернов, которые язык позволяет устранять. Чем больше разных паттернов можно устранить — тем более высокоуровневый язык.
Однако паттерны, в свою очередь, тоже могут быть разного уровня. Рекурсия?
... << RSDN@Home 1.2.0 alpha 4 rev. 1490 on Windows 7 6.1.7600.0>>
T>>Очень интересно. В двух словах: высокоуровневость — характеристика языка, описывающая множество паттернов, которые язык позволяет устранять. Чем больше разных паттернов можно устранить — тем более высокоуровневый язык.
AVK>Однако паттерны, в свою очередь, тоже могут быть разного уровня. Рекурсия?
Не уверен, что понял. Вы про то, что после редукции патернов можно выявить новые патерны (теперь состоящие из новых слов)? Ну да, удобно описать этот процесс с помощью рекурсии.
Здравствуйте, Temoto, Вы писали:
AVK>>Однако паттерны, в свою очередь, тоже могут быть разного уровня. Рекурсия?
T>Не уверен, что понял. Вы про то, что после редукции патернов можно выявить новые патерны (теперь состоящие из новых слов)? Ну да, удобно описать этот процесс с помощью рекурсии.
Более того, на практике так и происходит в языках с поддержкой макросов. Одни паттерны выражаются в терминах других. Скажем упоминавшийся тернарный оператор (аналогом которому является if немерла) используется внутри других макросов, а те при описании третьих. Чем более глобальный паттерн устраняется, тем чаще при их реализации используются более гранулярные абстракции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AVK>>>Однако паттерны, в свою очередь, тоже могут быть разного уровня. Рекурсия?
T>>Не уверен, что понял. Вы про то, что после редукции патернов можно выявить новые патерны (теперь состоящие из новых слов)? Ну да, удобно описать этот процесс с помощью рекурсии.
VD>Более того, на практике так и происходит в языках с поддержкой макросов. Одни паттерны выражаются в терминах других. Скажем упоминавшийся тернарный оператор (аналогом которому является if немерла) используется внутри других макросов, а те при описании третьих. Чем более глобальный паттерн устраняется, тем чаще при их реализации используются более гранулярные абстракции.
Кстати, расскажите, пожалуйста, как вы в немерле боретесь (если) с многопроходностью? Достаточно ли быстро раскрываются шаблоны? Можно сделать рекурсивный макрос? Отследит ли это компилятор?
Здравствуйте, VladD2, Вы писали:
VD>В целом не плохо, хотя есть что по править.
Если напишешь конкретные замечения, скажу большое человеческое спасибо
VD>Особенно раздражает не по делу (и не верно) использование термина "энтропия".
А вот тут остановимся подробнее. Я говорю вот об этой энтропии здесь и она является ключевым понятием в моих рассуждениях. Если я слажал с ней, то под вопросом ценность всей статьи
VD>А вот это зря по той простой причине, что эту статью (а это уже тянет на статью) нельзя будет найти поиском.
Сказать по правде, я даже не задумался об этом
VD>По сему предлагаю прислать нам этот материал на сабмит, подкорректировать и выложить в виде полноценной статьи.
Хорошо. Я почитаю правила для статей, но для коррекции мне хорошо бы иметь замечания по статье.
VD>ЗЫ VD>Что касается вопроса "Так почему же мы не пишем все на Lisp?"...
Да, все так. Мне думается, что культурный аспект оказался решающим. Lisp появился слишком рано, когда IT-индустрия в массе была к нему не готова ни в каком смысле. В итоге он выпал из культуры средств разработки и оказался забыт, как и многие другие революционные вещи.
Здравствуйте, AndrewVK, Вы писали:
AVK>Однако паттерны, в свою очередь, тоже могут быть разного уровня. Рекурсия?
Рекурсия возникает в том случае, если один и тот же паттерн повторяется на разных уровнях. В таком случае получаем фрактальное устройство программы Но в остальных случаях на определенном уровне паттерны должны кончиться
Здравствуйте, AndrewVK, Вы писали:
AVK>MVC — хороший пример такого паттерна.
MVC как раз очень верхнеуровневый паттерн. На нижних уровнях не встречается.
0>>Но в остальных случаях на определенном уровне паттерны должны кончиться
AVK>Но как тогда определять высокоуровневость языка? У кого больше низкоуровневых паттернов, или у кого меньше, но они более высокоуровневые?
По отсутствию возможности решить задачу без приседаний. Скажем недостаточнось уровня C# для работы с зависимыми свойствами WPF очевидна любому кто с ней связвался. В коде появляется паттерн который мозолит глаза и заставляет копипастить. Устранить его средствами языка не выходит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 0x7be, Вы писали:
0>Если напишешь конкретные замечения, скажу большое человеческое спасибо 0>...Хорошо. Я почитаю правила для статей, но для коррекции мне хорошо бы иметь замечания по статье.
Если пришлешь статью в ближайшее время, то обещаю обработать ее первой. При это будут как правки языковые, так и замечания в виде комментариев (в балунах).
VD>>Особенно раздражает не по делу (и не верно) использование термина "энтропия". 0>А вот тут остановимся подробнее. Я говорю вот об этой энтропии здесь и она является ключевым понятием в моих рассуждениях. Если я слажал с ней, то под вопросом ценность всей статьи
По этому поводу чуть позже, так как занят, а чтобы ответить конкретно нужно еще раз читать статью.
0>Да, все так. Мне думается, что культурный аспект оказался решающим. Lisp появился слишком рано, когда IT-индустрия в массе была к нему не готова ни в каком смысле. В итоге он выпал из культуры средств разработки и оказался забыт, как и многие другие революционные вещи.
Пожалуй, но и простота реализации (необходимость программировать в АСТ) тоже сыграла не малую роль.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
здесь и она является ключевым понятием в моих рассуждениях. Если я слажал с ней, то под вопросом ценность всей статьи
Как минимум нужно было сослаться на используемое определение. В общем случае энтропия — это мера неопределенности (или хаоса). Собственно русская википедия дает близкое к этому определение.
Кроме того в твоих рассуждениях этот термин совершенно не нужен. Без него получится даже понятнее.
Скажем, если фразу "Избыточность сообщения — разница между энтропией сообщения и максимально возможной энтропией." перефразировать так — "Избыточность сообщения — разница между информационной насыщенностью сообщения сообщения и максимально возможной информационной насыщенностью сообщения.", то она станет только понятнее. Хотя после этого становится очевидным, что "максимально возможной информационной насыщенностью сообщения" может быть бесконечна. Из чего делаем вывод, что или определение не верное, или логический вывод хромает.
При этом нет нет никакого смысла давать определение понятиям "Информационная насыщенность сообщения" и "Избыточность сообщения". Все и так интуитивно понимают смысл этих слов. Избыточность — кода можно выкинуть лишнее и смысл не потеряется. Информационная насыщенность — когда мало "воды".
В общем, читая это не вольно ловишь себя на мысли, что автор начал заниматься фигней и графоманством давая запутанные определения и так понятным понятиям.
Усложнять — легко. Упрощать — тяжело. Так что не надо стараться усложнять. Это и так получится .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Temoto, Вы писали:
T>Кстати, расскажите, пожалуйста, как вы в немерле боретесь (если) с многопроходностью?
В самом компиляторе, или в коде на Nemerle?
Компилятор Nemerle 1.0 однопоточный. Компилятор Nemerle 2 будет многопоточным. Достигнуто это будет в основном за счет преобразования большей части структур в неизменяемые и распараллеливанием типизации тел членов (которая в основном и отнимает время).
Если речь о кода написанном на Nemerle, то тут доступны все средства что есть в дотнет-фрэймворке, плюс домарощенные макросы вроде async (похож на аналог из F#, но реализован в виде макроса).
T> Достаточно ли быстро раскрываются шаблоны?
Что за шаблоны? Макросы? Да достаточно быстро. Макрос по сути — это функция написанная на самом же немерле. Они компилируются перед выполнением, так что их скорость сравнима со скоростью сишного кода.
T> Можно сделать рекурсивный макрос?
Опять же что понимать под рекурсией?
Макрос:
1. Может определяться с использованием других макросов или даже себя же самого (прошлой версии).
2. Макрос может производить рекурсивные вычисления.
И то, и другое подходит под понятие рекурсия.
Как я уже говорил, макрос — это функция немерла. Синтаксис макросов это всего лишь точка входа. Внутри макроса возможно все что возможно в немерле. В том числе и использовать рекурсию. В то же время макрос можно выразить через самого себя, если предварильно скомпилировать его и подключить полученную сборку к проекту где определен макрос.
T>Отследит ли это компилятор?
Сначала надо понять о чем идет речь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Temoto, Вы писали:
T>>Кстати, расскажите, пожалуйста, как вы в немерле боретесь (если) с многопроходностью?
VD>В самом компиляторе, или в коде на Nemerle?
VD>Компилятор Nemerle 1.0 однопоточный. Компилятор Nemerle 2 будет многопоточным. Достигнуто это будет в основном за счет преобразования большей части структур в неизменяемые и распараллеливанием типизации тел членов (которая в основном и отнимает время).
VD>Если речь о кода написанном на Nemerle, то тут доступны все средства что есть в дотнет-фрэймворке, плюс домарощенные макросы вроде async (похож на аналог из F#, но реализован в виде макроса).
Влад, человек вроде про многопроходность, а не про многопоточность спрашивал
T>>Кстати, расскажите, пожалуйста, как вы в немерле боретесь (если) с многопроходностью?
VD>В самом компиляторе, или в коде на Nemerle?
VD>Компилятор Nemerle 1.0 однопоточный. Компилятор Nemerle 2 будет многопоточным. Достигнуто это будет в основном за счет преобразования большей части структур в неизменяемые и распараллеливанием типизации тел членов (которая в основном и отнимает время).
VD>Если речь о кода написанном на Nemerle, то тут доступны все средства что есть в дотнет-фрэймворке, плюс домарощенные макросы вроде async (похож на аналог из F#, но реализован в виде макроса).
В компиляторе, конечно. Многопоточный компилятор, это, конечно, круто, но вопрос был про количество проходов по исходнику, чтобы сгенерить MSIL.
T>> Можно сделать рекурсивный макрос?
VD>Опять же что понимать под рекурсией? VD>Макрос: VD>1. Может определяться с использованием других макросов или даже себя же самого (прошлой версии). VD>2. Макрос может производить рекурсивные вычисления.
VD>И то, и другое подходит под понятие рекурсия.
VD>Как я уже говорил, макрос — это функция немерла. Синтаксис макросов это всего лишь точка входа. Внутри макроса возможно все что возможно в немерле. В том числе и использовать рекурсию. В то же время макрос можно выразить через самого себя, если предварильно скомпилировать его и подключить полученную сборку к проекту где определен макрос.
Я точно не знаю синтаксиса Немерла, надеюсь, такой будет понятен:
macro Infinite
syntax "inf"
{
output "inf"
}
В принципе, уже такой макрос должен выполняться бесконечно, если после раскрытия макросов компилятор пытается снова найти макросы, до тех пор, пока они перестанут менять код. Но если у вас нет такой логики, то вот другой вариант:
macro Infinite
syntax "inf"
{
output Infinite()
}
Конечно, это вырожденные случаи, просто из любопытства интересно, ловит ли компилятор подобные извороты?
Здравствуйте, Курилка, Вы писали:
T>>>Кстати, расскажите, пожалуйста, как вы в немерле боретесь (если) с многопроходностью?
К>Влад, человек вроде про многопроходность, а не про многопоточность спрашивал
Э... сори. Проклятое зрение!
Многопроходности в общем-то и нет. Точнее есть стадии токенизации, препарсига, парсинга, построения дерева типов, связывания типов для типов и их членов, типизации тел типов и генерации IL-а и метаданных типов. Это с натяжкой можно назвать многопроходностью, но по сути это этапы трасформации исходного кода в сборку.
Макросы отрабатывают на некоторых стадиях или между ними. Скажем макро-атрибуты отрабатывают после построения дерева типов и после связывания типов для типов и их членов. Макросы уровня выражения раскрываются во время типизации тел методов (непосредственно перед типизацией выражения в котором они встречаются).
Макросы могут раскрыться в код так же содержащий макросы.
Так что при раскрытии макросов никакой многопроходности нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Temoto, Вы писали:
T>В компиляторе, конечно. Многопоточный компилятор, это, конечно, круто, но вопрос был про количество проходов по исходнику, чтобы сгенерить MSIL.
По исходнику давно уже никто не ходит больше одного раза. Ну, разве что для реализации препроцессора.
Работа ведется на базе АСТ. Сначала создаются токены, потом они трасформируются в АСТ. Макросы уже работают с АСТ (как в Лиспе).
Макрос уровня выражения — это просто функция получающая набор выражений в качестве параметров и возвращающая выражение (АСТ уровня выражения). Мета-атрибуты — это процедуры выполняемые в различные стадии компиляции и способные модифицировать АСТ (императивно).
T>Я точно не знаю синтаксиса Немерла, надеюсь, такой будет понятен:
T>В принципе, уже такой макрос должен выполняться бесконечно,
Дык в том то все и дело, что макросы не выполняются, а раскрываются. В указанном тобой виде макрос можно будет определить только при уловии, что до этого макрос был реализован без рекурсии. Готовый макрос можно подключить (в виде dll) к проекту соберающему тот же макрос. Но это будет предыдущая версия макроса! При своем раскрытии эта версия генерирует код в котором не будет себя же. Этот код и станет результатом работы нового макроса. Кода проект содержащий макрос будет перекомпилирован еще раз, то точно так же раскроется новая весрия, но так как она была создана из старой, то она вернет все тот же АСТ не содержащий себя.
Так что в этом плане рекурсия и есть, и ее нет. Визуально мы можем написать код так:
Еще раз повторюсь макрос Nemerle должен быть скомпилирован до применения. Так что самого себя он использовать не может.
T>если после раскрытия макросов компилятор пытается снова найти макросы, до тех пор, пока они перестанут менять код.
T>Конечно, это вырожденные случаи, просто из любопытства интересно, ловит ли компилятор подобные извороты?
Они просто невозможны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Temoto, Вы писали:
H>>А ловит ли компилятор, скажем, Си, извороты вида: H>>
for(;;);
H>>
T>Проверил. Не ловит. Очень удивительно, я ожидал варнинг.
Он о том, что компилятор C написан на С же, но это не приводит к тому, что компилятор зацикливается встретив конструкцию for... если я его правильно понял.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Другое дело, что никто в здравом уме не станет такую фигню писать.
Ну почему же. Например макрос json насквозь рекурсивный, другое дело, что для рекурсии можно использовать макрос в виде вызова метода, хотя использование его напрямую в цитатах выглядело бы изящнее.
Здравствуйте, Ziaw, Вы писали:
Z>Ну почему же. Например макрос json насквозь рекурсивный, другое дело, что для рекурсии можно использовать макрос в виде вызова метода, хотя использование его напрямую в цитатах выглядело бы изящнее.
В принципе достаточно сделать в компиляторе защиту от неограниченной рекурсии макросов (скажем, 100 итераций), не известно правда, насколько это оправданно. Во всяком случае никто на такие проблемы еще не натыкался.
T>Конечно, это вырожденные случаи, просто из любопытства интересно, ловит ли компилятор подобные извороты?
C++ или D вполне возможно, используя шаблоны, заставить компилятор задуматься навсегда (до переполнения стека),
в немерле и любом другом языке поддерживающем тьюринг-полное метапрограммирование должно быть аналогично.
Здравствуйте, hardcase, Вы писали:
Z>>Ну почему же. Например макрос json насквозь рекурсивный, другое дело, что для рекурсии можно использовать макрос в виде вызова метода, хотя использование его напрямую в цитатах выглядело бы изящнее.
H>В принципе достаточно сделать в компиляторе защиту от неограниченной рекурсии макросов (скажем, 100 итераций), не известно правда, насколько это оправданно. Во всяком случае никто на такие проблемы еще не натыкался.
В двойке точно не получится, там никак не выйдет использовать в цитатах макросы из этой же сборки, т.к. квазицитаты надо парсить парсером расширенным нескомпилированными макросами, я представляю как это сделать на практике.
А в защите от неорганиченной рекурсии я вообще смысла не вижу, это всего лишь один из нескольких рядовых способов уронить компилятор из макроса (обычную же рекурсию мы ограничивать не собираемся).
Здравствуйте, VladD2, Вы писали:
VD>Кроме того в твоих рассуждениях этот термин совершенно не нужен. Без него получится даже понятнее. VD>Скажем, если фразу "Избыточность сообщения — разница между энтропией сообщения и максимально возможной энтропией." перефразировать так — "Избыточность сообщения — разница между информационной насыщенностью сообщения сообщения и максимально возможной информационной насыщенностью сообщения.", то она станет только понятнее. Хотя после этого становится очевидным, что "максимально возможной информационной насыщенностью сообщения" может быть бесконечна. Из чего делаем вывод, что или определение не верное, или логический вывод хромает.
Что-то я запутался в твоих рассуждениях. Информационная энтропия по Шеннону имеет одно очень конкретное свойство, на которое я опираюсь в своих рассуждениях — она ограничена сверху. В конечном итоге из этого я делаю заключение, что каждую конкретную программу нельзя сжимать до бесконечности, даже используя сколь угодно продвинутые средства абстракции. Совсем выкидывать энтропию из текста нельзя. Может просто не ссылаться на неё часто, а только в определении насыщенности и там, где используется её свойство ограниченности сверху?
VD>При этом нет нет никакого смысла давать определение понятиям "Информационная насыщенность сообщения" и "Избыточность сообщения". Все и так интуитивно понимают смысл этих слов. Избыточность — кода можно выкинуть лишнее и смысл не потеряется. Информационная насыщенность — когда мало "воды".
С этим соглашусь
VD>В общем, читая это не вольно ловишь себя на мысли, что автор начал заниматься фигней и графоманством давая запутанные определения и так понятным понятиям.
Фигня и графоманство у меня в первой части, где я определения даю.
Это побочный эффект написание текста, как эссе, для приведения собственных мыслей в порядок.
Для публикации в виде статьи можно упростить.
VD>Усложнять — легко. Упрощать — тяжело. Так что не надо стараться усложнять. Это и так получится .
Черт возьми, а ведь ты прав!
Здравствуйте, VladD2, Вы писали:
VD>Если пришлешь статью в ближайшее время, то обещаю обработать ее первой. При это будут как правки языковые, так и замечания в виде комментариев (в балунах).
Постараюсь побыстрее, но не обещаю.
С делами завал.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>Компилятор вылетает с переполнением стека.
VD>Если это так, то это просто баг. Компилятор не должен видеть имени еще не скомпилированного макроса.
А он и не видит. Компиляция валится при использовании этого макроса.
Я же для тебя написал комментарий: <[ Macro1() ]> есть ничто иное как обычный PExpr.Call("Macro1", []), тогда как синтаксические макросы в цитатах выглядят как MacroEnvelope, если мне не изменяет память.
