ART - экспериментальный встроенный язык для 1С

Программирование - Практика программирования

48
Насколько сложным должен быть встроенный инструмент программирования для такой системы, как 1С и что получится, если упростить его до последнего предела...

В этом языке всего два основных элемента: элемент A (assembly, группа) и элемент R (repeat, цикл) 

Здесь я приведу три примера того, что можно сделать, используя эти два элемента. 

Первый пример будет совсем простой. У нас есть справочник "Товары". В справочнике есть реквизит "Цена". Мы хотим сделать переоценку, т.е. изменить все цены. Кликаем на элемент R и добавляем его на рабочее поле. Вызываем контекстное меню для добавленного элемента и открываем окно свойств.

Поменяем предопределенное имя R на Товары.  Укажем источник цикла - Справочник.Товары. Укажем новое значение реквизита Цена и команду ЗАПИСАТЬ.

Последняя буква в названии ART, T означает - tracking. Это и получение результата и сам результат и отладка.  Нажмем кнопку "Трэкинг".  Данный наш случай слишком простой, чтобы что-нибудь отслеживать. Просто откроем справочник Товары и убедимся, что цены действительно изменились. Чтобы вернутся в режим разработки, нажмем эту же кнопку (она изменила свой вид):

Слегка усложним задачу. У нас есть документ Отгрузка с табличной частью Товары. Мы хотим разделить этот документ на два. Можно придумать множество способов разделить один документ на два. Мы возьмем самый простой: половину строчек в один документ, другую половину в другой. Разместим на рабочем поле два элемента типа A  и один типа R

Зададим свойства для элемента Подготовка. Исходный документ - это тот который мы хотим разделить на два. Первый и Второй - это новые документы.

У элемента Разделение укажем одно свойство: Источник. Больше нам здесь ничего не нужно.

Элемент Запись содержит команды записи Первого и Второго документов

 

Зайдем внутрь элемента Разделение и создадим там два новых элемента типа A. Назовем их Туда и Сюда. На иллюстрации заливка этих элементов выглядит размытой. Это говорит о том, что каждый из них содержит условие выполнения.

Вот так выглядят свойства элемента Туда. Свойства элемента Сюда очевидным образом отличаются условием и обращением ко Второму документу вместо Первого.

 

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

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

Эти примеры, конечно, примитивные и вряд ли они кого-то удивят. Тем менее, лично мне эта штука уже не раз помогла справиться с ерундовой работой, ради которой лень открывать конфигуратор. Попробуем теперь сделать что-то приближенное к "боевым условиям". У нас есть документы ЗаказПокупателя, Поступление и Отгрузка. Поступление делает запись в регистр остатков ТоварыНаСкладе со знаком "плюс". Отгрузка - со знаком "минус". ЗаказПокупателя пишет в регистр остатков ЗаказыПокупателей "плюс", Отгрузка пишет "минус", используя для этого реквизит Основание. Мы хотим определить: что мы можем сейчас отгрузить по оставшимся на текущий момент заказам покупателей. И создать документы Отгрузка на основе этих данных.
Разместим на рабочем поле элемент типа R c названием Подбор. Зададим ему следующие свойства:

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

Внутри элемента Заказы разместим два элемента типа A. Один из них назовем Еще, другой Все. Свойства элемента Еще зададим так:

А свойства элемента Все так (обратите внимание на команду Прервать):

В любой момент можно перейти в режим трэкинга и проконтролировать процесс.

Сейчас у нас есть в наличии вся необходимая информация и можно заняться созданием документов. Разместим рядом с элементом Подбор элемент типа R Отгрузка. Обратите внимание на источник. Здесь мы хотим получить содержимое элемента Подбор (т.е. то, что мы получили на предыдущем шаге). "Подбор.Заказы" означает, что мы хотим взять все элементы с нижнего уровня дерева (а Подбор - это дерево, как нетрудно догадаться). Наконец "...Заказы(Заказ)" говорит о том, что мы хотим сгруппировать полученные элементы по заказам. В результате мы получим дерево. На верхнем уровне будет перечень заказов. Уровнем ниже будут детальные строки. 

