53

Насколько разные "программист" и "программист 1С"?1

Жизнь получилась так, что параллельно с разработкой на моём актуальном стеке Python/PHP/C++/C# + MariaDB/PostgreSQL/Oracle DB пришлось программировать в 1С.

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

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

Начнем с введения про ЯП.

Компьютер понимает только бинарный код, но писать в двоичном стиле:

00010010 00110011 00110010

или хотя бы в 16-ричном

00 AB 9C

смогут, но только единицы на планете. Но проблема в другом - ПО требуется много, а так разрабатывать очень долго. Поэтому придумали программы, которые преобразуют условно понятный человеку язык в понятный ЭВМ бинарный код.

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

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

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

Но... Это прорыв или провал? Парадоксально, но одновременно и то и то.

Чтобы понять прорыв нужно вспомнить такой момент - современная банковская сфера столкнулась с тем, что разработчики основного международного финансового ПО уже практически пенсионеры, а молодежь туда не особо горит желанием идти. Поэтому ситуация там весьма печальная. Как минимум 80% задач в 1С могут решать школьники с 8 класса (по шаблонам в ИТС). То есть дефицита кадров нет и скорее всего никогда не будет.

Чтобы понять провал... Идеала не существует, поэтому достигая прорыва в чём-либо одном нужно провалиться во что-то другое. И этим провалом опять же стал сам язык. Он слишком простой и примитивный.

Давайте копнём глубже.

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

Квалификация:

- выучив 1С программист получает только поверхностные знания о программировании, наиболее сложные моменты остались "за кадром", поэтому полноценным программистом разработчик 1С не является;

- программист, который работает с обычным ЯП знает довольно много трюков, когда небольшая правка "верхнего уровня" (базовых классов) способна сильно упростить код "внизу"... Но не в 1С. Писать тонны кода, когда вопрос можно было решить буквально парой строк в базовом классе... Можно, но психологически напрягает.

Структура кода:

- язык 1С в плане структуры максимально однозначен и примитивен. Это позволяет учить его легко, при этом избежать 90% ошибок (мы помним, что порог вхождения почти отсутствует), из оставшихся в 90% довольно легко понять где возникла проблема и как её решать;

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

Организация работы:

- программисты 1С работают в жестко сформированной среде. Тот же code-style придумывать не нужно, он вшит в язык. Многие вопросы организации проекта так же уже вшиты в синтаксис. По сути для решения задачи из материалов ИТС (или аналогичных ресурсов) нужно либо копипастить код, либо проходить "мастера" написания кода, при этом подставлять в него свои элементы. Любой другой подход скорее всего просто не будет работать;

- программисты других ЯП в этом вопросе очень свободны. В принципе на любом языке 2 и последующих поколений можно писать в почти бесконечном количестве стилей... Что на порядки повышает эффективность одного разработчика, но приводит к тому, что до 90% времени работы над проектом зачастую тратятся на то, чтобы одни программисты понимали написанное другими программистами.

Надежность:

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

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

Общий вывод:

1С является прекрасным (не рискну сказать, что лучшим, но всё возможно) решением, где недостатки платформы не настолько существенны, как её плюсы. Эта сфера - построение бизнес-решений по модели CRUD (C - create - создание, R - read - чтение, U - update - обновление, D - delete - удаление) средствами слабо квалифицированных, но при этом сравнительно легко обучаемых разработчиков.

С позиции типовых требований бизнеса 1С - наилучшее известное мне на сегодня решение.

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

Сейчас я немного обосную вывод на нескольких обобщенных примерах:

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

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

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

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

Рекомендации разработчикам:

1С которые хотят уметь в другие ЯП - если Вы хотите дальше развиваться и заниматься разработкой на других ЯП, то начинайте учить другой ЯП и работать на нём не позже полугода от начала работы в 1С. Чем дольше вы "варитесь" в 1С, тем меньше шансов на то, что сможете оттуда вырваться и не из-за того, что Вы думаете. Над самыми сложными для понимания и реализации задачами уже подумали в самой 1С при реализации платформы, но разработчики в других ЯП над этим должны думать сами. При этом эти задачи требуют в разы больше знаний теории и умения применять её на практике, чем всё, что вложено в 1С. ИМХО раз в 5.

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

1C:Предприятие 8

395 постов4.1K подписчиков

Правила сообщества

В 1С можно всё. Я проверял.

34
Автор поста оценил этот комментарий
ответный пост

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

