Я тут недавно завел разговор о пределах высокоуровневости языков программирования и получил много интересных ответов, которые дали мне пищу для размышлений.
Результаты этих размышлений я решил изложить в письменном виде и предложить форуму. На сенсацию не претендую, но, может быть, кому-то будет интересно.
Поскольку я писал текст используюя Google Docs, и переносить его сюда со всем форматированием мне лень, я опубликовал текст средствами гуглдокс
Особую благодарность хочу выразить участникам alpha21264, VladD2, Кодёнок, Mystic и Kerbadun, поскольку их реплики направили ход моей мысли в нужное русло.
Очень интересно. В двух словах: высокоуровневость — характеристика языка, описывающая множество паттернов, которые язык позволяет устранять. Чем больше разных паттернов можно устранить — тем более высокоуровневый язык.
Спасибо вам за труд. Вряд ли я бы нашёл время прочитать оригинальное обсуждение целиком.
Замечания по оформлению:
— в конце заголовков точка не ставится
— у параграфов отступы разной ширины
— почти все параграфы состоят из 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>Однако паттерны, в свою очередь, тоже могут быть разного уровня. Рекурсия?
Не уверен, что понял. Вы про то, что после редукции патернов можно выявить новые патерны (теперь состоящие из новых слов)? Ну да, удобно описать этот процесс с помощью рекурсии.
В целом не плохо, хотя есть что по править. Особенно раздражает не по делу (и не верно) использование термина "энтропия".
0>Поскольку я писал текст используюя Google Docs, и переносить его сюда со всем форматированием мне лень, я опубликовал текст средствами гуглдокс
А вот это зря по той простой причине, что эту статью (а это уже тянет на статью) нельзя будет найти поиском.
По сему предлагаю прислать нам этот материал на сабмит, подкорректировать и выложить в виде полноценной статьи.
ЗЫ
Что касается вопроса "Так почему же мы не пишем все на Lisp?"...
Тут есть две составляющих. Социально-психологическая (субъективная) и объективна.
Субъектная часть хорошо описывается совсем уж выдающимся примером — оплатой ЖКХ. Чтобы заплатить за жилье можно:
1. Пойти в сбербанк, встать в очередь и оплатить через окошко. При этом убивается море времени, платится больший банковский процент и тратится много нервов.
2. Заплатить через банкомант или спец.терминал.
3. Заплатить через интернет.
Самый сложный и неудобный — это первый вариант. Но как не парадоксально, но это самый популярный вариант.
Нечто похожее происходит и с языками программирования (а так же другими компьютерными технологиями). Люди морально и психологически не готовый к более абстрактным языкам.
Объективные причины так же парадоксальны. Лисп предлагая мощнейшие абстракции (ФП, ООП, МП) при этом умудряется не предоставлять простейшие абстракции вроде привычных всем математических выражений (инфиксные операторы и т.п.). Так же в Лиспе имеются проблемы с типизацией (она динамическая, а при попытках ввести статическую появляются явные описания типов, а это уже повышает объем кода без увеличения объема информации). Кроме того до недавнего времени банально не было эффективных реализаций Лиспа для ПК. Да и те что есть сейчас имеют проблемы под Windows.
Кроме того Лисп хотя и обладает мощной макро-системой, но все же она не позволяет расширять синтаксис, а только меняет семантику. Это приводит к тому, что программы должны быть записаны в виде S-выражений которые с трудом читаются простыми смертными. Справедливости ради надо отметить, что есть эксперименты по прикручиванию к лиспу качественных синтаксических расширений, но он почему-то тоже не выстрелили.
Однако Лисп — это действительно незаслуженно забытое (а многими и не узнанное) достижение человечества.
Среди языков программирования я бы назвал Лисп и Пролог языками которые не смогло оценить интеллектуальное большинство. А жаль. Работы над немерлом — это попытка исправить ситуацию. В немерле исправлены многие недостатки лиспа. Думаю что Nemerle 2 будет идеальным по расширяемости языком. Но, боюсь, что социально-психологический аспект может препятствовать популяризации и Nemerle. Но я уверен, что если не за Nemerle, то за его потомками (последователями) будет будущее. Видимо через несколько десятков лет никого не будет пугать мысль о том, что язык может настраиваться под задачу. Но сегодня это не так. Люди боятся расширяемости даже спустя 50 лет с момента появления первого расширяемого языка — Лиспа.
Кроме того есть еще одна, на мой взгляд намного более серьезная, проблема — гиганты-монополисты просто таки подминают под себя рынок ПО и начинают им управлять. Это приводит к тому, что они просто таки навязывают свою волю большиству и тем самым сами формируют рынок. Создание языков и производство компиляторов перестало быть прибыльным делом. Сегодня уже нельзя выпустить Turbo Lisp и захватить рынок. Массы же ориентируются на отсталые и экстенсивно развивающиеся технологии предлагаемые монополистами просто на том основании, что за ними стоит бабло, а бабло, как известно, на сегодня всегда побеждает бабро.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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-индустрия в массе была к нему не готова ни в каком смысле. В итоге он выпал из культуры средств разработки и оказался забыт, как и многие другие революционные вещи.
Пожалуй, но и простота реализации (необходимость программировать в АСТ) тоже сыграла не малую роль.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да все плохо. Высокоуровневость ЯП зависит от коррелированности обрабатываемых данных предметной области. Чем "хаотичнее" предметная область, тем сложнее его отобразить в виде программы (упорядоченного набора команд-сообщений) на любом ЯП, где словарь (тезаурус) тоже упорядоченный набор информации. Есть некоторые проблески в виде замены отношения порядка на отношение эквивалентности в лице хеш-функций, но коллизии заставляют упорядочивать. И чем больше набор разнообразной информации тем больше коллизий. Вот когда найдем "серебряную пулю" — словарь с поиском O(1) для любого N, тогда можно поговорить о "самом" высокоуровневом ЯП. А пока все ЯП практически равнозначны, просто они заточены под разные предметные области.
здесь и она является ключевым понятием в моих рассуждениях. Если я слажал с ней, то под вопросом ценность всей статьи
Как минимум нужно было сослаться на используемое определение. В общем случае энтропия — это мера неопределенности (или хаоса). Собственно русская википедия дает близкое к этому определение.
Кроме того в твоих рассуждениях этот термин совершенно не нужен. Без него получится даже понятнее.
Скажем, если фразу "Избыточность сообщения — разница между энтропией сообщения и максимально возможной энтропией." перефразировать так — "Избыточность сообщения — разница между информационной насыщенностью сообщения сообщения и максимально возможной информационной насыщенностью сообщения.", то она станет только понятнее. Хотя после этого становится очевидным, что "максимально возможной информационной насыщенностью сообщения" может быть бесконечна. Из чего делаем вывод, что или определение не верное, или логический вывод хромает.
При этом нет нет никакого смысла давать определение понятиям "Информационная насыщенность сообщения" и "Избыточность сообщения". Все и так интуитивно понимают смысл этих слов. Избыточность — кода можно выкинуть лишнее и смысл не потеряется. Информационная насыщенность — когда мало "воды".
В общем, читая это не вольно ловишь себя на мысли, что автор начал заниматься фигней и графоманством давая запутанные определения и так понятным понятиям.
Усложнять — легко. Упрощать — тяжело. Так что не надо стараться усложнять. Это и так получится .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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()
}
Конечно, это вырожденные случаи, просто из любопытства интересно, ловит ли компилятор подобные извороты?