0. mkalimulin 308 07.12.18 17:41 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. bulpi 139 07.12.18 19:47 Сейчас в теме
4. mkalimulin 308 07.12.18 21:57 Сейчас в теме
(1) Мне тоже. Спасибо!
dbachinsky; +1 Ответить
2. pm74 134 07.12.18 20:30 Сейчас в теме
5. mkalimulin 308 07.12.18 21:58 Сейчас в теме
7. pm74 134 07.12.18 22:01 Сейчас в теме
(5) только непонятно нифига ))
что такое r и a
Mails79; IgorS; for_sale; +3 Ответить
8. mkalimulin 308 08.12.18 00:40 Сейчас в теме
(7)
R - repeat, цикл
A - assembling, группа
Все элементы могут быть вложены друг в друга, и таким образом, образуют иерархию.
Но элемент R, в отличие от A, в момент трэкинга превращается во множество.
3. PerlAmutor 33 07.12.18 21:48 Сейчас в теме
Декларативное программирование на базе ООП?
6. mkalimulin 308 07.12.18 21:59 Сейчас в теме
(3) Да, вроде, не похоже на декларативное. Есть состояния и переменные. Вполне себе императивное.
9. Steelvan 08.12.18 12:15 Сейчас в теме
10. Dementor 389 08.12.18 12:59 Сейчас в теме
(9) тоже вспомнил и про скретч и про его предшественника ЛОГО.
12. mkalimulin 308 08.12.18 13:21 Сейчас в теме
(9) Спасибо. Я, конечно, знаю и Блокли и Скретч. Когда я преподавал программирование детям, я их часто использовал.
Но могу сказать, что эта идея не получила дальнейшего развития (Скретч создан 11 лет назад, Блокли 6).
На мой взгляд, это произошло потому, что авторы так и не смогли уйти от представления программы, как текста.
Т.е. они нам предлагают набор забавных блоков, но в результате, по их представлениям, должен получиться все равно ТЕКСТ ПРОГРАММЫ. А программа - не текст.
Dementor; +1 Ответить
11. Dementor 389 08.12.18 13:05 Сейчас в теме
(0) разделение документа на 2 это мало интересно. Предположим у нас есть какие-то управленческие документы с описанием затрат в разрезе статей затрат. Раньше все можно было писать в один документ, что обычно и делали. Но руководство приняло решение - каждый вид затрат писать в отдельный документ и разграничить доступ по статьям затрат (не ищите логику - пример из пальца). У нас документ может остаться нетронутым, может разделится на два, три... десять... сто... Количество гипотетических разделений зависит от размера справочника статей затрат, который наполняется в реальном времени. Сможет ли АРТ справится с таким вызовом? :)
13. mkalimulin 308 08.12.18 13:24 Сейчас в теме
(11) Ну разумеется. ART - Тьюринг-полный инструмент.
14. mkalimulin 308 08.12.18 13:30 Сейчас в теме
(11) Кстати, выглядеть это будет проще, чем вам кажется. Если внимательно посмотрите на пример 3, вы найдете решение этой задачи.
68. mkalimulin 308 16.12.18 13:49 Сейчас в теме
Dementor в посте 11 совершенно справедливо заметил, что разделить документ на две части - это слишком просто. Он предложил свой вариант задачи. Мне она не показалась сложной. Тем не менее, я нашел время ее решить. Получилось пять элементов. Два на верхнем уровне, и еще три вложенных во второй.
Все бы ничего. Но тут с мисты от Garikk прилетела такая задача, которую я не могу не процитировать:

"...ну я полистал

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

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

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

