Фирма «1С» анонсировала новые возможности «1С:Исполнителя»

29.09.2021      251618

В технологическом блоге «Заметки из Зазеркалья» разработчики опубликовали описание новых возможностей языка в планируемом релизе «1С:Исполнителя».

Что известно об обновлении языка в «1С:Исполнителе» 

В новый релиз планируется включить следующие возможности языка «1С:Исполнитель».

Обобщенные типы: появится возможность типизировать элементы коллекций; в ряде случаев компилятор сам выводит типы.

 

Типизация элементов массива. Источник: wonderland.v8.1c.ru

 

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

 

Лямбда-выражения. Источник: wonderland.v8.1c.ru

 

Именованные параметры: появится возможность задавать параметры в произвольном порядке по именам; возможность пропуска параметров в позиционной форме будет убрана.

 

Именованные параметры. Источник: wonderland.v8.1c.ru

 

Синтаксический сахар для работы с Неопределено: Оператор «?.» для безопасного доступа через точку (если источник Неопределено – результат всей цепочки вызовов – Неопределено), оператор «умолчание» возвращающий левое значение, если оно не Неопределено, иначе – правое.

 

Оператор «умолчание» для работы с Неопределено. Источник: wonderland.v8.1c.ru

 

 

Сроки выхода новой версии и перспективы «1С:Исполнителя» 

Фирма «1С» обещает выпустить анонсированное обновление до конца этого года. Напомним, что на данный момент «1С:Исполнитель» существует в статусе бета-версии.

Впервые об «1С:Исполнителе» стало известно в июне 2020 года. С тех пор вышло уже 6 релизов. Какой-либо информации о выходе из беты пока нет.

Между тем, недавно было объявлено о том, что «1С» работает над новой технологией разработки «1С:Предприятие.Элемент», одним из компонентов которой стал «1С:Исполнитель». Предполагаем, что благодаря этому обстоятельству «1С:Исполнитель» будет действительно динамично развиваться, и пользователи продукта смогут протестировать очередной релиз уже в этом году.

Пользователи с активным договором 1С:ИТС и партнеры фирмы 1С могут следить за выходом релизов «1С:Исполнителя» на сайте сервиса «1С:Обновление программ».
 

Полный текст заметки о возможностях новой версии «1С:Исполнителя» в официальном технологическом блоге


Автор:
Обозреватель


Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. dvsidelnikov 63 30.09.21 10:17 Сейчас в теме
Тверской областной суд переезжает, или даже уже переехал в здание бывшего торгового центра под названием Бастилия.
У меня теперь появилась мечта. Поставить там 1C:Executor и написать для них конфигурацию "Гильотина" для учёт судебных актов.
Пусть будет allinclusive: Суд-Бастилия-Экзекутор-Гильотина =)
starik-2005; user605780_L.Alexander8; kild; user1146461; +4 Ответить
2. leonvlas 30.09.21 11:40 Сейчас в теме
К большому сожалению язык совсем не выразительный и его надо учить по новому.
Почему нельзя было использовать стандартный синтаксис, подобное решение уже есть.
Почему 1с пошла по такому пути загадка.

В решении 1С Шина используется исполнитель.
user790708; +1 Ответить
3. kild 89 30.09.21 12:08 Сейчас в теме
(2)
Язык получился очень лаконичным современным. Видно, что 1с привлекли нужных профессионалов.
Местами напоминает Котлин.
Наконец-то выбросят старый синтаксист недоразумение 30 летний давности (прощайте шутки про 1сников). Платформа давно переросла возможности языка.
Строгая типизации решит кучу проблем в больших проектах и у туллинга больше возможностей появится.
Порог вхождения в 1с немножко увеличится, но теперь действительно можно будет кодить за результат, а не страдать.
4. amd1986 30.09.21 12:23 Сейчас в теме
(3) Можно было и существующему прикрутить типизацию.

результат это не кодинг, а готовый продукт. Когда выйдет новый язык, как минимум поначалу, трудозатраты на разработку только вырастут.
5. kild 89 30.09.21 13:03 Сейчас в теме
(4)
Можно было и существующему прикрутить типизацию.

Что бы старые проблемы умножить на новые? Тут более фундаментальные проблемы

результат это не кодинг, а готовый продукт

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

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

Язык уже вышел. Еще долгое время будет выбор между инструментами. Трудозатраты на больших проектах существенно снизятся. Читаемость кода сильно улучшится. Компилятор будет приносить больше пользы. Старый язык просто ограничен. Отсутствие возможностей не есть преимущество.
На новом языке можно продолжать писать в старом стиле если не охота отлавливать ошибки на этапе компиляции, а передавать это занятие пользователям и продолжать сидеть на небольших проектах. Думаю будет и возможность легко конвертировать старый код под новый.
6. Darklight 32 30.09.21 14:50 Сейчас в теме
Ну наконец-то, хоть что-то полезное в новом языке появилось. Все описанные новые возможности хороши.
Немного только смущает оператор "умолчание" в последнем примере (он, почему-то даже не подсвечен как ключевое слово; а ну да в 1С Исполнителе не все ключевые слова подсвечиваются, вернее операторы видимо не относятся к ключевым словам - что допускают в будущем перегрузку операторов?) - всё-таки, мне кажется, не стоило выбиваться из общемирового тренда - такой оператор должен быть в виде такого терма "??".

И ещё, я может раньше что-то пропустил - в типе "Структура" методы и деструкторы (хотя бы финализаторы) уже завезли, или только конструкторы пока есть?
Про свойства даже спрашивать пока не буду - чтобы совсем уж не расстраиваться, тем более про наследование

Ну а пока будем ждать кортежи... и деконструкторы

(5)
Компилятор будет приносить больше пользы

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

Думаю будет и возможность легко конвертировать старый код под новый.

