Re: Когда императивность переходит в декларативность... - Компьютерные священные войны

Вот императивный способ создания GUI и это плохо:

Form mainForm = new Form();

Button blueButton = new Button();
blueButton.Color = Colors.Blue;

mainForm.Children.Add(blueButton);

А если всего чуток изменить, то можно без особой переделки сделать чтобы все было декларативно. А именно:

Form(
   Children: [
      Button(
         Color: Colors.Blue
      )
   ]
)

Т.е. делаем new не обязательным, создание объекта без него. И даем возможность задать в конструкторе свойства. И все! Теперь без переделки ядра и без создания нового языка — мы можем писать все декларативно. Не нужен XAML или еще что. Получается что все выглядит как JSON или подобие его — все просто и ясно, даже парсить можно парсером в 10 срок кода.

Все гениальное — просто.

Здравствуйте, Shmj, Вы писали:

S>Вот императивный способ создания GUI и это плохо:

S>

S>Form mainForm = new Form();

S>Button blueButton = new Button();
S>blueButton.Color = Colors.Blue;

S>mainForm.Children.Add(blueButton);
S>

ты же в курсе что в современном C# можно так:

Form mainForm = new () {
    Children = {
        new Button() { Color = Colors.Blue }
    }
}

?

Причем кроме target-typed new можно было еще 10+ лет назад так написать. А сейчас можно потребовать инициализировать свойства при создании.

S>А если всего чуток изменить, то можно без особой переделки сделать чтобы все было декларативно. А именно:

S>

S>Form(
S>   Children: Button(
S>      Color: Colors.Blue
S>   )
S>)
S>

S>Все гениальное — просто.

Гм, а что именно тут "гениально"? Сокращение контекста путем объявления его локальным?

Если б вот так же можно было императивность-декларативность поменять на функциональность, вот это было б интересно. Особенно если еще сайд-эффекты устранить при этом.

Здравствуйте, gandjustas, Вы писали:

S>>Все гениальное — просто.
G>Ага, и придумано давно.

Тогда зачем придумали XAML, если можно было на этом построить GUI?

Здравствуйте, Shmj, Вы писали:

S>Тогда зачем придумали XAML, если можно было на этом построить GUI?

Чтобы вёрсткой мог заниматься не программист, как это происходит в мире HTML + CSS.
Только по-моему у них это не очень получилось

Здравствуйте, Shmj, Вы писали:

S>Теперь без переделки ядра и без создания нового языка — мы можем писать все декларативно.

Нет. Мы по-прежнему можем писать императивно, только теперь с мудацким синтаксисом.

Порядок создания всё так же определяется кодом (делая невозможными оптимизации и ленивые загрузки), только теперь неявно. Расширения языка разметки, в частности принятое повсеместно игнорирование неизвестного, невозможно. И т.д. и т.п.

Далее. Суть хорошей разметки не в языке описания, а в модели хранения (DOM). Это знает любой, кто реально что-то верстает. Оттого, что ты компиляцией и исполнением построишь иерархию дотнетных объектов в памяти, работать с ней удобнее не станет. Или ты предлагаешь тому, кто будет этим пользоваться, вместо DevTools/Inspector/они-по-разному-называются-в-разных-движках какой-нибудь дотнетный монитор-дизассемблер запускать?

Здравствуйте, karbofos42, Вы писали:

K>Чтобы вёрсткой мог заниматься не программист, как это происходит в мире HTML + CSS.
Ну мы на примере HTML + CSS видим что это было ошибкой.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

Здравствуйте, CreatorCray, Вы писали:

CC>Ну мы на примере HTML + CSS видим что это было ошибкой.

Ну, у этих конечно не сами дизайнеры разметкой занимаются, но всё же существуют отдельные верстальщики, которые разгружают программистов.
XAML только по-моему вышел ещё хуже и в итоге просто программисты помимо C# ещё с ним разбираются и не у всех это получается

Казалось бы: многолетний опыт всяких Dreamviewer должен был показать, что и Blend скорее всего не взлетит и придётся всю разметку ручками прописывать, чем дизайнеры заниматься точно не смогут и не захотят.
Но у Microsoft свой путь и они решили сами по граблям прогуляться.
Уже собственно похоже почти наигрались, что закидывают альтернативы XAML:
https://github.com/dotnet/Comet

