Re[3]: Преимущества чистого кодогенератора
От: L_G Россия  
Дата: 20.09.19 11:09
Оценка:
ltc>Один из серьезнейших недостатков подобного подхода это отсутствие "инкрементальности".

ltc>Я считаю, что можно было бы данный недостаток побороть, используя автоматический мерж. Только мержить надо не плейн-текст, а синтаксические деревья. Причем не абстрактные, а конкретные, чтобы все форматирование сохранилось.


partial class не зря же придуманы.
в winforms вроде всё неплохо решено — в автоматически генерируемые *.designer.cs лезть никакой нужды нет.
я бы к аналогу этого стремился.
Re[4]: Преимущества чистого кодогенератора
От: ltc  
Дата: 20.09.19 12:23
Оценка:
Здравствуйте, L_G, Вы писали:

ltc>>Один из серьезнейших недостатков подобного подхода это отсутствие "инкрементальности".


ltc>>Я считаю, что можно было бы данный недостаток побороть, используя автоматический мерж. Только мержить надо не плейн-текст, а синтаксические деревья. Причем не абстрактные, а конкретные, чтобы все форматирование сохранилось.


L_G>partial class не зря же придуманы.


А чем бы они помогли? Вот генератор создал что-то, функционирующий набросок UI. Теперь я хочу его адаптировать по своему вкусу, что-то поправить. А потом средствами того же генератора учесть обновления в модели.

L_G>в winforms вроде всё неплохо решено — в автоматически генерируемые *.designer.cs лезть никакой нужды нет.


Не, там другое, там же практически взаимнооднозначная конвертация получается. Это просто два представления одного и того же.
Re[7]: Многие делают - но каждый свой велосипед
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.09.19 12:30
Оценка: +1
Здравствуйте, ltc, Вы писали:
ltc>Хм. Я, видимо, недостаточно въехал в контекст.
ltc>Если формочки постоянно правятся без изменения схемы базы данных, то почем нельзя относиться к ним как к обычным данным (коими они и являются в таком случае)?
Потому что жизненный цикл учётных данных и жизненный цикл формочек отличаются. Ваш К.О.
ltc>Если нам важна история данных — то не апдейтим, а инсертим, по дефолту используем последнее добавленное. В таком случае откат на любое предыдущее состояние тривиален.
Ну вот, вы уже начинаете изобретать тот тулчейн, который ведущие компании писали тридцать и более лет. Все вот эти blame, merge, branch, и прочие code review.
В теории так можно сделать. Но тогда вы получите ровно то же программирование форм, вид сбоку. Зачем?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: MS делают видео вместо статей - где разум?
От: Ночной Смотрящий Россия  
Дата: 20.09.19 14:35
Оценка:
Здравствуйте, MadHuman, Вы писали:

MH>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.


И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[8]: MS делают видео вместо статей - где разум?
От: MadHuman Россия  
Дата: 20.09.19 14:52
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:


MH>>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.


НС>И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML

Я бы не был столь категоричен к примеру графические конструкторы сайтов бурно плодятся и развиваются, по сути в итоге рождая html на основе накликанных и сконфигурённых энд-юзером высокоуровневых блоков.
Нельзя говорить что что-то однозначно всегда лучше, панацей небывает.
И тот и иной подход имеет смысл, важно понимать когда. Вообщем как и с любой другой технологией, важно понимать рамки её применимости и бонусы и недостатки.
Re[9]: MS делают видео вместо статей - где разум?
От: Ночной Смотрящий Россия  
Дата: 20.09.19 14:54
Оценка:
Здравствуйте, MadHuman, Вы писали:

НС>>И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML

MH>Я бы не был столь категоричен к примеру графические конструкторы сайтов бурно плодятся и развиваются, по сути в итоге рождая html на основе накликанных и сконфигурённых энд-юзером высокоуровневых блоков.

Только реальное применение всех этих конструкторов ограничивается сайтами-визитками.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Преимущества чистого кодогенератора
От: L_G Россия  
Дата: 20.09.19 15:50
Оценка:
ltc>А чем бы они помогли? Вот генератор создал что-то, функционирующий набросок UI. Теперь я хочу его адаптировать по своему вкусу, что-то поправить. А потом средствами того же генератора учесть обновления в модели.