Навряд ли. Из кода с динамической типизацией делать код со статической куда сложнее, чем наоборот
9. alex_sayan 01.10.21 11:15 Сейчас в теме
(6) зачем нужны деструкторы? Это атавизм
11. Darklight 32 01.10.21 11:33 Сейчас в теме
(9)Вы меня правильно поняли?
Я говорил
1. о финализаторах или об освободителях ресурсов - вещи не очень часто нужные в прикладгных программах на учётных платформах - но-всё-таки бывают полезными (уж на скриптовых языках то уж точно) - когда программный код захватывает какой-то ресурс (в 1С Предприятие 8 - это, например, может быть блокировка, в т.ч. объектная, или явная транзакция) - и должен явно его освобождать - есть специальные паттерны программирования (я синтаксический сахар(, позволяющие выполнять такие действия очень изящно, понятно и безопасно.

2. о деКонструторах - это тема для кортежей - позволяющая изящно приводить кортежи к набору переменных (в т.ч. изягщно их определяя) с минимум кодинга. Сейчас уже в моде неявные деконструкторы. Но иногда нужно писать явные. Так же деконструкторы примены к структурным данным (не кортежам) позволяющие так же деконструировать их поля на набор переменных применяя синтаксис деконструкции кортежей. Это всё из ФП идёт - и это сейчас в тренде в императивных ЯП
12. alex_sayan 01.10.21 11:42 Сейчас в теме
(11) зачем? Это прекрасно разруливается сборщиком мусора. К тому же, в нашем несовершенном мире 1сники вовсю пишут километровые процедуры, приводящие к излишне долгой жизни переменных. Так что не до роскоши
buganov; kild; +2 Ответить
14. Darklight 32 01.10.21 11:56 Сейчас в теме
(12)
Это прекрасно разруливается сборщиком мусора

Я говорю о явном управлении ресурсами. Если хватало сборщика мусора - то этого не было в других управляемых ЯП. Для скриптового языка - это вообще очень важно - так как тут такие операции достаточно часты:
1. Файловые операции
2. Операции с базами данных
3. Сложное web-взаимодействие (с сеансами), как по HTTP, так и напрямую на TCP сокетах
4. Криптооперации с повышенной безопасностью
5. Взаимодействие с внешними компогненами/библиотеками
6. Прочие операции интеграции с другими системами

Всё изложенное касается и учётных систем. Тут ещё добавить можно:
1. Явное управление транзакциями
2. Явное управление блокировками (просто сейчас этого нет в 1С8 - то что есть в управляемых блокировках - это всё слишком тривиально и ограничено, хотя... вот есть объектные блокировки)
3. Разграничения и блокировки при параллельной работе (даже сейчас это может быть актуально в 1С8 при работе с фоновыми заданиями - просто уровень очень примитивный, чем мог бы быть в будущем)

К тому же, в нашем несовершенном мире 1сники вовсю пишут километровые процедуры, приводящие к излишне долгой жизни переменных

Вот как раз освободители ресурсов могли улучшить эту ситуацию - ибо сразу в мире 1С пришли соответствующие паттерны программирования и их стали бы прививать


К тому же на освободителях ресурсов можно строить очень интересные нестандартные схемы применения при формировании движений, или выходных форм. Особенно если платформа даст такие гибкие возможности
18. alex_sayan 01.10.21 16:22 Сейчас в теме
(14) всё перечисленние от и до юзается в системах на Java, но в Java нет деструкторов

Вот как раз освободители ресурсов могли улучшить эту ситуацию - ибо сразу в мире 1С пришли соответствующие паттерны программирования и их стали бы прививать


Не очень в этом уверен. Сейчас можно встретить, как в длинной процедуре создаётся МенеджерВременныхТаблиц, ещё в самом начале [кода процедуры] он выполняет свою миссию, а потом благополучно живёт до конца процедуры, удерживая соединение и временные таблицы в TempDB. Уж если МВТ не удосуживаются закрыть, то что говорить о других ресурсах. Какие там паттерны, хотя бы рукозадство победить
20. Darklight 32 01.10.21 16:34 Сейчас в теме
(18)Я не говорю о физических деструкторах (как, например в C++) - я говорю о паттернах освобождения ресурсов - обычно реализуемых через интерфейс IDisposable и некоторый синтаксический сахар в ЯП.

Не очень в этом уверен. Сейчас можно встретить, как в длинной процедуре создаётся МенеджерВременныхТаблиц, ещё в самом начале [кода процедуры] он выполняет свою миссию, а потом благополучно живёт до конца процедуры, удерживая соединение и временные таблицы в TempDB. Уж если МВТ не удосуживаются закрыть, то что говорить о других ресурсах. Какие там паттерны, хотя бы рукозадство победить

Я имел в виду, несколько иное - а именно захват владения временной таблицей после её создания и удаление как только она больше не нужна, с возможно последующим новым созданием.
Кстати, аналогично можно удерживать и коллекции в объектной модели - об этом не задумываешься, пока не начинаешь программировать для BigData
13. buganov 200 01.10.21 11:54 Сейчас в теме
(11)
п.1. Как Вы себе представляете освобождение блокировки внутри транзакции? И как должна повести себя система в таком случае, если транзакция еще длится, а незакоммиченные данные уже свободны для изменения? А если будет в конце * транзакции?

В чем польза явной типизации? Ну вот хотя бы пару примеров. На грабли только натыкаться. Да и как это применимо в рамках конфигураций 1С? Пару мегабайт памяти экономить, чтобы возросла стоимость разработки и сопровождения?
1С в свое время и заняла рынок тем, что порог входа низкий, любая организация в максимально сжатые сроки максимально дешево перенесли бизнес-процессы в программу. Для любителей садо-мазо есть ABAP в SAP.

Именованные параметры, ну да, удобнее, но мне ближе питоновский синтаксис словаря, коротко и ясно:
Структура = {"Фамилия": "Иванов", "Имя": "Иван"}

Значение по умолчанию, в целом, неплохо, но как то не красиво
19. Darklight 32 01.10.21 16:25 Сейчас в теме
(13)
Как Вы себе представляете освобождение блокировки внутри транзакции? И как должна повести себя система в таком случае, если транзакция еще длится, а незакоммиченные данные уже свободны для изменения? А если будет в конце * транзакции?

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

Надо сразу определиться с тем, сколько у нас может быть разных ситуативных сценариев (в общем случае, а не только то, что может сейчас платформа 1С Предприятие 8 и СУБД). А, на вскидку, имеем 4 ситуации (2 на 2 вариантов)
Два варианта - это какие данные мы блокируем - неизменяемые, или изменяемые
Два варианта - это какие способы у нас есть изменения данных: только полная замена значения, или доступны более хитрые операции

Рассмотрю эти сценарии (в транзакции):

1. Обычные операции изменения. Блокировка изменяемых данных.
Навскидку в такой ситуации есть резон блокировать данные до момента их изменения. И нет смысла отпускать блокировку явно, до завершения транзакции. Но, возможны нюансы:
1а. Могут быть случаи явной предварительной блокировки изменяемых данных без их фактического изменения. При этом алгоритм может понять, что эти данные ему не нужны за долго до завершения транзакции – и принять решение о том, чтобы их отпустить – чтобы не мешать другим алгоритмам (оставим пока в стороне проблемы взаимных блокировок – это уже другой вопрос и с другой правильной стратегией решения, явно непротиворечащей данной ситуации), пока ещё выполняется текущая транзакция.

1б. Могут быть случаи, когда данные нужно заблокировать, изменить и тут же отпустить. Не завершая текущую транзакцию (но внося изменения в СУБД) – это уже задача формирования параллельной транзакции (немножко другая тема), но по факту такие задачи тоже могут возникать (у меня возникали). Кстати на 1С Предприятие 8 такую ситуация «через одно место» но реализовать можно – параллельные транзакции можно открывать фоновыми заданиями.
Кстати итоговая транзакция в конце может как успешно зафиксироваться, так и откатиться. И это всё тоже по-разному может отработать (в случае отката – можно на это «подписаться» и тоже выполнить какие-то действия «освобождения»)

1в. Могут быть ситуации, когда данные меняются временно – нужны только для текущего алгоритма выполнения, но нужно отразить их в СУБД. А потом отменить и блокировку и изменения, не откатывая всю транзакцию – но это уже совсем специфическая ситуация. Чаще всего решаемая временными таблицами. Но, кстати, удерживание временных таблиц – это тоже хороший повод для реализации стратегии управления явным освобождением ресурсов.

2. Обычные операции изменения. Блокировка неизменяемых данных.
Вполне себе рядовая ситуация – когда нужно получить целостный кластер данных из СУБД, в промежутках получения которого уже полученные данные не изменятся. А после получения всех данных – блокировку можно смело снять, продолжая текущую транзакцию. Так как по сути изменение исходных данных уже не должно повлиять на алгоритм – т.е. работа с версией слепка данных. В конце транзакции можно, при необходимости, привести контрольное получение всех данных – и если что-то изменилось принято, то или иное решение. Например, оставить транзакцию зафиксированной, но пометить – что какая-то бизнес операция может быть неактуальной – и её нужно будет актуализировать позже.

3. Расширенные операции изменения. Или отложенные во времени операции изменения. Блокировка изменяемых данных.

Если в нашем распоряжении по изменению данных есть что-то больше чем тупое устаревшее присвоение с поной заменой нового значения. То можно делать более хитрые и более сводные от ожидания на блокировках операции изменения данных. Например, будь у нас относительные операции изменения как «Плюс» («Минус») – то можно вносить изменения в ресурс относительно – тогда в ряде практических сценариев можно не держать блокировку ресурсов долго – и отпустить их сразу после завершения относительной операции. Само собой операции чтения таких ресурсов должны уметь поддерживать нефиксированные значения (двойные: одно устаревшее зафиксированное, другое оперативное, но готовое измениться в любую сторону в любой момент, в т.ч. при откате транзакции).
Аналогичным может быть сценарий, добавления новых записей в таблицу (так называемых вероятно фантомных, или записей не повторяющегося чтения) – мы можем заблокироваться на время защитив себя от таких записей, а потом снять блокировку, когда нам это уже будет не важно, но ещё до завершения транзакции. Ведь если есть алгоритм, который хочет внести такие записи – то он всё-равно их может внести, просто сейчас дождавшись завершения блокировки-транзакции – но на первый алгоритм это никак уже не повлияет. А задержка на блокировке может быть существенной. Так же как если бы это были фантомы – которые потом «задним числом» исчезнут. Это всё проблемы, которые нужно решать скорее не блокировками, а другими сценариями контроля.
Так же в этот сценарий можно включить изменения данных, которым не важно кто-то их изменил последним. Которые в процессе транзакции могут по нескольку раз считываться и изменятся.
А ещё – операции изменения могут быть отложенными во времени – например, нужно частично провести сейчас (оперативно), а полностью позже (отразить в остальных разделах учета). Тогда можно оперативны ресурсы заблокировать сразу, внести оперативные изменения, отпустить оперативные ресурсы. И только потом приступить к прочим длительным алгоритмам формирования остальных движений.

4. Расширенные операции блокировки. Блокировка неизменяемых данных.
Могут быть сценарии, когда нужно заблокировать неизменяемые данные, так, чтобы их, на время их обработки их никто не мог другой заблокировать (но их можно было читать), при этом ещё и можно было бы получать все незаблокированные (или наоборот – текущие заблокированные). И в процессе их дальнейшей обработки поочередно каждый или выборочно отпускать, снимая блокировку – давая возможность их обрабатывать параллельным транзакциям. Это могут быть, например, какие-то триггерные-дескрипторы, управляющие параллельными процессами обработки связанных с ними данных.

Это я кратко изложил идеи. Конечно тут много над чем стоит подумать и проработать. Но это уже статью надо готовить. Суть в том – чтобы снижать время блокировки ресурсов. В идеале – стараться их вообще не блокировать и вести учет в рамках недетерминированных значений ресурсов.

В чем польза явной типизации? Ну вот хотя бы пару примеров. На грабли только натыкаться. Да и как это применимо в рамках конфигураций 1С? Пару мегабайт памяти экономить, чтобы возросла стоимость разработки и сопровождения?

1. Это упрощает процесс кодинга – когда сразу известны ожидаемые типы – подсказки IDE (малую толику таких подсказок уже можно увидеть в EDT, да и стандартный конфигуратор частично тоже умеет выводить типы – просто очень ограничено), автодокументация, более быстрое понимание алгоритмов и API, снижение числа ошибок, упрощение контроля входных данных, упрощение автоматизации тестирования. Более явное обозначение мест реального возникновения ошибки по всему дереву стека вызовов (т.е. откуда фактически пошли неверные входные данные). Логические ошибки тоже сокращаются – если внутри функции аргумент должен быть номенклатурой (и так он записывается в регистр, например), а в функцию передадут номенклатурную группу – то никакой ошибки не будет даже в рантайм – а запись в регистре будет неверной (пустое значение, если номенклатрные группы не поддерживаются, а если поддерживаются - то всё-равно это может быть не ожидаемое значение и оно всплывёт где-то позже – и попробуй потом найди «откуда ноги растут»). Ведь исходное значение может придти откуда угодно – да хоть из внешней системы. Будете тратить время на проверку каждого аргумента в коде? Или проще в пару слов задать ожидаемый тип как я указал выше, и всё проверки сделает платформа – причём постарается вынести их как можно ближе к реально получаемым исходным данным!
2. Упрощение кодогенерации, особенно при применении рефлексии – можно писать препроцессоры, которые на основе одного кода буду генерировать другой код.
3. Оптимизация алгоритмов – не столько за счёт сокращения объёмов памяти, а сколько из-за сокращения проверок в рантайм, а так же лишних левых соединений при обращении через точку к составным типам.
Стоимость разработки и сопровождения возрастает не значительно (да и в моём предложении для 1С Предприятие 8 я описал доп возможности, которыми можно не пользоваться, например, в тривиальных случаях). А вот анализ такого кода станет куда более простым – а значит, как раз сопровождение в дальнейшем будет проще.

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

Тогда да – но времена изменились. Теперь из-за этого 1С теряет рабочую силу – современным программистам язык 1С кажется динозавром из прошлого. А бывалые 1С-программисты тоже чертыхаются из-за того, какой сложный и замороченный программный код выходит «из под пера 1С» в силу ограниченности языка и платформы, и как сложно его расширять, поддерживать и обновлять. И тут тоже начались уже потери кадров.
Да и вообще классические платформы учета теряют уже актуальность – простота создания учётных систем на них стала не так критична. Ибо на обучных языках программирования прошёл серьёзный прогресс и писать такого рода системы стало куда проще и комфортнее. Как и искать таких специалистов. А ещё в моде нынче опенсорс. И экономия на лицензия. Плюс ориентир потребления на сферу web и мобильных клиентов – где в тренде стали совсем другие подходы к фронтенду и клиент-серверному взаимодействию так же не пользу старых проприетарных учетных систем. Но западные системы уже начали меняется и подстраиваться под новые реалии.
Бакэнд разработка тоже давно угла вперёд – в моде облака, параллельные и распределённые вычисления, микросервисы и гибкая интеграция с разносторонним софтом через шины данных.
В тренде AI системы, голосовое управление, умная кодогенерация и машинное обучение.
В общем мир изменился – то что ранее было привлекательно, сейчас уже просто ржавый якорь.
Новым платформам и ЯП нужно быть в тренде, чтобы не остаться за боротом. А упрощение должно идти за счёт умных IDE с AI ассистентами, инструментами анализа и рефакторинга программного кода, повышения его прозрачности и лёгкости модификации, сопровождения и обновления. ЯП должен быть привычным актуальному мировому тренду. И иметь мощные привлекательные фишки, выделяющие его на фоне других систем. Большая часть кода должна формироваться автоматической и полуавтоматической кодогенерацией.

Именованные параметры, ну да, удобнее, но мне ближе питоновский синтаксис словаря, коротко и ясно:
Структура = {"Фамилия": "Иванов", "Имя": "Иван"}

Я, кстати, не об именованной передачи аргументов говорил. И не об определении структура.
Но если Вы об этом заговорили. То питоновский подход мог бы быть близок к текущей идеологии конструирования объектов типа «Структура» в 1С8 (хотя подход из JS мне нравится больще).
Но у него могут быть проблемы с операциями рефакторинга и с подсветкой синтаксиса.
А я, всё-таки говорил о кортежах, у которых значения могут и не быть именованными (а могут и быть – тогда это просто более легковесные структуры – передаваемые по значению, а не посылке)
Например так (на расширенном синтаксисе 1С8)
Перем к,к2, а, б, в;
к = (10, ”стр”, Истина);
(а, б, в ) = к;
к = (а:=10, б:=”стр”, в:=Истина);
к2 = (a:=0,б:=0,г:=0,б=0);
к2 := к; // к2 заполнит значения (a:=10,б:=”стр”,г:=0,б=Истина)

Простите, за кривоватый пример – лень сейчас придумывать красивый
22. buganov 200 01.10.21 18:57 Сейчас в теме
(19) Если честно, то читать Вас безумно сложно. Вроде текста много и слов умных много, а сидишь и думаешь, что автор треда пытался сказать. Проще нужно быть, не в обиду.
1. Почти все противоречит принципам ACID транзакций.
И это не 1С такая плохая, это ограничения СУБД. 1С единственное, не может работаьт в режиме изоляции Sanpshot. Не RCSI, а именно снепшот.
1б. Параллельные транзакции могут блокировать только непересекающиеся данные. И это правильно, иначе среди тысяч пользователей начнется хаос.
1в. Атомарность транзакции. Про временные таблицы не понял, они и так не накладывают блокировок.
2. Вы описываете почти то, что делает платформа при RCSI. С той разницей, что я понять не могу, зачем блокировать считываемые данные и прямо внутри транзакции? Если Вам прямо так нужно, то откройте явную транзакцию, установите Shared управляемую блокировку и закройте транзакцию
3. Вы описываете устаревший уровень изоляции. В 8.3 или 8.2 с флагом снепшот в СУБД нет неповторяющегося чтения, по крайней мере в управляемом режиме. И фантомы возникают только при чтении вне транзакций в 8.2

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

Язык 1С всегда казался для типа трушных динозавром. И смешным. И вообще на русском. И вообще фу-фу-фу. Но факт остается фактом. Порог входа низкий, на коленке вкатить бизнес-процесс можно. И в целом, очень даже неплох. Да, нет библиотек, да, БСП, да, хотелось бы расширить и сделать из 1С 1С#, или питон. Но зачем? Вот в принципе, какую учетную задачу не решит 1С? И даже при правильном подходе выдержит highload с тысячами пользователей и десятками террабайт данных. Да, хочется сахара, но куда важнее для бизнеса фишки для бизнеса, а не для кодеров, они как-нибудь уж и сами разберутся. И очень даже неплохо получается. При должных компетенциях, конечно же.
Мода и всякие красивые словечки это не про 1С, согласен. Но еще раз, зачем оно? Вот есть завод или торговая сеть. Зачем заводу микросервис, если и в рамках базы все работает? Зачем облака, если можно запустить тонкий клиент? И уж тем более AI, который разве что в крышку унитаза не пихают. Может еще блокчейн впендюрить? Тоже мода.
Хотите микросервис? Да пожалуйста, в платформе есть механизм http. Да, нагрузку десятков тысяч запросов он не выдержит, но редкому бизнесу это нужно. Ржавый якорь работает и работает очень даже хорошо. Торговую сеть любого масштаба автоматизирует и РЦ любого масштаба.
И что-то я в том же питоне в пишарме не видел автоматическую и полуавтоматическую кодогенерацию, или он тоже того?
Ни сап, ни оракл, ни аксапта не гонятся за мировыми трендами. Почему? Да потому что это enterprise и тут не шашечки, тут ехать. Гибкая интеграция через шины данных? Это тоже есть и на ИС немало статей даже. Вам нужны бантики, мода и уважение среди тру, бизнесу нужно быстрое внедрение новых процессов.
25. Darklight 32 04.10.21 11:30 Сейчас в теме
(22)
умных много, а сидишь и думаешь, что автор треда пытался сказать.

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

Почти все противоречит принципам ACID транзакций

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

Параллельные транзакции могут блокировать только непересекающиеся данные

Я с этим и не спорил (но замечу, что, в общем-то, блокировки могут быть разные - и куда более хитрые, чем те к которым привыкли программисты 1С, главное реализовать их поддержку). Я в пункте 1б. говорил о параллельной обработке данных в отдельной скоротечной транзакции со снижением времени стандартных блокировок.

Про временные таблицы не понял, они и так не накладывают блокировок

В пунтке 1в. я говорил о блокировка не на временных таблицах. А, например на такой таблице как регистр сведений "Списанные товары" - используемой для промежуточных расчётов, но не являющейся временной. Ранее эта таблица в типовых конфигурациях была очень узким местом. Сейчас более активно (но не всегда - те же регистры расчёта) используются временные таблицы. Но это не исключает того, что будь механизм блокировок более гибким - это не дало бы преимуществ при использовании не временных промежуточных таблиц для ряда хитрых сценариев. Например, при использовании параллельных потоков обработки данных. Хотя некоторые СУБД умеют поддерживать временные кросс-сеансовые таблицы.

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


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

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

Вы описываете устаревший уровень изоляции

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

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

Просто я плохо описал. Я Вы плохо поняли. Ни в коем случае не пропагандирую вредные сценарии. Всему своё место.
И, как уже сказал, принципы ACID сейчас уже не так уж оберегаемы - и поэтому очень популярны NoSQL решения. А сейчас начался ещё и новый тренд - гибридных СУБД - сохраняющих ACID (хотя бы частично) и дающих новые расширенные возможности NoSQL с минимизацией блокировок и ускорением аналитических запросов.

Порог входа низкий, на коленке вкатить бизнес-процесс можно

В простые задачи да? С нуля написать на коленке приложение - действительно не так уж и сложно. В БСП уже нет! В типовые конфигурации - уже нет!
Синтаксис языка простой - но уже не привлекательный.
А конфигурации на нём созданные - уже не простые и через "пень колоду" спроектированные - это всё тоже уже отпугивает.

хотелось бы расширить и сделать из 1С 1С#, или питон. Но зачем?

Потому что в нынешнем виде он уже никому особо не интересен - лишь старой гвардии по инерции. Да и среди них ряды уже редеют. Простоты тут уже нет.
Времена бейсика прошли - бейским мётв! Тенденции и тренды уже совсем другие!
Но я не говорю - что ЯП должен быть сложным. Он должен быть гибким - позволять легко создавать и поддерживать понятный программный код. И вообще - стремить в область LowCoding'а. Но нынешние ЯП 1С (что один, что другой) - это всё не из этой оперы.

Зачем заводу микросервис

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

Зачем облака, если можно запустить тонкий клиент?

Не понял, что Вы имели в виду?
Облачные технологи - это средства оптимизации серверной части - они от клиента не зависят (ну условно не зависят - реализация разной бывает, вот сейчас 1С автономные клиенты внедряет в мобильном секторе - все жду этого и в десктопом)

Хотите микросервис? Да пожалуйста, в платформе есть механизм http

И на том спасибо. Жаль только асинхронный так и не завезли. А без асинхронности нынче всё это уже не так привлекательно. Да и переделывать вручную всё клиент-серверное взаимодействие на http сервисы - та ещё задачка!
И, говоря, о микросервисах - я имел в виду работу с СУБД - и да, это всё-таки задачи из области BigData - то есть не для всех!

Ржавый якорь работает и работает очень даже хорошо

Работает. Я и не спорю. Вон - люди до сих пор учет в Excel ведут, или на Acces или в FoxPro ведут или делают записи в бумажных журналах - и ничего - не жалуются. Бизнес идёт, налоги платся.

И что-то я в том же питоне в пишарме не видел автоматическую и полуавтоматическую кодогенерацию, или он тоже того?

не могу судить за питон. Но в C# точно есть - хотя бы Razor/Blazor, есть и системы пользовательского препроцессинга, и механизмы сборки, системы авто генерации документации.
Но всё-таки - говоря о когенерации я всё-таки имею в виду не ЯП - я платформу, в рамках которой этот ЯП используется.
Я хочу написать статью и сделать даже доклад для конференции - о том как я вижу учётную систему не очень далёкого будущего - пока подготавливаю материал - но надеюсь в недалёком ;-) будущем всё-таки всё это подготовлю - надеюсь это будет познавательно (и изложено более простым языком)! Даже если я окажусь не прав!

Ни сап, ни оракл, ни аксапта не гонятся за мировыми трендами. Почему? Да потому что это enterprise и тут не шашечки, тут ехать

Все они уже и так обходят платформу 1С по своим возможностям и все они вместе с 1С уже и так стагнируют по учётному рынку - потому что новые клиенту при выборе учётной - активно смотрят уже в сторону не проприетарных платформ. А активно применяют опенсорс. Все эти старые системы пока ещё выезжают на счёт инерционности мышления рынка (и за счёт регл. учета - который всё чаще уже на аутсорсе). Но так или иначе все они изменятся.
У 1С мог бы быть шанс потеснить мировых корифеев на рынке учёта - создай она новый уникальный продукт - с принципиальными преимуществами, конкурентный как с мировыми монстрами учёта, так и с системами условного опенсорса, не применяющих проприетарные учётные платформы
26. buganov 200 04.10.21 12:45 Сейчас в теме
(25)
Все они уже и так обходят платформу 1С по своим возможностям и все они вместе с 1С уже и так стагнируют по учётному рынку

А Вы лично работали с одной из этих систем в качестве разработчика? Сап допилить -можно чокнуться, какие уж тренды, там в коде семидесятые годы прошлого столетия. Оракл невыносимо сложный. Аксапта. Обхохотаться можно. Любая интеграция через их коннектор боль и душераздирающие стоны. Скорость разработки крайне низкая. Специалистов крайне мало.
Опенсорс? Я, конечно, все понимаю, но чтобы из опенсорса сделать ERP систему нужно вложить тонны нефти. Та же 1С работает из коробки. Ни один опенсорс не вывезет РСБУ в сроки, в которые вываливают изменения наши власти.
И как раз из-за простоты, легкости и стоимости 1С может тягаться с мировыми топами. Другое дело санкции, осторожность в российский софт, а вдруг запретят и пошло и поехало.
Я не против сахара, возможности из коробки NoSQL для некоторых задач, но учетные системы явно не про NoSQL. Я не против удобства и свистелок-перделок. Просто странно читать про все вот это модненькое и напоминает тред менеджера по продажам. Модное != Лучшее. Для 1С приоритет стабильность, качество конфигураций. Прирост устойчивости сервера под нагрузкой. А Вы предлагаете нырнуть в пучину, начать пилить под модные веяния, которые через пяток лет уйдут, как невзлетевшие, и что тогда? Назовите хоть одну торговую сеть, которая построила свою учетную систему на микросервисе =) Начните с мастадонта X5 и магнита
27. Darklight 32 04.10.21 13:30 Сейчас в теме
(26)Я не спорю, что конкурирующие системы просты в разработке, и не имеют досадных ограничений.
Но по привлекательности для разработчиков и для клиентов - они с лихвой обходят 1С - иначе 1С бы их давно потеснила на мировом рынке. Но это уже холивор - так как проблем вытеснения таких систем вагон и маленькая тележка - и большая часть из них лежит вне технической части платформы (как и то, что 1С в некоторых странах СНГ, включая Россию, имеет такие же сильные позиции для вытеснения этими же импортными конкурентами).
Поэтому и написал - чтобы подвинуть гору не достаточно просто иметь двигатель просо мощнее чем у других - нужны инновации!
1С Предприятие - хорошая платформа с большим потенциалом. Но сколько можно копошиться в XX веке? Если сейчас в России платформа ещё привлекательна для бизнеса (скорее в силу демпинговой ценовой политики компании 1С). То для новых разработчиков она уже не интересна.
Как когда-то я - совершенно случайно занялся задачами на 1С7.7. (работая в компании программистом совсем других систем) - та платформа мне совсем не нравилась. Как и её лозунг "Всерьёз и надолго". Ничего серьёзного в неё я не наблюдал. Но так сложились реалии того времени для бизнеса - срочно нужно было освоить готовое решение, доработать и провести развёртывание и интеграцию, а ни одного 1С-ка в кампании не было.
Прочертыхался я с 7.7 2 года - а потом пришла 1С Предприятие 8.0 - и это было "небо и земля" - не идеальная, но вполне себе удобная платформа. Да, она во многом уступала обычным системам программирования даже конца XX - но в неё виделся большой потенциал! Причём я тогда мало знал про Java - если бы больше - то наверное ушёл бы туда, как вскоре сделал мой друг и колега (вместе с которым мы осваивали 1С с нуля) - и он не пожалел.
А потом пришла эра MS .NET и C# - и это была революция в ЯП (сразу скажу - что не считаю C# идеальным языком, и вообще я тогда совсем другой ЯП для .NET стал осваивать).
С этого момента вообще в IT начались революции в подходах к разработке - много чего появилось за последние 20 лет в системах проектирования IT систем.
Но платформа 1С Предприятие 8.... нет она, конечно, тоже кое в чем продвинулось, но, во многом, что устарело уже в начале XXI века так и осталась в прошлом. И лично мне кажется, в таком виде у этой платформы уже нет будущего. Побарахтается, наверное, ещё лет 30 и окончательно загнётся. Хотя - если РФ уйдёт в политическую самоизоляцию - то новые технические веянья в страну поступать почти перестанут - тогда да - может и ещё полвека продержаться - пока свои Кулибины не всё-таки её не сбросят с пьедестала - ибо консерватизм полезен только в меру!
Но я делаю ставку на то, что через 30 лет всё-таки и в 1С случится новая революция - старый топменджмент уйдет, а новый, возможно, будет смотреть дальше в будущее!

