Здравствуйте, Mystic, Вы писали:
AS>>У меня _ВСЕ_ задачи такого рода =) Большую часть времени я думаю, читаю, ковыряю отладчик и пишу маленькие но хитрые скрипты на питоне. Давно уже понял — пока я не знаю что именно я собираюсь делать, код писать бессмысленно. M>У меня часто наоборот бывает. Начинаешь писать код, понимаешь, что собираешься сделать. А иначе можно до конца века видеть и размышлять, а всего в голове не удержишь
И чего пишешь когда начинаешь, если не понимаешь чего собираешся делать?! ИМХО, не надо всё в голове держать, ты же не всё за раз пишешь, а по кусочкам. В голове только этот кусочек и общая (текущая) картина того что должно получится и где этот кусочек в ней находится. В моём понимании программирование чего либо сложнее helloworld в принципе есть циклическое и кусочное прототипирование желаемого. Собственно принципильное отличие между моей точкой зрения и позицией топик-стартера, прототипировать надо части живой софтины или отдельные минималистические кейсы, возможно вообще на другом языкеи и в другом окружении. И такой прототип вполне себе рабочая часть этого 'организма', требующая переработки только когда не справляется с меняющимеся требованиями.
Просто не надо пытаться написать совершенный код, который разве что кофе в постель не приносит =) Программы надо не 'строить' их надо 'выращивать' =)))
Однако, нельзя просто сесть и начать писать какие-то конструкции языка. Сначала надо создать в голове хоть какую-то модель решения задачи и только после этого попробовать её реализовать. Иначе это не программирование, а какое-то рифмоплётство получается.
Ну да, скоко-то лет тому назад я именно так и писал (от пальцев), но не от эффективности метода, а от пустой головы. Потом мне мозги вправили и через несколько лет я перистал заниматься таким творчеством. =)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, мыщъх, Вы писали:
М>>я бы еще добавил -- прототип должен быть максимально гибким. в частности, сейчас я пишу высокоскоростной парсер, работающий с битыми входными данными by design. и пишу его... на 90% на регулярках. VD>Жуть! Я бы в таком даже побоялся бы признаться. В прочем я бы таким и заниматься не стал бы.
в общем не такая уж и жуть. 73 мегабайта парсятся на питоне с регулярками за пару минут на тормозном ноуте. я не совсем двинутый, чтобы писать парсер _полностью_ на регулярках.
основная сложность задачи даже не распарсить битый скрипт (это как раз как два байта переслать), сложнее реконструировать (насколько это возможно) отсутствующий код. вот допустим, у вас есть нечто вида data = foo(a,b,c), причем foo не библиотечная функция и она физически отсутствует, но мы можем проанализировать происхождение аргументов и что делается с возвращаемым значением, автоматически заменяя функцию foo тем, что она предположительно делает.
вопрос: какие у нас шансы на удачу? стоит ли игра свеч? какие общие закономерности "побитости" прослеживаются во входных данных? теоритически на этот вопрос ответить невозможно, т.к. нужно смотреть реальный характер повреждений, а чем его смотреть? гигабайты данных ведь не перелопатишь руками...
поигравшись с разными моделями, пришел к выводу, что в 30% случаев все можно угадать тупым набором заранее сгенерированных правил. но 30% это неинтересно и потому играюсь дальше. в принципе, гадать можно достаточно долго (для начала в off-line). если скрипт выдаст осмысленный результат -- значит, мы угадали. ну а нет, так нет.
VD>Руками? А почитать что-нить по теме парсеров не пробовал для начала? Не все задачи берутся методом замучивания.
читаю книгу дракона (второе издание, ценую в сто баксов). а что вы еще можете порекомендовать? существующие инструменты крайне плохо подходят для решения данной задачи. ну вот например:
понятно, что тут имеет место быть выпавший фрагмент. read() уже как бы наводит на мысли. а return data позволяет предположить, что это было data = f.read(); есть так же вероятность, что val это имя файла, которое нужно открыть.
сейчас я все это могу распарсить на регулярках, т.е. понять, что 'olla-la-shit-happens' это одно, а f.read это уже другое. именно f.read, а не happensf.read, т.к. дальше идет f.close.
ну вот чем такое парсить-то? что из готовых инструментов вы посоветуете? у меня токенизация делается по списку ключевых слов. в первом проходе это будет read, close, return. во втором проходе мы накладываем шаблон, специфичный для каждого ключевого слова и выделяем val, f, data. в третьем проходе мы с учетом знания о поведении каждого "токена" строим "смысловые" связи и зависимости по данным. val -> ???, f <-- open(???), read() -> ?resilt?, return data, ?result?.
на финальном проходе мы выдвигаем предположение о возможной связи val и open, а так же read и return. в данном случае у нас только одна комбинация подходящая по смыслу. и дальше мы смотрим кто вызываем foo, какие аргументы ей передают и как используют ее данные.
VD>Парсить регулярками — это из серии вырезать гланды через жопу автогеном.
это верно. но... пока остановился на таком варианте, т.к. он позволяет менять логику работы парсера на лету.
VD>В общем, мой тебе совет. Возьми подходящий инструмент и сделай свой прототип. Подходящий VD>интсрумент тут — это генератор парсеров. Я бы посоветовал бы взять наш Nemerle.Peg. Он грамматики любой сложности возьмет.
у нас половина людей под никсами, вторая половина под маками. код им понимать необязательно, но он у них должен по крайней мере работать. я не в курсе как у вас с кросс-платформенностью. под линухом заведется?
и дело тут не в сложности грамматики. это JavaScript, VBS. под JS есть готовые парсеры/грамматики/whatever, но нету таких, которые бы отвечали условиям задачи (как в примере выше, который _очень_ типичный пример).
> Ну, а "битые входные данные" это ни что иное как более сложные грамматики. И PEG тут будет самым подходящим инструментом. > В прочем, любой генератор парсеров будет лучше чем регулярки или ручное написание парсера.
подскажите, пожалуйста, а то я уже мозг сломал -- как какому-нибудь стандартному генератору парсеров объяснить, что строка может не закрываться кавычкой или начинаться не с кавычки (т.е. ello, world\n'; var a = 'AAA'; ). парсить "по науке" у меня не получается. ну не знаю я как описать такую грамматику, а потому сначала выделяю ключевые слова ("ключевые" в смысле словарные), а уже отталкиваясь от них бью текст на токены, но это разбивка предположительная, и там приходится искать лучшее соответствие. я стрю семантическое дерево (если я правильно его называю), в котором токены связаны во всех комбинациях, которые допускаются заранее заданными правилами и ищется самый длинный маршрут в дереве.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, VladD2, Вы писали:
VD>Ткнул на ссылки и увидел вполне вменяемые ответы. Может не хотел увидеть?
Нет, там ответы из серии "если такие задачи сложно решать с ФП-подходом — значит, мейнстрим отстой и надо от него отказаться". Напомню, исходный топик лежал не в философии и был посвящён конкретной проблеме на конкретной платформе. Соответственно, я ожидал практически применимых советов, не нарушающих FDG.
Если последовать совету ув. WolfHound, перейти к immutable спискам и хранить копии списков для undo-redo, как быть с биндингом, с вычислением изменений, с уведомлением об изменениях (они нужны как минимум для ограничений)?
Нам придётся имитировать поведение BindingList|ObservableCollection, и весь выигрыш от первоначальной идеи уйдёт на допиливание обёрток. Я не просто так, абстрактно говорю — я делал вполне рабочий прототип и делал замеры. В таком виде идея не взлетит.
Здравствуйте, Alexéy Sudáchen, Вы писали:
AS>Здравствуйте, Mystic, Вы писали:
AS>>>У меня _ВСЕ_ задачи такого рода =) Большую часть времени я думаю, читаю, ковыряю отладчик и пишу маленькие но хитрые скрипты на питоне. Давно уже понял — пока я не знаю что именно я собираюсь делать, код писать бессмысленно. M>>У меня часто наоборот бывает. Начинаешь писать код, понимаешь, что собираешься сделать. А иначе можно до конца века видеть и размышлять, а всего в голове не удержишь
AS>И чего пишешь когда начинаешь, если не понимаешь чего собираешся делать?!
А шо делать? Ждать, пока "понимание" спустится свыше?
AS>ИМХО, не надо всё в голове держать, ты же не всё за раз пишешь, а по кусочкам.
Не всегда выполнимо. Например, я разрабатываю алгоритм, который должен правильно работать для различных типовых задач (их около десятка). Всякое изменение алгоритма для одной типовой задачи затрагивает остальные девять. В ряде случаев я даже затрудняюсь, что надо вернуть. А есть еще куча случаев, о которых я вообще не подумал, их еще надо обнаружить. Для начала мне надо исследовать проблему, вот я и делаю шаг влево, шаг вправо. Пробую что-то писать и вижу: тут возникает такая вот нестыковка. Ага, надо придумать что-то другое...
Да, я пишу кусочками, но это не част общей мозаики, а скорее блуждание по лабиринту.
На мой взгляд есть всего один способ писать сложный код — продумать как и что делать, а потом сесть и написать.
Прототипирование решает всего одну проблему — устраняет неопределенность. Имея грамотно сделанный прототип можно отбросить гадания и выбрать правильный результат.
Но в любом случае для решения сложных задач намного важнее две вещи:
1. Продуманный план (который может видоизменяться в процессе разработки в виду появления новых данных).
2. Вол и упорство.
Очень советую почитать статью IT о видах сложностей. Ты явно не читал ее, или читал по диагонали. Если прочесть ее внимательно, то можно заметить, что твой вопрос сформулирован не верно. Сложности бывают разными. И их можно трансформировать. Так вот есть задачи сложность которых заключается в объемах. А есть те чья сложность заключается в интеллектуальной составляющей. И последний вид проблем не решить качественно без пополнения собственных знаний.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>На мой взгляд есть всего один способ писать сложный код — продумать как и что делать, а потом сесть и написать.
Ок, как быть, когда _детально_ придумать что и как делать на порядки сложнее/дороже по времени, чем просто написать код? Когда известна архитектура, известно, как (примерно) будет выглядеть API, но сам код можно написать несколькими способами?
Я ведь уже приводил кучу примеров, когда попытки решить задачу с наскока сваливались в перебор всего дерева вариантов. Дошли до аргументации в духе "а нафига мейнстрим, если в нём не работает ФП-подход?".
На конкретный вопрос (несколько раз ведь спрашивал) ни вы, ни WolfHound не ответили, предпочитая К.О. — утверждения
Но в любом случае для решения сложных задач намного важнее две вещи:
1. Продуманный план (который может видоизменяться в процессе разработки в виду появления новых данных).
2. Вол и упорство.
и лёгкие наезды аля
Очень советую почитать статью IT о видах сложностей. Ты явно не читал ее, или читал по диагонали.
Задача весьма странная. Интересно откуда у нее растут ноги? Что ломает эти скрипты?
VD>>Руками? А почитать что-нить по теме парсеров не пробовал для начала? Не все задачи берутся методом замучивания. М>читаю книгу дракона (второе издание, ценую в сто баксов).
Это бесполезное занятие. Особенно если это русский вариант (перевод). Книга сильно устарела и не содержит передовых подходов.
М>а что вы еще можете порекомендовать?
Давай лучше на ты.
М>существующие инструменты крайне плохо подходят для решения данной задачи. ну вот например:
М>foo(val){a='olla-la-shit-happensf.read();f.close();return data;}.
М>понятно, что тут имеет место быть выпавший фрагмент. read() уже как бы наводит на мысли. а return data позволяет предположить, что это было data = f.read(); есть так же вероятность, что val это имя файла, которое нужно открыть.
М>сейчас я все это могу распарсить на регулярках, т.е. понять, что 'olla-la-shit-happens' это одно, а f.read это уже другое. именно f.read, а не happensf.read, т.к. дальше идет f.close.
В твое задаче просто напрашивается:
1. Применение PEG-а для распознавания битых последовательностей. Откаты тут просто серебряная пуля. Ты просто перечисляешь список возможных несуразностей в грамматике, а парсер будет планомерно подбирать подходящий вариант.
2. Преобразование результата парсирга в очень вольный AST с последующим анализом его с помощью сопоставления с образцом.
Задача бьется на две подзадачи:
1. Распознавание кода с учетом возможных повреждений.
2. Анализ поврежденного кода с применением шаблонов выявляющих характерные ошибки.
М>ну вот чем такое парсить-то?
Однозначно PEG-ом!
М>что из готовых инструментов вы посоветуете? у меня токенизация делается по списку ключевых слов. в первом проходе это будет read, close, return.
PEG позволяет избавиться от стадии лексического разбора, что позволит тебе выявлять и битые последовательности. Скажем не закрытую строку или сросшиеся литералы.
М> во втором проходе мы накладываем шаблон, специфичный для каждого ключевого слова и выделяем val, f, data.
Стадии у тебя должны быть такими:
1. Парсинг в алгебраические типы данных. Причем формат АлгТД должен быть таким чтобы учитывать возможность хранения битых последовательностей. Их можно по ходу дела наращивать.
2. Рекурсивный анализ полученной иерархии с использованием паттерн-матчинга (ПМ). ПМ позволит выявлять сразу паттерны, а не возиться с набором унылых if-ов.
М>в третьем проходе мы с учетом знания о поведении каждого "токена" строим "смысловые" связи и зависимости по данным. val -> ???, f <-- open(???), read() -> ?resilt?, return data, ?result?.
Вот это все можно записать в один шаблон. И тогда выявление подобных последовательностей станет банальным занятием. Ну, а уж дальше ты сможешь применить свои эвристики чтобы догадаться, что же пропущено.
VD>>Парсить регулярками — это из серии вырезать гланды через жопу автогеном. М>это верно. но... пока остановился на таком варианте, т.к. он позволяет менять логику работы парсера на лету.
А зачем тут что-то делать на лету? Пойми, твоя задача не решается перебором. Тут нужно применять интеллект. Так что очень советую сменить стратегию.
VD>>В общем, мой тебе совет. Возьми подходящий инструмент и сделай свой прототип. Подходящий VD>>интсрумент тут — это генератор парсеров. Я бы посоветовал бы взять наш Nemerle.Peg. Он грамматики любой сложности возьмет. М>у нас половина людей под никсами, вторая половина под маками. код им понимать необязательно, но он у них должен по крайней мере работать. я не в курсе как у вас с кросс-платформенностью. под линухом заведется?
Во-первых, немерл, а стало быть и Nemerle.Peg прекрасно живут под Моно, а значит под Линуксом и Маком.
Во-вторых, ты же говоришь о прототипе. А его по фигу на чем писать. Ты должен только отработать идею и выявить то, что пока что скрыто от твоего взора. Так вот сделать это с PEG-ом, АлгТД (ака в немерле называются вариантами) и паттерн-матчингом будет в сто раз проще (я даже не преувеличиваю). Ну, а потом можешь это дело хоть на С переписать. У тебя уже будет понимание того как проблему нужно решать. Следовательно сложность уже будет другого порядка. Если переписывание окажется слишком сложным (что не мудрено, так как в языках где не доступен МП кода будет раз в 5 больше), то можно просто сгенерировать С-ишных код по типизированному представлению который тебе выдаст компилятор немерла.
М>и дело тут не в сложности грамматики. это JavaScript, VBS. под JS есть готовые парсеры/грамматики/whatever, но нету таких, которые бы отвечали условиям задачи (как в примере выше, который _очень_ типичный пример).
Я это прекрасно понимаю. Могу тебе привести в качестве примера похожей задачи написанные мной XML-литералы. Это собственно встроенный в язык XML, но со "вставками". Причем вставками кода. При этом грамматика ХМЛ-я не катит, так как вставки ее сильно расширяют. Соответственно невозможно использовать готовые парсеры ХМЛ-я. Но написать грамматику ХМЛ-я не составило труда, так как PEG очень мощный формализм.
Кстати, PEG очень похож на регулярные выражения. Так что если есть опыт работы с регулярками, но нет опыта работы с герераторами парсеров, то это еще один повод воспользоваться пегом.
Кстати, грамматика JavaScript (не знаю уж насколько полноценная) уже есть. Можно взять ее за основу и доработать напильником, так чтобы парсер брал и битый код.
>> Ну, а "битые входные данные" это ни что иное как более сложные грамматики. И PEG тут будет самым подходящим инструментом. >> В прочем, любой генератор парсеров будет лучше чем регулярки или ручное написание парсера. М>подскажите, пожалуйста, а то я уже мозг сломал -- как какому-нибудь стандартному генератору парсеров объяснить, что строка может не закрываться кавычкой или начинаться не с кавычки (т.е. ello, world\n'; var a = 'AAA'; ).
Создать правило которое будет выявлять эту незакрытость и парсить столько сколько получается.
С любым генератором парсеров тут будут проблемы, так как они в основном все лексерные, что требует выявления битости на уровне символов. Но вот как раз таки PEG безлексорынй. И еще в PEG-е есть офигительно мощная штука — предикаты. С их помощью можно тупо парсить строку следующим образом:
Этот код означает, что мы просим парсер распознать последовательность начинающуюся с "'" (символ ' взятый в кавычки, если не понятно) и состоящую из любых сиволов, при условии, что символ не начинает последовательность удовлетворяющую выражению ЖабаСкрипта или символа "'". Оператор "!" означает негативный предикат. Правило идущее за ним не возвращает результата разбора. Оно только сопоставляется со входной строкой и в случае успеха правило any не будет разбираться, а разбор правила (!(jsExpr / "'") any)* будет остановлен. Таким образом негативный предикат позволяет задать синтаксическое правило останова разбора. Есть еще позитивный предикат "&" он остановит разбор в случае если идущее за ним правило провалится, и позволит двигаться дальше в обратном случае.
Собственно важно здесь именно возможность то что для выявления останова можно применять предикаты. Они позволят создать очень гибкие эвристики.
То что ты делаешь в науке называется восстановлением после обнаружения ошибки. Твоя задача восстановиться с минимальным пропуском значимых данных. Стратегия восстановления целиком зависит от тебя. А PEG предоставляет тебе очень удобный формализм в котором эта стратегия может быть выражена декларативно.
М>парсить "по науке" у меня не получается. ну не знаю я как описать такую грамматику,
Тут нужна практика и подходящий инструмент. А у тебя получилось, что ты не имеешь ни того, ни другого.
Понятно, что при таких условиях тебе оказалось проще взять регексы и какую-то матерь. Но это только от недостатка опыта и слабости инструментов. Поверь тому кто последние шесть лет копал в этом направлении.
М> а потому сначала выделяю ключевые слова ("ключевые" в смысле словарные), а уже отталкиваясь от них бью текст на токены, но это разбивка предположительная, и там приходится искать лучшее соответствие. я стрю семантическое дерево (если я правильно его называю),
Не правильно. Это называется синтаксическим деревом, или сокращенно AST (Abstract Syntax Tree).
М> в котором токены связаны во всех комбинациях, которые допускаются заранее заданными правилами и ищется самый длинный маршрут в дереве.
Тебе надо построить дерево которое получается, а потом начать выявлять паттетны ошибок. И для этого нужен другой механизм который есть во многих функциональных языках (в том числе в немреле, который я предлагаю использовать) — сопоставление с образцом. ПМ очень существенно упростит задачу распознования паттернов ошибок в коде.
В общем, это как раз тот случай когда сложность можно уменьшить применением подходящего инструмента и систематизацией своих знаний, а не грубой силой.
ЗЫ
Если решишься на применение немрела для прототипизрования, обещаю помочь по скайпу советами и другими консультациями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, мыщъх, Вы писали:
VD>Задача весьма странная. Интересно откуда у нее растут ноги? Что ломает эти скрипты?
Скрипты вбивали через аську, часто путая буквы и окна
Здравствуйте, Sinix, Вы писали:
VD>>Ткнул на ссылки и увидел вполне вменяемые ответы. Может не хотел увидеть? S>Нет, там ответы из серии "если такие задачи сложно решать с ФП-подходом — значит, мейнстрим отстой и надо от него отказаться".
Я этого не заметил. На мой взгляд (возможно поверхностный) в данном случае на тебя довлеет твой императивный опыт.
S>Напомню, исходный топик лежал не в философии и был посвящён конкретной проблеме на конкретной платформе. Соответственно, я ожидал практически применимых советов, не нарушающих FDG.
FDG — это что?
S>Если последовать совету ув. WolfHound, перейти к immutable спискам и хранить копии списков для undo-redo, как быть с биндингом, с вычислением изменений, с уведомлением об изменениях (они нужны как минимум для ограничений)?
Да никаких проблем с этим нет. Неизменяемые данные хороши тем, что позволяют переиспользовать неизмененные структуры данных, что практически избавляет от дублирования данных. В общем, WolfHound дело говорит.
S>Нам придётся имитировать поведение BindingList|ObservableCollection, и весь выигрыш от первоначальной идеи уйдёт на допиливание обёрток. Я не просто так, абстрактно говорю — я делал вполне рабочий прототип и делал замеры. В таком виде идея не взлетит.
Я не знаю твой задачи, по этому ничего утверждать не возьмусь. Скажу только что на счет неизменяемых структур ты не прав. Они как раз обеспечивают дешевую версинность данных, облегчают создание многопоточного кода и никак не мешают разным оповещениям и т.п. В прочем, зачастую при применении версионных данных оповещения становятся вообще не нужны. Но это отдельный разговор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я этого не заметил. На мой взгляд (возможно поверхностный) в данном случае на тебя довлеет твой императивный опыт. VD>Да никаких проблем с этим нет. Неизменяемые данные хороши тем, что позволяют переиспользовать неизмененные структуры данных, что практически избавляет от дублирования данных. В общем, WolfHound дело говорит.
Не, это никогда не закончится Как можно 3 поста подряд игнорировать (и ведь каждый раз одно и то же пишу)
Если последовать совету ув. WolfHound, перейти к immutable спискам и хранить копии списков для undo-redo, как быть с биндингом, с вычислением изменений, с уведомлением об изменениях (они нужны как минимум для ограничений)?
Нам придётся имитировать поведение BindingList|ObservableCollection, и весь выигрыш от первоначальной идеи уйдёт на допиливание обёрток. Я не просто так, абстрактно говорю — я делал вполне рабочий прототип и делал замеры. В таком виде идея не взлетит.
и продолжать гнуть линию о тотальном превосходстве immutable в сфероконических условиях?
VD>FDG — это что?
Framework Design Guidelines, вестимо. Обязательно для чтения при разработке публичного API.
VD>Я не знаю твой задачи, по этому ничего утверждать не возьмусь.
Если совсем-совсем упрощённо — general-purpose список с возможностью согласованного undo-redo (undo-redo нескольких списков одновременно). Увы, это только часть задачи.
Здравствуйте, Sinix, Вы писали:
VD>>На мой взгляд есть всего один способ писать сложный код — продумать как и что делать, а потом сесть и написать. S>Ок, как быть, когда _детально_ придумать что и как делать на порядки сложнее/дороже по времени, чем просто написать код? Когда известна архитектура, известно, как (примерно) будет выглядеть API, но сам код можно написать несколькими способами?
Надо сесть и еще раз хорошенько подумать.
В процессе раздумий можно написать несколько тестов...
S>Я ведь уже приводил кучу примеров, когда попытки решить задачу с наскока сваливались в перебор всего дерева вариантов. Дошли до аргументации в духе "а нафига мейнстрим, если в нём не работает ФП-подход?".
Как я понял аргументы были не про мэйнстрим, а про неподходящие подходы для решения конкретных задач, которые приняты в мэйснтриме.
S>и лёгкие наезды аля S>
S>Очень советую почитать статью IT о видах сложностей. Ты явно не читал ее, или читал по диагонали.
S>Предлагаю закругляться.
Хорошая идея. А статью все же прочитай/перечитай. Это не наезд, а очень мудрая мысль. Я ее перечитывал три раза. Вот думаю еще раз перечитать. При поверхностном изложении в ней заложены глубокие мысли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, samius, Вы писали:
VD>>Задача весьма странная. Интересно откуда у нее растут ноги? Что ломает эти скрипты? S>Скрипты вбивали через аську, часто путая буквы и окна
Хм. То что вбивается через аську предназначено для чтения человеком. Это же идеи а не рабочий код. Не уж-то вы такой код пытаетесь в продакшен помещать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, samius, Вы писали:
VD>>>Задача весьма странная. Интересно откуда у нее растут ноги? Что ломает эти скрипты? S>>Скрипты вбивали через аську, часто путая буквы и окна
VD>Хм. То что вбивается через аську предназначено для чтения человеком. Это же идеи а не рабочий код. Не уж-то вы такой код пытаетесь в продакшен помещать?
То была шутка не в тему. Я вообще к этому отношения не имею.
Здравствуйте, samius, Вы писали:
VD>>Хм. То что вбивается через аську предназначено для чтения человеком. Это же идеи а не рабочий код. Не уж-то вы такой код пытаетесь в продакшен помещать? S>То была шутка не в тему. Я вообще к этому отношения не имею.
Да, я когда уже послал ответ, то понял, что автор был другой. Но вопрос действительно интересный. Я смысл в подобном вижу только если это некая IDE и ей нужно разбирать ошибочный код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Надо сесть и еще раз хорошенько подумать. VD>В процессе раздумий можно написать несколько тестов...
Ок, тогда сойдёмся на том, что исходный пост — как раз про этап написания тестов и ?
S>>Я ведь уже приводил кучу примеров, когда попытки решить задачу с наскока сваливались в перебор всего дерева вариантов. Дошли до аргументации в духе "а нафига мейнстрим, если в нём не работает ФП-подход?". VD>Как я понял аргументы были не про мэйнстрим, а про неподходящие подходы для решения конкретных задач, которые приняты в мэйснтриме.
Начали этим:
Если код получается сложным значит ты идешь не тем путем или используешь плохой инструмент.
Тебе говорили как свести решение к тривиальному но ты не послушал.
а закончили — в ответ на описание проблем, которые бывают на практике, а не в абстрактных спорах — вот этим:
Технологии менстрима заставляют писать неоправданно сложный код.
Получается, мы культурно оплевали друг друга и вернулись к исходному вопросу: как быть, когда приходится писать тот самый "неоправданно-сложный код"?
VD>Хорошая идея. А статью все же прочитай/перечитай. ... При поверхностном изложении в ней заложены глубокие мысли.
Полностью поддерживаю (читал и саму статью, и последующий холивар)
S>Если код получается сложным значит ты идешь не тем путем или используешь плохой инструмент.
Я готов был бы подписаться од этим, если бы в понятие "сложность" не вкладывалось бы столько разных смыслов.
S>а закончили — в ответ на описание проблем, которые бывают на практике, а не в абстрактных спорах — вот этим: S>
S>Технологии менстрима заставляют писать неоправданно сложный код.
Ты предложил свое, не верное на взгляд Вольфхаунда, решение которые было навеяно тебе твоими привычками и знаниями. Что он еще мог на это сказать?
Пойми, ты видишь решение задач только в рамках имеющихся у тебя заготовок решений. Когда тебе предложили решение к которому ты не привык, то ты сразу же начал с ним бороться вместо того чтобы попробовать осмыслить его. При таких условиях что тебе не скажи, все равно будет не понимание.
S>Получается, мы культурно оплевали друг друга и вернулись к исходному вопросу: как быть, когда приходится писать тот самый "неоправданно-сложный код"?
Выходит, что ты отбрасываешь не подходящие тебе ответы и возвращаешься к неверной постановке задачи.
VD>>Хорошая идея. А статью все же прочитай/перечитай. ... При поверхностном изложении в ней заложены глубокие мысли. S>Полностью поддерживаю (читал и саму статью, и последующий холивар)
Тогда обрати внимание на мысль о том, что сложность количественная может быть переведена в сложность интеллектуальную. Именно по этому задачи неберучки для новичков использующих "стандартные" (читай — мэйнстрим) решаются опытными товарищами с применением подходящих инструментов и подходов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Закончим маленьким примером. Прототип:
... S>Хоть результат и не блещет внутренней красотой — это не public api, и от него не требуется универсальность и переиспользуемость — но, по крайней мере, он отражает _намерения_ программиста куда лучше, чем предыдущий код.
А что этот код хоть делать должен ?
S>Во-вторых, основная цель поста — показать, как на практике пишется "сделай не-знаю-что"-код. Ключевое слово — на практике, т.е. всё вышеперечисленное работает как минимум у меня.
S>3. Используй xDD (подставить нужное). S>С радостью. Делитесь — как решаете такие задачи вы?
Кент Бек написал целую книгу про это Первые главы в ДДД тоже сгодятся
Здравствуйте, VladD2, Вы писали:
VD>Ну, а "битые входные данные" это ни что иное как более сложные грамматики. И PEG тут будет самым подходящим инструментом. В прочем, любой генератор парсеров будет лучше чем регулярки или ручное написание парсера.
Дык сами грамматики отлаживать тоже надо. Любой генератор парсеров хорош лишь для заведомо отлаженной грамматики.
?
)