Внутри элемента Отгрузка разместим элементы Документ, СтрокиДокумента, Запись. Свойства элементов Документ и Запись, я думаю, вам сейчас уже должны быть очевидны. Свойства элемента СтрокиДокументы выглядят так. Обратите внимание на источник. Здесь мы обращаемся к элементу-родителю. Он ведь дерево, следовательно мы получим ветки.

Вот и вся задача. Можно запустить трэкинг и убедиться, что новые документы действительно создаются. А если эта штука нам действительно полезна в работе, можно создать еще один элемент типа A, перетащить туда элементы Подбор и Отгрузка, и задать расписание. 

В приложении к публикации вы найдете саму обработку, показанные здесь примеры в файлах test1.xml, test2.xml, test3.xml, а также тестовую базу.

Обработка тестировалась на управляемых формах. Платформа 8.3.10.2667. Код обработки полностью открыт.

48

Скачать файлы

Наименование Файл Версия Размер
ART - экспериментальный встроенный язык для 1С:
.rar 101,10Kb
07.12.18
5
.rar 101,10Kb 5 Скачать

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. bulpi 137 07.12.18 19:47 Сейчас в теме
4. mkalimulin 228 07.12.18 21:57 Сейчас в теме
2. pm74 130 07.12.18 20:30 Сейчас в теме
5. mkalimulin 228 07.12.18 21:58 Сейчас в теме
7. pm74 130 07.12.18 22:01 Сейчас в теме
(5) только непонятно нифига ))
что такое r и a
IgorS; for_sale; +2 Ответить
8. mkalimulin 228 08.12.18 00:40 Сейчас в теме
(7)
R - repeat, цикл
A - assembling, группа
Все элементы могут быть вложены друг в друга, и таким образом, образуют иерархию.
Но элемент R, в отличие от A, в момент трэкинга превращается во множество.
3. PerlAmutor 33 07.12.18 21:48 Сейчас в теме
Декларативное программирование на базе ООП?
6. mkalimulin 228 07.12.18 21:59 Сейчас в теме
(3) Да, вроде, не похоже на декларативное. Есть состояния и переменные. Вполне себе императивное.
9. Steelvan 08.12.18 12:15 Сейчас в теме
10. Dementor 338 08.12.18 12:59 Сейчас в теме
(9) тоже вспомнил и про скретч и про его предшественника ЛОГО.
12. mkalimulin 228 08.12.18 13:21 Сейчас в теме
(9) Спасибо. Я, конечно, знаю и Блокли и Скретч. Когда я преподавал программирование детям, я их часто использовал.
Но могу сказать, что эта идея не получила дальнейшего развития (Скретч создан 11 лет назад, Блокли 6).
На мой взгляд, это произошло потому, что авторы так и не смогли уйти от представления программы, как текста.
Т.е. они нам предлагают набор забавных блоков, но в результате, по их представлениям, должен получиться все равно ТЕКСТ ПРОГРАММЫ. А программа - не текст.
Dementor; +1 Ответить
11. Dementor 338 08.12.18 13:05 Сейчас в теме
(0) разделение документа на 2 это мало интересно. Предположим у нас есть какие-то управленческие документы с описанием затрат в разрезе статей затрат. Раньше все можно было писать в один документ, что обычно и делали. Но руководство приняло решение - каждый вид затрат писать в отдельный документ и разграничить доступ по статьям затрат (не ищите логику - пример из пальца). У нас документ может остаться нетронутым, может разделится на два, три... десять... сто... Количество гипотетических разделений зависит от размера справочника статей затрат, который наполняется в реальном времени. Сможет ли АРТ справится с таким вызовом? :)
13. mkalimulin 228 08.12.18 13:24 Сейчас в теме
(11) Ну разумеется. ART - Тьюринг-полный инструмент.
14. mkalimulin 228 08.12.18 13:30 Сейчас в теме
(11) Кстати, выглядеть это будет проще, чем вам кажется. Если внимательно посмотрите на пример 3, вы найдете решение этой задачи.
15. genayo 08.12.18 13:51 Сейчас в теме
Интересно, но слишком абстрактно, на мой взгляд. Gherkin и ему подобные в этом отношении выглядят более перспективно.
16. mkalimulin 228 08.12.18 15:01 Сейчас в теме
(15) Gherkin - это язык. ART - не язык. ART - инструмент программирования, показывающий, что можно программировать без языка.
Да, и разве мои примеры абстрактны? А что тогда конкретно?
17. genayo 08.12.18 16:10 Сейчас в теме
(16) А зачем без языка программировать? И, конкретно, интерфейс на ART нарисовать можно?
18. mkalimulin 228 08.12.18 16:40 Сейчас в теме
(17) Затем, что язык - не самое адекватное средство для представления программы. Инструментов для рисования интерфейса и так слишком много.
19. genayo 08.12.18 18:04 Сейчас в теме
(18)Хорошо..Но кроме вас никто этим пользоваться не будет...
20. mkalimulin 228 08.12.18 20:48 Сейчас в теме
21. Steelvan 08.12.18 20:52 Сейчас в теме
(20) Перестаньте кормить местного тролля, там бесполезно задавать вопросы, надеясь на вразумительный ответ, он во всех умных темах пытается поучаствовать.
Aggressorak; trntv; alk; nomadon; +4 Ответить
22. mkalimulin 228 08.12.18 22:53 Сейчас в теме
(21) Положение автора обязывает отвечать на все вопросы и а также задавать вопросы для прояснения позиции комментатора. Разумеется, в рамках темы.
24. genayo 09.12.18 07:25 Сейчас в теме
(21) ... а караван идёт. С добрым утром, Дружок!
23. genayo 09.12.18 07:24 Сейчас в теме
(20) Что упрощает ваш инструмент? В чём преимущества его использования? Для кого он?
25. mkalimulin 228 09.12.18 10:09 Сейчас в теме
(23) Посмотрите на пост (11). Автор поста обозначил задачу, которую он считает сложной, называет ее вызовом.
Когда он поймет, что решение этой задачи в ART состоит из трех блоков вложенных в еще один (всего четыре блока), возможно, он захочет пользоваться таким инструментом.
ART упрощает процесс программирования. И предназначен для всех, кому так или иначе приходится этим процессом заниматься.
Но в чем-то я с вами согласен. Надо будет добавить не просто пример, а что-нибудь имеющее практическую ценность. Я подумаю.
26. genayo 09.12.18 10:43 Сейчас в теме
(25) Преимущества вашего инструмента не очевидны из статьи, нужны сравнительные примеры.
29. mkalimulin 228 09.12.18 12:16 Сейчас в теме
(26) У меня есть соображения насчет этого. Но потребуется некоторое время. Следите за темой.
30. genayo 09.12.18 14:14 Сейчас в теме
(29) Хорошо, поставил плюс :)
59. gaglo 12.12.18 14:54 Сейчас в теме
(16) Хитро придумано, и захотелось попробовать. Времени нет, как всегда, ...
Но от раскрытия темы аж вздрогнул...
инструмент программирования, показывающий, что можно программировать без языка

