Pull to refresh

Comments 43

На самом деле, самому периодически приходится писать на 1С. И с проблемами автора тоже сталкивался.
irony` Опрос среди программистов показал, что программисты ненавидят программировать `
Имеется ввиду работа, а не собственное творчество
Немного неожиданная реакция… Я собственнно не жалуюсь ведь. Можно и циклами аккуратно пользоваться. Пока ждал публикации, с озона пришлел «Совершенный код» Макконелла. Там много написано, как с умом циклы использовать, и даже про goto несколько оправдательных слов есть.

Просто мне кажется, что если заранее себе поставить условие использовать алгоритмамы, вместо циклов, меньше шансов в запарке написать что-то неудобоваримое. Пока не поймешь как следует задачу, агоритмами ее не обобщишь. А циклы можно начать писать даже не додумав до конца как все работать будет.
Идея интересная.
Надо пробовать…
Сам работаю с 1С и приходится иногда делать отчеты для руководства.
База растет… отчеты всё медленнее и медленее…
Если что — пишите в личку, пообщаемся.
Мне кажется, что под жестью все имеют в виду синтаксис в 1с. Программирование на кириллице для меня — это нечто выходящее за рамки :).
За месяц привыкаешь.
Не совсем к теме, но мне давно не дает покоя вопрос: почему компания 1С тратит лишние ресурсы изобретая свой интерпретатор вместо того что-б использовать какой-нибудь опен-сорсный, стабильный и популярный?
а лицензирование и зарабатывание денег?
Многие используют и зарабатывают деньги, тот же Lua применяют в продаваемых играх.
С таким же успехом они могли написать свой сервер БД.
Как программист 1с скажу, что как RAD для задач учета 1с — действительно лучшее. по совокупности плюсов.
Но.

1) требуется именно программист RAD, языка неспециализированного. Человек, занимающийся таким узким направлением, теряется, как правило, специалист в IT. Автор статьи — редкий умница, должен признать. Мне чаще приходилось общаться на почве интеграции с до ужаса безграмотными консультантами SAP или программистами 1С;

2) нет возможности использовать наработки большого сообщества программистов; а отдельная средних размеров фирма вроде 1С, ясно дело, просто не потянет адекватное развитие языка;

3) нет возможности привлекать программистов на этих самых языках общего назначения.

Тадам.
а как, кстати, язык программирования в 1С называется? Я так понимаю, RAD у вас — Rapid App-n Dev-t?
Язык программирования 1с называется «Встроенный язык 1с». RAD — именно так.
У 1с есть «Библиотека стандартных подсистем», где реализована куча всего — от типовых справочников контрагентов/номенклатуры до системы логирования действий пользователя, регламентированных календарей и загрузки курсов валют.

1с может взаимодействовать с компонентами, разработанными другими людьми через командную строку, COM, SOAP, внешними компонентами, написанных на других языках, HTML, XML и т.д.

есть куча специализированных ресурсов, на которых выложены разработки большого числа программистов, таких как infostart.ru или специализированных форумов типа mista.ru
Думаете, я не в курсе? Но. Каждая либа — это чудо самодейтельности с индивидуальным комплектом проблем. Лучше знаю про траблы SAP на примере SAP XI, но были непонятности и с 1C

Да что ж это я вам рассказываю? Уверен, вы и так в курсе.

Честно, вот честно, просто признайтесь. Ну нет причин создавать собственный язык, кроме исторических! Тем более настолько непохожий на типовые.
Это вопрос философский. сколько за последние 20 лет (с 1991 года, когда была основана 1с, сама учетная система была создана несколько ранее, для «внутреннего» пользования) было создано новых языков программирования? а был ли в этом смысл? начиналось все как скриптовый язык для бухгалтеров, чтобы они сами могли что-то подправить в соответствии с особенностями учета, а закончилось «почти» полноценным специализированным языком.

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

Что же до последнего, про бейсик, це же не комплимент языку, сами понимаете :)

Зато простой и дубовый.

Ну и вспоминаем, что в середине-конце 90-х VB был чуть ли не основным средством для создания внутреннего софта для контор(в российских реалиях правда больше прижился дельфи). Порог вхождения в него был очень низкий, а гуру умеющего делать на плюсах то же самое и в те же сроки держать было гораздо накладнее.
Вместе с тем, VB исчерпал себя, не так ли? Как и Delphi, по большому счету. Anyways, оба языка были прямым следствием доминанты единственной базовой платформы — Win32 API

Причины подробно перебирать нынче лень. Ключевая одна. Платформой для разработки приложений — в том числе корпоративных — стал Веб; и ни VB, ни Delphi, являясь замечательными средствами накидывания форм; с задачей работать не могли. Более того, Майкрософт вообще до самого последнего времени игнорировала Интернет.

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

Я ведь тоже не на ровном месте это говорю. Помимо интеграции с 1С на небольших фрилансных сайтах, в последнем крупном проекте для одной из жирнейших госкорпораций мне довелось общаться с, цитирую, «лучшими специалистам по SAP в России».

Мужики нормальные, но ни бельмеса за пределами своей консольки не шарят. Был один нормальный парень; но в среднем… Они нам запороли фразой «да у нас все и так работает» месяца два работы.