У меня появилась мечта - чтобы до людей дошло, что именно их работа / инфраструктура / ЯП / стандарты... Это не истинна в последней инстанции. Это не более чем один конкретный случай.

И 1С, это "одна из" технология, со своими + и -. И как и у любой технологии есть места, где она "маст хэв", а есть где вообще не применима.

И что самое страшное... Это - нормально. Так и должно быть. И абсолютно любая технология так же имеет свои сильные и слабые стороны.

Говорить о том, что Х хорошо или плохо умный человек может только В КОНТЕКСТЕ некоторой задачи. А утверждать об ошибке / гениальности / глупости можно только вариативным анализом.

Контекст, ВНЕЗАПНО, может меняться. И вчерашнее гениальное решение сегодня может быть полным УГ. Наоборот - тоже.

И количество установок / внедрений не показатель. Миллионы мух не могут ошибаться?

Есть задачи. Есть инструменты. Есть наиболее отвечающий задаче инструмент, который имеет наилучшие показатели, которые требуют от задачи. Всё. Вот реально всё.

И сейчас я по эстафете передам урок, который мне преподали лет +/- 15 назад. Скорее даже серия уроков.

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

Не буду утомлять, но суть всех задач сводилось к тому, что полное и страшное уёбище в коде / технологии и т.д. и т.п. Работало. Хорошо работало. И хорошо зарабатывало. И SQL запросы на тысячи строк и функции на те же тысячи строк. И полные изнасилования архитектуры приложений.

С опытом появлялись возможности сравнивать и проверять различные тезисы. Так вот - забейте. Просто забейте. Лично мне неизвестно "общепринятое правило" или "лучшая практика", которые не были опровергнуты конкретной задачей.

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

Я не горжусь, но есть такой показательный пример.

Как-то раз прилетела задача, реализовал я которую практически как идеальный пример говнокода. Где без крови из глаз нельзя посмотреть почти ни на одну строчку. Решение делалось "на коленке" нужно было "ещё позвчера". Задачу потом переписали "по стандартам", но... Правильное решение так ни разу в бой не пошло. Почему?

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

Безусловно, что это - исключение. Это ни разу не повод для гордости и больше игра случая. Согласен, что так не надо делать. Да, я всё это понимаю, осознаю и не спорю, но...

Это пример того, что незыблемых истин нет.

Показать полностью
комментарии (22)
1
Автор поста оценил этот комментарий
Ну если даже так, так то "хоть такого" в 1с найти несложно.
А "нормальный" последние годы ушёл в джаву. Раньше помнится был сионистом.
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

По Java спорить не буду, ибо под мои задачи её не воткнуть. Поигрался, познакомился и забыл. Год назад общался с Java разрабом, он жаловался, что конкуренция высокая очень. Правдивость подтвердить или опровергнуть не могу.

26
Автор поста оценил этот комментарий
Кодеров и разработчиков на 1с совершенно не стоит сравнивать.Если ты не понимаешь в бухгалтерии никакое знание синтаксиса тебе не поможет!
раскрыть ветку (1)
3
Автор поста оценил этот комментарий

Собственно это особенность разработчика на любом ЯП. Без понимания матчасти задачи в принципе не решаются.


По сути каждый программист просто делает цифровое отражение какого-либо процесса.


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

показать ответы
3
Автор поста оценил этот комментарий

Запрос в SQL на 6.5к строк нужно распечатать на гофрированной бумаге, свернуть в рулон и засунуть написавшему в жопу, потому как это говно нормально не масштабируется и не тестируется. А 30к строк кода это просто 30к строк кода, можно хуево написать, можно нормально.

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Меня удивляет тот факт, что многие так эмоциональны в том, что противоречит их личному опыту.


На самом деле мест, где SQL-запросы уходят за 1к строк довольно много. И за 10к уходят.


Если лично на вашем месте что-то дико или не принято, то это не значит, что везде так. Ситуации бывают ОЧЕНЬ разные.

показать ответы
30
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Ниже ответил - #comment_282651673


Это неотъемлемая часть каждого разработчика - понимать то, с чем работаешь.

0
Автор поста оценил этот комментарий
Ну и я не говорю сто система идеальная. Подрезка баз все-таки устоявшаяся практика, нравится нам это или нет. Но и идеи "вечной" базы на террабайты я не понимаю. Со временем индексы раздуваются и перестраивать их с каждым апдейтом СУБД сложнее и сложнее. А ради чего? Чтобы дела давно минувших дней в рабочей БД иметь? Чтобы что?
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

1. Аналитика. Обычно она 3 года, но есть сферы, где 3 мало, нужно 5 - 7 (это далеко не предел), причём подрезать ничего нельзя.


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


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


Именно в бух сфере даные старше 5 лет имеют ценность в исключительных случаях и 90% пользователей за всю жизнь не столкнутся с тем, что это понадобится.

0
Автор поста оценил этот комментарий
Я, честно говоря, все еще пытаюсь сообразить о том, зачем вы сливаете все в одну помойку, а потом радостно превозмогаете?! Ведь можно написать или использовать вполне себе существующие линковшики для получения данных и формирования результатов.
Все это выглядит как изначальная ошибка в архитектуре.
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Во-первых сложно планировать рост в Х раз, где Х как минимум двузначный, но скорее всего трёхзначный ;-)

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


С позиции собственника это выглядит так - есть инфраструктура, которая на текущий момент стоит 1 млрд. руб. и зарабатывает 10 млрд. руб. в год. (не знаю сколько точно, но примерно этот порядок). Она - работает. В ней сбой - событие, которое реже квартала и в 100% случаев, это попытка "улучшить".


И тут является кто-то и говорит "у вас неправильно, нужно переделать"... Возникают вопросы:

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

- а что будет в итоге? Переписали. Какие плюсы будут? За что собственник будет платить?


Вкладывать как минимум десятки миллионов в то, чтобы у сотрудника было чувство, что "всё по фен-шую"?


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


Менять? Чтобы что?

показать ответы
0
Автор поста оценил этот комментарий
Не согласен с тезисом про "малый и средний бизнес".

Продукты от 1С уже давно присутствуют в большом бизнесе (даже в очень больших холдингах) и работают вполне успешно.
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

На самом деле смысл в другом.


Например, есть инструмент "1С Бухгалтерия предприятия КОРП". Для решения задачи "ведение бухгалтерии холдинга" - круто, лично я на 99% уверен, что это лучший вариант. Писать что-то своё смысла в принципе не имеет т.к. потратив Х времени и дохера денег получится + / - то же самое (поэтому, кстати, новые ОС и не появляются).


Но для решения задачи "аналитическое хранилище для OLAP" (не то, что для крупного холдинга, а для даже для нижней части среднего бизнеса) использовать ту же "1С Бухгалтерия предприятия КОРП" - терминальный идиотизм. Просто потому что во-первых  просто работать не будет (из-за технических ограничений), во-вторых прописать всё что нужно в хранилище на BSL (это ЯП 1С) будет сильно дороже и дольше, чем на типичном для этой задаче Python.

показать ответы
Автор поста оценил этот комментарий

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

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Жаль, что нельзя дать вам доступ к запросу и инфраструктуре. Показали бы мастер-класс (нет).


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


Сама база на десятки ТБ, в некоторые таблицы заходит больше 100к строк кода в час. 24/7.


Практически каждый, кто приходит туда на работу так же пытается "нормально переписать", но...


Это не работает. Любые попытки "оптимизации" делают сильно хуже, как минимум по скорости выполнения.


И руководство там хочет чтобы работало, а не "было правильно".


И вот дилемма. Рабочее говно или не рабочее "правильное" решение.

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

Вот только цикл твой будет работать на несколько ПОРЯДКОВ дольше, чем SQL-запрос.

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

И да и нет.


Да в том, что нормально работать с СУБД могут очень немногие и под словами последнего абзаца готов подписаться полностью.


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


Например, если есть кластер серверов, нужно дать им команду обновления, а данные доступа лежат в csv, то именно проход по файлу в цикле будет самым быстрым.


Задача решает.

2
Автор поста оценил этот комментарий

ты п - пи**бол. прости господи.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Ну ок. Вот сейчас нужен спец Py+PL/SQL. Главное требование, чтобы сложные запросы не вешали БД в таблицах которой до пары миллиардов строк и мог собирать в одну витрину связку по Py и PL/SQL. За 2 года нашли условно одного, но и его приходится местами учить. Готового специалиста нет в принципе.

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

Скажем так, есть области, где "нужно уволить, но вообще некем заменить", это скорее правило.


А этот "нормальный" в какой области/ЯП?

показать ответы
0
Автор поста оценил этот комментарий
@astrobeglec, что думаете насчёт HDL-языков? (VHDL, Verilog, SystemVerilog)? Имхо это "очеловеченная работа с бинарным кодом".
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Не работал с ними. Так что ничего не скажу.

показать ответы
5
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Эмм... Как вы пришили "могильщика 1с"? В посте вообще-то прямо написано, что в его области у 1с нет конкурентов.

показать ответы
0
Автор поста оценил этот комментарий

Собираются из чего попало, но потом все равно в любой bi системе структурируются и хранятся в кубах как надо.

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

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Извините, но вопрос - а на чём вы пишете, что на Py переписывается в 10 раз дольше?

0
Автор поста оценил этот комментарий
Я 1с занимаюсь давно, как раз со стороны заказчика. То что вы пишете, это прямая задача команды внедрения - продать красивые отчёты и таблицы. Иначе как убедить бизнес начать проект? А когда начинается эксплуатация, проходит год, два, данных становится много и тот красивый отчёт формируется не 2 секунды, а несколько часов, начинаются вопросы, но не команде внедрения, а команде эксплуатации. Производительность 1с на больших данных - базы от 2 ТБ - и большом количестве пользователей - от 1000, оставляет желать лучшего. Это не только мое мнение, но и большинства коллег из других крупных компаний. Однако альтернатив в текущих реалиях нет и не предвидится в обозримом будущем.
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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


Пользователей больше 2к, база больше 3ТБ Решение с которого переходили грузило в пике сервер на 30 - 40%, время выполнения основных операций - секунды, 1С сразу в 100% причём всё - ЦП, ОЗУ, диски. Простое открытие документа до 2-х минут. Руководство посмотрело и сказало "нахуй".

1
Автор поста оценил этот комментарий

"аналитическое хранилище для OLAP" делается с помощью инструмента 1С:Аналитика, к которой можно прикрутить и бухгалтерию, и зарплату, и даже данные из внешних систем не на 1с.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Думаю, что вы просто не в теме ;-)


Смысл в том, что с OLAP (в контексте 1С) основных проблем две:

- данные обычно собираются из "чего попало";

- данных очень много.


До некоторого уровня 1С по производительности справится, выше - чисто физически нет. В БД которую генерит 1С данные хранятся в своём формате, что сильно влияет на производительность. Писать интеграции на 1С сильно дольше, чем на стандартном для ETL Python. В итоге 1С:Аналитика будет настраиваться сильно дольше,  в разработке и в эксплуатации сильно дороже и работать будет гораздо менее стабильно. Плавали, знаем.


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

показать ответы
0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Потому что почти все отчеты это требуют, да и просто в коде получить объект через запрос бывает проще, чем другими способами.

0
Автор поста оценил этот комментарий
Отчёты вообще не обязательно из olap.

Ни разу ни на одном крупном ERP внедрении не видел чтобы понадобилось какое-то внешнее OLAP хранилище.
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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


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


Лично мне мозгов на понимание OLAP не хватило. Я работать с ними могу, но уровень вообще не тот. Но наблюдал работу тех, кому понимания реально хватило. Очень впечатляет, когда "покрутив кубы" дается команда "Ивановой И. И. выплатить з/п за 6 месяцев и уволить". На звонок из кадров следует объяснение, что человека в возрасте и у него хроническое заболевание, так что нефиг его мучить на работе. Если вылечится, то пусть снова приходит устраиваться.


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


Причём такой результат, это именно результат профессиональной работы с OLAP, потому что после заболевания показатели работы сотрудника изменились. И по этим изменениям было сделано заключение (мне показали как). Просто по отчетам это не понять, это просто другой уровень.

0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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


Как-то раз поднимал железки, году в 2009 - 2010-м. Каждая железка работает с БД, которую нужно поднимать на отдельном выделенном сервере.  На сервере ничего, кроме БД и ssh ничего не должно быть. Даже агентов мониторинга. Потому что не хочет работать. IP железки и IP сервера строго прописаны и зафиксированы.


Говно? С позиции ИТ-специалиста - безусловно, да. Вообще спорить не буду, ибо сам так считаю. Зашивать IP намертво в прошивку у серийной модели без возможности смены настроек, это полный пиздец. "Нежный" код, которому мешает даже клиент Заббикса на сервере - это тоже пиздец.


