Здравствуйте, 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 не требуется.

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

Автор: Kolesiki
Дата: 05.12.21

(коммент от 06.12.21 21:43) — почти как у тебя, но придуман раньше.
Вопрос только в одном — когда они уже наконец ПОЕДУТ?!

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Ночной Смотрящий
Дата: 11.08.23

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

НС>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 в виде дерева элементов -- нет. А совершенно напрасно. Поэтому скоро будет один сплошной веб.
Вначале в Москве конечно, а потом и на периферии.

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

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

S>

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 и т.д чем не подходят под "декларативное дерево"?