Здравствуйте, Shmj, Вы писали:

S>Все гениальное — просто.
Простое легко сделать простым.
Ты наваяй пример с десятком контролов как минимум, чтобы всё прыгало и менялось, по событиям и прочим таймерам, посылало запросы. Чтобы функциональность покрывалась тестами, которые не сыпятся при небольшой модификации дизайна. Чтобы код был читабельным, с минимумом копипасты, простотой переиспользования, и легко поддавался рефакторингу, внесению новых изменений.

Здравствуйте, karbofos42, Вы писали:

K>Чтобы вёрсткой мог заниматься не программист, как это происходит в мире HTML + CSS.
K>Только по-моему у них это не очень получилось

Т.е. дизайнер по умолчанию может понимать только XML-подобный синтаксис?

Т.е. это код, по этому дизайнер не поймет:

Form(
   Children: [
      Button(
         Color: Colors.Blue
      )
   ]
)

А это:

<Form>
   <Children>
      <Button Color="Blue" />
   </Children>
</Form>

— не смотря на громоздкость — магическим образом сразу поймет?

Здравствуйте, Shmj, Вы писали:

S>Вот императивный способ создания GUI и это плохо:

S>А если всего чуток изменить, то можно без особой переделки сделать чтобы все было декларативно. А именно:

S>Все гениальное — просто.

Первый вариант хорош, а второй плох хотя бы тем, что по первому можно нормально пройти отладчиком, а по второму хрен.
Я в своих проектах после нескольких лет геморроя на пустом мест запретил девелоперам использовать декларативный стиль в бизнес логике, кроме элементарных случаев,
т.к. он не поддается отладке ни дебаггером, ни логгером.

А парсить этот твой код непонятно зачем надо.

Здравствуйте, karbofos42, Вы писали:

K>https://github.com/dotnet/Comet

Fool me seven times — shame on you. Fool me eight times — shame on me! (Futurama).

Здравствуйте, Shmj, Вы писали:

S>Тогда зачем придумали XAML, если можно было на этом построить GUI?
Потому что xml легко парсить, а C# не очень, особенно на момент создания XAML. Xaml может быть использование .net, например winrt c++ приложения могут использовать Xaml. Не говоря уже о программах-дизайнерах UI.

Здравствуйте, Shmj, Вы писали:

S>Т.е. дизайнер по умолчанию может понимать только XML-подобный синтаксис?

Нет. Просто уже есть же популярный HTML (и XHTML), значит и тут прокатит.

S>Т.е. это код, по этому дизайнер не поймет:

Ну, в Qt за основу взяли JS и у них в QML что-то похожее на то, что тебе хочется.
Microsoft любили XML и взяли его за базу (те же форматы docx, xlsx и т.д. на нём).
Пилить что-то своё с нуля — долго, сложно и дорого.
Взять готовый синтаксис — уже куча кода для парсинга есть, инструменты с подсветкой синтаксиса, базовые проблемы решены и т.д. и т.п.

Здравствуйте, karbofos42, Вы писали:

S>>Тогда зачем придумали XAML, если можно было на этом построить GUI?

K>Чтобы вёрсткой мог заниматься не программист, как это происходит в мире HTML + CSS.
K>Только по-моему у них это не очень получилось

Такое разделение труда вышло не очень удобным с т.з. менеджмента команд. Горизонтальные зависимости девелопер-девелопер увеличивают хаос в планировании.
Поэтому мы с вами наблюдаем появление т.н. фуллстеков, которые занимаются всем подряд, от запросов к бд до верстки. В этом случае нужны продвинутые фремворки, которые изолируют разработчиков от множества технических деталей.
Для большинства проектов это очень годная модель.

Здравствуйте, Shmj, Вы писали:

S>А если всего чуток изменить, то можно без особой переделки сделать чтобы все было декларативно. А именно:

S>

S>Form(
S>   Children: [
S>      Button(
S>         Color: Colors.Blue
S>      )
S>   ]
S>)
S>