Но с позиции бизнеса всё зашибись. Оборудование в текущих ценах стило бы порядка 5 - 6 млн. руб., при этом зарабатывает чистыми порядка 3 - 4 млн. руб. В месяц. Аналогов нет, потому что специализация его настолько узка, что всего их в стране - пара тысяч и больше их не нужно, просто потому что в стране нет и физически не может быть больше работы для него. И в мире эту задачу никто не решает (им нахер это не упало).


Угадайте в какое место вас пошлют с рассуждениями о том насколько "это говно"? Мне этот заказ попал в ...дцатую очередь и я заработал просто на том, что молча выполнил свою работу. Не рассуждая про говно.

0
Автор поста оценил этот комментарий

Ты не на месте моего начальника


1. Петабайты нормально для сотен миллионов пользователей.


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


3. Давай до свидания. Если там 30 запросов в секунду то это еще смешнее.


>2. В нагруженную БД заливать данные по 1 строке в запросе может только клинический идиот.

В хайлоаде сливают по 1 строке, но не в БД, а в сервис очередей.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Пахнуло Яндексом ;-) В принципе кто в теме, тот знает о чём речь.

2
Автор поста оценил этот комментарий
Тут сложно поспорить, ибо "хранилище для OLAP" очень размытая формулировка.

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

В бизнесе нет задачи "сделать хранилище OLAP", есть задача "Хочу видеть это, вот это и вот это"
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

На самом деле есть. То, что отчеты выгружают обычно из OLAP не значит, что нет тех, кто с ним напрямую работает. Очень редко, но есть.

показать ответы
0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Потому что логика написания другая. Фронт и бэк - тот же принцип.


В императивных языках (Py, C++ и т.д.) ты пишешь "как", в декларативных (HTML/SQL/Prolog) "Что".


Очень грубо в императиве:

Взять А прибавить Б и разделить на В


В декларативе:

Вывести список девушек от 18 до 35 не замужем, без детей (SQL)

Вывести таблицу с заголовком Х и даннми У (HTML)


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

показать ответы
0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

В больших. Но там далеко не все работают

показать ответы
0
Автор поста оценил этот комментарий
Как программист 1с скажу, что как и в любом другом яп, начальный уровень доступен 90%, а вот уровень я могу решить почти любой вопрос самостоятельно, доступен очень не многим. Большинство 1с-ков, не способны на решение не стандартных задач. А что, в других яп как то по другому? Да, язык 1с примитивен, но.. в реальных задачах, нужно знать и понимать много чего за рамками 1с. А что, в других яп по другому? Одним словом, не нужно принижать 1с в угоду других яп. И тут и там есть свои конструкторы и мнение, что очень низкий порог вхождения. Он конечно низкий, но вот далеко не каждый сможет уйти с начального уровня на решение реальных бизнес задач.
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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


Я могу считать человека идиотом потому что он забивает гвозди микроскопом, но никогда не считал идиотами тех, кто пользуется микроскопом или молотком. Потому что знаю довольно много технологий и скажу, что даже в примитиве типа HTML/CSS есть много не очевидных нюансов, от которых у "илитных программистов" мозг сломается.


Всё просто:


Если поставленная задача решена, то всё хорошо. Если поставленная задача решена оптимально, то всё отлично. Если кто-то с чем-то не согласен, то может сразу идти нахуй.


В любом ЯП есть своя специфика, методы, правила, стандарты и т.д. и т.п. Они продиктованы средой в которой этот ЯП рождался и целями, которые перед ним ставили. По сути все ЯП равны и "программист на Х", это прежде всего программист, а потом уже Х. А кто считает, что его Х равнее... Оруэловский "Скотный двор" ИМХО не перестанет быть актуальным никогда.

Автор поста оценил этот комментарий

Мне просто приходилось переносить это под другую БД, после того как кончилась поддержка. БД умирают, и десятки человек для поддержки того, что может в любой момент сломаться это путь в никуда.

Даже для одной БД 6к строк не тестируемого и не версионируемого кода это 6к проблем.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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


Поскольку понимания ситуации явно нет - есть основная БД действительно крупной компании. Например, масштаб в половину Газпрома. В эту БД сливаются данные из тысяч других БД из разных систем 1С, CRM, ERP, парсинги сайтов, ОФД, показания СКУД, систем мониторинга и т.д. и т.п. Потом из этой БД с разной частотой (от часа до года) запросами делаются тысячи разных отчетов для десятков тысяч сотрудников.


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


И запрос этот никто версионировать не будет. Скажу больше, его и бэкапить особо не будут. Потому что его принципиально нельзя "немного поправить" т.к. написать с нуля  похожий запрос будет сильно проще по времени и нервам. Не потому что разработчик - идиот. А потому что 99% кода запроса, это оптимизация запроса под конкретную БД.

показать ответы
Автор поста оценил этот комментарий

Десяток ТБ это смешно, я с петабайтами работаю и это даже сейчас хайлоадом не считается.

Что значит 100к кода в час, 300 жалких запросов в секунду? Такую нагрузку может выдержать ноутбук с авито за 5к.

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Честно? На месте начальника я бы вас уволил. По двум причинам - во-первых вы думать принципиально отказываетесь.


1. Размер БД. Петабайты в холде и даже гигабайты, не говоря про ТБ в хоте, это две принципиально разные вещи.


2. Число запросов. То есть вы реально считаете, что в базе на десятки ТБ есть ровно 1 таблица в которую стабильно и ламинарно заходит 100к строк?


Во-вторых, если я провожу собеседование и мне говорят подобное

100к кода в час, 300 жалких запросов в секунду

то прощаюсь сразу. Потому что:

1. Если просто поделить 100 000 / 3 600, то получится 27,7, ошибка на порядок в простом делении...

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


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

показать ответы
0
Автор поста оценил этот комментарий

И, оно не в стандарте ведь.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Зато работает. В отличии от не реализованного нигде расширения стандарта

показать ответы
Автор поста оценил этот комментарий

Но ты же понимаешь, что пишешь говно не масштабируемое? Как ты к этому запросу добавишь сервер в друогой стране? Например персональные данные должны обрабатываться в РФ, а у ЕС, в ЕС, как ты это сделаешь?

Да и какие трое суток, мап редус не завезли с облаками?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Я всё понимаю. Это вы, как типичный религиозный фанатик, принципиально отказываетесь понимать, что рассматриваемый запрос - результат конкретной задачи в конкретной БД. Он в принципе никогда не будет масштабироваться, он никогда не поедет в другую страну. Он даже в другую БД не поедет, потому что это главная БД конкретной компании, написана с нуля, существует и всегда будет существовать ровно в 1 экземпляре. Потому что у других крупных компаний свои БД, которые спроектированы под их нужды.


И что обслуживает эту БД штат из десятков человек, которые перепробовали всё. Просто работает именно это.

показать ответы
Автор поста оценил этот комментарий

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

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Поскольку лично приходилось писать подобные запросы могу рассказать как это происходит.


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


Через Х дней десяток строк запроса стало 2к (в моём случае), но работает запрос всего пару секунд или минут.


Да, хочется писать кратко, красиво и правильно. Просто это не всегда работает.

показать ответы
0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

А я и не утверждал, что в 1С "не программисты".


В Си нет классов. Вообще. Но сказать, что С-программисты, это "не программисты, раз нет ООП" нельзя.


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

0
Автор поста оценил этот комментарий

И где тут питон?

SQL/Framework;

SQL/Foundation;

SQL/CLI — Call Level Interface;

SQL/PSM — Persistent Stored Modules;

SQL/MED — Management of External Data;

SQL/OLB — Object Language Bindings;

SQL/Schemata — Information and Definition Schemas;

SQL/JRT — SQL Routines and Types for the Java Programming Language;

SQL/XML — XML-Related Specifications.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Ну уходит. И что?


Мне просто любопытно, что элементарная мысль о том, что эти 6,5к строк кода запроса связаны с конкретной и далеко не типовой задачей в далеко не типовой БД в вашу голову просто не заходит.


При этом в БД, которые находятся в 6-й нормальной форме, сотни строк запроса могут уходить банально на джойны. Потому что в 6НФ абсолютно все таблицы это либо ИД+значение или ИД+ИД. Таблиц с 3 и более колонками просто нет. Вообще. А поскольку JOIN обычно в 2 строки пишут, то просто собрать ФИО, это уже минимум 14 строк в запросе (2 join на колонку + строки select и from).


Если в запросе нужен union, то количество строк возрастает в разы, а case-wheh-then в зависимости от задачи сам по себе может быть дико большим.

показать ответы
Автор поста оценил этот комментарий

1. Угу, как и SQL/CLI, запросы к базе в языках это такое же расширение.

2. И?

3. И? Один расширяет другой, и по синтаксису можно заметить, что один это подмножество другого.


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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Забавно. Аргументация "это стандарт т.к. используется в не реализованном никем расширении" - норм, а я чушь несу.


