Ну тут как бы не совсем "Давать жуликам". Мы используем https шифрованные запросы. По этому это не совсем безрассудное решение. А так да, на тот момент нас это устраивало для быстрой реализации, хоть и скрипя зубами.

Да, только на поиск ответов решений и сложение 2+2 в этой доке оказалось не такой уж и простой задачей при условии нулевых знаний PHP. Но опыт получается прикольный))

Примерно так и велась работа с Битриксом...(

Спасибо за комментарий и уточнения. Плюсанул)

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

Понятно что глянуть через Get можно, даже есть такой запрос, но вот вопрос? А как узнать какие в этом загадочном API параметры на вход идут))

https://habr.com/ru/articles/936252/ - уже про api Битрикса выпускал статейку, советую прочитать, что бы понимать с чем имеете дело))

Понимаю))

Такая теория существует

Как же я восхищаюсь вашим комментарием. Аплодирую стоя. Да-да и ещё раз да. Всё это г в упаковке желтенькой современной модной конфетки.
Но я хоть изначально не понимал его сути, его прикола. Но к сожалению или к счастью сейчас понял.

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

Что касается самостоятельных объектов с собственной структурой - ответ позитивный, но с нюансами))). В Элементе вы по-прежнему активно работаете с предметно-ориентированными типами вроде Справочников, Документов и прочих метаданных, которые определяют бизнес-смысл и привязаны к базе данных. Но теперь в языке появилась возможность создавать пользовательские структуры и типы данных, которые не обязательно напрямую связаны с метаданными базы.

То есть вы можете описывать свои структуры с набором полей и методами, создавать объекты этих структур и работать с ними как с полноценными типами.

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

По сути это можно назвать большим шагом к более чистой и масштабируемой архитектуре внутри языка семейства 1С. Это приближает Элемент к классическим ООП-языкам, но до сих пор не тоже самое на 100%.

Для кого это:  Статья адресована тем, кто пишет, а в иделе кто начинает писать код и иногда думает: «Как эта штука вообще работает?» Не академикам, не спецам с большим бекграудом (я и предполагал, что такие и не поинтересуются данной статьёй).

Про Java и хабы:  Статья не про Java конкретно. Она про принцип, как любой высокоуровневый код превращается в машинные команды. Java, Python, 1C - просто примеры. Суть одна: везде между вашим кодом и железом стоят посредники (JVM, интерпретатор, платформа).

Про «винегрет» и структуру: да, это не диссертация по Computer Science. Так и было задумано - в статье с первых строк сказано: «без хардкора, с понятными аналогиями». Если хочется строгой линейности - учебники и спецификации всегда под рукой. А здесь была задача связать в голове «мой красивый код» и «тупое, но быстрое железо» - без скучных переходов.

Но всё равно спасибо за комментарий))

Спасибо, очень круто описал. Читал прям в захлёб.

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

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

Спасибо, отличный комментарий!

Это идеальная утопия, которая разбивается о бизнес-реальность.

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

Реально)))

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

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

Просто, скорее всего IT это больше про призвание и желание развиваться. И тогда только это окупится.