S>Все гениальное — просто.

Вы изобрели flutter. Можно еще короче:

Form [
      Button(
         Color: Colors.Blue
      )
]

Здравствуйте, Shmj, Вы писали:

S>Все гениальное — просто.

См. фреймворки на Котлине, и Флаттер, да. Так и сделано.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>>>Все гениальное — просто.
G>>Ага, и придумано давно.

Вот так например можно:
https://github.com/idexus/CodeMarkup-Maui

S>Тогда зачем придумали XAML, если можно было на этом построить GUI?

Потому что изначально xaml начали придумывать как расширение html, чтобы внутри страничек в браузере делать доп функционал. И идея была в том, что этот код никто не увидит, а все будет делаться в визуальном редакторе типа Blend
А потом, наверно, побоялись сказать начальству, что зря время потратили

Здравствуйте, Shmj, Вы писали:

S>Все гениальное — просто.

https://github.com/giraffe-fsharp/Giraffe.ViewEngine#html-elements-and-attributes

да, есть такое, правда, производительность может просесть.
еще лучше гибрид старого доброго и генерал пурпос языка https://fsbolero.io/docs/Templating

Вопрос по ходу. Не пора ли DI в C# заменить на глобальный контекст на базе record?

Здравствуйте, swame, Вы писали:

S>Первый вариант хорош, а второй плох хотя бы тем, что по первому можно нормально пройти отладчиком, а по второму хрен.

а первый вариант плох тем, что куча дублирования. Надо проверять кучу моментов:

Всё это надо проверять в императивном коде. Для этого даже можете запустить отладчик (только он тут нифига не поможет).
В декларативном стиле дублирование (и ошибки с ним связанные) сведено к минимуму. Исчезают ненужные названия (blueButton или mainWindow). Связи (как минимум one-to-many) устанавливаются автоматически. Ну да, потеряли отладчик. Но в большинстве случаев без него можно жить.

Здравствуйте, Shmj, Вы писали:

S>Все гениальное — просто.

То что ты привел, это не гениальное.
Разница между декларативностью и императивностью вовсе не в синтаксисе. Декларативность это когда ты описываешь намерения, императивность — когда даешь указания что делать. В твоем примитивном примере первый вариант тоже декларативен, хоть и записан императивными конструкциями. Поэтому его легко преобразовать в декларативную форму. Проблемы у тебя начнутся как только ты реально императивный код напишешь. Например:

Button blueButton = new Button();
blueButton.Color = _options.Colors.Button;

...

Button blueButton = new Button();
blueButton.Color = _options.HasBlue ? Colors.Blue : Colors.Gray;

...

if (_options.HasBlueButton)
{
Button blueButton = new Button();
blueButton.Color = _options.Colors.Button;
mainForm.Children.Add(blueButton);
}

Перепишешь в своем гениальном стиле?

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Перепишешь в своем гениальном стиле?

Form [
    when(options.hasBlueButton) [
        Button(
           Color: Colors.Blue
        )
    ]
]

Здравствуйте, Pauel, Вы писали:

P>

P>Form [
P>    when(options.hasBlueButton) [
P>        Button(
P>           Color: Colors.Blue
P>        )
P>    ]
P>]
P>

Вот, уже появляются специальные конструкции, а не просто подмена синтаксиса. А если дальше пойти — анимация, data binding и т.п. — такие конструкции становятся все изощренние и изощренние, и получаем XAML.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Shmj, Вы писали:

S>>>Все гениальное — просто.
G>>Ага, и придумано давно.

S>Тогда зачем придумали XAML, если можно было на этом построить GUI?
А тем, что количество строк меньше при использовании конвертеров, стилей, шаблонов, триггеров
https://metanit.com/sharp/wpf/2.3.php

DataTriggers
https://stackoverflow.com/questions/9049197/conditional-datatemplate

В свое время для Xamarin не было визуального редактора. Все в коде. Не понравилось.
Но вот Flutter как раз на дарте и использует программный подход

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>

P>>Form [
P>>    when(options.hasBlueButton) [
P>>        Button(
P>>           Color: Colors.Blue
P>>        )
P>>    ]
P>>]
P>>