но чтобы из опенсорса сделать ERP систему нужно вложить тонны нефти

Никто из опенсорса ERP с нуля не делает. Берут отельные блоки и интегрируют между собой. Отдельные части пишу с нуля да - но только по-необходимости. И замечу, что я вынес регл. учет в отдельный блок - и сказал, что всё чаще его ставят на аутсорс, где совсем другие реалии. Просто в РФ до этого ещё не созрели - чёрная бухгалтерия не отпускает как и опасения за утерю конфиденциальной финансовой информации - дикая страна же!

но учетные системы явно не про NoSQL

Обоснуйте?

Для 1С приоритет стабильность, качество конфигураций

Чего нет в 1С итого нет!


.... да и не о микросервисах я писал вовсе.... есть много всего, что можно было бы внедрить даже в 1С Предприятие 8 - сохраняя совместимость! И в первую очередь - что упростило бы разёртывание, доработку и сопровождение платформы и конфигураций на её основе! Повысило бы их надёжность!
но на других ресурсах, где обитают программисты только их использование и обсуждают.... что они все мелкие сошки?
28. buganov 200 04.10.21 13:42 Сейчас в теме
(27) NoSQL хорошо, когда данные добавляются, редко изменяются и часто читаются. Те же журналы в эластике прямо глоток воздуха, когда ТЖ и ЖР(140 Гб за две недели) закинул. Есть, конечно, вероятность, что я несколько отстал, но не вижу в целом механизма работы ERP в NoSQL. Может примеры есть какие?
1С работает стабильно во многих крупняках. Главное ее правильно приготовить. Есть, конечно, вероятность бага платформы, но в целом норм даже под нагрузкой. Не сотни тысяч, конечно, но оно и не надо.
они все мелкие сошки?

