Здравствуйте, Kolesiki, Вы писали:
K>>>Никакого кода! Декларативно — значит отдельно от мух. AM>>Это зря. Конечно смешивать бизнес логику и рисование не надо, но если язык позволяет — то имеет смысл использовать тот же язык.
K>Сам себе противоречишь — не смешивать и "тот же язык".
не вижу противоречий. То что вьюху лучше написать в отдельном классе логично, но если на том же языке — почему нет? K>Более того — в C# нет вообще ничего, что хоть как-то делало бы его удобным для UI. Даже в HTML больше "визуальности", чем в C#.
Да вроде развивается язык, можно многие вещи достаточно декларативно писать, не сравнить с 1й версией AM>>И не надо какой-то ещё один язык писать.
K>Надо. Для того и придумали идею DSL.
А если новый DSL — это всё тот же C#, то вообще красота.
AM>>Подобным путём пошли не только Eto, но и для мобилок swiftUI, flutter, compose: тоже на swift, dart, kotlin UI пишут.
K>"Ну и дураки!" (ц) Нет смысла равняться на баранов, если они бегут в пропасть. Ну и попутно, надо расширять свой лоб, чтоб не мыслить узко: ведь дело не только в том, чтобы "побырому накрапать гуйню" — так пишут студенты одноразовый код.
Вполне неплохой код получается на всех этих языках, легко пишется и потом читается, сопровождается K> А так, по-хорошему, есть и другие попутные преимущества именно отдельного ГУЙ-языка:
K>DSL позволяет меньше ошибаться в коде, меньше вообще его писать. <Button> — за этим может скрываться 20 строчек кода! Причём проверенного.
а если будет написано Button() всё будет так же, плюс компилятор сразу и типы проверит. K>DSL можно "отдать на сторону" для дизайна. Как известно, программисты — отвратные дизайнеры, поэтому ГУЙ должен делать отдельный UI/UX подаван.
Сколько лет слышу эту байку, а в живую пока не видел — на этих DSL всё равно пишут программисты. Неожиданно надо уметь программировать, чтобы на них рисовать, дизайнеры обычно отвратные программисты. K>DSL позволяет легко улучшать низлежащий код — декларации остаются, а контрол хорошеет.
Любая библиотека может быть улучшена без изменения внешних соглашений K>DSL легко перезагружать, он динамичен. Низлежащие onClick'и остаются, а ГУЙ полностью меняется одним движением руки.
многие умеют hot-reload K>DSL в принципе проще — и структурно, и для изучения, и для улучшения (сопровождения).
на мой взгляд код C# упрощает чтение кода, поскольку пограммист его уже знает.
AM>>Меня только new здесь смущает, а так на мой взгляд читается не хуже вашего предложения. K>Я и говорю — "студенты пишут одноразовый код" — тогда да, почти не хуже. Но если прочитать приведённый список, то "сишарповая гуйня" — тот ещё отстой. Увы.
На мой взгляд, просто не очень winforms восстребован, поэтму Eto не очень продвинута.
Для WPF вот вполне приятная либа: https://github.com/VincentH-Net/CSharpForMarkup
Здравствуйте, AntoxaM, Вы писали:
AM>Здравствуйте, Kolesiki, Вы писали:
K>>>>Никакого кода! Декларативно — значит отдельно от мух. AM>>>Это зря. Конечно смешивать бизнес логику и рисование не надо, но если язык позволяет — то имеет смысл использовать тот же язык.
K>>Сам себе противоречишь — не смешивать и "тот же язык". AM>не вижу противоречий. То что вьюху лучше написать в отдельном классе логично, но если на том же языке — почему нет?
Каком "том же"?? UI — декларативный DSL. Который, повторюсь, позволяет "смешивать бизнес логику и рисование не надо".
K>>Более того — в C# нет вообще ничего, что хоть как-то делало бы его удобным для UI. Даже в HTML больше "визуальности", чем в C#. AM>Да вроде развивается язык, можно многие вещи достаточно декларативно писать, не сравнить с 1й версией
Не надо путать ЯОН с декларативным UI — это вообще "разные миры". То, что в каком-то ЯОН стало чуть лучше что-то писать, вообще никак не делает его пригодным для UI. См. мой пример выше — там C# даже близко не стоял.
K>>Надо. Для того и придумали идею DSL. AM>А если новый DSL — это всё тот же C#, то вообще красота.
C# не может быть "новым DSL", так как уже является стандартным C#.
K>>DSL можно "отдать на сторону" для дизайна. Как известно, программисты — отвратные дизайнеры, поэтому ГУЙ должен делать отдельный UI/UX подаван. AM>Сколько лет слышу эту байку, а в живую пока не видел
Ограниченность личного опыта — не повод для общих суждений. В нищебродной России программисты даже принтер заправляют — но это же не повод??
Дизайнер — отдельная профессия, именно для них делался целый Blend. Другой вопрос, что освоить раздутое г***но типа WPF даже программистам сложно, поэтому инструмент тихо загнулся.
А как раз ПРОСТОЙ язык позволит струячить UI не задевая прогера: он делает скелет, дизайнер "крутит ползунки".
AM> на этих DSL всё равно пишут программисты
Потому и пишут, что DSL — гогно! Слишком сложен. Плюс, индустрию надо РАЗВИВАТЬ, а не как MS — швырнула в толпу WPF и всё, делайте чё хотите, вот вам кусок нашего гения!
По фотошопу курсы есть — по WPF тоже должны быть, индустрия должна быть уверена в стабильности платформы и её развитии. А WPF просто забросили НА ГОДЫ — ну и кто будет в это вкладываться??
K>>DSL легко перезагружать, он динамичен. Низлежащие onClick'и остаются, а ГУЙ полностью меняется одним движением руки. AM> многие умеют hot-reload
Мне нужны не "многие", а у хорошего GUI DSL. Он пока ещё никем не написан.
K>>DSL в принципе проще — и структурно, и для изучения, и для улучшения (сопровождения). AM>на мой взгляд код C# упрощает чтение кода, поскольку пограммист его уже знает.
Ну да, см. пример про принтер. А потом придёт какой-нть "ЛИСПовод" или вообще "дизайнер-самоучка" — "А чоэта у вас тут C#, я не уметь!". ТЫ его будешь своему "цэшарпу" учить??
Теги HTML осваивает даже секретарша, благодаря чему на заре Тырнета мы поимели миллионы "хомепаг". C# — отдельный сложный язык, в нём без программистского бэкграунда делать нечего.
Корень проблемы — "совок" в голове: когда программист за нищенскую зарплату тянет сотню профессий. Просто представь: в мире есть ОТДЕЛЬНЫЙ дизайнер, который "умеет в цвета". Всё. ЕМУ ты это объясни, что "C# — это круто!" Тебя даже слушать не будут, ибо не круто.
AM>На мой взгляд, просто не очень winforms восстребован, поэтму Eto не очень продвинута.
Сложно сказать, кто именно и по каким критериям считал это "невостребован". Вот Бейсик — очевидно, постоянно в догоняющих, сам язык многословный, неуклюжий, "детский" какой-то. По нему я уверенно могу сказать "живой труп, никак не сваливающийся на обочину истории" (в осн. благодаря чудилам из M$). А вот WinFroms... очевидно, что она имеет серьёзные преимущества, чтобы вот так её голословно хоронить. Я потому и занялся декларациями ДЛЯ WINFORMS, т.к. сама технология вполне мощная, просто клоунам в MS "скучно" её улучшать.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, AntoxaM, Вы писали:
AM>>Здравствуйте, Kolesiki, Вы писали:
K>>>>>Никакого кода! Декларативно — значит отдельно от мух. AM>>>>Это зря. Конечно смешивать бизнес логику и рисование не надо, но если язык позволяет — то имеет смысл использовать тот же язык.
K>>>Сам себе противоречишь — не смешивать и "тот же язык". AM>>не вижу противоречий. То что вьюху лучше написать в отдельном классе логично, но если на том же языке — почему нет?
K>Каком "том же"?? UI — декларативный DSL. Который, повторюсь, позволяет "смешивать бизнес логику и рисование не надо".
Пока так и не понял в чём преимущество UI на своём языке. Плохой программист всё равно найдёт место где наговнокодить.
K>>>Более того — в C# нет вообще ничего, что хоть как-то делало бы его удобным для UI. Даже в HTML больше "визуальности", чем в C#. AM>>Да вроде развивается язык, можно многие вещи достаточно декларативно писать, не сравнить с 1й версией
K>Не надо путать ЯОН с декларативным UI — это вообще "разные миры". То, что в каком-то ЯОН стало чуть лучше что-то писать, вообще никак не делает его пригодным для UI. См. мой пример выше — там C# даже близко не стоял.
про c# мне тяжело судить, но вот когда смотрю и пишу на jetpack compose или swiftUI, то вполне себе выглядит как DSL, работает как DSL, крякает как DSL и при этом является кодом на kotlin и swift.
K>>>Надо. Для того и придумали идею DSL. AM>>А если новый DSL — это всё тот же C#, то вообще красота. K>C# не может быть "новым DSL", так как уже является стандартным C#.
библиотека может позволить коду на C# выглядеть как DSL.
K>>>DSL можно "отдать на сторону" для дизайна. Как известно, программисты — отвратные дизайнеры, поэтому ГУЙ должен делать отдельный UI/UX подаван. AM>>Сколько лет слышу эту байку, а в живую пока не видел
K>Ограниченность личного опыта — не повод для общих суждений. В нищебродной России программисты даже принтер заправляют — но это же не повод?? K>Дизайнер — отдельная профессия, именно для них делался целый Blend. Другой вопрос, что освоить раздутое г***но типа WPF даже программистам сложно, поэтому инструмент тихо загнулся. K>А как раз ПРОСТОЙ язык позволит струячить UI не задевая прогера: он делает скелет, дизайнер "крутит ползунки".
Интересно было бы такое увидеть, но пока звучит как фантастика — очень непросто создать инструмент, удобный дизайнеру и позволяющий его потом использовать программистом.
Вспоминая Blend, который MS как раз под этим соусом пытался протолкнуть, как оно — где-то видно его, много дизайнеров его освоили?
В какого дизайнера ни плюнь — умеет фигму, иногда adobe или скетч. Статический html уже не все могут, а уж в какой-нибудь angular/react уже вряд ли осилят.
AM>> на этих DSL всё равно пишут программисты
K>Потому и пишут, что DSL — гогно! Слишком сложен. Плюс, индустрию надо РАЗВИВАТЬ, а не как MS — швырнула в толпу WPF и всё, делайте чё хотите, вот вам кусок нашего гения! K>По фотошопу курсы есть — по WPF тоже должны быть, индустрия должна быть уверена в стабильности платформы и её развитии. А WPF просто забросили НА ГОДЫ — ну и кто будет в это вкладываться??
DSLи сложные, потому что тема сложная.
AM>>на мой взгляд код C# упрощает чтение кода, поскольку пограммист его уже знает.
K>Ну да, см. пример про принтер. А потом придёт какой-нть "ЛИСПовод" или вообще "дизайнер-самоучка" — "А чоэта у вас тут C#, я не уметь!". ТЫ его будешь своему "цэшарпу" учить??
для UI из всего c# надо будет знать достаточно небольшое его подмножество, разницы с отдельным языком я не вижу.
Дизайнер будет уметь в фигму, а c# или ваш язык не будет знать и не захочет знать.
Ну а если, лисповод придёт программировать под .net на c#, и при этом будет жаловаться — а чё это у вас тут с#, я удивлюсь.
K>Теги HTML осваивает даже секретарша, благодаря чему на заре Тырнета мы поимели миллионы "хомепаг". C# — отдельный сложный язык, в нём без программистского бэкграунда делать нечего.
для UI из всего c# надо будет знать достаточно небольшое его подмножество, сложность будет не выше html.
K>Корень проблемы — "совок" в голове: когда программист за нищенскую зарплату тянет сотню профессий. Просто представь: в мире есть ОТДЕЛЬНЫЙ дизайнер, который "умеет в цвета". Всё. ЕМУ ты это объясни, что "C# — это круто!" Тебя даже слушать не будут, ибо не круто.
ну так тебе этот дизайнер нарисует в фигме картинки с нужными цветами и на этом всё — дальше ему сложно и не понятно.
AM>>На мой взгляд, просто не очень winforms восстребован, поэтму Eto не очень продвинута.
K>Сложно сказать, кто именно и по каким критериям считал это "невостребован". Вот Бейсик — очевидно, постоянно в догоняющих, сам язык многословный, неуклюжий, "детский" какой-то. По нему я уверенно могу сказать "живой труп, никак не сваливающийся на обочину истории" (в осн. благодаря чудилам из M$). А вот WinFroms... очевидно, что она имеет серьёзные преимущества, чтобы вот так её голословно хоронить. Я потому и занялся декларациями ДЛЯ WINFORMS, т.к. сама технология вполне мощная, просто клоунам в MS "скучно" её улучшать.
Возможно это поыт такой у меня, и на самом деле продолжают писать на нём, но все знакомые WinForms программисты уже давно WinForms в глаза не видели.
Здравствуйте, AntoxaM, Вы писали:
K>>>>Надо. Для того и придумали идею DSL. AM>>>А если новый DSL — это всё тот же C#, то вообще красота. K>>C# не может быть "новым DSL", так как уже является стандартным C#. AM>библиотека может позволить коду на C# выглядеть как DSL.
Полностью согласен. Не понимаю, зачем плодить языки программирования, если они не улучшают существующие, не повышают продуктивность и т.п.
Есть масса библиотек генераторов кода, в т.ч. для генерации JavaScript и т.п., например:
Из современных возможно (не разбирался пока подробно): https://anglesharp.github.io/
AM>>> на этих DSL всё равно пишут программисты AM>>>на мой взгляд код C# упрощает чтение кода, поскольку пограммист его уже знает. AM>для UI из всего c# надо будет знать достаточно небольшое его подмножество, разницы с отдельным языком я не вижу. AM>для UI из всего c# надо будет знать достаточно небольшое его подмножество, сложность будет не выше html.
Полностью согласен, кроме того можно ведь реально сделать ограничения по синтаксису, чтобы знатоки не наворотили слишком крутых конструкций, нечитаемых потом нубами-дизайнерами.
Т.е. добавить специальный предварительный синтакс Analyzer перед сборкой, который будет отпинывать сложные конструкции как нежелательные в данном проекте.
AM>>>На мой взгляд, просто не очень winforms восстребован, поэтму Eto не очень продвинута.
Интересно, насколько расширяема Eto? Например, насколько сложно описать для нее дополнительные конструкции для компонентов DevExpress WinForms?
K>>Сложно сказать, кто именно и по каким критериям считал это "невостребован". Вот Бейсик — очевидно, постоянно в догоняющих, сам язык многословный, неуклюжий, "детский" какой-то.
В этом его преимущество, программы на нем легко читаются и через 10 лет после написания.
>По нему я уверенно могу сказать "живой труп, никак не сваливающийся на обочину истории" (в осн. благодаря чудилам из M$).
Надеюсь, вы понимаете, что в рамках MS Office даже VBA (подмножество VB6) живее всех живых, хотя какие-то значительные инновации в нем появлялись более 20 лет назад?
> А вот WinFroms... очевидно, что она имеет серьёзные преимущества, чтобы вот так её голословно хоронить. Я потому и занялся декларациями ДЛЯ WINFORMS, т.к. сама технология вполне мощная, просто клоунам в MS "скучно" её улучшать.
Согласен, очень экономная технология по затратам времени на разработку несложных UI и потом ресурсов для запуска.
Windows раньше славилась очень экономичным потреблением ресурсов для GUI приложений. Более бедный UI на базе X11 отъедал в разы больше оперативки и поэтому в 90-ые использовался большей частью на дорогих рабочих станциях UNIX типа SGI, Sun, etc.. Windows 95 же работала на относительно доступных уже в то время персоналках X86 с 4-16 Mega (а НЕ гига, как сейчас) bytes оперативной памяти.
WinForms по сути своей — это ведь надстройка как раз над тем самым первозданным относительно лайтовым WinAPI, поэтому программы на WinForms не такие прожорливые к оперативке как WPF и другие более современные.
Мало того, WinForms можно запускать на Linux из под WINE, а значит и в OCI контейнерах, например в Docker или Kubernetes например с доступом по VNC (и с сайтиков noVNC), а значит можно обеспечить деплой, сравнимый с современными смузихлебными веб технологиями:
Здравствуйте, Kolesiki, Вы писали:
MD>>Ждём. Раньше и C#-код сам по себе был windows-only. А сейчас гляди-ка — NET Core работает на линуксах.
K>Жди. Только вот перенос WPF даже не в планах(!!!). Что говорит как о квалификации его архитекторов, так и "воплощателей". И вообще M$ уже не интересен WPF — они побежали вперёд со своими Кошмаринами, MAUI и прочей белибердой. Как только на этих бородатых школотронов кончатся деньги (и терпение), их погонят ссаной метлой пилить "мультиплатформ" на морозе.
А чем Avalonia хуже WPF кроме того, что для нее пока не делают массово компоненты гиганты отрасли компонентостроения типа DevExpress, Telerik, etc. ?
Тебя даже слушать не будут, ибо не круто.