По той же логике можно назвать Python не ЯП, а расширением SQL. Даже более логично, ибо реализовано в PostgreSQL

показать ответы
2
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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

0
Автор поста оценил этот комментарий
Го яп с вордпресс сравнивать )
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

WP это CMS

1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Не все задачи нужно глубоко понимать.

показать ответы
0
Автор поста оценил этот комментарий

травкой конечно) заходи) вместе оценим.

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

На самом деле не мутант. Есть вещи, где 1С объективно рулит. Есть вещи, где она полностью неприменима. Те же OLAP-кубы, "умное" оборудование и т.д. и т.п.


Была идея сделать унифицированную интеграцию, можно сказать "бесшовную" между нормальными структурами и 1С. А не рожать ёжиков месяцами там, где можно всё порешать за 5 минут.

1
Автор поста оценил этот комментарий
Я не специалист по SQL, но неоднократно писал циклы в хранимках, поэтому мой ответ на академичность не тянет. Синтаксически реализация циклов, ок пусть в pl/sql не сильно отличается от других языков.
А по 1с будет ликбез по циклам?
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

PL/SQL и SQL имеют меньше общего, чем Java и JavaScript. Названия похожи, но сущности - принципиально разные.

7
Автор поста оценил этот комментарий

Судя по посту у вас самих низкие требования к разрабам 1С, поэтому и дефицита у вас нет.

А потом будете сидеть с таким лицом: "а кто это здесь наговнокодил, почему всё тааак тормозит" ))

Иллюстрация к комментарию
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Понятно, что в самой 1С. За их методы обращения с БД нужно кувалдой по пальцам бить. Долго и вдумчиво.

показать ответы
5
Автор поста оценил этот комментарий
поэтому полноценным программистом разработчик 1С не является

Ох уж эти комплексы исключительности "полноценных" программистов.

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Да нет никаких комплексов. Лично у меня. Мне в какой-то мере похрен на каком ЯП писать.


Просто "пустая" конфигурация, на самом деле совсем не пустая. И если уходить с 1С на другой ЯП, то нужно всего лишь на этом другом ЯП в каком-то виде эту обвязку самому написать. Всё.


Ничего суперменского нет. Но те, кто хотят уйти с 1С на этом моменте очень часто спотыкаются.

1
Автор поста оценил этот комментарий

SQL/PSM часть стандарта SQL и там есть совершенно обычные циклы, не неси чушь.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

1. SQL/PSM это РАСШИРЕНИЕ стандарта SQL.

2. Полностью НИГДЕ не поддерживается. Наиболее полно поддерживается DB2.

3. Стандарты SQL и SQL/PSM разные и не наследуются друг от друга.


По сути вы сейчас менее точны, чем те, кто Java к JavaScript прикручивают. Так что вопрос кто из нас чушь несёт.


Да и те, кто императивщину в SQL видел знает, что там различий сильно больше, чем общего.

показать ответы
3
Автор поста оценил этот комментарий

В смысле, вам все описанное в статье знакомо?

Или наоборот, вам без примеров непонятно?

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Я бы почитал с удовольствием

3
Автор поста оценил этот комментарий

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


но блять вот за эти строчки


как минимум 80% задач в 1С могут решать школьники с 8 класса (по шаблонам в ИТС).

То есть дефицита кадров нет и скорее всего никогда не будет.


просто выпей ЙАДУ, как говорили олдскул герои. либо ты поверхностно знаешь 1с либо вообще не вдупляешь что говоришь.

пункт а. 90% решать шаблонные варианты? ммм.. ну типа обновить конфигурацию? или  сделать печатную форму? что ты имеешь ввиду.

пункт б. СЕЙЧАС СУКА ЭТИХ 1с ников с огнем не сыщешь. а толковых перекупают по кругу делая зп х2.

опять же про маштабируемость и области применения. 1с ЭТО РУССКИЙ продукт там писать надо ПО РУССКИ!!! и сферы применения... блять это настолько универсальный инструмент что зная можно нахуевертить всё что угодно. ЛОГИКА ВЕЗДЕ ОДНА!


и поверьте я знаю о чем говорю ( кто в теме тот поймет, у нас развернут РИБ с расширениями)

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Кто бы говорил. Ну допустим у вас хитро выебанная конфигурация, которая требует гуру 1С. А в 100500 конторах базовая стоит. Где пару кнопок нажать надо для обновления "по умолчанию", а Конфигуратор можно годами не открывать, если уметь в СКД.