Нет, конечно, но каждой разработки свои технологии. Основой учетной системы как микросервис я вижу только в интеграции с сайтом, с кассами. Но есть ведь еще много чего. Складской учет, БУ, УУ, логистика. И все это про расчеты, но не про сервисы.
Согласен, что в платформе фичи для разработки появляются редко, и что хотелось бы гораздо большего или вообще отдать JetBrains аутсорс, чтобы сделали крутую IDE, но работаем с тем, что есть и в целом, мне нравится, можете меня назвать динозавром =) Только чур тиранозавром =)
29. Darklight 32 12.10.21 12:39 Сейчас в теме
(28)
NoSQL хорошо, когда данные добавляются, редко изменяются и часто читаются.


Да, NoSQL изначально заточен под это. Но сейчас есть гибридные системы (та же SAP HANA, например) позволяющие совмещать оба подхода – просо часто изменяющиеся данные хранятся в реляционной структуре оперативного кеша. А теперь давайте поразмышляем – большая ли потребность в учетных системах в часто изменяющихся данных (при условии применении версионирование модели хранения записей в СУБД)?

Есть, конечно, вероятность, что я несколько отстал, но не вижу в целом механизма работы ERP в NoSQL. Может примеры есть какие?


По сути – справочники, и документы – это всё редко меняющиеся данные. При их вводе – их можно помещать в оперативный кеш – а далее СУБД уже сама их переместит в не реляционную структуру (какую – но это можно либо индивидуально настраивать, либо ставить режим auto – чтобы умная система сама решала, как лучше хранить данные – в зависимости от анализа их фактической структуры и статистики обращения к ним).

На самом деле - все виды регистров тоже прекрасно подходят под нереляционное хранение. Просто тут более явное разделение на два вида нагрузок OLTP и OLAP. И именно под разный сценарий использования нужно заранее конфигурировать регистр. В т.ч. задавать гибридный вариант. В зависимости от настройки – регистр может храниться в СУБД по-разному (как и по-разному к нему могут строиться вспомогательные структуры, для оптимизации доступу к данным). Не зависимо от настройки сценария нагрузки, для регистров нужна настройка режима «архивирования» - когда старые сведенья (даже для оперативного регистра) переводятся из реляционной модели в NoSQL (скорее всего в колоночный формат), в т.ч. вообще могут выноситься из основной базы данных и замещаться в архивной базе данных – на более медленном оборудовании (ну или может применяться режим секционирования таблицы, и вынесение в отдельный файл или даже отдельный сервер кластера СУБД).

В Гибридном варианте могут сразу применяться две стурктуры OLTP и OLAP. Сначала данные кэшируется в реляционной модели (по современным меркам это уже строго режим In memory database – для максимизации производительности), но система старается как можно быстрее перенести их в NoSQL формат – чтобы обеспечить максимальную производительность считывания (и уменьшить объём хранения – стараясь оставить хранение горячих данных в памяти)