НС>Вот, уже появляются специальные конструкции, а не просто подмена синтаксиса.

Здесь нет специальной конструкции ради where — все ровно то же, что и для обычных тегов
1 идет тег
2 необязательные круглые скобки с параметрами,
3 или фигурные скобки, с именоваными свойствами,
4 или квадратные, как alias для Children

На такой основе можно нагородить всё что хошь.

Здравствуйте, Pauel, Вы писали:

P>Здесь нет специальной конструкции ради where — все ровно то же, что и для обычных тегов

Что такое when?

P>На такой основе можно нагородить всё что хошь.

Содержимое when в студию.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Shmj, Вы писали:

	Скрытый текст
	S>Вот императивный способ создания GUI и это плохо: S> `S>Form mainForm = new Form(); S>Button blueButton = new Button(); S>blueButton.Color = Colors.Blue; S>mainForm.Children.Add(blueButton); S>` S>А если всего чуток изменить, то можно без особой переделки сделать чтобы все было декларативно. А именно:

S>Form(
S>   Children: [
S>      Button(
S>         Color: Colors.Blue
S>      )
S>   ]
S>)
S>

S>Т.е. делаем new не обязательным, создание объекта без него. И даем возможность задать в конструкторе свойства. И все!
Что делать, если по нажатию кнопки в Children надо добавить ещё одну кнопку?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Перепишешь в своем гениальном стиле?

В простейших случаях можно использовать свойство Visible.

Но когда требуется императивное поведение — то этот гениальный подход позволяет простым образом его использовать. Это же просто код.

Попытка представить в декларативном виде императивное поведение — сделает только хуже и все усложнит.

Здравствуйте, B0FEE664, Вы писали:

BFE>Что делать, если по нажатию кнопки в Children надо добавить ещё одну кнопку?

Это уже императивное поведение, не имеет смысла писать декларативно — будет только хуже. Вы нагородите кучу абстракций — а проще не будет.

Приведенный мной образец — это же просто код, просто иначе записан. Там можно и функцию добавить.

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>Здесь нет специальной конструкции ради where — все ровно то же, что и для обычных тегов

НС>Что такое when?

Обычный тег, с таким же синтаксисом, как и все остальные теги. Его задача обеспечивать условный рендеринг контента.

P>>На такой основе можно нагородить всё что хошь.

НС>Содержимое when в студию.

В отличие от других тегов, у него нет собственного представления, он чилдов передаёт паренту 1 в 1. Можета сами понаобъявлять таких сколько угодно.

S>Тогда зачем придумали XAML, если можно было на этом построить GUI?

Не надо искать злой умысел там, где достаточно некомпетентности.

Здравствуйте, B0FEE664, Вы писали:

S>>Т.е. делаем new не обязательным, создание объекта без него. И даем возможность задать в конструкторе свойства. И все!
BFE>Что делать, если по нажатию кнопки в Children надо добавить ещё одну кнопку?

Без проблем, это есть так называемая Elm-архитектура с MVU-паттерном. В языках где все есть выражение представление лишь функция составленная из выражений, в том числе условных.

https://elm-lang.org/try
https://safe-stack.github.io/docs/component-elmish/
https://github.com/fabulous-dev/Fabulous (декларативный прямо по описанию

)
https://fsbolero.io/docs/Elmish
Вообщем, подход довольно популярный

Здравствуйте, Shmj, Вы писали:

S>Это уже императивное поведение, не имеет смысла писать декларативно — будет только хуже. Вы нагородите кучу абстракций — а проще не будет.

S>Приведенный мной образец — это же просто код, просто иначе записан. Там можно и функцию добавить.

А в итоге одни разработчики выдумывают свой DSL для декларативного описания, прикручивают кодогенерацию из него в основной язык, создают всякие инструменты для отладки всего этого добра.
Другие разработчики потом начинают этим пользоваться, сначала учат как замечательно это всё декларативно делается,
а потом выясняют как убого это всё прописывается императивно и гуглят: "как создать кнопку программно?".
Может лучше иметь один нормальный механизм на одном языке?

