История изменений

Скорее всего «сложный эффект» представляет собой пару красивых формул в цикле по пикселям.

Это очень сильное упрощение. Вот к примеру, описание математики по ту сторону популярного плагина Liquid Rescale.

Незначительная часть кода, по сравнению с ублажением пользователя свистками-бубенцами.

Простите, но вы ерунду пишите. Расскажите о многочисленых свистелках в интерфейсе GIMP, тормозящих его работу. Мы вас внимательно слушаем, ваше мнение очень важно для нас. Да покажите хотя бы заметные преимущества ImageMagick перед GIMPом по скорости (не говоря о том, что для индивидуальной работы превью используемого эффекта и возможность отмены и комбинирования — очень важна). А теперь тоже самое — для Blender. Вот лично я люблю PovRay, но почему народ таки предпочитает первый продукт? И почему они оба написаны на C/C++ а не на питоне или JavaScript?

В контексте UI на сях

Я бы не стал сводить даже какой-нибудь Aseprite к чистому UI. Не, редакторы спрайтов и векторов на JS уже пишут (а потому-что online), как и собственно игры (а потому что то же самое), но когда это всё запускается более-менее одновременно (нормальная для разработчика ситуация) почувствовать что «железо жмёт» не так сложно, особенно если ты, к примеру, из-за мобильности в пространстве предпочитаешь компактные ноутбуки. А если ты разрабатываешь, к примеру, стратегическую игру со сложной и глубокой симуляцией, то там и даже не используя графику можно с не такими уж минимальными требованиями к ресурсам столкнуться.

Ладно, бог с ней с графикой, бог с ними с играми, но да, я всё ещё предпочитаю текстовые редакторы с ядром на C, C++, FreePascal в конце-то концов (vim, emacs, scintilla etc.) которые не тормозят, и показывают приемлимые результаты на по-настоящему больших текстах, какую бы скриптовую обвеску «для UI и бизнес логики» мы на них не навешали. Внешний слой (те самые свистки и бубенцы) может быть на питоне, луа, тикле или чём угодно (я сейчас больше про scintilla, в emacs то lisp) — но ядро — нет. Ок, Microsoft сделала свой VSCode на чистом JS, но когда для того, чтобы обеспечить нормальную работу текстового редактора им пришлось применить довольно изошрённую многопоточность и умную деградацию возможностей при нехватке ресурсов — простите, но вы (все, с MS во главе) втираете мне какую-то дичь.

И да, принесите мне в студию мало-мальски популярный текстовый редактор на Питоне или чём-то аналогичном (c js то всё ясно — он вездесущ, и причины можно понять), без сцайнтилы и чего-то похожего «внутре» — поговорим за свистки и бубенцы дальше, а пока — Dixi.

Скорее всего «сложный эффект» представляет собой пару красивых формул в цикле по пикселям.

Это очень сильное упрощение. Вот к примеру, описание математики по ту сторону популярного плагина Liquid Rescale.

Незначительная часть кода, по сравнению с ублажением пользователя свистками-бубенцами.

Простите, но вы ерунду пишите. Расскажите о многочисленых свистелках в интерфейсе GIMP, тормозящих его работу. Мы вас внимательно слушаем, ваше мнение очень важно для нас. Да покажите хотя бы заметные преимущества ImageMagick перед GIMPом по скорости (не говоря о том, что для индивидуальной работы превью используемого эффекта и возможность отмены и комбинирования — очень важна). А теперь тоже самое — для Blender. Вот лично я люблю PovRay, но почему народ таки предпочитает первый продукт? И почему они оба написаны на C/C++ а не на питоне или JavaScript?

В контексте UI на сях

Я бы не стал сводить даже какой-нибудь Aseprite к чистому UI. Не, редакторы спрайтов и векторов на JS уже пишут (а потому-что online), как и собственно игры (а потому что то же самое), но когда это всё запускается более-менее одновременно (нормальная для разработчика ситуация) почувствовать что «железо жмёт» не так сложно, особенно если ты, к примеру, из-за мобильности в пространстве предпочитаешь компактные ноутбуки. А если ты разрабатываешь, к примеру, стратегическую игру со сложной и глубокой симуляцией, то там и даже не используя графику можно с не такими уж минимальными требованиями к ресурсам столкнуться.

Ладно, бог с ней с графикой, бог с ними с играми, но да, я всё ещё предпочитаю текстовые редакторы с ядром на C, C++, FreePascal в конце-то концов (vim, emacs, scintilla etc.) которые не тормозят, и показывают приемлимые результаты на по-настоящему больших текстах, какую бы скриптовую обвеску «для UI и бизнес логики» мы на них не навешали. Внешний слой (те самые свистки и бубенцы) может быть на питоне, луа, тикле или чём угодно (я сейчас больше про scintilla, в emacs то lisp) — но ядро — нет. Ок, Microsoft сделала свой VSCode на чистом JS, но когда для того, чтобы обеспечить нормальную работу текстового редактора им пришлось применить довольно изошрённую многопоточность и умную деградацию возможностей при нехватке ресурсов — простите, но вы втираете мне какую-то дичь.

И да, принесите мне в студию мало-мальски популярный текстовый редактор на Питоне или чём-то аналогичном (c js то всё ясно — он вездесущ, и причины можно понять), без сцайнтилы и чего-то похожего «внутре» — поговорим за свистки и бубенцы дальше, а пока — Dixi.