так напомнило
для программиста же желателен пользователь безрукий (или, по крайней мере, лишенный клавиатуры и мыши)

(Котеров Д. В., Костарев А. Ф. - PHP 5. 2-е издание (В подлиннике) - 2008)
27. necropunk 5 09.12.18 12:02 Сейчас в теме
Вообще, не имея доступ к конфигуратору, если навскидку бы прилетели такие задачи - я бы запустил базу в толстом клиенте и воспользовался Инструментами Разработчика. Но это навскидку. Выглядит все очень интересно, но непривычно, сходу не могу начать думать на предложенных конструкциях. Но попробую обязательно, спасибо, очень любопытно.
Team leader; zqzq; +2 Ответить
28. mkalimulin 228 09.12.18 12:15 Сейчас в теме
(27) Спасибо за отзыв! Я исходил из того, что инструмент должен обладать Тьюринговой полнотой. Т.е. решать в принципе любые задачи. Представьте что вам надо разово сделать то, что описано в примере 3. Сравните - что бы вам пришлось слелать в Инструментах разработчика и что делается в ART.
40. Team leader 7 10.12.18 12:04 Сейчас в теме
(27) Интересно было бы - взглянуть на 1,2 фичи - аля ИР.
31. trustasia 12 10.12.18 06:46 Сейчас в теме
Я хотел бы с Вами связаться по Вашим работам в этом направлении. Есть созвучная идея, которую я один наверное не потяну. Ознакомившись с этим материалом, понял, чего мне не хватало - действительно, текстовость языка лишний груз. Просьба связаться в личной переписке.
32. for_sale 293 10.12.18 09:34 Сейчас в теме
1C когда-то создавалась для того, чтобы бухгалтеры, не зная программирования, могли быстро и интуитивно "подправить" программу :) А потом всё заверте...

