S>> R>Педалить руками замл и радоваться, это совсем упороться надо любовию майкрософтовской... На SwiftUI посмотри.
S>> Посмотрел на это убожество. Редактор форм, это по сути конструктор со страницами свойств и отображении формы при изменении свойств без перекомпиляции всего проекта. S>> А там этих свойств огромное количество, и для редактирования свойства есть свой редактор. S>> Ты видно со сложными формами и не работал.
R>ЯННП
S>> https://learn.microsoft.com/ru-ru/visualstudio/xaml-tools/xaml-code-editor?view=vs-2022
R>OMG, блэт. XML это машиночитаемый формат, он не для человеков. Предлагать править XML руками могли додуматься только в МС, или подобные им альтернативно одаренные. Но деваться некуда, сделать визуальный редактор замла, который не падает каждые десять секунд они не вывезли.
Ничего не падает. Xaml как раз и хорош тем, что можно и руками непосредственно в Xml, так и редактор свойств.
И главное отображение формы без предкомпиляции всего проекта!
А поделки типа SwiftUI чем они лучше того же Xaml на чистом C#? У редактора XAML куча конвертеров, редакторов упрощающих написание и чтение XAML.
Любителям SwiftUI этого не понять!
и солнце б утром не вставало, когда бы не было меня
S>Согласны ли вы, что т.н. визуальное программирование или визуальное администрирование или даже визуальные схемы — годится только для простейших случаев и по мере усложнения системы — все неизбежно переходит в форму языка со словами? И почему так?
Текст можно посимвольно сравнивать и копипастить (и доводить вручную только разницу). Прецизионно, только нужные куски. (А в каком-нибудь дизайнере XAML — при нажатии на контрол оно ещё и само спозиционируется в нужную точку текста, и без переключения окон). Как такое проделать с "наглядными диаграммами, не требующими платить программисту"? Особенно когда придётся копаться с тысячами их. Сколько сотен раз надо в "удобном визуальном редакторе" точно прицелиться и свозить мышку вместо 1 переноса куска xml?
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Здравствуйте, Serginio1, Вы писали:
S> R>OMG, блэт. XML это машиночитаемый формат, он не для человеков. Предлагать править XML руками могли додуматься только в МС, или подобные им альтернативно одаренные. Но деваться некуда, сделать визуальный редактор замла, который не падает каждые десять секунд они не вывезли.
S> Ничего не падает.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Serginio1, Вы писали:
S>> R>OMG, блэт. XML это машиночитаемый формат, он не для человеков. Предлагать править XML руками могли додуматься только в МС, или подобные им альтернативно одаренные. Но деваться некуда, сделать визуальный редактор замла, который не падает каждые десять секунд они не вывезли.
S>> Ничего не падает.
R>Правда? А у меня падает И не только у меня: https://github.com/dotnet/wpf/issues/2780
Сейчас какой год?
S>> А поделки типа SwiftUI чем они лучше того же Xaml на чистом C#?
R>XAML на C#? Ты сам понимаешь, что ты несешь? Ладно, хочу увидеть пример, вне зависимости от того, что ты подразумеваешь под "замл на сишарп".
То, что любой элемент XAML можно описать кодом. Иногда пользуюсь когда конвертеры и прочие писать лень.
Допустим я хочу создать TextBox и задать ему в текст «Habr», на C# это будет выглядеть так:
var tb = new TextBox(){Text = "Habr"};
На XAML это будет выглядеть так:
<TextBox Text="Habr"/>
и солнце б утром не вставало, когда бы не было меня
Баг открытый. В 2023 еще падало. Хочешь 2024? https://developercommunity.visualstudio.com/t/XAML-designer-keeps-crashing/10656332?sort=newest МС даже фикс выпустила для "непадающего дизайнера". Можешь и сам погуглить.
S> S>> А поделки типа SwiftUI чем они лучше того же Xaml на чистом C#?
S> R>XAML на C#? Ты сам понимаешь, что ты несешь? Ладно, хочу увидеть пример, вне зависимости от того, что ты подразумеваешь под "замл на сишарп".
S> То, что любой элемент XAML можно описать кодом. Иногда пользуюсь когда конвертеры и прочие писать лень.
S> Допустим я хочу создать TextBox и задать ему в текст «Habr», на C# это будет выглядеть так: S>
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Serginio1, Вы писали:
S>> R>Правда? А у меня падает И не только у меня: https://github.com/dotnet/wpf/issues/2780
S>> Сейчас какой год?
R>Баг открытый. В 2023 еще падало. Хочешь 2024? https://developercommunity.visualstudio.com/t/XAML-designer-keeps-crashing/10656332?sort=newest МС даже фикс выпустила для "непадающего дизайнера". Можешь и сам погуглить.
S>> S>> А поделки типа SwiftUI чем они лучше того же Xaml на чистом C#?
S>> R>XAML на C#? Ты сам понимаешь, что ты несешь? Ладно, хочу увидеть пример, вне зависимости от того, что ты подразумеваешь под "замл на сишарп".
S>> То, что любой элемент XAML можно описать кодом. Иногда пользуюсь когда конвертеры и прочие писать лень.
S>> Допустим я хочу создать TextBox и задать ему в текст «Habr», на C# это будет выглядеть так: S>>
S>> var tb = new TextBox(){Text = "Habr"};
S>>
S>> На XAML это будет выглядеть так: S>>
S>> <TextBox Text="Habr"/>
S>>
R>
R>И это ты называешь похожим на SwiftUI?
То есть эту лабуду на SwiftUI нельзя написать на C#?
Ну да где то будут new
struct ContentView: View {
var text1 = "some text"
var text2 = "some more text"
var body: some View {
VStack{
Text(text1)
.padding()
.frame(width: 100, height: 50)
Text(text2)
.background(Color.gray)
.border(Color.green)
}
}
}
var text1 = "some text"var text2 = "some more text"var ContentView = new View {
Boody = new View {
VStack = new VStack().Add(
new Text(text1)
.padding()
.frame(width: 100, height: 50)
).Add(new Text(text2){
Baackground=Color.gray,
Border=Color.green
}
)
}
}
}
А теперь поменяй что либо и посмотри редактор форм без перекомпиляции!
и солнце б утром не вставало, когда бы не было меня
G>Я собсно как-раз работаю над такой штуковиной для доказательного программирования, которая радикально отличается в этом плане, не то язык, не то фреймворк. G>Древовидная структура с предикатами, юзер выбирает из списка возможных следствий. Некоторые следствия создают разветвления.
А где гарантия что юзер не перепутает предикат, как он это может сделать в текстовом if ?
Доказательство какое то может быть если два программиста пишут один код на разных ЯП, а потом хитрый компилятор собирает их оба и сверяет AST или типа того. А лучше три программиста на трех разных ЯП
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Serginio1, Вы писали:
S> R>И это ты называешь похожим на SwiftUI?
S> То есть эту лабуду на SwiftUI нельзя написать на C#? S> Ну да где то будут new
S> struct ContentView: View { S> var text1 = "some text" S> var text2 = "some more text" S> var body: some View { S> VStack{ S> Text(text1) S> .padding() S> .frame(width: 100, height: 50) S> Text(text2) S> .background(Color.gray) S> .border(Color.green) S> } S> } S> }
S>
S> var text1 = "some text"
S> var text2 = "some more text"
S> var ContentView = new View {
S> Boody = new View {
S> VStack = new VStack().Add(
S> new Text(text1)
S> .padding()
S> .frame(width: 100, height: 50)
S> ).Add(new Text(text2){
S> Baackground=Color.gray,
S> Border=Color.green
S> }
S> )
S> }
S> }
S> }
S>
S> А теперь поменяй что либо и посмотри редактор форм без перекомпиляции!
Пха-ха. Вот, почитай: https://habr.com/ru/articles/796029/ Обрати внимание на two-way редактирование с помощью инспектора (хз, как дать ссылку в середину статьи. Ищи этот текст: "Хотя я предпочитаю настраивать свойства элемента управления путем написания кода, также можно использовать холст дизайна для их редактирования."). Вот как надо, а не это ваше унылое...
Здравствуйте, rudzuk, Вы писали:
R>Пха-ха. Вот, почитай: https://habr.com/ru/articles/796029/ Обрати внимание на two-way редактирование с помощью инспектора (хз, как дать ссылку в середину статьи. Ищи этот текст: "Хотя я предпочитаю настраивать свойства элемента управления путем написания кода, также можно использовать холст дизайна для их редактирования."). Вот как надо, а не это ваше унылое...
Ну молодцы. Только вот с декларативности никакой. XAML с его приверженностью к XML тоже не идеал.
Еще раз нужно отвязать форму от программиста. То есть дизайном занимается дизайнер, а кодом программист.
То есть совмещение конвертеров, DependencyObject, стилей, триггеров, биндинги, ресурсы итд.
XAML если убрать XML достаточно продуманная технология для декларативного описания интерфейса.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
G>>Я собсно как-раз работаю над такой штуковиной для доказательного программирования, которая радикально отличается в этом плане, не то язык, не то фреймворк. G>>Древовидная структура с предикатами, юзер выбирает из списка возможных следствий. Некоторые следствия создают разветвления. G>>Ветви переносятся, клонируются, сливаются, неконсистентные — удаляются. По итогу генерится код. S>Очень интересно. Есть какие-то публичные ресурсы про вашу работу? Статьи или описание продукта?
Тут все есть. Может еще на свежую голову что-то подопишу, но в целом думаю понятно, если вообще понятно, что я там понаписал
Здравствуйте, Shmj, Вы писали:
S>Согласны ли вы, что т.н. визуальное программирование или визуальное администрирование или даже визуальные схемы — годится только для простейших случаев и по мере усложнения системы — все неизбежно переходит в форму языка со словами? И почему так?
Ну видимо, преемственность культуры и накопление знаний требуют письменного текста.
Здравствуйте, Shmj, Вы писали:
S>Сейчас почти все описывается кодом или переходит в эту сторону:
Если ты про языки программирования, то это тоже часть языка людей. Специализированная.
Аналогично языки написания научных статей. Они тоже специализированные с кучей специфических значков.
Здравствуйте, Shmj, Вы писали:
S>Согласны ли вы, что т.н. визуальное программирование или визуальное администрирование или даже визуальные схемы — годится только для простейших случаев и по мере усложнения системы — все неизбежно переходит в форму языка со словами? И почему так?
Когда программист пишет программу, то он переставляет/добавляет/удаляет маленькие графические символы и бывает так, что забудет добавить графический символ, скажем, запятую — и всё: баг. Разве манипуляции с маленькими графическими символами на экране это не визуальное программирование? А что же тогда?
Здравствуйте, Shmj, Вы писали:
S>Согласны ли вы, что т.н. визуальное программирование или визуальное администрирование или даже визуальные схемы — годится только для простейших случаев и по мере усложнения системы — все неизбежно переходит в форму языка со словами?
Нет, не считаю.
S>И почему так?
Влияние консольного Linux, вестимо.
Влияние хорошо заточенных только на текстовый формат систем контроля версий, конечно.
Т.е. тот самый постыднейший случай, когда бытие формирует сознание, а не наоборот, бгг...
Здравствуйте, Shmj, Вы писали:
S>Сейчас почти все описывается кодом или переходит в эту сторону:
Победа systemd с описательными юнитами вместо явного кода почти во всём — противоречит этому.
S>2. Скрипты установки.
Основу в пакетных менеджерах всё равно представляет собой файловое дерево.
Скрипты активизируются только в том, без чего не обойтись, и от них стараются избавиться, если что-то можно решить простым описанием.
S>4. Даже устройство микропроцессоров — уже не схемы рисуют а описывают кодом. Возможно что скоро и мат. платы и пр. — будут описывать кодом.
Что значит "даже"?
Код неизбежен тут, когда мы описываем поведение строительных блоков.
Но потом всё равно идёт генерация структур и множество работ, не описываемых кодом.
S>5. Даже мы с вами — и те описаны генетическим кодом, а не чертежами.
Тупая неправда. "Генетический код" это не программа, это набор именно что поэлементных описаний конструкций элементов (белки и управляющие РНК — в первую очередь). "Код" он примерно в том же смысле, что "код ASCII" или "код Морзе". И да, это чертежи. Путаные и сложные, но чертежи. Процессы возникают, только когда элементы, созданные по этим чертежам, вступают во взаимодействие.
S>Согласны ли вы, что т.н. визуальное программирование или визуальное администрирование или даже визуальные схемы — годится только для простейших случаев и по мере усложнения системы — все неизбежно переходит в форму языка со словами? И почему так?
Там, где должны быть описаны временные соотношения и модальные зависимости, их проще описывать словами. Хотя можно и начертить.
Не вижу тут места для глобальных выводов.
Здравствуйте, Shmj, Вы писали:
S>Согласны ли вы, что т.н. визуальное программирование или визуальное администрирование или даже визуальные схемы — годится только для простейших случаев и по мере усложнения системы — все неизбежно переходит в форму языка со словами? И почему так?
Да, согласен. Идея о том, что программу можно представлять в визуальном виде существует с самого начала программирования. Было множество попыток, но все они не увенчались успехом.
Помните блок-схемы или например UML? Попробуйте сделать полную блок-схему какого-нибудь небольшого реально работающего модуля, там получится такой ужас, что в этом разобраться невозможно.
И даже полная UML диаграмма какого-нибудь более менее нетривиального проекта. Все это начинает выглядеть очень сложным и запутанным. Не давно все рекламировали курсы по зеро-кодингу. Визуальные методы программирования годятся для обучения, разного рода схемы отлично подходят для документирования и презентаций, но это всегда сильно упрощенные схемы, скрывающие детали. Есть специфические отрасли, например делать GUI без визуального радактора формочек это жуткое извращение, неплохо работают визуальные редакторы для создания структуры БД.
Я бы с удовольствием поигрался бы с системами, которые представляют программу не в виде кода, а в каком-то другом виде, но пока я не видел ничего, что бы позволяло делать что-то сложнее маленьких учебных программок (GUI отдельный разговор).
Здравствуйте, ksandro, Вы писали:
K>Я бы с удовольствием поигрался бы с системами, которые представляют программу не в виде кода, а в каком-то другом виде, но пока я не видел ничего, что бы позволяло делать что-то сложнее маленьких учебных программок (GUI отдельный разговор).
И не только у меня: https://github.com/dotnet/wpf/issues/2780
Ладно, хочу увидеть пример, вне зависимости от того, что ты подразумеваешь под "замл на сишарп".
