Сообщение Re[7]: Что вас останавливает от изучения нового языка? от 24.04.2011 22:16
Изменено 16.03.2015 9:19 vdimas
Здравствуйте, WolfHound, Вы писали:
WH>И ответ "не хочу" на предложение прочитать статью, описывающую техники переднего края должен быть не мыслим.
А ну-ка, что у нас тут на передовом крае:
Ну и опять же. Про узость самой области исследований языков ты похоже не въезжаешь абсолютно. Давай я тебя с утра до ночи алгоритмами обработки сигналов грузить буду? Это же круто! И даже область применения на многие порядки шире. Это настолько повсеместно используется, что вы просто не замечаете. Оно "работает и всё". Но в ней как раз "передних краев" дофига, т.е. гораздо больше свежака (катализованного спросом на сетевые технологии), в отличие от всего этого нафталина в области ФП и доказательства теорем.
Ну и по последнему писку моды тоже хватае тпроблем и они известны. Для зависимых типов — это ввод значений, требующий в общем случае техники суперкомпиляции (а не того подобия техники динамического приведения, что ты когда-то предлагал), а uniqueness типы имеют проблемы в многопоточном окружении. Собственно, эта практика еще допиливается, исследования идут именно в направлении как сделать это полезным на практике, и до мейнстрима прямо сейчас еще далеко. Такова се ляви.
WH>Лаптев на предложение почитать про немерле сказал примерно тоже самое но другими словами.
Дык, Немерле ведь от всего вышеупомянутого страшно далек, ты его сюда не приписывай. Он просто динозавр, родившийся поздно. Представляет из себя сугубо практическую попытку собрать несколько полезных наработок в одном языке на основе имеющейся мощной платформы, угу. В общем, вовсе не "край", а сугубо практическая попытка найти приемлемый компромисс м/у обилием фич и привносимыми ими помехами. Кстати, я не отрицаю полезность этой попытки. Скорее наоборот, обоими руками ЗА. Ведь макросы в С несколько сдали назад по тем временам и подорвали доверие к этой технике. Например, даже возможности макроассемблера на порядок превосходят возможности препроцессора С, не говоря уже о 50-летнем Лиспе или 40-летнем Форте. Пора вернуть макросы на заслуженное место, снабдив их типобезопасностью. Возможно, Немерле своим примером поможет сделать это в следующих версиях интересных мне языков. Хотя, справедливости ради, чрезмерное увлечение макросами всегда считалось плохим тоном во всех перечисленных языках. Элегантности кода не нужно приносить в жертву очевидность происходящего. Иначе бывает больно, вплоть до полного выкидывания и переписывания заново. В общем, моё ИМХО по этому вопросу умеренное, не приемлет обе крайности.
V>>Нужно нечто более полезное из прикладных IT-областей.
WH>Бла-бла-бла.
Кстати, показательно. По-твоему, "настоящие программисты" должны писать софт исключительно для других программистов и заниматься исключительно проблемами языков. Сорри, но это сразу в сад, не задерживаясь.
V>>Язык реализации — это последнее, что интересует. Вернее, не интересует никогда.
WH>Ну да... конечно.
WH>И после того как человек в это начинает верить получается всякая байда типа компиляторов на С.
А что не так с С? Отличная абстракция ассемблера. Настоящий нейтив во-плоти, без встроенных фокусов (если сравнивать с Паскалем, например). Что получится в итоге известно фактически до бит, что и требуется для ПО, непосредственно общающегося с кодом. С этого языка "взлетают" все современные аппаратные платформы, и уже поверх него работают все эти джавы, дотнеты и прочие экзотичности. Поверх него — т.е. поверх кода, созданного компилятором С. Фактически весь современный нейтивный код написан на С/С++, от операционок, офиса и БД, до дотнета и игрушек.
V>>Защитите хотя бы кандидатскую...
WH>И нахрена оно мне надо?
Чтобы привести в порядок собственные наработки. Чтобы в численном виде подсчитать характеристики и преимущества, наконец, если они есть. Чтобы провести и зафиксировать полноценное сравнение с имеющимися наработками в этой же области, показать прогресс (если есть), и характерные отличия.
Например, ты прямо сейчас способен обосновать, почему нерекурсивные алгебраические типы представлены ссылочными типами, хотя дотнет позволяет оперировать value-type? А ведь ML-языки умеют делать такие оптимизации уже черти сколько лет. Пяток подобных вопросов без убедительных ответов, и можно идти допиливать диссер, а лучше сам язык.
V>>Ну и самое главное — будущего инженера надо научить учиться, а остальное — шелуха и болтовня. Дотнетов, джав и прочих технологий будет еще много, заранее всему не научишь. А классика — она вечна.
WH>И что есть классика?
WH>С++?
Для императивных — Фортран/С/Паскаль. Функциональный — Лисп, логический — Пролог. Отличные языки для изучения парадигм. Почему отличные? — а ничего лишнего, никаких понтов, шелухи и синтаксического сахара. Да, в этом и проблема Пролога например, что у него плохая стыковка с "общепрограммисткими" задачами, типа ГУИ, БД, сетка и т.д. Но для целей изучения логического програмимрования — это наоборот, мега-плюс. Бо ничего лишнего.
V>>Во-первых, в 20 раз меньше кода — это ты переборщил.
WH>1)Читай что написано.
WH>2)Это факты.
WH>Причем даже без макросов.
Пока я не видел примеров. Все, что многократно приводились на этом сайте и по сто раз обсуждались в течении 5-ти лет, не дают такой разницы. Ну и домашние заготовки под определенные классы задач в любом более-менее универсальном языке накрутить можно.
V>>Насчет простоты поддержки... Чем более решение высокоуровневое, тем более дорогая нужна поддержка, то бишь требующая более дорогих спецов. Я пока сталкиваюсь ровно с противоположным, что мои более-менее неординарные снипетты кода ругаются более молодыми коллегами за "сложность и непонятность".
WH>Неординарные? Ты имеешь в виду лапшу?
Define "лапшу"?
WH>Не мудрено.
WH>Вот тебе кусочек кода. https://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n
А вот и оно, спасибо. Типичный индусокод. Ни малейшего понятия о декомпозиции и тестопригодности. Развязаться через независимые ф-ии видно не судьба.
Насчет тестопригодности. Ты должен будешь на один метод завязать как кучу низкоуровневых независимых тестов по проверке каждого отдельного вычисления, так и комплексные тесты, проверяющие их комбинации. А это залёт, курсант.
И где там пуля, ткни пальцем. 90% — ветвления идет по единичному тагу размеченного объединения.
Или в этих строках, что ли:
В факте предпросмотра на один уровень вперед (тоже самое тут: Fsm(a)::Fsm(b)::rest)? Да еще через ж... динамическую типизацию в реализации Nemerle? Издеваешься или как?
В общем, декомпозируй решение, и на любом языке это будет смотреться очень похоже. Ни в какие 20 раз и близко разницы не будет.
Далее, вот это ленивые вычисления или энергичные?
Если энергичные, то в топку, бо многопроходность, а оно вполне решаемо за один проход.
Тоже самое с Sequence(rules). Заметь, на плюсах тут вполне можно было обобщить на шаблонах оба случая. Но на немерле или C# — это надо было бы городить огород из паттерна "Стратегия" для целей обобщения, и овчинка выделки не стоила бы.
Собственно 90% функциональности метода рассмотрено. Проходишь по всем вложенным конструкциям и вызываешь оптимизацию правил для вложенных правил, если есть. Самих оптимизаций по сути две — это оптимизация последовательностей Not/And, и вызов FsmBuilder для цепочек символов и автоматов.
Далее. Есть предложение для обоих случаев насчет возможности построения оптимизированного варианта сразу, по мере парсинга правил, а не "потом", за вот этот проход оптимизации. Это как разница в подходах построения ДКА — сначала можно строить по регулярным выражениям НКА, приводить его к ДКА, а затем минимизировать, но ведь можно строить сразу минимизированный ДКА — это порой на порядок быстрее, т.к. на каждом шаге обработке подвергается множество меньшей мощности. Хоть алгоритм и чуть более сложный, угу. К автомату, в свою очередь генерируемому вызываемым тут FSMBuilder это тоже относится.
Кстати, тут еще одно будет преимущество: optimize у тебя распадётся на составляющие, каждая из которых будет вызвана в нужном известном месте без дополнительной диспетчеризации по тагам (т.к. мы заведом знаем, где мы). А то сейчас имеем тот самый случай, когда сначала сливаем в бутылочное горлышко, а потом снова разливаем.
В общем, подкинь что-нить посущественнее, что ли...
WH>Прикинь как он будет выглядеть на С++.
Кое в чем буков будет больше, кое в чем меньше. Разницы в разы не будет. А после декомпозиции вообще будет фактически 1-в-1. Исключение составляют ленивые вычисления на IEnumerable, но это тогда на каком-нить C# надо воспроизводить. Или на плюсах таки сразу строить минимизированный вариант и не париться с последующей ленивой обработкой.
WH>И ответ "не хочу" на предложение прочитать статью, описывающую техники переднего края должен быть не мыслим.
А ну-ка, что у нас тут на передовом крае:
Причем предпоследнее — это скорее классификация имеющихся знаний, чем что-то новое. А последнее — тем более, довольно-таки прикладной репорт на основе имеющегося материала. В общем, что-то скорее нафталиновое, чем передовое. Да и есть ML-языки, которые пытаются реализовать эти наработки. И что эти яыки из себя представляют мы прекрасно знаем: неудобство для общеприкладных задач и тормозной получаемый код, требующих дохрена памяти. Был бы этот сыр бесплатный, весь этот материал давно был бы в мейнстриме.Gandy, Robin O. The simple theory of types. In Logic Colloquium 76, volume 87 of Studies in Logic and the Foundations of Mathematics, pages 173–181. North Holland, 1976.
Whitehead, Alfred North and Bertrand Russell. Principia Mathematica. Cambridge University Press, Cambridge, 1910. Three volumes (1910; 1912; 1913).
Ramsey, Frank P. The foundations of mathematics. Proceedings of the London Mathematical Society, Series 2, 25 (5): 338–384, 1925. Reprinted in (Braithwaite, 1931).
Church, Alonzo. A formulation of the simple theory of types. Journal of Symbolic Logic, 5: 56–68, 1940.
Martin-Löf, Per. An intuitionistic theory of types: predicative part. In H. E. Rose and J. C. Shepherdson, editors, Logic Colloquium, ’73, pages 73–118. North-Holland, Amsterdam, 1973.
Martin-Löf, Per. Intuitionistic Type Theory. Bibliopolis, 1984.
Berardi, Stefano. Towards a mathematical analysis of the Coquand-Huet calculus of constructions and the other systems in Barendregt’s cube. Technical report, Department of Computer Science, CMU, and Dipartimento Matematica, Universita di Torino, 1988.
Barendregt, Henk P. Lambda calculi with types. In Abramsky, Gabbay, and Maibaum, editors, Handbook of Logic in Computer Science, volume II. Oxford University Press, 1992.
Ну и опять же. Про узость самой области исследований языков ты похоже не въезжаешь абсолютно. Давай я тебя с утра до ночи алгоритмами обработки сигналов грузить буду? Это же круто! И даже область применения на многие порядки шире. Это настолько повсеместно используется, что вы просто не замечаете. Оно "работает и всё". Но в ней как раз "передних краев" дофига, т.е. гораздо больше свежака (катализованного спросом на сетевые технологии), в отличие от всего этого нафталина в области ФП и доказательства теорем.
Ну и по последнему писку моды тоже хватае тпроблем и они известны. Для зависимых типов — это ввод значений, требующий в общем случае техники суперкомпиляции (а не того подобия техники динамического приведения, что ты когда-то предлагал), а uniqueness типы имеют проблемы в многопоточном окружении. Собственно, эта практика еще допиливается, исследования идут именно в направлении как сделать это полезным на практике, и до мейнстрима прямо сейчас еще далеко. Такова се ляви.
WH>Лаптев на предложение почитать про немерле сказал примерно тоже самое но другими словами.
Дык, Немерле ведь от всего вышеупомянутого страшно далек, ты его сюда не приписывай. Он просто динозавр, родившийся поздно. Представляет из себя сугубо практическую попытку собрать несколько полезных наработок в одном языке на основе имеющейся мощной платформы, угу. В общем, вовсе не "край", а сугубо практическая попытка найти приемлемый компромисс м/у обилием фич и привносимыми ими помехами. Кстати, я не отрицаю полезность этой попытки. Скорее наоборот, обоими руками ЗА. Ведь макросы в С несколько сдали назад по тем временам и подорвали доверие к этой технике. Например, даже возможности макроассемблера на порядок превосходят возможности препроцессора С, не говоря уже о 50-летнем Лиспе или 40-летнем Форте. Пора вернуть макросы на заслуженное место, снабдив их типобезопасностью. Возможно, Немерле своим примером поможет сделать это в следующих версиях интересных мне языков. Хотя, справедливости ради, чрезмерное увлечение макросами всегда считалось плохим тоном во всех перечисленных языках. Элегантности кода не нужно приносить в жертву очевидность происходящего. Иначе бывает больно, вплоть до полного выкидывания и переписывания заново. В общем, моё ИМХО по этому вопросу умеренное, не приемлет обе крайности.
V>>Нужно нечто более полезное из прикладных IT-областей.
WH>Бла-бла-бла.
Кстати, показательно. По-твоему, "настоящие программисты" должны писать софт исключительно для других программистов и заниматься исключительно проблемами языков. Сорри, но это сразу в сад, не задерживаясь.
V>>Язык реализации — это последнее, что интересует. Вернее, не интересует никогда.
WH>Ну да... конечно.
WH>И после того как человек в это начинает верить получается всякая байда типа компиляторов на С.
А что не так с С? Отличная абстракция ассемблера. Настоящий нейтив во-плоти, без встроенных фокусов (если сравнивать с Паскалем, например). Что получится в итоге известно фактически до бит, что и требуется для ПО, непосредственно общающегося с кодом. С этого языка "взлетают" все современные аппаратные платформы, и уже поверх него работают все эти джавы, дотнеты и прочие экзотичности. Поверх него — т.е. поверх кода, созданного компилятором С. Фактически весь современный нейтивный код написан на С/С++, от операционок, офиса и БД, до дотнета и игрушек.
V>>Защитите хотя бы кандидатскую...
WH>И нахрена оно мне надо?
Чтобы привести в порядок собственные наработки. Чтобы в численном виде подсчитать характеристики и преимущества, наконец, если они есть. Чтобы провести и зафиксировать полноценное сравнение с имеющимися наработками в этой же области, показать прогресс (если есть), и характерные отличия.
Например, ты прямо сейчас способен обосновать, почему нерекурсивные алгебраические типы представлены ссылочными типами, хотя дотнет позволяет оперировать value-type? А ведь ML-языки умеют делать такие оптимизации уже черти сколько лет. Пяток подобных вопросов без убедительных ответов, и можно идти допиливать диссер, а лучше сам язык.
V>>Ну и самое главное — будущего инженера надо научить учиться, а остальное — шелуха и болтовня. Дотнетов, джав и прочих технологий будет еще много, заранее всему не научишь. А классика — она вечна.
WH>И что есть классика?
WH>С++?
Для императивных — Фортран/С/Паскаль. Функциональный — Лисп, логический — Пролог. Отличные языки для изучения парадигм. Почему отличные? — а ничего лишнего, никаких понтов, шелухи и синтаксического сахара. Да, в этом и проблема Пролога например, что у него плохая стыковка с "общепрограммисткими" задачами, типа ГУИ, БД, сетка и т.д. Но для целей изучения логического програмимрования — это наоборот, мега-плюс. Бо ничего лишнего.
V>>Во-первых, в 20 раз меньше кода — это ты переборщил.
WH>1)Читай что написано.
WH>2)Это факты.
WH>Причем даже без макросов.
Пока я не видел примеров. Все, что многократно приводились на этом сайте и по сто раз обсуждались в течении 5-ти лет, не дают такой разницы. Ну и домашние заготовки под определенные классы задач в любом более-менее универсальном языке накрутить можно.
V>>Насчет простоты поддержки... Чем более решение высокоуровневое, тем более дорогая нужна поддержка, то бишь требующая более дорогих спецов. Я пока сталкиваюсь ровно с противоположным, что мои более-менее неординарные снипетты кода ругаются более молодыми коллегами за "сложность и непонятность".
WH>Неординарные? Ты имеешь в виду лапшу?
Define "лапшу"?
WH>Не мудрено.
WH>Вот тебе кусочек кода. https://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n
А вот и оно, спасибо. Типичный индусокод. Ни малейшего понятия о декомпозиции и тестопригодности. Развязаться через независимые ф-ии видно не судьба.
Насчет тестопригодности. Ты должен будешь на один метод завязать как кучу низкоуровневых независимых тестов по проверке каждого отдельного вычисления, так и комплексные тесты, проверяющие их комбинации. А это залёт, курсант.
И где там пуля, ткни пальцем. 90% — ветвления идет по единичному тагу размеченного объединения.
Или в этих строках, что ли:
| Not(Not(rule)) => optimize(Rule.And(r.Location, rule))
| And(Not(rule)) => optimize(Rule.Not(r.Location, rule))
| Not(And(rule)) => optimize(Rule.Not(r.Location, rule))
| And(And(rule)) => optimize(Rule.And(r.Location, rule))В факте предпросмотра на один уровень вперед (тоже самое тут: Fsm(a)::Fsm(b)::rest)? Да еще через ж... динамическую типизацию в реализации Nemerle? Издеваешься или как?
В общем, декомпозируй решение, и на любом языке это будет смотреться очень похоже. Ни в какие 20 раз и близко разницы не будет.
Далее, вот это ленивые вычисления или энергичные?
| Choice(rules) =>
def rules = rules.Map(optimize);
def rules = rules.Map(
fun(_)
{
| Rule.Choice(rules) => rules
| rule => [rule]
});
def rules = rules.Flatten();
...Если энергичные, то в топку, бо многопроходность, а оно вполне решаемо за один проход.
Тоже самое с Sequence(rules). Заметь, на плюсах тут вполне можно было обобщить на шаблонах оба случая. Но на немерле или C# — это надо было бы городить огород из паттерна "Стратегия" для целей обобщения, и овчинка выделки не стоила бы.
Собственно 90% функциональности метода рассмотрено. Проходишь по всем вложенным конструкциям и вызываешь оптимизацию правил для вложенных правил, если есть. Самих оптимизаций по сути две — это оптимизация последовательностей Not/And, и вызов FsmBuilder для цепочек символов и автоматов.
Далее. Есть предложение для обоих случаев насчет возможности построения оптимизированного варианта сразу, по мере парсинга правил, а не "потом", за вот этот проход оптимизации. Это как разница в подходах построения ДКА — сначала можно строить по регулярным выражениям НКА, приводить его к ДКА, а затем минимизировать, но ведь можно строить сразу минимизированный ДКА — это порой на порядок быстрее, т.к. на каждом шаге обработке подвергается множество меньшей мощности. Хоть алгоритм и чуть более сложный, угу. К автомату, в свою очередь генерируемому вызываемым тут FSMBuilder это тоже относится.
Кстати, тут еще одно будет преимущество: optimize у тебя распадётся на составляющие, каждая из которых будет вызвана в нужном известном месте без дополнительной диспетчеризации по тагам (т.к. мы заведом знаем, где мы). А то сейчас имеем тот самый случай, когда сначала сливаем в бутылочное горлышко, а потом снова разливаем.
В общем, подкинь что-нить посущественнее, что ли...
WH>Прикинь как он будет выглядеть на С++.
Кое в чем буков будет больше, кое в чем меньше. Разницы в разы не будет. А после декомпозиции вообще будет фактически 1-в-1. Исключение составляют ленивые вычисления на IEnumerable, но это тогда на каком-нить C# надо воспроизводить. Или на плюсах таки сразу строить минимизированный вариант и не париться с последующей ленивой обработкой.
Re[7]: Что вас останавливает от изучения нового языка?
Здравствуйте, WolfHound, Вы писали:
WH>И ответ "не хочу" на предложение прочитать статью, описывающую техники переднего края должен быть не мыслим.
А ну-ка, что у нас тут на передовом крае:
Ну и опять же. Про узость самой области исследований языков ты похоже не въезжаешь абсолютно. Давай я тебя с утра до ночи алгоритмами обработки сигналов грузить буду? Это же круто! И даже область применения на многие порядки шире. Это настолько повсеместно используется, что вы просто не замечаете. Оно "работает и всё". Но в ней как раз "передних краев" дофига, т.е. гораздо больше свежака (катализованного спросом на сетевые технологии), в отличие от всего этого нафталина в области ФП и доказательства теорем.
Ну и по последнему писку моды тоже хватае тпроблем и они известны. Для зависимых типов — это ввод значений, требующий в общем случае техники суперкомпиляции (а не того подобия техники динамического приведения, что ты когда-то предлагал), а uniqueness типы имеют проблемы в многопоточном окружении. Собственно, эта практика еще допиливается, исследования идут именно в направлении как сделать это полезным на практике, и до мейнстрима прямо сейчас еще далеко. Такова се ляви.
WH>Лаптев на предложение почитать про немерле сказал примерно тоже самое но другими словами.
Дык, Немерле ведь от всего вышеупомянутого страшно далек, ты его сюда не приписывай. Он просто динозавр, родившийся поздно. Представляет из себя сугубо практическую попытку собрать несколько полезных наработок в одном языке на основе имеющейся мощной платформы, угу. В общем, вовсе не "край", а сугубо практическая попытка найти приемлемый компромисс м/у обилием фич и привносимыми ими помехами. Кстати, я не отрицаю полезность этой попытки. Скорее наоборот, обоими руками ЗА. Ведь макросы в С несколько сдали назад по тем временам и подорвали доверие к этой технике. Например, даже возможности макроассемблера на порядок превосходят возможности препроцессора С, не говоря уже о 50-летнем Лиспе или 40-летнем Форте. Пора вернуть макросы на заслуженное место, снабдив их типобезопасностью. Возможно, Немерле своим примером поможет сделать это в следующих версиях интересных мне языков. Хотя, справедливости ради, чрезмерное увлечение макросами всегда считалось плохим тоном во всех перечисленных языках. Элегантности кода не нужно приносить в жертву очевидность происходящего. Иначе бывает больно, вплоть до полного выкидывания и переписывания заново. В общем, моё ИМХО по этому вопросу умеренное, не приемлет обе крайности.
V>>Нужно нечто более полезное из прикладных IT-областей.
WH>Бла-бла-бла.
Кстати, показательно. По-твоему, "настоящие программисты" должны писать софт исключительно для других программистов и заниматься исключительно проблемами языков. Сорри, но это сразу в сад, не задерживаясь.
V>>Язык реализации — это последнее, что интересует. Вернее, не интересует никогда.
WH>Ну да... конечно.
WH>И после того как человек в это начинает верить получается всякая байда типа компиляторов на С.
А что не так с С? Отличная абстракция ассемблера. Настоящий нейтив во-плоти, без встроенных фокусов (если сравнивать с Паскалем, например). Что получится в итоге известно фактически до бит, что и требуется для ПО, непосредственно общающегося с кодом. С этого языка "взлетают" все современные аппаратные платформы, и уже поверх него работают все эти джавы, дотнеты и прочие экзотичности. Поверх него — т.е. поверх кода, созданного компилятором С. Фактически весь современный нейтивный код написан на С/С++, от операционок, офиса и БД, до дотнета и игрушек.
V>>Защитите хотя бы кандидатскую...
WH>И нахрена оно мне надо?
Чтобы привести в порядок собственные наработки. Чтобы в численном виде подсчитать характеристики и преимущества, наконец, если они есть. Чтобы провести и зафиксировать полноценное сравнение с имеющимися наработками в этой же области, показать прогресс (если есть), и характерные отличия.
Например, ты прямо сейчас способен обосновать, почему нерекурсивные алгебраические типы представлены ссылочными типами, хотя дотнет позволяет оперировать value-type? А ведь ML-языки умеют делать такие оптимизации уже черти сколько лет. Пяток подобных вопросов без убедительных ответов, и можно идти допиливать диссер, а лучше сам язык.
V>>Ну и самое главное — будущего инженера надо научить учиться, а остальное — шелуха и болтовня. Дотнетов, джав и прочих технологий будет еще много, заранее всему не научишь. А классика — она вечна.
WH>И что есть классика?
WH>С++?
Для императивных — Фортран/С/Паскаль. Функциональный — Лисп, логический — Пролог. Отличные языки для изучения парадигм. Почему отличные? — а ничего лишнего, никаких понтов, шелухи и синтаксического сахара. Да, в этом и проблема Пролога например, что у него плохая стыковка с "общепрограммисткими" задачами, типа ГУИ, БД, сетка и т.д. Но для целей изучения логического програмимрования — это наоборот, мега-плюс. Бо ничего лишнего.
V>>Во-первых, в 20 раз меньше кода — это ты переборщил.
WH>1)Читай что написано.
WH>2)Это факты.
WH>Причем даже без макросов.
Пока я не видел примеров. Все, что многократно приводились на этом сайте и по сто раз обсуждались в течении 5-ти лет, не дают такой разницы. Ну и домашние заготовки под определенные классы задач в любом более-менее универсальном языке накрутить можно.
V>>Насчет простоты поддержки... Чем более решение высокоуровневое, тем более дорогая нужна поддержка, то бишь требующая более дорогих спецов. Я пока сталкиваюсь ровно с противоположным, что мои более-менее неординарные снипетты кода ругаются более молодыми коллегами за "сложность и непонятность".
WH>Неординарные? Ты имеешь в виду лапшу?
Define "лапшу"?
WH>Не мудрено.
WH>Вот тебе кусочек кода. https://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n
А вот и оно, спасибо. Типичный индусокод. Ни малейшего понятия о декомпозиции и тестопригодности. Развязаться через независимые ф-ии видно не судьба.
Насчет тестопригодности. Ты должен будешь на один метод завязать как кучу низкоуровневых независимых тестов по проверке каждого отдельного вычисления, так и комплексные тесты, проверяющие их комбинации. А это залёт, курсант.
И где там пуля, ткни пальцем. 90% — ветвления идет по единичному тагу размеченного объединения.
Или в этих строках, что ли:
В факте предпросмотра на один уровень вперед (тоже самое тут: Fsm(a)::Fsm(b)::rest)? Да еще через ж... динамическую типизацию в реализации Nemerle? Издеваешься или как?
В общем, декомпозируй решение, и на любом языке это будет смотреться очень похоже. Ни в какие 20 раз и близко разницы не будет.
Далее, вот это ленивые вычисления или энергичные?
Если энергичные, то в топку, бо многопроходность, а оно вполне решаемо за один проход.
Тоже самое с Sequence(rules). Заметь, на плюсах тут вполне можно было обобщить на шаблонах оба случая. Но на немерле или C# — это надо было бы городить огород из паттерна "Стратегия" для целей обобщения, и овчинка выделки не стоила бы.
Собственно 90% функциональности метода рассмотрено. Проходишь по всем вложенным конструкциям и вызываешь оптимизацию правил для вложенных правил, если есть. Самих оптимизаций по сути две — это оптимизация последовательностей Not/And, и вызов FsmBuilder для цепочек символов и автоматов.
Далее. Есть предложение для обоих случаев насчет возможности построения оптимизированного варианта сразу, по мере парсинга правил, а не "потом", за вот этот проход оптимизации. Это как разница в подходах построения ДКА — сначала можно строить по регулярным выражениям НКА, приводить его к ДКА, а затем минимизировать, но ведь можно строить сразу минимизированный ДКА — это порой на порядок быстрее, т.к. на каждом шаге обработке подвергается множество меньшей мощности. Хоть алгоритм и чуть более сложный, угу. К автомату, в свою очередь генерируемому вызываемым тут FSMBuilder это тоже относится.
Кстати, тут еще одно будет преимущество: optimize у тебя распадётся на составляющие, каждая из которых будет вызвана в нужном известном месте без дополнительной диспетчеризации по тагам (т.к. мы заведом знаем, где мы). А то сейчас имеем тот самый случай, когда сначала сливаем в бутылочное горлышко, а потом снова разливаем.
В общем, подкинь что-нить посущественнее, что ли...
WH>Прикинь как он будет выглядеть на С++.
Кое в чем буков будет больше, кое в чем меньше. Разницы в разы не будет. А после декомпозиции вообще будет фактически 1-в-1. Исключение составляют ленивые вычисления на IEnumerable, но это тогда на каком-нить C# надо воспроизводить. Или на плюсах таки сразу строить минимизированный вариант и не париться с последующей ленивой обработкой.
WH>И ответ "не хочу" на предложение прочитать статью, описывающую техники переднего края должен быть не мыслим.
А ну-ка, что у нас тут на передовом крае:
Причем предпоследнее — это скорее классификация имеющихся знаний, чем что-то новое. А последнее — тем более, довольно-таки прикладной репорт на основе имеющегося материала. В общем, что-то скорее нафталиновое, чем передовое. Да и есть ML-языки, которые пытаются реализовать эти наработки. И что эти яыки из себя представляют мы прекрасно знаем: неудобство для общеприкладных задач и тормозной получаемый код, требующий дохрена памяти. Был бы этот сыр бесплатный, весь этот материал давно был бы в мейнстриме.Gandy, Robin O. The simple theory of types. In Logic Colloquium 76, volume 87 of Studies in Logic and the Foundations of Mathematics, pages 173–181. North Holland, 1976.
Whitehead, Alfred North and Bertrand Russell. Principia Mathematica. Cambridge University Press, Cambridge, 1910. Three volumes (1910; 1912; 1913).
Ramsey, Frank P. The foundations of mathematics. Proceedings of the London Mathematical Society, Series 2, 25 (5): 338–384, 1925. Reprinted in (Braithwaite, 1931).
Church, Alonzo. A formulation of the simple theory of types. Journal of Symbolic Logic, 5: 56–68, 1940.
Martin-Löf, Per. An intuitionistic theory of types: predicative part. In H. E. Rose and J. C. Shepherdson, editors, Logic Colloquium, ’73, pages 73–118. North-Holland, Amsterdam, 1973.
Martin-Löf, Per. Intuitionistic Type Theory. Bibliopolis, 1984.
Berardi, Stefano. Towards a mathematical analysis of the Coquand-Huet calculus of constructions and the other systems in Barendregt’s cube. Technical report, Department of Computer Science, CMU, and Dipartimento Matematica, Universita di Torino, 1988.
Barendregt, Henk P. Lambda calculi with types. In Abramsky, Gabbay, and Maibaum, editors, Handbook of Logic in Computer Science, volume II. Oxford University Press, 1992.
Ну и опять же. Про узость самой области исследований языков ты похоже не въезжаешь абсолютно. Давай я тебя с утра до ночи алгоритмами обработки сигналов грузить буду? Это же круто! И даже область применения на многие порядки шире. Это настолько повсеместно используется, что вы просто не замечаете. Оно "работает и всё". Но в ней как раз "передних краев" дофига, т.е. гораздо больше свежака (катализованного спросом на сетевые технологии), в отличие от всего этого нафталина в области ФП и доказательства теорем.
Ну и по последнему писку моды тоже хватае тпроблем и они известны. Для зависимых типов — это ввод значений, требующий в общем случае техники суперкомпиляции (а не того подобия техники динамического приведения, что ты когда-то предлагал), а uniqueness типы имеют проблемы в многопоточном окружении. Собственно, эта практика еще допиливается, исследования идут именно в направлении как сделать это полезным на практике, и до мейнстрима прямо сейчас еще далеко. Такова се ляви.
WH>Лаптев на предложение почитать про немерле сказал примерно тоже самое но другими словами.
Дык, Немерле ведь от всего вышеупомянутого страшно далек, ты его сюда не приписывай. Он просто динозавр, родившийся поздно. Представляет из себя сугубо практическую попытку собрать несколько полезных наработок в одном языке на основе имеющейся мощной платформы, угу. В общем, вовсе не "край", а сугубо практическая попытка найти приемлемый компромисс м/у обилием фич и привносимыми ими помехами. Кстати, я не отрицаю полезность этой попытки. Скорее наоборот, обоими руками ЗА. Ведь макросы в С несколько сдали назад по тем временам и подорвали доверие к этой технике. Например, даже возможности макроассемблера на порядок превосходят возможности препроцессора С, не говоря уже о 50-летнем Лиспе или 40-летнем Форте. Пора вернуть макросы на заслуженное место, снабдив их типобезопасностью. Возможно, Немерле своим примером поможет сделать это в следующих версиях интересных мне языков. Хотя, справедливости ради, чрезмерное увлечение макросами всегда считалось плохим тоном во всех перечисленных языках. Элегантности кода не нужно приносить в жертву очевидность происходящего. Иначе бывает больно, вплоть до полного выкидывания и переписывания заново. В общем, моё ИМХО по этому вопросу умеренное, не приемлет обе крайности.
V>>Нужно нечто более полезное из прикладных IT-областей.
WH>Бла-бла-бла.
Кстати, показательно. По-твоему, "настоящие программисты" должны писать софт исключительно для других программистов и заниматься исключительно проблемами языков. Сорри, но это сразу в сад, не задерживаясь.
V>>Язык реализации — это последнее, что интересует. Вернее, не интересует никогда.
WH>Ну да... конечно.
WH>И после того как человек в это начинает верить получается всякая байда типа компиляторов на С.
А что не так с С? Отличная абстракция ассемблера. Настоящий нейтив во-плоти, без встроенных фокусов (если сравнивать с Паскалем, например). Что получится в итоге известно фактически до бит, что и требуется для ПО, непосредственно общающегося с кодом. С этого языка "взлетают" все современные аппаратные платформы, и уже поверх него работают все эти джавы, дотнеты и прочие экзотичности. Поверх него — т.е. поверх кода, созданного компилятором С. Фактически весь современный нейтивный код написан на С/С++, от операционок, офиса и БД, до дотнета и игрушек.
V>>Защитите хотя бы кандидатскую...
WH>И нахрена оно мне надо?
Чтобы привести в порядок собственные наработки. Чтобы в численном виде подсчитать характеристики и преимущества, наконец, если они есть. Чтобы провести и зафиксировать полноценное сравнение с имеющимися наработками в этой же области, показать прогресс (если есть), и характерные отличия.
Например, ты прямо сейчас способен обосновать, почему нерекурсивные алгебраические типы представлены ссылочными типами, хотя дотнет позволяет оперировать value-type? А ведь ML-языки умеют делать такие оптимизации уже черти сколько лет. Пяток подобных вопросов без убедительных ответов, и можно идти допиливать диссер, а лучше сам язык.
V>>Ну и самое главное — будущего инженера надо научить учиться, а остальное — шелуха и болтовня. Дотнетов, джав и прочих технологий будет еще много, заранее всему не научишь. А классика — она вечна.
WH>И что есть классика?
WH>С++?
Для императивных — Фортран/С/Паскаль. Функциональный — Лисп, логический — Пролог. Отличные языки для изучения парадигм. Почему отличные? — а ничего лишнего, никаких понтов, шелухи и синтаксического сахара. Да, в этом и проблема Пролога например, что у него плохая стыковка с "общепрограммисткими" задачами, типа ГУИ, БД, сетка и т.д. Но для целей изучения логического програмимрования — это наоборот, мега-плюс. Бо ничего лишнего.
V>>Во-первых, в 20 раз меньше кода — это ты переборщил.
WH>1)Читай что написано.
WH>2)Это факты.
WH>Причем даже без макросов.
Пока я не видел примеров. Все, что многократно приводились на этом сайте и по сто раз обсуждались в течении 5-ти лет, не дают такой разницы. Ну и домашние заготовки под определенные классы задач в любом более-менее универсальном языке накрутить можно.
V>>Насчет простоты поддержки... Чем более решение высокоуровневое, тем более дорогая нужна поддержка, то бишь требующая более дорогих спецов. Я пока сталкиваюсь ровно с противоположным, что мои более-менее неординарные снипетты кода ругаются более молодыми коллегами за "сложность и непонятность".
WH>Неординарные? Ты имеешь в виду лапшу?
Define "лапшу"?
WH>Не мудрено.
WH>Вот тебе кусочек кода. https://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n
А вот и оно, спасибо. Типичный индусокод. Ни малейшего понятия о декомпозиции и тестопригодности. Развязаться через независимые ф-ии видно не судьба.
Насчет тестопригодности. Ты должен будешь на один метод завязать как кучу низкоуровневых независимых тестов по проверке каждого отдельного вычисления, так и комплексные тесты, проверяющие их комбинации. А это залёт, курсант.
И где там пуля, ткни пальцем. 90% — ветвления идет по единичному тагу размеченного объединения.
Или в этих строках, что ли:
| Not(Not(rule)) => optimize(Rule.And(r.Location, rule))
| And(Not(rule)) => optimize(Rule.Not(r.Location, rule))
| Not(And(rule)) => optimize(Rule.Not(r.Location, rule))
| And(And(rule)) => optimize(Rule.And(r.Location, rule))В факте предпросмотра на один уровень вперед (тоже самое тут: Fsm(a)::Fsm(b)::rest)? Да еще через ж... динамическую типизацию в реализации Nemerle? Издеваешься или как?
В общем, декомпозируй решение, и на любом языке это будет смотреться очень похоже. Ни в какие 20 раз и близко разницы не будет.
Далее, вот это ленивые вычисления или энергичные?
| Choice(rules) =>
def rules = rules.Map(optimize);
def rules = rules.Map(
fun(_)
{
| Rule.Choice(rules) => rules
| rule => [rule]
});
def rules = rules.Flatten();
...Если энергичные, то в топку, бо многопроходность, а оно вполне решаемо за один проход.
Тоже самое с Sequence(rules). Заметь, на плюсах тут вполне можно было обобщить на шаблонах оба случая. Но на немерле или C# — это надо было бы городить огород из паттерна "Стратегия" для целей обобщения, и овчинка выделки не стоила бы.
Собственно 90% функциональности метода рассмотрено. Проходишь по всем вложенным конструкциям и вызываешь оптимизацию правил для вложенных правил, если есть. Самих оптимизаций по сути две — это оптимизация последовательностей Not/And, и вызов FsmBuilder для цепочек символов и автоматов.
Далее. Есть предложение для обоих случаев насчет возможности построения оптимизированного варианта сразу, по мере парсинга правил, а не "потом", за вот этот проход оптимизации. Это как разница в подходах построения ДКА — сначала можно строить по регулярным выражениям НКА, приводить его к ДКА, а затем минимизировать, но ведь можно строить сразу минимизированный ДКА — это порой на порядок быстрее, т.к. на каждом шаге обработке подвергается множество меньшей мощности. Хоть алгоритм и чуть более сложный, угу. К автомату, в свою очередь генерируемому вызываемым тут FSMBuilder это тоже относится.
Кстати, тут еще одно будет преимущество: optimize у тебя распадётся на составляющие, каждая из которых будет вызвана в нужном известном месте без дополнительной диспетчеризации по тагам (т.к. мы заведом знаем, где мы). А то сейчас имеем тот самый случай, когда сначала сливаем в бутылочное горлышко, а потом снова разливаем.
В общем, подкинь что-нить посущественнее, что ли...
WH>Прикинь как он будет выглядеть на С++.
Кое в чем буков будет больше, кое в чем меньше. Разницы в разы не будет. А после декомпозиции вообще будет фактически 1-в-1. Исключение составляют ленивые вычисления на IEnumerable, но это тогда на каком-нить C# надо воспроизводить. Или на плюсах таки сразу строить минимизированный вариант и не париться с последующей ленивой обработкой.