Здравствуйте, VladD2,

Рискну дать тебе совет: ты лучше не с ветряными мельницами борись в попытках найти ответ на вопрос, что останавливает людей от изучения новых языков, а собери статистику причин, которые заставляют изучать новые языки. Ручаюсь, узнаешь много нового и неожиданного.

Здравствуйте, WolfHound, Вы писали:

WH>И ответ "не хочу" на предложение прочитать статью, описывающую техники переднего края должен быть не мыслим.

А ну-ка, что у нас тут на передовом крае:

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.

Причем предпоследнее — это скорее классификация имеющихся знаний, чем что-то новое. А последнее — тем более, довольно-таки прикладной репорт на основе имеющегося материала. В общем, что-то скорее нафталиновое, чем передовое. Да и есть ML-языки, которые пытаются реализовать эти наработки. И что эти яыки из себя представляют мы прекрасно знаем: неудобство для общеприкладных задач и тормозной получаемый код, требующий дохрена памяти. Был бы этот сыр бесплатный, весь этот материал давно был бы в мейнстриме.


Ну и опять же. Про узость самой области исследований языков ты похоже не въезжаешь абсолютно. Давай я тебя с утра до ночи алгоритмами обработки сигналов грузить буду? Это же круто! И даже область применения на многие порядки шире. Это настолько повсеместно используется, что вы просто не замечаете. Оно "работает и всё". Но в ней как раз "передних краев" дофига, т.е. гораздо больше свежака (катализованного спросом на сетевые технологии), в отличие от всего этого нафталина в области ФП и доказательства теорем.

Ну и по последнему писку моды тоже хватае тпроблем и они известны. Для зависимых типов — это ввод значений, требующий в общем случае техники суперкомпиляции (а не того подобия техники динамического приведения, что ты когда-то предлагал), а 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# надо воспроизводить. Или на плюсах таки сразу строить минимизированный вариант и не париться с последующей ленивой обработкой.

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

А какие новые языки ты изучил в последнее время, и какие из них ты бы в первую очередь порекомендовал для изучения другим?

Здравствуйте, VladD2, Вы писали:

VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".

Исключительно этот пункт. Вообще не выходит изучать что-то "для себя" — вроде и интересно, а "не идёт". Кстати, с обычными языками та же беда: заинтересовался было испанским, почитал, посмотрел, пару песенок перевёл, да и забросил.

Здравствуйте, WolfHound, Вы писали:


V>>Значимость парадокса Блабла ИМХО преувеличена. Этот парадокс скорее применим к студенту 1-го курса, пока он прошел только тройку императивных языков по программе, и ему еще не прочитали другие языки и парадигмы. Потому как после 2-3-го курса профильного обучения с его Лиспами, Прологами, ИИ, базами знаний и курсовыми по разработке "запчастей" компиляторов, остальное выглядит как "где-то я ЭТО уже видел".
WH>Это не правда.
WH>Вон посмотри на Дворкина с Лаптевым. Они блин профессоры!

Профессорство за знание языков, слава богу, не дают. Нужно нечто более полезное из прикладных IT-областей. Язык реализации — это последнее, что интересует. Вернее, не интересует никогда. Если только сама специализация не на языках, но это крайне узкая область IT и ей занят маленький % научного народу. Кстати, если ваши эксперименты действительно что-то новое и полезное дадут, дык, отбросьте лень, накатайте диссер на эту тему. Защитите хотя бы кандидатскую... По возрасту еще не очень поздно.


WH>Но один застрял в С++ другой в обероне.

Оба достаточно универсальны для целей обучения императивному программированию.

Для примера, Лисп тоже весьма проблемный язык, как и Пролог, и не зря есть куда как более "продвинутые" современные их аналоги, однако же их успешно преподают на курсе "языки обработки знаний", потому как если студент поймет как работает программа на Лиспе и Прологе, он поймет и принцип работы более современных поделок.

Ну и самое главное — будущего инженера надо научить учиться, а остальное — шелуха и болтовня. Дотнетов, джав и прочих технологий будет еще много, заранее всему не научишь. А классика — она вечна.

WH>И ничего за их приделами не видят.

Прекрасно видят. Не видят пользы для целей обучения. Даже Паскль и С/С++ на отлично в ВУЗах знает меньше половины студентов. Или в твоей группе, где ты учился, была другая статистика? В общем, куда там твои "гигиенические макросы"... Захотят быть спецами — изучат сами, тем более после Лиспа.

WH>Вот только ты сильно преуменьшаешь значимость языка.
WH>Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.

Во-первых, в 20 раз меньше кода — это ты переборщил. Когда речь идет о такой катастрофической разнице, то уже используются кодогенераторы, даже самописные. Получить эти 20 раз можно лишь на очень маленьком классе задач, вот например то самое описание DependecyProperty в сравнении с C#. Но, во-первых это очень малая часть проекта, а во-вторых, в крайнем случае на макросах-шаблонах CLR/C++ с опцией компиляции в чистый байткод тоже выкрутиться можно в те же 20 раз, подготовив некий синтаксис простого перечисления.

А вот на произвольно взятой общей задаче, где нет "домашних заготовок" ты эти 20 раз не получишь никогда, ибо решения верхнего уровня будет выглядеть весьма похоже даже на разных языках, а все низлежащее придется делать и там и там.

Приличный разгон дает лишь повторное использование кода во многих проектах. Но это работает даже на библиотечном уровне.

Насчет простоты поддержки... Чем более решение высокоуровневое, тем более дорогая нужна поддержка, то бишь требующая более дорогих спецов. Я пока сталкиваюсь ровно с противоположным, что мои более-менее неординарные снипетты кода ругаются более молодыми коллегами за "сложность и непонятность". Они так и говорят, пусть будет в 3 раза больше кода, но пусть оно будет в 3 раза понятней и без сюрпризов в отладке. Спрашиваю — ну дык если что-то переделать, вам в 10 раз больше переделывать придется, вместо того, чтобы подкрутить в одном месте — "пусть, зато за конечное время".

В общем, добро пожаловать в реальность.

От изучения не останавливает ничего, каждый разработчик изучает за свою жизнь великое множество всякой дряни, и в большинстве своем, это куда менее забавно чем поиграть с новым языком.
Правильный вопрос — что подталкивает к изучению. Подталкивают реальные задачи, они уже стоят, их уже нужно решать. И пока не будет очевидно что существующие инструменты для этих задач плохо подходят — вряд-ли кто-то будет искать что-то новое

Для примера миграция части проекта на шарп произошла исключительно из-за GUI библиотек на нете. Сам язык как никого не интересовал тогда, так никого не интересует и сейчас
Еще часть проекта мигрировала на шарп из-за необходимости написать тонкого веб клиента. И опять сам язык никого не интересовал ни тогда, ни сейчас

Здравствуйте, VladD2, Вы писали:

ГВ>>Не, этот код я полностью не могу прочесть, потому что смутно представляю себе постановку задачи. ПМ, язык — это всё шелуха. Кстати, спасибо, что объяснил, что именно и зачем тут оптимизируется.

VD>Нет, уважаемый. Код тут вполне очевидный. Вон тот же vdimas разобрался с ним на раз. Даже нашел реальный недостаток — небольшое дублирование функционала. А вот ты его не понял.

Как по мне, так тут недостатков намного больше. Кстати, что характерно, vdimas понял и моё высказывание тоже.

VD>>>Ген. Не моли чушь просто от того, что ты не понимашь написанного. Ну это же бред.
ГВ>>А... Да, есть ошибочка.
VD>Это не ошибочка. Это полное непонимание. Оно не мудренно. ПМ — это действительно другой подход к программированию. Но я тебе уверяю, что освоить его полезно просто для собственного развития.

Завелась шарманка... Оказывается локальный байндинг имён — это killer feature, надо мужикам с Прологом рассказать, что они, оказывается, на острие прогресса. Влад, как ты думаешь, почему я упустил это из внимания?

ГВ>>Вызов optimizie нужно было записать примерно так: optimize(And(r.Location, rule.r.r), чтобы показать, что новый узел формируется из вложенного. Но это простительная неточность в данном случае.

VD>Ага. Это простительная. Это — опечатка. А вот это "if (match(rule, Not(Not()))" полная чуешь.

Это почему это? Допущение для иллюстрации, не более того. В реальности код может выглядеть примерно так:

if (match(rule, Rule(Rule::Not, Rule(Rule::Not)))) ...

Что с помощью инлайновых функций несложно упрощается до искомого:

if (match(rule, Not(Not())))) ...

Можно помудрить и с привязкой переменных, получится что-то в этом роде:

if (match(rule, Not(Not, &subRule))) ...

То есть в subRule (скорее всего, это будет какой-нибудь smart-указатель) попадёт результат унификации, сиречь, анализа, выполняемого функцией match. Термин "унификация" употреблён из-за схожести процесса с прологовской унификацией.

ГВ>>Я же полностью рабочий код не собирался делать.
VD>А кому интересны не работающие выдумки? Я тогда могу тоже код представить: Done! и заявить, что он решает данную задачу.

Как минимум, они интересны тебе, раз ты продолжаешь их обсуждать.

ГВ>>Кстати, Not(Not()) может быть заменён на статическую константу:
ГВ>>

static const NotNotRulePattern = Not(Not());
ГВ>>...
ГВ>>else if (match(rule, NotNotRulePattern)) ...
ГВ>>

VD>Ну, то есть ты перемещаешь код проверки объекта в match. А что тогда ее код не приводишь?

Так он тривиальней некуда, хотя зависит от реализации самого Rule. Вот из-за того, что мне лень всё это раскручивать, я и не привожу код match.

VD>Кроме того ты не понял важной фишки ПМ. ПМ не только распознает паттерн, но и производит декомпозицию структуры данных.
VD>Паттерн:
VD>

VD>| Not(Not(rule)) => ... rule ...
VD>

VD>означает выполнить код "... rule ..." в случае если сопоставляемый объект это экземпляр типа None у которого поле rule яляется так же экземпляром типа None, и если этот паттерн распознался, то связать с полем rule вложенного типа локальное имя rule. В коде обработчика (том что идет за =>) в rule будет находиться ссылка на поле вложенного типа. Кроме того тип поля rule Rule (а это базовый тип для Not и остальных правил), так что ПМ за одно осуществляет проверку типов.

Угу, спасибо за объяснение. Почему-то ничего нового для меня тут не прозвучало. Да, я действительно не придал значения локально связанным именам, но, в общем, на мой вывод (и на иллюстрацию) это никак не влияет.

ГВ>>Спасибо за перевод, но это мне понятно.
VD>Очевидно же, что не понятно. Или надо констатировать факт — ты обманываешь намеренно.

Кого обманываю и в чём?

ГВ>>Конечно, не гарантируется. Только кто тебе сказал, что по отношению к такому примеру цикл заметно ухудшит код?
VD>Мне говорить не надо. Я это на своей шкуре проходил. Это и замедление, и возможность вылететь по переполнению стека.

Я не доверяю переживаниям "твоей шкуры" уж лет восемь как. Так что, не стоит бередить старые раны.

ГВ>>Цикл тут один, подразумевается он в любом случае, хотя бы в виде tail-оптимизированной рекурсии через ПМ, так что, на "понимаемость" кода его введение повлияет слабо.
VD>Ну, ты давай, перепиши весь пример на знакомом тебе языке, так чтобы он работал и сравним.
VD>С рекурсией здесь все шоколадно, а цикл сразу добавит грязи.

Немного добавит, не спорю, но принципиальным для сопровождения это не станет. Главная проблема здесь в теоретической основе этих самых match-ей, что ты сам и доказал, сказав, что Wolfhound потратил пару месяцев на... Короче, не помню, на что именно, на что-то теоретическое.

ГВ>>Да и управляться он, пожалуй, будет лучше.
VD>

ГВ>>Иными словами, приведённый фрагмент будет выглядеть где-то так:

ГВ>>

else if (match(rule, Not(Not())) { rule = And(r.Location, rule); continue; }

VD>Это бред, который даже не скомпилируется. Зачем повторяться?

Чтобы показать, где именно будет стоять continue в этом коде.

VD>>>2. Компилятор немерла работает не с объектами, а свариантами. Это позволяет ему контролировать, что match-и обрабатывают все возможные сочетания. В твоем случае такая проверка невозможна в приципе.

ГВ>>Хм. Not(Sequence(rule)) где? Ты ведь говоришь обо всех возможных сочетаниях, нет? Кстати, сочетания какой длины гарантированно контролируются?

VD>Контролируется, что в операторе match перехвачены все случаи, а не то что в коде присутствует перемножение всех сочетаний. [...]

Ясно, спасибо. Собственно, этого я и ждал (хотя надеялся на чудо) — да, контролируется полнота проверки по всем возможным вариациям данного АлгТД, но никак не его сочетаний. Пожалуй, что мне теперь стоит зацепиться за твою фразу: "...что match-и обрабатывают все возможные сочетания" и поднять шум о том, какой ты бессовестный обманщик и как вводишь в заблуждение своих наивных слушателей.

VD>Таким образом верхние паттерны (например, Not(Not(rule))) распознаю частные случаи, а нижние (например, Not(rule)) более общие.
VD>В ПМ важен порядок. Паттерны идущие выше более приоритеные. Если они сопоставились, то нижние уже не проверяются.

Короче говоря, порядок перебора совпадений — "сверху-вниз" в порядке перечисления. В принципе, схоже с пролог-машиной, только там учитывается порядок занесения предикатов в базу данных. Правила перебора совпадают с точностью до деталей реализации вычислительной среды.

VD>>>Так что описанная выше прямая трансляция является плохим стилем. Стало быть ее, по уму, нужно заменить на использование паттерна посетитель. Но как только ты это сделашь распознование вложенных паттернов (Not вложенный в Not, как в данном примере) превратится в мучение. Кода станет уже не в 5, а в 10-20 раз больше.
ГВ>>Влад, ты когда с самим собой разговариваешь, клавиатуру в сторону отодвигай. При чём тут паттерн "посетитель"?
VD>При том, что он описывает список веток которые нужно посещать и как и ПМ гарантирует, что ты не забудешь посетить их все.

Ценой распыления аналитического кода по всем классам? Ну, я не спорю, субъект с тяжёлым синдромом ООП головного мозга способен и на такое ради "гарантий". Только зачем болезнь выдавать за правило?

ГВ>>То есть я понимаю, каким боком его тут можно привинтить, но это как тебе сказать... Нечто вроде метода показать наихудший из возможных способов реализации. Здесь самая обыкновенная трансформация дерева структур, даже ОО-стиль особо-то впихивать некуда.
VD>Посетитель наилучший способ из имеющихся в арсенале ООП. Код обработки выделяется в одном месте. Есть возможность гарантировать, что посещены все ветки. Можно добавлять другие обработки не ломая уже существующие и не вводя тонны методов (по одному на каждую ветку).

Хм. Зачем ты так рьяно защищаешь такое убогое применение ООП? Ну, я как бы в курсе твоего любимого метода критики — взять нечто идиотское, реализованое на языке X и на этом основании заклеймить весь язык X, но это не совсем чистоплотно, не находишь?

VD>Если тебе это не очевидно, я не виноват.

Ты понимаешь, в чём проблема, я переболел парадигмами и прочими идеологиями уже довольно давно. Поэтому то, о чём ты говоришь, мне очевидно, но очевидно ещё и то, что сейчас я (и не только я) без веских причин так не сделаю, чтобы там ни тарахтели разнообразные ООП-пуристы и прочие, сдвинутые на спасении мира посредством чистоты парадигмы. Честно, мне плевать, как код реализации проецируется на некий идеал, взятый из той или иной химеры (aka парадигмы), я руководствуюсь вполне локальными соображениями.

VD>Вариант с МП обладает всеми теми же достоинствами плюс:
VD>1. Намного более краткий.
VD>2. Позволяет легко обрабатывать сложные случаи (вложенные паттерны).

VD>В приведенном примере вложенность небольшая (2). Но она не ограничена. И чем сложнее анализ, тем полезнее становится ПМ.

Я не спорю с тем, что ПМ полезен, но это далеко не то, ради чего стоит пускаться во все тяжкие (читай, непременно менять язык реализации и т.п.).

VD>>>Так что насмехаешься и горлопанишь ты тут исключительно от своей невежественности. Ну, а приведенный тобой "код" просто нерабочий.
ГВ>>Конечно, не рабочий, я и не пытался делать его рабочим. Я тебе что, полный PEG-парсер буду переписывать?
VD>Ну, а что обсуждать набор символов нечего не имеющий с реальным кодом?

Разницу между иллюстрацией и фрагментом рабочего кода объяснять нужно?

ГВ>>Не, Влад, эпопею с делегатами я повторять не буду — одного раза мне хватило.
VD>Я не слышал про эпопею с делегатами, но если там ты приводил такой же бред вместо года, то понятно что ты "победил" в том споре. Ведь всегда можно написать краткий и понятный, но неправильный код.

Я же говорю, что переживаниям "твоей шкуры" я доверяю чуть менее, чем никак. Ты теперь сам прекрасно подтверждаешь мои размышления. Поищи в Исходниках по ключевому слову "Делегаты на C++", там даже твои комментарии имеются. Лаялись, кстати, знатно. Что характерно, с того момента ты, если я ничего не путаю, уже изменил свою оценку значения делегатов, как таковых. А в C++ появились лямбды.

ГВ>>Это не значит ничего. То есть я хотел сказать, что в соответствии с правилами форума ФП из этих двух фактов можно сделать совершенно любой вывод.

VD>Ты? Да, пожалуй.

Я? Да, пожалуй, что не могу.

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Изучать что-то новое всегда останавливает отсутствие материала для обучения.

Если брать конкретно nemerle:
1)Когда будет спецификация языка на уровне Ecma-334?
2)Когда появится Nemerle Team Blog или что-то в этом роде, где будут свежие новости, примеры, анонсы итп?
3)Когда будут статьи с внятными объяснениями чем макросы помогут рядовому программисту, который не компиляторы и DSL изобретает, а нечто более приземленное?
4)Когда появится хотябы одна книга или учебный курс по Nemerle?
5)Когда будет справка по библиотеке nemerle и макросов на уровне MSDN?
6)Когда будут опубликованы скринкасты, показывающие вживую разработку на nemerle?

Кстати если вы изобретаете свои фреймворки "независимые от asp.net\ado.net\что_то_там_net, то все указанное выше касается и этих фреймворков тоже.

Здравствуйте, VladD2, Вы писали:

Ничего не останавливает. Изучаю, стараюсь применять на практике. Единственное исключение — Nemerle. Отпугивает сложиышшеся вокруг него сообщество в RSDN. Не хочется даже близко подходить.

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Тут большиинство телепатирует, что вопрос скорее всего был задан с целью понять, почему народ не хочет изучать Немерле. Это не обязательно так, но предположим, что так.

Ответ простой: не нужен

Это почти что "3. Политические предпосылки — Все равно не смогу применять его на работе....", но не совсем.

Дальше идет мало отформатированный и плохо сформированый поток сознания

Итак, последние пару месяцев я периодически (по работе и для души) писал на:
— PHP
— Python
— Javascript
— Java
— Erlang

Оказалось, что эти 5 языков покрывают мои нынешние и будущие потребности, как бык корову. И куда и зачем впихивать туда еще один язык программирования —

То есть совсем непонятно, какие проблемы этот язык решит лично для меня.

— PHP. Мне за него платят. Так что приходится
— Python. На нем решаем проблемы, с которыми РНР не справляется. Быстрее, чем РНР, скриптовый, достаточно простой и лаконичный — то, что доктор прописал именно для скриптов (1000 строчек — практически потолок).
— Javascript. Ну, в вебе без него никуда
— Java. Потому что в graph databases она сейчас рулит со страшной силой, а я все думаю, куда эти самые базы применить
— Erlang. Потому что я все же подсел на Zotonic CMS ну и вообще он мне нра

Ну и не говоря о плюшках, которые каждый из этих языков предлагает (да, и РНР тоже):
— PHP. LAMP или LNMP (N == nginx). Проверенная годами связка
— Python. Скрипты + некоторая изящность самого языка + уже готовые удобные библиотеки типа Mysqldb/PIL и некоторых других
— Javascript. В вебе без него никуда А также ExtJS, jQuery И т.п.
— Java. Потому что мегакрутые фичи для graph databases на Java.
— Erlang. Думаю, и так понятно Асинхронность, параллельность и тыды и тыпы.

А зачем мне нужен Немерле?

Тут, помнится, не раз жаловались, что новые люди, приходящие в Немерле, через пару недель начинают писать компилятор вместо того, чтобы разрабатывать какие-то другие проекты на Немерле. Вот тут кроется и ответ на вопрос "почему" и на вопрос "зачем".