Сам термин NoSQL формат мне не нравится – но не знаю какой ещё применить для описания обобщённого семейства форматов, отличных от реляционного. Система может поддерживать сразу несколько из них – под разные цели подойдут свои форматы.

А вот язык запросов как раз должен быть единым – и вполне может сохранить большую совместимость с SQL языками современных реляционных СУБД. Некоторые современные NoSQL сейчас активно стараются обеспечить такую поддержку, кстати – но это не важно – в учётной системе то свой язык запросов.

Но я не сторонник языка SQL – считаю его сильно устаревшим пережитком прошлого. Считаю – что обработку данных всё-таки стоит вести на более продвинутых языках запросов (но можно оставить некоторую совместимость и с ANSI SQL – для страждущих по классике). Тут важнее не чёткое следование совместимости (в этом нет большой нужды в учётной системе), а куда важнее функциональные фишки и мощные конструкции языка запросов – чтобы эффективно обрабатывать данные, не обращая внимания на то, как они реально хранятся в СУБД, да и вообще где они расположены – в СУБД или в объектной модели.


Основой учетной системы как микросервис я вижу только в интеграции с сайтом, с кассами. Но есть ведь еще много чего. Складской учет, БУ, УУ, логистика. И все это про расчеты, но не про сервисы
.

Во-первых. Я не хотел бы пропагандировать именно модель микросервисов (что Вы к ним привязались). Можно обойтись и без них. Просо это сейчас в тренде – это привлекает. Это даёт гибкости масштабирования и повышения надёжности.

Во-вторых. Говоря о микросервиса можно подразумевать сразу 4 совершенно разных подхода к их использованию:
1. Платформенные фишки. То есть то, как разные технические функциональные блоки платформы интегрируются между собой. То есть то, что обещали сделать в 1С Предприятие 8.4 – но видимо уже забили! Серверная платформа 1С Предприятие 8.3 сейчас и так уже построена на отдельных сервисах, функционирующих и распределяемых по разным серверам кластера. Это здорово. Просто этот механизм можно было бы осовременить, сделав его развёртывание и настройку более привычной для системных администраторов – так как большинство современного серверного софта уже применят именно подход на микросервисах. И много готовых схем и инструментов обеспечения интеграции этих микросервисов друг с другом.

2. Интеграционные фишки. Отчасти уже есть в 1С Предприятие 8.3 – средства, позволяющие гибко интегрироваться прикладному решению с другим софтом – web/http-сервисы, внешние источники данных, средства интеграции, боты. Вот бы ещё больше поддержки популярных шин данных, и костюмных провайдеров.

3. Прикладные фишки. Отчасти реализуются в п.2. но хотелось бы более встроенной поддержки со стороны платформы. Речь о более гибкой системе разнесения частей данных по разным источникам данных вне текущей СУБД. Чтобы, скажем, можно было легко и бесшовной бы вынести общие справочники в другую базу данных (как на платформе 1С Предприятие 8), так и на базе произвольной внешней СУБД (либо со встроенной ограниченной поддержкой текущей платформы (главное что-бы формат структуры данных был поддерживаемым), так и через внешний костюмный провайдер данных – тут уже требуется только поддержка API провайдера данных), так через универсальный REST API протокол). Аналогично, чтобы можно было бы выносит не всю таблицу, а, скажем её часть – например архивные данные – или по заданному разделителю, или только отдельные доп свойства – загружаемые только по требованию. И конечно же, это всё касается не только справочников. А, например, и для данных отчётов или печатных форм. И конечно же должен поддерживаться и обратный процесс интеграции из внешней системы (не только через REST API).

4. СУБД фишки. Ну и самое интересное – это микросервисы внутри СУБД. Возможность писать свои «относительно низкоуровневые подпрограммы» обработки данных внутри СУБД (на поддерживаемом СУБД ЯП, но в идеале – это должен быть универсальный ЯП платформы – транслируемый в ЯП каждой поддерживаемой СУБД). И эти подпрограммы можно вызывать либо через HTTP-сервис, либо прямо в языке запросов – обращаясь к ним как к функциям, в т.ч. как функциям-источников данных.
Сюда же хочу отнести и возможность легко обращаться к серверным функциям прикладного решения через механизм микросервисов (не заморачиваясь над обёртыванием этих функций в HTTP-сервисы).

И сразу скажу – что обычно работа с микросервисами подразумевает асинхронный режим взаимодействия; и распределённый режим взаимодействия (когда вызов может быть обработан разными физическими серверами, как параллельными, так и резервными). Вот этого по всем пунктам не хватает сейчас 1С Предприятие 8.3.

работаем с тем, что есть и в целом, мне нравится


Вот так и работаем. Смирились и стараемся получать удовольствие. Продолжаем жрать засохший колючий кактус! Кто-то по-прежнему верит, в то, что ему это всё ещё нравится. Сила самовнушения, и заядлый консерватизм – боязнь перемен. Это обычно возрастное.

Но мне текущее положение дел не нравится!
30. buganov 200 14.10.21 10:50 Сейчас в теме
(29)
возрастное
Согласен. Будучи молодым и неопытным я так же бил хвостом оземь, махая шашкой и выдавая идеи. Тут сломать, тут кардинально поменять, тут выкинуть переписать. Все, что Вы описываете, это, конечно, прикольно, но на уровне прикольно и заканчивается.
И Вы снова написали очень много и снова не в степь бизнеса. Вы про SAP Hana то прочли, что он поставляется вместе с ОГРАНИЧЕННЫМ набором оборудования? Много фирм готовы на такое?
Справочники в кеш? Документы в кеш? Ну-ну. Попробуйте закешить хотя бы 100Гб а потом мы вместе посмеемся над результатом. Расскажите про справочники любой страховой компании, и про документы любой торговой сети.
П.2. Рассказать анекдот про таблетки от жадности?
П.3. Все это Вы можете сделать и сейчас. А бесшовно как Вы себе представляете, если структура разная? По правилам? А в чем тогда профит, если сейчас то же самое?
П.4. СУБД фишки и причем тут 1С, если она СУБД не занимается?
И не совсем понял аналогию с кактусом. Если так не нравится 1С, что Вы тогда тут забыли? В мире полно крутых и модненьких ЯП со смузи и барышнями. Только вот 1С это про бизнес. И запомните уже, конфигуратор не ОСНОВНОЙ продукт фирмы 1С. 1С не JetBrains, который пилит инструменты разработки и зарабатывает этим. 1С пилит конфигурации для бизнеса и какую то часть выдает сахар для разработчиков. Но если 1С сосредоточится именно на конфигураторе, то может потерять в конфигурациях, а это потенциал роста в среде бизнеса.
Если для Вас лично это не очевидно, то я просто предлагаю демагогию свернуть и остаться при своих.
31. Darklight 32 14.10.21 17:51 Сейчас в теме
(30)
И Вы снова написали очень много и снова не в степь бизнеса.

Не знаю, почему Вы так считаете. Да, наверное, в основном, всё что я написал мелкому бизгнесу не нужно - это больше крупнякам. Но.... мелкий бизнес в будущем в больше степени будет пользоваться услугами крупняков - так что его это, хоть, и косвенно, тоже касается. Что до среднеразмерного бизнеса - то тут судить по Российским меркам сложно в силу осбых Российских специфик. Что до западного рынка - там свои специфики и я их не знаю, но думаю, там указанные фишки могли бы прийтись по вкусу бОльшей части среднего бизнеса.
Многое из сказанного - это в область облачных технологий и сокращения персонала - и, как следствия, сокращение издержек - а об этом мечтает любой владелец бизнеса - главное суметь ему это грамотно маркетингово преподнсти!

Вы про SAP Hana то прочли, что он поставляется вместе с ОГРАНИЧЕННЫМ набором оборудования? Много фирм готовы на такое?

Да не говорю я про SAP. То что там завязка на оборудовании - по больше части маркетинговые фишки. Но да, SAP HANA безусловно более придирчива к некоторым аспектам железа (в целом, а не по тем, кто оплатил "SPA Совестимо"). Но - я привёл SAP Hana просто как некий пример - того что уже есть. Есть другие системы, менее известные, или более специализированные - там нет таких требований (но есть, конечно свои).
Я Вам так скажу
- Если бы софт не дёргал железячников - то до сих пор, наверное под ДОС/Линукс на 32битных процессорах работали, с экранами 17'' в лучшем случае
- Многие указанные мной фишки безусловно сейчас весьма революционны - но я не ратую за то, чтобы внедрять их прямо сейчас - ИМХО - период внедрения - вторая половина XXI века - но думать об архитектуре будущего нужно уже сейчас - такие серьёзные вещи "с кондачка" не делаются
- Говоря про развитие платформы 1С Предприятие - почти всё что я тут имел в виду всё-таки лучше относить к гипотетической платформе 1С Предприятие 9, выпускать которую ранее середины века особо смысла вообще нет.
И я бы вообще сделал бы, на месте менеджеров из компании 1С так - я н стал бы активно заменять платформу 1С Предприятие 8 на 9 (как было с компанией по замене 7.7 га 8) - я бы выкателил новую платформу - как совершенно новый продукт, НЕ ШИБКО КОНКУРИРУЮЩИЙ с платформой 1С Предприятие 8 (которую так же продолжил бы неспешно развивать).И позиционировал бы 1С Предприятие 9 (или вообще дал бы совсем другое название и новую нумерацию - например 1С Процессинг 2050) как систему более высокого класса - для тех, кто дорос до инноваций и сокращению издержек! А 1С Предприятие 8 осталась бы в качестве продвинутого Экселя/Аксеса, как пережиток XX века.
Даже модель лицензирования новой платформе бы вкорне поменял бы (вариант в 1С Предприятие 8 считаю уже изжившим себя).

Справочники в кеш? Документы в кеш? Ну-ну. Попробуйте закешить хотя бы 100Гб