Например, в генерируемом коде, возможно, описываются классы и в любом случае создаются экземпляры объектов. Свойства им назначаются по-минимуму (например, координаты для контролов на форме). Твои поправки (в отдельном файле) — это только изменение их свойств (например, корректировка размеров и расположения контролов, добавление обработчиков событий), но не их создание.

ltc>Не, там другое, там же практически взаимнооднозначная конвертация получается. Это просто два представления одного и того же.


я про разделение кода формы на пару файлов — полностью генерируемый (form1.designer.cs) и редактируемый программистом (form1.cs)
Re[6]: MS делают видео вместо статей - где разум?
От: Shmj Ниоткуда  
Дата: 20.09.19 17:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Фокус разработки usable софта переместился сначала в веб, потом в мобилки. На десктопе мы безнадёжно застряли в девяностых.


На самом деле 90-е были не так уж плохи в плане юзабилити...
Re[8]: Многие делают - но каждый свой велосипед
От: ltc  
Дата: 23.09.19 09:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

ltc>>Если нам важна история данных — то не апдейтим, а инсертим, по дефолту используем последнее добавленное. В таком случае откат на любое предыдущее состояние тривиален.

S>Ну вот, вы уже начинаете изобретать тот тулчейн, который ведущие компании писали тридцать и более лет. Все вот эти blame, merge, branch, и прочие code review.
S>В теории так можно сделать. Но тогда вы получите ровно то же программирование форм, вид сбоку. Зачем?

Я в данном треде не утверждаю, что это правильный путь. Просто отметил, что при желании вопросы с версионностью, восстановлением и т.д. технически разрешимы.
Re[9]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 25.09.19 12:02
Оценка:
Здравствуйте, ltc, Вы писали:

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


У нас чувак делал простой список изменения MS SQL процедур, с возможностью посмотреть diff (примерно как на RSDN версии редактирования).
Re[10]: Многие делают - но каждый свой велосипед
От: Ночной Смотрящий Россия  
Дата: 25.09.19 14:55
Оценка:
Здравствуйте, Shmj, Вы писали:

S>У нас чувак делал простой список изменения MS SQL процедур, с возможностью посмотреть diff (примерно как на RSDN версии редактирования).


Ну и нафига, если есть SSDT?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: MS делают видео вместо статей - где разум?
От: Silver_S Ниоткуда  
Дата: 01.10.19 11:50
Оценка:
Здравствуйте, Kolesiki, Вы писали:

Y>>В будущем огромный пласт программистов средней руки исчезнет

K> Эх, мечтатели!... Вы прям как те ЛИСПеры с горящими глазами, каких-то 30 лет назад предсказывающие ровно такой же "коллапс посредственностей". А воз? Он и ныне там.

Воз уже не там. Уже большой пласт отделился, стали конфигураторами 1C, а не программистами. На рынке труда не мало такой работы.
Re[8]: MS делают видео вместо статей - где разум?
От: Silver_S Ниоткуда  
Дата: 01.10.19 13:20
Оценка:
Здравствуйте, Sinclair, Вы писали:

MH>>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.

S>Ну, так современное программирование гуя — это оно и есть. Если мы отбросим бредовые идеи "создавать ГУИ по схеме данных" и "хранить описание ГУИ в СУБД", то останется совершенно нормальное программирование на обычном современном языке.

Прорыв в автоматизации такой работы случится, ИМХО, после того как появится эффективный промежуточный уровень — схема данных для пользователя, по которому автоматически строится GUI, с кастомизацией.
И решатся проблемы синхронизации серверной и пользовательской схемы данных при изменениях. Проблемы с производительностью, когда данные проходят через этот промежуточный уровень в обе стороны.
И проблемы написания логики, то ли в БД то ли в этой пользовательской схеме.
Возможно, с новым специализированным ЯП для этого.
По сложности правильно сделать этот промежуточный уровень не меньше чем создать сам SQL Server, или больше (всякие EntityFramework это пока баловство).
Но рано или поздно, оно точно постепенно появится.

MH>>ну как же, 1с вполне нормальная платформа для учетных решений. хотя я и не являюсь их сторонником, но справедливости ради.

S>1с — то же самое, вид сбоку. Для 90х — офигенная штука. С точки зрения юзабилити — твёрдые 3 с минусом.

И все таки 1C — конфигураторщики отобрали много работы у тех кто врукопашную все делает. Уже очень большая ниша когда выгоднее использовать такое решение.
Отредактировано 01.10.2019 13:23 Silver_S . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.