Надо сказать, что я даже засомневался: а может это и вправду будет уже громоздко. Конечно, сел, решил. Снова получилось пять элементов. Видимо, пять - это волшебное число )))
А если серьезно, ART устроен так, что всякая задача естественным для него образом отображается в такую структуру, что у вас перед глазами почти всегда будет два-три элемента. Обе задачи, о которых я только что говорил, имеют решение, где два элемента располагаются на первом уровне и еще три на втором.
Я обновил файл приложения и включил в него эти два примера.
Dementor; +1 Ответить
15. genayo 08.12.18 13:51 Сейчас в теме
Интересно, но слишком абстрактно, на мой взгляд. Gherkin и ему подобные в этом отношении выглядят более перспективно.
16. mkalimulin 308 08.12.18 15:01 Сейчас в теме
(15) Gherkin - это язык. ART - не язык. ART - инструмент программирования, показывающий, что можно программировать без языка.
Да, и разве мои примеры абстрактны? А что тогда конкретно?
17. genayo 08.12.18 16:10 Сейчас в теме
(16) А зачем без языка программировать? И, конкретно, интерфейс на ART нарисовать можно?
18. mkalimulin 308 08.12.18 16:40 Сейчас в теме
(17) Затем, что язык - не самое адекватное средство для представления программы. Инструментов для рисования интерфейса и так слишком много.
19. genayo 08.12.18 18:04 Сейчас в теме
(18)Хорошо..Но кроме вас никто этим пользоваться не будет...
20. mkalimulin 308 08.12.18 20:48 Сейчас в теме
21. Steelvan 08.12.18 20:52 Сейчас в теме
(20) Перестаньте кормить местного тролля, там бесполезно задавать вопросы, надеясь на вразумительный ответ, он во всех умных темах пытается поучаствовать.
dbachinsky; Aggressorak; trntv; alk; nomadon; +5 Ответить
22. mkalimulin 308 08.12.18 22:53 Сейчас в теме
(21) Положение автора обязывает отвечать на все вопросы и а также задавать вопросы для прояснения позиции комментатора. Разумеется, в рамках темы.
24. genayo 09.12.18 07:25 Сейчас в теме
(21) ... а караван идёт. С добрым утром, Дружок!
23. genayo 09.12.18 07:24 Сейчас в теме
(20) Что упрощает ваш инструмент? В чём преимущества его использования? Для кого он?
25. mkalimulin 308 09.12.18 10:09 Сейчас в теме
(23) Посмотрите на пост (11). Автор поста обозначил задачу, которую он считает сложной, называет ее вызовом.
Когда он поймет, что решение этой задачи в ART состоит из трех блоков вложенных в еще один (всего четыре блока), возможно, он захочет пользоваться таким инструментом.
ART упрощает процесс программирования. И предназначен для всех, кому так или иначе приходится этим процессом заниматься.
Но в чем-то я с вами согласен. Надо будет добавить не просто пример, а что-нибудь имеющее практическую ценность. Я подумаю.
26. genayo 09.12.18 10:43 Сейчас в теме
(25) Преимущества вашего инструмента не очевидны из статьи, нужны сравнительные примеры.
утюгчеловек; +1 Ответить
29. mkalimulin 308 09.12.18 12:16 Сейчас в теме
(26) У меня есть соображения насчет этого. Но потребуется некоторое время. Следите за темой.
30. genayo 09.12.18 14:14 Сейчас в теме
(29) Хорошо, поставил плюс :)
81. kalyaka 437 09.02.19 13:12 Сейчас в теме
(18) наверное вы имели в виду не язык, а текст - не самое адекватное представление программы. Согласен, программа - это не текст, однако текст это одно из возможных представлений программы и наиболее распространенное.

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

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

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

Функциональный подход бладает достаточно высоким уровнем абстракции и менее доступен для понимания большинства, чем императиыный. Так что кажущаяся простота инструмента не означает простоту написания программ для не профессионалов.
83. mkalimulin 308 09.02.19 16:13 Сейчас в теме
(81) Язык линеен (или почти всегда линеен), поэтому я и ставлю знак равенства между языком и текстом.
Второй момент - язык сложен, а программа проста. Главное препятствие мешающее людям освоить программирование - неадекватность выразительного средства.
Функциональная парадигма - это, все-таки, немного другое. Если бы у меня переменные принимали значение типа "функция", тогда можно было бы о ней говорить.
На мой взгляд, функциональная парадигма всего лишь чуть лучше традиционного текста. Это - попытка вырваться из объятий метафоры бесконечной ленты. Прыгнуть от Тьюринга к Чёрчу. Она лишний раз доказывает, что проблема неадекватности текста существует и требует какого-то решения. Но решение, как мне кажется, не удачно. Будь оно удачно - мы бы уже все занимались функциональным программированием.
88. kalyaka 437 09.02.19 22:40 Сейчас в теме
(83)
Язык линеен
линейность зависит от ширины канала восприятия.
язык сложен, а программа проста
Язык сложен своей семантикой, а программа проста на определенном уровне абстракции. Простая семантика - простой язык, например как встроенный язык 1С
Главное препятствие мешающее людям освоить программирование - неадекватность выразительного средства
На мой взгляд главное препятствие - необходимость этому учиться, так же как необходимость учиться математическому мышлению или логике. Еще одно препятствие - это большое количество как самих языков и инструментов, так и изменений в них. Третье - сложность, как неотъемлемая характеристика программирования, моделирующего задачи действительности.

Выходом из положения являются специализированные языки DSL. Их семантика соответствует предметной области и предполагается, что владение предметной областью должно быть достаточным, чтобы программировать алгоритмы под ее задачи. Т.е. должна быть обеспечена адекватность языка предметной области.
Если бы у меня переменные принимали значение типа "функция"
Мне кажется вы могли бы докрутить свой инструмент для этого :) Ведь возможность переиспользования - это одна из главных возможностей программирования, уменьшающей трудозатраты и способствующей лучшему качеству программ.
функциональная парадигма... Но решение, как мне кажется, не удачно
У функционального подхода очень высокий уровень абстракции, который требует особого склада мышления, ему нужно учиться. У него есть преимущества и есть недостатки. Главное преимущество - математическая надежность программ, недостаток - требование отсутствия побочных эффектов, когда большинство пользовательских задач созданы ради этих эффектов.

В общем то как раз по той причине, что не найдено единой формулы универсального языка, нет и самого такого универсального языка. Вместо этого есть много языков и количество их продолжает увеличиваться, каждый из который наилучшим образом решает задачи только своей области.
Будь оно удачно - мы бы уже все занимались функциональным программированием
Тренд уже есть, все большее количество языков начинает поддерживать функциональную парадигму. Даже скриптовый язык браузера JS ее поддерживает и я уже не могу представить программирование на нем без функционального стиля.
94. mkalimulin 308 10.02.19 22:57 Сейчас в теме
(88) Выходом из положения является адекватный инструмент. Отказ от текста дает ту самую лекгость, без которой нет массового использования.
95. kalyaka 437 10.02.19 23:49 Сейчас в теме
(94) текст хорош тем, что не требует инструмента. Можно программировать где угодно, откуда угодно. Можно пользоваться GIT.

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

Попытки уйти от текста как представления программы есть, это тотже UML, оркестровки, диаграммы трансформации. UML не смог заменить текст, т.к. в его задачу не входит 100% описание программы, а лишь показать модель с определенной точки зрения. Оркестровки, диаграммы, построители SQL - да, но это все таки DSL.
96. mkalimulin 308 11.02.19 01:15 Сейчас в теме
(95) Гвоздь лучше самореза тем, что не требует инструмента. Его можно любым тяжелым предметом забить. Топор лучше бензопилы тем, что не требует бензина. А веревка лучше электросварки тем, что не требует дорогостоящего аппарата, а две железяки может вполне надежно соединить. Надо только соответствующие узлы вязать научиться.
В чем проблема воспользоваться инструментом? Религия не позволяет?
Если вы будете программировать с помощью текста, тогда вам не потребуется инструмент.
А если вы воспользуетесь инструментом, тогда вам не придется извращаться и представлять алгоритмы в неестесственном виде.
97. acanta 47 11.02.19 01:58 Сейчас в теме
(96) вы правы, для программирования сегодня достаточно пальцем ткнуть . За вашей идеей большое будущее.
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 308 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 657 10.12.18 09:34 Сейчас в теме
1C когда-то создавалась для того, чтобы бухгалтеры, не зная программирования, могли быстро и интуитивно "подправить" программу :) А потом всё заверте...

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

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

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


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

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

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

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

Кстати, оба фактора важны. Есть такой язык - ифкуиль. Типа как архиватор языка. Можно выражать длинные мысли несколькими звуками. Вроде как повышает производительность мыслительного процесса и речи. Но из-за очень большой сложности всё равно не нашёл распространения.
50. mkalimulin 308 10.12.18 17:39 Сейчас в теме
(43) Производительность можно обеспечить только если реализовывать ART на уровне платформы. Но, как показывает опыт, выразительность важнее производительности. Алгол тоже проигрывал в производительности автокоду.
Артано; +1 Ответить
44. for_sale 657 10.12.18 16:13 Сейчас в теме
(35)
А там и до написания своего языка для общения с 1С недалеко:) И будет 1С внутри 1С! Да и кто вообще может гарантировать, что мы все не находимся внутри какого-то 1С верхнего уровня? :))
41. Alien_job 157 10.12.18 14:03 Сейчас в теме
48. mkalimulin 308 10.12.18 17:29 Сейчас в теме
(41) Этому Дракону больше четверти века. Его проблема в том, что блок-схема - это тоже текст. Чтобы инструмент стал действительно "Д"-дружественным, надо уйти от текста.
42. vano-ekt 1136 10.12.18 14:40 Сейчас в теме
а какой-нибудь рег.отчет/общий модуль с тысячей методов можно посмотреть на ARTe как будет смотреться?
В обучении, в описании алгоритмов такие языки может быть... Но в прикладной, практической разработке в мире 1С не представляю их.
Описывать какой-то автомат, сервис - может быть. А написать учетную систему? Тут чаще гибкость, чем абстрактность нужна...
а плюсану-ка
Лет через 20 может на код 1С будт смотреть как на
49. mkalimulin 308 10.12.18 17:34 Сейчас в теме
(42) После того, как мне уже сказали: "дайте что-нибудь конкретное", я как раз в сторону налоговых деклараций и смотрю. Потребуется немного времени. Следите за темой.
52. Мичман Харитонов 11.12.18 10:39 Сейчас в теме
Интересно. С таким инструментарием программировать ну, скажем... на мобильном устройстве будет гораздо удобнее, чем традиционно набирать текст. Ну и в учебных целях, опять же. Это гораздо лучше, чем рисовать "мертвые" блок-схемы в тетрадке.
53. mkalimulin 308 11.12.18 10:49 Сейчас в теме
(52) Безусловно. Когда программирование пойдет в массы, люди в основном и будут программировать на смартфонах.
А блок-схемы, как я уже говорил, это - те же тексты.
54. Darklight 18 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 18 12.12.18 17:53 Сейчас в теме
(57) В пункте 2 я в первую очередь думал об идеи шаблонов языка С++, и о функциональных языках.
В 5-том пункте об интерфейсах думал только о средстве ввода и вывода данных. А не об архитектуре взаимодействия человек-данные
61. mkalimulin 308 12.12.18 18:08 Сейчас в теме
(54) С 1 и 3 согласен. И даже одно время хотел включить в стартовую версию.
Насчет 2 и 4 есть опасения, что пропадет простота инструмента.
По п.5 готов спорить. Встроенная операция ввода есть. Указываете источник для итератора - вот вам и ввод. Можно и нужно расширять понятие источника, включая, например: произвольные БД, HTTP-запросы, табличные документы.
Выходные же форматы, как мне кажется, не стоят усилий. Есть формат ART, в нем заложена органичная связь между дизайном и результатом.
55. yurikmellon 11.12.18 13:58 Сейчас в теме
очень интересно, попробую
62. mkalimulin 308 12.12.18 18:09 Сейчас в теме
56. btr 12.12.18 13:48 Сейчас в теме
Чего мне обычно не хватает как разработчику - это структуризации текста, с одной стороны (чтобы размечать конструкции, сворачивать их и разворачивать) и визуальный контроль контекста (т.е. какие объекты, структуры, переменные доступны в текущей конструкции, в модуле, в экспортных модулях, в подключенных API) - это два разных инструмента и их можно реализовать раздельно.

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

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

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

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

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

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

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

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

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

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