Если отойти в сторонку и взглянуть на суету вокруг Немерле, а также на сообщения людей, его продвигающих, то окажется, что:
— этим людям интересно языкостроение и написание компиляторов
— этим людям интересны парсеры, их теория и построение

Не даром в качестве killer-фичи языка в последнее время приводится именно Nemerle.Peg. Ведь несмотря на то, что формально язык позиционируется, как язык общего назначения, (подавляющее?) большинство разговоров о нем сводится имено к парсингу и/или компилятору.

Если бы я интересовался этими вопросами, то, возможно, меня Немерле и заинтересовал. Но, увы Даже для того самого PEG у меня на руках есть Neotoma для Erlang'а


Как-то так

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

В основном останавливает уверенность в том, что не в языке загвоздка. Прикладная IT-область, с которой работаешь, порой требует внимания и объема знаний на порядки больше, чем требуется для изучения некоего языка и его основных либ. И еще останавливает тот факт, что в багаже уже хватает историй с изучением языков до приличного уровня, успешного их применения в течении некоторого продолжительного времени, а потом это всё становится не нужным на новых проектах. Сколько еще подобного балласта надо изучить? К тому же, изучение языков — это вовсе не фундаментальные знания IT, а тоже весьма прикладные, недалеко отстоящие по характеру "знаний" от каких-нить библиотек или АПИ. Ну и самое главное, изучение языка и его использование не занимает исторически долгое время. Особенно при наличии достаточного кол-ва исходников, про которые можно сказать — "это true style для данного языка". Т.е. учить новые языки вполне можно (и желательно) для реальной работы на них, а не ради ознакомления с еще одним "занимательным диалектом".

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Время одиночек прошло, вот что останавливает. Приходится подстраиваться под команду.

Ты лучше поинтересуйся, что именно толкает людей на изучение новых языков. Это куда интереснее, ибо отсутствие каких-либо причин не изучать язык Х — не является причиной немедленно бросаться его изучать.

Здравствуйте, WolfHound, Вы писали:

WH>Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.

Если сущностей в коде в десять раз меньше, а не буковок.

Дабы не витать в абстракциях, я буду говорить по вопросу на примере Nemerle.
Меня от изучения языка не останавливает ничего. Наоборот, интересно в новом всём копаться. Часто идеи из разных языков программирования можно переложить на используемый повседневно(ну, например, использование ООП в ассемблере)

Но само по себе изучение даёт мало. Язык надо еще применять и, при том, применять на реальных задачах. Например, изучить синтаксис LUA можно за день-два. А вот так, чтобы сказать, что я на этом языке умею программировать, у меня ощущение появилось где-то через год, когда на этом языке решил много всяких разных задач(я работал в GameDev, а там LUA широко применяется) и попрограммировал игровой GUI в смешанном императивно-фунциональном стиле.

А вот от применения чего-то нового останавливают несколько вещей:
1. Риск. Всегда есть ненулевая вероятность, что я не смогу эффективно решить этим языком свою задачу, впустую потрачу время и придётся вернуться к привычным методам, если кто-то уже не решал подобную и нет success story об этом. Конечно же, интересно быть первопроходцем, интересно копать и искать лучшее, но почти всегда на это у компании нет ни времени ни денег. Всегда легче "педалить" старым, проверенным, стабильным методом.
2. Страх. Самое страшное — это внутренние ошибки языка, IDE, отладчика. И есть понимание, что, так как язык молодой, шишек на нём не набили, то может всплыть что угодно как раз посредине пути по реализации проекта. Кто мне даст гарантию, что баги быстро исправятся, если я сделаю багрепорт? Кто мне даст гарантию, что они вообще исправятся? Когда сообщество вокруг языка не является устоявшимся, нет, вообще, гарантии, что все просто не разбегутся.
3. Человеческая инертность. Ну вот я такой весь из себя рыцарь на белом коне кодер на розовом слоне, который готов применять новый подход и идеи, но, как убедить членов команды, что язык будет полезен и стоит его изучать, и на нём мы сможем решать задачи быстрее и лучше? Исходя из пунктов 1. и 2. это будет трудно. Я на работе рассказывал про Nemerle, про фичи, про то, что есть статьи и ведётся разработка, на что мне ответили: "Смысл на него смотреть? За пределы RSDN он не вышел, никто о нём не знает".

Здравствуйте, Undying, Вы писали:

WH>>Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.
U>Если сущностей в коде в десять раз меньше, а не буковок.

Кстати если сущностей столькоже, а кода очень мало получается наоборот. Кто поймёт собственный Regexp написанный месяц назад?

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
...
4. Утомило в очередной раз искать — как в языке N вывести число в формате 00.000. Ну и ещё тысячу мелочей.

Если отдача от изучения не очевидна, то всегда находятся более важные дела. В очереди на прочтение стоят десятки книг и статей.

Здравствуйте, Lloyd, Вы писали:

L>Корректный ответ на этот вопрос можно дать только зная язык.
L>Далее — см. парадокс Блаба.

Значимость парадокса Блабла ИМХО преувеличена. Этот парадокс скорее применим к студенту 1-го курса, пока он прошел только тройку императивных языков по программе, и ему еще не прочитали другие языки и парадигмы. Потому как после 2-3-го курса профильного обучения с его Лиспами, Прологами, ИИ, базами знаний и курсовыми по разработке "запчастей" компиляторов, остальное выглядит как "где-то я ЭТО уже видел".

Тем более что налицо следующее наблюдение: значительный прирост производительности программиста дает не столько язык, сколько наличие хороших библиотек и инструментария вокруг него. Джава или дотнет тому пример. Имеем тупые, как пробка, языки (по крайней мере C# в прошлых версиях), но мильон библиотек под все случаи жизни + одна из самых неплохих на сегодня IDE в сумме делают из тупейшего языка просто чудеса в плане производительности программиста. И даже миллионы индусов стали кому-то полезны. Значит, дело не столько только в языке, сколько в инфраструктуре: помимо среды и библиотек это доступный хороший справочный материал, форумы, книги, мильон примеров по интернету на все случаи жизни и т.д. Все это создает уверенность, что взяв этот язык вдруг не упрешься по ходу разработки в нечто, значительно прибавляющее трудоемкости и геммороя.

Здравствуйте, VladD2, Вы писали:

VD>Не неси пургу. Это трансформация дерева. Причем вынесенная в отдельную функцию (локализованная). Устранять здесь "диспечиризацию" — означает превращать код в говно смешивая разную логику.

Кто-то предложил устранить диспетчеризацию? Перечитай плиз замечания еще раз, бо ты пока не понял, что именно критикуется.


VD>Если ты до этого еще не до рос, то иди работай над собой, а не давай советы вселенского масштаба и вселенской же глупости.

И тебя приятно видеть все в той же боевой форме.

V>>Хе. А если ему Лисп привычен?
VD>Он только название такое знает.

А как с тобой люди работают? После пары итераций любого технического обсуждения с тобой самый адекватный ответ на твои выпады — это предложения эротического плана. В общем, поменьше рефлексии.

V>>А что, обрабатываемые правила могут иметь бесконечную вложенность?

VD>С достаточной чтобы получить переполнение стега.

Ты в состоянии нарисовать такую систему правил, что глубина графа выражений переполнит стек при его обходе?


V>>И вопрос на 1000000 баксов: в Немерле хвостовая рекурсия только в рамках одной ф-ии работает?

VD>К сожалению — да.

В принципе, тогда все ясно, половину обсуждения можно сворачивать.

VD>Проблема в том, что реализовать взаимную рекурсию для общего случая не так просто.

Общий случай спасает агрессивный инлайнинг, который умудряется раскручивать в цикл даже нехвостовую рекурсию. Хотя, суперкомпиляция — это отдельная тема, но мое ИМХО в том, что для языков с ПМ суперкомпиляция просто обязательна.

VD>Ну, не томи. Давай продемонстрируй нам код на шарпе или плюсах. Потом без посетителей конечно можно жить, но вот только до появления второго обхода дерева. После этого экономия на спичках сразу же превращается в гимор.

Это понятно, просто сия задача оптимизации сильно привязана к типу узла, и я многократно видел (и сам так же организовывал оптимизацию графов выражений) именно через ее реализацию в теле соответствующего объекта, представляющего узел. Бо задача как бы обязательная при построении графов выражений. Как минимум от лишних скобок (ваше And(And))) всегда избавляются.

Хотя, после пояснения относительно ограничений хвостовой рекурсии в N все вопросы отпадают. Беда, тут нечего обсуждать.
Вот этим стоило заняться в первую очередь. Просто все остальное бросить и заняться этим. Ибо (посмотри чуть со стороны) влияние фичи конкретной реализации компилятора на стиль писания на языке (а компилятор и язык, по идее, не одно и то же, хоть и верно для ваших реалий), это жирный такой минус. Факт: приведенный код сразу же сказал о св-вах компилятора заглянувшему человеку со стороны. Показательно.


VD>Код, кстати, не верный.

Проверь оригинал. Если же речь про Location, я позволил себе опустить подробности.


VD>А что ты будешь делать когда потребуется еще один уровень вложенности? Начнешь типы приводить и вложенные кейсы писать?
VD>Да, и не видно шаблонов! Ты тут ведь недавно про шаблоны говорил. Они же должны дать невероятный эффект.

Я говорил про код Гены и хелперы для синтаксиса.


VD>Очень интересно что ты будешь делать когда придется кроме оптимизации еще каую-то обработку сделать? Бежим по файлам и добавляем новые методы? Посетитель ведь нам не нужен.

Смотреть надо. Посетитель тоже тормоз порядочный, хоть и быстрее обычно на порядок, чем развесистый ПМ. Если не привязываться в AST к виртуальным вызовам и некоему "базовому интерфейсу", который не облокотился при наличии структурной типизации на шаблонах в С++, то конечно! бежать по файлам и добавлять легковесные операции в специализированные легковесные объекты, всё в инлайне и без виртуальных вызовов.

В общем, в плюсах свои интересные плюшки есть и их охотно пользуют.


VD>А где Команда? Ты ведь еще этот паттерн упоминал.

"Стратегию", а не "Команду". и не для матча, а для одной из операций во время пробега по списку.


VD>Если приглядеться, то несложно заметить, что код твой стал полным говном, так как контроль компилятора утрачен. Обрати внимание на то что МП контролирует наличие всех возможных пересечений в match.

Ты уж договаривай. Ваш матч так же позволяет задать дефолтное поведение, чтобы не описывать все варианты, если оно не надо. С++ тоже не позволит не вернуть значение, если его положено вернуть, поэтому там стоит default. Насчет лучшей типизированности решения на матчах я и не спорю, бо лучшая типизированность всегда лучше.

А замечания были о следующем, напомню:
— диспатчинг и обработка свалены в кучу, например, приведенные мной ф-ии не были завязаны даже на optimize, т.е. на ограничения по хвостовой рекурсии, т.е. они просто не нужны в теле этого метода. И их нельзя отдельно протестировать в данном оформлении. А тестировать надо, ведь вы запчасти компилятора пишете, и ошибка вероятна не только в этом коде, а где-то еще в компиляторе, но на этом участке она может просто проявиться.
— утверждения насчет 20 раз экономии строк кода.

Оба вопроса ортогональны друг другу.

VD>Серьзено? Вместо аж трех? Ты привел замену двум строкам кода:
VD>

VD> | Not(Not(rule))                => optimize(Rule.And(r.Location, rule))
VD> | And(Not(rule))                => optimize(Rule.Not(r.Location, rule))
VD>

VD>и то с ошибками.

Внимательнее смотрим:

        | And(Not(rule))                => optimize(Rule.Not(r.Location, rule))
        | And(And(rule))                => optimize(Rule.And(r.Location, rule))
        | And(rule)                     => Rule.And(r.Location, optimize(rule))

VD>В результате вместо двух строк ты получил 7 в сжатом виде.

Нет, я получил вместо N строк кода N+2. Дополнительные строки, связанные с закрывающими скобками, зависят от форматирования.

VD>А в придачу ты заработал геморрой на всю оставшуюся жизнь, так как код этот не будет контролироваться компилятором. Любой изменение в структуре правил сможет привести к долгим и мучительным вискиваниям мест в которых ты забыл добавить обработку.

Ровно наоборот. При удачной декомпозиции, любые изменения в ДРУГИХ, не связанных типах узлов, не повлияют на ЭТОТ код.

V>>"Рабочесть" приведенного кода зависит от обвески,

VD>Что за rule тут взялось из неоткуда? А Not(Not()) это что за хрень? Врменные объекты?

Вот, наконец вопросы по существу, хоть и развлекательного плана.

Да, Not(Not()) может быть чем угодно, например, временным объектом, и совсем другим, чем Tag::Not, т.е. специальным как бы "синтаксическим хелпером", он может быть 0-й длины, и служить исключительно целям визуализации диспетчеризации перегрузок сигнатуры match. В общем, в плюсах выбор синтаксиса невелик: это синтаксис вызова ф-ий (оно же вызов конструкторов) + переопределяемые имеющиеся операторы, в том числе operator(). Поэтому, тут возможны минимум три варианта. Один из них приведу ниже.

VD>Короче это бред, а не код. Его не заставить летать даже с помощью волшебной палочки.

С помощью ящика пива на спор гораздо проще.

VD>Не знаю. Покажи, я ознакомлюсь.

Так можно:

template<typename Tail>
struct Cons { Tag::Enum head; Tail tail;};

struct Nil {};

template<typename Tail>
inline bool match(Rule * rule, Cons<Tail> tagList) {
  retun rule && rule->tag() == tagList.head && match(rule->arg(), tagList.tail);
}

inline bool match(Rule * rule, Nil) { return false; }

#define DEFINE_HELPER(xtag) \
template<typename Tail>     \
Tag::Enum xtag(Tail tail = Nil()) { return make_cons(Tag::xtag, tail); } // make_cons() пусть идет как домашнее задание

DEFINE_HELPER(Not); 
DEFINE_HELPER(And); 
DEFINE_HELPER(Choice); 
DEFINE_HELPER(Sequence);

...
// пользуем
if(match(rule, Not(Not()))) { ... }

Здравствуйте, dimgel, Вы писали:

FR>>Чуть выше показали на шаблонах C++.
D>Чуть выше ответили так же, что в шаблонах используется динамическая типизация.

Структурная, а не динамическая. Это разыне вещи. Там типизация статическая (ты не можешь добавить метод классу в рантайме, шаблон не будет использовать метод из наследника) и структурная.

Здравствуйте, vdimas, Вы писали:

V>Время одиночек прошло, вот что останавливает.

Скорее, прошло время слепой веры в заоблачные возможности синтаксиса.

Здравствуйте, dimgel, Вы писали:


FR>>Для них обоих современные динамические языки именно "не читал но осуждаю" теоретики они.
FR>>У меня самого было очень похожее мнение насчет динамики, изменилось оно только через полгода программирования на питоне.

D>Как тебе уже ответил WolfHound, в твоих ответах отсутствуют конкретные возражения по конкретным претензиям к динамике. Чистое бла-бла-бла.

Их претензии претензии теоретиков, у них гипертрофированные претензии к тем вещам которые на практике не являются сколь либо значимыми помехами
при работе с динамическими языками. В теории они да во многом правы, и как по тебе видно могут быть и очень убедительны. Ну и плюс их большевистский
черно-белый взгляд на мир, этого достаточно чтобы спорить вечно.

D>Сам я не знаю питона, но я знаю PHP и скалу, и я вполне могу экстраполировать свой опыт со слабо-динамически-типизированным языком на сильно-, тем более, что это будет по сути не экстра- а интерполяция (там с другого конца скала подпирает).

Вот ты знаешь PHP а они нет.
Я PHP и JavaScript практически не знаю, но судя по тем же флеймам они гораздо более подвержены ошибкам чем питон и руби ввиду очень слабой типизации.

D>То есть, я знаю достаточно, чтобы квалифицированно оценивать аргументы обоих сторон.

Я тоже, так как пишу еще и на одном из самых сильно типизированных языков — OCaml.

D>Ты — сторона спора.

Я уже практически нет, так иногда огрызаюсь.

D>Я — посторонний наблюдатель. "В споре рождается истина" — это, конечно, полная брехня, но одно исключение я таки-обнаружил: в позиции постороннего наблюдателя картина максимально полная, учитывающая аргументы всех сторон. Это касается не только статики-динамики, но и rich-anemic, к примеру, и всех остальных срачей. Ну а ты, если тебе так охота защищать динамику, — так защищай её, продумывай ответы на аргументы твоих оппонентов. Наезды на их квалификацию — это не аргументы, а переход на личности.

Нет никаких наездов, я уважаю их квалификацию в той области в которой они специалисты.
Но у них нулевая практика в динамике (а знание любого языка на 90% практика) поэтому они не могут адекватно судить о важности и значимости
недостатков динамики которые конечно существуют и про которые они годами не устают повторять.

D>Доказывающий кстати, что твоя квалификация ниже, раз тебя не хватает на аргументы должного уровня.

Возможно и ниже, но не в динамике.
Аргументы тут не помогут, в теории они во многом правы, например в том что теоретически в динамических языках
должно быть гораздо больше ошибок на единицу функциональности, на практике этого не наблюдается. Чтобы это доказать
нужно проводить крупномасштабное исследование, чего я сделать не в состоянии.

1. принципиальная невозможность использования на практике
вот есть язык Go, и он интересен, но его нет под винду, а у меня все проекты под винду по этому учить мне его бессмысленно

2. наличие альтернативного языка
как-то я интереса ради поставил перл, прочитал тутор, поигрался в интерпретаторе
— да хороший интересный язык, но на этом всё закончилось, т.к. для скриптов я знаю питон который имеет схожую область применения,
при этом питон мне нужен для проектов на google-app-engine, для скриптов в одной проге, а для перла у меня таких "зацепок" нет

3. ограниченная возможность использования на практике
в основном у меня нативные проекты, потому что у многих юзеров нет .NET и я не могу заставить их его поставить.
по этому я мало интересуюсь .NET языками, скажем я изучил F#, почитал тутор немерле, но в текущих проектах я не могу использовать .NET, а значит мне пока нет никакого толку с этих языков.

4. отсутствие нормальных средств разработки для языка
VС++ живо в винде потому что есть ИДЕ (MSVC+VAX) которая лучше всех остальных ИДЕ и плагинов к блокнотам (для языков типа С++),
потому что есть компилятор с поддержкой расширений нужных в винде,
потому что есть хороший отладчик, .pdb и минидампы.
По этому нет смысла учить D, т.к. при всех минусах С++, разработка в VC++ будет быстрее и надежнее.

Аналогично — C#+решарпер лучше чем самая-последняя-версия-немерле+блокнот с подсветкой

Однако в ряде случаев 50 строк питона в IDLE лучше 2000 строк C++\C#\хзчего в самой навороченной ИДЕ


5. эстетические\религиозные соображения
я не понимаю, почему когда я в хаскеле компилю .dll, которая экспортирует функцию int32_t returns_x_plus_y(int32_t x, int32_t y), я получаю файл в котором более 1Мб кода. Это подрывает веру в компилятор и производительность программ.
Считайте это странным и несовременным, но я хочу юзать языки которые компилят большие исполняемые файлы.
(это относится и к mingw (который использует хаскель), и к D)

6. отсутствие нормальных библиотек для языка.
обычно проще взять старый добрый язык для которого всё есть,
чем новый для которого есть только какие-то альфа-версии биндингов и то не всех нужных библиотек

Здравствуйте, VladD2, Вы писали:

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Язык — это часто просто средство для достижения определенной цели.
Перед тем, как начать применять новый язык(новое средство), его надо выучить(освоить). Нет можно и по другому но лучше не надо
Перед тем, как начать изучать новый язык, люди обычно думают на тему "А действительно ли проблема в языке(средстве)?"
И обычно находят другие проблемы. Например недостаточный уровень владения старым инструментом.
Находят, решают и достигают цели. Все просто. Новый язык тут не нужен.

Бывают и другие случаи. Когда например изучение языка и есть цель. Вот тут новый язык очень нужен по определению.
Его изучают или даже придумывают.
А потом носятся с ним и с неуемным желанием хоть куда-нибудь его применить.
А вот с применением туговато. И начинается...
Вполне безобидная и простая фраза "Не нужен" становится самым сильным оскорблением. Ну и всякое такое.

Лично я — сторонник первого подхода. Более того я им зарабатываю на жизнь.
Хотя и во втором подходе я ничего особо плохого не вижу.
Мне правда кажется что им сложнее заработать(ну судя например по сегодняшним вакансиям), но кто знает что будет завтра

Здравствуйте, Undying, Вы писали:

L>>Корректный ответ на этот вопрос можно дать только зная язык.

U>Для этого достаточно думать не в терминах языка, а в терминах решаемой задачи. Тогда сразу становится видно хорошо ли наилучшее решение ложится на используемый язык или плохо. Если, как правило, ложится хорошо, то особо смысла искать новый язык нет.

Понятий "хорошо" и "плохо", имхо, не существует. Зато есть "лучше" и "хуже", для употребления которых уже и нужно зныние иных языков.

Здравствуйте, FR, Вы писали:

FR>Угу IDE'шки для питона сейчас уже вменяемее чем для C++.
Нашёл с чем сравнивать.
Ты хотя бы с интеграций немерле сравни.
Смех же на палочке. Питон намного старше. Имеет на порядки больше ресурсов, а все ИДЕ, в том числе коммерческие говно на фоне интеграции немерла.

Здравствуйте, FR, Вы писали:

FR>В теории и частично и на практике(PyPy) да является, для сильно типизированного динамического языка подмножество кода приводимого к статическому будет намного большим. Например тот-же PyPy транслирует код в статически типизированный RPython для которого все плюшки статически
FR>сильно типизированных языков доступны.
Но это возможно только для де-факто статически типизированных кусков кода.
Отсюда вывод: Код по факту статически типизирован. Но компилятору об этом почему-то ничего не говорят.
Следствие: Раз код и так статически типизирован то нахрена нам вообще динамическая типизация?

FR>Я так не считаю, как и множество других программистов.
FR>Юнит тесты в динамике да необходимы, но не тонны, их размер будет вполне сопоставим с размером оных для статики.
Ты почитай, что тебе говорят.
Как, например я код рефакторю: Правлю интерфейсы, и компилятор мне все места, где код поправить нужно находит.
Что мне может предложить питон?
Тесты гонять?
А где гарантия, что покрытие 100%?
А если оно и 100% то где гарантия что на вход все типы подаются?
А в случае со статикой мне забыть ни о чем не дадут.

Здравствуйте, vdimas, Вы писали:

V>Значимость парадокса Блабла ИМХО преувеличена. Этот парадокс скорее применим к студенту 1-го курса, пока он прошел только тройку императивных языков по программе, и ему еще не прочитали другие языки и парадигмы. Потому как после 2-3-го курса профильного обучения с его Лиспами, Прологами, ИИ, базами знаний и курсовыми по разработке "запчастей" компиляторов, остальное выглядит как "где-то я ЭТО уже видел".
Это не правда.
Вон посмотри на Дворкина с Лаптевым. Они блин профессоры!
Но один застрял в С++ другой в обероне.
И ничего за их приделами не видят.

V>Тем более что налицо следующее наблюдение: значительный прирост производительности программиста дает не столько язык, сколько наличие хороших библиотек и инструментария вокруг него.
Вот только ты сильно преуменьшаешь значимость языка.
Если кода в 10 раз меньше, то это не только разгоняет разработку раз в 20, но и упрощает поддержку раз в 100.

Здравствуйте, FR, Вы писали:

FR>Меняется, шаблоны статическая часть C++, динамики там нет.

Понятно, ты готов повторять слово "сахар", пока во рту не станет сладко.

D>>Тут уже двое отписали — WolfHound и adontz — что шаблоны C++ НЕстатические.
FR>adontz говорил ровно противоположное.

adontz говорил "В шаблонах Си++ структурная типизация." WolfHound — "В С++ типы динамически типизированы. Вот у нас есть template<class T>. И это все что у нас есть. Про тип T мы ничего не знаем пока его нам не дадут и мы не начнем компилировать данный шаблон с данным типом." Про статику никто из них не говорил.

FR>Тебе читать хотя бы Вандервуда "Шаблоны С++".

Не интересно. Ты в состоянии сам логично и последовательно объяснить, почему они — статика? Вышеупомянутые персоны не гнушаются аргументировать свои утверждения, чем ты хуже?

D>>При чём здесь твой окалм? О нём речь вообще не идёт. Начинаем сначала:
FR>Это статический жестко типизированный язык, обобщенное программирование в нем тоже есть.

И что?

D>>1) ты защищал динамику, утверждая, что её недостатки, описываемые немерлистами, несущественны.
FR>Нет, ты перевираешь, я говорил что они несущественны на практике.

Не придирайся к словам. Программирования — это практическая дисциплина. Теория никого не интересует.

D>>2) в ответ на просьбы указать преимущества динамики ты не смог сказать ничего.
FR>Не видел просьб, только нападки тролля.

Просьба шла от WolfHound: "Ну так где аргументы то? Есть только один: Меньше кода. Но это по сравнению с жабой меньше. А по сравнению с немерле экономии почти нет. А какие еще? Ну, хоть один."

D>>3) когда зашла речь о том, что тесты не дают никаких гарантий, ты стал утверждать, что статика тоже не даёт гарантий.
FR>Нет, я сказал что статика не дает 100% гарантии.

Угу.

D>>4) когда тебя попросили привести пример заявленных тобой проблем статики, ты привёл пример шаблонов C++.
FR>Который вполне релевантный.

Нет.

D>>5) два C++ника ответили, что шаблоны в C++ — это не статика.
FR>Нет, один из них такого не говорил, ну и плюс я сам C++ник, а ты можешь пока постоять в сторонке.

Что они говорили, см. выше. Я писал на C++ лет 5, хоть и давно. Наезды свои оставь при себе. (Очередной съезд на личности, похоже принцип "как аукнется, так и откликнется" до тебя не доходит.)

D>>6) ты скорректировал своё утверждение: "полный статический анализ возможен не для всех статически типизированных языков". В новой редакции оно эквивалентно следующему: "существуют статически-типизированные языки, в которых невозможен полный статический анализ". Что ни коим образом не доказывает порочность самой концепции, т.к. не отрицает существования языков, в которых этот самый полный статический анализ возможен. Согласен?

FR>А я нигде ни собирался доказывать порочность концепции.

Тогда что ты пытаешься доказать?

FR>Ты выдумал себе виртуального собеседника и с ним беседуешь, а мне приходится за него отвечать, цирк какой-то

Можешь не отвечать, тебя же никто не заставляет? Тем более, что ты уже слил по всем фронтам неоднократно.

Здравствуйте, WolfHound, Вы писали:

V>>Профессорство за знание языков, слава богу, не дают.
WH>Человек, преподающий программирование обязан знать множество языков.

Тебя и Влада послушать, так получится, что любое множество изученных языков без Nemerle является нерепрезентативным.

WH>И ответ "не хочу" на предложение прочитать статью, описывающую техники переднего края должен быть не мыслим.
WH>Но Дворкин мне именно это и заявил.
WH>Лаптев на предложение почитать про немерле сказал примерно тоже самое но другими словами.

Лаптев сказал, если я не путаю, что синтаксическим макросам сто лет в обед.

V>>Язык реализации — это последнее, что интересует. Вернее, не интересует никогда.
WH>Ну да... конечно.
WH>И после того как человек в это начинает верить получается всякая байда типа компиляторов на С.

Кто куда чем стоял?

V>>Для примера, Лисп тоже весьма проблемный язык, как и Пролог, и не зря есть куда как более "продвинутые" современные их аналоги, однако же их успешно преподают на курсе "языки обработки знаний", потому как если студент поймет как работает программа на Лиспе и Прологе, он поймет и принцип работы более современных поделок.
WH>Ага, конечно.

Угу, именно так.

WH>Вот тебе кусочек кода. https://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n
WH>Прикинь как он будет выглядеть на С++.

За такую лапшу нужно отлучать от клавиатуры. Вложенные match доставляют особо. Не, знаешь, такой ценой добиваться сокращения объёма кода — это себе дороже. Пусть код будет втрое длиннее, но хоть сгруппировали бы по ветвлениям одного уровня. Это был раз. А два, я, например, не вижу принципиальной разницы между:

| Not(Not(rule))                => optimize(Rule.And(r.Location, rule))

и совершенно банальным:

else if (match(rule, Not(Not())) { return optimize(And(r.Location, rule)); }

Совпадения имён случайные, ни один кролик во время прикидок не пострадал.

Так что, подозреваю, что в изображении подобного кода на C++ ничего чудовищного не будет.

Здравствуйте, VladD2, Вы писали:

VD>Да ты шутник, однако. Только форумом ошибся. Тебе нужно в юмор.

VD>2 WolfHound: Когда ты поймешь, что показывать примеры кода можно только тем, кто их понимает. Ты думешь, что что-то там обосновываешь, а человек тупо нихрена не понимает. Он в жини только if-ы освоил. И твои примеры для него — это еще один енпонятный набор крокозябр.

Влад, поменьше понтов. Сначала попробуй понять, что именно критикуется. Автор кода, я уверен, понял прекрасно. А вот ты нет.

На досуге помедитируй над вот этими двумя локальными ф-иями и попробуй найти у них связанность:

          def catFSM(_)
          {
            | (Rule.Fsm(fsm1) as r1) :: (Rule.Fsm(fsm2) as r2) :: rules =>
              catFSM(Rule.Fsm(r1.Location + r2.Location, FSMBuilder.Choice([fsm1, fsm2])) :: rules)
            | rule :: rules => rule :: catFSM(rules)
            | []            => []
          }
=====================================================
          def catFSM(_)
          {
            | (Rule.Fsm(fsm1) as r1) :: (Rule.Fsm(fsm2) as r2) :: rules =>
              catFSM(Rule.Fsm(r1.Location + r2.Location, FSMBuilder.Seq([fsm1, fsm2])) :: rules)
            | rule :: rules => rule :: catFSM(rules)
            | [] => []
          }

А после тщетных попыток попробуй нарыть хотя бы одну метрику оценки кач-ва кода, значение которой не будет для приведенных отрывков наихудшим.


VD>Я тебе сейчас переведу этот код. Вот как это будет выглядеть на доступных для тебя языках:

Да пофиг, основное замечание было в смешении процесса диспетчеризации и каких-то ф-ий "по месту", которые не связаны с диспетчеризацией.

VD>1. В привычных тебе языках оптимизация концевой рекурсии не гарантируется,

Хе. А если ему Лисп привычен?

VD>так что для корректной реализации тебе придется заменить вложенную функцию на цикла и стек (с ручной манипуляцией этим стеком).

А что, обрабатываемые правила могут иметь бесконечную вложенность? И вопрос на 1000000 баксов: в Немерле хвостовая рекурсия только в рамках одной ф-ии работает? Т.е. случай двух взаимно-вызываемых ф-ий не оптимизируется? Только это бы объяснило приведенный код в стиле дельфийского MegaButton_Click, т.е. оправдало бы автора... но это же приговор текущей реализации компилятора, требующей от программистов говнокодить.


VD>2. Компилятор немерла работает не с объектами, а свариантами. Это позволяет ему контролировать, что match-и обрабатывают все возможные сочетания. В твоем случае такая проверка невозможна в приципе.
VD>Так что описанная выше прямая трансляция является плохим стилем. Стало быть ее, по уму, нужно заменить на использование паттерна посетитель.

Ваш optmize не требует посетителя. Достаточно абстрактного метода и реализация в наследниках. Тоже забыть переопределить будет сложно. К тому же, можно будет обобщить, где близко (Choice/Sequence) и разнести нафиг несвязанный функционал всего остального.

VD>Но как только ты это сделашь распознование вложенных паттернов (Not вложенный в Not, как в данном примере) превратится в мучение. Кода станет уже не в 5, а в 10-20 раз больше.

В 10?

virtual Rule ^ Rule::And::optimize() {
  switch(arg->tag()) { 
    case TagNot: return gcnew Not(arg->optimize());
    case TagAnd: return gcnew And(arg)->optimize();
    default: return gcnew And(arg->optimize());
  };
}

Это вместо 3-х матчей в исходном примере. Разница ровно на "обвеску" (заголовок метода), но это ведь после декомпозиции.

VD>Так что насмехаешься и горлопанишь ты тут исключительно от своей невежественности. Ну, а приведенный тобой "код" просто нерабочий.

"Рабочесть" приведенного кода зависит от обвески, то бишь реализации окружения, как и в вашем примере. В плюсах, знаешь ли, бывают удивительные шаблонные перегрузки сигнатур, вполне можно и такой синтаксис сбацать.

VD>Так для справки. Обрезанный компилятор C# (из SS CLI) написанный на С++ Майрософтом занимает 5 мег. Компилятор Немерле ~2. И это при том, что язык сложнее в разы.


И это при том, что компилятор Немерле имеет зависимость от нескольких основных дотнетных либ по многу мег, а приведенный компилятор C# писан с 0-ля без внешних зависимостей. Сравнил так уж сравнил.

Здравствуйте, WolfHound, Вы писали:

V>>Это понятно, просто сия задача оптимизации сильно привязана к типу узла, и я многократно видел (и сам так же организовывал оптимизацию графов выражений) именно через ее реализацию в теле соответствующего объекта, представляющего узел. Бо задача как бы обязательная при построении графов выражений. Как минимум от лишних скобок (ваше And(And))) всегда избавляются.
WH>И что тут лишнего?

Лишние подстановки в традиционных грамматиках — это лишние вызовы ф-ии перебора, либо сдвига-свертки. Поэтому правила обычно оптимизируют, "раскрывают скобки". Всего вашего кода не видел, но эта оптимизация And(And(rule)) в приведенном файле очень похожа именно на нивелирование избыточной глубины графа выражений.

Или ты не понял смысла фразы о "лишних скобках"?

V>>Хотя, после пояснения относительно ограничений хвостовой рекурсии в N все вопросы отпадают. Беда, тут нечего обсуждать.
V>>Вот этим стоило заняться в первую очередь. Просто все остальное бросить и заняться этим. Ибо (посмотри чуть со стороны) влияние фичи конкретной реализации компилятора на стиль писания на языке (а компилятор и язык, по идее, не одно и то же, хоть и верно для ваших реалий), это жирный такой минус. Факт: приведенный код сразу же сказал о св-вах компилятора заглянувшему человеку со стороны. Показательно.
WH>Показательно что ты снова несешь бред на ровном месте.
WH>Я этот код писал не задумываясь о каких либо оптимизациях.

Ты решил показательно проигнорировать суть замечаний о декомпозиции и тестопригодности? Это поза такая? Под названием "идите все на х..."? Тебя никто не заставлял выставлять исходник на обсуждение, если что.

WH>И я не вижу ни одной причины написать его иначе.

Значит, ни тестов на него писаться ни поддерживаться другими людьми этот код не будет. Это мусор, называя вещи своими именами. То самое "первое приближение", результат эксперимента, и т.д., требующее рефакторинга перед завершением работы над этим участком. Хотя, вот тут уже спотыкаемся об ограничения на раскрутку хвостовой рекурсии. И если это требование принципиально, то декомпозировать можно будет не все.

V>>Смотреть надо. Посетитель тоже тормоз порядочный, хоть и быстрее обычно на порядок, чем развесистый ПМ.
WH>Лол.
WH>Учитывая что ПМ очень даже может тупо по таблицам работать...

В реализации Немерле? Сколько я смотрел рефлектором, пока не замечал. Не покажешь, если я плохо смотрел? Например, вот скомпилированный обсуждаемый кусок. Ну и табличный вариант как раз с виртуальным вызовом сравняется.

Здравствуйте, VladD2, Вы писали:

VD>Выдумки я твои пропустил. Обсуждать их не вижу никакгого смысла.

Ну нет, так нет.

ГВ>>Угу, спасибо за объяснение. Почему-то ничего нового для меня тут не прозвучало. Да, я действительно не придал значения локально связанным именам, но, в общем, на мой вывод (и на иллюстрацию) это никак не влияет.
VD>Ну, есссено! Только код что тебе привели компилируется и работает. И более того, работает очень шустро. А твой — это выдумка которая никогда не заработает. Вот и вся разница. Так что в деталях как всегда кроется черт.

Конечно, не заработает. На фига мне PEG-парсер? Хотя, если вдруг понадобится...

ГВ>>Кого обманываю и в чём?
VD>Приведением кода который по твоим словам аналогичен, а на практике является полной фигней.

ГВ>>Ясно, спасибо. Собственно, этого я и ждал (хотя надеялся на чудо) — да, контролируется полнота проверки по всем возможным вариациям данного АлгТД, но никак не его сочетаний.

VD>Ну, почему же? Убери вхождения:
VD>

VD>        | Not(rule)                     => Rule.Not(r.Location, optimize(rule))
VD>        | And(rule)                     => Rule.And(r.Location, optimize(rule))
VD>

VD>и компилятор проверит те что есть и выдаст предупреждения для каждого не покрытого случая. Если ты хотя бы одино из вхождений не укажешь будет сообщение. А укажешь все — не будет.

М-м-м... Разве такое поведение компилятора будет вызвано не тем, что в типе Rule прямо объявлено:

    | Not            { rule : Rule; }
    | And            { rule : Rule; }

?

ГВ>>Пожалуй, что мне теперь стоит зацепиться за твою фразу: "...что match-и обрабатывают все возможные сочетания" и поднять шум о том, какой ты бессовестный обманщик и как вводишь в заблуждение своих наивных слушателей.
VD>Ну, попробуй. Авось в процессе еще немного в тему въедешь .

Не буду пробовать, у меня не получится так экспрессивно, как у тебя.

ГВ>>Короче говоря, порядок перебора совпадений — "сверху-вниз" в порядке перечисления. В принципе, схоже с пролог-машиной, только там учитывается порядок занесения предикатов в базу данных. Правила перебора совпадают с точностью до деталей реализации вычислительной среды.

VD>Ну, в прологе механизм по круче. Там тот же ПМ, но на базе унификации. В конце сопоставления обе стороны унифицируются.

Угу, покруче в каком-то смысле. Понятно теперь, почему ПМ для меня не новость? И ни для кого не новость, кто знаком с Прологом.

VD>МП из ФЯ по слабее, но за то сильно шустрее. В результате получается очень эффективный код. Такой же если бы это дело писалось вручную на базе низкоуровневых средств.

VD>Но в общем, механизм действительно похожий на прологовский. Разница только в том, что он работает только в одну сторону.

Ну да, правильно, потому что предназначен для других вещей — не только для поиска набора унификаций.

VD>>>>>Так что описанная выше прямая трансляция является плохим стилем. Стало быть ее, по уму, нужно заменить на использование паттерна посетитель. Но как только ты это сделашь распознование вложенных паттернов (Not вложенный в Not, как в данном примере) превратится в мучение. Кода станет уже не в 5, а в 10-20 раз больше.
ГВ>>>>Влад, ты когда с самим собой разговариваешь, клавиатуру в сторону отодвигай. При чём тут паттерн "посетитель"?
VD>>>При том, что он описывает список веток которые нужно посещать и как и ПМ гарантирует, что ты не забудешь посетить их все.

ГВ>>Ценой распыления аналитического кода по всем классам?
VD>У меня закрадываются сомнения в том, что ты знаешь что такое паттерн посетитель.

Объясни, что ты имеешь в виду в данном контексте?

ГВ>>Ну, я не спорю, субъект с тяжёлым синдромом ООП головного мозга способен и на такое ради "гарантий". Только зачем болезнь выдавать за правило?
VD>Ты видимо очень крут. Но вот все компиляторы и системы обработки деревьев выражений (включая LINQ) создаваемые на ООЯ почему-то всегда реализуют Посетителя для своих структур. Видимо ООП головного мозга поразил всех окружающих. И меня в том числе. В R# я тоже его реализовывал. Правда средствами метапрограммирования, так что это не было так уж многословно.

Всё зависит от контекста. Если набор типов изначально не ограничен, как, например, ограничен набор вариаций для Rule, то "посетитель" может оказаться уместным. Но мы, вроде как, обсуждаем другой случай — Rule имеет строго определённый набор вариаций.

VD>>>Посетитель наилучший способ из имеющихся в арсенале ООП. Код обработки выделяется в одном месте. Есть возможность гарантировать, что посещены все ветки. Можно добавлять другие обработки не ломая уже существующие и не вводя тонны методов (по одному на каждую ветку).
ГВ>>Хм. Зачем ты так рьяно защищаешь такое убогое применение ООП?
VD>Я? Я его не защищаю. Но в арсенале ООП и ИП дугих средств нет. Точнее те что есть еще хуже. Уж лучше проиграть в обхеде кода посетителя, но потом не иметь тех проблем что можно огрести без него.

Какие это проблемы можно без него огрести, например, в коде транслятора? Забыть, что ли, switch/if вставить там, где он нужен? Так это, прости меня, детский сад, право слово. Корректность компилятора контролируется наборами тестов, а не языком реализации. Да и, собственно, ветку в ПМ тоже можно запросто "заглушить".

ГВ>>Ну, я как бы в курсе твоего любимого метода критики — взять нечто идиотское, реализованое на языке X и на этом основании заклеймить весь язык X, но это не совсем чистоплотно, не находишь?
VD>Если ты считаешь этот паттерн идиотским, то или ты его не понимаешь, или ты освоил ПМ и понимаешь, что Посетитель жалкое его подобие (частный случай).

Ну, в данном контексте другого применения Посетителю, кроме идиотского я придумать не могу. Поясню:

class Rule {
  virtual Rule *optimize() = 0;
};

class AndRule : public Rule {
  virtual Rule *optimize() {
    // "Самооптимизация" And либо что-то в этом духе:
    return host->optimizeAnd(this);
  }
};

Вполне возможно, что ты видишь другие варианты.

VD>>>Если тебе это не очевидно, я не виноват.
ГВ>>Ты понимаешь, в чём проблема, я переболел парадигмами и прочими идеологиями уже довольно давно.
VD>Да я заметил. Жаль что это случилось чуть раньше чем ты освоил их все.

Я? Да ну что ты, я ни одной так и не освоил, мне наука освоения парадигм программирования как неких цельных артефактов не под силу by design — не умею я бессмысленные вещи осваивать.

ГВ>> Поэтому то, о чём ты говоришь, мне очевидно, но очевидно ещё и то, что сейчас я (и не только я) без веских причин так не сделаю, чтобы там ни тарахтели разнообразные ООП-пуристы и прочие, сдвинутые на спасении мира посредством чистоты парадигмы.
VD>Я тебе назвал минимум три причины. Тебя не волнует дальнейшая поддержка кода? Тогда можно их игнорировать.

Э-э-э... А где они перечислены? Не ткнёшь пальцем?

ГВ>>Честно, мне плевать, как код реализации проецируется на некий идеал, взятый из той или иной химеры (aka парадигмы), я руководствуюсь вполне локальными соображениями.
VD>Да мне тоже. Лишь бы он был рабочим, простым и легким в поддержке.

Ну вот видишь, к чему тогда паттерн Посетитель там, где цепочка if-ов покрывает потребности без выкрутасов?

VD>Но у этой задачи есть только три решения. Посетитель, ПМ и неправильное. Последнее на первый взгляд выглядит разумно и даже порой красиво, но на самом деле это мина замедленного действия. Отложенные грабли.

Не, не так. У задачи подбора по структурному паттерну есть много решений, все они так или иначе связаны с перебором. ПМ, Посетитель, if/switch — это возможные реализации, только у ПМ реализация самого перебора неявная. Ну а оптимизация перебора может выполняться как вручную (скажем, подходящей декомпозицией), так и реализовываться компилятором (например, хэш где-нибудь вычислять). Впрочем, хэш можно и явно вычислять.

ГВ>>Я не спорю с тем, что ПМ полезен, но это далеко не то, ради чего стоит пускаться во все тяжкие (читай, непременно менять язык реализации и т.п.).
VD>Ну, это мнение того кто сам на практике это самое МП не использовал. Я так понимаю Пролог ты ведь тоже на практике не используешь?

Мимо. Не часто, но использую.

VD>А вот среди тех кто попользовался ПМ бытует другое мнение — что языки не поддерживающие ПМ сразу проигрывают тем что поддерживают. У многих просто ломка начинается когда они вынуждены возвращаться на язык без ПМ.

Меня их мнение не волнует, как и ломка. Забегая вперёд, я понимаю о чём идёт речь, когда люди говорят о "ломке" при переходе от одного языка к другому, и сам её испытывал некогда, но не считаю эту причину, в общем, сколь-нибудь существенной. Куда как сильнее "ломка" от осознания бессмысленности замены одного средства разработки на другое, когда, например, ясности с постановкой задачи как не было, так и нет. Или, скажем, когда решение задачи упирается в её теоретическую неразрешимость. А тасование языков программирования ради "комфорта" — это как в той басне про квартет: "А вы, друзья, как ни садитесь..."

VD>А дело здесь в том, что ты не думаешь категориями АлгТД и ПМ. А те кто думает очень многие задачи видят именно в их применении. Как результат разрыв между возможностями языка и внутренним представлением решения. Далее начинаются эмуляции ПМ в рантайме (на функция) и т.п. На следующей стадии эта эмуляция выбрасывается, так как становится явсно, что без поддержки языка получается плохо.

Влад, я думаю вовсе не в категориях языка программирования и вообще затрудняюсь вербализовать сам процесс — в каких категориях осуществляется мышление. Так что, ты свой "мозгоскоп" лучше отключи, а то батарейки только сажаешь.

ГВ>>Разницу между иллюстрацией и фрагментом рабочего кода объяснять нужно?
VD>Не надо. Но твой код не рабочий потому что бессмысленный, в не потому что он не полон.

Я это в цитатник занесу: "код не рабочий потому что бессмысленный, а не потому что он не полон". Махатма Ганди нервно протирает очки.

Здравствуйте, VladD2, Вы писали:

VD>>>и компилятор проверит те что есть и выдаст предупреждения для каждого не покрытого случая. Если ты хотя бы одино из вхождений не укажешь будет сообщение. А укажешь все — не будет.

ГВ>>М-м-м... Разве такое поведение компилятора будет вызвано не тем, что в типе Rule прямо объявлено:

ГВ>>

ГВ>>    | Not            { rule : Rule; }
ГВ>>    | And            { rule : Rule; }
ГВ>>

ГВ>>?

VD>Именно. Но не только этих двух вхождений, а всех. Там очень хитрая штука делается. Строится так называемое дерево решения. А потом анализируется.

[...]

Лучше перескажи, а не отсылай меня к комментариям в коде компилятора.

Несколько вопросов:

1. Что является входными данными для Decision tree?
2. Что имеется в виду под 'given branch' и 'given pattern':

If given branch is not found in the output tree, then given pattern
never matches and is thus redundant.

?
3. Что такое и откуда берутся failure nodes в Decision tree?

Чую, что ответы достаточно простые, но пока это только чутьё "спинным мозгом".

ГВ>>Угу, покруче в каком-то смысле. Понятно теперь, почему ПМ для меня не новость? И ни для кого не новость, кто знаком с Прологом.
VD>К сожалению, эти "все" (включая тебя) Пролог изучали так же. Побаловались и бросили. В прочем, я от вас не далеко ушел. Вот только разве что не гоню напраслину.

Ну, насчёт побаловались и бросили — это оставляю на твоей совести. А напраслину ты прекрасно гонишь в адрес C++ и тех, кто на нём программирует — у тебя это получается даже лучше, чем у других в адрес N.

VD>Раз ты знаком с прологом, то должен понимать, что похожие механизмы но обеспечивающие высокую скорость кода очень даже крутая штука. И по уму ты должен жалеть, что в "твоих" языках такого нет. Но тебя радует то что ты "это видел".

Понимаю, отчасти сожалею. Отчасти, потому что для меня главной проблемой всегда было не "как" перебрать структуры, а "что" именно перебирать. Догадываешься, в чём разница?

ГВ>>Ну да, правильно, потому что предназначен для других вещей — не только для поиска набора унификаций.
VD>Не для других, а для одной из целей — нахождения соответствия. А вот унификацию он как раз таки не обеспечивает.

Нахождения первого соответствия, заметь. В остальном согласен (замнём терминологические тонкости для ясности).

VD>>>У меня закрадываются сомнения в том, что ты знаешь что такое паттерн посетитель.
ГВ>>Объясни, что ты имеешь в виду в данном контексте?
VD>То что сказал. Похоже ты просто не понимаешь зачем этот паттерн был придуман.

Ну-ка, ну-ка, я весь внимание.

ГВ>>Всё зависит от контекста. Если набор типов изначально не ограничен, как, например, ограничен набор вариаций для Rule, то "посетитель" может оказаться уместным. Но мы, вроде как, обсуждаем другой случай — Rule имеет строго определённый набор вариаций.

VD>Вот еще одно подтверждение. Посетителя ты не понимаешь. Как раз Посетитель уместен только когда набор типов необходимых посетить ограничен и редко расширяется.

Да ты что? То есть разносить реализации управления посещением по классам нужно только тогда, когда этот набор редко расширяется? А я-то всегда считал, что Посетитель нужен для того, чтобы предоставить "посещаемым" возможность самостоятельно выбрать метод(ы) их обработки. То есть набор доступных методов у "посетителя" как правило должен отличаться от набора "посещаемых" классов. Иначе на хрена оно вообще нужно-то при фиксированном наборе классов? Так просто, из принципа?

Короче, кроме шуток. Влад, тебя, похоже, намертво заклинило на иллюстративной реализации

Автор(ы): Андрей Корявченко
Дата: 06.12.2006
Очень часто в программах встречаются сложные структуры, представляющие собой дерево или граф, состоящий из разнотипных узлов. И, конечно же, при этом имеется необходимость обрабатывать этот граф. Самое очевидное решение — добавить в базовый класс виртуальный метод, который перекрыть в наследниках для выполнения нужного действия и осуществления дальнейшей навигации по дереву.
Однако у этого приема есть серьезный недостаток: в нем структура данных оказывается увязанной с обрабатывающими ее алгоритмами. Если нам понадобится алгоритм, отличный от реализованного, то придется добавлять еще один виртуальный метод. Еще хуже, если классы, составляющие дерево, содержатся в недоступном для модификации коде.
Одним из вариантов решения проблемы высокой связности в данном случае является паттерн Посетитель.

Посетителя:

public interface IVisitor
{
  void VisitRoot(RootNode node);
  void VisitType1(Type1Node node);
  void VisitType2(Type2Node node);
  void VisitType3(Type3Node node);
}

На самом деле, общий случай тут совсем не такой, а вот такой:

public Interface IVisitor
{
  void VisitRoot(RootNode node);
  void Action1ForNode1(Type1Node node);
  void Action2ForNode1(Type1Node node);
  void Action3ForNode(RootNode node);
  // ...
}

То есть набор операций IVisitor вовсе не обязан соответствовать набору имеющихся "внешних" классов. А иначе реализация этого паттерна являет собой просто паттерн ради паттерна с вырожденной реализацией посещаемых классов типа такой:

class A {
virtual void visit(IVisitor *visitor)
{
  visitor->visitTypeAnode(this);
}
};

Хотя это по сути двойная диспетчеризация, но, тем менее, она служит хорошим примером к тезису о вреде работоспособных иллюстраций — людей клинит на иллюстративном материале, как на истине в последней инстанции. Весьма показательны в этом смысле истории с примерами из книг Буча — их тоже, почему-то иной раз пытаются прямо перенести в рабочий код.

ГВ>>Какие это проблемы можно без него огрести, например, в коде транслятора?
VD>Все те же. При очередном рефакторинге забыть обработать некоторые из типов (ветвей дерева).

Ясен перец, копаться в десятке реализаций удобнее, чем в одном case, кто бы спорил... Влад, не гони, а?

ГВ>>Забыть, что ли, switch/if вставить там, где он нужен?
VD>Ага. Они то и приводят к проблемам.

Ага, я даже представляю, что ты вспомнишь следующим. LSP, да?

ГВ>>Так это, прости меня, детский сад, право слово.
VD>Детский сад — это не знать детали паттерна и лезть спорить о нем.

Какие ещё детали паттерна? О чём ты?

ГВ>> Корректность компилятора контролируется наборами тестов, а не языком реализации. Да и, собственно, ветку в ПМ тоже можно запросто "заглушить".
VD>Ага! Разговоры о тестах это такая лакмусовая бумажка.

VD>Ты понимаешь разницу между значением слов "гарантия" и "протестировано"?
VD>Если есть возможность получить гарантию глупо делать тесты.

Если хоть один компилятор сможет мне дать гарантию, что никто из разработчиков не напишет вот такой:

| Not(Not(rule))                => r // Пока не знаю, что тут делать

или такой код:

virtual Rule *optimize(RuleOptimizer *)
{
  return this; // TODO: Разобраться, что тут писать
}

...то я готов принести тебе свои извинения. А если нет, то уж прости, но это можно проверить только тестами. Вне зависимости от того, считаешь ты их лакмусовой бумажкой или нет. Да, я вовсе не думаю, что напишут это по злому умыслу — причин для появления заглушек может быть миллион.

ГВ>>Я это в цитатник занесу: "код не рабочий потому что бессмысленный, а не потому что он не полон". Махатма Ганди нервно протирает очки.
VD>Занеси. Только не показывай никому. А то стыдно будет.

Кому? Тебе? Не бойся, я никому не скажу!

Здравствуйте, WolfHound, Вы писали:

V>>И нафига там, все-таки, прикидка по весам, хоть убей не пойму? Это типа такой эвристики, наподобие алгоритма инлайнера компилятора gcc? Чья идея? Это же не из той области. В стандартном шаге упрощения систем правил производят ПОЛНУЮ подстановку (!!!), т.е. до тех пор, пока не натыкаемся на рекурсию. Заметь, пофиг веса абсолютно.
WH>Ну так и знал.
WH>Теоретик.

Отчего же, не только теоретик.

WH>После некоторого размера инлайн ничего не дает.
WH>Но размер генерируемого кода раздувает очень сильно.

Это смотря как делать. Бо еще делают так, что ровно наоборот: размер генерируемого кода зависит только от общего кол-ва нетерминалов, и чем оно меньше, тем меньше кода. Т.е. избавление от промежуточных нетерминалов, не являющимися целевыми, идет на пользу. Тело правил — табличное. И оно по быстродействию ручному switch/case вовсе не уступает, а местами ровно наоборот, бо вызовов и косвенности меньше при полном раскрытии.

Ну а ты как обычно пускаешь понты и пузыри. Первый парсер в твоей истории, что ли? Эдак тебя прет.

WH>Короче обсуждать с тобой парсер я более не намерен.
WH>Толку нет.
WH>Ибо ты ничего не угадал. Совсем.

Я и не обязан был подробности угадать, но спросить мог. А тот факт, что ты свои подробности считаешь единственно возможным вариантом реализации, говорит само за себя.

Ты прямо вопрос задай, чего ты вокруг да около.

"Чуваки, че вы наш немерле не хотите поюзать ?"

Да потому что вы сами, носители вашего немерле, ниче поразительного на нем не сделали. Удиви нас, сделай что то чтобы я сказал вау, какую хрень можно однако сотварить на етом Н.

Ни вы со своим немерле, ни микросовт со своим ф# не могут донести чего ж там у вас такова..

А тем временем шарп уже дорос почти до статуса ФЯП, так что ребята сори, но вы зря тратите время.
ну если тока грантик какой нить пилите, тоды понятно.

Здравствуйте, VladD2, Вы писали:

D>>А про языки вообще, самый главный аргумент — время. Всё изучить — жизни не хватит. Вот я долго прицеливался, и взялся за скалу. Потому что жопа моя чует, что это будущее, и надо долбить задел, пока мозги работают. А тратить время на всякие питоны и прочее — нет у меня его столько, времени этого. Старею уже.

VD>Вот, вот. Это как раз и интересно. Не мог бы ты описать свои мысли и действия по подробнее? Что останавливает? Что произошло при начале изучения? На каком сейчас этапе? Не хочется ли бросить изучение? ...

Я изучаю язык только с одной целью: начать на нём писать. Полноценно: много и сложно. Варианты "поглядеть 20-страничную презентацию по языку" и "поковыряться с недельку" — это чистейшая профанация. Ну то есть, для тебя возможно и нет, если ты уже стотыщ разных языков знаешь (имеешь реальный опыт программирования) и поэтому быстро понимаешь, какие идеи языка откуда спёрты, ну и в итоге быстро и адекватно оцениваешь язык в целом. Я же не знаю "нормальных" динамически-типизированных языков, и языков с МП тоже не знаю. А изучать их только ради того, чтобы потом быстрее изучать ещё более другие языки — мне чё, больше заняться нечем? Языков, на которых действительно стоит писать, не так много, чтобы специально прокачивать скилл "поиск нормального языка". Тупо между делом поглядывая на форумы, я в фоновом режиме, в порядке отдыха получаю вполне достаточно информации. Гораздо больше, чем мог бы получить, поковырявшись неделю-другую в самом языке: в спорах в "Философии" и "Архитектуре" обсуждают вещи, которые на мелких задачах увидеть невозможно.

Здравствуйте, dimgel, Вы писали:

D>А generics с вариантностью и upper/lower bounds в окалме есть?

Сложный вопрос, без шуток.

Проблема в том что в OCaml объекты и интерфейсы структурно типизированы, а понятие класс практически синтаксический сахар для удобства
наследования реализации.

Вторая проблема в OCaml нет выделенного понятия generic, но есть несколько своих механизмов их заменяющих.

Во первых параметизированые классы http://caml.inria.fr/pub/docs/manual-ocaml/manual005.html#toc27 это как раз очень близко
по свойствам к генерикам или шаблонам классам C++, но там засада в том что в терминах C++ это скорее ближе не к шаблоному классу,
а к классу с шаблонным конструктором.

Во вторых у объектов методы могут быть параметризованными http://caml.inria.fr/pub/docs/manual-ocaml/manual005.html#toc28, что в совокупности
с предыдущим позволяет изобразить что-то похожее на генерики.

В третьих обычные методы и функции у которых параметры объекты из-за структурной типизации ведут себя как генерики, например функция

let f o = o#put

будет обобщенной принимающей любой объект с методом put и соответствующей сигнатурой, что в большинстве случаев делает бессмысленными
использование генериков.

В четвертых кроме этого есть параметизированные модули (модули в ML не связанны с единицами компиляции) http://caml.inria.fr/pub/docs/manual-ocaml/manual004.html#toc16 на них тоже можно изобразить что-то похожее на генерики.

D>Пример lower bound на скале:

D>

D>trait Animal {
D>    def feed(...)
D>}
D>class Elephant extends Animal {
D>    def feed(...) {
D>        // ...
D>    }
D>}
D>class ZooCage[A <: Animal] (a: A) {
D>    // ....
D>    a.feed(...)
D>}
D>new ZooCage(new Elephant)
D>

D>Здесь запись [A <: Animal] означает "generic-тип A, являющийся подтипом Animal". Благодаря этому внутри generic-класса ZooCage компилятор имеет информацию о супертипе A и в состоянии проверить корректность вызова метода a.feed(). А при инстанциировании ZooCage с конкретным аргументом выполняется проверка, что A=Elephant удовлетворяет условию A <: Animal. Полный контроль, в отличие от шаблонов C++.

В OCaml иерархия выше малоосмыслена из-за структурной типизации. При структурной типизации классы не различаются по именам, если будет два класса у которых имена разные, но все публичные сигнатуры функций совпадают будут считаться компилятором одним и тем же классом. Хотя тут вру классы вообще не
учитываются, в внимание принимаются только сигнатуры методов. Ну и подтип определяется не наследованием а только структурным совпадением.
Поэтому твой пример повторить не получится, языки слишком разные.

Вот примерно попытался показать особенности, но это так чтобы только продемонстрировать разницу.

open Printf


class elephant = 
  object
    method say = printf "elephant\n"
  end

(* с точки зрения компилятора этот класс совпадает с elephant *)
class mamont = 
  object
    method say = printf "mamont\n"
  end


class dog = 
  object    
    method say = printf "dog\n"
    method dog_id = ()
  end

class wolf = 
  object
    method say = printf "wolf\n"
    method wolf_id = ()
  end

(* этот класс совсем левый, метода say нет *)
class troll = 
  object
    method hollow = printf "bla-bla\n"    
  end


(* инициализируем объекты *)
let elephant_ = new elephant
let mamont_ = new mamont
let dog_ = new dog
let wolf_ = new wolf

let troll_ = new troll

(* максимально обобщенная функция *)
let say o = o#say

let _ = say elephant_
let _ = say mamont_
let _ = say dog_
let _ = say wolf_

(* тут если раскомметировать будет ошибка компиляции у класса нет метода say *)
(*let _ = say troll_*)


(* 
  переопределяем, теперь принимаются только типы полностью структурно совпадающие
  с elephant, то есть elephant_ и mamont_ то что закомментированно ошибка 
  компиляции.
*)
let say (o : elephant) = o#say

let _ = say elephant_
let _ = say mamont_
(* let _ = say dog_ *)
(* let _ = say wolf_ *)
(*let _ = say troll_*)


(* 
  переопределяем, теперь принимаются только типы полностью структурно 
  совпадающие с dog.
*)
let say (o : dog) = o#say

(*let _ = say elephant_*)
(*let _ = say mamont_*)
let _ = say dog_
(* let _ = say wolf_ *)
(*let _ = say troll_*)

Контроль здесь тоже полный с учетом структурности конечно, в отличии от C++ тип класса хоть и максимально обобщенно, но _выводится_
учитывая используемые в теле функции методы класса, C++ же поступает наоборот подставляет тип в шаблон.

FR>>Я ничего, пытаюсь отбиться от тролля, чистая самозащита.

D>Лучший способ избавиться от тролля — это перевести разговор в конструктивное русло, давать грамотные аргументы. Поскольку ты себя этим не отягощаешь, троллем выступаешь именно ты. Но я очень надеюсь, что аргументы рано или поздно наконец появятся. Итак?

Ладно чушь про С++ замнем. Динамику тоже, мне про нее спорить давно обрыдло, так по инерции в очередной срач влетаю.
В общем предлагаю перестать нападать друг на друга

