![[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
no subject
no subject
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)
(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