Здравствуйте, Ночной Смотрящий, Вы писали:

https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.itemscontrol.itemtemplateselector?view=windowsdesktop-7.0&redirectedfrom=MSDN#System_Windows_Controls_ItemsControl_ItemTemplateSelector

https://stackoverflow.com/questions/9049197/conditional-datatemplate

Здравствуйте, Pauel, Вы писали:

НС>>Что такое when?
P>Обычный тег, с таким же синтаксисом, как и все остальные теги. Его задача обеспечивать условный рендеринг контента.

Какой такой тег? У шимжи речь шла про императивный язык.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Shmj, Вы писали:

НС>>Перепишешь в своем гениальном стиле?
S>В простейших случаях можно использовать свойство Visible.

Покажи.

S>Но когда требуется императивное поведение — то этот гениальный подход позволяет простым образом его использовать. Это же просто код.

Это же просто императивный код. Синтаксис просто делает его чуть удобнее. Декларативным он от этого не становится, даже если примитивные кейсы внешне похожи.

S>Попытка представить в декларативном виде императивное поведение — сделает только хуже и все усложнит.

Ну как сказать. Слышал про такую штуку как continuation monad? Вот это оно и есть, и в некоторых кейсах вполне себе работает. В частности, современная программа на C# может на 90% состоять из continuation monad.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Serginio1, Вы писали:

S>https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.itemscontrol.itemtemplateselector?view=windowsdesktop-7.0&redirectedfrom=MSDN#System_Windows_Controls_ItemsControl_ItemTemplateSelector
S>https://stackoverflow.com/questions/9049197/conditional-datatemplate

Как обычно невпопад. Я привел пример того, для чего нужен XAML (тут даже не про синтаксис речь, а про его модель), а ты решил опровергнуть это примерами на xaml.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Shmj, Вы писали:

S>Это уже императивное поведение, не имеет смысла писать декларативно — будет только хуже.

Как ты категоричен.
А если тебе твою форму надо оттранслировать в HTML? Или, как в свое время в винфонах было, интерпретировать модель без ее предварительной компиляции?

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Что такое when?
P>>Обычный тег, с таким же синтаксисом, как и все остальные теги. Его задача обеспечивать условный рендеринг контента.

НС>Какой такой тег? У шимжи речь шла про императивный язык.

Я и написал, что можно иначе. Для этого С# умеет почти всё, что нужно для такого, но всё равно синтаксического шума выйходит многовато, придется везде понадобавлять всякие new итд, что убивает на месте

Здравствуйте, Pauel, Вы писали:

НС>>Какой такой тег? У шимжи речь шла про императивный язык.
P>Я и написал, что можно иначе.

Где ты такое написал? Слова "иначе" в твоих ответах до этого момента не было.
Суть топика очень проста. Шымжа придумал очередную кулибинщину, имитацию декларативности при том что "без переделки ядра и без создания нового языка — мы можем писать все декларативно. Не нужен XAML или еще что". И мои примеры были предназначены для демонстрации нежизнеспособности его "гениальной" идеи.
Так при чем тут тогда твои теги?

P>Для этого С# умеет почти всё

Но C# далеко не чисто императивный язык.

P>придется везде понадобавлять всякие new итд

using static и набор обычных статических методов позволит обойтись без new.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Shmj, Вы писали:

html с css давно придумали. И во что оно сейчас превратилось?
Может не стоит по тем же рельсам ехать опять?

Здравствуйте, Sheridan, Вы писали:

S>html с css давно придумали. И во что оно сейчас превратилось?
S>Может не стоит по тем же рельсам ехать опять?

Html и css усиленно пролазят в webassembly и canvas
Так что эта песня будет вечной

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>придется везде понадобавлять всякие new итд

НС>using static и набор обычных статических методов позволит обойтись без new.

А C# умеет приклеивать object и collection initializer не только к конструктору?
Если нет, то мастырить на шарпе вряд ли стоит.

Здравствуйте, Pauel, Вы писали:

НС>>using static и набор обычных статических методов позволит обойтись без new.
P>А C# умеет приклеивать object и collection initializer не только к конструктору?

Obj init умеет, но не на самом верхнем уровне. На вложенных уровнях new не требуется.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

S>А если всего чуток изменить, то можно без особой переделки сделать чтобы все было декларативно. А именно:
S>Form(
S> Children: [
S> Button(
S> Color: Colors.Blue
S>Все гениальное — просто.
И теперь во время присвоения очередного свойства выскакивает ошибка, и куда мы выпадаем в отладчик? Просто никуда. Гениальным программистам отладчик не нужен.

Здравствуйте, Osaka, Вы писали:

O>И теперь во время присвоения очередного свойства выскакивает ошибка

Какая?

O>и куда мы выпадаем в отладчик? Просто никуда. Гениальным программистам отладчик не нужен.

Расскажи, куда ты попадаешь в отладчик на машине пользователя?

Здравствуйте, ·, Вы писали:

·>Ты наваяй пример с десятком контролов как минимум, чтобы всё прыгало и менялось, по событиям и прочим таймерам, посылало запросы. Чтобы функциональность покрывалась тестами, которые не сыпятся при небольшой модификации дизайна. Чтобы код был читабельным, с минимумом копипасты, простотой переиспользования, и легко поддавался рефакторингу, внесению новых изменений.
QML

Здравствуйте, karbofos42, Вы писали:

K>Ну, в Qt за основу взяли JS и у них в QML что-то похожее на то, что тебе хочется.
Есть еще slint. Разработчики стояли у истоков QML, поэтому slint и QML похожи. По словам разработчиков сделан с учетом ошибок допущенных при проектирование QML. Нет зависимости от Qt.

Здравствуйте, korvin_, Вы писали:

_>Расскажи, куда ты попадаешь в отладчик на машине пользователя?
В то самое место, где темно и ни х#% не видно.
Именно поэтому такое отлаживать невозможно. "Хлебаем" с Blazor сейчас по полной.
Когда проект есть комбинация разных технологий: С#, Javascript, HTML, CSS — ну его нафиг.
Я с ностальгией вспоминаю сейчас о С++ и Qt

Суть декларативности в том, что ты по-другому просто не можешь. А в твоём случае — хочешь, пишешь так, хочешь — по-другому.

Удивительное в том, что порой ограничения дают пользу. Есть даже такое выражение: искусство рождается из ограничений.

Простая аналогия:

Есть такое понятие, как чистое функциональное программирование. Это когда в языке нет изменяемых переменных. Всё через функции и рекурсию.

По сути ведь функции и рекурсия есть почти в любом языке. Но если у нас в языке нет изменяемых переменных, мы можем любой вызов функции отсылать в отдельный поток. Если у нас процессор с миллионом ядер, то наша программа теоретически сможет их использовать очень эффективно. Пока что у нас процессоры в основном с 2-4 ядрами, поэтому такая концепция больше теоретическая, но суть того, что из ограничения (запрет на изменяемые переменные) рождается новое свойство (программа автоматически может быть распалаллелена) я постарался передать.

Здравствуйте, Shmj, Вы писали:

S>Вот императивный способ создания GUI и это плохо:
S>А если всего чуток изменить, то можно без особой переделки сделать чтобы все было декларативно.

Велосипеды разной степени гениальности появляются раз в год. Вот Sketchy (коммент от 06.12.21 21:43) — почти как у тебя, но придуман раньше.

Вопрос только в одном — когда они уже наконец ПОЕДУТ?!

Здравствуйте, Shmj, Вы писали:

S>Вот императивный способ создания GUI и это плохо:

S>Т.е. делаем new не обязательным, создание объекта без него. И даем возможность задать в конструкторе свойства. И все! Теперь без переделки ядра и без создания нового языка — мы можем писать все декларативно. Не нужен XAML или еще что. Получается что все выглядит как JSON или подобие его — все просто и ясно, даже парсить можно парсером в 10 срок кода.

S>Все гениальное — просто.

А теперь нужно что-то сделать динамически, и статическое описание лэйаута не годится...

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>using static и набор обычных статических методов позволит обойтись без new.

Тогда синтаксис инициализации пропертей отлетает.

Здравствуйте, vdimas, Вы писали:

НС>>using static и набор обычных статических методов позволит обойтись без new.

V>Тогда синтаксис инициализации пропертей отлетает.

Re[11]: Когда императивность переходит в декларативность...

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Obj init умеет, но не на самом верхнем уровне. На вложенных уровнях new не требуется.

Если на вложенном уровне опять не используешь new, а используешь одноимённый с типом статический метод, то опять проперти инициализировать никак.

Здравствуйте, fk0, Вы писали:

fk0>Здравствуйте, Shmj, Вы писали:

S>>Вот императивный способ создания GUI и это плохо:

S>>Т.е. делаем new не обязательным, создание объекта без него. И даем возможность задать в конструкторе свойства. И все! Теперь без переделки ядра и без создания нового языка — мы можем писать все декларативно. Не нужен XAML или еще что. Получается что все выглядит как JSON или подобие его — все просто и ясно, даже парсить можно парсером в 10 срок кода.

S>>Все гениальное — просто.

fk0> А теперь нужно что-то сделать динамически, и статическое описание лэйаута не годится...

Почему нет? https://sutil.dev/#examples-if-blocks?LogicIf.fs
синтаксис C# просто недостаточно comprehension
одна простая идея что все есть список, который может представлять все что угодно, например, view в UI + так называемый list comprehension
позволяют без отдельного редактора описывать интерактивный интерфейс.

Здравствуйте, Разраб, Вы писали:

S>>>Вот императивный способ создания GUI и это плохо:

S>>>Т.е. делаем new не обязательным, создание объекта без него. И даем возможность задать в конструкторе свойства. И все! Теперь без переделки ядра и без создания нового языка — мы можем писать все декларативно. Не нужен XAML или еще что. Получается что все выглядит как JSON или подобие его — все просто и ясно, даже парсить можно парсером в 10 срок кода.

S>>>Все гениальное — просто.

fk0>> А теперь нужно что-то сделать динамически, и статическое описание лэйаута не годится...

Р>Почему нет? https://sutil.dev/#examples-if-blocks?LogicIf.fs
Р>синтаксис C# просто недостаточно comprehension
Р>одна простая идея что все есть список, который может представлять все что угодно, например, view в UI + так называемый list comprehension
Р>позволяют без отдельного редактора описывать интерактивный интерфейс.

Компилятор этого описания в рантайме нужен. Там ж не просто список элементов, и не только элементов.
конечно можно, Tcl/Tk так работает, например. Или в Web (javascript + html) так работают. Последнее
наверное понятней. Там можно двумя способами. Можно нагенерировать html и заставить его браузер интерпретировать
(предлагаемый подход). А можно руками из javascript развешивать на DOM-дерево вручную созданные элементы.
Последний подход может оказаться проще, если нужно что-то делать динамически. Впрочем если структура
сложная, то оба подхода -- плохи. Тогда лучше третий подход: есть шаблон написанный в html, который трансформируется
путём его параметризации данными (из json, например). Ну это почти как xslt-преобразование, но руками и попроще.
Трансформируется не на уровне текста, разумеется, а на уровне дерева. И потом это дерево просто вставляется
в DOM-страницы. В случае с GUI для десктопной программы это так просто не получится, там просто способа
представления GUI в виде дерева элементов -- нет. А совершенно напрасно. Поэтому скоро будет один сплошной веб.
Вначале в Москве конечно, а потом и на периферии.

S>Form(
S>   Children: [
S>      Button(
S>         Color: Colors.Blue
S>      )
S>   ]
S>)
S>

S>Т.е. делаем new не обязательным, создание объекта без него. И даем возможность задать в конструкторе свойства. И все! Теперь без переделки ядра и без создания нового языка — мы можем писать все декларативно. Не нужен XAML или еще что. Получается что все выглядит как JSON или подобие его — все просто и ясно, даже парсить можно парсером в 10 срок кода.

По поводу new
И в squirrel и в ksi не надо писать new
Там просто тип и сразу круглые скобки для параметров, как у функции

S>Все гениальное — просто.

В squirrel правда придётся писать конструктор.

В ksi просто обычные структуры с набором свойств, и для любого типа можно задать атрибут initial для значений по умолчанию.
Конструкторов нет, когда оно нужно — делается функция формирования, выдающая инстанс структуры, заполненный как надо
Или можно метод доп-инициализации забабахать отдельно.

instance = ( My_struct(prop1: 1, prop2: "2") !init(param1 param2) )

Кстати в вашем примере
Children хранит массив.

Но удобнее же иметь доступ к дочерним элементам управления не по индексу, а по идентификатору, так?
Тогда нужен map, а не array

-- ui

main_form = Form(
  children: {
    "button1" : Button(
      color: Colors.Blue
      caption: "ok"
    )
    "input1" : Text_area(
      scroll: Scroll.both
    )
  }
)

-- main events

main_form.events.on_resize = #fn (from) {
  form.children.input1.size.width = form.size.width
}

main_form.events.on_close = #fn (from) {
  (form.data.is_saved == $bool.false) #then { /* prompt */ }
}

Либа с тем-же синтаксисом:

-- определения для ui

Form = #struct (
  children
  size
  font
  events
)

