Что вас останавливает от изучения нового языка? - Философия программирования

Здравствуйте, 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. Вот здесь есть изолированный пример уже переведенный в классическую форму для ООЯ. Можешь разы сам посчитать. Если брать полный компилятор, то по моим прикидкам выходит где-то раз в 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>В общем, подкинь что-нить посущественнее, что ли...

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

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

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

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

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

2 Ziaw: Ты попался на наукоподобный бред ламера. Он и представления не имеет о платформе реализации, а лезет с умными мыслями.

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

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

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

A>А что где-то есть библиотека реализации паттернов на Немерле?

А как же?
Прямо в стандартной библиотеке. Вот здесь есть описание.

A>Пока что, то что я вижу, это 6 маленьких библиотечек макросов на nemerle.org и какая-то масса разрозненного кода на google code. А солидной, готовой для использования, хорошо документированной библиотеки я не вижу.

Плохо смотришь.

A>Или предлагается самому писать себе макросы на каждый конкретный случай?

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

A>Макросы — это, конечно, круто и все дела.

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

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

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

A>Вот тогда-то Немерле и будет представлять существенный интерес. А пока это просто хобби для тех, кому интересно возиться с макросами.

Пока что кто-то плохо пользуется поиском по сайту. Вот автоматизацию паттернов не нашел и возмущается

.

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

Библиотеки ты тоже ждешь когда за тебя напишут?

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

V>Ты бы обратил, вообще-то, внимание на две последние приведенные публикации. Они ключевые на сегодня в теории типов. В предпоследней, наконец, классифицируются способы типизации и отношения м/у ними и показано место, к примеру, зависимых типов в т.н. Barendregt's Lambda Cube

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

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

Потом меня все эти теоритические рботы просто радуют. Куча заумностей на ровном месте. В реальных компиляторах вся эта псевдонаучная хрень не использутся.

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

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

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

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

Z>>А чем должна отличаться реализация для нерекурсивных?

V>Инлайнится по-возможности, т.е. не создаваться на куче. Участвовать в распространении констант без всяких динамических проверок дискриминатора (т.е. типа объекта). Наиболее естественно — сделать как дотнетный value-type и агрессивно оптимизировать, как в Хаскеле.

Зачем говорить о том в чем плохо разбираешься?

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

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

Здравствуйте, 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-ля без внешних зависимостей. Сравнил так уж сравнил.

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

V>>Инлайнится по-возможности, т.е. не создаваться на куче. Участвовать в распространении констант без всяких динамических проверок дискриминатора (т.е. типа объекта). Наиболее естественно — сделать как дотнетный value-type и агрессивно оптимизировать, как в Хаскеле.

VD>Зачем говорить о том в чем плохо разбираешься?

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

VD>Создай тестовый проект на Шарпе и попробуй сэмулировать свое решение. Тебе ждет огромное разочарование.

Да сделано давно discriminated union для компилятора IIOP.Net.

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

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

Сама платформа доставляет неудобств. В Хаскеле размеченное объединение может перекрывать свои адреса, в дотнете это можно только для bool и чисел, а ссылки должны стоять где-то сбоку. Т.е. вопрос упаковки и смещений полей не последний. Но и это решаемо. К тому же, полно сценариев, где все варианты довольно простые и не содержат ссылочных полей. Уж их-то точно можно было выразить через value-type.

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

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

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

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

Ну и кто тут лам? Вопрос непротиворечивой упаковки полей уже нерешаемый?

VD>Этот "проффесор" таких деталей не знает, но суется рассуждать о высших материях.

С каких пор задача рассовать три шара по двум корзинам перекочевала в высшие материи?

Влад, не позорься. Попробуй, и увидишь, как все просто.

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

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

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

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

V>Сама платформа доставляет неудобств. В Хаскеле размеченное объединение может перекрывать свои адреса, в дотнете это можно только для bool и чисел, а ссылки должны стоять где-то сбоку. Т.е. вопрос упаковки и смещений полей не последний. Но и это решаемо. К тому же, полно сценариев, где все варианты довольно простые и не содержат ссылочных полей. Уж их-то точно можно было выразить через value-type.

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

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

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

Вот этот куб — это и есть пальцы.

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

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

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

VD>2 Ziaw: Ты попался на наукоподобный бред ламера. Он и представления не имеет о платформе реализации, а лезет с умными мыслями.

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

Здравствуйте, 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.

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

VD>Пока что кто-то плохо пользуется поиском по сайту. Вот автоматизацию паттернов не нашел и возмущается

.

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

И поверь мне, макросы никто писать не хочет. Использовать готовые — пожалуйста. На это и нужно давить. Создавать библиотеку макросов общего назначения для облегчения написания кода, который обычно доставляет сложности (например в C#). Без такой библиотеки Немерле — не более чем еще один функциональный язык со странным синтаксисом.

PS: зашёл на сайт Boo недавно. Захотелось что-нибудь на нём написать. С чего бы это?

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

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

A>>А что где-то есть библиотека реализации паттернов на Немерле?

VD>А как же?
VD>Прямо в стандартной библиотеке. Вот здесь есть описание.

Это скорее статья на тему "смотрите какие в принципе есть возможности". Но никак не готовая к использованию библиотека.

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

V>Ну, давай разбираться подробней, если готов.

Не, ну, давай. А сначала разбирайся, а потом выноси суждения о спешке в реализации.
Направление исследований я тебе обозначил. Дерзай.

VD>>Создай тестовый проект на Шарпе и попробуй сэмулировать свое решение. Тебе ждет огромное разочарование.

V>Да сделано давно discriminated union для компилятора IIOP.Net.

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

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

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

Стек тоже не бесплатен. А совмещать поля в дотнете нельзя. Любая грязь в ссылочном поле прведет к падению ЖЦ.

V>Сама платформа доставляет неудобств. В Хаскеле размеченное объединение может перекрывать свои адреса, в дотнете это можно только для bool и чисел, а ссылки должны стоять где-то сбоку.

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

V>Т.е. вопрос упаковки и смещений полей не последний. Но и это решаемо.

Не решаемого это. Точнее решения получаются хуже оригинального.

К тому же сам по себе АлгТД в МЛ-языках имеет ссылочную семантику (размещается в куче).

V>К тому же, полно сценариев, где все варианты довольно простые и не содержат ссылочных полей. Уж их-то точно можно было выразить через value-type.

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

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

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

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

	От:	vdimas
	Дата:	25.04.11 01:56
	Оценка:

	От:	vdimas
	Дата:	25.04.11 02:00
	Оценка:	-1

От:	VladD2	www.nemerle.org
Дата:	25.04.11 02:03
Оценка:	-1

От:	VladD2	www.nemerle.org
Дата:	25.04.11 02:11
Оценка:

От:	VladD2	www.nemerle.org
Дата:	25.04.11 02:20
Оценка: