![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Строго типизированный лог
А вот интересно, возможна ли такая концепция: писать не текстовый лог, а строго типизированный, чтобы в будущем можно было грузить сохраненные в него объекты и выполнять над ними какие-нибудь запросы?
Сейчас анализ логов сводится к grep, awk и прочей тексто-ориентированной линуксятине. Существует мнение, что это (текстово-ориентированный обмен данными между линуксовыми утилитами через |) хорошо, но у меня это усиленно ассоциируется с электронным прибором, у которого все платы соединены одинаковыми никак не различимыми разъемами, а плата сама решает, "что делать с входным сигналом", т.е. нет никакой защиты от обобщенного индуса-дяди-Васи-телемастера-из-соседнего-гаража.
Плохо то, что большинство интересующих объектов обычно содержат кучу пропертей-ссылок на всякие дебри, которые вне рабочего контекста смысла не имеют, а чтобы их исключить, нужно какой-то флаг на проперть типа атрибута/аннотации "NotLoggable". А это плохо тем, что логгинг не должен требовать лишнего от объектов, с которыми он работает.
Сейчас вывод в лог выглядит следующим образом:
А желательно было бы так:
А DebugAll был бы хитрым метапрограммным макросом, который бы доставал, в зависимости от флагов, имя метода, this, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.
Сейчас анализ логов сводится к grep, awk и прочей тексто-ориентированной линуксятине. Существует мнение, что это (текстово-ориентированный обмен данными между линуксовыми утилитами через |) хорошо, но у меня это усиленно ассоциируется с электронным прибором, у которого все платы соединены одинаковыми никак не различимыми разъемами, а плата сама решает, "что делать с входным сигналом", т.е. нет никакой защиты от обобщенного индуса-дяди-Васи-телемастера-из-соседнего-гаража.
Плохо то, что большинство интересующих объектов обычно содержат кучу пропертей-ссылок на всякие дебри, которые вне рабочего контекста смысла не имеют, а чтобы их исключить, нужно какой-то флаг на проперть типа атрибута/аннотации "NotLoggable". А это плохо тем, что логгинг не должен требовать лишнего от объектов, с которыми он работает.
Сейчас вывод в лог выглядит следующим образом:
mLog.DebugFormat("OnAuthenticateRequest: {0} {1} {2}",
httpApplication.Request.RawUrl,
httpApplication.Request.UserAgent,
httpApplication.Request.UserHostAddress);
А желательно было бы так:
mLog.Debug("some_user_comment",LogFlags.LocalVars | LogFlags.MethodName | LogFlags.This | LogFlags.Parameters);
А DebugAll был бы хитрым метапрограммным макросом, который бы доставал, в зависимости от флагов, имя метода, this, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.
no subject
C++ - если писать очень аккуратно и исключительно руками, то он будет струдомчитабельным. Если генерировать из какой-то другой программы (например, из компилятора высокоуровневого языка), то нечитабельность практически гарантирована. Причём, проблемы что у XML, что у HTML, что у C++ схожие (хотя и не идентичные) - безумная избыточность синтаксиса в первую очередь.
C# я знаю очень плохо и ничего на нём не писал, хелловорлды не в счёт. Так что, говорить о нём не буду.
no subject
PS. А что, какие-то логи более читабельны чем XML? Там ты даже названия и назначение полей не всегда увидишь...
no subject
no subject
no subject
Фигня полная. Лаконичный Haskell на несколько порядков читабельнее безумно избыточных плюсов.
> HTML даже этой страницы нормально читается.
То-то специальных программ для его чтения понаписали немеряно.
> Другое дело что 130К неформатированного кода на ЛЮБОМ языке будут неразберабельны.
130K иксэмэля легко превратятся в 60K чего-нибудь типа ямла, а в обычных логах легко уместятся в 30K.
> Чтобы C++ генерировали откуда-то и при этом сложно читаемый - первый раз слышу.
Ну, генераторов нечитабельного C просто пруд пруди. С плюсами сложнее - их мало кто вообще генерит, за ненадобностью.
> Там ты даже названия и назначение полей не всегда увидишь...
И это, зачастую, хорошо. Потому что "117:24" - гораздо более читабельно, чам "row='117' column='24'", я уж молчу про ситуации, когда полей десять штук и из-за прихоти иксэмэль-генератора row оказывается на одном конце, а column - на другом.
no subject
no subject
Я где-то сказал обратное?
> Более компактные языки не всегда являются более читаемыми, так как предполагают более глубокие знания самого языка.
Будете смеяться, любой язык надо знать, чтобы им пользоваться. Сюрприз.
> Конструкции типа return (func(x) ? 0 : GetLastResult()) я не считаю более читабельными чем процедурное выражение.
Согласен. Многовато скобочного шума. А, скажем,
if func x then 0 else getLastResult
- уже сильно лучше.
> При этом объем лога ничего не говорит о его читаемости.
Безусловно, я просто намекнул, что говорить о 130K чего угодно - не вполне корректно, если речь идёт о разных языках.
> Может попросить вас код этой страницы выразить на Haskell?
Вы путаете язык программирования и язык разметки.
> Вы уже начинаете путать процедурные, функциональные
Учитывая, что они служат одной цели - не вижу, почему не говорить о них одновременно.
> и языки разметки в одну кучу.
Вы первый поставили C++ и HTML в одно предложение.
> Десять штук полей - это фигня
That depends. Если они всегда в одном порядке - да. Правда, XML этого никак не обеспечивает.
> Зато при незначительном изменении структуры, все продолжит работать, без необходимости что-то переделывать.
Свежо питание.
> Ну и опять же упомянутый XQuery - стандарт де-факто для интеграции.
Угу, только это на порядок более громоздкая и неудобная штука, чем банальный регэксп.
no subject
Да. Вы стали расуждать категориями "более|менее читаем".
> Согласен. Многовато скобочного шума. А, скажем, if func x then 0 else getLastResult - уже сильно лучше.
Два return-а забыли ;) Я к чему это говорил - в языках есть конструкции слабо воспринимаемые зрительно. Если еще все это разбавить частым использованием "x = (заодно еще чего-нибуль посчитаем), (куда-нибудь присвоим), (а вот только тут значение для x)", то и язык C++ придется признать нечитаемым. В этом свете мне непонятны претензии к XML.
> Угу, только это на порядок более громоздкая и неудобная штука, чем банальный регэксп.
Что делать, газовая плита - более громозкая и неудобная штука, чем банальная зажигалка...
no subject
В какой момент я сказал, что читаемость XML выше нуля?
Кстати, говорю. Немножко выше. Примерно как у бинарного кода.
> Два return-а забыли ;)
Нет, не забыл. Это именно то, что я и говорю: синтаксический мусор.
> Если еще все это разбавить частым использованием "x = (заодно еще чего-нибуль посчитаем), (куда-нибудь присвоим), (а вот только тут значение для x)"
Да, мутабельность переменных - это полный ужас, согласен. При чём тут это, правда...
> то и язык C++ придется признать нечитаемым
А это почти так и есть.
> Что делать, газовая плита - более громозкая и неудобная штука, чем банальная зажигалка...
Поэтому от плиты прикуривают лишь в исключительных ситуациях.
no subject
>А это почти так и есть.
А может, вы не умеете его готовить?
no subject
no subject
no subject
Плюс, конечно, проблемы императивных языков - бесконечные неконтролируемые сайд-эффекты.
Плюс проблемы низкоуровневых языков - арифметика указателей (когда она нафиг не нужна) и пр.
Плюс проблемы ссылок - когда функция изменяет свой параметр, а в синтаксисе вызова это не отражается (вообще звиздец).
no subject
no subject
2) Для того, чтобы предъявить аналог, я должен вообще хоть немного работать в данной области.
3) Может быть, вы мне покажете аналог, скажем, STM на C++?
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
http://en.wikipedia.org/wiki/Human-readable
Что касается избыточности и "мусора", то, следуя Вашей логике, консоль следует признать более выразительной чем GUI. Может и так, но она от этого не становиться более human-friendly.
no subject
А экзешник может понять любой человек, которому понадобилось его прочитать.
Только времени у него это займёт немеряно.
> следуя Вашей логике, консоль следует признать более выразительной чем GUI.
Вывод не понял. Консоль часто более выразительна, но далеко не всегда.
> она от этого не становиться более human-friendly.
А это вообще омерзительное понятие. Компьютерная программа - мой раб. Я не хочу, чтобы раб был ко мне дружелюбен.
no subject
Именно поэтому сравнение совершенно неуместно.
> Вывод не понял. Консоль часто более выразительна, но далеко не всегда.
Я тоже ваших выводов не понимаю. Вы всегда крайне категоричны в оценках и делите все на массу остоя и "моя-прелесть".
> Компьютерная программа - мой раб. Я не хочу, чтобы раб был ко мне дружелюбен.
Ваше право. Только к общедисциплинным вопросам это отношения не имеет.
no subject
Именно поэтому оно в яблочко.
> Я тоже ваших выводов не понимаю.
Задавайте вопросы. И желательно сразу.
> Вы всегда крайне категоричны в оценках
Разумеется. Вы ждали толерантности и политкорректности?
> делите все на массу остоя и "моя-прелесть".
Отнюдь. Просто пока ваши варианты проходят по разряду "отстой".
no subject
Угу, только это на порядок более громоздкая и неудобная штука, чем банальный регэксп.
Как человек, пользовавшийся и тем, и другим, заявляю: Брехня. Это не говоря о том, что в регэксп покрывает хорошо если 0.01 выразительной мощности XQuery.
no subject
А может, вы не умеете его готовить?
no subject
/*/*/*[@a eq "somestr"]/../somelem[6]
(мог напутать в синтаксисе - давно не открывал стандарта)
no subject
Не говоря уже о том, что это, в общем-то, не XQuery, а его маленькая часть XPath.
no subject
no subject