Form->initial.font = Fonts.system_default

Events = #struct (
  on_resize
  on_close
)

-- controls

Button = #struct (
  caption
  color
  border_size
)

Button->initial(color: Colors.system_button_text, border_size: 1)

Text_area = #struct (
  scroll
  value
)

Text_area->initial(scroll: Scroll.none, value: "")

-- inner types

Scroll = #enum ( none vertical horizontal both )
Size = #struct ( width height )

Здравствуйте, Nikolaz, Вы писали:

N>В то самое место, где темно и ни х#% не видно.
N>Именно поэтому такое отлаживать невозможно. "Хлебаем" с Blazor сейчас по полной.
N>Когда проект есть комбинация разных технологий: С#, Javascript, HTML, CSS — ну его нафиг.
N>Я с ностальгией вспоминаю сейчас о С++ и Qt

.
У нас сейчас для одного проекта используется С++ или Python для логики и QML для визуаулизации. Все работает на всех мыслимых платформах.
Другая команда использует .Net + Maui поверх С++ и страдает, пытаясь сделать что-то визуально приличное хотя бы под Винду.

Здравствуйте, fk0, Вы писали:

fk0>В случае с GUI для десктопной программы это так просто не получится, там просто способа
fk0>представления GUI в виде дерева элементов -- нет. А совершенно напрасно.
QML/XAML/MAUI/SLINT и т.д чем не подходят под "декларативное дерево"?

Здравствуйте, B0FEE664, Вы писали:

BFE>Что делать, если по нажатию кнопки в Children надо добавить ещё одну кнопку?

Вариант 1: новая кнопка уже добавлена, просто скрыта флагом .visible = false; Меняем по нажатию на true и всё.

Вариант 2: реализовать возможность добавлять элементы управления не только декларативно, но и императивно.

form.children.add([
  "new_button_1": Button(caption: "Yes")
  "new_button_2": Button(caption: "No")
])

	От:	Shmj
	Дата:	07.08.23 20:20
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	07.08.23 20:28
Оценка:

	От:	SkyDance
	Дата:	07.08.23 22:28
	Оценка:

	От:	Shmj
	Дата:	08.08.23 00:21
	Оценка:

	От:	karbofos42
	Дата:	08.08.23 07:36
	Оценка:	+1

От:	Pauel	http://blogs.rsdn.org/ikemefula
Дата:	08.08.23 12:04
Оценка:

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	08.08.23 14:56
Оценка:

От:	Евгений Акиньшин	grapholite.com
Дата:	09.08.23 02:54
Оценка:	2 (2)

	От:	Ночной Смотрящий
	Дата:	09.08.23 11:25
	Оценка:	+1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	09.08.23 12:07
Оценка:

От:	Nikolaz	www.nikeware.com
Дата:	25.08.23 13:47
Оценка:	1 (1)

От:	fk0	https://fk0.name
Дата:	28.09.23 06:50
Оценка:

	От:	Разраб
	Дата:	10.08.23 03:00
	Оценка: