Если бы HP создал просмотрщик или редактор для своих PCL- файлов - аналогия с PDF была бы полная.
Мы не сравниваем возможности PDF и PCL, а наличие возможностей редактирования не требуется для PDL. У вас логическая ошибка отождествления по предикату.
они для печати в файл PDF
Нет, речь не о печати в PDF, а о том, что принтеры HP позволяли напрямую печатать из файла PDF даже под MS DOS без какого-либо дополнительного ПО.
Кажется я понял, вы имели ввиду, что PDF для этих принтеров — это page description language (PDL), так же, как и HP Printer Control Language (PCL). Тогда да. PDF и PCL входят в множество PDL.
Как говорил Брюс Ли: «Я боюсь не того, кто переведёт 16 статей, которые должен знать каждый Node.js-разработчик, а того, кто переведёт одну статью 16 раз»
Убрали примеры формирования файлов в PS из более поздних изданий из-за патентных ограничений?
Вот поэтому бы вы могли привести конкретную цитату или ссылку на то издание, где это явно упомянуто. Тем более, если вы боитесь быть неточным.
TeX ведь почти готовый PDL. В изданиях начала 80-х был пример для выгрузки в PDF.
Всё-таки скорее DVI является PDL, а не TeX.
Нет под рукой статей с интервью Питера Дойча
Не нравится мне "джинса" - пишу об этом в комментариях.
Тогда всё равно можно было кратко пересказать суть его статьи. Ваши комментарии выше выглядят как «я что-то знаю, но не скажу, ищите сами, но вообще это и не важно, но вроде как и важно, ведь я об этом говорю, но вообще не говорю, а только намекаю».
Не задумывались о том, почему
Ваш стиль комментариев в виде узкоспециальных вопросов (которые не являются риторическими, потому что контекст не известен большинству) не способствует даже вашему желанию покритиковать статью.
который вроде бы был
по-идее должен
Откуда мы знаем наверняка, какие там внутренние взаимоотношения между Xerox, Adobe и HP? Тем более, если принтеры Xerox поддерживают PS, почему они не должны поддерживать PCL6 и наоборот?
То есть, опять-таки, язык должен не позволять простое использование переменных из родительского контекста. Тогда для программиста будет привычно, что он может читать код функций без оглядки на родительский контекст. Иначе перекрытие рано или поздно может встретиться случайно или намеренно.
Автор подразумевал любое переиспользование идентификатора в дочерних контекстах, которое затрудняет понимание кода. Не только неожиданный shadowing (который приводит к некорректному поведению и будет выловлен при тестировании кода), но и формально корректное перекрытие.
Так а какая для программиста разница: это user из родительской функции или user из класса? Ему всё равно придётся понять, что тут есть перекрытие, если функции длинные.
Вообще я не писал ни про C++, ни про какой-либо конкретный язык. Это может быть не только класс+метод, но и вложенные друг в друга функции, и вообще глобальный контекст + локальный контекст функции.
Судя по вашим словам, язык с полной поддержкой инкапсуляции всегда должен требовать явно указывать имена, захватываемые из родительского контекста, дабы программист мог явно видеть, что это именно переменная из родителя (кстати такое как раз есть в лямбдах из C++). И то даже это может быть сомнительно. Или мы с вами в принципе о разных вещах говорим? Может быть приведёте свой пример какого-то «правильного» языка?
Ручной контроль часто не требуется, потому что для разных языков есть и широко используются статические анализаторы, рапортующие о перекрытии переменных.
В том и дело, что чтобы осознать, что эта переменная именно локальная, а не прилетела из внешнего контекста, нужно увидеть это в коде и запомнить. Предположим, у нас есть класс с некоторым полем user. Если в коде отдельного метода вводится локальная переменная user, то у программиста, который знает структуру класса и о существовании в нём поля user, но не помнит устройство метода, может возникнуть недоразумение при анаализе работы метода и класса в целом. Он видит null pointer exception при обращении к user.sendEmail, но уверен, что поле user определено, и это может вызвать у него когнитивный диссонанс. Разумеется, это простейший случай.
Так или иначе при анализе вложенных функций и методов класса всё равно приходится держать в голове внешний контекст, поскольку в большинстве случаев обращение к этому контексту производится неявно.
Потому что компилятор/интерпретатор языка легко поймёт, что переменная затенена, а вот человеку держать в уме одинаково поименованные, но разные переменные во вложенных контекстах намного сложнее. К принципу инкапсуляции это имеет косвенное отношение, и независимо от языка затенять переменные — не очень хорошая идея. Лучше явно обозначить различие этих переменных.
Почему именно PDF = PCL? Разве нельзя допустить, что принтер мог поддерживать и PCL, и PDF? Файлы PDF начинаются с последовательности %PDF, принтеру это несложно проверить на лету и сразу переключиться на интерпретацию такого формата.
Вообще-то вы её сами подняли. Упомянули зачем-то прочитать для подробностей «Искусство программирования», но там, похоже, ничего об этом нет. Теперь вообще отправляете искать неизвестные высказывания Кнута в интернете.
Но дело не в Д. Кнуте.
И в Кнуте тоже...
Определитесь уже. Вы сами упомянули Кнута, его книгу и якобы факта, что PDF изобрели какие-то другие люди. Цитирую: «В этой истории нет озвученных в статье фамилий как авторов языка и формата PDF». Или что вообще вы имели ввиду?
Тот кто захочет - найдет.
Вы намеренно создаёте вокруг себя ореол тайного знания?
И чем, интересно, PDL Postscript так уж принципиально отличается от PDL PCL5/PCL6 от HP?
Спецификация PostScript была выпущена в 1984 году, PCL5 вышел в 1990 году.
Так вы договаривайте уже свои мысли. Или полноценную статью хотя бы напишите, если вам есть что сказать. То ссылались на Кнута, якобы он срывает все покровы, теперь говорите, что не в нём дело.
С архитектурной точки зрения, у вас кастомные настройки модели и вьюшки — это внешние данные. Они передаются на фронтенд через API, а дальше их нужно обработать и отобразить. Можно представить работу с ними всё теми же паттернами MVC или MVVM, разложив по иерархии как у автора или любым другим способом. Только здесь они ещё будут играть роль метаданных для собственно данных, с которыми работает пользователь.
Архитектура — это не способ упорядочения модулей в файловой иерархии. Архитектура — это способ взаимодействия компонентов системы. По этой причине MVC/MVVM/etc (которые как раз представляют архитектуру) ортогональны FSD, Local-First, Feature First и прочим способам организации файловой структуры проекта.
Например, если есть некоторые сущности предметной области Foo и Bar, то при архитектурном подходе MVC можно разложить компоненты в файловой системе по-разному:
Мы не сравниваем возможности PDF и PCL, а наличие возможностей редактирования не требуется для PDL. У вас логическая ошибка отождествления по предикату.
Нет, речь не о печати в PDF, а о том, что принтеры HP позволяли напрямую печатать из файла PDF даже под MS DOS без какого-либо дополнительного ПО.
Бесплатно можно отредактировать PDF в том же LibreOffice Draw.
Кажется я понял, вы имели ввиду, что PDF для этих принтеров — это page description language (PDL), так же, как и HP Printer Control Language (PCL). Тогда да. PDF и PCL входят в множество PDL.
Как говорил Брюс Ли: «Я боюсь не того, кто переведёт 16 статей, которые должен знать каждый Node.js-разработчик, а того, кто переведёт одну статью 16 раз»
Что нет? На вопрос «почему?» нельзя дать ответ «нет».
Неделю назад перевод этой статьи так заминусили, что её сняли с публикации: https://habr.com/ru/articles/891612
Вот поэтому бы вы могли привести конкретную цитату или ссылку на то издание, где это явно упомянуто. Тем более, если вы боитесь быть неточным.
Всё-таки скорее DVI является PDL, а не TeX.
Тогда всё равно можно было кратко пересказать суть его статьи. Ваши комментарии выше выглядят как «я что-то знаю, но не скажу, ищите сами, но вообще это и не важно, но вроде как и важно, ведь я об этом говорю, но вообще не говорю, а только намекаю».
Ваш стиль комментариев в виде узкоспециальных вопросов (которые не являются риторическими, потому что контекст не известен большинству) не способствует даже вашему желанию покритиковать статью.
Откуда мы знаем наверняка, какие там внутренние взаимоотношения между Xerox, Adobe и HP? Тем более, если принтеры Xerox поддерживают PS, почему они не должны поддерживать PCL6 и наоборот?
То есть, опять-таки, язык должен не позволять простое использование переменных из родительского контекста. Тогда для программиста будет привычно, что он может читать код функций без оглядки на родительский контекст. Иначе перекрытие рано или поздно может встретиться случайно или намеренно.
Автор подразумевал любое переиспользование идентификатора в дочерних контекстах, которое затрудняет понимание кода. Не только неожиданный shadowing (который приводит к некорректному поведению и будет выловлен при тестировании кода), но и формально корректное перекрытие.
Так а какая для программиста разница: это user из родительской функции или user из класса? Ему всё равно придётся понять, что тут есть перекрытие, если функции длинные.
Вообще я не писал ни про C++, ни про какой-либо конкретный язык. Это может быть не только класс+метод, но и вложенные друг в друга функции, и вообще глобальный контекст + локальный контекст функции.
Судя по вашим словам, язык с полной поддержкой инкапсуляции всегда должен требовать явно указывать имена, захватываемые из родительского контекста, дабы программист мог явно видеть, что это именно переменная из родителя (кстати такое как раз есть в лямбдах из C++). И то даже это может быть сомнительно. Или мы с вами в принципе о разных вещах говорим? Может быть приведёте свой пример какого-то «правильного» языка?
Ручной контроль часто не требуется, потому что для разных языков есть и широко используются статические анализаторы, рапортующие о перекрытии переменных.
В том и дело, что чтобы осознать, что эта переменная именно локальная, а не прилетела из внешнего контекста, нужно увидеть это в коде и запомнить. Предположим, у нас есть класс с некоторым полем
user. Если в коде отдельного метода вводится локальная переменнаяuser, то у программиста, который знает структуру класса и о существовании в нём поляuser, но не помнит устройство метода, может возникнуть недоразумение при анаализе работы метода и класса в целом. Он видит null pointer exception при обращении кuser.sendEmail, но уверен, что полеuserопределено, и это может вызвать у него когнитивный диссонанс. Разумеется, это простейший случай.Так или иначе при анализе вложенных функций и методов класса всё равно приходится держать в голове внешний контекст, поскольку в большинстве случаев обращение к этому контексту производится неявно.
Потому что компилятор/интерпретатор языка легко поймёт, что переменная затенена, а вот человеку держать в уме одинаково поименованные, но разные переменные во вложенных контекстах намного сложнее. К принципу инкапсуляции это имеет косвенное отношение, и независимо от языка затенять переменные — не очень хорошая идея. Лучше явно обозначить различие этих переменных.
Почему именно PDF = PCL? Разве нельзя допустить, что принтер мог поддерживать и PCL, и PDF? Файлы PDF начинаются с последовательности
%PDF, принтеру это несложно проверить на лету и сразу переключиться на интерпретацию такого формата.Вообще-то вы её сами подняли. Упомянули зачем-то прочитать для подробностей «Искусство программирования», но там, похоже, ничего об этом нет. Теперь вообще отправляете искать неизвестные высказывания Кнута в интернете.
Определитесь уже. Вы сами упомянули Кнута, его книгу и якобы факта, что PDF изобрели какие-то другие люди. Цитирую: «В этой истории нет озвученных в статье фамилий как авторов языка и формата PDF». Или что вообще вы имели ввиду?
Вы намеренно создаёте вокруг себя ореол тайного знания?
Спецификация PostScript была выпущена в 1984 году, PCL5 вышел в 1990 году.
Так вы договаривайте уже свои мысли. Или полноценную статью хотя бы напишите, если вам есть что сказать. То ссылались на Кнута, якобы он срывает все покровы, теперь говорите, что не в нём дело.
С архитектурной точки зрения, у вас кастомные настройки модели и вьюшки — это внешние данные. Они передаются на фронтенд через API, а дальше их нужно обработать и отобразить. Можно представить работу с ними всё теми же паттернами MVC или MVVM, разложив по иерархии как у автора или любым другим способом. Только здесь они ещё будут играть роль метаданных для собственно данных, с которыми работает пользователь.
Привет, закон о рекламе
Привет, закон о СМИ
Архитектура — это не способ упорядочения модулей в файловой иерархии. Архитектура — это способ взаимодействия компонентов системы. По этой причине MVC/MVVM/etc (которые как раз представляют архитектуру) ортогональны FSD, Local-First, Feature First и прочим способам организации файловой структуры проекта.
Например, если есть некоторые сущности предметной области Foo и Bar, то при архитектурном подходе MVC можно разложить компоненты в файловой системе по-разному:
Layer First
Feature First
Взаимосвязи между сущностями остались теми же, изменились только пути к файлам.
Вы точно понимаете в чём проблема глубоко вложенных запросов? У вас бекенд от комбинаторной сложности не ляжет?