Я чего-то не понимаю? Зачем это всё кешировать в таких объёмах. Кеш он на то и кеш - что там только горячие данные.
Ещё я говорил об оперативном учёте "In memory" - да это требует некоторого количества памяти. Но память как раз нынчне не такая уж дорогая - и иметь на сервере несколько сот гигов ОЗУ не проблема (и более терабайта в нескольких кластерах). Мелкому бизнесу такие объёмы и не нужды будут. Да и отключить можно - я же написал, что это всё должно быть настраеваемым. А если понадобится - а денег нет - добро пожаловать в облака!
Поэтому In memoru databases сейчас так сильно стали набирать оборот - нет дефецита на память - а прирост скорости колоссальный! И тем более я говорю про гибридное хранение! Классификаторы и холодные данные вообще отлично сжимаются в памяти при колоночном хранении.

Расскажите про справочники любой страховой компании, и про документы любой торговой сети.
Рассказать анекдот про таблетки от жадности?

Не понимаю, что Вы имеете в виду?

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

Сейчас не то же самое. Скажу кратко - я представляю себе модель работы с данными в виде Источник данных (он же может быть приёмник, это будем подразумевать тоже), например, таблица "Справочник.Номенклатура" - нужно определять как Сервис - т.е. для алгоритма это абстрактная прокси-сущность (по сути сейчас тоже так есть), извне не известно как она устроена внутри. На её работу влияют настройки. Можно в метаданных её настроить так - чтобы фактически данные ссылались на другой Источник (в т.ч встроенный, в т.ч. автогенерируемый - если нужен классический подход в виде таблице в СУБД; в т.ч. с возможностью скомбинировать между собой несколько Источников), или на какой - Провайдер данных - который может реализовывать некую произвольную логику доступа к данным (в т.ч. встроенный Провайдер данных - который может реализовывать логику доступа через HTTP-Сервисы, или какие-то другие встроенные каналы). При этом внутренний механизм платформы выполнит локальное кеширование данных, по-необходимости. Может так же реализовать и схему когда часть данных локальна, часть через в другом Источнике. Может реализовать схему отложенной синхронизации - когда локальные данные асинхронно отправляются в удалённый Источгник. И т.п.
И всё - это просто настройки. Для прикладных алгоримов всё это происходит за кадров. И настройки могут меняться, а алгоритмы будут работать.
Тем самым - в группе компаний можно вынести весь справочник "Номенклатура" или его часть в отдельную базу - и там его хранить. Не дублируя его в десятках баз. И не особо теряя в производительности - за счёт кеширования, а так же за счёт умных AI алгоритмов, которые будут предсказывать какие данные будут вероятно востребованы далее - и кешировать их локально.

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

СУБД фишки и причём тут 1С, если она СУБД не занимается?

По сути эти фишки уже есть в ряде СУБД - их просто нужно поддержать извне (ну и унифицировать поддержку).
Ну... и может в будущем 1С в коллаборации с другими вендорами - выкатит и свою СУБД - чем черт не шутит! Уверен - они давно об этом думают! Она им была бы очень кстати.

И не совсем понял аналогию с кактусом. Если так не нравится 1С, что Вы тогда тут забыли?

Я не говорил, что не нравится. Кактус пока ещё вкусный - но колючий и подсохший.
И я не пропагандирую за отказ от платформы 1С. Я пропагандирую за то, чтобы сообщество больше уделяло внимания тому, что платформе "1С Предприятие" давно пора стать ещё лучше!

1С пилит конфигурации для бизнес

Да не так уж много она пилит конфигураций для бизнеса. Скажем так - для этого у неё есть партнёры (в т.ч. которыми она владеет) - конфигурации пилят в основном они.
И зарабатывает 1С в основном не на этом. А на продажах лицензий на платформу и за услуги магазина-издателя-посредника, ну и с поддержки клиентов некоторый барыш имеет (хотя как раз эти доходы в основном идут на оплату аутсорсе и содержание дочерних компаний)

З.Ы.
Да и сами конфигурации не особо то и развиваются (кроме ргел. учета) - видимо очень много сил уходит на сопровождение этих жутких монстров, так не похожих друг на друга - а ещё и постоянно переписываемых.
Когда я смотрю на типовой код мне страшно - за людей которые это писали и это сопровождают!
Столько сил в пустую уходит у них!
Вот перешли бы на новые технологии платформы - себе же жизнь бы упростили!
7. amd1986 30.09.21 15:29 Сейчас в теме
(5)
(5)
Вот поэтому старый язык и не проходит дальше естественный отбор как и неповоротливые прогеры которых заменят молодые. 1с давно уже не только платформа для бухгалтеров. Продукту нужна эффективность

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

(5)
Трудозатраты на больших проектах существенно снизятся

За счет чего?

Читаемость кода сильно улучшится

Видя синтаксис - читаемость хуже. Скорее нужно меньше печатать символов. Но это не улучшение читаемости, а лень.

а передавать это занятие пользователям и продолжать сидеть на небольших проектах


Скорее в платформе будет сразу два языка. Один для фронта, другой для бэка. Но хорошо ли это.. Но факт в том, что бизнес будет платить больше, точнее конечные потребители.
Sashares; +1 Ответить
10. Darklight 32 01.10.21 11:23 Сейчас в теме
(7)
Скорее в платформе будет сразу два языка. Один для фронта, другой для бэка. Но хорошо ли это.. Но факт в том, что бизнес будет платить больше, точнее конечные потребители.


Я бы вообще 5 языков бы ввёл:

1. Алгоритмический (со статической типизацией) - для описания работы алгоритмов (на относительно низком уровне) - позволяющий проводить низкоуровневую статическую оптимизацию, и высокую интеграцию с платформой и внешними кистемами/компонентами

2. Декларативный (абстрактный) - для обобщённого описания процессов, без вникания в детали реализации конкретных блоков обработки данных - позволяющий больше оперировать описанием того, что надо сделать, с сокращением внимания к деталям как это сделать и над чем это надо сделать - такие инструкции должен орбрабатывать AI - и переводить их (после финальной сборки всего решения и максимально возможного определения структуры данных и вызываемых алгоритмов) через кодогенерацию в инструкции алгоритмического языка - который далее уже компилируется под целевую платформу

3. Язык запросов - думаю стоит пока выделить это в отдельный встроенный ЯП (хотя считаю, что декларативный язык вполне себе может его заменить - просто генерируя на выходе инструкции на языке запросов СУБД, но для упрощения вхождения программистов я бы его оставил) - но это уже должен быть не текстовый язык - а по-настоящему интегрированный в IDE язык - что-то типа C# LINQ - и универсальный - обрабатывающий как внешние источники данных (СУБД) так и объектную модель (всё так же на уровне кодогенерации в инструкции целевой платформы) с единым синтаксисом. И единый для запросов к данным и к построению отчётов а-ля СКД.

4. Можно отдельно ввести и фронтэнд ЯП - но тут есть нюансы - во-первых, первые два ЯП вполне себе могут быть удобны и для фронтенда (при наличии соответствующих фронтэнд библиотеки и нужной степени интеграции), сейчас вообще тенденция смещения фроентенда в сторону Webassembly и программирования классическим путём на классических ЯП. Поэтому тут имеет смысл в отдельном ЯП только если он даст либо расширенное максроуправление дизайном выходной формы - как Razor/Blazor/REACT/VUE... статическое и динамическое - с кодогенерацией. Либо просто это будет JavaScript - как нативный фронтэнд язык в WEB - для тонкого клиента можно добавить его поддержку

5. Язык машинного нелинейного программирования - можно рассмотреть как задел на будущее и уже нынешние тенденции - специальный синтаксис, упрощающий программирование нечёткой логики для AI систем анализа и обработки данных. Ну тут понятно - что это весьма специфическая область программирования и ей нужен спецефический и достаточно универсальный язык программирования - если поддержка такой области будет заявлена в будущей платформе - а без неё, честно, на мой взгляд, не стоит и начинать новую платформу, если она выйдет не ранее середины этого века (ну а ранее её уже и нет смысла выпускать - если говорить о действительно новой, революционной платформе)
15. amd1986 01.10.21 14:13 Сейчас в теме
(10) На текущий момент для 1С это нереально. В будущем, возможно. Только не на уровне фирмы 1С, а на уровне технологического кластера.
16. Darklight 32 01.10.21 14:20 Сейчас в теме
(13)
Как Вы себе представляете освобождение блокировки внутри транзакции? И как должна повести себя система в таком случае, если транзакция еще длится, а незакоммиченные данные уже свободны для изменения? А если будет в конце * транзакции?

Конечно, я имел в виду не платформу 1С Предприятие 8. А именно вариант развития учетной платформы в будущем - если компания1С созреет до очередной революционной платформы, где-то ко середине века.
Ну или это может быть актуально для планирования архитектуры совершенно иной платформы, вне семейства 1С.
Я просто привёл соображения на тему того, что в составе учетной платформы вполне себе может быть несколько ЯП разного назначения. С одной стороны это усложняет разработку решений под такую платформу. С другой - как раз наоборот - позволяет более чётко структурировать навыки и разделять задачи по разным концептуальным направлениям - и не пытаться микроскопом забивать гвозди, а кувалдой крутить гайки!

А что можно было бы реализовать в рамках платформы 1С Предприятие 8 я написал в посте (8) чуть ниже данного.
И это далеко не всё, что можно было бы внедрить уже в 8-мой платформе, не ломая концепцию вцелом (хоть и идея достаточно революционна для данного 8-го поколения платформы). А только некоторая часть, и только по ЯП

А вот Вашу мысль про технологический кластер, который вне уровня компании 1С, я вообще не понял
8. Darklight 32 01.10.21 11:04 Сейчас в теме
(4)Я бы к существующему строгую типизацию прикручивать бы не стал, тем более, если говорить об эволюции языка в 1С Предприятие 8.
Но, вот сделать контрактные аннотации - можно было бы (примерно как это сделано в ЯП с без строгой типизации Python) - то есть возможность (например, аннотациями) снабжать функции/параметры функций (и возвращаемое значение) метаинформацией о допустимых типах (отчасти это уже есть в ЯП 1С Предприятие 8, и отчасти поддерживается EDT - но только на уровне всплывающей быстрой подсказки, и делается в особом формате формирования комментарии заголовка функции).
Тут возможны два уровня реализации:

1. Информативный - только статический в IDE - как сейчачас в 1C EDT - просто информация в всплывающей подсказке, но можно расширить возможностью автогенерации справки (и поддержки её в синтакс-помошнике), а так же статической проверкой синтаксиса - когда можно явно вывести типы реальных аргументов и определить, что они не соответствуют разрешённым - то выдавать предупреждения (ошибки). Ещё эту информацию можно было бы применять в системе юнит-тестирования.

2. Контрактный - как минимум более чёткое проведение юнит-тестов и работа в отладочном реже со встраиванием проверки типов аргументов и возвращаемых значений в реальном времени (и выдачей ошибок некорректных аргументов в месте вызова, а в месте размещения функции). Но можно, опционально, разрешить такой контроль вне отладочного режима (просто такие проверки снижают производительность).

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

Размещать аннотации можно 4 путями:

1. По классике (но это уже устарело в мировом тренде, хотя пока принято в 1С) - размещение специального формата комментария в заголовке функции, с управляющими конструкциями - сейчас ограничено это умеет использовать 1С EDT

2. В виде специальных аннотаций к определению функции (в её заголовке) - где специальными директивами компиляции связывать имя аргумента (или возвращаемое значение) с описанием допустимого типа. Аннотации в 1С начинаются с "&" параметры привязки можно передать внутри аргументов этих аннотаций в круглых скобках

3. В виде специальных аннотаций к описанию параметров функции (и к самой функции для возвращаемого значения)- где специальными директивами компиляции связывать имя аргумента (или возвращаемое значение) с описанием допустимого типа (отличается от предыдущего местом привязки аннотаций - здесь в разделе определения каждого аргумента)

4. В виде специального ключевого слово (например, как в некоторых других ЯП - "when" ("когда") или "where" ("где")) - размещаемого в заголовке функции (в 1С - вероятно в месте, где указывается "экспорт") - за ключевым словом можно размещать выражение стандартного условия проверки аргументов (как в секции "если") - отличие будет только в том, что можно будет более эффективно указывать проверку на составные типы, проверка будет стараться по возможности отрабатывать статически на стадии компиляции, рантайм проверка будет встраивать (при компиляции) не внутрь функции, а в место её вызова (стандартная практика контрактной парадигмы), эти данные можно будет получить при доступе к метаданным (правда пока в 1С Предприятие 8 нет поддержки метаданных (то что принято в других ЯП называть рефлексии) для функций, а жаль).

Описывать типы я бы предложил более компактно, чем сейчас в 1С Предприятие 8 - например так (в виде литерала-типа)
Простые: 'Строка', 'Число(10,,ДопустимыйЗнак.Неотрицательный)', 'СправочникССылка.Номенклатура'
Составные: 'СправочникССылка.Номенклатура | СправочникСсылка.НоменклатурнаяГруцппа', 'ОпределяемыеТипы.БизнесПроцесс'
Хотя вот так мне тоже нравится: {СправочникСсылка, ДокументССылка, Строка(100), УникальныйИдентификатор}
И для проверки или определение на тип сделал бы отдельный оператор ":".
Ну и расширение на возможность значения "неопределено" - "?"
Итого, пример:

функция Типизированная( а : 'Строка',
б : 'Строка(10) | Число(10,2)',
в : 'СправочникСсылка.Номенклатура | СправочникСсылка.НоменклатурнаяГруппа?' ) : 'Число?'

возврат КакиеТоВычисления(а, б, в);
КонецФункции

С рантайм проверкой будет примерно такое определение

функция  Типизированная( а, б, в)

     __$результат =  КакиеТоВычисления(а, б, в);
     __$результатТипЗначения = ТипЗнч(__$результат);
     Если  __$результат <> НЕОПРЕДЕЛЕНО И __$результатТипЗначения <> Тип("Число") Тогда
          вызватьисключение __$ВстроенныеФункции.ПолучитьИсключениеКонтроляВозвращаемогоЗначенияФункции(__$результатТипЗначения, Истина, "Число")
     КонецЕсли;
     возврат __$результат;
КонецФункции
Показать


А вызов "рез = Типизированная(10, ВвестиЧисло(), ПолучитьНоменклатуру())" (где тип возвращаемого значения функции "ПолучитьНоменклатуру" не определён) будет такой

__$арг1 = Строка(10);
__$арг2 = ВвестиЧисло();
__$арг3 = ПолучитьНоменклатуру();
__$арг3ТипЗначения  = ТипЗнч(__$арг3);
Если  __$арг3 <> НЕОПРЕДЕЛЕНО И __$арг3ТипЗначения <> Тип("СправочникСсылка.Номенклатура") И __$арг3ТипЗначения<> Тип("СправочникСсылка.НоменклатурнаяГруппа")  Тогда
     вызватьисключение __$ВстроенныеФункции.ПолучитьИсключениеКонтроляАргументаФункции(__$арг3ТипЗначения, "в", 3, Истина, "СправочникСсылка.Номенклатура, СправочникСсылка.НоменклатурнаяГруппа")
КонецЕсли;
рез = Типизированная(__$арг1, __$арг2, __$арг3)
Показать


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

Аналогично - будь возвращаемое значение задано с возможностью неявного приведения (например типом ": 'Строка(100)'") - то оно было бы явно встроено

функция  Типизированная( а, б, в)

     __$результат =  КакиеТоВычисления(а, б, в);
     __$результатТипЗначения = ТипЗнч(__$результат);
     Если  __$ВстроенныеФункции.КонтрольТипЗначения(__$результат,__$результатТипЗначения, "Строка", 100) Тогда
          вызватьисключение __$ВстроенныеФункции.ПолучитьИсключениеКонтроляВозвращаемогоЗначенияФункции(__$результатТипЗначения, Истина, "Строка", 100)
     КонецЕсли;
     возврат __$результат;
КонецФункции
Показать



Итого - по сути, я предложил не такие уж большие изменения в синтаксис текущей реализации ЯП 1С Предприятие 8, сохранив динамическую природу типизации, но дав возможность (с полной обратной совместимостью) указывать типы (только там где надо) и эффективно контролировать их. Всё это можно было бы уже сейчас ввести в языке, например в 1С Предприятие 8.4 (если вдруг оно выйдет когда-нибудь). Можно было бы ввести и в какой-нибудь релиз 8.3.* - так как изменения синтаксиса является его расширение с полной обратной совместимостью (асинхронные вызовы же так ввели).

Такому подходу правда очень не хватает ещё и чётко типизированных структурных типов (как они определяются в 1С Исполнителе) - но это уже отдельная задача и отдельное расширение синтаксиса - но именно с ним бы данное предложение по типизации обрело бы свою ключевую мощь - когда можно было бы статически описывать сложные структурные форматы данных и статически (и динамически) их проверять при обращении к функции (да и в обычных выражения условий ветвления тоже).

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

Ну а следующий этап - это уже повышение качества генерации и ветвления кода (желательно статического, а не только рантайм)
17. starik-2005 3013 01.10.21 14:26 Сейчас в теме
Блин, исполнитель уже ООП. Вот жеж...
21. Darklight 32 01.10.21 16:48 Сейчас в теме
(17)Пока я не вижу тут ООП (только древний турбо паскаль + немного лямбд и нулабелсейфти) - где Вы узрели краеугольные камни ООП: абстракция, инкапсуляция, наследование и полиморфизм; а ещё репрезентативность т.е. поддержка API разных интерфейсов)? Не говоря уже о том, что современный ООП - это куда больше данных базисных принципов
23. starik-2005 3013 01.10.21 22:12 Сейчас в теме
(21) ну конструкторы у классов уже появились, типы как в С++ для простых коллекций. Думаю, что инкапсуляцию, которая и в текущей 1С есть, тоже сделали. Полиморфизм и так был искаропки, т.к. это высокоуровневый интерпретируемый язык. Ну а наследование - тоже скорее всего есть т.к. это просто вызов метрда родительского класса и сборка класса на основе других классов.

По поводу API "разных интерфейсов", то тут стоит в принципе определиться, нужны ли здесь интерфейсы (абстрактные классы)? Или что имеется ввиду вообще?
24. Darklight 32 04.10.21 09:56 Сейчас в теме
(23)
Думаю, что инкапсуляцию, которая и в текущей 1С есть, тоже сделали

Что Вы имеете в виду? Мне на ум приходят только объекты метаданных 1С Предприятие 8 - у которых "формально" можно считать, что есть инкапсуляция. В 1С Исполнителе ничего подобного я пока не вижу (но может я что-то не знаю). Конструкторы внутри структур - это, всё-таки, не совсем инкапсуляция. Да и сейчас, в современных ЯП вообще стараются прививать конструкцию объектов через неявно определяемые и анонимные конструкторы.

Полиморфизм и так был искаропки, т.к. это высокоуровневый интерпретируемый язык

Вообще не понимаю что Вы имеете в виду?
В 1С Предприятие 8 полиморфизм отчасти есть благодаря систем Расширений конфигурации. Но это очень условно - так как сам механизм Расширений конфигурации ну уж очень специфичен и ограничен.
Пожалуй всё (перехват событий не в счёт).
В 1С Исполнителе я пока никакого полиморфизма не наблюдаю.
То что язык высокоуровневый и интерпретируемый -никакого полиморфизма в ЯП не привносится

Ну а наследование - тоже скорее всего есть т.к. это просто вызов метрда родительского класса и сборка класса на основе других классов

Моя Вас совсем не понимать!


По поводу API "разных интерфейсов", то тут стоит в принципе определиться, нужны ли здесь интерфейсы (абстрактные классы)? Или что имеется ввиду вообще?