Что касается предмета статьи - так и не понял, зачем это изобретение? Если просто абстрактно, то ок. А применять это... Ну справа, в значениях, например, уже есть какие-то конструкции из программирования, операторы, имена реквизитов и объектов конфигурации и т.п. Т.е. программировать без языка уже не получится, надо как минимум иметь какие-то основы, лезть в конфигуратор за метаданными и т.п.

То, что это - Тьюринг-полный инструмент, конечно, прекрасно. Но любой язык программирования - тоже, в том числе 1С.

Чтобы начать это использовать, нужны какие-то преимущества (даже, наверное, серьёзные) перед остальными инструментами. Какой порог вхождения в это знание? Как долго нужно обучаться работе? Насколько сократится время на разработку? Судя по длине статьи - как минимум обучаться нужно, ничего интуитивного там нет, а время на разработку - пока что кажется, что кодом как минимум не дольше. И в результате возвращаемся к первому вопросу - а зачем?
user595646_formsg2007; +1 Ответить
45. mkalimulin 228 10.12.18 16:22 Сейчас в теме
(32) Хорошо, что вы вспомнили про бухгалтеров.
Да, я рассчитываю на то, что инструментом будут пользоваться все. И бухгалтеры тоже.
Я исхожу из следующего. Для того, чтобы получить настоящую пользу от ИТ-технологий, необходимо программировать.
Но программирование до сих пор еще не пошло в массы. И причина этому в том, что то программирование, которое практикуется сейчас - настоящее извращение. А люди в большинстве своем предпочитают естественное. ART - это инструмент для программирования естественным способом.
Возможно, вас сбивает с толку простота инструмента. В моих трех примерах содержится практически полное описание инструмента. В нем больше ничего нет. И больше ничего и не надо для ведения учета.
Насчет залезания в Конфигуратор. Я хотел сделать браузер объектов (как в конструкторе запросов), но потом отложил это на более поздние версии.
В любом случае, спасибо вам за отзыв. Вы мне напомнили о том, что описание все-таки следует добавить.
33. brr 175 10.12.18 09:44 Сейчас в теме
Интересно. Как встроить вызов вашего языка в 1С? Например, в обработку проведения.
34. mkalimulin 228 10.12.18 09:55 Сейчас в теме
(33) Кстати, да. Хорошая идея - добавить программный интерфейс. Спасибо.
35. brr 175 10.12.18 10:01 Сейчас в теме
(34) И генератор кода 1С :). Чтобы не тратить время на обработку схемы. А еще обратное преобразование из 1С кода в схему :). Красотень.
36. mkalimulin 228 10.12.18 10:08 Сейчас в теме
(35) Тогда придется отдел разработки 1С брать на подряд ))
Но, конечно, преобразователь - тема серьезная. А то тут все спрашивают: а чем это лучше? Действительно, дал людям преобразователь. Они преобразовали "простынку" кода в три-четыре блока. И больше вопросов не задают.
Надо подумать.
37. brr 175 10.12.18 10:30 Сейчас в теме
(36)Ну не сразу, задача сложная. Можно разбить на этапы. 1. программный интерфейс,2. генератор кода и т.д. Поместите в github - поможем.
38. pm74 130 10.12.18 10:49 Сейчас в теме
(36) я около года назад занимался чем то подобным см. рис.
правда идея была не в том , чтобы уйти от кода совсем , а в том , чтобы декомпозировать его на примитивные блоки , передав логику управления на более абстрактный уровень


В принципе вашу систему тоже можно рассматривать как некий случай КА с "неявным" выделением состояний. Ну.. мне так кажется на первый взгляд.

правда потом столкнулся с рядом проблем и (примерно на год ) забиыл про это дело , и вот недавно (кое что переосмыслив) вновь вернулся теме

странное дело (я про это уже неоднократно высказывался) , сходные (по смыслу ) решения появляются у разных людей примерно в одном промежутке времени. Тут поневоле начинаешь задумываться о "коллективном разуме" ))
Прикрепленные файлы:
btr; trustasia; user642070_seperblunt; +3 Ответить
51. mkalimulin 228 10.12.18 17:52 Сейчас в теме
(38) Я так понимаю, что просто пришло время программированию уйти в массы. Вы можете свободно использовать любые идеи или куски кода из этой публикации. Я буду рад,если это поможет вам продвинуться.
39. brr 175 10.12.18 11:19 Сейчас в теме
(36)Продолжу надоедать вопросами. Как дела обстоят с запросами? Работа с табличными документами? Можно ли вызывать методы из других схем? Ну и вишенка, рекурсия поддерживается? :)
46. mkalimulin 228 10.12.18 17:23 Сейчас в теме
(39) Внутри запросы, конечно же используются. На уровне инструмента никакие особые конструкции не нужны. Есть элемент-итератор, у него задан источник. Вот собственно и все. Вывод в табличный документ не считаю нужным поддерживать. Это - пережиток докомпьютерных технологий. Использовать табличный документ (в различных форматах) как источник - это другое дело. Можно и реализовать для совместимости. Но это не самое первое дело.
Я планирую расширять понятие источника. В представленной сейчас версии источником может быть база 1С и переменные среды выполнения. Но в принципе,это может быть и не 1С-овская база данных, может быть результат HTTP-запроса, может быть таблица Excel (вот здесь, да, появится табличный документ).
По поводу повторного использования одного и того же у меня есть определенные соображения. Но они пока еще "сырые" и не вошли в стартовую версию.
Любая рекурсия может быть представлена в виде цикла. Пока остановился на этом. Я думал над тем, как поизящнее реализовать обход источника с произвольным количеством уровней. Найденные варианты мне не нравятся.
47. brr 175 10.12.18 17:26 Сейчас в теме
(46) Спасибо за развернутый ответ
43. for_sale 293 10.12.18 16:11 Сейчас в теме
(36)
а пример преобразованной простынки можно?

Я вот тоже не понимаю, чем это лучше и как можно с помощью этого получить повышение производительности и упрощение работы?

Кстати, оба фактора важны. Есть такой язык - ифкуиль. Типа как архиватор языка. Можно выражать длинные мысли несколькими звуками. Вроде как повышает производительность мыслительного процесса и речи. Но из-за очень большой сложности всё равно не нашёл распространения.
50. mkalimulin 228 10.12.18 17:39 Сейчас в теме
(43) Производительность можно обеспечить только если реализовывать ART на уровне платформы. Но, как показывает опыт, выразительность важнее производительности. Алгол тоже проигрывал в производительности автокоду.
44. for_sale 293 10.12.18 16:13 Сейчас в теме
(35)
А там и до написания своего языка для общения с 1С недалеко:) И будет 1С внутри 1С! Да и кто вообще может гарантировать, что мы все не находимся внутри какого-то 1С верхнего уровня? :))
41. Alien_job 160 10.12.18 14:03 Сейчас в теме
48. mkalimulin 228 10.12.18 17:29 Сейчас в теме
(41) Этому Дракону больше четверти века. Его проблема в том, что блок-схема - это тоже текст. Чтобы инструмент стал действительно "Д"-дружественным, надо уйти от текста.
42. vano-ekt 1129 10.12.18 14:40 Сейчас в теме
а какой-нибудь рег.отчет/общий модуль с тысячей методов можно посмотреть на ARTe как будет смотреться?
В обучении, в описании алгоритмов такие языки может быть... Но в прикладной, практической разработке в мире 1С не представляю их.
Описывать какой-то автомат, сервис - может быть. А написать учетную систему? Тут чаще гибкость, чем абстрактность нужна...
а плюсану-ка
Лет через 20 может на код 1С будт смотреть как на
49. mkalimulin 228 10.12.18 17:34 Сейчас в теме
(42) После того, как мне уже сказали: "дайте что-нибудь конкретное", я как раз в сторону налоговых деклараций и смотрю. Потребуется немного времени. Следите за темой.
52. Мичман Харитонов 11.12.18 10:39 Сейчас в теме
Интересно. С таким инструментарием программировать ну, скажем... на мобильном устройстве будет гораздо удобнее, чем традиционно набирать текст. Ну и в учебных целях, опять же. Это гораздо лучше, чем рисовать "мертвые" блок-схемы в тетрадке.
53. mkalimulin 228 11.12.18 10:49 Сейчас в теме
(52) Безусловно. Когда программирование пойдет в массы, люди в основном и будут программировать на смартфонах.
А блок-схемы, как я уже говорил, это - те же тексты.
54. Darklight 16 11.12.18 11:56 Сейчас в теме
Любопытная идея программирования. Лично мне было бы интересно видеть нечто подобное в 1С: Предприятие 9 - на самом высоком уровне абстракции (а я хотел бы надеяться что в 9-ке всё-таки произойдёт разделение разработки по уровням абстракции) - а наивысший уровень - это уровень программирования логики бизнес-процессов, аналитических инструментов и простых обработок данных - естественно без применения императивного программирования (хотя некоторые декларатативные высокоуровневые скрипты возможны). Но на этом уровне, работа должна вестись с блоками архитектуры и кода, которые будут созданы на более низком уровне абстракции. А инструменты работы с этими блоками должны быть похожи на описанные здесь подходы.

А вот ART сейчас не хватает пяти вещей:
1. Библиотек повторного использования
2. Обобщённых шаблонов недетерменированных алгоритмов - детерменируемых по ходу применения через принципы, замены суперпозиции и карирования
3. Готовых универсальных настраиваемых паттернов проектирования
4. Расширения (наследования с полиморфизмом) - для создания новых операций на основе имеющихся с их частичным видоизменением
5. Встроенных операций ввода/вывода - как для ввода входных данных (как интеррактивному, так и из произвольных источников), так и для преобразования результата к нужному формату
57. btr 12.12.18 13:55 Сейчас в теме
(54) А можете привести какие-нибудь примеры ИСР, где бы поддерживались хотя бы плохо и коряво уровни абстракции?

Что касается Вашего пункта 5, то это не только ввод-вывод, это всевозможные протоколы и интерфейсы взаимодействия и управления. Тоже не встречал толково реализованного подхода к обобщению этой задачи, все в конечном итоге реализуется самостоятельными моделями, вроде MVVM или более древних MVP, MVC, MVCP и прочих.

Я бы еще добавил идею архитектурного ландшафта системы (т.е. определение архитектуры и разработку, как декомпозицию блоков и связей).
60. Darklight 16 12.12.18 17:53 Сейчас в теме
(57) В пункте 2 я в первую очередь думал об идеи шаблонов языка С++, и о функциональных языках.
В 5-том пункте об интерфейсах думал только о средстве ввода и вывода данных. А не об архитектуре взаимодействия человек-данные
61. mkalimulin 228 12.12.18 18:08 Сейчас в теме
(54) С 1 и 3 согласен. И даже одно время хотел включить в стартовую версию.
Насчет 2 и 4 есть опасения, что пропадет простота инструмента.
По п.5 готов спорить. Встроенная операция ввода есть. Указываете источник для итератора - вот вам и ввод. Можно и нужно расширять понятие источника, включая, например: произвольные БД, HTTP-запросы, табличные документы.
Выходные же форматы, как мне кажется, не стоят усилий. Есть формат ART, в нем заложена органичная связь между дизайном и результатом.
55. yurikmellon 11.12.18 13:58 Сейчас в теме
очень интересно, попробую
62. mkalimulin 228 12.12.18 18:09 Сейчас в теме
56. btr 12.12.18 13:48 Сейчас в теме
Чего мне обычно не хватает как разработчику - это структуризации текста, с одной стороны (чтобы размечать конструкции, сворачивать их и разворачивать) и визуальный контроль контекста (т.е. какие объекты, структуры, переменные доступны в текущей конструкции, в модуле, в экспортных модулях, в подключенных API) - это два разных инструмента и их можно реализовать раздельно.

Но метафора текста очень глубоко сидит в умах разработчиков. Чтобы ее победить, нужна новая, очень сильная метафора. Одним структурированием здесь не обойтись. В конечном счете разные ассистенты при работе с текстом - тоже способ повышения производительности.

Я давно не слежу за широким спектром средств разработки, но даже идеи 20-летней давности все еще не реализованы.

Конечно, средства уровня игры - это несерьезно. Только способ представить концепцию.

Нужно серьезное промышленное средство визуального проектирования кода. А тут еще постепенно подпирают новые парадигмы. Нейросети, квантовые алгоритмы.

Может быть попробую на новогодних каникулах написать статью по нескольким серьезным парадигмам визуального проектирования кода, которые пока толком не рассматривались широким сообществом и не выходили за пределы очень небольших исследовательских групп.

Ведь даже идею структурирования текстового кода не так просто во всех аспектах изложить, а уж идею визуализации контекста для каждого конкретного места в программе - вообще нужно начинать с нуля, поскольку подходящих метафор и вовсе нет (только в общих чертах идеи манифестов и оркестровки, разве что)
63. mkalimulin 228 12.12.18 18:15 Сейчас в теме
(56) Сначала была метафора бесконечной ленты. Потом доказательство, что любая программа может быть представлена в виде текста. Так и пошло-поехало. В сущности, на чем бы вы сейчас ни писали, вы пишите на слегка улучшенном брейнфаке.
58. adwas777 12.12.18 14:49 Сейчас в теме
так или иначе, собственно текст программ остался и в вашем инструменте, верно?
то есть, это - при всей её оригинальности - красивая обёртка, чтобы не писать циклы,
а так, как по мне, если серьёзный алгоритм какой, то по сути облегчения понимания или визуального представления не видно.

возможно, в этом смысле всё же лучше вести в сторону ФП?
64. mkalimulin 228 12.12.18 18:20 Сейчас в теме
(58) Нет. В моем инструменте нет текста. Есть то, что я называю ART. В каждый момент времени вы видите только то, что может поместиться в вашу оперативную память.
65. adwas777 12.12.18 21:21 Сейчас в теме
(64)
А вот это: Подбор(Заказ), Цена = Цена*1.1 и т.п. - это не текст?
66. mkalimulin 228 12.12.18 21:27 Сейчас в теме
(65) Нет, конечно. На картинке вверху два прямоугольника, внизу таблица свойств )))
Если серьезно, текстом надо называть все, что разбито на строки и количество строк превышает верхний предел оперативной памяти человека.
67. btr 12.12.18 23:39 Сейчас в теме
(66) Да, метафора текста не в том, что в отдельных блоках есть текст, а в том, что сам алгоритм представлен текстом.
Бесконечная лента уже не совсем лента - конвейеры, треды, параллельное исполнение.

А вот проектирование этого самого кода - все еще на основе текста. Лонгриды.

Поэтому, мне кажется наиболее уместным на верхнем уровне представления - архитектурный ландшафт системы. Но пока эта метафора не вполне интуитивна. Это что-то вроде доков в порту, например. Было бы лучше сказать про космопорт, этакое 3d. А в случае наличия в системе разных GPU или других массивов параллельной обработки, так и 4d не лишним будет :) Но это уже на правах тухленького юмора.

Я и сам пока ищу хорошие метафоры для современных средств разработки.

Идея ART будет понятнее, когда пройдет испытания масштабным проектом. Будем присматриваться, следить за новостями.
Оставьте свое сообщение