Здравствуйте, Ziaw, Вы писали:

Z>Аналогия не верна. ПМ используется во всех проектах и используется очень широко. Логический решатель — узкая ниша.

Я же смайл поставил.

А если по делу, мне крайне не нравится реализация алгебраических типов в Немерле. Она там одинакова для рекурсивных и нерекурсивных АглТД, т.е. явно была сделано "на скорую руку". Но нынешняя команда сим вопросом заниматься не будет.

Здравствуйте, Vasilich3333, Вы писали:

VD>>Необходимость появится точас же как ты поймешь концепции заложенные в эти языки и научишься применять их на практике.

V>Спорный аргумент о необходимости! Я уверен многие обладают знаниями,которые так и не были востребованы

Бесспорно одно, из невостребованности одних знаний не вытекает ненужности других. Не делай таких логических ошибок в будущем.

В общем, кури Парадокс Блаба, если не понял о чем я говорю.

Здравствуйте, FR, Вы писали:

FR>Я PHP и JavaScript практически не знаю, но судя по тем же флеймам они гораздо более подвержены ошибкам чем питон и руби ввиду очень слабой типизации.

Является ли сильная типизация по сравнению со слабой преимуществом при автоматическом рефакторинге, если оба языка динамически типизированные? Я склонен считать, что нет, т.к. ошибка типов в любом случае вылетит в рантайме, IDE никакой помощи тут не предоставит. Если так, то это ключевая претензия, и она ни на йоту не гипертрофированная: её значение переоценить невозможно. Как по мне, невозможность быстро и надёжно (без необходимости писать тонну юнит тестов) рефакторить код — это приговор языку. На любом хоть сколько-нибудь крупном проекте рефакторинг будет выливаться в такой геморрой, что проще повеситься. "Отвинтили пупок — отвалилась задница." Всё остальное я перетерплю, но когда рефакторинг кода похож на хождение по минному полю, когда на каждый чих типа переименования метода приходится вручную шерстить весь проект глобальным поиском, потом смотреть, что из найденного относится к нашему классу, а что не относится (а в отсутствие информации о типах приходится анализировать логику, иногда глубоко), а потом молиться, чтобы где-нибудь не упала завязанная на рефлексии динамика, конструирующая имя вызываемого метода так, что он не нашёлся поиском... это ад, в общем. Огромное количество временных затрат на ровном месте. Вот реальная проблема. А что в рантайме я не смогу присвоить числовой переменной строку — мне глубоко пофиг, я уже привык assert-ами по коду разбрасываться, они неплохо компенсируют слабую типизацию.

Здравствуйте, VladD2, Вы писали:

Изучают языки, как мне кажется, в нескольких случаях. Когда люди увлекаются языками программирования, и постоянно изучают новые и малоизвестные академические языки программирования для расширения кругозора, решают на них всякие головоломки, пытаются "сломать" компилятор и тд. Потом, например, человек, не увлекающийся языками, может изучать новый, когда необходимо сменить область деятельности на некоторую другую, в которой принято использовать другие языки.

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

ИМХО ни одна из этих причин не играет роли.
Зачастую синтаксические различия не играют роль, но так исторически сложилось, что языки с си подобным синтаксисом были в целом удобнее остальных, по некоторым другим причинам.

Идеологические причины имхо тоже не должны играть определяющую роль, потому что все эти языковые парадигмы не равнозначны, как например цвет рабочего стола или атомобиля. Где то удобнее применять одно, где то другое. Поэтому я считаю, современный язык должен быть мультипарадигменным.

Ну и политические предпосылки тоже не катят. Что значит применить на работе? Начальство не одобрит? Тогда ставится вопрос, а почему уже оно не хочет перейти на новый язык.

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Такая ситуация бывает у тех кто изучает языки ради развлечения. И бывает это довольно часто, ну почти всегда если изучается язык, ещё не ставший популярным.

Я думаю, основная проблема, из-за которой недавно созданный язык не становится популярным и почти не ипользуяется на практике, заключатся в том, что он не решает задачи ЗНАЧИТЕЛЬНО лучше чем существующие средства. То есть недостаточно просто сделать язык немного лучше. Никто из-за этого не бросит свои старые проекты и не будет переходить на него.

Про язык Немерле я могу сказать следующее. Я читал все статьи, написаные про него, часто читаю переписку на этом форуме, устанавливал компилятор, ковырялся в языке, но до практического применения так и не доходило. А всё потому что я, например, не знаю таких задач (мне они не встречались), которые с одной стороны наилучшим образом решались бы на .NET, а с другой стороны требовали чего то навороченного от языка.
То есть все эти фитчи с изменением синтаксиса просто негде использовать среднестатистическому программисту на .NET.

Вот если бы язык Немерле компилировался в нативный код, тогда было бы другое дело...

Недавно Влад писал о фреймворке для создания языков программирования. Несмотря на то, что я крайне одобряю идеи метапрограммирования, мне кажется возможность такого обширного изменения синтаксиса попросту бесполезной. Этим почти никто не воспользуется.
На самом деле менять синтаксис требуется очень редко. Большинству програмимистов это не требуется никогда. И уж тем более писать свой язык. Свой язык пишут тогда, когда необходимо компилировать код под какое то свое устройство, для которого нет ещё нормальных языком. Но НИКТО не будет писать свой язык, под существующую богатую языками платформу в рамках выполнения работы. Ради развлечения — конечно.
Изменять синтаксис можно и в языке C++, при этом мало кто этим занимается. В основном люди и шаблоны то не используют.
Вполне достаточно иметь возможность менять синтаксис в таких же пределах, как это сделано в С++. Ну если честно, то чуть больше.
Следовательно, раз такая функциональность не востребована, не стоит её делать основной фитчей языка.

И вообще, вся идея с .NET о том, что будет одна среда выполнения и куча разных языков довольно глупая. По факту большинство языков обладает одинаковой выразительностью и отличается только особенностями синтаксиса.

Если бы Немерле компилировался в нативный код (не только, например под llvm ещё), то это открыло бы большой простор для реализации различных макросов, которые не только добавляют синтаксический сахар, как текущие макросы, но и позволяют удобно трансформировать код и управлять процессом кодогенерации. Таким образом, во первых, можно было бы использовать Немерле как универсальный язык для современных компьютеров, то есть можно было бы программировать всю аппаратную часть на нем. То есть не так, что для видеокарты один язык, для основного процессора другой. А во вторых, появилась бы возможность автоматизировать использование современных инструкций процессора, а не писать на ассемблере или использовать интринсики.
Это повысило бы выразительность Немерле ещё на один уровень.

Я знаю, что в Немерле некоторые такие вещи можно делать, например Nemerle CL и CUDA, но всё таки, как я понял, не самым удобным образом. И это совсем не пропагандируется как одна из основных фитч Немерле. Также можно было бы использовать Немерле для вычислений на кластерах.

То есть на мой взгляд, лучше при разработке Немерле 2 сконцентрировать силы на добавлении возможности генерировать код под разные платформы.

А то получается, что немерле повторяет в основном просто фитчи сишарпа, только на макросах. Ну да, есть PEG, которого нет в сишарп, но он нужен опять же только для тех кто пишет компиляторы. Для большинства программистов тут нет значительных преимущества перед сишарпом, чтобы переходить на Немерле.

Если бы Немерле компилировался в нативный код, появилась бы возможность ручного управления памятью, а сборщик мусора можно было бы реализовать на макросах. Тогда программист мог бы сам выбирать алгоритм сборки мусора, используя тот или иной набор макросов, тем самым повышая производительность программы для разных сценариев раборы с памятью.

PS Я понимаю, что перевести Немерле на генерацию нативного кода довольно сложная задача, но на платформе .NET у Немерле вряд ли есть будущее. Можно конечно отработать некоторые идеи в текущей реализации, а потом уже с готовыми решениями браться за переписывание. Я повторюсь, на платформе .NET Немерле вряд ли когда нибудь будет обладать значительными преимуществами по сравнению с сишарпом для среднестатистического программиста. По сравнению с эфшарпом, Немерле конечно выглядит более привлекательным, но и эфшарп вряд ли станет популярным языком.

Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
Для затравки дам некоторые возможные ответы:
1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
3. Политические предпосылки — "Все равно не смогу применять его на работе...".
...

Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

А про языки вообще, самый главный аргумент — время. Всё изучить — жизни не хватит. Вот я долго прицеливался, и взялся за скалу. Потому что жопа моя чует, что это будущее, и надо долбить задел, пока мозги работают. А тратить время на всякие питоны и прочее — нет у меня его столько, времени этого. Старею уже.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, alpha21264, Вы писали:

A>>Нафиг надо, если С++ уже есть?

VD>На фиг нужен был С++ когда был С или даже Фортран?

A>>Зачем изучать "те же яйца в профиль", если они не дают новых возможностей?

VD>Не, ну правда! С++ это же те же яйца только в профиль. На фиг ты его учил? Время тратил?

Эээ... Ну перечитай же еще раз "если они не дают новых возможностей".
То есть, если новые возможности будут, то я изучать буду.

A>>Я лучше что-нибудь другое поизучаю ступенькой повыше. Паттерны например. Или что-нибудь связанное с архитектурой.

VD>А если тебе скажут, что есть язык который повзоляет эти паттерны превратить в готовую к использованию библиотеку или фичу языка, тебя это не заинтересует?

Заинтересует. Только ты пойми правильно. Паттерны хороший программист придумывает достаточно часто.
Конечно не так часто как функции и алгоритмы, но мир паттернов не исчерпывается теми двадцатью, которые написаны в книжке.
Ну и ты сам сказал, что мне более нужно: дайте мне это в виде библиотеки, а язык оставьте старый.
Чтобы я получил новые возможности, а все старые остались при мне.

VD>Зачем учить паттерны, когда можно просто воспользоваться готовым решением?

VD>Когда-то давно было много программистов писавших GUI на С. GUI отилично ложится на ООП. Но ООП в С не было. Тогда С-программисты придумали паттерны: класс, сообщение, событие и т.п. и начали писать код с их использованием. Многие и сейчас так делают. Но ты видимо к ним не относишься, так как знаешь, что есть язык — С++ в котором эти паттерны встроены. И знаешь, что писать на таком языке объектно-ориентированные прогрммы проще чем на С.

1) Эээ... ООП — это вообще-то внеязыковая конценция. ООП даже на ассемблере бывает. Только таблицу виртуальных функций будешь организовывать сам.
2) C++ он именно потому и плюс-плюс, что не забрал ни одной старой возможности. Вот идеал, к которому надо стремиться.

VD>Вот такая же фигня и с другими частями. Скажем ты усердно выписываешь паттерн перебора элементов контейнера везде где нужно с ними что-то делать. А в каком-нить Шарпе есть встроенный оператор foraech который позовляет не выпиливать паттерн, а точно описать что с ним делать. А в каком-то другом языке есть готове решение позволяющее не писать циклы вообще (это я на ФП намекаю, хотя оно и в Шарпе есть).

VD>А теперь представь, что есть язык который позволяет большую часть таких паттернов (в том числе и паттернов-проектирования) запихнуть в библиотеки и использовать где надо. Вместо тщательного выпиливания канонов паттерна ты просто декларируешь его применение и задаешь (тоже декларативно) нужные параметры. А все остальное автоматически выпиливает компилятор по программе называемой "макрос" (не путать с сишными текстуальными макросами). И более того, такие "программы" для компилятора ты можешь создавать сам.

VD>Не уж-то это не стоит того, чтобы хотя бы ознакомиться с таким языком?

Нет, не стОит. Язык не будет за тебя решать твою задачу.
Зайди (например) на сайт Яндекса и посмотри какие там задачи. Ну вот одна из таких:
Есть два списка глаголов русского языка 1) совершенные и 2) несовершенные.
Соберите каким-нибудь образом все пары типа "делал-сделал".

Ну вот каким образом новый язык программирования поможет в решении такой задачи? Воот...

Я обьясню это через придуманную мною алегорию.
Можно купить машину с очень мощным мотором.
Но стоять в пробке она будет примерно с той же скоростью как Запорожец.
Потому что движение лимитурует другой фактор.

Так и с языками. Языки программирования уже давно не лимитируют твое понимание предметной области.

PS.
Я так понял что ты языками занимаешься? Немерл (или как его там) сочиняешь? Идея мне тут в голову пришла.
Макрос — это же не языковое понятие. Результатом применения макроса является преобразование одного текста в другой текст.
Текст этот не обязательно должен быть именно на языке программирования. Он может быть и на русском.
Вот... придумай достаточно мощщщщщщщщный язык макросов, который можно было бы прикрутить... к чему угодно.
Например как препроцессор препроцессора С++. И реализуй на нем то, что ты мне тут в виде рекламы написал — паттерны.
И прославишь ты свое имя на веки вечные как Страуструп и Степанов.
А С++ не трожь, не замахивайся на святое!
Когда разбогатеешь 10% мне не забудь, ты же честный человек

PS2. Макросы как часть IDE могут быть. Чтоб сразу видеть было-стало.

Здравствуйте, FR, Вы писали:

FR>У вас этого опыта нет, так что ценность ваших поучений относительно этого предмета близка к нулю.
FR>Вот если вы будете критиковать C# или Немерле это будет весьма ценно для цели "обучения на чужом опыте".
Ну то есть притензий к озвеченным фактам нет.
Так и запишем.

Здравствуйте, Undying, Вы писали:

L>>Понятий "хорошо" и "плохо", имхо, не существует. Зато есть "лучше" и "хуже", для употребления которых уже и нужно зныние иных языков.

U>И что эта игра словами изменила? Если думать не в терминах языка, а в терминах решаемой задачи, то становится видно можно ли найденное решение записать лучшим образом по сравнению с записью в используемом языке. Знать другие языки для этого не требуется. Вот если видишь, что решение можно было записать лучше, но язык не позволил, тогда да возникает вопрос, а существуют ли языки, в которых нужная тебе запись доступна. И вот только для ответа на этот вопрос требуется знание других языков.

Есть у тебя список, надо вернут все элементы, удовлетворяюшие условию.
Если ты не знаком с функциональными фичами шарпа, то у тебя родится тчо-то вроде

var result = new List();
foreach (var x in coll)
  if (test(x))
    result.Add(x);

Как, думая в терминах решаемой задачи, прийти к более простому варианту

var result = new List(coll.Where(test));

Здравствуйте, Undying, Вы писали:

U>И что эта игра словами изменила? Если думать не в терминах языка, а в терминах решаемой задачи, то становится видно можно ли найденное решение записать лучшим образом по сравнению с записью в используемом языке. Знать другие языки для этого не требуется. Вот если видишь, что решение можно было записать лучше, но язык не позволил, тогда да возникает вопрос, а существуют ли языки, в которых нужная тебе запись доступна. И вот только для ответа на этот вопрос требуется знание других языков.
Неверная логика.
Если человек не знает о возможностях то он о них и думать не будет.

Здравствуйте, WolfHound, Вы писали:

WH>Неверная логика.
WH>Если человек не знает о возможностях то он о них и думать не будет.

Чтобы узнать о возможностях, не обязательно изучать язык. Достаточно посмотреть, как на нём решаются типичные задачи твоей предметной области.

Здравствуйте, Lloyd, Вы писали:

L>Есть у тебя список, надо вернут все элементы, удовлетворяюшие условию.
L>Если ты не знаком с функциональными фичами шарпа, то у тебя родится тчо-то вроде

L>

L>var result = new List();
L>foreach (var x in coll)
L>  if (test(x))
L>    result.Add(x);

L>

L>Как, думая в терминах решаемой задачи, прийти к более простому варианту
L>

L>var result = new List(coll.Where(test));
L>

L>

Плохой пример. Для меня первый вариант проще, чем второй. В простых случаях (таких как приведенный) это не заметно, но очень хорошо видно в случаях сложных.

Здравствуйте, dimgel, Вы писали:

FR>>Я PHP и JavaScript практически не знаю, но судя по тем же флеймам они гораздо более подвержены ошибкам чем питон и руби ввиду очень слабой типизации.

D>Является ли сильная типизация по сравнению со слабой преимуществом при автоматическом рефакторинге, если оба языка динамически типизированные?

В теории и частично и на практике(PyPy) да является, для сильно типизированного динамического языка подмножество кода приводимого к статическому будет намного большим. Например тот-же PyPy транслирует код в статически типизированный RPython для которого все плюшки статически
сильно типизированных языков доступны.

D>Я склонен считать, что нет, т.к. ошибка типов в любом случае вылетит в рантайме, IDE никакой помощи тут не предоставит.

Статический анализ кода для динамики тоже существует и используется в таких вещах как pylint pychecker rope
Плюс довольно большое число ошибок ловится в такой фазе как загрузка модуля, да это рантайм, но он не требует полного исполнения кода, также как и
такие вещи как абстрактная интерпретация работающая на грани динамики и статики.
Конечно пока до уровня хорошей сильной статики это все не дотягивает, но движение есть.

D>Если так, то это ключевая претензия, и она ни на йоту не гипертрофированная: её значение переоценить невозможно. Как по мне, невозможность быстро и надёжно (без необходимости писать тонну юнит тестов) рефакторить код — это приговор языку.

Я так не считаю, как и множество других программистов.
Юнит тесты в динамике да необходимы, но не тонны, их размер будет вполне сопоставим с размером оных для статики.

D>На любом хоть сколько-нибудь крупном проекте рефакторинг будет выливаться в такой геморрой, что проще повеситься. "Отвинтили пупок — отвалилась задница." Всё остальное я перетерплю, но когда рефакторинг кода похож на хождение по минному полю, когда на каждый чих типа переименования метода приходится вручную шерстить весь проект глобальным поиском, потом смотреть, что из найденного относится к нашему классу, а что не относится (а в отсутствие информации о типах приходится анализировать логику, иногда глубоко), а потом молиться, чтобы где-нибудь не упала завязанная на рефлексии динамика, конструирующая имя вызываемого метода так, что он не нашёлся поиском... это ад, в общем. Огромное количество временных затрат на ровном месте. Вот реальная проблема. А что в рантайме я не смогу присвоить числовой переменной строку — мне глубоко пофиг, я уже привык assert-ами по коду разбрасываться, они неплохо компенсируют слабую типизацию.

Тесты в этом вполне рулят.

Здравствуйте, dimgel, Вы писали:

D>Демагогия detected. Система типов именно что даёт математически доказанные гарантии.

Для языков с выводом типов не дает. Мешает проблема останова и алгоритмическая сложность, если нужны подробности смотри Основания языков программирования

Автор(ы):
Дж. Митчелл


Если Вы хотите написать или уже пишете свой язык программирования №1 в мире, то стоит заботать данную книгу. Книга большая, очень много математики, читается тяжело,
но создание языка программирования №1 — требует жертв. Книга представляет собой теоретическое введение в лямбда-исчисление (основу современных языков программирования).
Материал книги использовался при проведении 3-х семестровых курсов в Стэнфорде. Изучение книги позволяет при создании своего языка встать "на плечи гигантов" и переиспользовать опыт по выделению базовых абстракций из которых строятся языки программирования.

последнюю главу.
Для императивных языков без вывода типов никаких математических теорий просто нет.

FR>>В данном случае да статика(вернее ее подмножество) рулит.

D>А ещё рулит компилятор, ага, который выполнит анализ без необходимости деплоймента и запуска приложения (иногда дорогостоящего) и кликанья по менюшкам, чтобы добраться до загрузки проверяемого модуля.

Зачем менюшки, юнит тесты выполняются одним нажатием на клавишу, и вообще с ними удобно работать http://pydev.blogspot.com/2010/12/improved-unittest-support-in-pydev.html приложение запускается не чаще чем в статике.

Здравствуйте, FR, Вы писали:

FR>Так с анализом обобщенного когда и в статике проблематично.
Чего?

FR>Тебе не нужно, это уже практически аксиома
Что значит мне не нужно?
Оно вообще не нужно.
Ибо никто не может сказать зачем.

FR>Оно поможет тем что нужно меньше правок.
Это ложь.

FR>Угу, кто не хочет слушать не услышит.
Ну так где аргументы то?
Есть только один: Меньше кода.
Но это по сравнению с жабой меньше. А по сравнению с немерле экономии почти нет.
А какие еще? Ну, хоть один.

Здравствуйте, FR, Вы писали:

FR>Как-то не тянет, обращаться к сильно агрессивным людям

То есть претензия исключительно к моей манере общения, а не к квалификации? Ну хоть на том спасибо.

D>>И кстати, рекомендую на досуге поизучать скалу, чтобы ознакомиться с настоящей, нормальной статикой, и не демонстрировать собственное невежество,

FR>Только начинаю думать что с тобой можно нормально общаться и опять трололо с переходом на личности

D>>утверждая про проблемы с generics.

FR>Спасибо за совет про скалу, но мне хватает OCaml'а и небольших доз F# там этой статики более чем достаточно.

Раз ты говорил о проблемах с generics, значит нормальных generics ты не видел, следовательно недостаточно. И не надо расценивать констатацию факта твоего невежества в отдельно взятом вопросе (который ты собственноручно доказал) как переход на личности — это детство какое-то. Я сам невежда в огромном количестве областей, и что? Так что повторю рекомендацию: изучи скалу. "Мне хватает того-то сего-то" — это констатация собственной лени и нежелании развиваться. Кто тебя после этого будет воспринимать всерьёз?

By the way, я не знаю, что ты вкладываешь в слова "со мной можно нормально общаться". Я не вижу причин менять стиль общения с человеком, не понимающим аргументов, не желающим развиваться, не дружащим с формальной логикой, неспособным вести строго аргументированные споры, постоянно скатывающимся на обсуждение квалификации собеседника. Если честно, я вообще не вижу смысла с таким человеком общаться, но уж как-то так случилось. Положительная сторона в том, что мне не нужно строить из себя политкорректность.

Здравствуйте, WolfHound, Вы писали:

WH>Типизация выполняется полностью на этапе компиляции.
WH>Но из-за того что отсутствуют типы типов ошибка компиляции появляется черт знает где, а не там где она действительно произошла.

Это я понимаю. Но это уточнение не прибавит аргументов FR-у.

Здравствуйте, vdimas, Вы писали:

V>Дык, Немерле ведь от всего вышеупомянутого страшно далек, ты его сюда не приписывай. Он просто динозавр, родившийся поздно. Представляет из себя сугубо практическую попытку собрать несколько полезных наработок в одном языке на основе имеющейся мощной платформы, угу. В общем, вовсе не "край", а сугубо практическая попытка найти приемлемый компромисс м/у обилием фич и привносимыми ими помехами. Кстати, я не отрицаю полезность этой попытки. Скорее наоборот, обоими руками ЗА. Ведь макросы в С несколько сдали назад по тем временам и подорвали доверие к этой технике. Например, даже возможности макроассемблера на порядок превосходят возможности препроцессора С, не говоря уже о 50-летнем Лиспе или 40-летнем Форте. Пора вернуть макросы на заслуженное место, снабдив их типобезопасностью. Возможно, Немерле своим примером поможет сделать это в следующих версиях интересных мне языков. Хотя, справедливости ради, чрезмерное увлечение макросами всегда считалось плохим тоном во всех перечисленных языках. Элегантности кода не нужно приносить в жертву очевидность происходящего. Иначе бывает больно, вплоть до полного выкидывания и переписывания заново. В общем, моё ИМХО по этому вопросу умеренное, не приемлет обе крайности.

Ты бы лучше чем выпячивать тут свои знания истории ответил на один простой вопрос. Так почему наши профессора не знают даже такой дремучей древности?

V>Кстати, показательно. По-твоему, "настоящие программисты" должны писать софт исключительно для других программистов и заниматься исключительно проблемами языков. Сорри, но это сразу в сад, не задерживаясь.

Они должны знать перспективы индустрии и учить этому студентов. А не зацикливаться на поделаках вроде ББ, у которых даже GC на уровни Симулы остался.

V>>>Язык реализации — это последнее, что интересует. Вернее, не интересует никогда.
WH>>Ну да... конечно.
WH>>И после того как человек в это начинает верить получается всякая байда типа компиляторов на С.

V>А что не так с С? Отличная абстракция ассемблера. Настоящий нейтив во-плоти, без встроенных фокусов...

Если бы ты прекратил токовать как тетерев и внимательно прочел его слова, то заметил бы слово "компиляторов". Писать компиляторы на С при наличии потомков того самого МЛ — это действительно глупость.

V>>>Защитите хотя бы кандидатскую...
WH>>И нахрена оно мне надо?

V>Чтобы привести в порядок собственные наработки. Чтобы в численном виде подсчитать характеристики и преимущества, наконец, если они есть. Чтобы провести и зафиксировать полноценное сравнение с имеющимися наработками в этой же области, показать прогресс (если есть), и характерные отличия.

Ды та не боись. На немрле пару человек уже защитилось. Проблема только в том, что код написанный для защиты — это код приготовленный в топку. И за "защитниками" все надо переписывать.

V>Например, ты прямо сейчас способен обосновать, почему нерекурсивные алгебраические типы представлены ссылочными типами, хотя дотнет позволяет оперировать value-type? А ведь ML-языки умеют делать такие оптимизации уже черти сколько лет. Пяток подобных вопросов без убедительных ответов, и можно идти допиливать диссер, а лучше сам язык.

Ну, ты разберись в рантйме дотнета и тогда ты поймешь, что на то есть объективные причины. В дотнете запрещена реинтерпретация памяти (типобезопасность однако). А для реализации АлгТД в виде вэлью-типов нужна реинтерпретация. Дотнетный GC тупо упадет если ему попытаться подсунуть структуру в которой совмещены, скажем, целочисленные и ссылочные поля.

WH>>И что есть классика?
WH>>С++?

Незнаю, не знаю. Когда я слушаю моцерта, то понимаю, что большей части моих современников до него как до луны. Когда я вижу код на С++, я понимаю, что это была тупиковая ветвь эволюции.

V>Для императивных — Фортран/С/Паскаль. Функциональный — Лисп, логический — Пролог. Отличные языки для изучения парадигм. Почему отличные?

Да не очень то они отличные. Хотя приемлемые. Но ведь на практике же их все равно никто в вузах не преподает. Точнее иногда преподают, но на уровне все того же Паскля. Сколько я видел людей говоривших мне что учили Лисп в универе и даже сдававших лабы на нем. Только вот когда они видели макры и ФВП, то сразу дополняли свой рассказ откровение вроде — "А я думал что Лисп это такй императивный язык...". То есть они вообще не проходили того что делает Лисп Лиспом.

V> — а ничего лишнего, никаких понтов, шелухи и синтаксического сахара. Да, в этом и проблема Пролога например, что у него плохая стыковка с "общепрограммисткими" задачами, типа ГУИ, БД, сетка и т.д. Но для целей изучения логического програмимрования — это наоборот, мега-плюс. Бо ничего лишнего.

+100. Ну, и где от Лаптева или Дворкина хоть слово про Пролог?

А где те программисты которые могут программировать на Прологе?

Фактом является то, что максимум что могут заложить наши бездарные учителя вузов — это общие знания о том, что есть какой-то ЛП, а есть что-то вроде ФП.

Я тебе скажу больше. Образование в области программирования у нас практически уничтожено. В стране осталось 3-4 вуза из которых выходят действительно программисты. Большая часть молодых программистов стали таковыми не благодаря системе образования, а вопреки ей.

Но это все здесь полнейший офтоп. Так что предлагаю с ним завязать.

WH>>Не мудрено.
WH>>Вот тебе кусочек кода. https://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n

V>А вот и оно, спасибо. Типичный индусокод. Ни малейшего понятия о декомпозиции и тестопригодности. Развязаться через независимые ф-ии видно не судьба.

Ты понты бы по убрал. А то вон на тебя ГЫ тут загляделся и на "Си" этот код переписал. Профи, хренов.

V>Насчет тестопригодности. Ты должен будешь на один метод завязать как кучу низкоуровневых независимых тестов по проверке каждого отдельного вычисления, так и комплексные тесты, проверяющие их комбинации. А это залёт, курсант.

Курсант, ты бредишь. Все что нужно тут тестировать — это то, что после преобразования из дерева А получилось дерево Б.

Более того подобные тесты просто не нужны. Тестом является любое применение макроса для которого этот оптимизатор работает.

V>И где там пуля, ткни пальцем.

Да маттерн-матчинг, о котором ГВ и Лаптеву известно только то что он есть.

V>90% — ветвления идет по единичному тагу размеченного объединения.

Ты людей то не пугай такими словами "размеченного объединения". Их знания оканчиваются на ББ и СыПласПласс. А это никак не 92-ой год.

V>В факте предпросмотра на один уровень вперед (тоже самое тут: Fsm(a)::Fsm(b)::rest)? Да еще через ж... динамическую типизацию в реализации Nemerle? Издеваешься или как?

Не. Не издевается. Для них это кибер-бластер. Они вообще не понимаю, что здесь происходит. А вольфхаунд и не заявлял, что код особо сложный. Для любоого языка с ПМ код самый обыйденный.
Проблема в том, что строку вроде:

| (Rule.Fsm(fsm1) as r1) :: (Rule.Fsm(fsm2) as r2) :: rules =>

Ни Лаптев, ни Дворкин, ни Васильев понять не смогут. Для них это набор какой-то хрени.

V>В общем, декомпозируй решение, и на любом языке это будет смотреться очень похоже. Ни в какие 20 раз и близко разницы не будет.

Я тут даже соглашусь. Будет раз 5. Вот здесь

Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.

есть изолированный пример уже переведенный в классическую форму для ООЯ. Можешь разы сам посчитать. Если брать полный компилятор, то по моим прикидкам выходит где-то раз в 10. Но это, правда, в купе с макросами и остальной замшелой фигней известной с МЛ и Лиспа.

V>Далее, вот это ленивые вычисления или энергичные?
V>

V>| Choice(rules)                 =>
V>          def rules = rules.Map(optimize);
V>          def rules = rules.Map(
V>            fun(_)
V>            {
V>              | Rule.Choice(rules) => rules
V>              | rule               => [rule]
V>            });
V>         def rules = rules.Flatten();
V>         ...
V>

V>Если энергичные, то в топку, бо многопроходность, а оно вполне решаемо за один проход.

Энергичные. Только вот многопроходность ты здесь выдумал. В прочем, можно было конечно и в ленивой манере написать. Не думаю, что скорость изменилась бы.

V>Тоже самое с Sequence(rules). Заметь, на плюсах тут вполне можно было обобщить на шаблонах оба случая.

А ну-ка изобрази! Языком то все молоть горазды.

V>Но на немерле или C# — это надо было бы городить огород из паттерна "Стратегия" для целей обобщения, и овчинка выделки не стоила бы.

О как? Стратегия говоришь. Тоже давай изобрази. Люблю юмор.

V>Собственно 90% функциональности метода рассмотрено. Проходишь по всем вложенным конструкциям и вызываешь оптимизацию правил для вложенных правил, если есть.

Ага. Если язык гарантирует оптимизацию хвостовой рекурсии и есть МП, то нет пролем. Этот код что на F#, что на Скле можно написать за милую душу. А вот про С++ ты уже врешь. Про C# и подавно.

В общем, попробуй. Флаг тебе в руки. Особенно смешно со стратегией ты тут залудил. Я вообще люблю паттерны. Как они появляютс, так сразу весело становится. Посетители, Сратегии... И это все вместо ПМ и лямбд.

V> Самих оптимизаций по сути две — это оптимизация последовательностей Not/And, и вызов FsmBuilder для цепочек символов и автоматов.

Да не важно сколько их. Сейчас две. Завтра 22. Важно насколько на языке легко выразить задачу. Вот есть исходное дерево (или граф) и нужно получить конечное. Какие там паттерны на С++ использовать будешь? Ну, что будешь делать, если нужно будет вложенность в 4 колена обработать?

V>Далее. Есть предложение для обоих случаев насчет возможности построения оптимизированного варианта сразу, по мере парсинга правил, а не "потом", за вот этот проход оптимизации.

Офигительное предложение! За одно его тебя я уже больше никогда всерьез воспринимать не буду. Взять и смешать сложность из двух задач. Супер! Так держать. И еще при этом у тебя хватает наглости смеяться над чужим кодом. Да ты же просто ламер нахватавшийся умных слов.

V>Это как разница в подходах построения ДКА — сначала можно строить по регулярным выражениям НКА, приводить его к ДКА, а затем минимизировать, но ведь можно строить сразу минимизированный ДКА — это порой на порядок быстрее, т.к.

Ну, ты очень крут. Но как-то скромен. Можно же пойти дальше и сразу в один проход построить эффективный исполняемый код! Давай, дерзни.

Так вот я вот что тебе скажу. Код Вольфхаунда может быть и не безупречен, но на сегодня никто еще лучше не написал. Из реализаций PEG-а его самая быстрая.

А вам, ... с корачками у него лучше поучиться, а не выставлять свое распухшее эго на показ.

V> на каждом шаге обработке подвергается множество меньшей мощности. Хоть алгоритм и чуть более сложный, угу.

Угу. "Чуть более сложный". Я без мата этот лам даже дальше коментировать не могу. Чуть более сложный в данных условиях означает неподъемный. Там сложность зашкаливает. Только благодаря не ординарным способностям Вольфхаунда и использованию инструмента позволяющего снизить сложность до приемлемого значения этот генератор парсеров и стал возможным. Конкуренты лабающие аналоги на Яве и С++ уже много лет нервно курят в сторонке, так как их поделки раза в 3 медленнее.

V>В общем, подкинь что-нить посущественнее, что ли...

Куда тебе. Ты на этой задаче садяшь со своими подходами. Ты только что расписался в полном и беспросветном ламерстве. Идея распихать код оптимизации по парсеру — это супер! Глупее и придумать ничего нельзя.

В общем, сори, но читать подобну ахинею да еще с таким ханжеским апломбом я не могу. Я понимаю, что я перешел грань. Пойду забаню себя к чретям.

Тему вы мою все равно угробили офтопом.

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

Пожалуй, останавливает само количество языков:
http://en.wikipedia.org/wiki/List_of_programming_languages
Насчитал тут более 650 штук(!)

Здравствуйте, vdimas, Вы писали:

VD>>Да ты шутник, однако. Только форумом ошибся. Тебе нужно в юмор.

VD>>2 WolfHound: Когда ты поймешь, что показывать примеры кода можно только тем, кто их понимает. Ты думешь, что что-то там обосновываешь, а человек тупо нихрена не понимает. Он в жини только if-ы освоил. И твои примеры для него — это еще один енпонятный набор крокозябр.

V>Влад, поменьше понтов.

Это ты по меньше понтов бросла бы. А то все равно твои слова лам выдают ведь.
Цитата выше, правда, не про тебя была.

V>Сначала попробуй понять, что именно критикуется. Автор кода, я уверен, понял прекрасно. А вот ты нет.

Да я то понял. Он вообще не понимает как работат ПМ и что такое АлгТД. Ты явно это понимаешь, но похоже только теоретически. Потому как твои советы были феерическим ламом.

V>На досуге помедитируй над вот этими двумя локальными ф-иями и попробуй найти у них связанность:
V>

V>          def catFSM(_)
V>          {
V>            | (Rule.Fsm(fsm1) as r1) :: (Rule.Fsm(fsm2) as r2) :: rules =>
V>              catFSM(Rule.Fsm(r1.Location + r2.Location, FSMBuilder.Choice([fsm1, fsm2])) :: rules)
V>            | rule :: rules => rule :: catFSM(rules)
V>            | []            => []
V>          }
V>=====================================================
V>          def catFSM(_)
V>          {
V>            | (Rule.Fsm(fsm1) as r1) :: (Rule.Fsm(fsm2) as r2) :: rules =>
V>              catFSM(Rule.Fsm(r1.Location + r2.Location, FSMBuilder.Seq([fsm1, fsm2])) :: rules)
V>            | rule :: rules => rule :: catFSM(rules)
V>            | [] => []
V>          }
V>

V>А после тщетных попыток попробуй нарыть хотя бы одну метрику оценки кач-ва кода, значение которой не будет для приведенных отрывков наихудшим.

Ты говоришь о небольшом дублировании кода. А ГВ говорил о другом. Он вообще не понял написанного.

VD>>Я тебе сейчас переведу этот код. Вот как это будет выглядеть на доступных для тебя языках:

V>Да пофиг, основное замечание было в смешении процесса диспетчеризации и каких-то ф-ий "по месту", которые не связаны с диспетчеризацией.

Не неси пургу. Это трансформация дерева. Причем вынесенная в отдельную функцию (локализованная). Устранять здесь "диспечиризацию" — означает превращать код в говно смешивая разную логику.

Если ты до этого еще не до рос, то иди работай над собой, а не давай советы вселенского масштаба и вселенской же глупости.

VD>>1. В привычных тебе языках оптимизация концевой рекурсии не гарантируется,

V>Хе. А если ему Лисп привычен?

Он только название такое знает.

VD>>так что для корректной реализации тебе придется заменить вложенную функцию на цикла и стек (с ручной манипуляцией этим стеком).

V>А что, обрабатываемые правила могут иметь бесконечную вложенность?

С достаточной чтобы получить переполнение стега. К тому же даже если ты его не получишь скорость может очень сильно прочесть.

V>И вопрос на 1000000 баксов: в Немерле хвостовая рекурсия только в рамках одной ф-ии работает?

К сожалению — да.

V>Т.е. случай двух взаимно-вызываемых ф-ий не оптимизируется?

Нет.

V> Только это бы объяснило приведенный код в стиле дельфийского MegaButton_Click, т.е. оправдало бы автора... но это же приговор текущей реализации компилятора, требующей от программистов говнокодить.

Как раз взнаимная рекурсия нужна не так часто. Проблема в том, что реализовать взаимную рекурсию для общего случая не так просто. Хотя конечно, нужно реализовать хотя бы для случая вложенных функций. Это не так сложно.

В дотнете есть специальная мсил-ина для хвостовой рекурсии, но на практике вместо ускорения кода она дает замедление.

V>Ваш optmize не требует посетителя. Достаточно абстрактного метода и реализация в наследниках. Тоже забыть переопределить будет сложно. К тому же, можно будет обобщить, где близко (Choice/Sequence) и разнести нафиг несвязанный функционал всего остального.

Ну, не томи. Давай продемонстрируй нам код на шарпе или плюсах. Потом без посетителей конечно можно жить, но вот только до появления второго обхода дерева. После этого экономия на спичках сразу же превращается в гимор.

VD>>Но как только ты это сделашь распознование вложенных паттернов (Not вложенный в Not, как в данном примере) превратится в мучение. Кода станет уже не в 5, а в 10-20 раз больше.

V>В 10?
V>

V>virtual Rule ^ Rule::And::optimize() {
V>  switch(arg->tag()) { 
V>    case TagNot: return gcnew Not(arg->optimize());
V>    case TagAnd: return gcnew And(arg)->optimize();
V>    default: return gcnew And(arg->optimize());
V>  };
V>}
V>

Код, кстати, не верный.

А что ты будешь делать когда потребуется еще один уровень вложенности? Начнешь типы приводить и вложенные кейсы писать?

Да, и не видно шаблонов! Ты тут ведь недавно про шаблоны говорил. Они же должны дать невероятный эффект.

Очень интересно что ты будешь делать когда придется кроме оптимизации еще каую-то обработку сделать? Бежим по файлам и добавляем новые методы? Посетитель ведь нам не нужен.

А где Команда? Ты ведь еще этот паттерн упоминал.

Если приглядеться, то несложно заметить, что код твой стал полным говном, так как контроль компилятора утрачен. Обрати внимание на то что МП контролирует наличие всех возможных пересечений в match.

V>Это вместо 3-х матчей в исходном примере. Разница ровно на "обвеску" (заголовок метода), но это ведь после декомпозиции.

Серьзено? Вместо аж трех? Ты привел замену двум строкам кода:

 | Not(Not(rule))                => optimize(Rule.And(r.Location, rule))
 | And(Not(rule))                => optimize(Rule.Not(r.Location, rule))

и то с ошибками.

В результате вместо двух строк ты получил 7 в сжатом виде. А в придачу ты заработал геморрой на всю оставшуюся жизнь, так как код этот не будет контролироваться компилятором. Любой изменение в структуре правил сможет привести к долгим и мучительным вискиваниям мест в которых ты забыл добавить обработку.

V>Это ты бредишь. Твой код просто не верен. Ты выбросил одну проверку.

VD>>Так что насмехаешься и горлопанишь ты тут исключительно от своей невежественности. Ну, а приведенный тобой "код" просто нерабочий.

V>"Рабочесть" приведенного кода зависит от обвески,

Не. Никак. Это принципиально не рабочий код. Там как минимум требовалось дополнительное приведение типов. Плюс в коде для банального сравнения создавались временные объекты:

else if (match(rule, Not(Not())) { return optimize(And(r.Location, rule)); }

Что за rule тут взялось из неоткуда? А Not(Not()) это что за хрень? Врменные объекты?

Короче это бред, а не код. Его не заставить летать даже с помощью волшебной палочки.

V>то бишь реализации окружения, как и в вашем примере. В плюсах, знаешь ли, бывают удивительные шаблонные перегрузки сигнатур, вполне можно и такой синтаксис сбацать.

Не знаю. Покажи, я ознакомлюсь. Твой код я вот посмотрел и он похож на правду. Хреновую такую, но все же. А код ГВ просто не код, а его вымысел.

VD>>Так для справки. Обрезанный компилятор C# (из SS CLI) написанный на С++ Майрософтом занимает 5 мег. Компилятор Немерле ~2. И это при том, что язык сложнее в разы.

V>
V>И это при том, что компилятор Немерле имеет зависимость от нескольких основных дотнетных либ по многу мег, а приведенный компилятор C# писан с 0-ля без внешних зависимостей. Сравнил так уж сравнил.

Ну, давай расскажи что за чудо либы использует компилятор немерла? Я вот знаю одну — чтение из файла. В состав сишного кода тоже не включены библиотеки. Они там рядом лежат. Занимают бесятки мег.

А языки меж тем не соизмеримы. Так что если дать поправку на сложность кода, то получится где-то 7-10 раз. Ты же наверно не забыл, что в немерле как раз таки по полной программе есть и макросы, и расширяемый парсер, и паттерн-матчинг, и АлгТД, и поддержка linq. И это все против C# 2.0.

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, alpha21264, Вы писали:

A>>Здравствуйте, VoidEx, Вы писали:

A>>Ты очень далеко увел аналогию от обсуждаемой темы.
A>>Я не знаю, что такое "посторили метро" или "не построили метро"
A>>применительно к процессу написания программы.

VE>

A>Метро всё равно быстрее их обоих.

VE>Сам придумал, сам не знаешь?

Не хами. Метро быстрее — очевидный факт. В большинстве случаев просто в разы.

A>>Моё утверждение просто как палка:
A>>был бы хороший алгоритм, а реализовать его можно хоть на хинди. Язык не важен.
A>>Вот с этим спорь.

VE>Ты аналогию придумал, сам ввел метро, вот теперь и потрудись рассказать, что есть метро? Алгоритм? Тогда каким местом стоит выбор между метро (алгоритм) и автомобилем (языком)?
VE>А если это язык, который есмь побыстрее остальных, то назови ж нам его.
VE>Алгоритм — это путь; в пробочном пути ехать на мерсе дольше, но это не значит, что по более быстрому пути теперь можно и на запоре гонять.

Тебе сколько лет?
Я тебе уже сказал. Для сложных задач (не ларек об1Сивать) язык не важен.
Совсем не важен, как авторучка для писателя, нужно чтобы просто была какая-нибудь.
Ничто, никакой божественный язык не позволит тебе написать FineRider или хотя бы Промт.
Потому что ты не знаешь что и как должна делать программа.
С самым совершенным языком ты будешь просто в два раза быстрее тупить.
Мерседес тебя никуда не довезет, если ты не знаешь, куда ехать.

Я тут уже предлагал простенькую задачку (с сайта Яндекса). Есть список глаголов русского языка.
Сформировать список пар глаголов "делал"-"сделал".
Какие преимущества в этой задаче может дать язык программирования?
В качестве эталона берем С++.

Здравствуйте, hardcase, Вы писали:

H>Цель парсера, построенного с помощью нашего макроса — разобрать исходник и построить его AST.

Я тут выше намекал уже на парсер SAX, и на парсер XML-DOM. Второй получается из первого, путем добавления модуля постройки этого DOM. Похожую схему я как наблюдал неоднократно, так и делал сам, — очень удобно, рекомендую. Особенно в целях тестирования и гибкости доработки построителя модели, в вашем случае ACT. А wolfhound просто воткнуть никак в этот намек не может.


H>Абракадабра получается после трансформации некоторых правил в конечный автомат (но даже тогда вполне читаемая и наглядная). В остальном все вполне читаемо и приемлемо для отладки и профилирования.

Да я уже понял, что у вас даже конечный автомат не табличный. Хотя, учитывая тормоза дотнета по чтению из массивов, может оно и правильно.

Здравствуйте, robin_of_the_wood, Вы писали:

A>>>http://en.wikipedia.org/wiki/List_of_programming_languages
___>Скролишь и думаешь — а вдруг убрали.

Monsanto go home!

Здравствуйте, Ziaw, Вы писали:

Z>А можно по аналогии привести примеры чего чудесного сделали авторы java/c#/питона/руби/хаскеля на своих языках?

Авторы C#, к примеру, dotnet framework написали. Для начала двухтысячных это было прорывом.

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

От изучения — не останавливает. Я "изучал" десятки языков на уровне "понять основные концепции-пройти несколько туториалов".

От применения останавливает следующее.

К сожалению, язык сам по себе — ничто, как сколь гениален он бы не был. Попробуйте переплюнуть Чарльза Мура и Джона Маккарти. Для серьезной работы нужны инструменты (как минимум, визуальный отладчик), окружение, библиотеки, причем не альфа-бета качества, и даже не первого релиза. Я присоединяюсь в данном случае к Ричарду Гэбриелу, в окончание своей почти 20летней эпопеи сказавшему что хороший программист хорошо и быстро пишет без корелляции с языком (не в том смысле что он способен хорошо писать на любом языке, а в том смысле что хороший С++шник способен не хуже писать на С++ чем хороший жавист на Java). Необходимо коммьюнити, вагончик библиотек на все случаи жизни (да, я знаю что ТЕОРЕТИЧЕСКИ я способен многое написать лучше, но ПРАКТИЧЕСКИ это нереально).

Есть определенные неубиенные слоны, которых не обойти. Навскидку (то что лично для меня создает наибольшую проблему, я такое написать неспособен в приемлемые сроки) — многопоточность, concurrency, lock-free алгоритмы и структуры данных, кластеризация. Пока таких слонов на "новом" языке нет — на нет и суда нет.

Здравствуйте, VladD2, Вы писали:

Любое изучение нового языка преследует 2 цели
1. Познавательная, для определения различий и из этого достоинства того или иного языка и в основном обзорное изучение.
2. Практическая, когда известно премущество данного языка для конкретной цели.

По первому пункту всегда интересно что нового появляется в программостроении.
Второй пункт зависит от существующих задач, а так же интересом применения накопленного опыта.

Здравствуйте, VladD2, Вы писали:

VD>Я не знаю что за хреть такая IIOP.Net, то чудес не бывает. Единственное решение которое я могу себе представить — это завести структуру которая бы сдублировала бы все поля всех вхождений АлгТД плюс тег. В итоге вместо создания объекта получаем перемножение всех полей всех вхождений. Передавать такую структуру через параметр это просто праздник какой-то.

Дык, ссылочные поля могут как раз могут перекрывать друг друга, и GC отлично работает. Эти ссылочные поля нельзя перекрывать нессылочными. Только ты GC все-равно не поломаешь, среда исполнения просто не загрузит такую сборку. Я же не зря упомянул процесс "упаковки". Должен быть внутри адресного поля объекта некий "пул" под объединение нессылочных и отдельно ссылочных полей.

Вот простеший пример, я поля вручную раскидал, ссылочные перекрывают ссылочные, нессылочные перекрывают нессылочные:

	Скрытый текст
	using System; using System.Collections.Generic; using System.Runtime.InteropServices; namespace Union { class Program { class TestObj1 { ~TestObj1() { Console.WriteLine("TestObj1 collected"); } } class TestObj2 { public virtual void SomeDummyMethodTomakeVTableDifferenced() { } ~TestObj2() { Console.WriteLine("TestObj2 collected"); } } struct A { public int i; public TestObj1 s; public A(int i, TestObj1 s) { this.i = i; this.s = s; } } struct B { public double d; public List<TestObj2> objs; public B(double d, List<TestObj2> objs) { this.d = d; this.objs = objs; } } [StructLayout(LayoutKind.Explicit)] struct Union { public enum Tag { A, B, C } [FieldOffsetAttribute(4)] Tag _tag; // A fields [FieldOffsetAttribute(sizeof(Tag) + 4)] int i; [FieldOffsetAttribute(sizeof(Tag) + sizeof(double) + 4)] TestObj1 s; // B fields [FieldOffsetAttribute(sizeof(Tag) + 4)] double d; [FieldOffsetAttribute(sizeof(Tag) + sizeof(double) + 4)] List<TestObj2> objs; public A A { get { if (_tag != Tag.A) throw new InvalidCastException(); return new A(i, s); } } public B B { get { if (_tag != Tag.B) throw new InvalidCastException(); return new B(d, objs); } } public Union(A a) : this() { _tag = Tag.A; i = a.i; s = a.s; } public Union(B b) : this() { _tag = Tag.B; d = b.d; objs = b.objs; } } static void Main(string[] args) { A a = new A(1, new TestObj1()); B b = new B(1.0, new List<TestObj2> { new TestObj2(), new TestObj2() }); Union u1 = new Union(a); Union u2 = new Union(b); } } }

Отлично вызываются все финализаторы. Запусти проверь. Заметь, я поставил не просто два экземпляра похожих типов, но один из них завернул в коллекцию List<>.



VD>>>Потому во всех языках дотнета (что поддерживают АлгТД) АлгТД сделаны через классы.

V>>И вот целый пласт возможных оптимизаций на уровне джита просто обрубается, не говоря уже о том, что даже дотнетная куча вовсе не бесплатна.

VD>Стек тоже не бесплатен.

По моим замерам, для небольших структур (на десятки байт), во многих сценариях было быстрее почти на порядок использовать эффективнее стековые объекты, чем из кучи. Понятное дело, что компилятор должен иметь верхний предел размера объекта после операции всех упаковок для принятия решения о технике реализации конкретного АлгТД.

VD>Смысла нет. На копировании в итоге проиграешь. Разве что ли для вариантов с одним полем. Но это как раз редкость.

Где-то на копировании проиграешь, а где-то за счет -1 уровню косвенности прилично выиграешь. Про верхний предел в размере я уже сказал и его было бы неплохо поискать через эксперименты. Или же явно дать программисту возможность управлять этим, MS же не постеснялась ввести ключевое слово struct. Потому как не только размер имеет значение, но и сценарии использования. Почему бы не ввести некое "variant value"?

VD>Многие варианты рекурсивны и имеют по 3 и более полей. Делать разную семантику для одной и той же сущности?

Фишка в том, что даже рекурсивные АлгТД вполне выполнимы по этой технике и во многих простых случаях дают прирост за счет буста наиболее частой операции — получения головы. Почти все алгоритмы смотрят/матчат значение головы, а тут -1 на косвенность. Это не мало.

VD>Забавно, что отсутствие в Яве пользовательских вэлью-типов заставило ее авторов больше заниматься оптимизацией. В итоге казалось бы более убогий рантайм работает быстрее дотнетного.

Дополнительные оптимизации к этой только плюсуются и никак ей не помешают. Передача небольших типов по значению — это самое естественное в программировании.

Здравствуйте, alpha21264, Вы писали:

A>Нафиг надо, если С++ уже есть?

На фиг нужен был С++ когда был С или даже Фортран?

A>Зачем изучать "те же яйца в профиль", если они не дают новых возможностей?

Не, ну правда! С++ это же те же яйца только в профиль. На фиг ты его учил? Время тратил?

A>Я лучше что-нибудь другое поизучаю ступенькой повыше. Паттерны например. Или что-нибудь связанное с архитектурой.

А если тебе скажут, что есть язык который повзоляет эти паттерны превратить в готовую к использованию библиотеку или фичу языка, тебя это не заинтересует?

Зачем учить паттерны, когда можно просто воспользоваться готовым решением?

Когда-то давно было много программистов писавших GUI на С. GUI отилично ложится на ООП. Но ООП в С не было. Тогда С-программисты придумали паттерны: класс, сообщение, событие и т.п. и начали писать код с их использованием. Многие и сейчас так делают. Но ты видимо к ним не относишься, так как знаешь, что есть язык — С++ в котором эти паттерны встроены. И знаешь, что писать на таком языке объектно-ориентированные прогрммы проще чем на С.

Вот такая же фигня и с другими частями. Скажем ты усердно выписываешь паттерн перебора элементов контейнера везде где нужно с ними что-то делать. А в каком-нить Шарпе есть встроенный оператор foraech который позовляет не выпиливать паттерн, а точно описать что с ним делать. А в каком-то другом языке есть готове решение позволяющее не писать циклы вообще (это я на ФП намекаю, хотя оно и в Шарпе есть).

А теперь представь, что есть язык который позволяет большую часть таких паттернов (в том числе и паттернов-проектирования) запихнуть в библиотеки и использовать где надо. Вместо тщательного выпиливания канонов паттерна ты просто декларируешь его применение и задаешь (тоже декларативно) нужные параметры. А все остальное автоматически выпиливает компилятор по программе называемой "макрос" (не путать с сишными текстуальными макросами). И более того, такие "программы" для компилятора ты можешь создавать сам.

Не уж-то это не стоит того, чтобы хотя бы ознакомиться с таким языком?

Здравствуйте, VoidEx, Вы писали:

VD>>Я тебе сейчас переведу этот код. Вот как это будет выглядеть на доступных для тебя языках:

VE>Плохо переводишь. Неаккуратно. Можно как-нибудь так:

Ты напиши. Не как-нибудь так, а конкретный код, матчащий Not(Not(rule)).

Чтобы он делал именно это и не был завязан на реализацию Not:

if (r is Rule.Not)
{
  var rNot = (Rule.Not)r;
  if (rNot.rule is Rule.Not)
  {
    var rule = (Rule.Not)rNot.rule;
    return optimize(new Rule.And(r.Location, rule));
  }
}

После этого покажи аналог 6 строчек с ПМ.

        | 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))
        | Not(rule)                     => Rule.Not(r.Location, optimize(rule))
        | And(rule)                     => Rule.And(r.Location, optimize(rule))

VE>С учётом написания not = typeof(Not) и другого boilerplate в 2-3 строки код станет не сильно хуже изначальной лапши.

Как бы я видел реализации ПМ на функциях, все они сильно хуже поддержки компилятора.

Здравствуйте, dimgel, Вы писали:

A>>В шаблонах Си++ структурная типизация. То есть, если говорить проще, факт использования типа влияет на процесс его рефакторинга.
D>А можешь примерчик нарисовать для иллюстрации? А то я не въехал.
В С++ типы динамически типизированы.
Вот у нас есть template<class T>. И это все что у нас есть. Про тип T мы ничего не знаем пока его нам не дадут и мы не начнем компилировать данный шаблон с данным типом.
И нет никакой возможности задать какие у типа должны быть методы.
Какие вложенные типы итп.

Порутчикам: Про хаки, которыми можно что-то вытащить, мне рассказывать не надо (я сам про них кому угодно могу рассказать). Ибо они начинают работать, когда нам уже тип подсунули.

Здравствуйте, dimgel, Вы писали:

A>>В шаблонах Си++ структурная типизация. То есть, если говорить проще, факт использования типа влияет на процесс его рефакторинга.
D>А можешь примерчик нарисовать для иллюстрации? А то я не въехал.

template <class T>
class MyTemplate
{
public:
    void Method(T t)
    {
        t.Invoke();
    }
};

class MyTest
{
public:
    Invoke();
}

class MyTest2
{
public:
    Invoke();
}

При переименовании MyTest.Invoke() надо так же переименовать вызов T.Invoke() в MyTemplate<T>.Method(T), если шаблон MyTemplate инстанциировался классом MyTest. Так же надо найти и переименовать методы Invoke в других классах, которыми инстанциируется MyTemplate (например MyTest2). Добавь сюда правила перегрузки функций: const, &, koenig lookup.

Здравствуйте, FR, Вы писали:

D>>4) когда тебя попросили привести пример заявленных тобой проблем статики, ты привёл пример шаблонов C++.

FR>Который вполне релевантный.

Да не очень то. Проблемы динамики носят системный характер (потеря информации о типах вызвана самой динамикой). Проблемы шаблонов С++ вызваны проектным решением. По сути это ошибка дизайна. Можно было бы выбрать дизайн не приводящий к проблемам.

К тому же в следствии того, что С++ статически-типизированный язык все же получать информацию о типах в шаблонах таки можно. Просто делать это придется в рамках конкретных воплощений. Рефакторинг для С++ так же возможен (и даже имеется кое где), хотя и сложен. Но сложности эти в основном носят вычислительный характер.

D>>5) два C++ника ответили, что шаблоны в C++ — это не статика.

FR>Нет, один из них такого не говорил, ну и плюс я сам C++ник, а ты можешь пока постоять в сторонке.

Да и первый тоже. Вольфхаунд сказал загадочную фразу о нитипизированости типов в С++. Это совсем не то что С++ не типизированн.

На самом деле все встает на свои места когда начинаешь думать о шаблонах С++ не как об обобщенных типах (которыми они являются с большой натяжкой), а как о синтаксическом препроцессоре. Фактически шаблоны не используются как тип. Воплощение шаблона (часто называемое дебильным словом "инстанциация") ни что иное как процесс копирования АСТ шаблона и замена параметров типов на реальные значения. Таким образом речь идет о процессе чуть более вменяемом чем текстуальная подстановка. Такой процесс нормален для метапрограммирования (тех же макросов), но не для системы типов. Отсюда и все проблемы.

Однако воплощенный шаблон — это вполне себе законченный тип в котором можно делать проверки типов.

Вольфхаунд указывает на то, что такие проверки делаются не на самом шаблоне, а на его воплощении, что приводит к тому, что сообщения об ошибках появляются не тогда когда компилируется шаблона, а в совсем в другое время. Зачастую у пользователя шаблона.

Именно это препятствует созданию полноценного рефакторинга для С++. Но все же это усложняет задачу, а не делает ее невозможной. Ну, и слабая типизация, конечно, в следствии которой в С++ спокойно можно обмануть систему типов.

Здравствуйте, alvas, Вы писали:

A>ЗЫ.
A>1. Подскажите, пожалуйста, Программирование на F# Смит К. понятней чем у Сошникова или нет?

Сошникова не читал, Смита сейчас потихоньку читаю, кажется просто и доступно.

A>2. Заинтересовался Lisp — что посоветуете почитать?

http://www.gigamonkeys.com/book/
или перевод http://lisper.ru/pcl/

Здравствуйте, night beast, Вы писали:

NB>ниповеришь. хочу с макросами (желание еще до Н появилось). в луа грамматика жестко забита.

metalua

Здравствуйте, VladD2, Вы писали:

Альтернативные издержки. За то время, пока изучаешь другой язык программирования, можно изучить что-то более полезное.

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

О, не про табы и пробелы, а полрсдна участвует... Вот еще взгляд программиста-маргинала, даже бомжа — мой.

Я раньше вникал в разные языки по делу и из любопытства. Сейчас без необходимости даже не интересуюсь. "Сейчас" многое отличаются от "тогда", но я, наверное, "тогда" этими языками уже объелся.

VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.

Программист — млекопитающее, должное мыслить абстрактно, в том числе обязанное уметь абстрагироваться от синтаксиса. В известных разумных пределах, конечно (не брэйнфак). Синтаксис на выбор должен влиять только при прочих равных. Но в жизни бывает не так, привычка — страшная сила.

VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.

Программировать объектно-ориентированным образом можно на Си и ассемблере. А в итоге все сводится к производительности труда при решении задач. Здесь надо учитывать затраты на изучения языка. Студент, формально выучивший язык в институте, должен на нем отработать годик-другой, чтобы котироваться на рынке труда. А, казалось бы, практические языки — это всего лишь "раствор" для склеивания предметных "кирпичей" (или материал для скульптора — как нравится), не более того.

Можно сказать, что человек, делающий язык, старается переложить свой способ восприятия и мышления на компьютерную реальность (в широком смысле и насколько это возможно: рамки существующих парадигм, за которые автор нового языка не всегда способен/хочет выйти; цели; доступный технический уровень и т.д.). Для успеха автору языка надо, само собой, попасть в какую-нибудь нишу, совпасть с другими в способе конвертации мысли в код, сделать что-то выгодное.

VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".

Вспоминаются, например, дискуссии об использовании NET и java в шароваре. Мне в свое время нравилось "расслабленное" программирование на java, но использовать ее сейчас лично мне негде. Ограничения "политические", думаю, редки, они обычно технические, рациональные. Хотя я сталкивался и с "историко-политическими", когда в одной конторе ту же джаву пихали в каждое отверстие, или когда я был вынужден покодить на Бэйсике из-за чисто политических глупостей. Но это исключения.


VD>Так же интересно что останавливает от применения языков.

Отсутствие необходимости. Также порог вхождения, отсутствие комплексной среды разработки (а среду сейчас в большинстве случаев трудно отделять от языка) и т.д. Нужны веские причины, чтобы использовать новый язык. Я подумаю об изучении нового языка/среды, только если передо мной открывается весомое новое направление, и этот язык обеспечит выигрыш с перспективой (хотя я бомж и скорее выберу другое направление ). А для небольших разовых задач я скорее предпочту погрузиться в новую среду на минимально необходимую глубину, а основную работу сделать знакомым старым не оптимальным инструментом, рассчитывая выиграть в суме.

VD>...

VD>Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

