выкладываю восьмую, последнюю статью, не попавшую в уже исчезнувший журнал RSDN Magazine.
Правда, осталась еще одна статья, но автор попросил подождать ее выкладывать: он нашел издание, куда пробует с ней толкнуться.
Так, что все свободны, всем спасибо
Даже тем, кто просматривал статьи под девизом: «Кто писал не знаю, а я, дурак, читаю» (А.Чехов «Жалобная книга»)
По обсуждениям статей, правда, удалось достичь консенсуса только по регистру SPL: нет несогласных с тем, что он на фиг не нужен
По теме, на мой взгляд, сюда, хотя какая «философия» может быть у вывода имен переменных? Но другие ветки еще менее подходят.
Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.
Здравствуйте, кт, Вы писали:
кт>По теме, на мой взгляд, сюда, хотя какая «философия» может быть у вывода имен переменных? Но другие ветки еще менее подходят. кт>Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.
Почему сразу лох? Делать специальные операторы для таких мелочей — ненужное усложнение языка. Делать препроцессор — серьёзное решение, которое потом может сильно аукнуться, у большинства современных языков препроцессоров нет.
Собственно какие языки вообще имеют такую возможность? Я вот ни одного такого языка не знаю. Только C/C++ за счёт препроцессора.
Так-то я согласен, удобно. Но можно много таких удобств придумать. Мне вот в Java не хватает захвата значений всех локальных переменных в Exception в каждом фрейме (и потом распечатывание их). Насколько проще была бы отладка.
Re[2]: О специализированных операторах ввода-вывода
Здравствуйте, vsb, Вы писали:
vsb>Собственно какие языки вообще имеют такую возможность? Я вот ни одного такого языка не знаю. Только C/C++ за счёт препроцессора.
Вот все и лохи Шучу, шучу. Просто в стародавние времена, когда не было интерактивных отладчиков и IDE с "распахиванием структур" больше внимания уделялось удобству вывода при отладке.
Ведь вывод с именами это действительно мелочь, но экономящая время. И нервные клетки.
vsb>Так-то я согласен, удобно. Но можно много таких удобств придумать. Мне вот в Java не хватает захвата значений всех локальных переменных в Exception в каждом фрейме (и потом распечатывание их). Насколько проще была бы отладка.
Да, и в Яве ведь стандартный вывод довольно развитой. Но почему-то опыт старых языков отвергли
Здравствуйте, кт, Вы писали:
кт>Сама статья, написана почти два года назад: кт>http://files.rsdn.org/122727/pl1ex19.doc
IMO в интерактивном отладчике такая фича просто не нужна.
В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику.
Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px".
Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать.
Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора.
Вывод — не вижу зачем лично мне бы понадобилась описанная доработка.
Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит.
Re[2]: О специализированных операторах ввода-вывода
Здравствуйте, vmpire, Вы писали:
V>IMO в интерактивном отладчике такая фича просто не нужна. V>В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику. V>Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px".
Речь идет в основном об отладочных выводах. Если у меня массив S из 10 строк, что я должен увидеть? 10 раз "unparsed string:" или S(1)=.. S(2)=...
в первом случае толку от такого вывода мало и легко ошибиться при анализе.
V>Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать.
Это я вообще не понял. Если меняются даже названия переменных, зачем читать старые логи?
V>Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора. V>Вывод — не вижу зачем лично мне бы понадобилась описанная доработка.
Описанная доработка потребовалась автору для приведения компилятора к стандарту языка. В языке это было предусмотрено.
V>Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит.
Вольному — воля. Описанная возможность встроена в язык и ляпать ничего уже не надо.
Здравствуйте, кт, Вы писали:
кт>Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.
На самом деле™, никто в логи просто так что попало не выводит. Нормальные логи имеют определенную структуру записи. Например: дата и время записи, ID текущего thread-а. Определенные требования могут предъявляться и к выводимым данным. Простой PUT DATA такое не потянет. Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA.
Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов. Тем более, что на них часто приходится натравливать всякие парсеры, которые могут упасть на непонятных записях.
Re[2]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>Простой PUT DATA такое не потянет.
Да он, собственно, никогда и не претендовал. Всеобъемлющего оператора вывода до сих пор нет
P>Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA.
Это да, лучше бы сделали PUT EDIT DATA
P>Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов.
[испуганно] А где я нарушил? Кстати, что такое "единый формат логов"? ГОСТ что-ли ввели? Вот сволочи, людей им не жалко...
Re[3]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
P>>Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA. кт>Это да, лучше бы сделали PUT EDIT DATA
А еще лучше, как сейчас. Когда весь ввод-вывод вынесен в библиотеки. Я плохо представляю себе, как должен быть устроен PUT EDIT DATA.
P>>Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов. кт>[испуганно] А где я нарушил? Кстати, что такое "единый формат логов"? ГОСТ что-ли ввели? Вот сволочи, людей им не жалко...
ГОСТ не ввели, не надо пугаться. Но в любой нормальной программной системе логи имеют определенный формат. И нарушать его не стоит. Просто потому, что можно не найти требуемую запись. С учетом использования автоматиированных анализаторов.
Re[4]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>А еще лучше, как сейчас. Когда весь ввод-вывод вынесен в библиотеки.
Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.
P>Я плохо представляю себе, как должен быть устроен PUT EDIT DATA.
Да, думаю, так же как в статье. Только в списке форматов нужно через один добавлять формат "A" (надо будет автору идею кинуть )
P>ГОСТ не ввели, не надо пугаться. Но в любой нормальной программной системе логи имеют определенный формат. И нарушать его не стоит. Просто потому, что можно не найти требуемую запись. С учетом использования автоматиированных анализаторов.
Да я пошутил. Речь-то шла об отладке. Т.е. об обычно разовых выводах, которые программист посмотрел и выкинул (выкинул оператор вывода). Здесь вывод полностью определяется программистом и его понятием об удобстве и наглядности. Лог, который будут смотреть во время эксплуатации — это уже другое. Хотя и там PUT DATA пригодится. Особенно, если имена переменных хорошо продуманны.
Re[5]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.
Это по тому что у вас языки не правильные. А в правильных языках библиотеки ещё не такое умеют. http://www.nemerle.org/
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.
Автор статьи пишет, что иногда нужно анализировать данные на распечатке. Мне такую ситуацию пердставить сложно. В 2016 году анализировать лог на бумаге просто неудобно. Поиск по ним не сделаешь. А современные логи — штука весьма объемная. А если нужный фрагмент уже найден, то удобнее просто скопировать его, к примеру, на флэшку и посмотреть копию на каком-нибудь гаджете. Например, мой гибрид для просмотра логов подходит отлично. А если есть средства автоматизации работы с логами, тогда в печати вообще смысла нет.
А почему для записи логов используется PUT? WRITE был бы логичнее, нет? К тому же, файл можно сделать индексно-последовательным. Современные версии PL/1 такое поддерживают, правда? Сразу поиск легче станет. В качестве ключа использовать время записи.
P>>Я плохо представляю себе, как должен быть устроен PUT EDIT DATA. кт>Да, думаю, так же как в статье. Только в списке форматов нужно через один добавлять формат "A" (надо будет автору идею кинуть )
кт>Да я пошутил. Речь-то шла об отладке. Т.е. об обычно разовых выводах, которые программист посмотрел и выкинул (выкинул оператор вывода). Здесь вывод полностью определяется программистом и его понятием об удобстве и наглядности. Лог, который будут смотреть во время эксплуатации — это уже другое. Хотя и там PUT DATA пригодится. Особенно, если имена переменных хорошо продуманны.
На самом деле™ удобно, когда лог выводится в едином формате. Уровни логирования не зря придумали. Если возникает нештатная ситуация в production, просто меняется в конфиге уровень с error на debug, и все дела. Сразу, не сходя с места, получаем расширенную информацию.
Я надеюсь, для логирования используются специальные модули? А то я знаю пару любителей пихать запись в лог прямо в код. Добавит такой любитель оператор вывода в лог, а в конце убрать забудет. А с нормальными логгерами и далать ничего не надо. Только уровни расставить.
А не так много реального кода на PL/1 видел. Но везде использовался только PUT EDIT для печати.
Re[6]: О специализированных операторах ввода-вывода
Здравствуйте, WolfHound, Вы писали:
кт>>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет. WH>Это по тому что у вас языки не правильные. А в правильных языках библиотеки ещё не такое умеют. WH>http://www.nemerle.org/
Я, кстати, оговорился. Компилятор имеет ИМЕНА и свойства.
Я же не написал создание невозможно. Я написал, что затруднено. Ведь сколько лишней информации нужно иметь и передавать туда-сюда только, чтобы вывести имя объекта в динамике. А если не нужен отладочный вывод? Все равно все иметь?
Re[3]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
V>>В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику. V>>Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px". кт>Речь идет в основном об отладочных выводах. Если у меня массив S из 10 строк, что я должен увидеть? 10 раз "unparsed string:" или S(1)=.. S(2)=... кт>в первом случае толку от такого вывода мало и легко ошибиться при анализе.
"временный отладочный вывод" — это как раз то единственное применение, которое я могу представить (о чём и написал в конце поста).
А если уж говорить о массиве, то мне, например, был бы удобен более компактный вид (Например как в JSON), а уж никак не "S(1)=.. S(2)=..."
V>>Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать. кт>Это я вообще не понял. Если меняются даже названия переменных, зачем читать старые логи?
Ну так логика-то не меняется. Пример:
Пришло на вход сервиса XML сообщение. В лог полезно вывести информацию о нём (скажем, URI схемы, чтобы понимать, какой блок кода будет с ним работать).
Это не меняется с версиями программы.
Но, например, в первой версии это была одна переменная, в следующей — другая, а потом мы поменяли парсер и надобность в переменной отпала.
А информация по прежнему есть и её надо выводить.
В такой ситуации имена переменных будут только путать.
"зачем читать старые логи" — вопрос, видимо, риторический, так как ответ на него очевиден.
V>>Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора. V>>Вывод — не вижу зачем лично мне бы понадобилась описанная доработка. кт>Описанная доработка потребовалась автору для приведения компилятора к стандарту языка. В языке это было предусмотрено.
Ну тогда ок. Видимо, тогда это местные проблемы PL\1, а не общие вопросы (как можно предположить из темы).
V>>Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит. кт>Вольному — воля. Описанная возможность встроена в язык и ляпать ничего уже не надо.
как это не надо? Язык сам догадается, какие переменные мне нужно записывать и в какой файл?
Re[6]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>На самом деле™ удобно, когда лог выводится в едином формате. Уровни логирования не зря придумали. Если возникает нештатная ситуация в production, просто меняется в конфиге уровень с error на debug, и все дела. Сразу, не сходя с места, получаем расширенную информацию. P>Я надеюсь, для логирования используются специальные модули? А то я знаю пару любителей пихать запись в лог прямо в код. Добавит такой любитель оператор вывода в лог, а в конце убрать забудет. А с нормальными логгерами и далать ничего не надо. Только уровни расставить.
Видите ли, у Вас вся отладочная печать почему-то, исключительно что-то вроде телеметрии (недавно у Прогресса отладочная печать прервалась на 383 секунде, слышали?) или протокола работы сервера. А при создании программ отладочный вывод совершенно разный можеть быть. Какую-нибудь матрицу и вектор один раз вывести. В процессе создания может еще и логов-то и в проекте нет.
Исследовать распечатку? А почему нет. Цифирки большие. От электричества не зависит
P>А не так много реального кода на PL/1 видел. Но везде использовался только PUT EDIT для печати.
Может о PUT DATA не слышали Или это не отладочный вывод был.
Re[7]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Я, кстати, оговорился. Компилятор имеет ИМЕНА и свойства. кт>Я же не написал создание невозможно. Я написал, что затруднено. Ведь сколько лишней информации нужно иметь и передавать туда-сюда только, чтобы вывести имя объекта в динамике. А если не нужен отладочный вывод? Все равно все иметь?
Как нужно, так и будет.
Библиотеки немерла в общем случае состоят из двух частей.
Той что выполняется во время исполнения и той что может поговорить с компилятором во время компиляции и сгенерировать, изменить или удалить код. https://github.com/rsdn/nemerle/wiki/Macros-tutorial
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, кт, Вы писали:
кт>По теме, на мой взгляд, сюда, хотя какая «философия» может быть у вывода имен переменных? Но другие ветки еще менее подходят. кт>Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.
Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает.
Re[8]: О специализированных операторах ввода-вывода
WH>Библиотеки немерла в общем случае состоят из двух частей. WH>Той что выполняется во время исполнения и той что может поговорить с компилятором во время компиляции и сгенерировать, изменить или удалить код. WH>https://github.com/rsdn/nemerle/wiki/Macros-tutorial
Ну вот пример в терминах PL/1
declare
x fixed(31) based(p),
y bit(32) based(p),
p ptr;
allocate x;
put data(x);
в библиотеке выполнения известен адрес. А то, что я хотел вывести именно как X, а не как Y довольно сложно определить, поскольку имеется только содержимое указателя P.
А здесь никаких заморочек не надо — внутри программы автоматически запишется "X=" и дело с концом.
Re[7]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Видите ли, у Вас вся отладочная печать почему-то, исключительно что-то вроде телеметрии (недавно у Прогресса отладочная печать прервалась на 383 секунде, слышали?) или протокола работы сервера. А при создании программ отладочный вывод совершенно разный можеть быть. Какую-нибудь матрицу и вектор один раз вывести. В процессе создания может еще и логов-то и в проекте нет.
Так логи — это и есть телеметрия, нет? И в разных ситуациях нужны разные уровни детализации выводимой информации.
Вывод может быть разным по содержанию. А форма должна быть стандартизована в рамках разрабатываемой системы.
Вот так это может выглядеть:
2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - font is changed
2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - page height is changed
2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - page width is changed
2385/12/20 15:43:43.3440 INFO ldomDocument::openCacheFile() - looking for cache file
2385/12/20 15:43:43.3440 TRACE getPersistenceFlags() returned 0
2385/12/20 15:44:33.4850 TRACE Updating screen after key event
2385/12/20 15:44:33.4850 TRACE animatePageFlip( 256 -> 258 )
2385/12/20 15:44:33.4850 TRACE CRUIReadWidget::prepareScroll(1)
Лог CoolReader-а. Нормально читается. PUT DATA так не умеет.
В конфиге, вероятно, стоит уровень вывода DEBUG. Если указать INFO, то уровень детализации существенно понизится.
Ведь DEBUG может понадобиться не только при отладке, но и при тестировании. А иногда и в рабочей системе, правда, такое случается редко.
кт>Исследовать распечатку? А почему нет. Цифирки большие. От электричества не зависит
Во-первых, как я уже писал, это банально неудобно. Исследуется не одна-две строки, а десятки или сотни. Тупой поиск глазами с карандашиком лично меня напрягает.
Во-вторых, при чтении по распечатке легко ошибиться. Ну там 0 и О. Или 1 и l или I.
В-третьих, от электричества-таки зависит. Лампа какая-нибудь обязательно нужна. Наощупь в темноте у меня почему-то не очень получается.
кт>Может о PUT DATA не слышали Или это не отладочный вывод был.
Про PUT EDIT, WRITE, ISAM слышал, а про PUT DATA — нет? Я таких не встречал.
offtopic: Кстати, а ISAM поддерживается в языке?
Re[8]: О специализированных операторах ввода-вывода
P>Так логи — это и есть телеметрия, нет? И в разных ситуациях нужны разные уровни детализации выводимой информации. P>Вывод может быть разным по содержанию. А форма должна быть стандартизована в рамках разрабатываемой системы. P> PUT DATA так не умеет.
чего-то у нас диалог глухих получается. Я-то другие примеры приводил. Допустим, я перепутал порядок умножения матриц (умножение не коммутативное). У меня программа отработала 3 секунды и закрылась по концу расчета. На хрен мне все эти логи, события и времена. Мне матрицы распечатать и посмотреть не обсчитавшись член №6 в матрице 3х3. Один PUT DATA и вперед с песнями!
P>Во-первых, как я уже писал, это банально неудобно. Исследуется не одна-две строки, а десятки или сотни. Тупой поиск глазами с карандашиком лично меня напрягает. P>Во-вторых, при чтении по распечатке легко ошибиться. Ну там 0 и О. Или 1 и l или I. P>В-третьих, от электричества-таки зависит. Лампа какая-нибудь обязательно нужна. Наощупь в темноте у меня почему-то не очень получается.
В темноте спать надо. А отладочная печать не обязательно миллионы строк.
P>offtopic: Кстати, а ISAM поддерживается в языке?
Это Indexed Sequential Access Method что-ли? А зачем эта древность сейчас при живых Accessaх с SQL-лями и файлами, отображаемыми на память?
Re[9]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>чего-то у нас диалог глухих получается. Я-то другие примеры приводил. Допустим, я перепутал порядок умножения матриц (умножение не коммутативное). У меня программа отработала 3 секунды и закрылась по концу расчета. На хрен мне все эти логи, события и времена. Мне матрицы распечатать и посмотреть не обсчитавшись член №6 в матрице 3х3. Один PUT DATA и вперед с песнями!
Это частный случай. Который несложно сделать с помощью нормальных средств логирования. И потом, ЕМНИП, PUT DATA выводил данные в одну строку. Если размерность матрицы больше, чем 2x2, читать такое будет сложно. Но тут могу наврать.
кт>В темноте спать надо. А отладочная печать не обязательно миллионы строк.
А как же "от электричества не зависит"?
И про ночь я ничего не писал. Сейчас зима, темнеет раньше, чем заканчивается рабочий день.
P>>offtopic: Кстати, а ISAM поддерживается в языке? кт>Это Indexed Sequential Access Method что-ли? А зачем эта древность сейчас при живых Accessaх с SQL-лями и файлами, отображаемыми на память?
Стандарт языка не требует разве?
Вот найдется вдруг какая-нибудь ценная программа, которая 40 лет на ленте пролежала и которую срочно надо запустить. А в ней такое:
OPEN FILE(STATE_FILE) KEYED ENVIRONMENT(INDEXED);
Ну и дальше, что там требуется от индекса.
И что будет?
Как ни странно, файловые хранилища распространены достаточно широко.