Не хочу говорить об Интерфейсах как об абстрактных классах как это всё зарождалось в С++, поддерживающим множественное наследование.
Я больше воспринимаю Интерфейсы как элементы контрактного программирования, хотя сейчас в актуальных ЯП они снова начали тяготеть к множественному наследованию.
Но всё-таки для меня Интерфейс - это больше контракт на предоставление унифицированного API, и элемент проверки на поддержку тех или иных возможностей.
Так же, его можно считать элементом абстракции - когда за приведённым к Интерфейсу объектом может скрываться всё что угодно и пользователь Интерфейса, условно, не знает что там на самом деле, и как вообще будет осуществляться обращение к этому объекту. То есть Интерфейс - это ещё прокси-посредник.
Интерфейс это ещё и элемент полиморфизма - так как у объекта напрямую может быть один API, с одной реализацией, а после получение из него Интерфейса - совсем другой API (изначально, возможно, скрытый) или такой же - но с другой реализацией. И это очень мощная вещь.
Ну а, последние тренды, Интерфейс - это ещё и элемент наследования - я имею в виду то, что называют реализацией (функциями, хотя ещё и свойствами) по умолчанию.

Интерфейсы - это лучшее, что породила ООП. И в 1С их нет, хотя они бы дали очень многое!
Как и хелперы-расширители API - но это уже другая тема
Оставьте свое сообщение

См. также

Онлайн-интенсив по платформе «1С:Предприятие» для начинающих 1С-программистов

Новость Обучение Программист

12 марта стартует онлайн-курс по изучению механизмов платформы «1С:Предприятие». Программа обучения подготовлена для слушателей, у которых уже есть некоторые навыки и знания по программированию и конфигурирования в системе «1С:Предприятие».

сегодня в 12:00    80    AnastasiaKl    0       

1

Открываем первый тур голосования за доклады и мастер-классы

Новость Aнализ&Управление Мероприятия

Сегодня стартует первый тур голосования за доклады и практические активности конференции «Анализ и управление в ИТ-проектах».

сегодня в 10:30    152    eselyanina    0       

2

«1С:Налоговый мониторинг»: новое имя продукта и модули для БП и ERP в составе основной поставки

Новость Новый релиз

Фирма «1С» изменила наименование решения для автоматизации налогового мониторинга, а также добавила в состав поставки модули для интеграции с 1С:ERP и 1С:Бухгалтерией 8.

сегодня в 09:37    156    ЕленаЧерепнева    0       

2

РежимЗамещения в 8.3.26: новый режим «Обновление» и применимость для регистров накопления

Новость Зазеркалье

В платформе 8.3.26 системное перечисление «РежимЗамещения» получит новое значение «Обновление» и сможет применяться, в том числе, для регистров накопления и подчиненных регистров сведений.

вчера в 13:48    502    ЕленаЧерепнева    1       

2

Представляем хедлайнеров конференции «Анализ и управление в ИТ-проектах»

Новость Aнализ&Управление Мероприятия

Уже завтра 27 февраля стартует голосование за заявки на доклады и мастер-классы: можно будет проголосовать за наиболее интересные для вас заявки и поддержат спикеров.

вчера в 12:30    255    eselyanina    0       

3

Итоги вебинара 1С-Отчетность: ответы на самые интересные вопросы

Новость Отчетность Сервисы ИТС

На бесплатном вебинаре по 1С-Отчетность мы рассказывали о новых ключевых возможностях системы: многопользовательский режим; формирование машиночитаемой доверенности (МЧД) в 1С-Отчетность; интеграция сервиса с личным кабинетом ФНС для контроля ЕНС.

вчера в 10:15    210    AnastasiaKl    1       

1

Как определить, что вашему 1С:ITIL нужен веб-портал

Новость

Представьте, что можно работать в конфигурации 1С:ITIL, даже если на вашем устройстве нет установленной платформы 1С. Функциональность решения при этом не ограничивается: пользователь может создавать обращения и управлять ими в быстром и интуитивно понятном интерфейсе.

22.02.2024    624    user997184    3       

3

Вебинар по Оркестратор 1С: делимся результатами встречи и ответами на вопросы слушателей

Новость

Бесплатный онлайн-вебинар «Единый центр мониторинга и логирования 1С систем» прошел 13 февраля. Спикер вебинара и разразработчик Оркестратор 1С Дмитрий Круглов рассказал о ключевых возможностях готового решения, какие задачи оно решает, и продемонстрировал работу программного продукта.

22.02.2024    869    AnastasiaKl    0       

16

О чем вы узнаете на митапе «1С в облаке: возможности и риски, решения и кейсы»?

Новость Мероприятия

15 марта в 11:00 мск пройдет бесплатный онлайн митап «1С в облаке: возможности и риски, решения и кейсы». Модераторы рассказали о том, зачем участвовать в митапе, какую пользу получат участники мероприятия.

22.02.2024    446    eselyanina    0       

16

Осталось 7 дней до повышения цен на участие в конференции «Анализ и Управление в ИТ-проектах»

Новость Aнализ&Управление Мероприятия

Успейте купить билеты по более выгодным тарифам: благодаря високосному году, времени на решение у вас чуть больше. А мы вам поможем с аргументами в пользу покупки и визита в почти летний Санкт-Петербург.

21.02.2024    579    user997184    0       

16

Infostart Toolkit 2024.1: новые инструменты и интеграция с полем глобального поиска

Новость InfostartToolkit Маркетплейс Новый релиз Обзор готовых решений

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

21.02.2024    1730    vikad    6       

16

Внимание, конкурс! Современные возможности 1С: нетиповые интеграции и доработки

Новость Сообщество

Конкурс статей и доработок на платформе 1С. Цель конкурса – показать, какие нетривиальные задачи можно решать с помощью функциональности платформы 1С:Предприятие.

20.02.2024    2461    user997184    8       

20

Приглашаем принять участие в бесплатном вебинаре на тему «Автоматизация процессов производственной лаборатории»

Новость

Онлайн-вебинар по автоматизации процессов производственной лаборатории состоится 29 февраля. На встрече мы расскажем, как эффективно управлять качеством продукции на производстве, применяя возможности 1С:LIMS.

20.02.2024    634    AnastasiaKl    0       

3

В УНФ и Рознице 3.0 поддержан разрешительный порядок продаж для маркировки

Новость 1С:Розница 3.0 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 ИТ-Новость

С 1 апреля без проверки в ГИС МТ «Честный знак» продавать некоторые категории маркированного товара на кассе будет нельзя. Рассказываем, как реализована поддержка новых требований в УНФ и Розница 3.0.

19.02.2024    1258    ЕленаЧерепнева    8       

5

Онлайн-курс по проектированию интерфейсов 1С в Figma. Старт – 18 марта

Новость Обучение

На курсе по проектированию мы изучим функционал мощного дизайнерского инструмента – Figma и научимся его использовать в разработке дизайн-решений для 1С интерфейсов.

19.02.2024    892    AnastasiaKl    0       

17

Станьте партнером конференции «Анализ и управление в ИТ-проектах»

Новость Aнализ&Управление Мероприятия

Через 3,5 месяца в Санкт-Петербурге состоится конференция «Анализ & Управление в ИТ-проектах». Пока мы работаем над программой и организацией мероприятия, партнеры активно бронируют места под стенды.

19.02.2024    734    eselyanina    0       

15

1С:Бизнес-обучение: новая веб-платформа от фирмы «1С» для обучения топ-менеджеров

Новость Сервисы ИТС

Фирма «1С» анонсировала новый образовательный сервис для руководителей с доступом по подписке. Пользователям будут доступны видеолекции и материалы, посвященные менеджменту и личному развитию. В планах – проведение вебинаров и онлайн-конференций.

19.02.2024    726    ЕленаЧерепнева    1       

2

5 новинок из каталога готовых решений для 1С

Новость Маркетплейс

Инфостарт.Маркетплейс представляет новые готовые решения каталога. Среди них: обработка по отправке отчетов в Telegram, решение по работе с маркировкой, виртуальный терминал по приему платежей по СБП и обработки для работы с табличными частями 1С.

15.02.2024    1469    AnastasiaKl    1       

3

Конференция «Анализ и Управление в ИТ-проектах 2024»: собрали идеи для ваших докладов о продуктовой разработке

Новость Aнализ&Управление Мероприятия

Одна из секций конференции «Анализ и Управление в ИТ-проектах 2024» посвящена управлению продуктом и продуктовой разработке. Модераторы секции «Управление продуктом» – Маргарита Маковеева и Дмитрий Макаров.

15.02.2024    897    user997184    0       

1

Участвуйте в пилотном проекте по Таймлист и упрощайте решение своих ежедневных бизнес-задач

Новость

2 февраля прошло ежегодное в России мероприятие по тайм-менеджменту – праздник «День сурка». Сотрудники Инфостарта побывали на событии в качестве информационных партнеров, и сегодня мы расскажем о пилотном проекте внедрения сервиса «Таймлист».

15.02.2024    1156    AnastasiaKl    0       

16

Бизнес-программисты и гиперавтоматизация: влияние 1С на развитие образования

Новость Образование

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

15.02.2024    745    ЕленаЧерепнева    1       

2

На полпути к 8.3.27: реализация планов и пожеланий для платформы 1С

Новость Зазеркалье

Официальный технологический блог «Заметки из Зазеркалья» опубликовал список основных задач, которые запланированы к реализации в будущем релизе платформы 8.3.27, и анонсировал, какие из задач уже выполнены.

14.02.2024    987    ЕленаЧерепнева    4       

3

Новые возможности 1С-Коннект: для всех пользователей доступны видеозвонки

Новость Сервисы ИТС

Разработчики 1С-Коннект выкатили очередную порцию обновлений для пользователей. Например, чтобы посмотреть на любимых коллег или партнеров, больше не нужно переключаться в Google Meet или Zoom. Организуйте созвоны прямо из приложения 1С-Коннект для компьютера и обсуждайте проекты, не отрываясь от работы с обращениями.

14.02.2024    1661    user997184    1       

19

Онлайн-интенсив по 1С:Предприятию для программистов: старт 12 марта

Новость Обучение Программист

Новой поток курса по изучению механизмов платформы 1С:Предприятие пройдет с 12 по 21 марта 2024 года. За 1,5 недели интенсивного обучения мы научимся с помощью механизма расширения конфигурации адаптировать типовые решения для заказчика.

13.02.2024    901    AnastasiaKl    0       

15

Подводим итоги и делимся видеозаписью митапа «Библиотеки и фреймворки на 1С, и все, что с этим связано»

Новость Мероприятия

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

13.02.2024    986    user997184    2       

4