У меня наоборот: С++ я использовать могу, но не изучил, и на строгом экзамене меня можно убить виртуальным деструктором.

п.с.
Имхо, в этой теме кое-что навалено в кучу. Есть промышленные разработки, есть академические. Не обязательно в масштабах ИТ, это может быть в рамках одной фирмы: есть череп, который слабает алгоритм в Матлабе и отдаст кодировать на Си юниорам или еще как-то. В итоге есть массовые языки — промышленные стандарты, а есть "штучные". Массовые, "штучные", академические... — вот это было бы неплохо попытаться разделить, как-то яснее будет.

Массовый язык в основе должен быть понятен дятлу и с минимальной вероятностью приводить к катастрофам. Здесь большая инерция.

п.п.с.
Интересно вспомнить 80-е, когда языки плодились со страшной силой. Это было время новых задач, больших, как запуск Гагарина: языки-всемогуторы; ИИ, базы знаний, компы 5-го поколения; параллельные вычисления и все такое. Потом наступило относительное затишье. Сейчас стало поживее. Вот мне кажется (именно кажется, я на самом деле не знаю), что сейчас это в массе связано с исканиями для промышленного программирования: производительность труда, безопасность... Тоже похоже на космос: уже в основном чистая прагматика, без романтики. Но может, я отстал от жизни.

Здравствуйте, VladD2, Вы писали:

VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Время и интерес. Мне вот что бы попробовать Немерле, надо отложить более интересные для меня вещи. На кой ляд это надо, если у немерла все success истории находятся рядом с компиляторм этого немерла ?

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

Нафиг надо, если С++ уже есть? Зачем изучать "те же яйца в профиль", если они не дают новых возможностей?
Я лучше что-нибудь другое поизучаю ступенькой повыше. Паттерны например. Или что-нибудь связанное с архитектурой.

Здравствуйте, VladD2, Вы писали:

HB>>Исключительно этот пункт. Вообще не выходит изучать что-то "для себя" — вроде и интересно, а "не идёт". Кстати, с обычными языками та же беда: заинтересовался было испанским, почитал, посмотрел, пару песенок перевёл, да и забросил.

VD>ОК, а чтобы могло подвигнуть преодолеть этот пункт?

Наличие хорошо оплачиваемых вакансий — точно могло бы. Хотя... если я сижу на такой же хорошо оплачиваемой и "пишу на дельфе", нафига оно мне надо? В общем, всё это сугубо личное, совокупность собственного любопытства и окружающих обстоятельств. С испанским — хороший пример, я его плюсанул. Отсутствие реальной практики, реальных проектов — и всё, тот же C++ я вообще не помню, хотя когда-то весьма интенсивно на форумах отвечал на вопросы (это было до кывта). Впрочем, нынешний C++ по слухам имеет уже мало общего с тогдашним — всякие Александрески с бустами понародились...

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

Во-первых, меня не интересуют маргинальные языки. Если у него нет своей ниши , и он реально не используется — подожду, когда ниша появится и использоваться будет реально. Изучить язык — много времени не надо, а зря тратить время на него незачем.

Во-вторых, я не люблю моду. Вдруг все набрасываются на что-то. Подождем, когда это нашествие козлотуров придет в какие-то рамки и выяснится, что же получилось. Где сейчас Ада ? А шуму было...

В-третьих, я должен быть уверен, что от этого языка будет для меня польза, то есть использовать его лучше, чем его предшественника. Иными словами, мне нужно быть уверенным, что он мне что-то такое положительное дает, чего в других языках, ранее мне известных, не было. И это не синтаксические конструкции, а нечто реальное.

Здравствуйте, VladD2, Вы писали:

I>>Время и интерес. Мне вот что бы попробовать Немерле, надо отложить более интересные для меня вещи.

VD>А если не секрет, что за более интересные вещи ждут твоего внимания?

Например кое какие планы на WCF, несколько книг (в т.ч. про компиляторы) которые я купил но еще не освоил, продожить Эрланг, который пришлось давненько отложить ради ASP.NET, и Хаскель.

VD>Я слово на Н даже не произносил. Предположим что это J$.

VD>Что до "success истории", то эта тема очень интересна. Ты сейчас на чем программируешь? Что за "success истории" ты слышал об этом средстве?

С#. Когда я начинал его где то в 2003м, C# и менеджед почти не применялся для тех задач, для которых мы его заюзали.

1 был в наличии интерес обусловленный _внятной_ демонстрацией возможностей(а не написанием калькуляторов). Возможности, например, быстрая и качественная разработка UI, легкая интерграция с COM, множество самого различного функционала и самое главное — возможность почти что безболезненного перехода с С++, настолько легкая что вопрос о наборе никогда не стоял — тупо брали почти любых сиплюсников ибо дотнетчиков практически не было.

2 success истории были найдены как в менеджед(Java), а уже позже в C#. Что именно это были за проекты, я точно не понмоню, извини, это был 2003й год. Направление — сапр, проектирование, вычисления.

то же самое было в своё время, когда я занимался Питоном. success история это был конвертер большой базы в xml и обратно при наличии _мизерного_ количества кода, при том, что с++ аналоги лажали на каждом шагу и соджержали в десятки раз больше кода при тех же возможностях.

Когда ты в свое время на право и налево вещал про парадокс Блаба и прочее непотребство, Гапертон написал всего немного сообщений про Эрланг на примере текстового процессора и я пошел смотреть эрланг.

Когда ты в время обвинял AVK чуть не во всех грехах по поводу http://www.gotdotnet.ru/blogs/avk/931/, C# 3.5 после Питона казался мне скучной, глупой и никому не нужной поделкой, и я увидел вот это — http://www.gotdotnet.ru/blogs/avk/925/

Хаскел заинтересовал в одном из сообщений на этом форуме, опять там же где ты "отметился"

Здравствуйте, VladD2, Вы писали:

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

1. Традиции предметной области.
Занимаюсь компьютерным зрением, большая часть библиотек на С/С++. Меньше на Матлабе. Совсем немного — Фортран. У многих есть биндинги к другим языкам, но они не так удобны, например при отладке. Например, пытался использовать OpenCV из Питона — не пошло.

2. Плюшки от более глубокого изучения предметной области.
Хочется изучить ещё этот алгоритм, посмотреть тот, а вот в новой статье написано так... Для меня эти знания важнее, чем языки.
Следствие. Время на кодирование гораздо меньше времени разработки алгоритмов. Ну и зачем мне тогда более удобный язык?

3. Быстродействие.
Не все языки (но многие) позволят мне достичь необходимой скорости выполнения программ.

4. Цена.
Увы! Хотелось бы работать с Матлабом — он очень удобен. Но дорогой, блин. Если контора ещё потянет, то я дома с ним работать не смогу.

P.S. Пользуюсь в основном связкой C++/CUDA/Lua

Здравствуйте, x-code, Вы писали:

XC>Это то, что следовало бы сделать, когда принимали новый стандарт С++: не впихивать кучу костылей в существующий cpp, а просто взять и сделать новое расширение cppx с ДРУГИМ синтаксисом, не ограниченным совмесиммостью со старым, и просто сказать: вот он, новый стандарт.
Ну и пошли бы они лесом. Как метры уже имеющегося кода переводить на новый стандарт? Выносить куски кода в отдельные файлы? В топку!

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, ausergiy, Вы писали:

A>>появится задача, за которую заплатят деньги, буду учить язык. Не появится, значит не надо. Даже если потратишь время и выучишь, работодателя потом не убедишь что язык знаешь, но опыта не имеешь.

VD>То есть изучать что-то новое для саморазвития не нужно?

ну не все же подряд языки же программирования. это как молотки изучать — примерно также интересно. Обычно это и делают, или по молодости, от соответствующего энтузиазма, или в силу производственной необходимости...

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, dimgel, Вы писали:

D>>То есть, ты предлагаешь мне убить пару-тройку лет на какие-нибудь динамически типизированные языки, чтобы убедиться, что все те помои, которые вы с WolfHound-ом на них выливаете, заслуженные? Гы, сорри, но это как раз тот случай, когда я предпочту поучиться на чужом опыте. Вполне, так сказать, доверяю.

D>Тем более, что помои аргументированные. А сам играясь с языком, я к этим же аргументам никогда, может быть, и не приду. Так и буду "писать на дельфе".

Очень большей частью как раз не аргументированные и Влад и WolfHound чистые теоретики и не имеют мало мальского опыта писания на этих языках.

Здравствуйте, alpha21264, Вы писали:

DR>>В языках с поддержкой метапрограммирования, вроде Немерле, макрос оперирует не текстом, а языковыми конструкциями.

A>Это как?

Оперирует уже распарсеным текстом обычно в виде AST

Есть даже препроцессоры, но не текстовые как в Си/С++ а синтаксические например http://en.wikipedia.org/wiki/Camlp4
которые также оперируют AST.

Здравствуйте, robin_of_the_wood, Вы писали:

___>Перед тем, как начать применять новый язык(новое средство), его надо выучить(освоить). Нет можно и по другому но лучше не надо
___>Перед тем, как начать изучать новый язык, люди обычно думают на тему "А действительно ли проблема в языке(средстве)?"

Корректный ответ на этот вопрос можно дать только зная язык.
Далее — см. парадокс Блаба.

Здравствуйте, WolfHound, Вы писали:

WH>Ну то есть притензий к озвеченным фактам нет.

Смысла нет в тысячный раз абсолютно бесполезно ругаться.

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, WolfHound, Вы писали:

WH>>1)А чем 2008 не устраивает?
A>тем что у меня есть 2010 и я нехочу ставить еще и 2008.

Поставь Visual Studio Isolated Shell, хотя точно не знаю работает ли с ним Немерл.

Здравствуйте, Lloyd, Вы писали:

___>>Перед тем, как начать изучать новый язык, люди обычно думают на тему "А действительно ли проблема в языке(средстве)?"

L>Корректный ответ на этот вопрос можно дать только зная язык.
L>Далее — см. парадокс Блаба.

Да я согласен с этим.
И может даже корректность этого ответа не так и важна.
Главное чтобы не получилось что человек писал плохой код на одном языке а теперь пишет
плохой код на другом языке, более мощном.

Здравствуйте, Lloyd, Вы писали:

L>Понятий "хорошо" и "плохо", имхо, не существует. Зато есть "лучше" и "хуже", для употребления которых уже и нужно зныние иных языков.

И что эта игра словами изменила? Если думать не в терминах языка, а в терминах решаемой задачи, то становится видно можно ли найденное решение записать лучшим образом по сравнению с записью в используемом языке. Знать другие языки для этого не требуется. Вот если видишь, что решение можно было записать лучше, но язык не позволил, тогда да возникает вопрос, а существуют ли языки, в которых нужная тебе запись доступна. И вот только для ответа на этот вопрос требуется знание других языков.

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Отсутствие смысла в изучении языка ради изучения языка.

Здравствуйте, FR, Вы писали:

D>>Вот тут мне не надо ляля. Я читаю флеймы достаточно подробно. Не все и не всегда, но тем не менее. С аргументацией у немерлистов всё гораздо лучше, чем у их оппонентов, чьи аргументы сводятся к "не читал но осуждаю", ноль конструктива. Да ты хоть эту ветку перечитай. Половина спорщиков даже примерно не представляет, что такое макросы в N.

FR>Для них обоих современные динамические языки именно "не читал но осуждаю" теоретики они.
FR>У меня самого было очень похожее мнение насчет динамики, изменилось оно только через полгода программирования на питоне.

Как тебе уже ответил WolfHound, в твоих ответах отсутствуют конкретные возражения по конкретным претензиям к динамике. Чистое бла-бла-бла. Сам я не знаю питона, но я знаю PHP и скалу, и я вполне могу экстраполировать свой опыт со слабо-динамически-типизированным языком на сильно-, тем более, что это будет по сути не экстра- а интерполяция (там с другого конца скала подпирает). То есть, я знаю достаточно, чтобы квалифицированно оценивать аргументы обоих сторон. Ты — сторона спора. Я — посторонний наблюдатель. "В споре рождается истина" — это, конечно, полная брехня, но одно исключение я таки-обнаружил: в позиции постороннего наблюдателя картина максимально полная, учитывающая аргументы всех сторон. Это касается не только статики-динамики, но и rich-anemic, к примеру, и всех остальных срачей. Ну а ты, если тебе так охота защищать динамику, — так защищай её, продумывай ответы на аргументы твоих оппонентов. Наезды на их квалификацию — это не аргументы, а переход на личности. Доказывающий кстати, что твоя квалификация ниже, раз тебя не хватает на аргументы должного уровня.

Здравствуйте, dimgel, Вы писали:

D>Является ли сильная типизация по сравнению со слабой преимуществом при автоматическом рефакторинге, если оба языка динамически типизированные? Я склонен считать, что нет, т.к. ошибка типов в любом случае вылетит в рантайме, IDE никакой помощи тут не предоставит. Если так, то это ключевая претензия, и она ни на йоту не гипертрофированная: её значение переоценить невозможно. Как по мне, невозможность быстро и надёжно (без необходимости писать тонну юнит тестов) рефакторить код — это приговор языку. На любом хоть сколько-нибудь крупном проекте рефакторинг будет выливаться в такой геморрой, что проще повеситься. "Отвинтили пупок — отвалилась задница." Всё остальное я перетерплю, но когда рефакторинг кода похож на хождение по минному полю, когда на каждый чих типа переименования метода приходится вручную шерстить весь проект глобальным поиском, потом смотреть, что из найденного относится к нашему классу, а что не относится (а в отсутствие информации о типах приходится анализировать логику, иногда глубоко), а потом молиться, чтобы где-нибудь не упала завязанная на рефлексии динамика, конструирующая имя вызываемого метода так, что он не нашёлся поиском... это ад, в общем. Огромное количество временных затрат на ровном месте. Вот реальная проблема. А что в рантайме я не смогу присвоить числовой переменной строку — мне глубоко пофиг, я уже привык assert-ами по коду разбрасываться, они неплохо компенсируют слабую типизацию.

Рефакторинг это поведение IDE, а не свойство языка. Си++ типизирован и кому это помогло?

Здравствуйте, MxMsk, Вы писали:

U>>Плохой пример. Для меня первый вариант проще, чем второй. В простых случаях (таких как приведенный) это не заметно, но очень хорошо видно в случаях сложных.
MM>Чем первый вариант проще?

Насчет проще на таком простом примере видно не будет. Но в этом случае код примерно одинаков по сложности, т.к. содержит равное количество сущностей. В обоих вариантах есть и пробег по коллекции, и условие, и обработка условия. Разница лишь в лаконичности, т.к. во втором случае пробег по коллекции спрятан внутрь функции.

А вот в примере со string.Join: http://rsdn.ru/forum/philosophy/4246608.1.aspx

Автор: Undying
Дата: 23.04.11

разница именно в количестве сущностей, стандартный Join заставляет создавать промежуточную коллекцию строк, которая по условию задачи не требуется.

Необходимость создания лишних сущностей является главным признаком того, что на данном языке эта задача записывается плохо.

Здравствуйте, adontz, Вы писали:

U>>Также объясни сколько языков нужно знать для того, чтобы понять, что даже в C# 1.0 можно было написать функцию: string MyJoin(string separator, string format, IEnumerable items), которая позволила бы избавиться от мусорного кода, хотя бы в простых (но очень распространенных) случаях?
A>

A>    public static string Join(string separator, IEnumerable<string> values);
A>

Это в каком шарпе появилось? Очевидно, что не в 1.0 и вроде даже не в 2.0.

Здравствуйте, FR, Вы писали:

WH>>Тесты гонять?
FR>Да.
WH>>А где гарантия, что покрытие 100%?
FR>100% гарантии теперь даже в банках не дают.

Демагогия detected. Система типов именно что даёт математически доказанные гарантии.

FR>В данном случае да статика(вернее ее подмножество) рулит.

А ещё рулит компилятор, ага, который выполнит анализ без необходимости деплоймента и запуска приложения (иногда дорогостоящего) и кликанья по менюшкам, чтобы добраться до загрузки проверяемого модуля.

Здравствуйте, FR, Вы писали:

FR>>>Юнит тесты в динамике да необходимы, но не тонны, их размер будет вполне сопоставим с размером оных для статики.

D>>Гыгы, нуну. -1.

FR>В статике они тоже необходимы, если пишется хоть что-то более-менее серьезное.

В статике я тестирую логику, и только логику. Там, где эта логика достаточно сложна и устойчива, где написание и поддержание актуальности тестов выгоднее, чем тыкаться вручную. Мне не нужно писать тесты на всё подряд только ради возможности безболезненно отрефакторить, и кроме того, при рефакторингах тесты будут зацеплены по необходимости (вследствии ругани компилятора). И таким образом не только количество, но и сложность поддержания юнит тестов в статике ниже.

FR>>>Тесты в этом вполне рулят.
D>>Пишите, Шура, пишите, они золотые.
FR>Жаль, мне ты казался более вменяемым

Ну, сорри, что разочаровал. Я не спец по языкам и компиляторам, но зато я практик, гы, в отличие от этих "теоретиков" Влада и WolfHound-а.

Здравствуйте, FR, Вы писали:

FR>Чуть выше показали на шаблонах C++.
Показывать на С++ и говорить что статика говно это демагогия.
Ибо С++ сам по себе гора страшных костылей.

Здравствуйте, WolfHound, Вы писали:

NB>>ты ведь понимаешь, что никто в нормальном здравии так писать не будет.
WH>Почему?
WH>В C# пишут.
WH>В хаскеле пишут.
WH>Почему на С++ не будут?

весь интерфейс используемый в функции переписывают?
этож застрелиться можно.
я думал это си — многословный язык, ан нет.

Здравствуйте, FR, Вы писали:

WH>>Ну так где аргументы то?
WH>>Есть только один: Меньше кода.
WH>>Но это по сравнению с жабой меньше. А по сравнению с немерле экономии почти нет.
WH>>А какие еще? Ну, хоть один.

FR>Практика.

Это демагогия, а не аргументы. Практика у всех своя. Практика дельфистов говорит, что дельфи — самый лучший из языков. Практика PHP-ников с восемью классами среднего образования говорит, что на PHP можно написать всё что угодно. Аргументы-то где?

Здравствуйте, dimgel, Вы писали:

FR>>Практика.

D>Это демагогия, а не аргументы. Практика у всех своя. Практика дельфистов говорит, что дельфи — самый лучший из языков. Практика PHP-ников с восемью классами среднего образования говорит, что на PHP можно написать всё что угодно. Аргументы-то где?

Я не верю в существование лучшего языка у всех реальных языков полно недостатков.
Практика не демагогия, а очень толстый и жирный аргумент, если язык живет и долгое время популярен, на нем выпускаются
вполне успешные проекты, то это железно доказывает его нужность при всех его недостатках, если этого не видят поклонники
одного очень крутого, но пока (хотя при таких фанатах может и навсегда ) не практичного языка то это их проблемы.

Здравствуйте, dimgel, Вы писали:

FR>>Нет, а вот твой тупой переход на личности мне очень не нравится, хотелось бы чтобы модераторы придерживались такого же мнения.
FR>>Ладно бы еще тонко тролил

D>Я не тролю, я общаюсь с фанатиком, неспособным аргументировать свою точку зрения. А переход на личности начал ты, я лишь его проявил.

Прикольно я тоже общаюсь с фанатиком.
Теоретизм наших уважаемых модераторов в динамике это не переход на личности а факт.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, adontz, Вы писали:
A>>Тебе есть что сказать по существу? Я где-то не прав?

WH>Так я вроде по существу и сказал.
WH>Что не ясно?

Девочки, не ссорьтесь.

Здравствуйте, WolfHound, Вы писали:

NB>>генерики могут быть без констрейнтов?
WH>Могут.
WH>Но тогда нельзя методы вызывать.

ок. позицию понял.
с концептами так не получится (иначе старый код перестанет компилироваться)

Здравствуйте, dimgel, Вы писали:

D>ИМХО эти вещи до некотороый степени взаимосвязаны. Там где я в ФП могу написать `val strings = ints.map(_.toStrings)`, на императивном языке я буду вынужден корёжиться с циклом (сорри, вы тут неподалёку что-то похожее в тему обсуждали, но мне в вашу тему вчитываться лениво). И сущностей меньше, и букв.

Это должен быть совсем ограниченный "жестко-императивный" язык, типа Джавы или Паскаля. На любом более-менее универсальном языке, например C# или С++, это делается примерно в такой же записи, +- несколько букв.

Джава — это вообще приговор мозгам. По фичам уступает даже до-дотнетному VB (за исключением поддержки наследования реализаций). Переносил как-то после появления дотнета несколько прог с Джавы на C#, исходники получались в 2-3 раза меньше, бо весь этот мусор из листенеров и самописных итераторов шел лесом, и становилось гораздо чище.

у нас мс платформа, зоопарк не нужен