Идея ART будет понятнее, когда пройдет испытания масштабным проектом. Будем присматриваться, следить за новостями.
89. kalyaka 437 09.02.19 23:15 Сейчас в теме
(64)
В моем инструменте нет текста
А как же классика:
"Лучшим форматом для постоянного хранения знания является простой текст, позволяющий обрабатывать информацию как вручную, так и с помощью любых доступных инструментов. Проблема большинства двоичных форматов состоит в том, что контекст, необходимый для понимания данных, отделен от самих данных. А с помощью простого текста, доступного для чтения без дешифровки, вы можете создать самодокументированный поток данных, не зависящий от программы, которая его породила." Программист-прагматик. Эндрю Хант, Дэвид Томас ?
93. mkalimulin 308 10.02.19 22:53 Сейчас в теме
(89) А никак. Нас тут формат хранения знания не интересует. Нас интересует инструмент программирования.
69. mkalimulin 308 16.12.18 14:17 Сейчас в теме
Пока кто-то сомневается (см. мой предыдущий пост), trustasia решил прямо сейчас использовать ART в своем проекте. Ему нужна связь через COM, поэтому ближайщий update будет посвящен этому вопросу. COM будет точно. ADO и HTTP возможно в этот раз или в следующий.
Со своей стороны, я также определился с "серьезным" проектом на ART. Это будет декларация по налогу на добавленную стоимость. Следите за новостями здесь и в телеграмм-канале artvirtue.
70. o.nikolaev 234 22.12.18 23:06 Сейчас в теме
Своеобразно. Но, когда осуществляется стратегия "пусть расцветают все цветы и соревнуются тысячи школ мысли", это добрый знак. Стало быть, язык и среда - живы, коль скоро позволяют взвести подобные ништяки.
71. mkalimulin 308 22.12.18 23:56 Сейчас в теме
72. mkalimulin 308 30.12.18 16:27 Сейчас в теме
Теперь ART можно использовать как "табло".
73. Pr-Mex 115 01.02.19 10:33 Сейчас в теме
(0)
Чем-то мне это Gherkin напомнило.
74. mkalimulin 308 01.02.19 10:45 Сейчас в теме
(73) Эээ... Мой посыл прямо противоположен.
Gherkin - это древняя идея. Ее смысл - "а давайте будем программировать на естественном языке".
Моя идея - "где язык и где программирование?" Долой текст из программирования, а вместе с текстом и язык. Программирование по своей природе примитивнее языка и в языке не нуждается.
82. kalyaka 437 09.02.19 13:51 Сейчас в теме
(74) Язык это знаковая система, посредством которой мы передаем информацию или пишем программу. У вас это знаки A R T. Просто у вас язык совпадает со структурой программы, т.е. при интерпретации языка ничего делать не надо (сразу готово абстрактное синтаксическое дерево исполнения), т.е. сразу можно передавать на исполнение.
84. mkalimulin 308 09.02.19 16:15 Сейчас в теме
(82) Для языка важен момент общения. Нет общения - нет языка. Когда мы пишем программу, мы ни с кем не общаемся.
85. kalyaka 437 09.02.19 20:57 Сейчас в теме
(84) формальные языки были разработаны для однознаной интерпретации и, в отличие от человеческих, они не предназначены для коммуникации.
86. mkalimulin 308 09.02.19 21:03 Сейчас в теме
(85) Поэтому и не стоит называть это языками. Отсюда идет путаница. Язык, коммуникация, общение - все это линейно. Алгоритм - нет.
75. informa1555 897 01.02.19 17:39 Сейчас в теме
Очень интересно! Я как раз развиваю проект-конструктор мобильных клиентов https://infostart.ru/public/976636/ и по структуре эта штука идеально вписывается. У меня сейчас обработчики на обычном языке, но ведь можно использовать этот язык Art как альтернативу...
76. mkalimulin 308 01.02.19 18:04 Сейчас в теме
(75) Спасибо за отзыв. Добавил вашу разработку в избранное. Посмотрю ее внимательно чуть позже.
77. Артано 646 05.02.19 02:16 Сейчас в теме
Автору моё почтение. Критикам - вы просто не понимаете, что такое программирование. Это начинаешь понимать, когда занимаешься обучением или контролем.
Потому что подавляющее большинство сегодняшних, якобы программистов, могут писать код, но не могут программировать.
Подобная платформа, позволит дать знания о теории алгоритмов незамутненному детскому мозгу еще не извращенному каким-либо синтаксисом какого-либо языка. Либо, я надеюсь, расшевелить мозги уже испорченные, но еще не одеревеневшие. Это программирование в чистом виде и этим ценно.
78. mkalimulin 308 05.02.19 02:35 Сейчас в теме
(77) Спасибо за душевный отзыв! Рад, что вам понравилось.
79. zekrus 155 07.02.19 08:10 Сейчас в теме
Доброе утро!
Тема весьма актуальная:

Ничего не напоминает?
П.С.:
- Очень скоро профессия "Программист" уйдет в далекое прошлое как динозавры
(любой ребенок будет способен зайти на ресурс подобный yandex и голосом описать задание на компиляцию ПО).
Ох, хорошо что у меня есть первое образование механика (будем перепрофилироваться, тфу тфу тфу)...
С уважением
80. mkalimulin 308 07.02.19 11:26 Сейчас в теме
(79) Доброе утро!
В этой картинке нет ничего особенного. Вам может показаться странным, но это тоже текст, и вполне себе традиционный подход к программированию. Так что - с этой стороны вам ничего не угрожает.
Использовать вместо текста арт - это другое дело. Это действительно приведет к тому, что программировать будут все. Но и здесь не стоит беспокоиться. Обратите внимание на то, что с повсеместным распространением грамотности профессия писателя вовсе не исчезла. Более того. Только с появлением большого количества читателей, она приобрела свое настоящее значение. Тоже будет и с программированием. Настоящий потенциал этой профессии пока еще не раскрыт.
Артано; +1 Ответить
87. acanta 47 09.02.19 21:59 Сейчас в теме
Программа это завещание или последняя воля. Если у программиста ничего нет, зачем её писать? Если у программиста есть все, он пишет что со всем этим надо делать. Например Альфред Нобель основал Нобелевскую премию для всех, кроме математиков, потому что ревновал жену. Это достаточно простой алгоритм.
90. mkalimulin 308 10.02.19 09:59 Сейчас в теме
У программиста есть воля. Для создания программы больше ничего не требуется.
91. acanta 47 10.02.19 12:36 Сейчас в теме
Получается, что любая тех поддержка это зло и в общем случае она не нужна, если работа с программой приносит ожидаемый доход пользователям и не противоречит каким-то правилам.
92. mkalimulin 308 10.02.19 19:50 Сейчас в теме
(91) Не понял - к чему относится этот комментарий?
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Москва
зарплата от 160 000 руб. до 180 000 руб.
Полный день

Ведущий программист / Руководитель проектов 1С
Москва
зарплата от 190 000 руб. до 190 000 руб.
Полный день

Программист 1С ЗУП
Уфа
зарплата от 60 000 руб. до 90 000 руб.
Полный день

Программист 1С
Москва
зарплата от 140 000 руб. до 140 000 руб.
Полный день

Программист 1С
Санкт-Петербург
Полный день