недоразвитость консоли в win растет из-за драконовских требований прямой и обратной совместимости: консоль является одной из главных подсистем ОС, и написаны тысячи и тысячи консольных приложений, которые должны работать в консоли — иначе кому нужна консоль с двумя с половиной приложениями?
таким образом, мы либо творим чудеса и сохраняем совместимость, улучшая консоль, либо переписываем все приложения, адаптируя к улучшениям консоли.
таким образом, хоть изначально подход windows console лучше (структура более целостна, чем поток), но подход *nix "всё есть файл"(а точнее, символьный поток) позволяет обогащать возможности при сохранении совместимости ("простое лучше сложного") и взаимодействовать совершенно разным стстемам и программам.
что значит, что открытие ядра не решит проблему.
и подтверждение тому — куча сторонних разработок типа ConEmu, которые все равно глючат и тормозят.
А почему, собственно, большинство комментаторов решило, что технология значительно подешевеет? Даже если предположить, что себестоимость будет низка, то сразу обложат миккимаус-патентами стоимостью в "атомоход". Патентодержатели, разумеется, озолотятся, но они также решат, что не стоит технологию давать большинству.
Далее, вполне может оказаться, что она не так уж желанна, но это поймут единицы, и спрос не упадет настолько, чтобы имело смысл снижать цену...
Что Вы говорите… То-то настроить отправку уведомлений с моего сервера на мой же ящик так, чтобы он хотя бы в "спам" попал — нужны танцы под луной и кровь девственницы…
А тут Вы мне глаза открыли, мы все уже 20 лет в опасности...
Это все ягодки… Ждем доступ по одобрению заявки из ФСБ, с обязательным MITM сертификатом и предоставлением ключей, рейтинги "благонадежности" и посещение публичных мест по паспорту.
И еще, по поводу интерпретаторов: виртуальная машина — только первый шаг, потребуется также реализовать парсер+лексер для выбранной грамматики — что по себе очень серьезная задача, особенно если писать самостоятельно (и чем дальше от семантики ассемблера, тем сложнее).
Поэтому зачастую проще взять существующую ВМ, сторонний парсер+интерпретатор, и только написать для этого парсера понятную ему грамматику.
Либо (если похожий язык есть, но нужно его расширить\изменить) — можно написать транспилер в целевой язык и положиться на свойства платформы этого языка. Этот способ привлекателен тем, что сам транспилер не обязан быть быстрым, многие конструкции просто перенести 1:1, и реализовать его можно хоть на любимых регулярках.
Для языка Си как основы вообще может оказаться достаточным применение макросов и его препроцессора
Я бы порекомендовал реализовать примитивные базовые (не пересекающиеся между собой) операции, необходимые для написания любого интерпретатора (ну хотя бы тот же брейнфак). Так, операции AddAssign и SubAssign являются лишними, но не хватает операции Assign.
Далее, как уже было замечено, сильно не хватает операций ветвления (условия, переходы), чтобы можно было написать нелинейный код. Конечно, для этого потребуется понятие адресации (абсолютной и\или относительной, возможно, меток) — интересно, какой подход выбрали (бы) Вы.
И последнее: всё описанное с легкостью реализуется на любом ЯП, не только Rust, но и C\C++, Java\C#, Python\Ruby etc.
связываю это утверждение со вступлением бесплатного и открытого ПО в период зрелости, когда таковое перестало уступать по удобству использования коммерческому, а также с ослаблением ассоциацивных связей (вроде графический редактор = фотошоп). Проще стало установить бесплатный аналог, чем искать подходящий кряк, который периодически может слетать.
Лично давно перешел на бесплатные и открытые аналоги и, поскольку не нужен спецсофт — только выиграл от этого.
Плюс, считаю правильным поддерживать (благодарить) материально коллег-энтузиастов, которые несмотря на все — смогли дать мне такую возможность.
Нет. давайте попробуем отделить мух от котлет, ибо мысли в статье здравые, а иллюстрации все портят.
Итак, когда нужна анимация и когда не нужна? Лично я мыслю так:
Резкость перехода между экранами раздражает. Нет ничего хуже, чем полностью сменить содержание… Разве что представив между ними пустой экран. Нет, не нужно морфинга, достаточно простых шторок или перелистывания, это дрбавляет комфорта для пользователя.
Анимация должна быть логичной. Да, давайте сделаем плавными движения ползунка, переключателя, и полосу прогресса плавной. В жизни нет мгновенно меняющихся элементов, поэтому не будем раздражать пользователя.
Анимация должна быть быстрой… если речь не о слайдшоу. сотенные доли секунды, максимум полсекунды, не заставят пользователя ждать мгновенного результата, а психологический эффект будет достигнут. Никто не ждет мультфильм и демонстрацию крутости разработчика.
Анимация должна быть уместной. т.е. никакого морфинга между не связанными между собой элементами (пример из статьи превращения кнопки в окружеость ужасен). Пожалуйста, не заставляйте меня интуитивно искать связь там, где ее нет. Даже если это общее место для бывшего и настоящего элементов.
Да, анимацию можно (но осторожно) использовать для привлечения внимания. К событиям, требующем безотлагательного внимания. И вместе с тем не уводите внимание от значительных элементов к значительным (для пользователя. Конечно, вам важнее обратить внимание на рекламу, которая снизит ваши расходы, но клиент скорее обозлится). И тем более, не зациуливайте анимацию, если элемент не ведет к критически важной для него информации.
И последнее. Хороша тв анимация, которая не заметна. Ведь ею мы действуем на подсознание, а не на сознание. Анимация обеспечивает комфорт, не вау-эффект. Он впечатлит один раз, а повторно будет раздражать, особенно если вашим продуктом пользуются постоянно. Нет, правда, спросите — а там-то была ли анимация или нет. В случае, если затруднятся с ответом — все сделано правильно.
Все правильно, задача была именно минимальными усилиями логировать ход работы потенциально проблемных мест, а проблема сокрытия данных даже не возникала.
Так бывает, когда разработчик один, а задача достаточно специфическая. Библиотечка покрыла все нужды своего создателя и логично прекратила свое развитие
DOS, Windows, CP/M, OS/2, Solaris...
Проблема в протоколе взаимодействия программ.
Какая же архитектура лучше?
с кодировками всегда ужас. особенно, с однобайтовыми
ХА ХА ХА!!! Всмысле, мяу. >^.^<
недоразвитость консоли в win растет из-за драконовских требований прямой и обратной совместимости: консоль является одной из главных подсистем ОС, и написаны тысячи и тысячи консольных приложений, которые должны работать в консоли — иначе кому нужна консоль с двумя с половиной приложениями?
таким образом, мы либо творим чудеса и сохраняем совместимость, улучшая консоль, либо переписываем все приложения, адаптируя к улучшениям консоли.
таким образом, хоть изначально подход windows console лучше (структура более целостна, чем поток), но подход *nix "всё есть файл"(а точнее, символьный поток) позволяет обогащать возможности при сохранении совместимости ("простое лучше сложного") и взаимодействовать совершенно разным стстемам и программам.
что значит, что открытие ядра не решит проблему.
и подтверждение тому — куча сторонних разработок типа ConEmu, которые все равно глючат и тормозят.
А почему, собственно, большинство комментаторов решило, что технология значительно подешевеет? Даже если предположить, что себестоимость будет низка, то сразу обложат миккимаус-патентами стоимостью в "атомоход". Патентодержатели, разумеется, озолотятся, но они также решат, что не стоит технологию давать большинству.
Далее, вполне может оказаться, что она не так уж желанна, но это поймут единицы, и спрос не упадет настолько, чтобы имело смысл снижать цену...
Что Вы говорите… То-то настроить отправку уведомлений с моего сервера на мой же ящик так, чтобы он хотя бы в "спам" попал — нужны танцы под луной и кровь девственницы…
А тут Вы мне глаза открыли, мы все уже 20 лет в опасности...
Это все ягодки… Ждем доступ по одобрению заявки из ФСБ, с обязательным MITM сертификатом и предоставлением ключей, рейтинги "благонадежности" и посещение публичных мест по паспорту.
sarcasm tag is deprecated
Тем более, что уже такое было...
А что в России? ЕМНИП, в метро установили такую систему
Поэтому зачастую проще взять существующую ВМ, сторонний парсер+интерпретатор, и только написать для этого парсера понятную ему грамматику.
Либо (если похожий язык есть, но нужно его расширить\изменить) — можно написать транспилер в целевой язык и положиться на свойства платформы этого языка. Этот способ привлекателен тем, что сам транспилер не обязан быть быстрым, многие конструкции просто перенести 1:1, и реализовать его можно хоть на
любимыхрегулярках.Для языка Си как основы вообще может оказаться достаточным применение макросов и его препроцессора
Далее, как уже было замечено, сильно не хватает операций ветвления (условия, переходы), чтобы можно было написать нелинейный код. Конечно, для этого потребуется понятие адресации (абсолютной и\или относительной, возможно, меток) — интересно, какой подход выбрали (бы) Вы.
И последнее: всё описанное с легкостью реализуется на любом ЯП, не только Rust, но и C\C++, Java\C#, Python\Ruby etc.
связываю это утверждение со вступлением бесплатного и открытого ПО в период зрелости, когда таковое перестало уступать по удобству использования коммерческому, а также с ослаблением ассоциацивных связей (вроде графический редактор = фотошоп). Проще стало установить бесплатный аналог, чем искать подходящий кряк, который периодически может слетать.
Лично давно перешел на бесплатные и открытые аналоги и, поскольку не нужен спецсофт — только выиграл от этого.
Плюс, считаю правильным поддерживать (благодарить) материально коллег-энтузиастов, которые несмотря на все — смогли дать мне такую возможность.
Нет. давайте попробуем отделить мух от котлет, ибо мысли в статье здравые, а иллюстрации все портят.
Итак, когда нужна анимация и когда не нужна? Лично я мыслю так:
Резкость перехода между экранами раздражает. Нет ничего хуже, чем полностью сменить содержание… Разве что представив между ними пустой экран. Нет, не нужно морфинга, достаточно простых шторок или перелистывания, это дрбавляет комфорта для пользователя.
Анимация должна быть логичной. Да, давайте сделаем плавными движения ползунка, переключателя, и полосу прогресса плавной. В жизни нет мгновенно меняющихся элементов, поэтому не будем раздражать пользователя.
Анимация должна быть быстрой… если речь не о слайдшоу. сотенные доли секунды, максимум полсекунды, не заставят пользователя ждать мгновенного результата, а психологический эффект будет достигнут. Никто не ждет мультфильм и демонстрацию крутости разработчика.
Анимация должна быть уместной. т.е. никакого морфинга между не связанными между собой элементами (пример из статьи превращения кнопки в окружеость ужасен). Пожалуйста, не заставляйте меня интуитивно искать связь там, где ее нет. Даже если это общее место для бывшего и настоящего элементов.
Да, анимацию можно (но осторожно) использовать для привлечения внимания. К событиям, требующем безотлагательного внимания. И вместе с тем не уводите внимание от значительных элементов к значительным (для пользователя. Конечно, вам важнее обратить внимание на рекламу, которая снизит ваши расходы, но клиент скорее обозлится). И тем более, не зациуливайте анимацию, если элемент не ведет к критически важной для него информации.