А ведь SAP типа считается посерьезней 1C.
Я думаю, ресурсов в общей массе не так много уходит, по сравнению с затратами на поддержку типовых решений. Преимущества своего языка некоторые есть. Не надо знать английский язык, чтобы давать грамотные имена переменным. Все заточено друг под друга: оболочка вокруг СУБД, язык программирования, редактор GUI. Только «продвинутых» возможностей в языке нехватает: инкапсуляции, проверки типов, ФП опять же. Боятся, что с такими «гранатами» «обезьяны» наколбасят чего-нить :).

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

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

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

«продвинутых» возможностей в языке нехватает: инкапсуляции, проверки типов, ФП опять же. Боятся, что с такими «гранатами» «обезьяны» наколбасят чего-нить :)

Мне как то кажется, что инкапсуляция и прочие «продвинутые» возможности не применимы если в языке ООП отсутствует в принципе.
Они начинали в далеких 90-х годах… тогда еще не было многих вещей.
Они выбрали свой путь.
Я начинал с 1С 7.5, вот там вообще жесть была.
А потом уже поздно было менять… слишком много народу стало пользоваться их системой.
Даже когда они меняли 7.7 на 8.0, хоть там и было много изменений технических но принципиально ничего не изменилось, вою было до небес про несовместимость и сложность переноса кода с 7.7 на 8.0.
Представляю что-бы было если они поменяли свой интерпретатор например на python…
В общем думаю они просто заложники выбранного пути…
Такой код потом просто выкинут, не будут вникать что к чему.
Что тут сказать. Я и сам этого опасаюсь.
повторяющиеся куски — временные таблицы, те запросы, что «обычное формируются конкатенацией строк» — с успехом реализуются с помощью построителя запросов и СКД, т.е. стандартными средствами. просто очень много начинающих программистов 1с не умеют ими пользоваться (к сожалению).
СКД хорошая вещь, но бесполезна, если данные не надо выводить в отчет. Я так понял перехватить результат выполнения комоновщика можно, но там прет какой-то поток управлящих объектов на подобие тэгов xml, из которых непонятно как собрать нормальную таблицу. Если Вы знаете об этом больше меня — просьба поделиться.

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

В проектной документации я постарался обосновать принятые решения.
да простят меня мозги тех, кто не привык к названиям 1с, но «ПроцессорВыводаРезультатаКомпоновкиДанныхВКоллекциюЗначенийИмениБорисаГеоргиевичаНуралиева» — выводит в коллекцию значений :)
Ай спасибо! Буду учить матчасть.
Кстати, источником данных для Построителя может быть результат запроса
А почему бы не передавать строку с именем функции, а внутри строить выражение, добавляя к этому имени фактические параметры? Прочитал бегло, извините, если не догнал.
Без проблем. Только для тривиальных случаев писать отдельную функцию долго, а чтобы прочитать надо глазами прыгать в другой конец листинга. Поэтому — выражения.
По моему это все зря. 99,9% отчетов можно сделать на языке запросов 1С (он же практически SQL). После того как в 8.1 или 8.2 не помню точно, появились временные таблицы вообще все красиво выглядит. Если поискать в интернете можно найти реализацию только на языке запросов 1С — ФИФО, ЛИФО и т.д.
И кстати практически любой запрос можно сделать без «контакенации строк», стандартная СКД к этому приучает…
Когда нужна контакенация:
— Пример «Дебиторская задолженность по интервалам» в типовой УТ. Количество полей запроса зависит от того, что выбрал пользователь, поэтому без контакенации никак. А запрос там — жесть.
— Бывает один и тот же подзапрос входит несколько раз без изменений в итоговый запрос в разных местах. Можно без контакенации все написать как есть. В случае внесения в него изменений надо менять одно и то же в нескольких местах и не запутаться.
— Хорошо, вложенный запрос заменили временной таблицей — от дублей избавились. Повторяющийся код может быть внутри выражений в полях и условиях запроса (выбор когда тогда и т.д). Как тут дубли устранить?
Мне кажется вы изобрели велосипед. Все что нужно для работы с БД и оптимизацией уже есть. Временные таблицы, индексы по временным таблицам, сложные условия. Есть СКД, которая на выходе может выдавать дерево и таблицу значений.
Значит пост был не зря опубликован. Есть еще над чем подумать, стоит ли идти дальше. СКД буду учить.
Если не хватает функционала встроенного языка запросов — то правильнее было бы написать функции, дополняющие язык запросов. Например, для хитрого приведения типов с учетом пустых значений, или для вставки динамических условий. Чтобы в конструкторе вставить псевдо-функцию (как переменную запроса), которая перед выполнением запроса будет преобразована в нужный кусок текста запроса.
Не совсем понял, каким образом преобразована? Замена одной подстроки в тексте запроса на другую? А причем тут тогда переменные запроса? Переменные запроса в куски текста вроде не преобразовываются (если только платформа этим не занимается, но платформа наши псевдо-функции юзать не станет).
ТекстЗапроса=«ВЫБРАТЬ &СписокДинамическихПолей ИЗ РегистрОстатков ГДЕ &УсловиеВключаемые И &УсловиеИсключаемые УПОРЯДОЧИТЬ ПО &Сортировка»;

Дальше с помощью СтрЗаменить() меняем переменные в тексте запроса на нужные нам поля, условия, подзапросы, итд…

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

В принципе, то же самое получается при использовании СКД, но иногда проще олдскульный метод подмены.
Sign up to leave a comment.

Articles