Скорее всего «сложный эффект» представляет собой пару красивых формул в цикле по пикселям.

Это очень сильное упрощение. Вот к примеру, описание математики по ту сторону популярного плагина Liquid Rescale.

Незначительная часть кода, по сравнению с ублажением пользователя свистками-бубенцами.

Простите, но вы ерунду пишите. Расскажите о многочисленых свистелках в интерфейсе GIMP, тормозящих его работу. Мы вас внимательно слушаем, ваше мнение очень важно для нас. Да покажите хотя бы заметные преимущества ImageMagick перед GIMPом по скорости (не говоря о том, что для индивидуальной работы превью используемого эффекта и возможность отмены, комбинирования — очень важна). А теперь тоже самое — для Blender. Вот лично я люблю PovRay, но почему народ таки предпочитает первый продукт? И почему они оба написаны на C/C++ а не на питоне или JavaScript?

В контексте UI на сях

Я бы не стал сводить даже какой-нибудь Aseprite к чистому UI. Не, редакторы спрайтов и векторов на JS уже пишут (а потому-что online), как и собственно игры (а потому что то же самое), но когда это всё запускается более-менее одновременно (нормальная для разработчика ситуация) почувствовать что «железо жмёт» не так сложно, особенно если ты, к примеру, из-за мобильности в пространстве предпочитаешь компактные ноутбуки. А если ты разрабатываешь, к примеру, стратегическую игру со сложной и глубокой симуляцией, то там и даже не используя графику можно с не такими уж минимальными требованиями к ресурсам столкнуться.

Ладно, бог с ней с графикой, бог с ними с играми, но да, я всё ещё предпочитаю текстовые редакторы с ядром на C, C++, FreePascal в конце-то концов (vim, emacs, scintilla etc.) которые не тормозят, и показывают приемлимые результаты на по-настоящему больших текстах, какую бы скриптовую обвеску «для UI и бизнес логики» мы на них не навешали. Внешний слой (те самые свистки и бубенцы) может быть на питоне, луа, тикле или чём угодно (я сейчас больше про scintilla, в emacs то lisp) — но ядро — нет. Ок, Microsoft сделала свой VSCode на чистом JS, но когда для того, чтобы обеспечить нормальную работу текстового редактора им пришлось применить довольно изошрённую многопоточность и умную деградацию возможностей при нехватке ресурсов — простите, но вы втираете мне какую-то дичь.

И да, принесите мне в студию мало-мальски популярный текстовый редактор на Питоне или чём-то аналогичном (c js то всё ясно — он вездесущ, и причины можно понять), без сцайнтилы и чего-то похожего «внутре» — поговорим за свистки и бубенцы дальше, а пока — Dixi.

Скорее всего «сложный эффект» представляет собой пару красивых формул в цикле по пикселям.

Это очень сильное упрощение. Вот к примеру, описание математики по ту сторону популярного плагина Liquid Rescale.

Незначительная часть кода, по сравнению с ублажением пользователя свистками-бубенцами.

Простите, но вы ерунду пишите. Расскажите о многочисленых свистелках в интерфейсе GIMP, тормозящих его работу. Мы вас внимательно слушаем, ваше мнение очень важно для нас. Да покажите хотя бы заметные преимущества ImageMagick перед GIMPом по скорости (не говоря о том, что для индивидуальной работы превью используемого эффекта и возможность отмены, комбинирования — очень важна). А теперь тоже самое — для Blender. Вот лично я люблю PovRay, но почему народ таки предпочитает первый продукт? И почему они оба написаны на C/C++ а не на питоне или JavaScript?

В контексте UI на сях

Я бы не стал сводить даже какой-нибудь Aseprite к чистому UI. Не, редакторы спрайтов и векторов на JS уже пишут (а потому-что online), как и собственно игры (а потому что то же самое), но когда это всё запускается более-менее одновременно (нормальная для разработчика ситуация) почувствовать что «железо жмёт» не так сложно, особенно если ты, к примеру, из-за мобильности в пространстве предпочитаешь компактные ноутбуки. А если ты разрабатываешь, к примеру, стратегическую игру со сложной и глубокой симуляцией, то там и даже не используя графику можно с не такими уж минимальными требованиями к ресурсам столкнуться.

Ладно, бог с ней с графикой, бог с ними с играми, но да, я всё ещё предпочитаю текстовые редакторы с ядром на C, C++, FreePascal в конце-то концов (vim, emacs, scintilla etc.) которые не тормозят, и показывают приемлимые результаты на по-настоящему больших текстах, какую бы скриптовую обвеску «для UI и бизнес логики» мы на них не навешали. Внешний слой (те самые свистки и бубенцы) может быть на питоне, луа, тикле или чём угодно (я сейчас больше про scintilla, в emacs то lisp) — но ядро — нет. Ок, Microsoft сделала свой VSCode на чистом JS, но когда для того, чтобы обеспечить нормальную работу текстового редактора им пришлось применить довольно изошрённую многопоточность и умную деградацию возможностей при нехватке ресурсов — простите, но вы втираете мне какую-то дичь.

И да, принесите мне в студию мало-мальски популярный текстовый редактор на Питоне или чём-то аналогичном (c js то всё ясно — он вездесущ, и причины можно поняь), без сцайнтилы и чего-то похожего «внутре» — поговорим за свистки и бубенцы дальше, а пока — Dixi.