В этом языке всего два основных элемента: элемент 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 элемент. Разобраться намного проще, чем в типовой тысяче (на самом деле еще больше) строк, разбросанной по разным модулям.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Прикольно 🙂
интересно , + за идею
Декларативное программирование на базе ООП?
(1) Мне тоже. Спасибо!
(2) Спасибо за отзыв!
(3) Да, вроде, не похоже на декларативное. Есть состояния и переменные. Вполне себе императивное.
(5) только непонятно нифига ))
что такое r и a
(7)
R — repeat, цикл
A — assembling, группа
Все элементы могут быть вложены друг в друга, и таким образом, образуют иерархию.
Но элемент R, в отличие от A, в момент трэкинга превращается во множество.
Автор, вот еще источник идей.
(9) тоже вспомнил и про скретч и про его предшественника ЛОГО.
(0) разделение документа на 2 это мало интересно. Предположим у нас есть какие-то управленческие документы с описанием затрат в разрезе статей затрат. Раньше все можно было писать в один документ, что обычно и делали. Но руководство приняло решение — каждый вид затрат писать в отдельный документ и разграничить доступ по статьям затрат (не ищите логику — пример из пальца). У нас документ может остаться нетронутым, может разделится на два, три… десять… сто… Количество гипотетических разделений зависит от размера справочника статей затрат, который наполняется в реальном времени. Сможет ли АРТ справится с таким вызовом? 🙂
(9) Спасибо. Я, конечно, знаю и Блокли и Скретч. Когда я преподавал программирование детям, я их часто использовал.
Но могу сказать, что эта идея не получила дальнейшего развития (Скретч создан 11 лет назад, Блокли 6).
На мой взгляд, это произошло потому, что авторы так и не смогли уйти от представления программы, как текста.
Т.е. они нам предлагают набор забавных блоков, но в результате, по их представлениям, должен получиться все равно ТЕКСТ ПРОГРАММЫ. А программа — не текст.
(11) Ну разумеется. ART — Тьюринг-полный инструмент.
(11) Кстати, выглядеть это будет проще, чем вам кажется. Если внимательно посмотрите на пример 3, вы найдете решение этой задачи.
Интересно, но слишком абстрактно, на мой взгляд. Gherkin и ему подобные в этом отношении выглядят более перспективно.
(15) Gherkin — это язык. ART — не язык. ART — инструмент программирования, показывающий, что можно программировать без языка.
Да, и разве мои примеры абстрактны? А что тогда конкретно?
(16) А зачем без языка программировать? И, конкретно, интерфейс на ART нарисовать можно?
(17) Затем, что язык — не самое адекватное средство для представления программы. Инструментов для рисования интерфейса и так слишком много.
(19) Почему?
(20) Перестаньте кормить местного тролля, там бесполезно задавать вопросы, надеясь на вразумительный ответ, он во всех умных темах пытается поучаствовать.
(21) Положение автора обязывает отвечать на все вопросы и а также задавать вопросы для прояснения позиции комментатора. Разумеется, в рамках темы.
(20) Что упрощает ваш инструмент? В чём преимущества его использования? Для кого он?
(23) Посмотрите на пост (11). Автор поста обозначил задачу, которую он считает сложной, называет ее вызовом.
Когда он поймет, что решение этой задачи в ART состоит из трех блоков вложенных в еще один (всего четыре блока), возможно, он захочет пользоваться таким инструментом.
ART упрощает процесс программирования. И предназначен для всех, кому так или иначе приходится этим процессом заниматься.
Но в чем-то я с вами согласен. Надо будет добавить не просто пример, а что-нибудь имеющее практическую ценность. Я подумаю.
(25) Преимущества вашего инструмента не очевидны из статьи, нужны сравнительные примеры.
Вообще, не имея доступ к конфигуратору, если навскидку бы прилетели такие задачи — я бы запустил базу в толстом клиенте и воспользовался Инструментами Разработчика. Но это навскидку. Выглядит все очень интересно, но непривычно, сходу не могу начать думать на предложенных конструкциях. Но попробую обязательно, спасибо, очень любопытно.
(27) Спасибо за отзыв! Я исходил из того, что инструмент должен обладать Тьюринговой полнотой. Т.е. решать в принципе любые задачи. Представьте что вам надо разово сделать то, что описано в примере 3. Сравните — что бы вам пришлось слелать в Инструментах разработчика и что делается в ART.
(26) У меня есть соображения насчет этого. Но потребуется некоторое время. Следите за темой.
(29) Хорошо, поставил плюс 🙂
Я хотел бы с Вами связаться по Вашим работам в этом направлении. Есть созвучная идея, которую я один наверное не потяну. Ознакомившись с этим материалом, понял, чего мне не хватало — действительно, текстовость языка лишний груз. Просьба связаться в личной переписке.
1C когда-то создавалась для того, чтобы бухгалтеры, не зная программирования, могли быстро и интуитивно «подправить» программу 🙂 А потом всё заверте…
Что касается предмета статьи — так и не понял, зачем это изобретение? Если просто абстрактно, то ок. А применять это… Ну справа, в значениях, например, уже есть какие-то конструкции из программирования, операторы, имена реквизитов и объектов конфигурации и т.п. Т.е. программировать без языка уже не получится, надо как минимум иметь какие-то основы, лезть в конфигуратор за метаданными и т.п.
То, что это — Тьюринг-полный инструмент, конечно, прекрасно. Но любой язык программирования — тоже, в том числе 1С.
Чтобы начать это использовать, нужны какие-то преимущества (даже, наверное, серьёзные) перед остальными инструментами. Какой порог вхождения в это знание? Как долго нужно обучаться работе? Насколько сократится время на разработку? Судя по длине статьи — как минимум обучаться нужно, ничего интуитивного там нет, а время на разработку — пока что кажется, что кодом как минимум не дольше. И в результате возвращаемся к первому вопросу — а зачем?
Интересно. Как встроить вызов вашего языка в 1С? Например, в обработку проведения.
(33) Кстати, да. Хорошая идея — добавить программный интерфейс. Спасибо.
(34) И генератор кода 1С :). Чтобы не тратить время на обработку схемы. А еще обратное преобразование из 1С кода в схему :). Красотень.
(35) Тогда придется отдел разработки 1С брать на подряд ))
Но, конечно, преобразователь — тема серьезная. А то тут все спрашивают: а чем это лучше? Действительно, дал людям преобразователь. Они преобразовали «простынку» кода в три-четыре блока. И больше вопросов не задают.
Надо подумать.
(36)Ну не сразу, задача сложная. Можно разбить на этапы. 1. программный интерфейс,2. генератор кода и т.д. Поместите в github — поможем.
(36) я около года назад занимался чем то подобным см. рис.
правда идея была не в том , чтобы уйти от кода совсем , а в том , чтобы декомпозировать его на примитивные блоки , передав логику управления на более абстрактный уровень
В принципе вашу систему тоже можно рассматривать как некий случай КА с «неявным» выделением состояний. Ну.. мне так кажется на первый взгляд.
правда потом столкнулся с рядом проблем и (примерно на год ) заб
иыл про это дело , и вот недавно (кое что переосмыслив) вновь вернулся теместранное дело (я про это уже неоднократно высказывался) , сходные (по смыслу ) решения появляются у разных людей примерно в одном промежутке времени. Тут поневоле начинаешь задумываться о «коллективном разуме» ))
(36)Продолжу надоедать вопросами. Как дела обстоят с запросами? Работа с табличными документами? Можно ли вызывать методы из других схем? Ну и вишенка, рекурсия поддерживается? 🙂
(27) Интересно было бы — взглянуть на 1,2 фичи — аля ИР.
Напомнило
а какой-нибудь рег.отчет/общий модуль с тысячей методов можно посмотреть на ARTe как будет смотреться?
В обучении, в описании алгоритмов такие языки может быть… Но в прикладной, практической разработке в мире 1С не представляю их.
Описывать какой-то автомат, сервис — может быть. А написать учетную систему? Тут чаще гибкость, чем абстрактность нужна…
а плюсану-ка
Лет через 20 может на код 1С будт смотреть как на
(36)
а пример преобразованной простынки можно?
Я вот тоже не понимаю, чем это лучше и как можно с помощью этого получить повышение производительности и упрощение работы?
Кстати, оба фактора важны. Есть такой язык — ифкуиль. Типа как архиватор языка. Можно выражать длинные мысли несколькими звуками. Вроде как повышает производительность мыслительного процесса и речи. Но из-за очень большой сложности всё равно не нашёл распространения.
(35)
А там и до написания своего языка для общения с 1С недалеко:) И будет 1С внутри 1С! Да и кто вообще может гарантировать, что мы все не находимся внутри какого-то 1С верхнего уровня? :))
(32) Хорошо, что вы вспомнили про бухгалтеров.
Да, я рассчитываю на то, что инструментом будут пользоваться все. И бухгалтеры тоже.
Я исхожу из следующего. Для того, чтобы получить настоящую пользу от ИТ-технологий, необходимо программировать.
Но программирование до сих пор еще не пошло в массы. И причина этому в том, что то программирование, которое практикуется сейчас — настоящее извращение. А люди в большинстве своем предпочитают естественное. ART — это инструмент для программирования естественным способом.
Возможно, вас сбивает с толку простота инструмента. В моих трех примерах содержится практически полное описание инструмента. В нем больше ничего нет. И больше ничего и не надо для ведения учета.
Насчет залезания в Конфигуратор. Я хотел сделать браузер объектов (как в конструкторе запросов), но потом отложил это на более поздние версии.
В любом случае, спасибо вам за отзыв. Вы мне напомнили о том, что описание все-таки следует добавить.
(39) Внутри запросы, конечно же используются. На уровне инструмента никакие особые конструкции не нужны. Есть элемент-итератор, у него задан источник. Вот собственно и все. Вывод в табличный документ не считаю нужным поддерживать. Это — пережиток докомпьютерных технологий. Использовать табличный документ (в различных форматах) как источник — это другое дело. Можно и реализовать для совместимости. Но это не самое первое дело.
Я планирую расширять понятие источника. В представленной сейчас версии источником может быть база 1С и переменные среды выполнения. Но в принципе,это может быть и не 1С-овская база данных, может быть результат HTTP-запроса, может быть таблица Excel (вот здесь, да, появится табличный документ).
По поводу повторного использования одного и того же у меня есть определенные соображения. Но они пока еще «сырые» и не вошли в стартовую версию.
Любая рекурсия может быть представлена в виде цикла. Пока остановился на этом. Я думал над тем, как поизящнее реализовать обход источника с произвольным количеством уровней. Найденные варианты мне не нравятся.
(46) Спасибо за развернутый ответ
(41) Этому Дракону больше четверти века. Его проблема в том, что блок-схема — это тоже текст. Чтобы инструмент стал действительно «Д»-дружественным, надо уйти от текста.
(42) После того, как мне уже сказали: «дайте что-нибудь конкретное», я как раз в сторону налоговых деклараций и смотрю. Потребуется немного времени. Следите за темой.
(43) Производительность можно обеспечить только если реализовывать ART на уровне платформы. Но, как показывает опыт, выразительность важнее производительности. Алгол тоже проигрывал в производительности автокоду.
(38) Я так понимаю, что просто пришло время программированию уйти в массы. Вы можете свободно использовать любые идеи или куски кода из этой публикации. Я буду рад,если это поможет вам продвинуться.
Интересно. С таким инструментарием программировать ну, скажем… на мобильном устройстве будет гораздо удобнее, чем традиционно набирать текст. Ну и в учебных целях, опять же. Это гораздо лучше, чем рисовать «мертвые» блок-схемы в тетрадке.
(52) Безусловно. Когда программирование пойдет в массы, люди в основном и будут программировать на смартфонах.
А блок-схемы, как я уже говорил, это — те же тексты.
Любопытная идея программирования. Лично мне было бы интересно видеть нечто подобное в 1С: Предприятие 9 — на самом высоком уровне абстракции (а я хотел бы надеяться что в 9-ке всё-таки произойдёт разделение разработки по уровням абстракции) — а наивысший уровень — это уровень программирования логики бизнес-процессов, аналитических инструментов и простых обработок данных — естественно без применения императивного программирования (хотя некоторые декларатативные высокоуровневые скрипты возможны). Но на этом уровне, работа должна вестись с блоками архитектуры и кода, которые будут созданы на более низком уровне абстракции. А инструменты работы с этими блоками должны быть похожи на описанные здесь подходы.
А вот ART сейчас не хватает пяти вещей:
1. Библиотек повторного использования
2. Обобщённых шаблонов недетерменированных алгоритмов — детерменируемых по ходу применения через принципы, замены суперпозиции и карирования
3. Готовых универсальных настраиваемых паттернов проектирования
4. Расширения (наследования с полиморфизмом) — для создания новых операций на основе имеющихся с их частичным видоизменением
5. Встроенных операций ввода/вывода — как для ввода входных данных (как интеррактивному, так и из произвольных источников), так и для преобразования результата к нужному формату
очень интересно, попробую
Чего мне обычно не хватает как разработчику — это структуризации текста, с одной стороны (чтобы размечать конструкции, сворачивать их и разворачивать) и визуальный контроль контекста (т.е. какие объекты, структуры, переменные доступны в текущей конструкции, в модуле, в экспортных модулях, в подключенных API) — это два разных инструмента и их можно реализовать раздельно.
Но метафора текста очень глубоко сидит в умах разработчиков. Чтобы ее победить, нужна новая, очень сильная метафора. Одним структурированием здесь не обойтись. В конечном счете разные ассистенты при работе с текстом — тоже способ повышения производительности.
Я давно не слежу за широким спектром средств разработки, но даже идеи 20-летней давности все еще не реализованы.
Конечно, средства уровня игры — это несерьезно. Только способ представить концепцию.
Нужно серьезное промышленное средство визуального проектирования кода. А тут еще постепенно подпирают новые парадигмы. Нейросети, квантовые алгоритмы.
Может быть попробую на новогодних каникулах написать статью по нескольким серьезным парадигмам визуального проектирования кода, которые пока толком не рассматривались широким сообществом и не выходили за пределы очень небольших исследовательских групп.
Ведь даже идею структурирования текстового кода не так просто во всех аспектах изложить, а уж идею визуализации контекста для каждого конкретного места в программе — вообще нужно начинать с нуля, поскольку подходящих метафор и вовсе нет (только в общих чертах идеи манифестов и оркестровки, разве что)
(54) А можете привести какие-нибудь примеры ИСР, где бы поддерживались хотя бы плохо и коряво уровни абстракции?
Что касается Вашего пункта 5, то это не только ввод-вывод, это всевозможные протоколы и интерфейсы взаимодействия и управления. Тоже не встречал толково реализованного подхода к обобщению этой задачи, все в конечном итоге реализуется самостоятельными моделями, вроде MVVM или более древних MVP, MVC, MVCP и прочих.
Я бы еще добавил идею архитектурного ландшафта системы (т.е. определение архитектуры и разработку, как декомпозицию блоков и связей).
так или иначе, собственно текст программ остался и в вашем инструменте, верно?
то есть, это — при всей её оригинальности — красивая обёртка, чтобы не писать циклы,
а так, как по мне, если серьёзный алгоритм какой, то по сути облегчения понимания или визуального представления не видно.
возможно, в этом смысле всё же лучше вести в сторону ФП?
(16) Хитро придумано, и захотелось попробовать. Времени нет, как всегда, …
Но от раскрытия темы аж вздрогнул…
так напомнило
(Котеров Д. В., Костарев А. Ф. — PHP 5. 2-е издание (В подлиннике) — 2008)
(57) В пункте 2 я в первую очередь думал об идеи шаблонов языка С++, и о функциональных языках.
В 5-том пункте об интерфейсах думал только о средстве ввода и вывода данных. А не об архитектуре взаимодействия человек-данные
(54) С 1 и 3 согласен. И даже одно время хотел включить в стартовую версию.
Насчет 2 и 4 есть опасения, что пропадет простота инструмента.
По п.5 готов спорить. Встроенная операция ввода есть. Указываете источник для итератора — вот вам и ввод. Можно и нужно расширять понятие источника, включая, например: произвольные БД, HTTP-запросы, табличные документы.
Выходные же форматы, как мне кажется, не стоят усилий. Есть формат ART, в нем заложена органичная связь между дизайном и результатом.
(55) Спасибо за отзыв.
(56) Сначала была метафора бесконечной ленты. Потом доказательство, что любая программа может быть представлена в виде текста. Так и пошло-поехало. В сущности, на чем бы вы сейчас ни писали, вы пишите на слегка улучшенном брейнфаке.
(58) Нет. В моем инструменте нет текста. Есть то, что я называю ART. В каждый момент времени вы видите только то, что может поместиться в вашу оперативную память.
(64)
А вот это: Подбор(Заказ), Цена = Цена*1.1 и т.п. — это не текст?
(65) Нет, конечно. На картинке вверху два прямоугольника, внизу таблица свойств )))
Если серьезно, текстом надо называть все, что разбито на строки и количество строк превышает верхний предел оперативной памяти человека.
(66) Да, метафора текста не в том, что в отдельных блоках есть текст, а в том, что сам алгоритм представлен текстом.
Бесконечная лента уже не совсем лента — конвейеры, треды, параллельное исполнение.
А вот проектирование этого самого кода — все еще на основе текста. Лонгриды.
Поэтому, мне кажется наиболее уместным на верхнем уровне представления — архитектурный ландшафт системы. Но пока эта метафора не вполне интуитивна. Это что-то вроде доков в порту, например. Было бы лучше сказать про космопорт, этакое 3d. А в случае наличия в системе разных GPU или других массивов параллельной обработки, так и 4d не лишним будет 🙂 Но это уже на правах тухленького юмора.
Я и сам пока ищу хорошие метафоры для современных средств разработки.
Идея ART будет понятнее, когда пройдет испытания масштабным проектом. Будем присматриваться, следить за новостями.
Dementor в посте 11 совершенно справедливо заметил, что разделить документ на две части — это слишком просто. Он предложил свой вариант задачи. Мне она не показалась сложной. Тем не менее, я нашел время ее решить. Получилось пять элементов. Два на верхнем уровне, и еще три вложенных во второй.
Все бы ничего. Но тут с мисты от Garikk прилетела такая задача, которую я не могу не процитировать:
«…ну я полистал
на элементарных опреациях ок…
а как начнется типа: выделить из документа те элементы которые закупались в периоде с 1 марта по 25 апреля от ООО ромашки, и оприходованы на склад 1 и в прошлом году в этом периоде остаток на складе был на 15% выше чем на месяц раньше два года назад
Вы упаритесь квадратики рисовать и ВРУЧНУЮ УСЛОВИЯ ТЕКСТОМ ПИСАТЬ»
Надо сказать, что я даже засомневался: а может это и вправду будет уже громоздко. Конечно, сел, решил. Снова получилось пять элементов. Видимо, пять — это волшебное число )))
А если серьезно, ART устроен так, что всякая задача естественным для него образом отображается в такую структуру, что у вас перед глазами почти всегда будет два-три элемента. Обе задачи, о которых я только что говорил, имеют решение, где два элемента располагаются на первом уровне и еще три на втором.
Я обновил файл приложения и включил в него эти два примера.
Пока кто-то сомневается (см. мой предыдущий пост), trustasia решил прямо сейчас использовать ART в своем проекте. Ему нужна связь через COM, поэтому ближайщий update будет посвящен этому вопросу. COM будет точно. ADO и HTTP возможно в этот раз или в следующий.
Со своей стороны, я также определился с «серьезным» проектом на ART. Это будет декларация по налогу на добавленную стоимость. Следите за новостями здесь и в телеграмм-канале artvirtue.
Своеобразно. Но, когда осуществляется стратегия «пусть расцветают все цветы и соревнуются тысячи школ мысли», это добрый знак. Стало быть, язык и среда — живы, коль скоро позволяют взвести подобные ништяки.
(70) Спасибо за отзыв!
Теперь ART можно использовать как «табло».
(0)
Чем-то мне это Gherkin напомнило.
(73) Эээ… Мой посыл прямо противоположен.
Gherkin — это древняя идея. Ее смысл — «а давайте будем программировать на естественном языке».
Моя идея — «где язык и где программирование?» Долой текст из программирования, а вместе с текстом и язык. Программирование по своей природе примитивнее языка и в языке не нуждается.
Очень интересно! Я как раз развиваю проект-конструктор мобильных клиентов и по структуре эта штука идеально вписывается. У меня сейчас обработчики на обычном языке, но ведь можно использовать этот язык Art как альтернативу…
(75) Спасибо за отзыв. Добавил вашу разработку в избранное. Посмотрю ее внимательно чуть позже.
Автору моё почтение. Критикам — вы просто не понимаете, что такое программирование. Это начинаешь понимать, когда занимаешься обучением или контролем.
Потому что подавляющее большинство сегодняшних, якобы программистов, могут писать код, но не могут программировать.
Подобная платформа, позволит дать знания о теории алгоритмов незамутненному детскому мозгу еще не извращенному каким-либо синтаксисом какого-либо языка. Либо, я надеюсь, расшевелить мозги уже испорченные, но еще не одеревеневшие. Это программирование в чистом виде и этим ценно.
(77) Спасибо за душевный отзыв! Рад, что вам понравилось.
Доброе утро!
Тема весьма актуальная:
Ничего не напоминает?
П.С.:
— Очень скоро профессия «Программист» уйдет в далекое прошлое как динозавры
(любой ребенок будет способен зайти на ресурс подобный yandex и голосом описать задание на компиляцию ПО).
Ох, хорошо что у меня есть первое образование механика (будем перепрофилироваться, тфу тфу тфу)…
С уважением
(79) Доброе утро!
В этой картинке нет ничего особенного. Вам может показаться странным, но это тоже текст, и вполне себе традиционный подход к программированию. Так что — с этой стороны вам ничего не угрожает.
Использовать вместо текста арт — это другое дело. Это действительно приведет к тому, что программировать будут все. Но и здесь не стоит беспокоиться. Обратите внимание на то, что с повсеместным распространением грамотности профессия писателя вовсе не исчезла. Более того. Только с появлением большого количества читателей, она приобрела свое настоящее значение. Тоже будет и с программированием. Настоящий потенциал этой профессии пока еще не раскрыт.
(18) наверное вы имели в виду не язык, а текст — не самое адекватное представление программы. Согласен, программа — это не текст, однако текст это одно из возможных представлений программы и наиболее распространенное.
Т.о. (6) ART — это декларативный язык с функциональной парадигмой.
Декларативный — потому что в нем задается что нужно сделать, без указания последовательности. Внутренняя реализация инструмента сама решит как лучше выполнить программу. Хотя впрочем последовательность неявно задана — она определяется зависимостью по входу в виде структуры, но если сделать независимые блоки, то последовательности не будет.
Функциональный — потому что здесь описываются функции с входными и выходными переменными.
Функциональный подход бладает достаточно высоким уровнем абстракции и менее доступен для понимания большинства, чем императиыный. Так что кажущаяся простота инструмента не означает простоту написания программ для не профессионалов.
(74) Язык это знаковая система, посредством которой мы передаем информацию или пишем программу. У вас это знаки A R T. Просто у вас язык совпадает со структурой программы, т.е. при интерпретации языка ничего делать не надо (сразу готово абстрактное синтаксическое дерево исполнения), т.е. сразу можно передавать на исполнение.
(81) Язык линеен (или почти всегда линеен), поэтому я и ставлю знак равенства между языком и текстом.
Второй момент — язык сложен, а программа проста. Главное препятствие мешающее людям освоить программирование — неадекватность выразительного средства.
Функциональная парадигма — это, все-таки, немного другое. Если бы у меня переменные принимали значение типа «функция», тогда можно было бы о ней говорить.
На мой взгляд, функциональная парадигма всего лишь чуть лучше традиционного текста. Это — попытка вырваться из объятий метафоры бесконечной ленты. Прыгнуть от Тьюринга к Чёрчу. Она лишний раз доказывает, что проблема неадекватности текста существует и требует какого-то решения. Но решение, как мне кажется, не удачно. Будь оно удачно — мы бы уже все занимались функциональным программированием.
(82) Для языка важен момент общения. Нет общения — нет языка. Когда мы пишем программу, мы ни с кем не общаемся.
(84) формальные языки были разработаны для однознаной интерпретации и, в отличие от человеческих, они не предназначены для коммуникации.
(85) Поэтому и не стоит называть это языками. Отсюда идет путаница. Язык, коммуникация, общение — все это линейно. Алгоритм — нет.
Программа это завещание или последняя воля. Если у программиста ничего нет, зачем её писать? Если у программиста есть все, он пишет что со всем этим надо делать. Например Альфред Нобель основал Нобелевскую премию для всех, кроме математиков, потому что ревновал жену. Это достаточно простой алгоритм.
(83)
линейность зависит от ширины канала восприятия.
Язык сложен своей семантикой, а программа проста на определенном уровне абстракции. Простая семантика — простой язык, например как встроенный язык 1С
На мой взгляд главное препятствие — необходимость этому учиться, так же как необходимость учиться математическому мышлению или логике. Еще одно препятствие — это большое количество как самих языков и инструментов, так и изменений в них. Третье — сложность, как неотъемлемая характеристика программирования, моделирующего задачи действительности.
Выходом из положения являются специализированные языки DSL. Их семантика соответствует предметной области и предполагается, что владение предметной областью должно быть достаточным, чтобы программировать алгоритмы под ее задачи. Т.е. должна быть обеспечена адекватность языка предметной области.
Мне кажется вы могли бы докрутить свой инструмент для этого 🙂 Ведь возможность переиспользования — это одна из главных возможностей программирования, уменьшающей трудозатраты и способствующей лучшему качеству программ.
У функционального подхода очень высокий уровень абстракции, который требует особого склада мышления, ему нужно учиться. У него есть преимущества и есть недостатки. Главное преимущество — математическая надежность программ, недостаток — требование отсутствия побочных эффектов, когда большинство пользовательских задач созданы ради этих эффектов.
В общем то как раз по той причине, что не найдено единой формулы универсального языка, нет и самого такого универсального языка. Вместо этого есть много языков и количество их продолжает увеличиваться, каждый из который наилучшим образом решает задачи только своей области.
Тренд уже есть, все большее количество языков начинает поддерживать функциональную парадигму. Даже скриптовый язык браузера JS ее поддерживает и я уже не могу представить программирование на нем без функционального стиля.
(64)
А как же классика:
«Лучшим форматом для постоянного хранения знания является простой текст, позволяющий обрабатывать информацию как вручную, так и с помощью любых доступных инструментов. Проблема большинства двоичных форматов состоит в том, что контекст, необходимый для понимания данных, отделен от самих данных. А с помощью простого текста, доступного для чтения без дешифровки, вы можете создать самодокументированный поток данных, не зависящий от программы, которая его породила.» Программист-прагматик. Эндрю Хант, Дэвид Томас ?
У программиста есть воля. Для создания программы больше ничего не требуется.
Получается, что любая тех поддержка это зло и в общем случае она не нужна, если работа с программой приносит ожидаемый доход пользователям и не противоречит каким-то правилам.
(91) Не понял — к чему относится этот комментарий?
(89) А никак. Нас тут формат хранения знания не интересует. Нас интересует инструмент программирования.
(88) Выходом из положения является адекватный инструмент. Отказ от текста дает ту самую лекгость, без которой нет массового использования.
(94) текст хорош тем, что не требует инструмента. Можно программировать где угодно, откуда угодно. Можно пользоваться GIT.
Недостаток текста в том, что в нем сложно добавлять много семантики — текст становится перегруженным. Отсюда все эти пляски с значками =, ==, ===, !=, +=, ++ и т.д. И здесь как раз инструмент поддержки текста очень помогает (см. IDE от JetBrains).
Попытки уйти от текста как представления программы есть, это тотже UML, оркестровки, диаграммы трансформации. UML не смог заменить текст, т.к. в его задачу не входит 100% описание программы, а лишь показать модель с определенной точки зрения. Оркестровки, диаграммы, построители SQL — да, но это все таки DSL.
(95) Гвоздь лучше самореза тем, что не требует инструмента. Его можно любым тяжелым предметом забить. Топор лучше бензопилы тем, что не требует бензина. А веревка лучше электросварки тем, что не требует дорогостоящего аппарата, а две железяки может вполне надежно соединить. Надо только соответствующие узлы вязать научиться.
В чем проблема воспользоваться инструментом? Религия не позволяет?
Если вы будете программировать с помощью текста, тогда вам не потребуется инструмент.
А если вы воспользуетесь инструментом, тогда вам не придется извращаться и представлять алгоритмы в неестесственном виде.
(96) вы правы, для программирования сегодня достаточно пальцем ткнуть . За вашей идеей большое будущее.
Не нашел, где взять?
«В приложении к публикации вы найдете саму обработку, показанные здесь примеры в файлах test1.xml, test2.xml, test3.xml, а также тестовую базу.»
(98) Добрый день. Не нашли что?