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

A>>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
S>В мире C++ богатый UI пишется на декларативном QML

Это случайно не тот самый ML, где id, source, height и color смешаны в одном тазике? Как в HTML до разделения доменов по DSL'ям.

А вообще, я говорил исключительно про работу с UI, где удобно делать именно такие кунштюки ("в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов"). И где крайне неудобен C++. Про бизнес-логику я ничего не говорил. Связка (HTML + CSS + JS) + C++ очень хороша для многих задач. Я почти всегда её и использую.

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

A>Это случайно не тот самый ML, где id, source, height и color смешаны в одном тазике? Как в HTML до разделения доменов по DSL'ям.
Стили для контролов и в QWidgets и в QML есть.
Другое дело, что очень часто в QML работа идет с более низкими примитивами типа Rectangle, и поддержку стилей надо самим реализовать при необходимости (это тривиально).

A>А вообще, я говорил исключительно про работу с UI, где удобно делать именно такие кунштюки ("в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов"). И где крайне неудобен C++.
Тут согласен: императивный подход для сложного UI не самое лучшее решение. Поэтому и придумали QML, Slint и т.п.

A>Про бизнес-логику я ничего не говорил. Связка (HTML + CSS + JS) + C++ очень хороша для многих задач. Я почти всегда её и использую.
Рабочее решение, но QML как язык куда приятнее HTML, IMHO. Плюс доп.расходы на порядом меньше.

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

A>>Это случайно не тот самый ML, где id, source, height и color смешаны в одном тазике? Как в HTML до разделения доменов по DSL'ям.
S>Стили для контролов и в QWidgets и в QML есть.
S>Другое дело, что очень часто в QML работа идет с более низкими примитивами типа Rectangle, и поддержку стилей надо самим реализовать при необходимости (это тривиально).

A>>А вообще, я говорил исключительно про работу с UI, где удобно делать именно такие кунштюки ("в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов"). И где крайне неудобен C++.
S>Тут согласен: императивный подход для сложного UI не самое лучшее решение. Поэтому и придумали QML, Slint и т.п.

Декларативность — понятие очень многозначное. Есть декларативность разметки. Есть декларативность адресации контролов (селекторы). Есть декларативность на уровне языка управления (поддержка лямбд вместо циклов).

Многие эти декларативности присутствуют в HTML, но не в QML. А другие, связанные с языковым уровнем, худо-бедно поддержаны в C++ без помощи Qt, но там нет автоматического управления памятью, который не менее важен для UI, чем декларативности. Поэтому я и дописал в конце: "И поуправляй памятью для всего этого дела".

Так-то, в скрипт (JS) вынесено всё самое императивное из связки HTML/CSS/JS. Декларативное оставлено в HTML, CSS и в языке селекторов. Сборщик мусора + намного более приятный синтаксис — вот чем, в первую очередь, зачётны скрипты в UI.

A>>Про бизнес-логику я ничего не говорил. Связка (HTML + CSS + JS) + C++ очень хороша для многих задач. Я почти всегда её и использую.
S>Рабочее решение, но QML как язык куда приятнее HTML, IMHO. Плюс доп.расходы на порядом меньше.

Не знаю, кому там что приятно, но сравнивать с титаническим HTML какие-то местечковые технологии... всякие QML, XAML... Я подписан на несколько дайджестов, где постоянно выкладывают фокусы, связанные с UI, сделанные на HTML. Конкурсы проводятся, жизнь бурлит. А покажи хоть один дайджест для QML-девелоперов. Или конкурс

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

A>Декларативность — понятие очень многозначное. Есть декларативность разметки.
Было бы интересно увидеть пример не декларативной разметки.

A>Есть декларативность адресации контролов (селекторы).
Что ты имеешь в виду? Привиди пример.

A>Есть декларативность на уровне языка управления (поддержка лямбд вместо циклов).
Лямбды ортогональны циклам и к декларативности отношения не имеют.

A>Многие эти декларативности присутствуют в HTML, но не в QML.
Декларативность в QML это просто и наглядно:

Rectangle {
width: 100
height: 200
Rectangle {
width: parent.width / 2
height: parent.height / 3
}
}

A>А другие, связанные с языковым уровнем, худо-бедно поддержаны в C++ без помощи Qt, но там нет автоматического управления памятью, который не менее важен для UI, чем декларативности. Поэтому я и дописал в конце: "И поуправляй памятью для всего этого дела".
Для связки C++/QML о памяти не нужно думать в 99%.

A>Так-то, в скрипт (JS) вынесено всё самое императивное из связки HTML/CSS/JS. Декларативное оставлено в HTML, CSS и в языке селекторов. Сборщик мусора + намного более приятный синтаксис — вот чем, в первую очередь, зачётны скрипты в UI.
Так это ровно также в QML: если нужно что-то императивное, то есть JS/Python/C++.

A>Не знаю, кому там что приятно, но сравнивать с титаническим HTML какие-то местечковые технологии... всякие QML, XAML... Я подписан на несколько дайджестов, где постоянно выкладывают фокусы, связанные с UI, сделанные на HTML. Конкурсы проводятся, жизнь бурлит. А покажи хоть один дайджест для QML-девелоперов. Или конкурс
Сядь в современный автомобиль: с выской вероятностью интерфейс написан на C++/QML.

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

A>>Декларативность — понятие очень многозначное. Есть декларативность разметки.
S>Было бы интересно увидеть пример не декларативной разметки.

Ну чего дурачка-то валять? "Есть декларативность разметки[, противопоставляемая императивности создания контролов кодом]".

A>>Есть декларативность адресации контролов (селекторы).
S>Что ты имеешь в виду? Привиди пример.

В старину были адреса: Кемская волость, село Пятаково, дом купца Калашникова (зелёный такой).

По аналогии, сейчас можно разыскивать секцию с обратной формой, поле для ввода текста, обязательно зелёное.

Если ты будешь перебирать контролы, пока не найдёшь обладающий всеми свойствами, это будет императивный подход. А можно получить одним декларативным запросом, если адресация селекторная (.feedback-form input.green). Сейчас синтаксис этих селекторов настолько развит, что это почти SQL уже

А если просто завести по переменной на каждый контрол и хранить ссылки, то это перестанет быть адресацией. Это будут шорткаты типа "доставьте посылку клиенту Васе".

A>>Есть декларативность на уровне языка управления (поддержка лямбд вместо циклов).
S>Лямбды ортогональны циклам и к декларативности отношения не имеют.

Да неужели. Лямбды позволяют описывать задачу, типа "трансформируй коллекцию так-то", в отличие от циклов, где тебе надо её пошагово решать.

A>>Не знаю, кому там что приятно, но сравнивать с титаническим HTML какие-то местечковые технологии... всякие QML, XAML... Я подписан на несколько дайджестов, где постоянно выкладывают фокусы, связанные с UI, сделанные на HTML. Конкурсы проводятся, жизнь бурлит. А покажи хоть один дайджест для QML-девелоперов. Или конкурс
S>Сядь в современный автомобиль: с выской вероятностью интерфейс написан на C++/QML.

Я лично делал два проекта для автомобильных интерфейсов, если что. А вообще, я, как бы, не об этом. Я о том, что сейчас именно HTML это cutting edge для интерфейсостроения. Просто не надо ассоциировать HTML исключительно с гугловским ожиревшим движком или, допустим, с сервером в отдельном процессе, про который тут выше ныли. Это вещи несвязанные. Бывает, что удобно делать веб-сервер, а бывает, что нет. Я вот думаю об одном проекте, где программа сможет подключаться к любым своим инстансам на любых машинах. Там, конечно, веб-сервер будет оправдан.