Строго типизированный лог

[metaclass]

А вот интересно, возможна ли такая концепция: писать не текстовый лог, а строго типизированный, чтобы в будущем можно было грузить сохраненные в него объекты и выполнять над ними какие-нибудь запросы?
Сейчас анализ логов сводится к 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, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.

Comments

[permea-kra.livejournal.com]

>> то и язык C++ придется признать нечитаемым
>А это почти так и есть.
А может, вы не умеете его готовить?

[migmit.vox.com (from livejournal.com)]

Понимаете в чём дело, если не знать, что такое "читабельный язык", то можно и плюсы счесть читабельными - в них есть немного читабельности, даже немножко больше, чем в иксэмэле.

[permea-kra.livejournal.com]

Читабельности там ничуть не меньше чем в хаскеле. Многословия больше, а так...

[migmit.vox.com (from livejournal.com)]

И это многословие очень сильно мешает читабельности.

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

Плюс проблемы низкоуровневых языков - арифметика указателей (когда она нафиг не нужна) и пр.

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

[permea-kra.livejournal.com]

реквестирую аналог, к примеру, mpqc, на haskell. Действующий с приемлимой скоростью.

[migmit.vox.com (from livejournal.com)]

1) Не смешивайте скорость с читабельностью. C++ - язык низкоуровневый, соответственно, работает быстрее.

2) Для того, чтобы предъявить аналог, я должен вообще хоть немного работать в данной области.

3) Может быть, вы мне покажете аналог, скажем, STM на C++?

[permea-kra.livejournal.com]

1)С++, к сожалению, ни фига не низкоуровневый, хоть и даёт доступ к потрохам.
3)Ну, fmap, например, пишется. Монады, пожалуй, тоже. STM... Пожалуй, я знаю как его написать, но сам заниматься не буду.

[migmit.vox.com (from livejournal.com)]

> С++, к сожалению, ни фига не низкоуровневый, хоть и даёт доступ к потрохам.

C++, к сожалению, слишком низкоуровневый.

> STM... Пожалуй, я знаю как его написать, но сам заниматься не буду.

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

[permea-kra.livejournal.com]

>>C++, к сожалению, слишком низкоуровневый.
То-то дептайпы в хаскеле только делают... Вот когда доделают, тогда можно будет так говорить. А пока - у кого-то слишком кривые руки.

>>А такие гарантии в плюсах, увы, невозможны.
unsafePerformIO

[migmit.vox.com (from livejournal.com)]

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

А в C++ они, типа, уже есть? Ну-ну.

> unsafePerformIO

За импорт System.IO.Unsafe бьют по рукам. Вы можете предъявить столь же простой критерий необходимости бить по рукам в плюсах?

[permea-kra.livejournal.com]

>> То-то дептайпы в хаскеле только делают...
>А в C++ они, типа, уже есть? Ну-ну.
в плюсах есть кривое, но всё же стандартизованное метапрограммирование на шаблонах. В ФП его аналогом будут дептайпы.

>> unsafePerformIO
>За импорт System.IO.Unsafe бьют по рукам.
Гм. Речь шла о гарантиях.

[migmit.vox.com (from livejournal.com)]

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

В ФП есть кривоватое, но, всё же, более прямое метапрограммирование. Дептайпы - несколько из другой оперы.

> Гм. Речь шла о гарантиях.

Именно. ЕДИНСТВЕННОЕ, что нужно сделать для получения ГАРАНТИЙ - запретить импорт System.IO.Unsafe. В плюсах получить гарантии невозможно вообще.

[permea-kra.livejournal.com]

>>В ФП есть кривоватое, но, всё же, более прямое метапрограммирование. Дептайпы - несколько из другой оперы.
TH? Удачи...

>>ЕДИНСТВЕННОЕ, что нужно сделать для получения ГАРАНТИЙ - запретить импорт System.IO.Unsafe....
И половины хакаджа. Удачи...

[migmit.vox.com (from livejournal.com)]

> TH? Удачи...

Пользовал. Кривовато, да. Примерно как плюсовые темплейты.

> И половины хакаджа. Удачи...

Брехня. Нормальные модули если и импортируют Unsafe, то не переэкспортируют его.

[permea-kra.livejournal.com]

>>не переэкспортируют его.
Они могут пользовать его внутри себя. Удачи.

[migmit.vox.com (from livejournal.com)]

> Они могут пользовать его внутри себя.

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

[madeveloper.livejournal.com]

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

http://en.wikipedia.org/wiki/Human-readable

Что касается избыточности и "мусора", то, следуя Вашей логике, консоль следует признать более выразительной чем GUI. Может и так, но она от этого не становиться более human-friendly.

[migmit.vox.com (from livejournal.com)]

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

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

Только времени у него это займёт немеряно.

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

Вывод не понял. Консоль часто более выразительна, но далеко не всегда.

> она от этого не становиться более human-friendly.

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

[madeveloper.livejournal.com]

> Только времени у него это займёт немеряно.

Именно поэтому сравнение совершенно неуместно.

> Вывод не понял. Консоль часто более выразительна, но далеко не всегда.

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

> Компьютерная программа - мой раб. Я не хочу, чтобы раб был ко мне дружелюбен.

Ваше право. Только к общедисциплинным вопросам это отношения не имеет.

[migmit.vox.com (from livejournal.com)]

> Именно поэтому сравнение совершенно неуместно.

Именно поэтому оно в яблочко.

> Я тоже ваших выводов не понимаю.

Задавайте вопросы. И желательно сразу.

> Вы всегда крайне категоричны в оценках

Разумеется. Вы ждали толерантности и политкорректности?

> делите все на массу остоя и "моя-прелесть".

Отнюдь. Просто пока ваши варианты проходят по разряду "отстой".