Не буду спорить, что ваша контора в 80% не попадает... Но это не отменяет существование сотен тысяч, а то и миллионов конфигураций в которых правки вполне по силам 8-класснику.

показать ответы
0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Травкой поделитесь?

1С под Linux уже давно есть, работает замечательно, кстати. Багов гораздо меньше. А делать аналог 1С... Нахуя простите?

показать ответы
7
Автор поста оценил этот комментарий
То есть дефицита кадров нет и скорее всего никогда не будет.

Вообще нет дефицита. Совершенно. Давно ли вы искали мало мальски вменяемого сотрудника?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Периодами ищу. В 1С ситуация лучше всего. Не хорошая, или сказочная, а именно лучше остальных.

показать ответы
0
Автор поста оценил этот комментарий

да вопрос не в сдвигах, понтах и "а раньше лучше было". просто раньше каждый писал библиотеку под себя, потом с нею работал. Сейчас фактически просто тупо настройка модуля для обработки. нужно было выгрузить новые цены на сайт, распарсив xlsx через курс валют с сайта цбр, так подключил библиотек десять в питоне, и строчек 150, из которых 50 в красоту и наглядность и комменты потомкам.
Ну и что я там сделал тогда по факту?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Кто-то и сейчас либы по минимуму пользует ;-)

0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

После Асма - да, все языки можно сказать одинаковые.


mov eax, ebx;

add eax, 10;


;-)

показать ответы
2
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну ОК. Вот смотри, в 1С есть справочники, документы, регистры и т.д. и т.п. То есть пласт знаний об организации данных в БД уже не нужен. Его НЕКУДА применять. Дробление на сервисы / микросервисы... Туда же. Конфигурация одна. Импорты библиотек... Туда же. Базовые классы приложения и код-стайл? Туда же. В 1С этого нет. Потому что всё (и не только вышеперечисленное) намертво вшито в платформу.


При этом это всё не самые простые задачи.

показать ответы
0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

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


Просто в кейсах были и не раз "мы работаем на Х", производитель Х гордо вписывает в партнеры. А по факту 100500 проблем просто заткнуто кадрами.


Например, в одной крупной компании 2 девелопера с з/п 200к+ занимаются тем, что из БД 1С перегружают данные в обычную БД с сохранением в обычные типы данных в обычные таблицы с обычными ID. Эта компания в сумме тратит 700к в месяц на то, что разрабы 1С решили просто повыёбываться с хранением данных.

показать ответы
0
Автор поста оценил этот комментарий
В 1с и скуле)
раскрыть ветку (1)
Автор поста оценил этот комментарий

Циклы в 1С и SQL? Я правильно понял?

показать ответы
0
Автор поста оценил этот комментарий
Видно непрограммиста ретрограда) программирование ушло далеко вперёд, набора кубиков со stackoverflow уже бывает не достаточно. Кстати циклы в 1с и скуле такие же как в других языках.
раскрыть ветку (1)
Автор поста оценил этот комментарий

Циклы где?

показать ответы
0
Автор поста оценил этот комментарий

могу так же ответить узкоспециализированной задачей, нужен программист на 1с 77. там уже не 77 а мутант на ее основе, в росси их человек 10 дай бог.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Извините, а нахера?

0
Автор поста оценил этот комментарий
Да
раскрыть ветку (1)
Автор поста оценил этот комментарий

Циклы. В SQL. В декларативном языке.


Просто на будущее постарайтесь запомнить, что в SQL/HTML/Prolog и т.п. нет и не может быть ни циклов, ни условий, ни других элементов императивных ЯП.


Приближенные к циклам конструкции есть в гибридных ЯП, по типу PL/SQL, но это отдельный класс ЯП и общего с обычным SQL у них очень мало, да и работает данная реальзация только в "своей" СУБД

показать ответы
11
Автор поста оценил этот комментарий
Даже так скажу, ТС ничего не написал про ЗУПовские запросы, а вот там начинается самый смак. Где там упомянутая простота реализации? Кто не открывал общий модуль на семёрке, кто не входил отладчиком в бесконечное множество вызываемых процедур ЗУП/КА2, тот и дальше будет твердить о простоте реализации. Очень просто, да.
раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну смотря кто с чем сравнивает. По сравнению с запросом в SQL на 6,5к строк или серии кода на 30к строк, это всё не так уже и сложно.

показать ответы

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества