ART — экспериментальный инструмент программирования






















Насколько сложным должен быть встроенный инструмент программирования для такой системы, как 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. Код обработки полностью открыт.

 

Update 22.12.2024

Добавлены новые источники итераций.

COM. Поддерживает только один объект V83.COMConnector. Позволяет подключаться к любым базам 1С.

ADO. Универсален. В частности, можно использовать для получения данных из Excel.

Архив содержит демо-примеры.

Update 30.12.2024

В процессе работы над декларацией по НДС, выяснилось, что нужны свойства без имени. Я решил, что такие свойства будут размещаться не в списке свойств, а прямо в рабочем поле.
Теперь ART можно использовать как "табло" (была такая штука в предыдущих версиях 1С). В режиме дизайна пишите выражения в рабочем поле.

 

В режиме трэкинга получаете их значения.

 

Update 26.01.2024

Добавлена декларация по НДС. Этот ART состоит из 61 элемента (22 для книги покупок, 22 для книги продаж, 16 для декларации и 1 элемент настройки). По сравнению с 1С-овским отчетом, в котором не менее 25 тысч строк кода — это совсем немного. А главное — гораздо более понятно и доступно. ART предназначен для работы в типовой конфигурации "Бухгалтерия предприятия". Тестировалаось на релизе 3.0.67.43. Платформа 8.3.12.1790.

ОБРАТИТЕ ВНИМАНИЕ. Этот продукт предназначен для ознакомления с экспериментальной технологией. Хотя он и будет работать в большинстве случаев, автор не может гарантировать этого для вас конкретно. Если вы захотите использовать его в реальной работе, то есть вероятность, что вам придется его донастраивать (впрочем, это совсем несложно).

Update 02.02.2024

Добавлен отчет СЗВ-М. Тестировалаось на релизе БП 3.0.65.91. Платформа 8.3.12.1790. В архиве последняя версия обработки, файл отчета и короткая инструкция. Еще раз напоминаю, что отчет предлагается as is. В нем всего 41 элемент. Разобраться намного проще, чем в типовой тысяче (на самом деле еще больше) строк, разбросанной по разным модулям.    

 

97 Comments

  1. bulpi

    Прикольно 🙂

    Reply
  2. pm74

    интересно , + за идею

    Reply
  3. PerlAmutor

    Декларативное программирование на базе ООП?

    Reply
  4. mkalimulin

    (1) Мне тоже. Спасибо!

    Reply
  5. mkalimulin

    (2) Спасибо за отзыв!

    Reply
  6. mkalimulin

    (3) Да, вроде, не похоже на декларативное. Есть состояния и переменные. Вполне себе императивное.

    Reply
  7. pm74

    (5) только непонятно нифига ))

    что такое r и a

    Reply
  8. mkalimulin

    (7)

    R — repeat, цикл

    A — assembling, группа

    Все элементы могут быть вложены друг в друга, и таким образом, образуют иерархию.

    Но элемент R, в отличие от A, в момент трэкинга превращается во множество.

    Reply
  9. Steelvan

    Автор, вот еще источник идей.

    https://habr.com/post/145067/

    Reply
  10. Dementor

    (9) тоже вспомнил и про скретч и про его предшественника ЛОГО.

    Reply
  11. Dementor

    (0) разделение документа на 2 это мало интересно. Предположим у нас есть какие-то управленческие документы с описанием затрат в разрезе статей затрат. Раньше все можно было писать в один документ, что обычно и делали. Но руководство приняло решение — каждый вид затрат писать в отдельный документ и разграничить доступ по статьям затрат (не ищите логику — пример из пальца). У нас документ может остаться нетронутым, может разделится на два, три… десять… сто… Количество гипотетических разделений зависит от размера справочника статей затрат, который наполняется в реальном времени. Сможет ли АРТ справится с таким вызовом? 🙂

    Reply
  12. mkalimulin

    (9) Спасибо. Я, конечно, знаю и Блокли и Скретч. Когда я преподавал программирование детям, я их часто использовал.

    Но могу сказать, что эта идея не получила дальнейшего развития (Скретч создан 11 лет назад, Блокли 6).

    На мой взгляд, это произошло потому, что авторы так и не смогли уйти от представления программы, как текста.

    Т.е. они нам предлагают набор забавных блоков, но в результате, по их представлениям, должен получиться все равно ТЕКСТ ПРОГРАММЫ. А программа — не текст.

    Reply
  13. mkalimulin

    (11) Ну разумеется. ART — Тьюринг-полный инструмент.

    Reply
  14. mkalimulin

    (11) Кстати, выглядеть это будет проще, чем вам кажется. Если внимательно посмотрите на пример 3, вы найдете решение этой задачи.

    Reply
  15. genayo

    Интересно, но слишком абстрактно, на мой взгляд. Gherkin и ему подобные в этом отношении выглядят более перспективно.

    Reply
  16. mkalimulin

    (15) Gherkin — это язык. ART — не язык. ART — инструмент программирования, показывающий, что можно программировать без языка.

    Да, и разве мои примеры абстрактны? А что тогда конкретно?

    Reply
  17. genayo

    (16) А зачем без языка программировать? И, конкретно, интерфейс на ART нарисовать можно?

    Reply
  18. mkalimulin

    (17) Затем, что язык — не самое адекватное средство для представления программы. Инструментов для рисования интерфейса и так слишком много.

    Reply
  19. mkalimulin

    (19) Почему?

    Reply
  20. Steelvan

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

    Reply
  21. mkalimulin

    (21) Положение автора обязывает отвечать на все вопросы и а также задавать вопросы для прояснения позиции комментатора. Разумеется, в рамках темы.

    Reply
  22. genayo

    (20) Что упрощает ваш инструмент? В чём преимущества его использования? Для кого он?

    Reply
  23. mkalimulin

    (23) Посмотрите на пост (11). Автор поста обозначил задачу, которую он считает сложной, называет ее вызовом.

    Когда он поймет, что решение этой задачи в ART состоит из трех блоков вложенных в еще один (всего четыре блока), возможно, он захочет пользоваться таким инструментом.

    ART упрощает процесс программирования. И предназначен для всех, кому так или иначе приходится этим процессом заниматься.

    Но в чем-то я с вами согласен. Надо будет добавить не просто пример, а что-нибудь имеющее практическую ценность. Я подумаю.

    Reply
  24. genayo

    (25) Преимущества вашего инструмента не очевидны из статьи, нужны сравнительные примеры.

    Reply
  25. necropunk

    Вообще, не имея доступ к конфигуратору, если навскидку бы прилетели такие задачи — я бы запустил базу в толстом клиенте и воспользовался Инструментами Разработчика. Но это навскидку. Выглядит все очень интересно, но непривычно, сходу не могу начать думать на предложенных конструкциях. Но попробую обязательно, спасибо, очень любопытно.

    Reply
  26. mkalimulin

    (27) Спасибо за отзыв! Я исходил из того, что инструмент должен обладать Тьюринговой полнотой. Т.е. решать в принципе любые задачи. Представьте что вам надо разово сделать то, что описано в примере 3. Сравните — что бы вам пришлось слелать в Инструментах разработчика и что делается в ART.

    Reply
  27. mkalimulin

    (26) У меня есть соображения насчет этого. Но потребуется некоторое время. Следите за темой.

    Reply
  28. genayo

    (29) Хорошо, поставил плюс 🙂

    Reply
  29. trustasia

    Я хотел бы с Вами связаться по Вашим работам в этом направлении. Есть созвучная идея, которую я один наверное не потяну. Ознакомившись с этим материалом, понял, чего мне не хватало — действительно, текстовость языка лишний груз. Просьба связаться в личной переписке.

    Reply
  30. for_sale

    1C когда-то создавалась для того, чтобы бухгалтеры, не зная программирования, могли быстро и интуитивно «подправить» программу 🙂 А потом всё заверте…

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

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

    Чтобы начать это использовать, нужны какие-то преимущества (даже, наверное, серьёзные) перед остальными инструментами. Какой порог вхождения в это знание? Как долго нужно обучаться работе? Насколько сократится время на разработку? Судя по длине статьи — как минимум обучаться нужно, ничего интуитивного там нет, а время на разработку — пока что кажется, что кодом как минимум не дольше. И в результате возвращаемся к первому вопросу — а зачем?

    Reply
  31. brr

    Интересно. Как встроить вызов вашего языка в 1С? Например, в обработку проведения.

    Reply
  32. mkalimulin

    (33) Кстати, да. Хорошая идея — добавить программный интерфейс. Спасибо.

    Reply
  33. brr

    (34) И генератор кода 1С :). Чтобы не тратить время на обработку схемы. А еще обратное преобразование из 1С кода в схему :). Красотень.

    Reply
  34. mkalimulin

    (35) Тогда придется отдел разработки 1С брать на подряд ))

    Но, конечно, преобразователь — тема серьезная. А то тут все спрашивают: а чем это лучше? Действительно, дал людям преобразователь. Они преобразовали «простынку» кода в три-четыре блока. И больше вопросов не задают.

    Надо подумать.

    Reply
  35. brr

    (36)Ну не сразу, задача сложная. Можно разбить на этапы. 1. программный интерфейс,2. генератор кода и т.д. Поместите в github — поможем.

    Reply
  36. pm74

    (36) я около года назад занимался чем то подобным см. рис.

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

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

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

    странное дело (я про это уже неоднократно высказывался) , сходные (по смыслу ) решения появляются у разных людей примерно в одном промежутке времени. Тут поневоле начинаешь задумываться о «коллективном разуме» ))

    Reply
  37. brr

    (36)Продолжу надоедать вопросами. Как дела обстоят с запросами? Работа с табличными документами? Можно ли вызывать методы из других схем? Ну и вишенка, рекурсия поддерживается? 🙂

    Reply
  38. Team leader

    (27) Интересно было бы — взглянуть на 1,2 фичи — аля ИР.

    Reply
  39. Alien_job
  40. vano-ekt

    а какой-нибудь рег.отчет/общий модуль с тысячей методов можно посмотреть на ARTe как будет смотреться?

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

    Описывать какой-то автомат, сервис — может быть. А написать учетную систему? Тут чаще гибкость, чем абстрактность нужна…

    а плюсану-ка

    Лет через 20 может на код 1С будт смотреть как на

    Reply
  41. for_sale

    (36)

    а пример преобразованной простынки можно?

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

    Кстати, оба фактора важны. Есть такой язык — ифкуиль. Типа как архиватор языка. Можно выражать длинные мысли несколькими звуками. Вроде как повышает производительность мыслительного процесса и речи. Но из-за очень большой сложности всё равно не нашёл распространения.

    Reply
  42. for_sale

    (35)

    А там и до написания своего языка для общения с 1С недалеко:) И будет 1С внутри 1С! Да и кто вообще может гарантировать, что мы все не находимся внутри какого-то 1С верхнего уровня? :))

    Reply
  43. mkalimulin

    (32) Хорошо, что вы вспомнили про бухгалтеров.

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

    Я исхожу из следующего. Для того, чтобы получить настоящую пользу от ИТ-технологий, необходимо программировать.

    Но программирование до сих пор еще не пошло в массы. И причина этому в том, что то программирование, которое практикуется сейчас — настоящее извращение. А люди в большинстве своем предпочитают естественное. ART — это инструмент для программирования естественным способом.

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

    Насчет залезания в Конфигуратор. Я хотел сделать браузер объектов (как в конструкторе запросов), но потом отложил это на более поздние версии.

    В любом случае, спасибо вам за отзыв. Вы мне напомнили о том, что описание все-таки следует добавить.

    Reply
  44. mkalimulin

    (39) Внутри запросы, конечно же используются. На уровне инструмента никакие особые конструкции не нужны. Есть элемент-итератор, у него задан источник. Вот собственно и все. Вывод в табличный документ не считаю нужным поддерживать. Это — пережиток докомпьютерных технологий. Использовать табличный документ (в различных форматах) как источник — это другое дело. Можно и реализовать для совместимости. Но это не самое первое дело.

    Я планирую расширять понятие источника. В представленной сейчас версии источником может быть база 1С и переменные среды выполнения. Но в принципе,это может быть и не 1С-овская база данных, может быть результат HTTP-запроса, может быть таблица Excel (вот здесь, да, появится табличный документ).

    По поводу повторного использования одного и того же у меня есть определенные соображения. Но они пока еще «сырые» и не вошли в стартовую версию.

    Любая рекурсия может быть представлена в виде цикла. Пока остановился на этом. Я думал над тем, как поизящнее реализовать обход источника с произвольным количеством уровней. Найденные варианты мне не нравятся.

    Reply
  45. brr

    (46) Спасибо за развернутый ответ

    Reply
  46. mkalimulin

    (41) Этому Дракону больше четверти века. Его проблема в том, что блок-схема — это тоже текст. Чтобы инструмент стал действительно «Д»-дружественным, надо уйти от текста.

    Reply
  47. mkalimulin

    (42) После того, как мне уже сказали: «дайте что-нибудь конкретное», я как раз в сторону налоговых деклараций и смотрю. Потребуется немного времени. Следите за темой.

    Reply
  48. mkalimulin

    (43) Производительность можно обеспечить только если реализовывать ART на уровне платформы. Но, как показывает опыт, выразительность важнее производительности. Алгол тоже проигрывал в производительности автокоду.

    Reply
  49. mkalimulin

    (38) Я так понимаю, что просто пришло время программированию уйти в массы. Вы можете свободно использовать любые идеи или куски кода из этой публикации. Я буду рад,если это поможет вам продвинуться.

    Reply
  50. Мичман Харитонов

    Интересно. С таким инструментарием программировать ну, скажем… на мобильном устройстве будет гораздо удобнее, чем традиционно набирать текст. Ну и в учебных целях, опять же. Это гораздо лучше, чем рисовать «мертвые» блок-схемы в тетрадке.

    Reply
  51. mkalimulin

    (52) Безусловно. Когда программирование пойдет в массы, люди в основном и будут программировать на смартфонах.

    А блок-схемы, как я уже говорил, это — те же тексты.

    Reply
  52. Darklight

    Любопытная идея программирования. Лично мне было бы интересно видеть нечто подобное в 1С: Предприятие 9 — на самом высоком уровне абстракции (а я хотел бы надеяться что в 9-ке всё-таки произойдёт разделение разработки по уровням абстракции) — а наивысший уровень — это уровень программирования логики бизнес-процессов, аналитических инструментов и простых обработок данных — естественно без применения императивного программирования (хотя некоторые декларатативные высокоуровневые скрипты возможны). Но на этом уровне, работа должна вестись с блоками архитектуры и кода, которые будут созданы на более низком уровне абстракции. А инструменты работы с этими блоками должны быть похожи на описанные здесь подходы.

    А вот ART сейчас не хватает пяти вещей:

    1. Библиотек повторного использования

    2. Обобщённых шаблонов недетерменированных алгоритмов — детерменируемых по ходу применения через принципы, замены суперпозиции и карирования

    3. Готовых универсальных настраиваемых паттернов проектирования

    4. Расширения (наследования с полиморфизмом) — для создания новых операций на основе имеющихся с их частичным видоизменением

    5. Встроенных операций ввода/вывода — как для ввода входных данных (как интеррактивному, так и из произвольных источников), так и для преобразования результата к нужному формату

    Reply
  53. yurikmellon

    очень интересно, попробую

    Reply
  54. btr

    Чего мне обычно не хватает как разработчику — это структуризации текста, с одной стороны (чтобы размечать конструкции, сворачивать их и разворачивать) и визуальный контроль контекста (т.е. какие объекты, структуры, переменные доступны в текущей конструкции, в модуле, в экспортных модулях, в подключенных API) — это два разных инструмента и их можно реализовать раздельно.

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

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

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

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

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

    Ведь даже идею структурирования текстового кода не так просто во всех аспектах изложить, а уж идею визуализации контекста для каждого конкретного места в программе — вообще нужно начинать с нуля, поскольку подходящих метафор и вовсе нет (только в общих чертах идеи манифестов и оркестровки, разве что)

    Reply
  55. btr

    (54) А можете привести какие-нибудь примеры ИСР, где бы поддерживались хотя бы плохо и коряво уровни абстракции?

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

    Я бы еще добавил идею архитектурного ландшафта системы (т.е. определение архитектуры и разработку, как декомпозицию блоков и связей).

    Reply
  56. adwas777

    так или иначе, собственно текст программ остался и в вашем инструменте, верно?

    то есть, это — при всей её оригинальности — красивая обёртка, чтобы не писать циклы,

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

    возможно, в этом смысле всё же лучше вести в сторону ФП?

    Reply
  57. gaglo

    (16) Хитро придумано, и захотелось попробовать. Времени нет, как всегда, …

    Но от раскрытия темы аж вздрогнул…

    инструмент программирования, показывающий, что можно программировать без языка

    так напомнило

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

    (Котеров Д. В., Костарев А. Ф. — PHP 5. 2-е издание (В подлиннике) — 2008)

    Reply
  58. Darklight

    (57) В пункте 2 я в первую очередь думал об идеи шаблонов языка С++, и о функциональных языках.

    В 5-том пункте об интерфейсах думал только о средстве ввода и вывода данных. А не об архитектуре взаимодействия человек-данные

    Reply
  59. mkalimulin

    (54) С 1 и 3 согласен. И даже одно время хотел включить в стартовую версию.

    Насчет 2 и 4 есть опасения, что пропадет простота инструмента.

    По п.5 готов спорить. Встроенная операция ввода есть. Указываете источник для итератора — вот вам и ввод. Можно и нужно расширять понятие источника, включая, например: произвольные БД, HTTP-запросы, табличные документы.

    Выходные же форматы, как мне кажется, не стоят усилий. Есть формат ART, в нем заложена органичная связь между дизайном и результатом.

    Reply
  60. mkalimulin

    (55) Спасибо за отзыв.

    Reply
  61. mkalimulin

    (56) Сначала была метафора бесконечной ленты. Потом доказательство, что любая программа может быть представлена в виде текста. Так и пошло-поехало. В сущности, на чем бы вы сейчас ни писали, вы пишите на слегка улучшенном брейнфаке.

    Reply
  62. mkalimulin

    (58) Нет. В моем инструменте нет текста. Есть то, что я называю ART. В каждый момент времени вы видите только то, что может поместиться в вашу оперативную память.

    Reply
  63. adwas777

    (64)

    А вот это: Подбор(Заказ), Цена = Цена*1.1 и т.п. — это не текст?

    Reply
  64. mkalimulin

    (65) Нет, конечно. На картинке вверху два прямоугольника, внизу таблица свойств )))

    Если серьезно, текстом надо называть все, что разбито на строки и количество строк превышает верхний предел оперативной памяти человека.

    Reply
  65. btr

    (66) Да, метафора текста не в том, что в отдельных блоках есть текст, а в том, что сам алгоритм представлен текстом.

    Бесконечная лента уже не совсем лента — конвейеры, треды, параллельное исполнение.

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

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

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

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

    Reply
  66. mkalimulin

    Dementor в посте 11 совершенно справедливо заметил, что разделить документ на две части — это слишком просто. Он предложил свой вариант задачи. Мне она не показалась сложной. Тем не менее, я нашел время ее решить. Получилось пять элементов. Два на верхнем уровне, и еще три вложенных во второй.

    Все бы ничего. Но тут с мисты от Garikk прилетела такая задача, которую я не могу не процитировать:

    «…ну я полистал

    на элементарных опреациях ок…

    а как начнется типа: выделить из документа те элементы которые закупались в периоде с 1 марта по 25 апреля от ООО ромашки, и оприходованы на склад 1 и в прошлом году в этом периоде остаток на складе был на 15% выше чем на месяц раньше два года назад

    Вы упаритесь квадратики рисовать и ВРУЧНУЮ УСЛОВИЯ ТЕКСТОМ ПИСАТЬ»

    Надо сказать, что я даже засомневался: а может это и вправду будет уже громоздко. Конечно, сел, решил. Снова получилось пять элементов. Видимо, пять — это волшебное число )))

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

    Я обновил файл приложения и включил в него эти два примера.

    Reply
  67. mkalimulin

    Пока кто-то сомневается (см. мой предыдущий пост), trustasia решил прямо сейчас использовать ART в своем проекте. Ему нужна связь через COM, поэтому ближайщий update будет посвящен этому вопросу. COM будет точно. ADO и HTTP возможно в этот раз или в следующий.

    Со своей стороны, я также определился с «серьезным» проектом на ART. Это будет декларация по налогу на добавленную стоимость. Следите за новостями здесь и в телеграмм-канале artvirtue.

    Reply
  68. o.nikolaev

    Своеобразно. Но, когда осуществляется стратегия «пусть расцветают все цветы и соревнуются тысячи школ мысли», это добрый знак. Стало быть, язык и среда — живы, коль скоро позволяют взвести подобные ништяки.

    Reply
  69. mkalimulin

    (70) Спасибо за отзыв!

    Reply
  70. mkalimulin

    Теперь ART можно использовать как «табло».

    Reply
  71. Pr-Mex

    (0)

    Чем-то мне это Gherkin напомнило.

    Reply
  72. mkalimulin

    (73) Эээ… Мой посыл прямо противоположен.

    Gherkin — это древняя идея. Ее смысл — «а давайте будем программировать на естественном языке».

    Моя идея — «где язык и где программирование?» Долой текст из программирования, а вместе с текстом и язык. Программирование по своей природе примитивнее языка и в языке не нуждается.

    Reply
  73. informa1555

    Очень интересно! Я как раз развиваю проект-конструктор мобильных клиентов https://infostart.ru/public/976636/ и по структуре эта штука идеально вписывается. У меня сейчас обработчики на обычном языке, но ведь можно использовать этот язык Art как альтернативу…

    Reply
  74. mkalimulin

    (75) Спасибо за отзыв. Добавил вашу разработку в избранное. Посмотрю ее внимательно чуть позже.

    Reply
  75. Артано

    Автору моё почтение. Критикам — вы просто не понимаете, что такое программирование. Это начинаешь понимать, когда занимаешься обучением или контролем.

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

    Подобная платформа, позволит дать знания о теории алгоритмов незамутненному детскому мозгу еще не извращенному каким-либо синтаксисом какого-либо языка. Либо, я надеюсь, расшевелить мозги уже испорченные, но еще не одеревеневшие. Это программирование в чистом виде и этим ценно.

    Reply
  76. mkalimulin

    (77) Спасибо за душевный отзыв! Рад, что вам понравилось.

    Reply
  77. zekrus

    Доброе утро!

    Тема весьма актуальная:



    Ничего не напоминает?

    П.С.:

    — Очень скоро профессия «Программист» уйдет в далекое прошлое как динозавры

    (любой ребенок будет способен зайти на ресурс подобный yandex и голосом описать задание на компиляцию ПО).

    Ох, хорошо что у меня есть первое образование механика (будем перепрофилироваться, тфу тфу тфу)…

    С уважением

    Reply
  78. mkalimulin

    (79) Доброе утро!

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

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

    Reply
  79. kalyaka

    (18) наверное вы имели в виду не язык, а текст — не самое адекватное представление программы. Согласен, программа — это не текст, однако текст это одно из возможных представлений программы и наиболее распространенное.

    Т.о. (6) ART — это декларативный язык с функциональной парадигмой.

    Декларативный — потому что в нем задается что нужно сделать, без указания последовательности. Внутренняя реализация инструмента сама решит как лучше выполнить программу. Хотя впрочем последовательность неявно задана — она определяется зависимостью по входу в виде структуры, но если сделать независимые блоки, то последовательности не будет.

    Функциональный — потому что здесь описываются функции с входными и выходными переменными.

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

    Reply
  80. kalyaka

    (74) Язык это знаковая система, посредством которой мы передаем информацию или пишем программу. У вас это знаки A R T. Просто у вас язык совпадает со структурой программы, т.е. при интерпретации языка ничего делать не надо (сразу готово абстрактное синтаксическое дерево исполнения), т.е. сразу можно передавать на исполнение.

    Reply
  81. mkalimulin

    (81) Язык линеен (или почти всегда линеен), поэтому я и ставлю знак равенства между языком и текстом.

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

    Функциональная парадигма — это, все-таки, немного другое. Если бы у меня переменные принимали значение типа «функция», тогда можно было бы о ней говорить.

    На мой взгляд, функциональная парадигма всего лишь чуть лучше традиционного текста. Это — попытка вырваться из объятий метафоры бесконечной ленты. Прыгнуть от Тьюринга к Чёрчу. Она лишний раз доказывает, что проблема неадекватности текста существует и требует какого-то решения. Но решение, как мне кажется, не удачно. Будь оно удачно — мы бы уже все занимались функциональным программированием.

    Reply
  82. mkalimulin

    (82) Для языка важен момент общения. Нет общения — нет языка. Когда мы пишем программу, мы ни с кем не общаемся.

    Reply
  83. kalyaka

    (84) формальные языки были разработаны для однознаной интерпретации и, в отличие от человеческих, они не предназначены для коммуникации.

    Reply
  84. mkalimulin

    (85) Поэтому и не стоит называть это языками. Отсюда идет путаница. Язык, коммуникация, общение — все это линейно. Алгоритм — нет.

    Reply
  85. acanta

    Программа это завещание или последняя воля. Если у программиста ничего нет, зачем её писать? Если у программиста есть все, он пишет что со всем этим надо делать. Например Альфред Нобель основал Нобелевскую премию для всех, кроме математиков, потому что ревновал жену. Это достаточно простой алгоритм.

    Reply
  86. kalyaka

    (83)

    Язык линеен

    линейность зависит от ширины канала восприятия.

    язык сложен, а программа проста

    Язык сложен своей семантикой, а программа проста на определенном уровне абстракции. Простая семантика — простой язык, например как встроенный язык 1С

    Главное препятствие мешающее людям освоить программирование — неадекватность выразительного средства

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

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

    Если бы у меня переменные принимали значение типа «функция»

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

    функциональная парадигма… Но решение, как мне кажется, не удачно

    У функционального подхода очень высокий уровень абстракции, который требует особого склада мышления, ему нужно учиться. У него есть преимущества и есть недостатки. Главное преимущество — математическая надежность программ, недостаток — требование отсутствия побочных эффектов, когда большинство пользовательских задач созданы ради этих эффектов.

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

    Будь оно удачно — мы бы уже все занимались функциональным программированием

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

    Reply
  87. kalyaka

    (64)

    В моем инструменте нет текста

    А как же классика:

    «Лучшим форматом для постоянного хранения знания является простой текст, позволяющий обрабатывать информацию как вручную, так и с помощью любых доступных инструментов. Проблема большинства двоичных форматов состоит в том, что контекст, необходимый для понимания данных, отделен от самих данных. А с помощью простого текста, доступного для чтения без дешифровки, вы можете создать самодокументированный поток данных, не зависящий от программы, которая его породила.» Программист-прагматик. Эндрю Хант, Дэвид Томас ?

    Reply
  88. mkalimulin

    У программиста есть воля. Для создания программы больше ничего не требуется.

    Reply
  89. acanta

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

    Reply
  90. mkalimulin

    (91) Не понял — к чему относится этот комментарий?

    Reply
  91. mkalimulin

    (89) А никак. Нас тут формат хранения знания не интересует. Нас интересует инструмент программирования.

    Reply
  92. mkalimulin

    (88) Выходом из положения является адекватный инструмент. Отказ от текста дает ту самую лекгость, без которой нет массового использования.

    Reply
  93. kalyaka

    (94) текст хорош тем, что не требует инструмента. Можно программировать где угодно, откуда угодно. Можно пользоваться GIT.

    Недостаток текста в том, что в нем сложно добавлять много семантики — текст становится перегруженным. Отсюда все эти пляски с значками =, ==, ===, !=, +=, ++ и т.д. И здесь как раз инструмент поддержки текста очень помогает (см. IDE от JetBrains).

    Попытки уйти от текста как представления программы есть, это тотже UML, оркестровки, диаграммы трансформации. UML не смог заменить текст, т.к. в его задачу не входит 100% описание программы, а лишь показать модель с определенной точки зрения. Оркестровки, диаграммы, построители SQL — да, но это все таки DSL.

    Reply
  94. mkalimulin

    (95) Гвоздь лучше самореза тем, что не требует инструмента. Его можно любым тяжелым предметом забить. Топор лучше бензопилы тем, что не требует бензина. А веревка лучше электросварки тем, что не требует дорогостоящего аппарата, а две железяки может вполне надежно соединить. Надо только соответствующие узлы вязать научиться.

    В чем проблема воспользоваться инструментом? Религия не позволяет?

    Если вы будете программировать с помощью текста, тогда вам не потребуется инструмент.

    А если вы воспользуетесь инструментом, тогда вам не придется извращаться и представлять алгоритмы в неестесственном виде.

    Reply
  95. acanta

    (96) вы правы, для программирования сегодня достаточно пальцем ткнуть . За вашей идеей большое будущее.

    Reply
  96. altar

    Не нашел, где взять?

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

    Reply
  97. mkalimulin

    (98) Добрый день. Не нашли что?

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *